如何管理大型软件团队
对于大型软件研发团队，一个最困扰的问题就是项目维护到后期变成“屎山”，修复错误、响应新需求的能力断崖下降，模块功能严重耦合而缺乏设计上的一致性。
造成这些问题的原因很多，今天我希望从以下三点来讨论一下：
- 如何组成优秀的团队
- 如何保证系统概念的完整性
- 如何降低团队成员的信息差
外科手术式团队
因为一些意想不到的交互会产生许多不易察觉的 bug，测试工作将非常耗时，因此相同的功能的系统组件，成本至少是独立程序的三倍。 —— 《人月神话》
一个系统，是否容易维护，取决于：
- 技术架构设计的耦合程度
- 交互设计的复杂性
- 软件团队内部的沟通成本
《人月神话》作者提出，当一个软件系统足够庞大，就需要更多人力的投入，但是人力投入又会导致内部沟通成本和设计的复杂性急剧上升。因此作者建议软件团队不应将不同模块拆分给不同团队和个人负责，而是应该组成一个少数资深成员和辅助成员构成的“外科手术式“的团队。下图是《人月神话》作者提到的一些角色。
虽然这本书出版了将近 50 年，但是对软件开发领域来说，其核心思想几乎没有过时。敏捷开发团队的人员也几乎是按照图中的人员构成来设计的。（我用不同颜色对应标记了不同角色在敏捷开发团队中的角色，其中部分角色已经被自动化工具取代）
系统概念的完整性
系统概念的完整性决定了使用的容易程度。不能与系统基本概念进行整合的想法和特性，最好放在一边，不予考虑。如果出现很多重要但是不兼容的构想，就应该抛弃原来的设计，对不同的概念进行合并，在合并后的系统上重新开始。
然而不幸的是，大部分软件团队，并不重视“系统的完整性”，将任务垂直拆分成彼此不关联的小任务派发给不同的责任人并行开发，进而造成系统各部分的不一致。
另一方面，一些团队追求狭隘的“民主设计”（亦作“委员会设计”），而忽视软件开发本质是强经验依赖的“师徒模式”的事实，造成团队内部决策成本升高，无法快速收敛问题（这种问题通常由于非技术管理者出于风险考虑，在无法深入日常开发工作细节的情况下，希望掌控团队进度和控制风险，亦或是对技术负责人能力的不信任等原因，采用“民主”的形式做技术决策，从而减少自身和其他成员的信息差）。
最后一种反面经验，就是由于内外部环境的变化，导致团队 Senior 以上人员流失，管理层出于无知或是不得已，将设计能力平庸，但是老黄牛式的、掌握了信息差的“老人”提拔成主力开发。而新的设计出于能力或是其他原因，无法与原有系统设计保持一致。
如何减少团队的信息差
最近听人说：“敏捷不是目的，敏捷是一种手段”。这是完全错误的，敏捷是一个团队的文化，敏捷是目的，不是手段，为了让团队达到敏捷的心流状态（专注问题；快速收敛分歧；最少交流成本）。
个人观点，减少团队分歧、降低成员之间认知差距的根本方向，是消灭知识的私有制：
- 用集体 code review 消灭技术知识私有制
- 通过估点、拆分 story 和 AC，避免团队出现 key person 掌握过多的业务上下文，消灭业务知识私有制
- CI/CD 和自动化测试，消灭运维知识私有制
- 通过迭代计划、retrospective 等流程消灭管理知识私有制
但是要注意的是，消灭知识的私有制并不代表要做集体决策，好的团队要在信息透明，人人可以自由获取信息的基础上，更好地理解技术负责人（首席程序员）的决策，负责人也要随时将判断的依据分享给团队成员，听取他人建议。团队协作不是下注押大小的赌博，任何决策都要随时调整和变化，所以敏捷开发团队最重要的并不是决定要做什么，而是要能够随时响应变化，随时调整方向的能力。