由 J. Sutherland、K. Schwaber、D. Star、M. Lacey 及 D. J. Anderson 撰写的关于敏捷的文章合集

微软公司为 Visual Studio 开发者汇总了很多资源，包括敏捷软件开发的原则、实践和准则。这些资源浓缩了Jeff Sutherland、Ken Schwaber、David Star、Mitch Lacey 和David J. Anderson 这些有影响力的敏捷开发领袖的文章，内容涵盖很多敏捷方法论的精华并对所有软件开发者都有助益。

这些资源分为下面三个部分：敏捷原则、敏捷实践、精益与 CMMI。

敏捷原则

敏捷原则和价值

Jeff Sutherland 详细说明了在敏捷软件开发宣言中描述的四个核心价值：

1. 个体及交互

2. 交付可工作的软件

3. 客户合作

4. 拥抱变化

他同时区分了敏捷、方法论和实践，详细讲述了 Scrum 及 XP 的含义及它们之间的互补关系。

敏捷十年回顾：我们在下个十年如何改进

在这篇文章中，Jeff Sutherland 回忆了 2011 年在犹他州 Snowbird 举行的敏捷 10 年回顾会议，一些当年敏捷宣言签署者与敏捷思想领袖会面，庆祝这 10 年来敏捷所取得的成绩，并指出在接下来的 10 年中继续保持成功的四个关键因素：

1. 追求技术卓越

2. 鼓励个体改变并引领组织转型

3. 组织的知识及改进教育

4. 在整个过程中最大化价值创造

中列举了几个通向成功之路的几个阻碍之后，Sutherland 总结道：

对于敏捷团队来说，最重要的是改进团队的实践以解决世界范围内敏捷社区最大的问题——技术卓越。准备好产品的 backlog 需要专业的产品经理，他们能够理解用户的需要，也需要团队的能力及交付卓越软件的激情。在一次 sprint 中完成产品 backlog 需要对工作进行优先级排序、持续集成进行中的任务并不容许缺陷。追求技术卓越是未来十年（敏捷社区）最重要的事情。

完成和未完成

运用实际或假想的案例，Ken Schwaber 及 David Starr 探讨了认为完成和实际完成，解释了如何区分这两者及为什么混淆它们会对项目的成功产生影响。他们详细的描述了透明性，技术债，交付计划及两种能够让事情真正做完的技术手段：针对 Scrum 的 Scrum和持续集成。

敏捷实践

构建和管理产品的Backlog

在这篇文章中，Mitch Lacey 探讨了产品 backlog 的重要性，给出了创建及维护一份良好的产品 backlog 的实践。文中他包含了下述主题：用户故事、估算、优先级排序及保持 backlog 整洁，文章的最后写道：

一份良好的产品 backlog 有助于确保构建出来的软件包含了最重要的功能，这些功能是你在与客户及项目干系人沟通的时候发现的，并采用用户故事记录下来。为了创建并维护一份好的产品 backlog，你需要保持与项目干系人 / 客户及项目团队持续的沟通——每个 sprint 都要进行。

构建良好的 backlog 不能保证交付一个良好的软件系统，但是如果没有好的 backlog，几乎可以肯定的是，最终交付的软件系统不是客户需要的。换句话说，不保持 backlog 持续更新几乎可以肯定导致项目失败。

Product owner 是一份全职工作，backlog 就是他们的职责所在。认真的对待这个角色。让产品 backlog 保持良好状态——你的客户会感谢你的。

优先级排序

Mitch Lacey 接着前一片文章《构建和管理产品的Backlog》写道，如何采用三种方法进行backlog 优先级排序：

• 客户满意度的Kano 模型

• 创新游戏

  • 修剪产品树

  • 购买一项功能

• 相对权重 —— Karl Weigers

Lacey 视 backlog 为“有生命的”，需要不断的投入精力并不断重新调整优先级，以便获得成功。

估算

在这篇文章中，Mitch Lacey 指出了项目估算中的问题，解释了为什么做出准确的估算很困难，也谈及故事点作为度量单位，并提出两种估算技术：计划扑克，和估算墙。Lacey 最后总结说：

估算是困难的，因为在项目开始时有太多的不确定性。Product Owner 和敏捷项目经理试图尽早让价值最大化，通过与他们的 product owner 和项目干系人沟通进行学习，产出可工作的软件，并不断将对软件的反馈集成进来以便能够达到可发布的状态。但是即使是敏捷项目，也必须给出某种估算，说明功能集何时能够交付。

Sprint 计划

Mitch Lacey 以一篇针对Sprint计划的文章作为他关于敏捷实践的系列文章的结尾。在本文中，他开篇探讨了预测与承诺，接下来说明了计划及如何达成目标，在此过程中伴随着解释了一些常见的问题和解决方案。Lacey 认为 Sprint 计划“不需要如此具有挑战性。（计划）通常是有趣的，并且这是一个让整个 Scrum 团队通过在一起工作建立友谊的机会”。

精益和 CMMI

精益软件开发

在这篇文章中，David J. Anderson 介绍了精益思想，及与敏捷之间的关系，并解释了精益的价值、原则和实践。Anderson 讲述了精益的价值在于：

• 承认个人的条件

• 承认复杂性和不确定性是知识工作的本质

• 共同工作以得到更好的经济效益

• 并得到更好的社会效益

• 探索、接受并怀疑来自各个学科的想法

• 以价值为主导的社区，增强积极改变的速度和深度

定义一个精益开发流程的原则是：

• 遵从系统化思考和设计方式

• 自发的产出可以被构架一个复杂的适应性系统的上下文所影响

• 尊重个人（作为系统的一部分）

• 采用科学方法（来引领改进）

• 鼓励领导力

• 创造可视性（在工作、工作流和系统运营中）

• 减少流动时间

• 减少浪费以提升效率

Anderson 说道，精益软件开发“没有规定实践”，然而社区接受了很多精益实践，包括：累积流图、可视化控制、可视化看板系统、小批量 / 小件流、自动化、改善事件、每日站立会议、回顾会议和运营回顾。

Anderson 总结说：

没有单独的精益软件开发流程。如果一个流程很明确的符合精益软件开发的价值和原则，那么这个流程就能被认为是“精益的”。精益软件开发没有规定实践，但是很多活动已经很常见……

采用精益软件开发流程的组织，如果展示出所有三种类型的浪费（不均衡、浪费及负荷过重）都很少，并显示出能够通过更有效的风险管理来优化价值的交付，则可以被称为精益的。在精益中追求完美是个不断的旅程。对完美的追求没有终点。真正的精益组织总是不断寻求更进一步的改进。

精益软件开发仍然是一个新型的领域，并且我们可以预期在下一个十年中仍会不断演进。

CMMI 原则和价值

这篇文章总结了这一系列有关敏捷的文章资源所谈到的内容，David J. Anderson 断言，经理、流程工程师和项目干系人能够通过采用能力成熟度模型集成（CMMI）获得对一个组织有价值的洞见。Anderson 解释了组织的成熟度是什么、CMMI 模型、一个组织如何能够沿着各成熟度层次不断进步，以及 CMMI 成熟度是如何评定等级的。

查看英文原文： A Collection of Agile Resources by J. Sutherland, K. Schwaber, D. Star, M. Lacey, and D. J. Anderson