定义敏捷12条原则

在敏捷宣言发布之后的数月，创建者继续保持沟通。为了支持团队向敏捷过渡，他们为宣言的4个价值观增添了12条指导性原则。

记住比较好

这些原则，加上白金原则（稍后将在“附加白金原则”一节中进行解释），能够作为石蕊测试，用于判断一个团队的具体实践是否真正符合向敏捷过渡的意图。

以下是原始的12条原则的文本，由敏捷联盟在2001年发布。

第1条 我们最优先考虑的是通过尽早和持续不断地交付有价值的软件来使客户满意。

第2条 即使在开发后期也欢迎需求变更。敏捷流程利用变更为客户创造竞争优势。

第3条 采用较短的项目周期（从几周到几个月），不断地交付可工作的软件。

第4条 业务人员和开发人员必须在整个项目期间每天一起工作。

第5条 围绕富有进取心的个体而创建项目。为他们提供所需的环境和支持，信任他们所开展的工作。

第6条 不论团队内外，传递信息效果最好且效率最高的方式是面对面交谈。

第7条 可工作的软件是测量进展的首要指标。

第8条 敏捷流程倡导可持续开发。发起人、开发人员和用户要能够长期维持稳定的开发步伐。

第9条 坚持不懈地追求技术卓越和良好设计，从而增强敏捷能力。

第10条 以简洁为本，最大限度地减少工作量。

第11条 最好的架构、需求和设计出自自组织团队。

第12条 团队定期反思如何能提高成效，并相应地调整自身的行为。

这些敏捷原则为开发团队提供了实践指南。

对这12条原则的另外一种组织方式是以下4个不同的组合。

>>客户满意；

>>质量；

>>团队工作；

>>产品开发。

下面将根据这些组合来讨论这些原则。

客户满意的敏捷原则

敏捷方法聚焦于让客户满意，这合乎情理。毕竟客户才是开发产品的首要原因。

尽管敏捷12条原则都支持使客户满意的目标，但前4条原则尤为突出。

第1条 我们最优先考虑的是通过尽早和持续不断地交付有价值的软件来使客户满意。

第2条 即使在开发后期也欢迎需求变更。敏捷流程利用变更为客户创造竞争优势。

第3条 采用较短的项目周期（从几周到几个月），不断地交付可工作的软件。

第4条 业务人员和开发人员必须在整个项目期间每天一起工作。

你可以采用多种方式来定义一个产品的客户。

>>客户是为产品出资的个人或群体。

>>在有些组织中，客户可以是组织以外的顾客。

>>在其他组织中，客户可以是组织内部的一个或一组干系人。

>>最终使用产品的人也是客户。但为了便于区分并且和原始的敏捷12条原则保持一致，故在本书中称这些人为用户。

如何贯彻并落实这些原则？你可以参考下列方法。

>> Scrum团队（Scrum是第5章中详细描述的一种常用的敏捷框架）设置产品负责人（Product Owner），由其负责把客户心中想要的翻译成产品需求。要想了解更多关于产品负责人的角色，请参阅第7章。

>>产品负责人根据业务价值或风险对产品特性进行优先级排序，并与开发团队进行沟通。开发团队在较短的开发周期（称为“迭代”或“冲刺”）中交付列表中最有价值的特性。

>>产品负责人每天保持深度参与，以便澄清优先级和需求、做出决策、提供反馈以及快速解答产品开发过程中突然出现的许多问题。

>>频繁地交付可工作的产品特性，让产品负责人和客户对于产品开发状态有全面的了解。

>>随着开发团队每1~8周或更短时间持续交付完成的、可工作的和潜在可交付的功能，整个产品的价值随着它的可用功能的增加而逐步提升。

>>客户的投资价值是通过在产品开发过程中定期收到新的、可使用的产品功能而不断累积的，并非通过等到最后一刻才第一次甚至是仅有的一次交付可发布的产品特性来体现。

在表2-3里，我们列出了一些在产品开发期间通常面临的客户满意度问题。你可以使用表2-3收集你遇到的一些客户不满意的例子。你认为使用敏捷方法后会有所不同吗？为什么会或者为什么不会？

表2-3 当客户不满意时，敏捷如何能加以帮助

小贴士大用途

让客户满意的敏捷策略如下：

>>在每次迭代中，首先产出最高优先级特性；

>>理想情况下，把产品负责人和其他团队成员集中在一起办公，以消除沟通障碍；

>>把需求分解成可以在短期迭代中交付的小价值模块；

>>书面需求越简单越好，推进更加积极有效的面对面沟通；

>>当每项功能完成时，让产品负责人进行验收；

