下载掌阅APP，畅读海量书库
立即打开
变化是破坏性的，新的想法需要花时间来学习。学习敏捷会使团队先慢下来。
团队会慢到什么程度？虽然对软件生产力没有一个客观的衡量标准 [Fowler2003] ，但根据经验，我估计一开始会有10%～20%的业绩下降，当团队熟练掌握了敏捷技能时，他们的表现就会变好。在团队的敏捷技能达到熟练程度之前，绩效会持续提高，然后如图4-1所示，团队的表现会逐渐趋于平缓。这就是所谓的J型曲线，它适用于所有重大变化。我们将在第5章仔细研究变化的问题。
时间上的投资通常会在第一年得到回报，如第3章所述，最初的业绩下降时间取决于每个团队所关注的流畅度区域。回顾一下：
· 专注区：1～4个月。
· 交付区：2～6个月。
· 优化区：1～3个月。
这些时期是重叠的，所以一个同时学习专注和交付技能的团队会有一个持续2～6个月的业绩下滑。相反，如果一个团队先学习专注技能，然后再学习交付技能，则会有两个低谷期。学习专注技能时有1～4个月的业绩下滑，学习交付技能时又会出现2～6个月的低谷。
图4-1：随时间变化的敏捷绩效表现
敏捷团队的业绩表现在其他方面也有变化。敏捷团队专注于在开发下一个功能之前将功能全部完成，对于交付团队来说尤其如此，他们从一开始就注重质量，而不是在最后才修复漏洞，这可以提高产量，提升性能。但具有讽刺意味的是，对于那些习惯于同时看到多个功能进展的人来说，这更像是在放慢速度。
最终的结果是，利益相关者可能会对敏捷开发的速度感到沮丧，尤其在第一年，他们要同时面对三个维度的打击：从学习中获得的实际延迟，从注重完成工作中获得的感知延迟，以及为完成敏捷前期这些被宣布为“已完成”但实际上并未完成的工作而付出的成本。
这种挫败感会导致团队在完成敏捷工作之前就不再学习敏捷，而只专注于交付软件，这对每个人来说都是适得其反的，团队会感觉被拉来拉去，从而感到沮丧，而组织也会浪费到目前为止所做的投资。在团队开始敏捷之旅前，要确保经理和利益相关者都能接受第一年的业绩下滑。
你的组织可以通过雇用人员来帮助团队用金钱换取时间。虽然这并不能消除绩效下滑，但会使业绩下滑的时间变得更短，损失更小。有各种各样的帮助方式可供选择：偶尔的指导、培训、帮助流程设计和实施，以及全职辅导。你能得到的最有效的帮助是雇用有经验的从业人员来全职指导每个团队。
当你考虑雇用谁的时候，不要理会无数的敏捷认证计划，大多数认证只不过是噱头。也有一些优秀的培训课程，但那是因为培训师，而不是认证，所以评估培训课程时不要只看认证，聘请顾问和教练时也是如此。可以向你的关系网寻求推荐，查看公开资料和推荐信。
在应用本书实践的过程中，你很可能会遇到一些问题和挑战，这些问题和挑战都是针对你的情况的。请确保你有一个导师并可以向他提问。这不一定要花钱；导师可以是一个在公司里受人尊敬的同事、一个当地的用户组，或一个在线论坛，这些都是不错的选择。
你可以通过以下方式使绩效下降得不那么明显，但在整体上要付出更大的代价：从仅使用专注区开始，慢慢进入敏捷状态。
如果你的组织根本不接受任何绩效下滑，那么现在就不是投资变革的好时机。如果从来没有好时机，那这就是一个巨大的警告。在你继续之前，你需要说服管理层为变革留出时间。
团队有了这本书，再结合网上的许多免费资源以及对学习的执着，就可以自学到所要知道的一切。外界的帮助虽然是有益的，但不是必需的。