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

　　上文提到，对等的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等技术实践结合起来……我已经看到失败的例子。反过来想，这些挑战带来的是更多领域的持续的改进，对于一个有理想有道德，想做出好产品的公司或团队来说，又何乐不为呢？