在本文，介绍以下内容：

1. 学习敏捷方法能给组织、Scrum团队和产品带来的十大收益；

2. 敏捷开发成功的十大关键因素。

一、敏捷产品开发的十大收益

1. 更高的客户满意度

Scrum 团队致力于创造满足客户的产品。以下敏捷方法能够使客户更为满意。

• 在整个开发过程中与客户合作收集反馈，使客户得到他们真正想要的产品。》确保产品负责人是产品需求和客户需求方面的专家，或者知道从哪里获得这些信息。

• 保持对产品待办事项列表的更新并调整需求优先级，以便快速响应变化。

• 在每一次冲刺评审时向干系人演示可工作的功能。

• 通过每一次发布，产品更快，更繁地交付到市场。

2. 更好的产品质量

客户要求高质量的产品。敏捷方法有很好的保障措施来确保尽可能高的产品质量。Scrum 团队通过下面的行动来确保质量。

• 采取积极的质量保证方法预防产品质量问题。》拥抱技术卓越、良好的设计和可持续发展。

• 即时定义和详细阐述需求，以便对产品特性的认知更清晰。

• 将验收标准构建到用户故事中，以便开发团队能更好地理解它们，以及产品负责人能更准确地进行验证。

• 把持续集成和深度测试融合到开发过程中，使开发团队能够将问题解决于萌芽阶段。

• 利用自动化测试工具，确保新的产品增量不会破坏以前的功能。》进行冲刺回顾，使 Scrum 团队能够不断改进流程与工作。

• 根据完工定义来完成工作:已开发、已测试、已集成和已归档。

3. 降低风险

事实上，敏捷产品开发技术几乎消除了产品绝对失败的可能--即花费了大量的时间和金钱而没有获得投资回报。Scrum 团队通过以下方式降低风险。

• 利用冲刺的形式进行开发，从最初的投资到快速失败或者知道一个产品或方法是否可行只需要很短的时间。确保在产品待办事项列表中优先包含最有价值和风险最高的事项，并尽早处理风险。有关评估产品风险和机会的信息。

• 从第一个冲刺开始，始终要有一个已集成的、可工作的产品，每次冲刺都会增加一些可交付的功能，这样能够确保产品不会完全失败。

• 在每次冲刺中根据完工定义实现需求，这样不管未来产品发生什么变化，发起人始终能得到完整的、可使用的功能。

• 通过以下方式不断地提供产品和流程的反馈信息: 召开每日例会，和开发团队进行持续的沟通; 产品负责人在每日工作中澄清需求、评审和验收特性; 召开冲刺评审会议，获得干系人和客户对已完成的功能的反馈; 召开冲刺回顾会议，开发团队可在会议上讨论流程改进; 定期发布，使最终用户看到新特性并做出反馈。

• 自筹资产品产生的早期回报，使组织为产品支付的前期费用更少。

4. 提升协作和责任感

• 一旦开发团队承担了产品的责任，他们就可以创造伟大的成果。敏捷开发团队通过以下方式协作并对产品的质量和性能负责。

• 确保开发团队、产品负责人和 Scrum 主管每天紧密合作。

• 召开目标驱动的冲刺计划会议，使开发团队对冲刺目标做出承诺并围绕冲刺目标组织自己的工作。

• 召开由开发团队主导的每日例会，开发团队成员围绕已完成的工作、将要开展的工作、工作中的障碍和团队士气进行讨论。

• 召开冲刺评审会议，开发团队在该会议上可以演示并与干系人直接讨论产品。》召开冲刺回顾会议，让开发团队成员回顾过去的工作，并为每个冲刺推荐更好的敏捷实践。

• 集中办公，使开发团队成员之间能够即时沟通和协作。如果你处于一个分布式的团队中，请与团队的视频会议保持连接。》使用诸如估算扑克和举手表决技术，达成决策共识。

5. 更多有针对性的度量指标

敏捷开发团队用来估算时间和成本、测量绩效和进行决策的度量指标往往要比传统项目的度量指标国有针对性、更准确。敏捷度量指标应该以一种最运合团队的方式来鼓励可持续的团队进步和效率提升，使团队能够尽早并且经常地向客户交付价值。在敏捷产品开发中，你可以通过以下方法来确定度量指标。

• 基于每个开发团队的实际绩效和能力来确定项目时间线和预算。

