下载掌阅APP，畅读海量书库
立即打开
正如我们在第3章中所看到的，要使团队从敏捷中获益，组织必须认可敏捷的哲学。相对容易的是花钱，更难的是对组织的结构、系统和行为做出真正的、有意义的改变。
这听起来像是一项很艰巨的工作……嗯，因为它确实是。这些投资真的如此重要吗？
是的，它们真的很重要。
大多数阻碍团队发展的并不是他们使用的流程，而是所受到的约束。
对敏捷进行投资很重要，因为你在投资于改变约束条件。大多数阻碍团队发展的并不是团队使用的流程，而是他们所受到的约束。如果进行投资而忽略了实践，团队仍然有可能改进，但如果执行实践而忽视投资，那么团队会陷入困境。
正如Martin Fowler所说 [1] ：
我看到DHH（David Heinemeier Hansson，Ruby on Rails的创造者）和Kent Beck（极限编程的创造者）有惊人的相似之处，对他们中的任何一位来说，如果你向他们展示一个受限的世界，他们就会看到那些我们认为理所当然但实际上并不必要的约束，进而创造一个没有约束的世界……他们只是抛开了一些思维陷阱，然后继续前进。这就是为什么他们能创造出像极限编程和Rails这样的东西，它们确实给行业带来了冲击。
——Martin Fowler
进行投资，这是敏捷成功的秘诀。
下面的章节描述了团队需要从组织中获得的投资。你可能无法得到所有投资，所以我提供了替代方案。但这些替代方案的代价是效率降低，所以要努力地尽可能多地获得这些投资。我只列出了一些重要的投资。
所有的敏捷团队：
· 如第5章所述，获得管理人员、团队成员和关键利益相关者的认同。
· 建立长期的、跨职能的团队，并将人员单独分配到团队中（参见4.2节）。
· 确保每个团队都有一个教练，教练可以帮助团队成员学习，使其凝聚成一个高效、团结的团队（参见4.3节）。
· 将工作分配给团队，而不是个人，让团队能够选择自己的方法来进行日常计划和任务分配（参见4.4节）。
· 让团队级别的管理人员专注于管理工作系统，而不是个人和任务（参见4.5节）。
· 为每个团队创建一个实体的或虚拟的团队房间（参见4.6节）。
· 对于每个团队的第一项工作，选择一个有价值但不紧急的目标，以利于学习敏捷（参见4.7节）。
· 用敏捷的管理政策取代瀑布式管理政策（参见4.8节）。
· 移除、修改或绕过阻碍团队工作的人力资源政策（参见4.9节）。
专注区团队：
· 考虑每个团队在1～4个月内的业绩下滑情况（参见4.1节）。
· 把具有用户技能和客户技能的人加入每个团队（参见4.3节）。
· 确保每个团队中都有或能够定期接触到决定其工作内容的人（参见4.3）。
· 确保每个团队都有一名教练，能够教授专注区实践（参见4.3节）。
· 确保每个团队都能接触到利益相关者或其代表（参见4.4节）。
交付区团队：
· 考虑每个团队在2～6个月内的业绩下滑情况（参见4.1节）。
· 将所有需要的开发技能，如测试和运维，整合到每个团队中（参见4.3节）。
· 确保每个团队都有一名教练，他可以教授交付实践（参见4.3节）。
· 确保每个团队都能控制其开发、构建、测试和发布过程（参见4.4节）。
· 对于每个团队的第一次工作，除非团队教练认为没有必要，否则应该选择一个涉及新建代码库的目标（参见4.7节）。
· 解决阻碍合作开发的安全问题（参见4.10节）。
优化区团队：
· 考虑每个团队在1～3个月内的业绩下滑情况（参见4.1节）。
· 确保每个团队都有具备业务知识、市场知识和专业知识的人员（参见4.3节）。
· 确保每个团队中都有一名教练，可以教授优化实践（参见4.3节）。
· 让每个团队对其预算、计划和结果负责（参见4.4节）。
[1] 摘自Fowler的文章 EnterpriseRails 。