采纳敏捷：十三人组成的敏捷团队在两天内能做些什么呢？

十三人组成的敏捷团队在两天内能做些什么呢？

4月19日和20日，公司在北京office进行了一次“Code Jam”。这次Code Jam是一个迷你型的敏捷项目，其目标是为乡村教育促进会（一个国际非盈利性组织，致力于通过素质教育改善中国农村地区儿童的生活）开发一个内部资源共享平台，以便分布在三个省份（山西、安徽和山东）的教师可以通过网络分享他们的教学计划和教学方法，互相学习交流。

本次项目中，除一名客户以外，其他成员都来自Thoughtworks，共计十三名，其中部分人员并未全程参与。人员组成为四名分析人员（三名BA和一名QA）以及九名开发人员。此项目历时两天半，其中一名BA、一名QA和客户用半天时间一起讨论需求，而此时其他人员完全不知道要做什么。在随后的两天，客户与所有团队成员在一起工作，从零起点开始，共同开发项目，最终由客户对项目进行验收。

从团队角度来看，团队成员对所用的敏捷软件开发方法都很熟悉，了解每个敏捷实践的意义所在，并认同这些实践。尽管大多数人没在一起工作过，但也可算是磨合过的敏捷团队。而从项目角度来看，客户在与BA和QA共同讨论之前，对项目仅有大致的想法，并没有详细的需求说明，交付时间也仅为两天。

所以根据团队组成及项目的特点，团队决定采用改进后的敏捷开发方法，也应用了诸多的敏捷开发实践。
 

• 卡片墙：分析人员与客户交流的工具，用于分级用户故事和BUG。
• On-site 客户：客户与开发团队在一起，有需求不清等问题可随时讨论，并排定优先级。客户想到需求，可以随时写下故事卡片，放在适当的优先级上。当开发人员正在开发高优先级的故事时，分析人员与客户会详细讨论低优先级的故事，敲定Acceptance Criteria。
• 测试驱动的开发（TDD）：RubyOnRails特供了很好的框架和测试环境。
• 站立会议（Standup meeting）：由于时间只有两天，所以团队决定每天两次站立会议（每半天一次），增进团队的沟通交流。
• 回顾会议（Retrospective）：第二天开始时做一次，用时仅五分钟左右，只能算是迷你回顾会议。团队成员仅把Well done、Can do better以及suggestions写出来，大家通读后确定没有疑问就结束，没有常规的投票和讨论。理由是：相信大家都知道该如何做正确的事。
• 结对编程（Pair programming）：通过交换Partner来传递代码知识。很多成员在两天内换了三次Partner。
• 小步快跑：由于项目只有两天，功能交叉较多，所以只有重构和尽快提交代码，才能保证尽早发现冲突和问题。最后，该项目共计有192次checkin。
• 持续集成：使用CruiseControl.rb做为持续集成工具。频繁的提交势必通过某种自动化的手段来检测结果。
• Showcase：每天结束前，全部成员与客户坐在一起，做当天的Showcase，分析人员会将那些处于"QA passed"状态的用户故事展示给客户，客户也会试用这些功能。

假如这个项目是六天的时间，可能就会采用另一种改进的敏捷开发方法去做。

　　无论怎样，敏捷方法并不是一成不变的，不变的只有“敏捷思想”。关于这个“迷你”敏捷项目，你可以查看InfoQ中文站。