AIChinese的敏捷之路

早就应该写这篇文章了，但是总是觉得没把握写好，还是不要出来误导别人了。现在通过团队的共同努力，已经证明了我们能够改善甚至解决一些问题，是团队给我了写这篇文章的信心。这篇文章的名字其实我早就想好了，但是我一直疑惑的是AIChinese项目开发究竟敏捷了没有。现在想来，多多少少敏捷了吧，于是还是决定用这个题目了

 

项目组在经历连续的加班、延期一两个礼拜之后，终于在2010/8/25将AIChinese第二个版本（Sprint2）发布了，大家基本上已经累趴下了，真的是身心俱疲。经过前两个版本的痛苦经历之后，项目组一直在想一个问题，到底我们接下来的项目开发如何前进，如何解决我们在前两个版本遇到的诸多问题？

注：其实真实的延期比这个还长，因为当时就没有明确的结束日期，这个结束日期是在管理层的再三催促下定下来的

面对的问题

在前两次发布中，我们遇到了一下比较严重的问题：

1. 项目目标不明确
2. 项目需求不明确
3. 项目需求没有主次
4. 项目中的各个成员之间经常出现信息不同步的情况
5. 项目进度不能很好的把握，前松后紧，经常延期
6. 软件开发流程繁重
7. 软件开发标准模糊
8. 软件设计投入较少，软件开发质量比较差

这个时候我也开始接触敏捷软件开发思想，正在看一本书叫《敏捷软件开发的艺术》，大概翻了几章之后，犹如在黑暗中找到一盏明灯，刹那间觉得敏捷就是为解决我们项目中问题而来的。在老大的鼓舞和支持下决定在团队中试一下敏捷开发。

但是书本上的东西毕竟是书本上的，如何将这些敏捷思想，价值，实践运用到项目中来，心里没底。

        《敏捷软件开发的艺术》对团队的敏捷转型的指导意见是刚开始就使用全部的敏捷实践，将团队做彻底的转型。但是从当时的情况来看，这个在我们团队中是比较困难的，一来我的项目管理经验，敏捷实战经验太少，实在没这个能力；二来，团队成员敏捷软件开发的知识和经验都是比较缺乏的；三来，团队成员能力和经验参差不齐，不容易统一思想。在接下来的sprint3中，经历过了一些失败的敏捷实践尝试之后，我们决定从最关键的问题着手，运用敏捷思想，逐步改善流程。

第一：目标是什么？要实现什么价值？

我们Sprint1, Spritn2整整花了4个月的时间，到最后才做出了真正具有价值的语言练习模块，在此之前没有任何发布，也就是说没有创造任何价值，管理层也对我们的进度非常不满。现在想来完全是漫无目的的闭门造车（主要是商务目标）。虽然是产品，但是没有从最大化公司利益出发，也没有从客户的角度来设计和制定计划。

现在一个很现实的问题摆在我们面前，Sprint3我们要实现什么目标？多长时间？

注：以下的描述虽然以Sprint3为例，但是都是贯穿于整个接下来的AIChinese项目开发中

首先，为了在固定的时间内有更高质量的功能开发出来，我们决定采取Time Boxed^[1]，我们选的是6个礼拜。这样就迫使我们在每个Sprint中去做出纠结的、非常艰难的取舍，从而获得更有价值的决定。

敏捷开发提倡全部完成^[2]，零Bug^[3][a]，也就是说一个功能完成的定义应该是全部完成了预期的功能并且没有Bug了。但是由于我们的开发质量，包括自动化测试这一块的欠缺，我们还需要在一次发布中留足测试时间，我们预定2个礼拜，也就是说，每六个礼拜就有两个礼拜的需求冻结期^[4]。我们希望随着开发质量的提高和自动化测试的普及，能够减少每次发布的需求冻结期。

其次，优先考虑公司利益，以客户利益为重。