• 确保由将要开展工作的开发团队而非其他任何人对需求进行工作量评估。

• 根据开发团队的知识和能力，使用相对估值面不是按小时数或天数来精确地进行工作量评估。

• 随着开发团队对产品了解得更多，定期细化并评估工作量、时间和成本。

• 每天更新冲刺燃尽图，以便准确提供开发团队在每个冲刺的绩效指标。

• 比较未来的开发成本与未来的开发价值，帮助团队确定何时结束开发并将资本部署到新的投资机会中。

6. 提高绩效的可见性

在敏捷开发中，每个团队成员员随时都能通道开发进展情况。团队可以通过以下方式提高绩效的可见性。

• 高度重视 Scrum 团队、干系人、客户，以及组织内其他任何想了解产品情况的人之间开放、坦诚的沟通。

• 通过每天更新冲刺待办事项列表来提供绩效测量结果。冲刺待办事项列表可供组织里的任何人查看。

• 通过召开每日例会，洞察开发团队当前的进展和面临的障碍。尽管只有 Scrum 团队可以在每日例会上发言，但产品团队的任何成员都可以参加会议，或观察或倾听。

• 通过使用任务板和在开发团队的工作区张贴冲刺燃尽图来展示每天的实际进度。

• 在冲刺评审会议中展示取得的成就。组织中任何人都可以参加冲刺评审会议。

7. 增加投资控制

Scrum团队有大量的机会控制投资绩效，并根据需要进行纠正，原因如下。

• 在开发中调整优先级，使得组织在适应变化的同时拥有固定的开发时间和固定价格的产品。

• 拥抱变化，使得团队能够对外部因素(如市场需求)做出响应。》每日例会使得 Scrum 团队可以在问题出现时快速解决。

• 每日更新冲刺待办事项列表意味着冲刺燃尽图准确地反映了冲刺绩效，让Scrum 团队有机会在问题发生之初就做出调整。》面对面交谈消除了沟通和解决问题的障碍。

• 冲刺评审让于系人看到了可工作的产品，并在发布前对产品提供反馈。

• 冲刺回顾使Scrum团队能够在每次冲刺结束时做出积极的调整，以增强产品质量、提高绩效、优化流程。

• 织自筹资产品开发的潜力。

在敏捷产品开发中存在大量的机会进行检查和调整，使所有产品团队成员--开发团队、产品负责人、Scrum主管和干系人--实施控制，最终创造出更好的产品。

8. 促进可预测性

敏捷产品开发技术帮助团队准确地预测整体工作会如何随着产品开发的进而发展。以下是一些提高可预测性的实践、工件和工具。

• 在整个开发中，所有冲刺都保持同样的时间跨度和人员分配，使开发团队知道每个冲刺的确切成本。

• 基于每个开发团队自己的开发速度，开发团队可以预测发布、剩余产品待办事项列表，或任何需求组合的时间线和预算。

• 通过使用来自每日例会、冲刺燃尽图和任务板的信息，团队能预测每个冲刺的绩效。

9.优化团队结构

自管理把通常由经理或组织行使的决策权交给 Scrum团队成员。3~9人组成的开发团队规模有限，因此，如有需要，一个敏捷产品开发可以设立多个 Scrum团队。自管理和规模限制意味着敏捷产品开发可以提供独特的机会来定制团队结构和工作环境。这里有几个例子。

• 开发团队可以按个人特定的工作风格和个性来构建团队结构。按工作风格构建的团队有这些好处: 允许团队成员按他们喜欢的方式工作; 鼓励团队成员提高技能，融入他们喜欢的团队; 帮助提高团队绩效，因为优秀的员工总喜欢在一起工作，并自然地相互吸引。

• Scrum 团队可以兼顾团队成员工作和生活的平衡来制定决策。

• 因为由开发团队来评估他们将要做的工作，所以产品负责人可以决定需要多少 Scrum 团队来完成产品待办事项列表中的事项。

• 总之，由 Scrum 团队自己制定规则，决定与谁一起工作以及如何工作。

团队定制化的想法使敏捷工作场所更加具有多样性。采取传统管理方式的组织倾向于拥有单一风格的团队，每个人都遵循相同的规则。而敏捷的工作环境更具有包容性。敏捷产品开发可以使各有所长的人融合成一个团队并创造出伟大的产品。

10. 更高的团队士气

