上海的两个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的挑战。