敏捷原则和价值 - Jeff Sutherland 著
Jeff Sutherland 在 1993 年开发了 Scrum，并与 Ken Schwaber 一起在 OOPSLA'95 上正式发布 Scrum。 他们一起在多家软件公司扩展并增强了 Scrum，并帮助编写 Agile Manifesto（敏捷宣言）。 Jeff 的博客回顾了 Scrum 的起源和最佳实践，网址为 http://scrum.jeffsutherland.com。 |
“敏捷开发”一词源自《敏捷宣言》，《敏捷宣言》是由一个小组在 2001 年编写的，该小组的成员包括 Scrum、极限编程 (XP)、动态系统开发方法 (DSDM) 和 Crystal 的创始人，以及功能驱动开发的代表人物和软件行业的其他几位思想领袖。 《敏捷宣言》为当时分散的敏捷方法树立了一套具有支配性的通用价值观和原则。 该“宣言”详述了建立高绩效团队的四项核心价值。
个体与交互
交付可用软件
客户协作
响应变化
这些核心价值以 12 条原则为支撑，在下面的网站上可以找到这些内容：Manifesto for Agile Software Development（敏捷软件开发宣言）。
这些价值并不是《敏捷宣言》创始人简单说说而已。 它们是切实存在的价值。 每种敏捷方法实现这些价值的方式略有不同，但都有孕育其中一项或多项价值的特定过程和做法。
个体与交互
个体与交互对高绩效团队至关重要。 对一个项目进行的“沟通饱和度”研究显示：当不存在任何沟通问题时，团队效率可以达到业界平均水平的 50 倍。 为便于沟通，敏捷方法依赖于频繁的检查和调整周期。 这些周期以各种不同的频率发生：如每几分钟的结对编程，每几小时的持续集成，每日的例行站立会议，每个迭代的审查和回顾。
但是，简单地提高反馈和交流频率不足以消除交流问题。 仅当团队成员的行为具备几种关键特质时，这些检查和调整周期才会起到良好的作用：
尊重每个人的价值
每次都诚实交流
所有数据、行为和决定都保持透明
相信每个人都是团队的支撑力量
积极投身于团队和团队目标
要培养这些行为特质，敏捷开发管理层必须提供支持性环境，团队教练必须促进这些行为的产生，团队成员必须表现出这些特质。 只有这样团队才能发挥其全部潜力。
发展这些行为特质比看起来要困难。 受文化标准或以往因诚实沟通导致冲突的负面经历的影响，很多团队都难以实现诚实、透明和相互信任的沟通。 要防止这些倾向的产生，领导者和团队成员必须促进有积极意义的冲突。 这样不仅有助于提高行为的实效，还有其他多方面益处：
这样做可以实现过程改进：团队可以列出组织中的障碍或问题列表，正视这些障碍和问题，然后分主次系统地消除它们。
只有思想的自由冲撞才能引发创新，这是 Scrum 的教父 Takeuchi 和 Nonaka 研究并记录的一种现象。
团队要向一个共同目标前进，需要显露并解决有冲突的议程。
仅当人们达成共同目标并以个人和团队形式努力改进时才会实现精诚合作。
最后一项关乎承诺，是尤为重要的。 只有个体和团队做出承诺时，他们才会肩负起实现高价值的责任感（这是软件开发团队的基本前提）。 敏捷方法鼓励团队从具有优先顺序的工作列表中抽出工作，管理他们自己的工作，并专注于改进其工作实践，从而有利于作出承诺。 这种做法是实现自律工作的基础，是实现敏捷团队工作成果的动力。
为建立高绩效团队，敏捷方法中个体与交互重于过程和工具。 实际而言，所有敏捷方法都尝试通过频繁的检查和调整周期来加强沟通与协作。 但是，这些周期只在敏捷开发领导者鼓励积极冲突时才起作用，在敏捷团队中建立坚实的诚实、透明、信任、尊重和承诺基础需要积极冲突。
可用的软件重于完备的文档
可用的软件是敏捷开发带来的重要不同点之一。 敏捷宣言中提出的所有敏捷方法都强调以设定的间隔向客户提供小部分可用软件。
所有敏捷团队都必须明确他们所谓“可用软件”的定义，这一定义也往往被认为是工作的完成标准。 在较高级别，一项功能只有在通过所有测试并可由最终用户操作时才算完成。 在最低级别，团队必须超出单元测试水平并在系统水平进行测试。 在定义一项功能的完成标准时，最好的团队还会纳入集成测试、性能测试和客户验收测试。
一家 CMMI 5 级公司通过许多项目中的大量数据证明：如果与功能一起定义验收测试、按优先级别顺序实现功能、对每项功能立即运行验收测试并修复确定为最高优先级的 Bug，将系统地加倍生产速度并减少 40% 的缺陷。 这个结论来自一家已在全球实现最低缺陷率的公司。
《敏捷宣言》建议团队按设定的间隔交付可用的软件。 就完成标准达成一致是敏捷团队所要采取的一个切实途径，借此可以实现达成此目标所需的高性能和高质量。
客户协作重于合同谈判
在过去二十年中，项目成功率在全球范围都已翻番。 这归功于小型项目和高频率的交付，客户因此可以定期对可用软件提供反馈。 当宣言作者强调软件开发过程的客户参与对于成功的重要作用时，他们显然意识到了什么。
敏捷方法通过使客户支持人员与开发团队携手工作来培养这种价值。 例如，第一个 Scrum 团队有数千位客户。 由于不可能使所有客户都参与产品开发，他们选择了一个客户代理（称为产品所有者），该客户代理不仅代表所有一线客户，还代表管理、销售、支持、客户服务人员以及其他利益干系人。 随着团队发布可用的软件，产品所有者负责每四周更新一次需求列表，同时将现状以及来自客户和利益干系人的实际反馈纳入考虑。 这样，客户就可以帮助塑造正在创建的软件。
第一个 XP 团队是从内部 IT 项目开始的。 他们的团队中有一群最终用户每天与他们一同工作。 大约有 10% 的时间，顾问和内部团队可以找到一个可以与团队每日共同工作的最终用户。 在其余 90% 的时间，他们必须指派一个代理。 这个被 XP 团队称为客户的客户代理与最终用户一起工作，提供清晰的具有优先次序的功能列表供开发人员实现。
行业数据之所以显示敏捷项目的成功率是传统项目全球平均成功率的两倍以上，与客户（或客户代理）之间的日常协作便是一项关键原因。 敏捷方法认识到了这一点，因此在开发团队中专为客户代表留有一席之地。
响应变化重于遵循计划
响应变化对创建使客户满意并提供业务价值的产品至关重要。 行业数据显示，有超过 60% 的产品或项目需求会在软件开发过程中发生变化。 传统项目即使按时按预算完成计划的所有功能，客户往往也会不满意，因为他们所得到的与他们希望得到的不能完全相符。“ 汉弗莱定律”指出，客户在看到可用软件之前从不知道自己想要的是什么。 如果客户直到项目完成时才看到工作软件，再想融入他们的反馈意见为时已晚。 敏捷方法在整个项目期间都在寻求客户反馈，因此可以在产品开发过程中融入反馈和新信息。
所有敏捷方法都有内置的流程，用以根据客户或客户代理的反馈定期更改计划。 这些计划的设计始终以提供最高业务价值为第一目标。 因为有 80% 的价值都存在于 20% 的功能之中，运行良好的项目往往很早完成（而大多数传统项目则完成较晚）。 结果是客户更满意，开发人员也更有成就感。 敏捷方法基于这样一种认知：要想取得成功，必须做出改变。 他们因此创建了如检查和回顾这样的工作流程，特别设计用于根据客户反馈和业务价值定期转换工作重点。
“敏捷”是一个涵盖性术语 - 方法是实现
敏捷开发本身并不是一种方法。 它是一个描述几种敏捷方法的涵盖性术语。 在 2001 年签署《敏捷宣言》时，这些方法包括 Scrum、XP、Crystal、FDD 和 DSDM。 从那时起，精益实践也已作为一种有价值的敏捷方法显露头角，因此本主题稍后的演示中也将其纳入敏捷开发范畴。
每种敏捷方法实现《敏捷宣言》核心价值的途径略有不同，就如许多计算机语言以不同的方式展现面向对象编程的核心功能一样。 最近的一项调查显示，大约 50% 的敏捷开发从业者表示他们的团队采用的是 Scrum。 另外 20% 表示他们采用 Scrum 与 XP 组件。 另外 12% 表示他们只采用 XP。 全球有 80% 以上的敏捷实现采用 Scrum 或 XP，因此 MSF for Agile Software Development 5.0 版专注于 Scrum 和 XP 的核心过程和做法。
.png "Agile Umbrella")
Scrum 是敏捷开发过程的框架。 它不包括具体的工程实践。 相反，XP 专注于工程实践，但不包括开发过程的总体框架。 这并不表示 Scrum 不建议采用特定的工程实践，也不表示 XP 没有相应的过程。 例如，第一个 Scrum 实现了现在称为 XP 的所有工程实践。 但是，软件开发的 Scrum 框架设计为使团队在两到三天内启动，而工程实践往往需要数月时间才能实现。 因此，有关何时（以及是否）实现特定实践的问题留给了每个团队。 根据 Scrum 的共同创始人 Jeff Sutherland 和 Ken Schwaber 的建议，Scrum 团队应立即启动并创建实践列表和过程改进计划。 工程实践被认为是障碍，团队应将 XP 实践作为改进方法。 最佳团队运行以 XP 实践为补充的 Scrum。 Scrum 帮助 XP 缩放，而 XP 帮助 Scrum 很好地工作。
下表显示了 Scrum 和 XP 中的关键术语的对应关系。
Scrum |
XP |
|---|---|
产品所有者 |
Customer — 客户 |
Scrum 主管 |
XP 教练 |
团队 |
团队 |
冲刺 (sprint) |
iteration — 迭代 |
冲刺 (sprint) 计划会议 |
计划会议 |