与那些享受工作快乐的人士一起工作，能得到更多的满足和回报。敏捷产品开发通过下列方法来提高 Scrum 团队士气。

• 通过自管理提升 Scrum团队的创新力，并且在其做出贡献后能够得到认可。》聚焦于可持续的工作实践，让人不至于因为压力过大而倒下。

• 采用服务型领导方法帮助Scrum团队自管理，从而有效避免命令与控制的管理方式。

• 设立专职服务的 Scrum 主管，他/她要帮助开发团队消除障碍，并为其屏蔽外部干扰。

• 提供支持和信任的环境，从而从整体上提高Scrum团队的动力和士气。

• Scrum 团队可以从提高自主性、专精能力、目的性和归属感中受益。

• 面对面交谈有助于减少因误解产生的挫折。

• 跨部门工作让开发团队成员能够学到新的技能，并通过教授别人而取得进步。

二、敏捷成功的十大关键因素

以上是决定敏捷转型是否成功的十大关键因素。你不需要在开始敏捷之旅时就解决所有的问题。你只需要意识到它们，并制订一个计划，尽可能早地在过程中解决它们。 我们发观，前三项是成功的最强指标。把这些做好，成功的可能性就会大大增加。

1. 专心工作的团队成员

要想将产品视为长期资源，有3个因素需要稳定、专心甚至永久性的团队。永久性团队保留了有关产品和客户的知识。他们的高绩效是经过多年的回顾总结努力建立起来的。由于职业发展机会等原因，可能需要对团队进行一些小的调整，但在大多数情况下，组织应该尽可能少地改变团队的组成。 此外，这些专心工作的团队成员--产品负责人、开发团队、Scrum主管-一次只关注一个目标是至关重要的。如果团队成员每小时、每天、每周甚至每月都在不同的项目场景之间切换，他们的效率就会降低，因为同时负责多个任务会增加成本。由任务转换所造成的时间损失是可观的。

如果你没有足够的人力来组建一个专职的Serm团队，那么你肯定也没有足够的人力让他们同时参与多种不同优先级的工作。美国心理协会报告说，任务切换浪费了多达 40%的时间。

团队内部的不确定性会导致项目结果的不确定性。

2. 集中办公

敏捷宣言将个体和互动列为第一价值观。正确践行这个价值观的方法是安排团队成员集中办公，使他们能够在整个开发过程中进行清晰、有效和直接的沟通。

对于分散式团队，他们面临的挑战是时差或跨地域给面对面沟通带来了不便，而书面沟通又容易造成代价高昂的沟通延迟甚至误解。当需要快速协同解决问题时，这种挑战尤其突出。缺乏实时的、面对面的交流会导致人们对他人的想法、行为和工作方式的信任及熟悉程度降低。

而集中办公是搭建敏捷环境的第一要素。有统计数据表明，贝尔实验室的生产力提高了 50 倍，他们成功的一个重要因素就是集中办公。这种做法提升了与客户的协作水平、产品功能的可用性和快速响应能力。视频会议和其他数字协作工具使分散式团队的协作更加有效。尽管科技有助于弥补分布式工作带来的不足，但它仍然不及在同一物理地点并肩工作产生的价值。

3.完成意味着可交付

如果在冲刺结束时产出的功能不可交付使用，那么这不是正确的敏捷模式。完成意味着可交付，根据定义，不能产出潜在可交付功能的冲刺不是真的冲刺。

开发团队通过集中开发用户故事来完成任务--一次处理一个用户故事，直到完成后再开始下一个用户故事。开发人员在开始一个新的用户故事之前，要确保在当前的用户故事中,“完工定义”规定的所有条件(包括自动化测试)都已得到满足，团队共同对此负责。产品负责人根据 Scrum 团队的“完工定义”来审查已完成的工作，然后批准团队开始开发新的用户故事。

4. 解决通过 Scrum 暴露出的问题

Scrum不会为你解决任何问题，但它会暴露问题。Scrum 将暴露你在流程、政策、组织结构、技能、角色、工件、会议效率、透明度等方面的不足和差距。如何处理这些问题取决于你自己。Scrum 提供了迭代检查和调整的框架，用于在向题暴露出来的时候处理它们。如果这些问题在 Scrum团队的控制范围内，他们应该能自己解决这些问题。如果超出 Scrum团队的控制范围，组织应该有渠道将这些问题反馈至组织的相关负责人，这些人应该具备变革影响力，以支持 Scrum团队更好地交付客户价值。解决 Scrum 暴露的诸多问题的有效方法是使用敏捷转型团队。

