这个随笔，基于一个简单的问题：由瀑布向敏捷转变后，组织结构要变，应用架构要变，为什么呢？
保持原来的组织结构，然后仅仅按照迭代的方式交付有什么问题吗？
瀑布模式形成职能部门或职能团队，职能部门通过交付物交接工作。至少会分成分析设计部门-开发部门-测试部门-运维部门。部门之间只需在交付物传递的时候做很少的沟通。这种方式非常的经济，保证了每个职能部门工作的内聚性，最大程度的减少了沟通的成本。
如果知识的传递没有变异，瀑布模型是最高效的交付模式。现实是，这个变异是巨大的，尽管我们有沟通管理的各种手段，最终还是无法避免鸡对鸭讲。解决这个问题，只能是最终结果的快速的反馈，只有做一点交付一点，然后增量的迭代。
这时，如果按照原来的职能部门结构，部门划分就会成为沟通壁垒，从而拖后腿影响敏捷小迭代频繁交付的目标实现。更好的方式是把交付流程中的原各个职能部门的人聚集在一起，在一起的一个意思是地理位置上靠近，另一个更重要的是要有相同的管理者——或者说属于同一个团队。
[图片上传失败...(image-49528f-1510282750572)]
那只是把原来的职能部门合并成一个大部门就可以吗？
当然不可以，一个大部门，每个职能都有多个人，而完成一件特性的交付，实际上只需要与一个职能部门中的一个或两个沟通，那到底与谁沟通呢，所以必须把全流程的各个职能部门需要联系的几个人串起来，组成一个小团队。
这就是所谓的特性团队了。这里说特性，就是某个产品的一个功能任务项集合。只有这种组织结构的变更，才能适应迭代的开发节奏，减少沟通浪费。当然，这也带来一些新问题。
- 一个产品对应多个特性团队，那整个产品的方向谁来把控？
- 各个特性会不会有重叠的部分？实现特性的代码会不会冲突？有冲突怎么办？
- 架构谁负责，似乎不应该是某个特性团队的职责哦？
- 一个产品对应一个代码库，多个特性团队，那谁对代码的质量负责？
显然必须有个 PO 负责整个产品的价值和方向，并且负责将产品增量拆分成特性。所谓拆分特性，就是最终拆分成一个特性团队可以在一个迭代内产生结果的需求小单元。至于个特性有多大，可以很大，也可以比较小。但是最终是要限制在一个特性团队在迭代内能有结果的粒度。
那需要再细粒度到个人吗？我觉得不需要，这个可以由团队的BA来完成分解。这里有一个矛盾，就是PO怎么能确定交给团队是合适的粒度——PO 将可能合适粒度的特性交给团队，特性团队必须再分析成更小具体到个人的粒度，然后总加，然后再反馈给PO。显然这个估算与沟通并不交付价值，是真正的协调成本。这也是Scrum 本身的缺点——没有实现交付粒度与迭代长度的解耦。
PO 负责把握产品的方向，那就解决了特性重叠的问题。那代码的冲突呢？这就必须要借助于持续集成，尽早的发现冲突问题。如果是必然的冲突则意味着特性的冲突——业务的矛盾，那就要 challenge PO 了。
架构谁来负责？先提另外一个问题，特性和组件的区别是啥，或者说特性团队和组件团队啥区别？定义良好的组件通常是恰当映射领域中的子域或者横切关注点(Cross-Functional feature)，它甚至可以看做一个独立的产品，因为它可以独立变化——当然在遵循Backwards Compatible, Open Close原则的前提下，直到确认所有依赖它的组件都已经不需要它对之前的某个版本兼容时，相应的代码才从系统中移除掉。
那负责这个组件的团队是不是可以视为理想的特性团队呢，不一定，决定因素是团队的人数。如果团队超过了十来个人，最好分裂成两个团队。每个团队都可以完成某个特性的从分析到交付的过程。
一个大的功能可能会跨越多个组件，那交付方式是同步各个组件团队的进度吗？不是的，各个组件要异步演进——不要相互等待——然后在一定时期演进，出现加剧的不平衡之后，再调整资源的分配。这样才最高效，但是异步演进带来一个问题，怎么保证各个组件能没有意外的集成在一起？
这就需要定义良好的接口，以及能够基于接口做独立测试的能力——也就是不应该依赖集成测试。这需要产品的PO 对各个组件的进度有清晰的了解。总结一下，大的组件可以视为独立的产品，组件和特性的关系可以视为产品与特性的关系。构成一个产品的组件要保持能够独立演进。
回到本来的问题，架构谁来负责？先定义一下，什么是好的架构？好的架构要解耦各个子域及各个横切关注点。也就是说把所有的子域和所有横切面都能够在实现上分离，都是可以异步演进的单元——组件。这样各个子域之间及与各个横切关注点之间的关系都视为两两关系来管理。
回到开始的问题，架构谁去做？在产品起始的时候可能由架构师做初步的设计，但在演进过程中，各个组件团队管理与其他组件的关系，架构最终表现为两两关系，各个组件可能需要融合、重组或分裂。目标是减少相互关系(依赖)的的数量。
接下来，谁对代码的质量负责？多个特性团队工作在同一片代码集合上的时候，这个问题必然会浮现。答案是，这往往暗示着代码库需要分拆分了，应该分离成更多的组件或者服务。而最终让每个组件或者代码库只有一个特性团队作为 owner。
这个说法看似有个矛盾，组件或者服务拆分不是领域驱动的吗，为啥变成了团队或者人员数量驱动的啦？这其实不矛盾，人员数量指示了需要再拆分，而划分的办法就是领域驱动。所以架构的本质是啥，是解决系统膨胀、人员增加、沟通成本增加的制约。如果业务范围扩大，或者解决方案不停膨胀，那就必须不停的演进架构。
所以特性团队最好就是一个组件团队，负责一个独立的代码库。最好各个组件能消除物理(artifact)依赖。那最理想的架构是什么呢？我猜你懂得。