>>定期重新回顾/检查特性列表，以确保最有价值的需求始终具有最高优先级。

质量的敏捷原则

产品开发团队每天都在承诺他们创造的每个产品增量的生产质量——从文档开发、集成到测试结果。每位团队成员都贡献了他/她最好的工作成果。尽管敏捷12条原则都支持质量交付目标，但以下原则尤为突出。

第1条 我们最优先考虑的是通过尽早和持续不断地交付有价值的软件来使客户满意。

第3条 采用较短的项目周期（从几周到几个月），不断地交付可工作的软件。

第4条 业务人员和开发人员必须在整个项目期间每天一起工作。

第6条 不论团队内外，传递信息效果最好且效率最高的方式是面对面交谈。

第7条 可工作的软件是测量进展的首要指标。

第8条 敏捷流程倡导可持续开发。发起人、开发人员和用户要能够长期维持稳定的开发步伐。

第9条 坚持不懈地追求技术卓越和良好设计，从而增强敏捷能力。

第12条 团队定期反思如何能提高成效，并相应地调整自身的行为。

这些原则在日常实践中可以描述如下。

>>开发团队成员在技术质量的构建上必须具有完全的主导权并被授予解决问题的权力。他们承担着决定如何创建产品、完成创建产品所需的技术工作以及组织产品开发的责任。没有参与这项工作的人员不能指导团队成员如何去开展这些工作。

>>敏捷软件开发需要敏捷架构，以使产品编码和测试模块化，并具有灵活性和可扩展性。产品设计需要用来解决当前的问题，并且尽可能简单地处理不可避免的变更。

>>一套纸面上的设计永远不会告诉你哪些是可以工作的，因为纸面上的任何事都是可行的。当产品质量达到在短期内能被演示并最终交付时，每个人将知道产品在冲刺结束时是可以工作的。

>>当开发团队完成特性时，团队向产品负责人展示产品功能，以确认产品是否符合验收标准。产品负责人的评审贯穿整个迭代，理想的评审时间是需求开发完成之日。即使在特性开发期间，产品负责人的反馈有时也是必要的。

>>在每个迭代（对于大多数团队来说，持续2周或者更短的时间）结束时，把可工作的功能向客户演示。这样，进度显而易见且易被测量。

>>测试是开发中不可或缺且持续进行的一部分，它每天都在进行，而非等到迭代周期结束才做。尽可能地进行自动化测试。要了解更多关于自动化测试的内容，请参阅第17章。

>>在软件开发中，以微小增量的方式来检查代码是否经过测试、能否与以前的版本集成，这种增量可能一天发生几次（在一些诸如谷歌、亚马逊和脸书这样的组织中，这种增量甚至一天会发生成千上万次）。这个流程被称为持续集成（Continuous Integration，CI），它有助于确保当新代码加进原有代码库时，整个解决方案能够持续工作。

>>在软件开发中，保持技术领先的方法包括建立代码编写标准、使用面向服务的架构、采用自动化测试以及针对将来的变更进行构建。

记住比较好

敏捷原则不仅仅适用于软件产品。无论你是在策划一场营销活动、出版书籍，还是在进行生产或研发工作，保持技术领先都是至关重要的。所有领域都有一套团队可以一直用来构建质量的技术实践。

小贴士大用途

敏捷方法提供了以下针对质量管理的策略：

>>在产品开发之初定义“完成”意味着什么（也就是可交付），然后使用该定义作为高质量产品的标杆；

>>通过自动化方式每天进行积极的测试；

>>根据需要，仅构建那些必需的功能；

>>评审软件代码并进行精简（重构）；

>>向干系人和客户只展示已经被产品负责人验收过的功能；

>>在每天、每个迭代以及整个产品生命周期中设置多个反馈时点。

团队工作的敏捷原则

团队工作对于敏捷产品开发至关重要。创建良好的产品需要所有团队成员（包括客户和干系人）的通力合作。敏捷方法支持团队构建和团队工作，并强调在自管理式的开发团队中建立信任。一个永久的、熟练的、富有进取心的、统一的和被赋能的团队才是成功的团队。要了解更多关于永久性团队的内容，请参阅第8章。

尽管这12条原则都支持团队工作的目标，但以下原则在支持团队赋能、高效和卓越方面尤为突出。

第4条 业务人员和开发人员必须在整个项目期间每天一起工作。

第5条 围绕富有进取心的个体而创建项目。为他们提供所需的环境和支持，信任他们所开展的工作。

第6条 不论团队内外，传递信息效果最好且效率最高的方式是面对面交谈。

第8条 敏捷流程倡导可持续开发。发起人、开发人员和用户要能够长期维持稳定的开发步伐。