5.清晰的产品愿景和路线图

尽管产品负责人决定产品愿景和路线图，但许多人会影响这些敏捷工件的清晰度。产品负责人需要在整个产品开发过程中接触干系人和客户，与之建立牢固的工作关系，以确保产品愿景和路线图持续反映客户和市场的真实需求。开发团队还必须清楚地了解其所从事的工作的目的--从产品愿景到单个的用户故事。以目标驱动的开发工作交付业务和客户价值，能够有效降低风险。

没有明确的目标，人们就会彷徨，缺乏主人翁精神。当所有的团队成员都明白目标时，他们就会走到一起。记住敏捷原则第 11条:“最好的架构、需求和设计出自自组织团队。”

6. 赋权产品负责人

产品负责人的角色是为了优化开发团队产生的价值。产品负责人需要了解产品和客户，每天都能与开发团队联系，有权做出优先级决策，能够及时地为开发团队给出明确意见，这样开发团队就可以减少等待时间，避免对产品开发的方向造成负面影响。 如果组织存在下列状况，那么在冲刺结束时就很难提供有价值的和可交付的功能。

• 产品负责人无法做出关键业务决策。

• 开发团队无法联系到产品负责人。产品负责人除了支持开发团队、与客户和干系人合作之外，还有太多其他的事情要做。

• 组织为一个产品指定了多名产品负责人，开发团队不清楚该找谁来澄清需求。

• 干系人推翻产品负责人的决策。

尽管 Scrum 团队中的所有角色都是至关重要且同等重要的，但一个没有赋权且效率低下的产品负责人通常会导致Scrum团队最终无法提供客户需要的价值。

7.掌握多种技能的开发人员

当你开始第一个敏捷产品开发工作时，可能并没有一支已经拥有完成产品待办事项列表中每个事项所需的理想技能水平的开发团队。你的目标应该是尽快让团队掌握各种必需的技能。如果任何一项技能(包括测试)水平存在不足，团队就将面临挑战，难以实现冲刺目标。

从第一天开始，你就需要团队成员保持好奇心和兴趣，去学习新事物、去尝试、去指导和接受指导，并协同团队其他成员工作，以便尽快完成任务。第7章详细讨论了团队技能的多样性。

8.Scrum 主管的影响力

当你决定从命令和控制的领导模式转向授权他人进行决策的领导模式时，服务型领导方法提供了工作思路。如果拥有正式授权，Scrum 主管将被视为一个管理者--他人需要向其汇报。实际上，这样并不利于开展工作。Scrum 主管不必拥有正式的权力，但是应该被领导层授予与Scrum 团队成员、干系人和其他第三方合作的权力，从而为开发团队的工作扫清障碍。

如果 Scrum 主管拥有组织影响力--一种非正式的、被群体认可的影响力，那么他/她就可能以最好的方式为团队服务，改善他们的工作环境。在第7章中，我们深人讨论了不同类型的影响力。需要为 Scrum 主管提供培训和辅导，以提升其服务型领导的相关技能，减少命令与控制的倾向。

9.领导层对学习的支持

当组织的领导者决定让组织变得更敏捷时，首先他们的思维方式必须改变。我们经常看到领导层指示敏捷转型后，没有任何后续行动来支持变革所需的学习过程。事实上，从领导层宣称支持敏捷开始，完成组织变革至少需要1~3年的时间。领导层的支持不仅仅意味着为培训或辅导服务买单，还意味着领导者自己也要参与进来，学习需要开展怎样的行动来领导变革，用他们的时间、努力和行动来体现真正的支持。

在第一次冲刺之后就期望能够得到敏捷带来的所有好处是不现实的。由于每个人都处在学习的过程中，我们允许试点产品出一些小差错。如果只是口头上支持学习，那么 Scrum团队很快就会觉察到这一点，进而失去尝试新事物的动力，并回到原点等待来自上级的具体工作指令。

10.转型支持

敏捷教练在领导层面和团队层面进行有效的指导可以增加成功的机会。指导的内容如下:

• 当团队违反敏捷原则或出现错误时，需要立即进行纠正;

• 强化培训;

• 针对问题，为特定角色进行一对一的辅导;

• 高管层的领导方式和心态的调整。