敏捷原则和价值 - Jeff Sutherland 著

“敏捷开发”一词源自《敏捷宣言》，《敏捷宣言》是由一个小组在 2001 年编写的，该小组的成员包括 Scrum、极限编程 (XP)、动态系统开发方法 (DSDM) 和 Crystal 的创始人，以及功能驱动开发的代表人物和软件行业的其他几位思想领袖。 《敏捷宣言》为当时分散的敏捷方法树立了一套具有支配性的通用价值观和原则。 当宣言作者详细启用高绩效团队的四个核心价值。

• 个体与交互

• 交付可用软件

• 客户协作

• 响应变化

这些核心价值以 12 条原则为支撑，在下面的网站上可以找到这些内容：Manifesto for Agile Software Development（敏捷软件开发宣言）。

这些价值并不是《敏捷宣言》创始人简单说说而已。 它们是切实存在的价值。 每种敏捷方法实现这些价值的方式略有不同，但都有孕育其中一项或多项价值的特定过程和做法。

个体与交互

个体与交互对高绩效团队至关重要。 对一个项目进行的“沟通饱和度”研究显示：当不存在任何沟通问题时，团队效率可以达到业界平均水平的 50 倍。 为便于沟通，敏捷方法依赖于频繁的检查和调整周期。 这些周期以各种不同的频率发生：如每几分钟的结对编程，每几小时的持续集成，每日的例行站立会议，每个迭代的审查和回顾。

但是，简单地提高反馈和交流频率不足以消除交流问题。 仅当团队成员的行为具备几种关键特质时，这些检查和调整周期才会起到良好的作用：

• 尊重每个人的价值

• 每次都诚实交流

• 所有数据、行为和决定都保持透明

• 相信每个人都是团队的支撑力量

• 积极投身于团队和团队目标

要培养这些行为特质，敏捷开发管理层必须提供支持性环境，团队教练必须促进这些行为的产生，团队成员必须表现出这些特质。 只有这样团队才能发挥其全部潜力。

为了使团队实现这些行为特质比看起来要困难。 受文化标准或以往因诚实沟通导致冲突的负面经历的影响，很多团队都难以实现诚实、透明和相互信任的沟通。 要防止这些倾向的产生，领导者和团队成员必须促进有积极意义的冲突。 当团队参与正冲突时，它们不仅提升更多的生产力的行为，而且工作实现其他几个好处：

• 这样做可以实现过程改进：团队可以列出组织中的障碍或问题列表，正视这些障碍和问题，然后分主次系统地消除它们。

• 创新只有思想的自由冲撞，由广隆竹内和 Ikujiro Nonaka 研究并记录的现象，scrum 的教父。

• 当团队在共同目标边对齐和图面它们的问题和潜在冲突，冲突的时间表的分辨率发生。

• 仅当人们达成共同目标并以个人和团队形式努力改进时才会实现精诚合作。

最后一项关乎承诺，是尤为重要的。 只有个体和团队做出承诺时，他们才会肩负起实现高价值的责任感（这是软件开发团队的基本前提）。 敏捷方法实现承诺，并由拉从一个优先顺序的工作项的抽出团队成员的实现自律列表，管理其工作并专注于改进其工作实践。 这些做法窗体实现自律的基础，是实现的动力在一个敏捷团队。

为建立高绩效团队，敏捷方法中个体与交互重于过程和工具。 实际而言，所有敏捷方法都尝试通过频繁的检查和调整周期来加强沟通与协作。 但是，这些周期只在敏捷开发领导者鼓励积极冲突时才起作用，在敏捷团队中建立坚实的诚实、透明、信任、尊重和承诺基础需要积极冲突。

可用的软件重于完备的文档

可用的软件是敏捷开发带来的重要不同点之一。 敏捷宣言中提出的所有敏捷方法都强调以设定的间隔向客户提供小部分可用软件。

所有敏捷团队都必须明确他们所谓“可用软件”的定义，这一定义也往往被认为是工作的完成标准。 在较高级别，一项功能只有在通过所有测试并可由最终用户操作时才算完成。 在最低级别，团队必须超出单元测试水平并在系统水平进行测试。 在定义一项功能的完成标准时，最好的团队还会纳入集成测试、性能测试和客户验收测试。

一次 CMMI 5 级公司，这已经有一种最低的 bug 比率在世界上，通过有关许多项目的大量数据显示了敏捷做法的优点。 具体地说，它们系统为生成的二进制文件可以速度并由 40 % 降低 bug 通过执行下列操作：。 这将从公司。

• 当定义功能时，请定义验收测试。

• 实现功能按顺序并按优先级顺序。

• 这些实现，对每个功能的验收测试。

• 修复尽快标识为最高优先级 bug。

《敏捷宣言》建议团队按设定的间隔交付可用的软件。 通过固定就象团队在成功意味着什么是敏捷团队实现高性能和高质量需要的实现此目标的一个切实途径。

客户协作重于合同谈判

在过去二十年中，项目成功率在全球范围都已翻番。 由于较小的项目和更频繁的交付，这些改进发生的事件，在可用软件允许客户时间提供反馈。 当宣言作者强调软件开发过程的客户参与对于成功的重要作用时，他们显然意识到了什么。

敏捷方法通过使客户支持人员与开发团队携手工作来培养这种价值。 例如，第一个 Scrum 团队有数千位客户。 由于不都参与产品开发，他们选择了一个客户代理，调用产品所有者。 产品所有者表示该字段的所有客户，不仅，还需要管理，销售保存，支持，客户端服务和其他利益干系人。 随着团队发布可用的软件，产品所有者负责每四周更新一次需求列表，同时将现状以及来自客户和利益干系人的实际反馈纳入考虑。 客户有效地帮助的形状正在创建的软件。

第一个 XP 团队是从内部 IT 项目开始的。 XP 团队可以有自己的团队的公司最终用户及其使用日报。 大约 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 的核心过程和做法。

Scrum 是敏捷开发过程的框架。 它不包括具体的工程实践。 相反，XP 专注于工程实践，但不包括开发过程的总体框架。 这并不表示 Scrum 不建议采用特定的工程实践，也不表示 XP 没有相应的过程。 例如，第一个 Scrum 实现了现在称为 XP 的所有工程实践。 但是，软件开发的 Scrum 框架设计为使团队在两到三天内启动，而工程实践往往需要数月时间才能实现。 因此，有关何时（以及是否）实现特定实践的问题留给了每个团队。 根据 Scrum 的共同创始人 Jeff Sutherland 和 Ken Schwaber 的建议，Scrum 团队应立即启动并创建实践列表和过程改进计划。 工程实践被认为是障碍，团队应将 XP 实践作为改进方法。 最佳团队运行以 XP 实践为补充的 Scrum。 Scrum 帮助 XP 缩放，而 XP 帮助 Scrum 很好地工作。

下表显示了 Scrum 和 XP 中的关键术语的对应关系。

请参见

概念

使用 Visual Studio ALM 和 TFS 跟踪工作

其他资源

适用于 Visual Studio ALM 的 MSF for Agile Software Development