近日张小龙的内部演讲刷爆了朋友圈，他提到当人数超过150人的时候，就变成了社会化组织，如何保持高效沟通和紧密的人际关系，对任何组织来说都是很挑战的事。他也在反思随着团队规模的扩张，正在与敏捷渐行渐远。真的只有小团队才能敏捷吗？在敏捷圈有很多关于大规模敏捷实践的讨论，也有很多应用SAFe/LeSS或其他框架的成功案例，这些足以让我们相信，1500人的组织也可以很敏捷！
关于SAFe和LeSS的讨论已经很多，我这里只想分享一个类Spotify的轻型规模化敏捷治理方案。这套方案在我所服务的海外大型金融保险企业里被成功应用并取得了不错的效果。
1.组织架构
以实现端到端持续交付为目的而组成的实体团队：
部落（Tribe）、分队（Squad）
以专业领域技术分享为目的而组成的虚拟社区：
协会（Guild）、分会（Chapter）
Squad-分队
Squad是组织里最小的交付单元，是稳定和可持续的，5-9人组成的能够实现端到端交付的全功能团队。
一个Squad从forming到performing通常需要6-9个月时间，所以尽量保证Squad稳定，分配不同项目给稳定的Squad。
希望人人都有混合的T型技能。（目前实例化需求做的好的开发团队只有BA和Dev两种角色，BA写的Spec可自动转成测试用例，开发也可以做测试，不需要专职的QA。）
毫无疑问，团队要有端到端的交付能力。
坐在一起。（有时因成本考虑团队会分布在澳洲印度和中国三地，相比于co-located沟通效率会大打折扣）
和PO合作紧密。（PO由客户业务需求提供方担任，他能保证每天参加站会，及时回复团队的问题，参加各阶段计划会议，以减少上下文信息传递）
通过Guild,Chapter提升专业技能。
Squad度量指标：
团队满意度 （每个迭代结束打分）
客户满意度（每个迭代结束打分）
迭代速率，完成率
交付质量（遗漏到生产环境的bug数）
Squad级别的敏捷成熟度评估
Tribe-部落
有着共同目标和使命的若干个稳定持续的Squad的集合。
150人以内
有单独的feature, MVP backlog
有Chapter，以保证核心实践不走样
有派代表参加相应的Guild
有SoS（每周2-3次）以协调各Squad的资源和依赖
最小化Squad之间的依赖和handoffs
最小化和其他Tribe的handoffs
最小化地域分布
有敏捷领导力的leader很重要
Tribe的度量指标：
PO满意度
干系人满意度
目标达成率
Tribe级别的敏捷成熟度评估
为满足各个角色专业技能的提升和知识共享，推行最佳实践，敏捷组织里还需要按职能划分的虚拟社区，比如测试Chapter/Guild，开发Chapter/Guild，BA Chapter/Guild。
Chapter-分会分会
Tribe内部的虚拟社区，跨Squad
每1-2个迭代开一次会，话题包括（不限于）-
1. 编码规范，架构标准，设计规范
2. 讨论遇到的技术挑战
3. 提供解决问题的环境。和相关Guild建立连接，方便找到资源
4. 分享可复用的技术，避免重复工作
Guild-协会
企业级别的虚拟社区，跨Tribe
每2-3个迭代开一次会
需要在Guild内部选出Guild leader，负责组织会议
讨论编码规范，架构标准，设计规范等话题
2. 敏捷治理原则
治理不能通过控制，必须通过指导来达成；
建立以分会（Chapter）、协会（Guild）为组织的的高语境实践社区；
通过实践社区，保证组织遵循统一标准，并维护和开发标准，提升能力；
利用部落和部落组的产品演示，最大化交叉授粉，减少重复
古月，企业敏捷教练。CSP，CSM，PMP，国家二级心理咨询师，NLP执行师。
985院校工科硕士，12年知名外企工作经验。曾做过软件开发，自动化测试，项目管理，Scrum Master。2010年开始带领团队进行敏捷转型，曾辅导过多个团队，现辅导某海外大型金融保险企业200余人的离岸团队。
2013年开始学习心理学、焦点解决短期治疗技术、隐喻技术、及NLP初中阶；并一直致力于将现代心理学和后现代心理咨询技术应用于敏捷教练工作中。
