规模化敏捷 Agile at scale

敏捷软件研发管理实践在10年前发起，现在基本上IT圈的朋友们都是耳熟能详，但是说到规模化敏捷，国内有经验的人不多，主要原因还是大型的软件研发集中在少数互联网公司以及少数的软件研发企业。

市场中关于规模化敏捷的方法论有这么几种SAFe, LeSS,DAD, 三种模式各有特点，
其中SAFe的覆盖面从战略投资portfolio, 到program management，到scrum team的覆盖最为全面，表现的最为严谨。核心就是以下三张图。

SAFe

投资组合管理 portfolio management

image.png

Program management

image.png

Scrum Team

image.png

LeSS

LeSS 方法里重点强调了当一个8~10人的团队个数超过8个的时候，就需要对业务领域进行拆分，每个团队尽可能对应一个独立的业务领域。

一个team的模式

image.png

多个team的模式

image.png

多个team的模式中，各个team还是可以共享代码库，通过持续集成处理代码之间的依赖，团队之间的沟通可以通过周期性的会议自发完成。

超过8个team的模式

image.png

超过8个团队的模式，需要根据业务场景进行划分。

值得一提的是微软的案例，微软是在2010年左右开始引入敏捷开发的理念，当时的试点小组是visual studio产品研发小组，受访人是管理5个10人左右研发团队的program manager Aaron Bjork。
在解决规模化敏捷 （Agile at Scale）的时候，他们的处理方式大致是这样：
代码库共享解决代码依赖；
通过5个团队共同持续集成的方式处理依赖；
Feature team；
团队之间的沟通自发组织；
program manager只关注program进度，不关注各个team的燃尽图，给团队最大的自主空间；

但是对于program之间如何沟通，如何sync，受访者只是提到了在14年的时候，他们的做法是每三个月program group之间进行信息的同步，同步的方式是，每个program team都有90分钟介绍自己的计划，每个team有15分钟的发言时间，通过这种方式来进行program之间的信息传递。

但是，令人遗憾的是，没有一种方式能够指出，在一个超过5_{8人团队（每个团队8}10人）的软件规模下，如何如何管理依赖的问题，这里所说的管理不光是沟通，而且是在项目进行过程中，如何对依赖进行快速的反馈。

敏捷方法之所以成功，是因为 build-quality-in, 通过自动化测试和CI手段对质量和依赖进行快速处理，特点就是这样的处理在一线工作者就可以完成，无需通过会议完成。因此技术支撑是敏捷实践的关键。这一点在规模化敏捷中也应该有所体现。

参考资料：
http://www.woshipm.com/pmd/969435.html
https://arstechnica.com/information-technology/2014/08/how-microsoft-dragged-its-development-practices-into-the-21st-century/4/
https://www.uperform.cn/less-agile-less-huge-large-scale-scrum-framework/