我们的敏捷之路-方法篇

前言

关于我们的敏捷实践故事以及技术转型方面已经在我的《敏捷之路》其他的问题文章中介绍过了，这篇文章中我是想介绍一下团队在转型敏捷过程中采取的根具体技术无关的各种方法。

背景

我一直觉得抛开具体的应用环境来谈论敏捷的方法论是浪费时间的行为，因此我们在这还是再简要介绍一下我们团队以及项目的基本情况。项目是一个遗留系统，需要进行大量的更新和优化，距离试运行时间还有两个月。团队方面一穷二白基本都是新人。最多2年经验，测试经验为零，更关键的是用户没有明确的需求。

敏捷方法

时间盒

项目下一个里程碑是试运行，由于距离试运行时间节点很短，不足两个月，我们将迭时间盒即迭代周期选为一周。经过八个sprint的艰苦卓绝的奋斗，系统终于如期进入试运行。但这两个月基本每个sprint都要加班才能完成任务，可以确定一周的迭代周期对于一个刚刚接触敏捷的团队是不太合适的。经过两个月的一周spirnt开发，团队成员普遍压力很大，状态不佳。

完成了试运行节点，团队深受鼓舞，在庆祝和欣喜之后，为了保证团队的持续战斗力，同时项目没有明确的节点要求，因此在接下来的迭代开发中，我们将时间盒调整为两周。团队成员的状态有了提升，经过大家讨论确认两周的时间盒长度是合适的，接下来没有特殊情况时间盒都是两周。

任务板

我们发现敏捷里第一个实用工具是任务板。通过任务板可以让团队中的每个人都清楚团队其他人的工作，同时配合上燃尽图和累积图可以直观的了解到项目的进展情况。

我们的任务版最开始就是普通的白板，分为三列分别是Todo,Doing以及Done，下面是多行每行是一个团队成员。

后来经过我们时间不断对任务板加以改进，形成了如下图所示的样子。



任务板

增加的内容：

1. 改进任务区，用来显示回顾产生的改进项；

2. 个人临时区，供成员放置实时做完的任务；

3. 加急通道，用来放置特殊的紧急临时任务。

4. MVP区，用来放置每个周期选择的最优先的任务，该任务一般是TDD或结对变成来做

5. 图表区：包括燃尽图，速率图以及累计图等手绘图表用来显示项目进展。

每日站会

我们发现敏捷里另一个简单实用的方法是每日站会。

我们一般在白板前进行，每天回答三个问题：

昨天做了什么？

今天准备做什么？

有什么困难？

关于这三个问题的回答还是很有必要要说一下的，首先不要让每日站会变成团队成员向你一个人的报告会，站会的目的是更加有效的沟通而不是报告，其次，最好与任务板结合，让每人在说自己的工作时同时更新任务板的内容。最后，务必每个团队成员都要参加没有例外，可以设立发红包，请大家喝饮料或扫地等惩罚措施。

计划会议

计划会议是每个迭代周期团队要做的第一件大事，由PO来给出用户故事和优先级，团队则进行任务拆分和评估，并对业务细节与PO或BA进行讨论。

可以考虑使用计划扑克的形式，值得注意的是要团队所有人一起参加，明确需求以及优先级是计划会议第一要务。刚开始时这个计划会议会很耗时，这时候SM要及时引导大家注意时间和讨论的范围。

需要注意的地方：

计划会议是敏捷团队获取需求的主要形式要让整个团队都参与进来；

让团队对于评估任务大小的粒度一致；

PO和核心测试人员一定不能缺席，万一缺席就需要他们找指定的人替他们出席并保证指定的人能达到他们的水平。

回顾会议

回顾会议是每个迭代周期团队做的最后一件大事，由SM主持，主要是确定本周期团队做的好的方面，做的不好的方面，更关键的是确定需要改进项。

关于回顾会议需要注意的地方是：

1. 开发团队一定要参加

2. 不要让会议变成自我的评价会议，是针对团队的方法而非个人

3. 组织领导不适合第一个发言，否则团队成员可能出现附和的情况

4. 改进项的确定交由团队确定，而不是领导指派

其他相关

测试驱动开发

关于测试驱动开发即ＴＤＤ，我们曾经尝试过但是失败了，原因很简单，人员的能力还没有达到ＴＤＤ要求的层次，因此就没有再去刻意的要求。

下面是关于ＴＤＤ的经验。

1. TDD对于开发人员的要求很高，主要体现在设计能力，开发能力，单元测试能力以及自律能力方面。

2. 不是所有地方都适合TDD。

3. 不要刻意单一的追求测试覆盖率。

结对编程

极限编程是由当时Smalltalk领域的大师级人物Kent Beck在1996年受聘领导克莱 斯勒公司的一个综合工资项目开发 C3(Chrysler Comprehensive Compensation)中首次采用, 并于1999年10月出版的《解析极限编程》一书中正式提出了这一软件开发方法。

结对编程我们也做了尝试，但是也是无疾而终，我觉得还是能力和文化没有达到结对编程的要求项目也不是十分适合结对编程。

关于结对编程的经验也是有一些。

1. 尊重和理解

2. 结对对象要不断调整

3. 每次时间不宜超过30分钟

4. 不是所有人适合结对

5. 不是所有的项目都适合结对

代码审查

代码审查是一种有效的提升团队水平的手段，一般都是下班前大家坐到一起来review每个人的代码，注意不要与下班时间安排的过紧，那样大家就没什么心情review了，而是一会要吃什么等等其他问题。还有注意review要对事不对人，发现情况不对赶紧介入。

结论

本文讨论的敏捷的形，而决定一个组织能否采取敏捷提升自己的效率的是是否能够接纳持续改进，全员负责的敏捷思想，一定要注意不能忽视团队的敏捷文化导入，否则敏捷转型只是形式上的，而结果一般都是转型失败。

适合自己的才是好的方法。