敏捷团队应该保持组织的相对稳定，应当存续六个月或者更长时间，以便培育出有效的合作。建立这样的团队需要有战略眼光，而且还要一并考虑每次迭代中必须立即满足的业务需求。如果不能维持这种平衡，由于速度和质量都无法预测，再加上过程中无法排除的陷阱，团队很快就会在业务上失败。

为了避免产生出脆弱而不协调的团队，当我们对过程进行反思的时候，应该问自己下面两个问题：

1、“这会对我们下次迭代的速度有什么影响？”

2、“这会对我们的学习过程有什么影响？”（学习又会进一步影响我们在迭代和项目中的速度和响应能力。）

因此，与其问说“结对编程会不会降低我们的速度？”，我们应该问，“结对编程会不会降低我们的学习效率？还是它会提高学习效率？“与其问“我们真的需要每两个星期做一次产品演示吗？虽然产品所有者一个月才能来一次？”，我们应该问，“把产品演示的频率降低到一个月一次会对我们的学习有什么影响？”与其问“为了支持敏捷，我应该安装哪个工具？”，我们应该问“，工具ABC促进了我们的学习吗？还是它让我们交流得更少，因而阻碍了我们的学习？”，或者采取更好的做法，一直等到真的需要跟踪某些信息（以便从中学习）的时候，才选择一件对你来说最省事的工具[7]。

当我们了解到学习是会增强“团队”这项公司资产的时候，现在我们可以有理有据地向利益相关方解释我们采取学习实践的益处了。“是的，结对编程乍看上去很奢侈——让我来解释一下它是怎样抵消风险的，而且长远来说这样做是物有所值……”别忘了——相对敏捷的短周期来说，“长远”可能说的只是3到6个星期。

下一步何去何从

我们写这篇文章只有一个目的。我们不是要分析学习的理论和机制，这个题目需要长篇大论才能解决，而且已经有了许多长篇大论。我们也不是要分类和验证各种敏捷实践——这里提到的实践只是作为简单的举例，提醒我们只要想学习，已经存在许多学习的方法。

我们的目标是把学习过程放在我们思考和行动的显著地位，因为我们相信它是敏捷实践成功的关键。不要仅仅潜移默化地学习，要把学习放到注意力的中心。本文的作用是提醒诸位，敏捷方法已经提供了许多学习方面的实践和机制——你是否已经在团队以及业务中有效地利用了它们？

用“学习过程是瓶颈”的眼光来看世界。这样可以大大减少出现“货机崇拜”[8]式的敏捷实践的机会，并让你的努力集中在如何令敏捷实践的效果最大化上面。

注释

1、初起炉灶—暴风骤雨—照本宣科—大放光彩（Forming–Storming–Norming–Performing）的团队发展模型由Bruce Tuckman最先提出。http://en.wikipedia.org/wiki/Forming-storming-norming-performing

2、这个假想实验和“学习过程是瓶颈”的说法来自Ashley Johnson，他是Valtech Skill Development公司负责商业计划及策略的副总裁。

3、关于早期轻量级方法的共通性的历史，请查阅Jim Highsmith 的作品 http://www.agilemanifesto.org/history.html

4、另一份早期轻量级方法的共通性的历史，请查阅Uncle Bob Martin的作品 http://blog.objectmentor.com/articles/2007/07/10/the-founding-of-the-agile-alliance

5、敏捷团队中的“渗透性沟通”： http://www.agilemodeling.com/essays/communication.htm

6、熟悉约束理论（Theory of Constraints）的读者可能会觉得这个论点很熟悉，如果考虑到非线性过程，这个论点在很大程度上是过于简化了。

7、参见 《Appropriate Agile Metrics: Using Metrics and Diagnostics to Deliver Business Value》，Deborah Hartmann and Robin Dymond，2006 http://www.berteigconsulting.com/archives/2005/01/agile_work_reso.php

8、货机崇拜：在第二次世界大战期间，许多空军基地建造在偏僻的热带岛屿上，岛上的土著还未进入工业时代。在战争期间军人在岛上建造机场和控制塔，从事各种活动，不时有大型货机降落及卸货。当地土著也会分得一些货物。战后军人撤离，土著也就不再有货物可得。于是他们按照自己的一知半解，模仿出机场跑道、控制塔等等形式，并举行仪式希望能召唤装满货物的飞机归来。于是“货机崇拜”被用来指一群人仅仅采纳了事物表面的形式而非实质，并相信这样做会带来他们期望的结果。

关于作者

Amr Elssamadisy是软件业里的实践者。构建软件是难的——大写的难——Amr的使命是找出开发软件的更好方法，并与社区分享他的发现。今天他在帮助他的客户成功采用敏捷实践构建出更好的软件，只要我们继续学习构建软件的更好方式，明天肯定会不一样。Amr还是《Patterns of Agile Practice Adoption: The Technical Cluster》这本书的作者，同时也是InfoQ的敏捷社区的编辑。

Deborah Hartmann是说两种语言的敏捷实践者、训练者和导师，她以多伦多为大本营从事国际性的工作。Deborah的使命是让工作既对业务有价值又能给团队带来乐趣。她指导过大企业和小公司转向敏捷的过程，从2006年4月起担任InfoQ的敏捷社区的主编，她还推动了XP社区的OpenSpace会议，并帮助加拿大及美国的BarCamp社区发展。

(编辑:aniston)