引言

本文讲述了一个我们如何在一家公司的特定项目中指导敏捷软件开发过程的故事。它传递给我们下述信息：一旦软件工程师理解了软件开发过程中对转变的需要，他们就能够完成（转变），而挑战是指如何指导他们自己认识到转变的必要，同时让他们自己引导这种转变。这样的认识需要观念上的转变，而我们的职责就是在采用敏捷方法的初始阶段引导这种（观念）转变。 我们用来指导这个过程的机制就是在每个迭代结束时进行一小时回顾会议。当团队成员开始自己主持回顾会议时 ，这标志着a）团队已经准备好引导敏捷开发所需要的观念转变和在开发过程中的转变，和b）我们已经完成对这个团队的指导。从我们的角度来看，达到这一阶段即为成功的标志。

在通常软件开发过程中引入反思过程，特别是在敏捷软件开发过程中引入的重要性，主要是基于Sch?n《反思实践者》的观点。（Sch?n，1983）。

从团队的角度来看，回顾过程旨在研究开发过程，并寻求改进方法。从指导者的角度来看，回顾也可以作为一种可以加强观念转变的工具。为了尽可能地挖掘他们的潜力，回顾会议选取在每两周迭代开发周期结束时进行，同时为了保证生产效率，每次会议时间控制在一小时。另外，在这个会议期间不进行其它活动，在每次回顾会议结束前至少会做出一个任务项，并指定具体的负责人。

示例图1描述了如何实现回顾会议的目标。实施每次回顾会议结束时做出的任务项将会在开发过程中产生一个变化，这种变化会导致对开发过程本身观念上的改变。这种变化，特别是在逐步实施敏捷过程中，在软件开发过程中产生了新的改进需要，这种需要最终会成为将来某次回顾会议的主题。这种方式，通过这个过程建立了观念转变，这个循环会在每一个小的观念转变导致下一个转变的过程中继续。逐步地，这些小的观念转变积累成为团队对于软件开发观念的显著转变。如下文所述，我们的经验表明在某些时候，这种转变足以使团队有能力自己开始主持回顾会议并自我主导这种观念转换。

示例图1. 回顾会议循环：回顾会议驱动观念转变

故事

项目环境

这个故事是关于一个复杂的、独一无二的项目，该项目是为客户特定需求专门定制应用程序的敏捷项目。这个特定的项目是系统开发，不像其它软件项目一样，这个项目开发涉及诸如硬件、固件和机械部分多个领域。这类项目开发周期相对很长，需要数年时间甚至有些情况下会持续几代人。

因为许多严重的问题，例如需求经常变化，费用超支（主要跨领域间的协作和集成），和团队内部缺少沟通，项目决策层决定在软件团队内尝试敏捷方法，软件团队包括15个成员，分为4个小组。大多数团队成员都是经验丰富的嵌入式实时软件工程师，他们专长是网络和通信。其中的一些人是团队领导。

敏捷方法分两个阶段实施。在第一阶段，应用了Scrum框架中的下述敏捷实践：每8周一个sprint，在小组内的每日站会，维护一份sprint backlog，sprint总结展示和sprint回顾会议。这一阶段向诸多方面的改进前进了一大步：计划，沟通和客户（系统工程师）合作。

然而，似乎必要采取更重要和有勇气的行动才能发挥敏捷方法论的最佳效果。具体来说，sprint回顾没有包括任何可测量的数据，因此没有关于流程成果的客观数据，无法衡量改进情况，也不能系统的改进流程。

第二阶段，也就是在我们指导开始后的第五个月，流程得到加强。特别是，软件团队采纳了下面的敏捷实践：迭代周期为两周的短迭代，客户参与，数据测量，角色分配和每两周的回顾会议。

描述关于知识共享的回顾会议循环

为了开始和敏捷方法相关的观念转变，在第二阶段的开始，回顾会议由我们主持，依靠我们作为软件从业者在软件工程上的专门知识。

表1描述了前15次和项目团队一起进行的回顾会议。可以看到，知识共享是几次回顾会议的主题。根据回顾会议循环（示例图1），回顾会议的主题不是在指导过程一开始就决定的，而是随着敏捷转变过程浮现出来的。几次回顾会议都关注于知识共享的事实一点儿也不应该感到惊讶；毕竟软件工程就是知识工作，因此，知识共享成为回顾会议的主题可以合乎情理，这些主题也应该在敏捷方法实施过程中解决。

表1. 回顾会议（#1——#15）

示例图2描述了知识分享的回顾会议循环，显示了回顾会议如何通过知识分享促进观念转变。

示例图2. 在知识共享的例子中的回顾会议循环

我们现在来描述两次知识分享的回顾会议并解释如何促进观念转变。