在Sprint3开始的时候我们首先询问了公司管理层对AIChinese的规划，从而制定了Sprint3的整体目标，然后再把这些目标拆分成具体的用户故事。团队将用户故事拆分成开发任务（程序员的拆分原则是垂直拆分^[5]，避免水平任务拆分），进行时间上的估算。我们的需求方（包括市场、设计和公司高层）和程序员、QA在一起，综合考虑任务的重要程度，任务开发的成本和整个开发周期的长度，我们按优先级制定出了一份此次发布的任务列表，在这里我们运用了计划博弈（Planing Game）很好地提高了发布版本的商业价值。

第二：信息化工作场所

我们在前面的工作中经常出现延期的一个原因是大家对项目计划不了解，对项目的进度不清楚，不敏感，开发比较盲目。原来的项目计划是“藏”在电子文档中的，查看，更新都不是那么直接，人类趋利避害的本能导致人们去避免一些比较繁琐的事情，所以必然造成大家对项目的计划，状态和计划变更不敏感。

我们改善这种情况的方案就是将项目计划和状态实体话，让大家很容易地就能够看到。在公司的支持下，团队购买了白板、卡片、磁石，将任务写在卡片上，并在白板上将卡片排列组合成我们的计划，并且用非常简洁、明显的方式表示每一个任务的状态。现在调整计划，更新计划状态都是非常容易做到，也非常直观。每天的站立早会大家都站在白板前检查、更新项目的进度。

第三：减小计划粒度，利用短迭代来检查项目状态

前面说到我们的一个发布周期是六个礼拜，除掉两个礼拜的测试时间，我们有4个礼拜的开发时间，我们将这四个礼拜拆分成四个迭代（Iteration）。每个迭代是一个最小的发布周期。敏捷实践中说到每个迭代都应该具有发布的能力，但是在当时的情况下我们的质量控制能力是达不到的。所以我们降低要求，将一个迭代计划作为我们的一个功能开发的截止点，也就是说不能出现一个任务的估算大于一个迭代，也不能出现跨迭代的功能开发。如果出现以上情况，则继续拆分功能。实际上我们允许的最大的单个任务开发时间是3天。通过以上步骤我们增加了检查结点（实际上我们在每天的站立早会（Standup Meeting）上都会检查状态）：检查功能的正确性；检查项目进度，及时察觉延期的趋势。这样做给团队带来的一个最明显的改变就是我们每次都按时发布了预期的目标，并且几乎再也没有加班。

上面说到我们按时发布了预期的目标，其实我们最后发布的功能和最初的计划是有一些变化的，由于估算不精确，或者开发中出现了意外，我们的一些任务出现了延期，导致有些功能来不及开发了。但是由于发布时间不能变，我们不得不思考孰轻孰重，孰急孰缓。所以在发布的时候没有能够完成的任务都是相对来说不那么重要的。从而达到了分清需求主次的目的，并且提高了整体发布的价值。

第四：加强团队协作

在前面的工作中经常性会出现大家对需求理解不一致的问题和信息不同步的问题。

团队开发是涉及到多个人的协同工作，那就必然涉及到多人之间的信息交流，如果交流不好，或交流方式不对，必然会造成以上问题。

让我们来剖析一下需求理解不一致的问题，对一个事物每个人都会有不同的认识，没有两个人的认识会是完全一致的，这是自然规律。对待需求也是一样，大家都会对需求有不同的认识。问题来了，如果同一个团队中对需求的认识不一致，那造成的后果就是大家目标不统一，不能往一处发力，并且会产生所谓的团队冲突，甚至产生敌对行为。这是一种非常危险的信号。如何解决呢？原来我们的做法是让需求尽量详细地记在文档上，然后充当团队队员之间交流的介质，这是一个比较通用的办法，但是同样存在维护成本大，并且要做到无异议地文字描述也是非常有挑战性的。我们的实践经验告诉我们：以乐观、积极的心态去进行交流和协作。敏捷思想告诉我们个体与交互 胜过 过程和工具。既然大家都有可能有不同的认识，那大家都将自己的理解说出来，大家思想的碰撞和汇总就可以得出一个思考更全面的结果，然后再将这些结果记录到文档，把大家的共识保存起来。