第11条 最好的架构、需求和设计出自自组织团队。

第12条 团队定期反思如何能提高成效，并相应地调整自身的行为。

小贴士大用途

敏捷方法专注于可持续开发。作为知识型员工，我们的大脑就是我们带给产品开发的价值。仅从团队利益出发，组织需要的是那些始终充满活力且头脑清醒的员工。保持一个有规律的工作节奏，而不是经常超负荷地紧张工作，有助于团队成员保持思路敏锐并交付高质量的产品。这一事实早在1908年就为人们所知，当时恩斯特·阿贝（Ernst Abbe）将每天的工作时长从12小时减少到8小时，并对增加的累积产出进行了量化。《疲劳和不安的经济学》（The Economics of Fatigue and Unrest）的作者萨金特·弗洛伦斯（P.Sargant Florence）也指出了，8小时工作制的产出比9小时工作制高出16%~20%。以下是一些可以用于实现团队工作愿景的实践：

>>确保开发团队成员有合适的技能和上进心；

>>为任务的完成提供足够的培训；

>>支持自组织团队决定做什么和怎么做，不需要让管理者来告诉团队做什么；

>>让团队成员作为一个整体而非个体来承担责任；

>>面对面沟通，快速、有效地传递信息。

不开玩笑！危险！

设想你通常使用电子邮件与莎伦沟通。你先花时间构思你的信息并发送。该信息停留在莎伦的收件箱中，直到最终她来阅读。如果莎伦有任何问题，她会写一封回复邮件并发送。她发送的信息到达你的收件箱，直到你最终打开。如此这般反复，这种打乒乓球式的沟通效率太低且不适合在快速迭代中使用。一个5分钟的讨论就可以迅速地解决问题并且减少误解产生的风险，从而降低延误的成本。

>>通过全天自发地进行交谈来学习知识、增强理解和提高效率。

>>团队成员集中办公、位置靠得近可以提高沟通效率。如果集中办公不可能，那么请优先使用视频而不是电子邮件。依赖书面沟通进行协作的团队工作效率较低，并且更容易在沟通上出错。团队内部的书面沟通实则是一种累赘。

>>确保经验教训总结是持续的反馈循环而不是仅仅发生在项目结束时。当每个迭代结束时，应该进行回顾，及时地反省和调整，这么做能够提升开发团队的生产力，创造出更高的效率。在开发结束时举行的经验教训总结会价值最小，因为在下一个产品创建中，参与的团队和要开展的实践可能都会不同。要了解更多关于回顾会议的内容，请参阅第12章。

>>第一次回顾会议和后面的任何回顾会议一样有价值（甚至更有价值，）因为一开始团队有机会做出变更，从而使产品开发的后续工作受益。

小贴士大用途

以下策略促进了团队有效地工作。

>>开发团队集中办公，为有效的、实时的沟通扫清物理障碍。

>>创建一个有利于协作的物理环境：一个有白板、彩色笔和其他有助于开发和传递想法的触觉工具的团队房间，可以确保团队成员达成共识。

>>创建一个鼓励团队成员说出他们的想法的环境。

>>尽可能面对面沟通，如果通过交谈能处理问题，就不要发电子邮件。

>>如果有需要，当天就澄清所有的疑问。

>>鼓励开发团队自己解决问题，而不是让经理为开发团队解决问题。

>>抵制对团队成员进行洗牌的诱惑，努力使团队成长为一个稳定、永久、高绩效、能力不断提升的团队。

记住比较好

一个长远的产品观离不开长期的、永久性团队。一支高绩效的团队需要数年时间才能建立起来。从逻辑上来讲，他们对客户的了解、从每次产品发布中获得的反馈、对产品提供的支持以及产品开发环境无不鼓励团队要尽可能保持稳定。部分团队成员可能在团队之外寻求新的职业发展机会，但是在大多数情况下，团队应尽可能保持稳定，以实现价值的最大化。随着每个新特性的交付，团队趋向稳定，从而能够为客户的产品使用提供支持，并在这个过程中不断学习。

产品开发的敏捷原则

产品管理中的敏捷性围绕以下3个关键领域：

>>确保开发团队富有成效并能在长时间内以可持续的方式提高生产力；

>>不需要通过询问来中断开发活动流程，即可确保干系人能够随时看到产品进展的信息；

>>一旦出现新的特性请求就进行处理，并把它们纳入产品开发周期。

敏捷方法聚焦于规划和执行工作，以生产出能够发布的最好的产品。该方法支持开放的沟通，能够避免分散精力和浪费性的活动，确保每个人都清楚产品开发的进展。

尽管这12条敏捷原则都支持产品管理，但以下原则尤为突出。

