——2 days agile development project

Code Jam是ThoughtWorks特别的活动之一，在很短的时间内为客户交付可用的软件（或原型），团队经过短期高强度的锻炼，可以对开发过程和开发技巧都做一些反思。这次的Code Jam是为乡村教育基金会做一个网站，属于一次公益性质的活动。我们几个人从周五开始就忙碌了起来。

首先，作为BA，先期了解一些需求是必要的。在开发之前，必须要知道Scope和优先级。周五下午我和QQ俩人就和我们的Client，来自（伦敦、香港、墨尔本）的Steven，一起进行了简短的需求分析。由于项目不大，而且总共只有2天时间，我们重点关注于需求的优先级。在搞清楚流程的基础上，把优先级分了7级。听起来好像很多的样子，实际上，从需求完整性考虑的话，前1－3级的需求比较多，后面的都是很小的功能模块。我们保证每一级开发出来都必须是可用的软件。Steven非常聪明，对我们的方式适应极快，很快把握到排序的要点，到后面亲自操刀开始写Story，终于达到了”客户编写用户故事“的极境，令俺窃喜不已。

终于，4个多小时之后，全新的story list出炉了，1-3级story有卡，1-2级的卡背面写有A/C。总结下来，这次需求分析做的比较好的地方有：
   1. 要在很短时间内需要搞清楚足够开发的需求，因此我们确定了项目远期目标、用户交互流程、特性的优先级，取消了评估开发时间一项。在下午需求会议开始前，我们制定了：1 项目目标 2 功能范围 3 优先级 4 界面交互原型 5 用户故事 6 细节验收条件等会议步骤，在4个小时内准备好了可以开发的需求。
   2. BA、QA和客户坐在一起交流需求。这是非常理想的情况，很多项目由于种种条件限制使得BA/QA没法从一开始在一起。
   3. 需求和界面原型全部采用纸质管理，没有除了照片以外的任何电子存档。不管是开发人员还是BA/QA，都手持卡片和人交流，有任何问题和发现都记录在卡片后面，这节约了很多时间。（当然，由于QQ太过谨慎，怕卡片被打扫卫生的阿姨清走，特地锁在了她的宝箱里，结果晚上胃病第二天没法来……由此可见，项目风险总是不可能全部预测的）
   4. 在Story的上面标注了依赖关系。以往做Story经常忽视这点。这次特别标记出来，在开发过程中作为Dev开发的参考。
   5. 优先级的制定。没有采用传统的MoSCoW法，而是就用1-9的数字来表示。我们最终将1-3的大多数需求交付，客户很满意。
   6. Hight Level 系统结构图。通过整理此图，我们全面的了解了系统的蓝图，客户也在过程中重新反思了不少的特性。这图不完全是流程，其实更像是Information Architecture+Domain Model，结合了功能+界面两种不同的元素

做的不够好的地方也有：
   1. 由于对Rails开发的效率无法预估，我错误的假设了两种不同类型的文档在提交时候有很大部分功能可以复用，因此在写第二类的时候，简化了一些Story，最后证明这些还是得写上。此处犯了INVEST中I的错误
   2. 有些Story的A/C描述的不够。凡是有可能出错的地方都一定出错定律。。。例如，search结果的list中，通常都有link可以view detail，因此就没写在A/C，果然被遗漏了

周六开始进入正式的开发阶段。由于时间短，我在周六早上主持了很短的kick-off，大致说明了项目情况，读了一遍优先级1的需求，就开始开发了。团队都是非常优秀的人，很容易就形成了自组织的团队。一开始所有的人都开始找BA问问题，有些手忙脚乱。好在过了启动这段后就好多了。

我和其他两位过来帮忙的BA一起，安装了只有ready, in dev, dev done, qa done四个状态的story wall在墙上。公司的推拉白板柜门很好用，需要用哪张墙就推过来，不用的就推走。一共占用了4张白板。Story Wall，流程Wall，界面流程Wall和Wiki Wall各一个。

因为大家采用Textmate，而并不是所有人都用过它，因此一开始team是用过的和没用过的pair，先熟悉工具。中午时候大家switch。

在开发阶段，我们整个团队做的比较好的地方有：
   1. 自组织的团队。真正实现了自组织。每个人都尽力将事情向好的方向推进。大家都尽职尽责的完成任务。
   2. 在开发优先级1需求的时候准备优先级3的A/C和优先级4-8的卡片，使我们不用在一开始就准备所有的功能。
   3. 采用活动墙壁做需求墙，team需要看什么就把那个移动过来近些。
   4. 开发团队频繁的轮换pair，可以收到很好的效果。从BA的角度可以很明显的感觉到哪个pair遇到了问题，从而协调team之间的取长补短。
   5. 和客户交流频繁，所有一开始由于时间关系无法确认的需求都交由现场客户Steven解答。中间根据进度，我们建议更改2和3级别优先级的顺序，客户也确认了这次更改的必要性，使得我们最终能够交付正确的产品。
   6. 一天两次的简短的standup。由于大家平时交流的充分，standup可退化成宣布值得大家知道、比较重要的事项的碰头会，如果没有事情说就不用说话。
   7. 简短的retrospective。自组织的团队不需要太多的反省。每一个人都是很好很有能力很有想法的成员，只要列出来我们发现的问题，大家会自觉的去解决。
   8. 从一开始就运行的test和build。很大程度上提高了团队的整合度。
   9. 8dev团队，一天95次的提交次数，一天18个migrate脚本，一天12张story卡的速度。

做的还不够好的地方或者改进的想法还有：
   1. 在开发之初的设立UI pair，在开发后期设立专门BUG pair的作用不可忽视
   2. 每天的switch pair还是做的不够多。我认为对于rails开发来说，理想情况2个小时就应该进行switch。更频繁的Switch能够使得知识传播的更快，尤其是在团队中不是所有人都对Rails开发熟悉的情况下。由于做的还不够好，出现了有的pair工作在一张卡上太多时间的情况，原因是俩人对这块都不够熟悉，如果早点switch就好了。
   3. 由于Rails开发中一些scaffold的存在，几个相关的CRUD的story可能一下子就全好了。这对写Story提出了更多的要求。要精确掌握粒度不太容易
   4. Rails和Textmate的中文支持还有待提高。看哪位神仙有空，给contribute一些plugin啦、月光宝盒什么的。

总之，如何更好的交流和协作是我们这次Code Jam学到的知识之一。Rails开发的效率极高，这对开发过程和开发团队就有了更多交流协作的要求。大家必须要通力协作：多提交和更新才能最快的把代码整合在一起；多交流才能保证不会有架构和数据迁移的冲突；多和BA/QA交流才能不走错路做错功能；多更换pair才能学到更多的技能技巧，保障对系统的了解程度；多和用户交流才能确保需求不会迷失方向。

周六晚上5点半showcase的时候，1优先级的功能差不多都出来了，可以大致预测到第二天的成果。可惜由于周日我下午又赶飞机，没能看到最后交付的场面，非常遗憾。

---

作者介绍
李默，ThoughtWorks公司咨询师、业务分析师，敏捷过程教练，BJUG(www.bjug.org)创始人之一。网名为“冰云”。目前主要专注于软件需求管理与市场营销的协作、产品交互设计、组织过程改进等方面的内容。