第二次回顾会议（指导过程开始后的一个月）：要求团队成员指出三件积极的事情和三件当前开发过程中需要改进的事情。缺少项目中不同部分的知识被确认为需要改进的内容，并被选为在所有团队成员提出的需改进内容中亟待解决的。在这次回顾会议结束的时候，确定了下述改进项：a）了解每个团队成员的专长领域（团队领导负责完成这项任务）和b）接下来几个迭代中，分配不熟悉特定领域知识的团队成员负责需要这些领域知识的任务。

实施这些任务项通过两种方式启动了知识分享的过程。首先，团队成员需要指出他们在项目不同部分的专长。为达到这个目的，他们必须a）评估他们在项目不同部分的知识水平和b）和其他团队成员分享评估结果。第二，分配需要特定领域知识的任务给那些不是很熟悉这些领域的人a）拓展了他们在项目不同部分的知识和b）鼓励那些在这些领域是专家的团队成员分享他们在这些领域的知识以便于支持团队成功的完成这些任务。毫无疑问这四个行动中的每一个都促进了知识共享并通过消除项目不同部分的知识鸿沟的方式改变了团队关于开发流程的观念。

第七次回顾会议：在一次观察站会之后，我们意识到在站会上团队成员见提到的一些概念表明存在知识差距。在确认这些差距确实存在之后，我们决定在第七次回顾会议上解决这些知识差距的问题（至少是部分解决）。

回顾会议的开始，我们要每个团队成员写下三个在站会上提到的他们不懂的概念。所有这些概念都匿名的写在白板上，并且团队成员对每个概念都投票指出他们理解或不理解。这个过程进行了10分钟。然后团队分为5个小组，每个小组要求选择一个概念然后花20分钟准备一个关于这个概念的介绍。接下来5个组分别为准备的概念做一个5分钟的展示，每个展示后面有一个1分钟的简短问答。这次回顾会议的一个行动项目是将这些介绍组织到团队的知识库中。

这个回顾会议得到了很多和知识分享相关的产出。首先，团队成员应该详细梳理在站会上提到的概念有关的知识并定义对这些不清晰概念的熟悉程度，无论这些不清晰的概念是他们自己的还是其他团队成员的。第二，当团队分小组整理概念时，团队成员必须一次次的分享他们对这些概念的知识，以便准备简短的展示。那些熟悉概念的团队成员出于完成展示的目标也得分享他们的知识，那些不熟悉的团队成员也要提出问题并指出哪些地方不清楚。第三，在小组展示的时候，所有这些知识都为整个团队所共享。

结果是，在一个小时之内，识别了5个不清楚的概念，准备了解释这些概念的简短展示并与全体团队成员分享，所有团队成员都参与其中，每个团队成员都分享了各自的知识。很显然，向分享知识的文化的转变已经达成。

团队成员开始引领观念转变

在我们开始指导过程的八个月之后，在这期间敏捷软件开发原则已经逐渐介绍给团队并实施，我们组织了一个专门的回顾会议来总结到目前为止我们完成了什么。我们询问团队成员，让他们指出在这个过程中三件好的事情和三件仍需改进的事情。这个回顾会议的结果是，两个需要解决的问题浮现出来：a）在团队中专门的知识分享时间；和b）避免时间压力。在接下来的回顾会议中，我们进一步研究了这些结果。

大约指导过程开始一年之后的一次回顾会议上我们解决了避免时间压力这一主题。在这次回顾会议中间，一个团队成员打断了讨论，说：“我们没抓住要点。在过去的几个回顾会议中，我们讨论了度量这些我们不懂的东西，但实际上分析未决任务更重要。”我们认识到这正是让团队成员自己领导回顾会议的时候，因此我们停止了回顾会议并和这位团队成员说：“请继续主持会议。”那个团队成员很自然的接过会议主导并接着主持回顾会议。这次回顾会议的行动项目是识别为决任务列表。[2]几个团队成员，根据计划，每人选择一个任务并主持关于该任务的回顾会议。

自此，在我们开始指导过程一年之后，回顾会议由团队成员自己主持。这个过程非常自然，每次回顾会议的主题都是由团队识别出来的，或者是由一个团队成员提出一个对他/她来说亟需解决的问题（例如时间估算和个人职责）。

总结

这个故事描述了观念转变如何与技术改变相关联，并建议使用一个途径——回顾会议——将两个过程关联起来。从我们的角度来看，作为敏捷教练，当开发团队，也就是开发流程中工程方面的专家，能够同时实行这两项转变过程，就意味着成功。

参考

Hazzan, O. and Dubinsky, Y. (2008). Agile Software Engineering, Springer.
Kerth, N. (2001). Project Retrospective, Dorest House Publishing.
Sch?n, D. A. (1983). The Reflective Practitioner, BasicBooks.