代码改变世界

如何增强Scrum Teams之间的协作(一)——Feature Team的优势

2010-05-18 21:35  菜阿彬  阅读(1925)  评论(1编辑  收藏  举报

  上海的两个Scrum Team,一个是专门开发新的模块的,另一个是maintenance team,专门负责Customer Issue 和Customer Enhancement。这样分工的初衷也许是为了有一个全勤的服务团队来应对紧急的Customer Issue,提高市场反应能力;而且由于两个Team各司其责,慢慢的都会对各自的领域更为熟悉,做起事情来也就更快更好。可惜从效果上来看,这显然陷入了“局部优化”(local optimization)的泥淖——短时间内提高了反应速度,长时间来看,其实拖累的整个项目组的输出能力。

  我想,更理想的划分Scrum Team的方式应该是两个对等的Team,都参加新模块的开发,同时也都会负责修Issue和小的Enhancement。也就是两个Team都是Feature Team

  比较一下这样的划分方式(Feature Team)与有专属maintenance  team的划分方式,前者的优势,也就是后者的劣势,如下:

  一,Customer Issue是最好的Feedback之一。Scrum或者Agile很讲究的是Feedback:2周的迭代、每天的Daily meeting、code review、Pair programming……等等实践后面隐藏的东西之一,就是通过Feedback来持续改进软件的质量。而有专属maintenance  team的划分方式,显然导致Customer Issue没有起到Feedback的作用,因为A Team写的新模块,发布出去后,提回来的Defect到了B Team,A Team丧失了一次反思的机会。

  二,前者的划分方式,促使每个Team都有机会衡量“修复一个Issue”与“交付一个新Feature”之间的优先级。把Customer Issue和new feature一起放到同一个backlog中,排列他们的优先级,这有助于两个Team作为一个整体,能交付出最有客户价值的东西。

  三,前者给团队更好的动力。相信很少有人会喜欢长期待在maintenance team,长久下去,容易造成该Team的成员士气低下。

  四,前者更能触发团队学习。由于两个Team都会参加新的模块的开发,相比对于原来待在maintenance team的成员来说,接触到的东西(包括业务知识,程序架构)更多了,因此学习就成了必须。

  五,前者会带来更好的代码和质量更高的设计。很简单,因为两个Team都会开发新的Feature,虽然他们所面对的需求领域会不一样,但是都会涉及到基础框架、基本控件和基础类。两个Team的代码将会有交互,A Team写的一个基类也许需要被B Team的人继承或重用,那么就促使A Team写出更好的代码,两个Team才能在代码层面更好的交流。

  六,前者减少浪费。用Lean的眼光来看,后者划分方式里,Customer Issue过多或过少的时期,将会产生maintenance team人员的过度使用或利用不全,这是浪费之一;另外,Customer Issue作为Feedback功能的丧失或延迟,这是浪费之二,因为Feedback周期越长,带来的浪费就越多。


  下一篇将介绍建立两个对等的Feature Team的挑战。