1.2 解释精益思想的核心概念，以及这些概念是如何应用到Scrum中
精益的企业是把丰田生产方式应用于业务所有层面所获致的结果。詹姆斯∙ 沃麦克和丹尼尔∙ 琼斯在他们合著的《精益思想》中把精益制造定义为包含五个步骤的流程：
1. 定义客户价值（customer value）
通过与客户对话，为具有特定功能以特定价格提供的产品精确定义价值。通过定义客户价值，知道什么是真正需要做的事，价值只能由最终客户来确定。
Scrum：
1) Scrum框架，通过提供针对复杂问题的自适应解决方案来帮助人们、团队和组织创造价值。Scrum框架本身就是一个创造价值的过程。
2) 产品是传递价值的载体。它具有明确的边界、已知的利益相关者和定义明确的用户或客户。Product Goal是Scrum Team的长期目标。
3) Scrum Team在一个Sprint期间将选择的工作（产品的idea）转化为价值的Increment，是一个创造价值的过程。(Sprint本身就是一个价值驱动的过程。)
4) 在Sprint Planning时，Scrum Team共同讨论为什么这次Sprint有价值？团队从Product Backlog中选择优先级高的需求条目，放入当前Sprint中。团队共同制定一个Sprint Goal，用以沟通当前Sprint最重要的价值，使团队聚焦。
5) Product Owner负责将Scrum Team的工作所产生的产品价值最大化。
6) Scrum Master帮助Scrum Team专注于创建符合DoD的高价值的Increment。
不符合DoD的“半成品”，对用户来说是没有价值的，是一种浪费。
2. 定义价值流程（value stream）
价值流是制造一件特定的产品所必需的一组特定的活动。
Scrum：
1) 在Scrum中，价值流是从一个需求转化为实现的过程。
2) 采用Scrum Board可视化价值流及Sprint的进展。
3) 产品研发的价值流与制造业的价值流是有区别的。
3. 建立连续的作业流程（flow）
价值流中的各项活动形成流动。
第一步，专注于实际目标：具体的设计、专门的订货和产品本身，从开始到完成都绝不让它脱离你的视线；
第二步，可以保证第一步能够实现，是打破工种、职能和企业的传统界限，去掉具体产品或产品系列连续流动的障碍，组成一个精益企业；
第三步，重新思考具体的工作方法和工具来消除所有各式各样的倒流、废品和障碍，使具体产品的设计、订货和生产得以连续进行。
Scrum：
1) 跨职能团队，在团队内部流动。
2) 用户故事，INVEST，小、独立可交付。
3) 通过技术实践和学习，持续改进，不断提升团队速率。
4) Scrum Master保护团队，排除障碍。
4. （pulling）拉动式生产方式
在下游客户提出要求之前，没有一家上游企业生产商品或提供服务。
假如一个组织只把精益技术用于使无人想要的商品流动得更快的话，那么除了产生浪费以外，不会有任何结果。
Scrum：
1) Product Backlog是涌现的、有序的清单
2) Daily Scrum：每天从Sprint Backlog中拉入新的工作任务
3) Sprint Plannning：从Product Backlog中拉入新的工作任务
4) Sprint Review：每个迭代结束，通过Sprint Review检视Sprint的成果并确定未来的适应性，根据实际情况调整Product Backlog以适应新的机会
5. 努力追求卓越
在价值、价值流、价值的流动、被客户拉动等方面，持续改进。
Scrum：
1) Sprint Review：检视Sprint的成果并确定未来的适应性，根据实际情况调整Product Backlog以适应新的机会。
2) Sprint Retrospective：迭代检视，团队识别出持续改进的行动。
3) Daily Scrum 每日检视达成Sprint Goal的进展。
4) Scrum价值观：承诺、专注、开放、尊重、勇气
帕彭迪克夫妇在将精益原则与软件开发结合方面做出了卓越贡献，他们精炼出七个精益原则。（www.poppendieck.com，The Lean Mindset）
1. 全局优化
局部的优化长期来说，会对系统整体优化不利。
∙ 专注于整体价值流：从概念到现金。从客户需求到软件部署。
∙ 交付完整产品：客户不要软件产品，他们要解决问题。完整的解决方案是由完整的团队构建的。
∙ 着眼长期：警惕导致短期思维和优化局部业绩的治理和激励体系。
Scrum：
1) Product Goal
2) 自组织团队
2. 消灭浪费
浪费指所有那些不能增加客户价值的事项。软件开发中的三大浪费如下：
∙ 构建错误的功能：“没有什么比高效完成根本不应做的工作更无用。”
∙ 拒绝学习：我们有很多策略都干扰了我们学习，例如，只按计划行事，频繁移交、决策与工作分离等。而学习则是开发的精髓。
∙ 辗转现象：那些干扰价值顺利流动的做法，例如，任务切换、请求清单冗长、大堆未完成的工作等等，都只能达到事倍功半的效果。
Scrum：
1) Product Goal，Sprint Goal
2) 跨职能团队，全栈工程师
3) Sprint：小步快跑，及时检视、反馈和调整
3. 品质为先
如果在验证过程中总是能发现缺陷，那流程就有问题。
∙ 最终验证不应发现缺陷：所有软件开发流程的根本目的都是尽早在开发阶段发现并修复缺陷。
∙ 采用测试先行的开发模式让流程具有防误机制：测试（包括单元测试、端对端测试和集成测试）必不可少，以此建立信心，保证系统在任何层次、在开发阶段任何时间点都始终正确无误。
∙ 打破依赖：系统架构应当支持随时填加功能。
Scrum：
1) 工程实践：TDD、重构、持续集成
2) 测试：自动化测试、人工测试
4. 不断学习
规划工作非常有用。学习则必不可少。
∙ 可预测的性能来自于反馈：可预测的组织不会猜测未来并称之为计划； 反之，他们会培养能力对未来做出响应。
∙ 保持选择方案：视代码为实验——使其具有容变性。
∙ 最后可靠时刻：在做出不可逆转的决策之前尽可能学习。不要提前做出纠正代价高昂的决策，也不要事后才做出决定！
Scrum：
1) Spike
2) 对失败的态度
3) Sprint：通过迭代形成短反馈
4) Scrum价值观：承诺、专注、开放、尊重、勇气
5. 尽快交付
从一开始就深入了解所有干系人看重的价值。然后基于这样深入了解的价值观，创建稳定、连贯的工作流。
∙ 快速交付、高质量和低成本是完全相互兼容的：以速度竞争见长的公司拥有很高的成本优势，他们可以交付优质的产品，而且对客户需求更为敏感。
∙ 排阶理论同样适用于开发，而不仅仅是服务行业：专注于使用性会造成交通堵塞，反而降低了使用性。以软小的批量、限制同时进行的工作数来缩短周期时间。大力限制等待清单和队列的长度。
∙ 管理工作流比管理进度表要容易得多：建立可靠、可预测交付物的最佳方式是通过迭代和看板建立可靠、可重复的工作流。
Scrum：
1) Product Backlog是涌现的、有序的清单。
2) Daily Scrum：每天从Sprint Backlog中拉入新的工作任务
3) Sprint Plannning：从Product Backlog中拉入新的工作任务
4) Sprint Review：每个迭代结束，通过Sprint Review检视Sprint的成果并确定未来的适应性，根据实际情况调整Product Backlog以适应新的机会。
5) 工程实践：持续集成、持续交付
6. 人人参与
聪明、有创造力的人员的时间与精力，是当代经济的稀有资源和竞争优势的基础。
获得公正薪资的人员在自主性、成长性和使命感等方面受到激励。
∙ 自主性：最有效的工作小组是半自治团队，有一个内部主管从头到尾负责完整、有意义的任务。
∙ 成长性：对人员的尊重意味着提供挑战、反馈和让所有人都能够发挥潜能、表现卓越的良好环境。
∙ 使命感：将工作与价值挂钩。只有相信自己工作的意义，团队成员才会全心投入工作，实现这种使命。
Scrum：
1) 自组织团队
2) Scrum Master真正的领导者
3) Scrum价值观：承诺、专注、开放、尊重、勇气
7. 不断提高
结果不是重点——重点是培养人、发展体制，使之能够交付结果。
∙ 失败是个学习机会：即使是非常小的失败都会被深入调查并纠正的，做到一丝不苟的时候，才可能获得最可靠的性能。
∙ 标准存在的目的就是要被质疑和提高的：将现行的、最知名的做法纳入人人都遵循的标准，与此同时鼓励所有人质疑并改变标准。
∙ 使用科学方法：教团队建立假设、开展大量快速实验、创建简明文档并实施最佳方案。
Scrum：
1) Sprint Review：检视Sprint的成果并确定未来的适应性，根据实际情况调整Product Backlog以适应新的机会。
2) Sprint Retrospective：迭代检视，团队识别出持续改进的行动。
3) Daily Scrum 每日检视达成Sprint Goal的进展。
4) Scrum价值观：承诺、专注、开放、尊重、勇气
实践中的问题：
1. 瀑布换了个名字，叫“精益”
2. 在“精益”的终极也是要求跨职能团队，如果组织架构不变，不形成跨职能团队，不改变是不是能够做到？
3. 精益也应该有产品作为载体（生产某个东西）？
4. 与Scrum如何结合？
5. 看板中“归档”的作用？
参考书：
1. 《精益思想》James P. Womack、Daniel T. Jones著，沈希瑾、张文杰、李京生译
2. 《敏捷软件开发工具——精益开发方法》 Mary Poppendieck、Tom Poppendieck著，朱崇高译
3. 《精益开发实战——用看板管理大型项目》 Henrik Kniberg著，李祥青译
