敏捷开发

 

1      前言：敏捷改进的关键要素

1.1     从传统团队开始

传统团队一般按照功能职责来组织划分团队，团队内部沟通与协作较少，而团队之间往往以“接口人”的形式限制沟通与协作。团队内的工作流程是瀑布式的，每个人的工作往往要到项目/版本末期才会集成到一起，因此彼此的工作目标是不一致的。

 

1.2      第一步：沟通与协作

敏捷转型的第一步，就是建立起来沟通与协作的机制。

 

团队内有广泛的沟通与协作，信息不是集中在个别人手中，而是透明地在团队内传播，从而团队有能力决策日常工作。

 

团队间不再设立“接口人”制度。敏捷鼓励团队之间广泛而高效地沟通；有许多敏捷实践帮助团队间有效沟通，而不会妨碍工作效率。

 

同时在团队划分上也会发生变化，团队按照特性(Feature)进行划分，大多数团队都是跨职能的，具备完成一个功能的必要技能（如设计、开发、测试等）。

 

1.3     第二步：进化

在沟通与协作的基础上，团队迭代式工作。一般而言，一个迭代的长度在1 – 2周之内；迭代长度是对团队技术能力的反映。每一个迭代的工作结果，都是对上一个迭代工作结果的改进与补充。

 

通过频繁迭代并交付，团队透明度提高，进一步加强与促进团队内部和团队之间的沟通与协作。

 

1.4     第三步：集成

在迭代的基础上，将所有人的工作尽早集成在一起，并使之与项目/产品的商业目标一致。团队之间的工作界限重叠度高；团队存在的意义在于，通过促进团队成员的沟通与协作，建立起来团队内部的工作范式，从而达到高效工作的目的[1]。

 

1.5     第四步：反馈

广泛地从团队内部与团队外部收集反馈，并根据反馈进行持续改进，从而达到更快、更好地达成商业目标的目的。

 

2      实践基础

2.1      What什么是站立会议

站立会议（英文为Stand-up Meeting，简称站会或Stand-up，也有Daily Scrum, Scrum Meeting等名称）是一种参会者站立着参与的会议，长时间站立的不舒服感有助于缩短会议时间，提高会议效率。

 

在Scrum框架中，团队每天在固定时间、固定地点进行站立会议，其目的是通过沟通工作进展，促进团队内的沟通与协作。这个会议的标准名称为Daily Scrum，但在实践中人们习惯地称之为站立会议。这个简单的实践能够显著地改进沟通协作，因此在非Scrum团队中也有极其广泛地应用。

 

2.2     Why为什么要做站立会议

当沟通是无序的、单向的、不透明的时候，沟通成本非常高、效率却非常低。

 

站立会议是：

l  有序的：每天固定时间、固定地点进行，参与者明确，沟通内容明确；

l  开放的：每个人所沟通的内容对于全体参与者都是重要的，因此沟通是开放性的；

l  透明的：沟通内容完全体现在可视化的看板上，团队进度对所有人都是透明的。

 

站立会议的有序性、开放性和透明性帮助提高沟通效率，降低沟通成本，消除沟通障碍，从而帮助提高工作效率。

 

2.3     When & Where站立会议的时间、地点

站立会议的原则之一就是每天召开、固定时间、固定地点。时间地点应由团队自行讨论决定，确保每位团队成员都能够准时参与会议。

 

一般而言，召开时间可以放在上午上班后（较常见）、临近午休、午休结束或者下午下班前（较少见）。

 

会议地点在团队进度看板前。有条件的情况下，看板应该放在距离团队的工位较近的地方。墙壁、柱子、会议室的外墙等都可以作为看板的放置地点。

 

2.4     Who谁参加站立会议

全体开发团队成员（开发人员、测试人员）参加站立会议。

 

需求人员（Scrum中的Product Owner）可以选择参加或不参加站立会议。需求人员在站立会议中扮演的角色是及时澄清需求，或根据会议中发现的问题，在会后与相关人员澄清需求。

 

团队管理者应以“沉默的参与者”方式参与站立会议。尽量确保站立会议不会变味成汇报会议。如果团队成员在沟通时面对着管理者发言，那么管理者可以转身背对团队，或不参与站立会议。

 

