循环：必要但不充分

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

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

沟通能加速并强化学习过程，暂停工作来一次正式的反省可以确保沟通的声音不会被耳边“快点，快点！”的催促声所掩盖。暂停可以像“回顾（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。处理其他地方并不能改进系统产出。

简单顺序过程

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

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

(编辑:aniston)