集体代码所有制。这是我自己非常喜欢的一个实践，尤其是在多团队的组织中。首先看一下它的好处。在一个团队中的好处毋庸置疑，在多个团队中的时候，只有集体代码所有制的情况下，不同的团队才可以真正按照product backlog里的优先级自上而下拿取任务。具体的说，比如product backlog里面前三个优先级最高的任务为A、B、C，但是这都是一个领域的需求，如果不是集体代码所有制，这几个需求的代码属于team one，那么在他不能一个迭代将其都完成的情况下，team two只能跳过C去做低优先级的任务。从组织的层面，没有集体代码所有制，关于价值交付的效益并不能完整发挥。在跨时区的多团队中，集体代码所有制的优势有其明显。因为时区的不同，不同的团队之间的沟通存在天然的限制，如果不是集体代码所有制，那么必然在涉及到别的团队的代码的时候，所需要的不必要沟通增加很多，再加上时区的限制，必然导致交付效益的下降。
如果没有人为代码负责，那么每个人都会表现的不负责任。正是因为有这种风险，我将共享代码列为扩展实践。这是极限编程一书中Kent Beck所说的一句话，我是比较认同的。对于团队和代码的责任感是需要培养的，并不是所有的团队、所有的组织在采用该实践的时候，这个前提天然就具备了，这太理想化了。现实是责任感需要培养，一个能提高效益的实践必然对团队提出更高的要求。或许是办公室政治的原因，通过代码的隔离打造部门墙；或许是集体这个概念让团队丢掉了聚焦的感受和责任感。所以在践行集体代码所有制的时候，要观察团队的现状，并循序渐进。
最后一个例子，来看下这个实践在实践中的采用和适应。本例子发生在诺基亚，北京一个团队和波兰一个团队都会修改一个领域的代码，开始的时候我们践行了集体代码所有制，工作方式如下：
可以看出来，这是很理想的一个状态。但是很快就遇到了问题，比如重构。虽然是代码集体所有制，但是波兰的团队是该部分代码的主力，他们想彻底重构该部分架构。但是在这个过程中，北京的团队会持续的提交代码到主干，给重构带来了极大的困扰。后来的工作模式修改成如下所示：
可见这是一个大打折扣的集体代码所有制了。但是在那个特定时期，是一个效率还可以的方式。后来重构结束，改变的前提消失了，北京的团队的感受越来越不好，因为交付的效率受到很大的影响，毕竟提交代码被其他团队控制。所以工作模式再次修改，如下图所示：
可见，这种模式又往理想的集体代码所有制上走了一步。北京的团队需要邀请波兰团队review代码，但是自己决定什么时候提交。
上述例子可见，集体代码所有制的实践并不是简单的理想化的使用即可，需要检视和适应，才能收获其在多团队中的效益。
自动化测试。自动化测试对于多团队的效益来说是一个影响因子非常大的实践。从某种方式而言，自动化测试用例是团队之间沟通的一个语言，不同团队之间要了解对方的工作内容的时候，阅读一下对方的自动化测试用例或许是一个好的开始，我们曾经有个实践就是不同的团队之间互相review code，要求有code change就需要有 case change，首先读的就是自动化测试用例，而不是代码。自动化测试也保证了多团队之间的协作可以是顺畅的，在有足够覆盖的、不同层面的自动化测试在CI中，团队之间的互相影响可以分钟级的得到反馈，从而发起团队之间的协作。当然技术实践往往不是孤立的，比如我们想利用自动化测试获得对于其他团队影响的分钟级的反馈，那么团队持续提交代码则是一个前置及时实践。
当然还有很多其他的实践对于多团队的效益有所帮助，他们很重要的特点除了本身可以提高团队内部的质量和效率，还可以帮助减少团队之间不必要的沟通（减少浪费），帮助获得更快的反馈（快速试错），从而获得更好的收益。
网友评论