ScrumMaster或敏捷教练可以自行决定是否出席站立会议，以及在会议上扮演何种角色。对于缺乏经验的Scrum Master，在会议中你应该扮演引导者的角色，即如果会议进行得很顺利的时候，你不需要发言或者引导，而如果有成员过度进入细节、讨论站立会议范畴外的内容、或者陷入某种局面需要帮助的时候，你及时站出来引导会议回归主题。

 

其他角色不建议参加站立会议。

 

2.5     How如何进行站立会议

在站立会议上，每个团队成员都要回答三个问题：

1.      从上一次站立会议到现在，我完成了什么工作内容；

2.      从现在到下一次站立会议，我计划做什么；

3.      我目前遇到了什么阻碍、需要谁的配合、或者需要什么帮助。

 

通过回答这三个问题，团队建立了一份沟通索引。根据这个索引，每个人都清楚哪些工作项需要进行沟通、谁需要参与沟通、以及何时进行沟通。这样，在会后相关人员自行沟通，而不相关的成员无须耗费时间精力参与讨论，团队的沟通、协作、以及工作效率都会得到大幅提升。

 

与会者需要避免针对细节进行讨论，因此每人只有最多2分钟的发言时间、发言时避免进入讨论。整个站立会议的时间不能超过15分钟。

 

站立会议是团队自己的会议，因此到了指定的时间，团队成员会自动地到达会议地点。不需要管理者、Scrum Master或敏捷教练的提醒或催促。如果在固定时间没有人到达会议地点，团队可以在下一次的回顾会议上探讨哪里出问题了，并做出相应的改进。

 

3      Tips小技巧

3.1      每天识别一个障碍

在改进初期，团队面临的障碍是很多的，但是往往团队已经对此习以为常，并不认为这是问题。因此可以在站会上设置一个识别障碍环节：当所有人发言完毕，团队一起识别出一个阻碍团队高效工作的障碍，并记录下来。不需要立即着手解决这个障碍，可以将其留到回顾会议(Retrospective Meeting)上进行讨论。

 

3.2      团队聚焦

三个问题、燃尽图、白板。团队发言时很容易陷入到细节讨论，或者是一些具体信息的沟通，这容易让站会失去焦点，或者让部分参与者注意力不集中。具体信息的沟通应该是随时随地的，不能积攒到站立会议上。

 

3.3      时间盒概念

会议是有时间限制的（Timeboxed：15分钟），不要在站会上试图讨论甚至解决问题。

 

3.4      Scrum Master的作用

ScrumMaster记录大家的障碍，并在会后协助团队移除障碍。Scrum Master不能扮演主持人的角色——站立会议上不需要主持人。作为引导者，Scrum Master在团队失焦的时候及时打断细节讨论，提醒团队时间盒剩余。

 

4      问题示例

4.1      队形问题

你的团队在站立会议上呈现半圆形站位吗？每个人在发言时都看着Scrum Master或管理者吗？

 

4.2      如何对待迟到者

毫无疑问地，迟到者需要受到一定程度的责备；但是切忌不能用行政的、管理的、压制的手段予以责备。记住，敏捷改进的一个重要思想就是调动起每个团队成员的积极性，构建信任氛围。

 

在实践中，好的处置方式都是由团队自行提出的。下面是一些示例：

Ø 迟到者为大家唱首歌或讲个笑话；

Ø 迟到者向团队的“冰激凌基金”捐一元钱；

Ø 在团队看板上记录每个人迟到的次数，并在回顾会议上讨论；

Ø 在回顾会议上思考是否重新设置站立会议的时间，让每个人都更容易准时出席站立会议；

Ø Scrum Master私下里向迟到者沟通迟到的原因，并探讨如何帮助迟到者消除该因素。

 

4.3      如何对待多个声音

站会上应该只有一个发言者。为了避免开小会、细节讨论等，可以考虑设置一个令牌，只有持有令牌的人可以发言。令牌可以是玩具鸡、黑板擦等小道具。

 

4.4      会议超时

我们不能接受会议超时。Scrum Master可以在会议剩余5分钟、2分钟、1分钟时提醒团队。15分钟的时间盒结束后，ScrumMaster可以沉默地向前跨一步，抬手看一下表，然后转头离开会议。也可以坚决果断地告诉团队，时间已经到了，我们必须立即结束站立会议。

 

 

---

[1]参见Tuckman团队成熟度模型http://baike.baidu.com/view/2135946.htm