十三人组成的敏捷团队在两天内能做些什么呢?
无论怎样,敏捷方法并不是一成不变的,不变的只有“敏捷思想”。关于这个“迷你”敏捷项目,你可以查看 InfoQ中文站。
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中文站。