代码改变世界

如何增强Scrum Teams之间的协作(二)——Feature Team的挑战

2010-05-19 20:59  菜阿彬  阅读(897)  评论(2编辑  收藏  举报

  上文提到,对等的Feature Team,比有专属的Maintenance Team的划分方法更有优势,然而,天下无免费午餐,在废弃专属Maintenance Team,组建对等的Feature Team的过程中,也会有不少的挑战需要面对。

  一,需要团队成员有更广的技术知识和产品知识。尤其是对从Maintenance Team转移到Feature Team的成员来说,很可能需要加强对产品知识的学习。然而,相信没有人或公司会逃避这样的挑战。

  二,可能遇到非常难学的技术。学习不是件坏事,可是如果需要攻克比较艰深的技术时,该怎么办呢?简单偷懒的办法是当面对这样的难题时,让团队中高手去解决——不过这办法仍旧属于局部优化,因为这样的高手很容易成为瓶颈。对团队长期更有利的做法是:鼓励高手去coach, 而不是去do。

  三,写代码过程中对设计的共同职责。成立对等的Feature Team后,最显而易见的变化是团队之间的交流势必增多,它们除了很少面对同样的需求领域外,将很常见地面对软件的架构、类的设计和交互。对同样一个解决方案,说话的人多了,争执也多了,如何面对这种局面又不影响开发的进度,也就成了团队需要面对的新的挑战。Lean里的Last Resposibility Moment可资参考。

  四,需要对程序库有更多的并发访问。即使没有这样的挑战,也赶紧抛弃VSS吧,除非你的团队只有2个人。

  五,组织结构的挑战。在每个Feature Team中,都会有Developer、有QA(理想的Agile团队应该没有这么明确的划分,只分偏向测试的Developer和偏向开发的Developer)、有PO。大部分公司的组织架构都是:Developer们有自己的主管,QA们也有自己的主管,而两个主管往往不是同一个人。而如果Team里的每个人都向同一个人汇报,会增加不少效率。

  六,紧急Customer Issue的处理。如果紧急Customer Issue很多,而又没有了专属的Maintenance Team,我们的响应能力会不会让客户难以接受?如果有这样的现象,或者由于别的原因需要有专属的Maintenance Team,那么让每个Feature Team来轮流担当Maintenance Team,也许是不错的办法。

  七,代码的集成。每个Feature Team都在交付不同的Feature,代码的集成问题也许会凸显出来。解决办法很简单,CI(持续集成)和TDD。没有任何变革是可以单独进行的,如果没有配套的其他变革,很容易失败。就像Scrum,如果不和XP等技术实践结合起来……我已经看到失败的例子。反过来想,这些挑战带来的是更多领域的持续的改进,对于一个有理想有道德,想做出好产品的公司或团队来说,又何乐不为呢?