第1条 我们最优先考虑的是通过尽早和持续不断地交付有价值的软件来使客户满意。

第2条 即使在开发后期也欢迎需求变更。敏捷流程利用变更为客户创造竞争优势。

第3条 采用较短的项目周期（从几周到几个月），不断地交付可工作的软件。

第7条 可工作的软件是测量进展的首要指标。

第8条 敏捷流程倡导可持续开发。发起人、开发人员和用户要能够长期维持稳定的开发步伐。

第9条 坚持不懈地追求技术卓越和良好设计，从而增强敏捷能力。

第10条 以简洁为本，最大限度地减少工作量。

以下是采用敏捷产品管理方法的一些优势。

>>敏捷产品开发团队可以更快地实现产品上市，并相应地节约成本。相比传统方法，敏捷方法最大限度地减少了在瀑布型项目早期通常要做的详尽的预先规划和文档，所以能更早地启动开发工作。

>>产品开发团队是自组织和自管理的。通常用于指导开发人员如何开展工作的管理工作可以被用来消除那些减慢开发团队进度的障碍和干扰。

>>敏捷开发团队决定在每次迭代中所需完成的工作量，并承诺实现这些目标。主人翁意识是敏捷方法有别于其他方法的根本，因为是开发团队自己做出了承诺，而不是遵守外部的承诺。

>>使用敏捷方法的人会问：“在仍然可以增加价值的情况下，我们可以设定的最低目标是什么？”而不是专注于把所有可能需要的特性和额外的改进都包括进去。敏捷方法通常意味着精简，即编制刚好够的文档、去掉不必要的会议、避免低效的沟通（例如电子邮件），并最大限度地降低底层代码的复杂性（刚好够让它工作就行）。

不开玩笑！危险！

编写对产品开发没有帮助的复杂文档纯属浪费精力。记录一项决策的文档是必要的，但是你不需要用很多页去记录形成决策的历史和细微差别。保持文档“刚好够”，你将有更多的时间去专注于支持开发团队。

>>如果将开发工作按照几周或持续时间更短的冲刺周期拆分，你就能在坚持当前迭代目标的同时适应接下来的迭代变更。在整个开发过程中，每个冲刺的时间要保持一致，从而让团队长期处于一个可预测的开发节奏中。

>>规划、需求提炼、开发、测试和功能演示都在一个迭代中发生，这样可以降低长时间走错方向或开发出客户不想要的东西的风险。

>>敏捷实践鼓励富有成效的、健康的、稳定的开发节奏。例如，在流行的极限编程（XP）敏捷软件开发方法中，每周最多工作40小时，首选35小时。敏捷产品开发，尤其从长期来看，具有稳定性和可持续性，并更加富有成效。

不开玩笑！危险！

传统方法通常会进行“死亡行军”，即为了达成先前未确定和不现实的截止日期，在开发结束前数天甚至数周加班加点。在“死亡行军”过程中，生产率急剧下降，并且将有更多的缺陷产生，因为缺陷需要在不中断其他功能模块的前提下进行纠正，所以缺陷纠正堪称是成本最高的可以被执行的工作。缺陷通常是由系统超负荷运作——特别是不可持续的工作节奏导致的。

>>敏捷方法使优先级、现有产品的开发经验以及最终每次冲刺中的开发速度清晰可见，这有助于团队很好地判断在给定时间内能够完成或应该完成多少工作量。

如果你以前曾在传统项目中工作过，或许你对项目管理活动有基本的理解。在表2-4中，我们列出了一些项目管理的任务，以及你如何用敏捷方法满足那些需求。请使用表2-4来观照你之前的经验，并且思考敏捷方法较之传统项目管理有何不同。

表2-4 传统项目管理和敏捷产品管理的对比

小贴士大用途

成功的产品开发是由以下敏捷方法促进的：

>>为开发团队提供实时的问题解答，使其免受竞争的优先事项的影响，赋能团队制定解决方案并决定每次迭代中要完成的工作量；

>>制作“刚好够”的文档；

>>精简状态报告，使开发团队能够短时间把信息推送出去，而不是让项目经理花费大量的时间来提取有用的信息；

>>最小化非开发任务；

>>树立信心，认为变更是正常且有益的，而不是让人惧怕和躲闪的东西；

>>采用准时制（JIT）的需求细化方式，以最大限度地减少变更干扰或工作浪费；

>>与开发团队合作，建立现实的进度计划与目标；

>>保护团队远离组织安排的、与产品目标无关的工作，这些工作可能影响产品目标的完成；

>>理解工作与生活的适当平衡是高效开发的组成部分；

>>将产品视为长期投资，需要永久性团队追求价值高于遵循规范。