我们通过三种方式来加强交流：每次迭代的计划会议、每日早会 和 功能Reivew。每次迭代的计划会议大家一起过一下这次迭代的任务，通过设计人员的讲解，对任务细节有一个具体的了解；大家通过每日早会互相了解了团队中每个成员的工作计划以及遇到的问题，如果出现和自己的理解不一致的问题大家可以一起交流；功能Review是一个功能完成后设计，开发，QA一起坐下来确认一下开发完成的功能是否满足各自的预期，往往这个时候交流比较多，因为真正可用的功能已经出来了，而不是存在于大家的大脑中，或者文档中，或者设计图上，软件开发的最终目的已经达到。对于大家的理解不一致，或者发现潜在没有考虑到的问题，这个时候也是一个集中的爆发点。

通过各个层次的交流，大家不光将各自的理解，想法，进行统一、汇总，更重要的是：通过差异化的思考，我们能够将事情想的更全面一点，彻底一点。多样性的团队才有价值^[6]

第五：改进发布流程

再快速地开发，再好地质量控制，如果不能迅速地发布，那开发所带来的价值将会大打折扣。

一个非常重型地发布流程会让人害怕去发布，从而降低我们的敏捷性。新开发的特性不能及时地发布到服务器，大大降低了开发的价值。刚开始发布的时候我们的发布步骤有十几个，经常一折腾就是一个下午。每次都要停机发布，部署各个组件，在服务器上修改配置文件，启动服务器，可能某个地方出了问题，还得排查，再加上那个时候公司的网络状况也不是很好，发布简直就是高危、高压力、令人发狂的工作。

再后来虽然发布时间缩短了，主要是做熟了，但是步骤一点没有少，手工工作太多，情况没有得到实质性的改善。但是轻量化发布的要求与日俱增，迫使我们寻找更快捷的办法，我们试着精简流程，将发布流程尽量精简，自动化，将配置文件参数化，一步步地精简，终于，我们现在的发布已经完全不需要停机和在线修改配置了，发布也缩短到短短十几分钟了。

以上五点是我认为我们团队在敏捷思想下最重要的改进，这些改进的结果就是我们的团队一起紧密协作，按照固定的周期，发布出管理层期望的、满足客户需求的软件。

        当然，我们也必须看到我们现在的成果只限于满足需求的层面上，对于技术管理和实践我们并没有花太多的时间去改进，我们的代码质量一直没有明显的提高，臭味随处可见。这也是我们权衡的结果，先满足外部需求 — 对于这一点，我们的团队已经做到了。

后记：

我们团队的敏捷改造现在还在稳步前进中，在不断变化的项目和条件下，我们继续使用敏捷思想来解决我们的问题，提高我们的团队凝聚力和战斗力。

现在我们针对以上描述中出现的短板继续改进，比如：

1. 技术实践
2. 团队的持续改进
3. 如何应对需求变更
4. 如何挖掘客户真正的需求
5. 团队的分工与协作
6. 团队的自组织

我会继续撰文为大家描述以上内容。

^[b]

---

[1] Time Boxed：也就是固定发布时间，不管有多少需求，在固定的时间之内一定要有一次发布。

[2] 全部完成：一个功能完成后应该是完全达到了需求期望的功能

[3] 零Bug：一个功能完成后除了满足需求之外，还应该尽量不产生Bug

[4] 需求冻结期：是指在特定的时间之内，要保持需求不能更改，不然就会给软件开发造成不确定性。在敏捷开发中，这个时间应该是很短，甚至是没有的。

[5] 垂直任务拆分：每个任务都是一个可以运行的功能，而不是按照开发架构的层次结构来分，比如表现层，数据层等。

[6] 在一次培训中听到的，非常精彩地描述了团队的价值，喜欢这句话