循环是“识别并应对变化”的两项基本要求之一——它提供了机会。第二项要求是沟通，通过涵盖所有的人来放大学习的效果，也就是敏捷方法中强调的“信息辐射”。

信息需要被传播给团队中的其他人，甚至更远。没有沟通，问题可能无法被识别出来。没有沟通，发现问题但找不到解决方案的人，就没有机会从其他不同技术背景的人那里得到解决的方案。在团队的环境中，对一个特定的问题，并不总是能够确定解决问题的最佳人选——但把问题告诉每个人等于在邀请所有感兴趣的人都提出他们的建议，而不局限于团队中的“专家”——有时候新手和外行反而能够“跳出框框”而令我们有意外之喜！

沟通能加速并强化学习过程，暂停工作来一次正式的反省可以确保沟通的声音不会被耳边“快点，快点！”的催促声所掩盖。暂停可以像“回顾（Retrospective）”过程那么正式，也可以像迭代结束后的聚餐那么不正式——只要学习与提高被列入议程。虽然沟通按计划应该发生在每次循环的开头（对目标的沟通）和结尾（对结果的检验），但在循环过程中的非正式、“渗透性的”[6]沟通也会有戏剧性的效果。

相当数量的敏捷实践直接针对沟通问题——包括正式的和“渗透性的”沟通：

◆自组织的团队（Self-organizing team）：团队成员一起工作，一起应对发生的变化。他们作为一个集体去进行构建软件所需的工作。

◆同处一室的团队（Co-located team）：团队成员坐在一起，并经常性地举行小组会谈，有意无意地听到成员间的谈话，每个人都由这种信息渗透而知晓正在发生的事情。

◆功能交错的团队（Cross-functional team）：受过不同训练的团队成员聚在一起工作，从头到尾地解决一个问题。通过在一起工作，他们分享彼此的专门知识。

◆结对编程：两个人一起完成一项任务，是一种分享经验与专门知识的非常深入的形式。

◆信息辐射体（Information radiators）：是一个“人人可见的大图表”，它存在的唯一目的就是把一些重要的数据传播给任何路过的人。

◆唤起回忆的文档（Evocative documents）：敏捷团队建立文档的时候聚在一起以便能够互相交谈。以后阅读文档的时候就会唤起对整个讨论和语境的回忆。这比起传统的文档要有价值得多。传统的文档完成之后就被丢到隔壁从此事不关己，它们本质上就是用来装点门面的——也就是说，因为已经在这些文档身上投入了那么多，我们可以（虚假地）相信这些正式文档实际上就是它们所描述的对象。

◆站立会议（Stand up meeting）：敏捷团队每天就刚刚完成的任务、遇到的障碍、以及第二天的任务计划进行沟通以达到同步。

沟通，当它被加入循环，会使得整个团队学习得更快，并且更加成为一个整体。毕竟，软件开发是一种集体工作。如果学习过程对团队来说是一个瓶颈，那么整个团队都需要尽可能更多更快地学习。

如果能妥善运用这些实践，敏捷团队无论学习什么都很快——不仅是技术：设计（TDD、结对编程、功能交错的团队），需求（演示产品和TDR），产品（迭代、发布），以及人（回顾、站立会议）。

为什么这么重要？从理论到实践

好吧，学习过程看起来是软件开发当中一个非常重要的环节。它可能比我们认为的更加重要——那又怎么样？关注学习过程云云又如何能帮助你我的团队生产出更好的软件？

虽然前面列举了众多“学习”方面的实践的例子，敏捷团队并不是对学习瓶颈免疫的。有时候在紧迫的任务的压力下，我们会为了短期的利益而跳过学习的步骤（“哦，我们以后会补上”）。在学习上失败的敏捷团队会表现出以下部分或全部症状：

◆疲劳（没有依照可持续的节奏来工作）导致士气问题

◆再三地无力在一次迭代中“搞定”

◆持续地让承诺落空（甚至有些承诺的特性和用户故事根本还没动手）

◆部署的软件持续地出现缺陷，缺陷之多使得开发计划完全脱离轨道

◆否定回顾的价值，放弃回顾（“因为我们从来都没办法解决发现的问题”）

让你的眼睛盯住瓶颈

请看下图：在每个步骤的名称下面的括号里是一个表示速度的数值。两个步骤速度不一致的时候就会产生积压（Inventory）——由于步骤A比步骤B快，A的过剩产品要等待B的处理。整个系统的产出总是为瓶颈所限[5]。也就是说，如果你希望提高整个系统的总体产出，你几乎只需要提高瓶颈部分的表现。在其他地方花功夫纯属浪费，甚至可能起到反作用。这意味着对于下图中的简单顺序过程（SSP），我们唯一的改进办法是调整步骤D。处理其他地方并不能改进系统产出。

简单顺序过程

如果学习过程确实是软件开发的瓶颈，那么它应该排在我们优先队列的第一位。也就是说我们花功夫在其他地方只会得到非常有限的生产力提高。倒过来说，这意味着任何提高我们的生产力的事物都在某种程度上提高了我们的学习效率。

现在，当我们反思我们的过程的时候，留心观察能传递更多价值的途径，我们要记住通常我们向业务方传递以下几种价值：当然首先是正常运作的软件，另外还有可维护的、可改变的软件，以及一个快速反应的团队来继续这些工作。前两项的优先次序看业务的需要，而第三项纯粹属于职业素养上的期望，通常也掌握在开发团队的手中。最后一项价值——团队敏捷性——实际上是组织的一项资产，它会比一个个项目存续得更久，它会创造出谋取更大利益的机会，并且加快后续项目的速度。

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

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

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社区发展。