精益与敏捷软件开发概述
广义而言，精益与敏捷是两组具有高度兼容性的价值观和原则，都阐述了如何成功地进行产品开发。Scrum、XP和看板则是将这些原则运用到实践中的三种具体方法。换句话说，它们是精益和敏捷软件开发里轻度重叠的三种不同风格。
Scrum、XP和看板都有很具体的技术，如Sprint规划会议（Scrum）、结对编程（XP）和限定在制品（看板）。这些技术都可视作流程工具。这三种工具的功能都有相当程度的重叠，例如，三种工具都建议使用真实的任务板将当前工作以可视化方式展现出来。
1、敏捷软件开发（Agile Software Development）
出现于2001年。当时，来自软件开发界的十七位思想领袖聚集在美国犹他州的一个滑雪度假胜地，探讨软件开发如何取得成功。研讨会期间，他们总结出一些强大的共同观点，形成了软件开发如何成功的共有愿景，即后来人们熟知的《敏捷宣言》 。
《敏捷宣言》内容如下：
我们正在通过亲身实践以及帮助他人实践，探寻更好的软件开发方法。通过这项工作，我们建立了如下价值观：
- 个体和互动胜过流程和工具。
- 可以工作的软件胜过详尽的文档。
- 客户合作胜过合同谈判。
- 响应变化胜过遵循计划。
也就是说，虽然右项也具有其价值，但我们认为左项具有更大的价值。
研讨会结束后，他们就支撑这些价值观的以下十二条原则达成共识：
- 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
- 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，要通过敏捷过程掌控变化。
- 经常地交付可工作的软件，比如相隔几星期或一两个月就交付，倾向于采取较短的周期。
- 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
- 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
- 不论团队内外，传递信息效果最好、效率也最高的方式是面对面的交谈。
- 可工作的软件是进度的首要度量标准。
- 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
- 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
- 以简洁为本，它是极力减少不必要工作量的艺术。
- 最好的架构、需求和设计出自自组织团队。
- 团队定期地反思如何能提高成效，并依此调整自身的举止表现。
虽然敏捷一词正式出现于2001年，但多数敏捷方法都是在20世纪80年代到90年代形成的。敏捷只是一个描述了共同特征的统称。凡遵循上述价值观和原则的方法或方式都可视为敏捷方法。
2、精益概述
精益起源于日本丰田公司的“TPS”（丰田生产方式），即助力丰田成为全球最成功汽车制造商的生产方式。实践证明，TPS的基本原则“丰田之道”几乎适用于所有行业，包括软件开发。
敏捷与精益可以看作是一对拥有共同价值观但起源不同的兄弟。精益起源于制造业，敏捷起源于软件开发。两组原则都能与对方完美契合，而且适用范围都非常广泛。越来越多的软件开发组织在探索如何将两组原则完美结合，从而应用于从产品创意到交付的完整开发链。
1）全局优化
局部的优化长期来说，会对系统整体优化不利。
- 专注于整体价值流：从概念到现金。从客户需求到软件部署。
- 交付完整产品：客户不要软件产品，他们要解决问题。完整的解决方案是由完整的团队构建的。
- 着眼长期：警惕导致短期思维和优化局部业绩的治理和激励体系。
2）消灭浪费
浪费指所有那些不能增加客户价值的事项。软件开发中的三大浪费如下：
- 构建错误的功能：“没有什么比高效完成根本不应做的工作更无用。”
- 拒绝学习：我们有很多策略都干扰了我们学习，例如，只按计划行事、频繁移交、决策与工作分离等，而学习则是开发的精髓。
- 辗转现象：那些干扰价值顺利流动的做法，例如，任务切换、请求清单冗长、大堆未完成的工作等等，都只能达到事倍功半的效果。
3）品质为先
如果在验证过程中总是能发现缺陷，那流程就有问题。
- 最终验证不应发现缺陷：所有软件开发流程的根本目的都是尽早在开发阶段发现并修复缺陷。
- 采用测试先行的开发模式让流程具有防误机制：测试（包括单元测试、端对端测试和集成测试）必不可少，以此建立信心，保证系统在任何层次、在开发阶段任何时间点都始终正确无误。
- 打破依赖：系统架构应当支持随时添加功能。
4）不断学习
规划工作非常有用。学习则必不可少。
- 可预测的性能来自于反馈：可预测的组织不会猜测未来并称之为计划；反之，他们会培养能力对未来做出响应。
- 保持选择方案：视代码为实验——使其具有容变性。
- 最后可靠时刻：在做出不可逆转的决策之前尽可能学习。不要提前做出纠正代价高昂的决策，也不要事后才做出决定！
5）尽快交付
从一开始就深入了解所有干系人看重的价值。然后基于这样深入了解的价值观，创建稳定、连贯的工作流。
- 快速交付、高质量和低成本是完全相互兼容的：以速度竞争见长的公司拥有很高的成本优势，他们可以交付优质的产品，而且对客户需求更为敏感。
- 排队理论同样适用于开发，而不仅仅是服务行业：专注于使用性会造成交通堵塞，反而降低了使用性。以较小的批量、限制同时进行的工作数来缩短周期时间。大力限制等待清单和队列的长度。
- 管理工作流比管理进度表要容易得多：建立可靠、可预测交付物的最佳方式是通过迭代和看板建立可靠、可重复的工作流。
6）人人参与
聪明、有创造力的人员的时间与精力，是当代经济的稀有资源和竞争优势的基础。
获得公正薪资的人员在自主性、成长性和使命感等方面受到激励。
- 自主性：最有效的工作小组是半自治团队，有一个内部主管从头到尾负责完整、有意义的任务。
- 成长性：对人员的尊重意味着提供挑战、反馈和让所有人都能够发挥潜能、表现卓越的良好环境。
- 使命感：将工作与价值挂钩。只有相信自己工作的意义，团队成员才会全心投入工作，实现这种使命。
7）不断提高
结果不是重点——重点是培养人、发展*，使之能够交付结果。
- 失败是个学习机会：即使是非常小的失败都会被深入调查并纠正的，做到一丝不苟的时候，才可能获得最可靠的性能。
- 标准存在的目的就是要被质疑和提高的：将现行的、最知名的做法纳入人人都遵循的标准，与此同时鼓励所有人质疑并改变标准。
- 使用科学方法：教团队建立假设、开展大量快速实验、创建简明文档并实施最佳方案。
3、Scrum概述
Scrum是由杰夫•萨瑟兰（Jeff Sutherland）和肯•施瓦伯（Ken Schwaber）于20世纪90年代早期共同创建的一种软件开发过程。Scrum核心内容如下：
1）按优先顺序排列的产品需求清单
将产品分割成一组小而具体的可交付物，即产品需求清单。产品负责人对产品愿景进行定义，并按商业价值以及风险和依赖关系等其他因素对需求清单进行排序。
2）跨职能团队
将产品所有人员划分为多个小规模、跨职能、自组织的开发团队。每个团队都有一位产品负责人负责定义愿景和总体的业务优先顺序，以及一位Scrum大师专注于改进团队、消除障碍。
3）Sprint
将整个开发时间划分成多个短小的、固定的迭代周期或Sprint（通常为两周或三周）。开发团队自行决定每个迭代周期要完成多少个产品需求清单项。每个迭代周期最后都要演示已通过测试、能够发布的版本。
4）持续调整版本发布计划
产品负责人与客户一起合作，在每个迭代周期之后仔细检查发布版本，根据所得的结果，不断优化版本发布计划，并更新优先排序。
5）持续调整流程
开发团队通过每个迭代周期之后的回顾会议不断优化开发流程。所以，Scrum开发模式意味着：不是由一个大团队用很长的时间来开发一个大产品……而是由一个小团队用很短的时间来开发一个小功能。但定期集成，以构成整体。Scrum模式不会硬性规定任何具体的工程实践——这些都由团队自行决定。不过，在实践中，不纳入XP的核心工程实践而通过Scrum模式取得成功是非常困难的。
4、XP概述
极限编程（XP）是肯特•贝克（Kent Beck）于20世纪90年代中期创立的软件开发方法。该方法以简洁、沟通、反馈、勇气和尊重等价值观为基础。XP方法是与Scrum并行发展的，实际上包含了大多数相同要素。例如，XP中的现场客户（on-site customer）就大致等同于Scrum中的产品负责人（product owner）。
从这个意义上而言，Scrum可被视作XP的“包装纸”，专注于结构问题和外部沟通。而XP除多数理念都与Scrum相同以外，还增加了一些团队内部的工程实践，包括以下内容：
- 持续集成：拥有一个随着团队的开发可自动编译、集成并测试代码的系统。这样就能尽早为开发团队提供有关产品质量方面的反馈。
- 结对编程：在一台工作站上进行结对编程，从而使学习效果最大化、设计质量最大化、缺陷最小化。
- 测试驱动开发：采用测试代码驱动系统的设计。编写自动化测试脚本，然后编写刚刚足够的代码以使其通过测试，然后从根本上重构代码，提高其可读性，移除重复代码。清理并重复这一过程。
- 集体代码所有权：允许（实际上是鼓励）开发团队的任何人编辑代码库的任何部分。这样可营造出团队所有权的意识，确保整个系统的设计都一致、易于理解。
- 增量式设计改进：从最简单的设计开始，然后运用重构等技术持续不断地改进设计，而不是从一开始就做好完整的设计。
上述许多实践都互为基础。例如，如果系统的自动化测试覆盖范围不足，那增量式设计改进就很难实现、令人生畏且风险很高，而若要测试覆盖范围足够，则需要通过测试驱动开发和结对编程才可实现。不过，如果所有的测试都必须手动触发，而且只能在开发人员的本地工作站上运行，问题就会让人更头痛，所以，我们就需要一个持续集成系统在后台自动完成上述工作，等等。
5、看板概述
看板是敏捷软件开发的精益方法。实际上，看板有着多方面的意义。从字面上看，看板是日语单词，是“可视卡片”（或标志）的意思。在丰田，看板专指将整个精益生产系统连接在一起的可视化物理信号系统。看板的规则很简单。不过，跟象棋一样，规则简单并不意味着游戏简单。
可视化工作流：把产品切分成小块，将每一块写在一张卡片上，然后将卡片贴到墙上。墙上的每一栏都有名称，以此显示每张卡片在工作流中所处的位置。
这就基本上直接实施了精益拉式生产调度系统。Scrum专注于结构和沟通，XP增加了工程实践，看板则专注于将工作流可视化，并对瓶颈进行管理。