一场“深刻的”大规模敏捷转型故事

此文讲述了一个经典的瀑布型软件开发团队向大规模敏捷转型的故事。如您有类似经历，这很可能不是巧合。

序幕：传统开发模式篇

话说很多年前，某软件公司招来上百位程序猿，需要共同开发一大型产品。领导们按照行业普遍惯例把他们分成了9个码农队，A/B/C码农队负责前端，D/E/F团队负责中间件，G/H/I团队负责后端。

9个产品施工队组建完成了，每个团队负责一个模块，程序猿们撸起袖子准备开码了。

这时候，领导拿起厚厚一叠产品需求文档，粗粗的分析了2个用户功能(customer centric feature)，发现每个功能都需要多个团队协作完成

用户功能和各个模块之间的依赖关系如下图：

第一场头脑风暴即将开始

问题1：这百来号程序猿谁可以来负责分析用户功能呢？

让写码的猿猿来分析好像不太合适，领导只好招几个商业分析员(Business Analyst)来干了。

BA到位，负责分析用户功能，搞成一个列表

问题2：这百来号程序猿谁可以来负责用户界面设计呢？

让猿猿来好像也不太合适，我们招个用户体验设计师(User eXperience)来干吧。

UX到位，负责设计用户界面。

现在功能列表有了，用户界面也有了，应该可以开始施工了吧？可是，这些功能都该交给哪些码农队伍去施工呢？这个问题好像没这么简单

第二场头脑风暴又开始了

问题3：商业分析狮️(BA)写的用户功能太具有商业气息(naive)，领导们担心程序猿们可能不太能理解。谁可以把它转换成猿猿们比较能理解的技术功能文档(professional)呢？

让猿猿们来分析好像又不太合适，我们再招两个技术分析狮️(TechnicalAnalyst)来干吧。

TA到位，负责写技术功能文档，好让程序猿们省点心，好理解点。

问题4：哪个码农队可以负责分析用户功能(customer centric feature)，分析哪个模块需要实现哪些接口的哪些功能呢？

让猿猿们来分析好像又不太合适，我们再招两个架构狮️(Architect)来干吧。

Architect到位，负责写架构文档，指出哪个施工队的哪个模块应该实现什么接口。

这回，码农队伍在新增的4个角色的帮助下，真的可以开始施工了。

刚撸代码不久新问题又来了，A/B/C团队的进度不一致，A依赖于B，B又依赖于C，A队干完都时候，不能测试，因为B还没交付，C队最慢，居然还没开始。等A/B/C都干完的时候都已经三个月过去了，领导们很抓狂

第三场头脑风暴即将上演

问题5：A/B/C哪个能端到端的负责用户功能的协调和发布工作呢？

无论让哪个团队来做好像都不合适，我们再招个发布经理(Release Manager)来干吧。

RM到位，专门负责协调功能的集成，测试和发布工作。

问题6：A/B/C哪个来负责端到端的测试工作呢？

这个简单，我们再招几个系统集成测试猿(System Tester)。

ST到位，专门负责端到端测试，经常需要和码农队扯皮。

问题7：领导想知道项目进展情况，找谁来负责呢？

这个小意思，再招个项目经理(Project Manager)。

PM到位，专门负责上下协调，尤其是向领导们汇报工作进展。

就这样，一个经典的瀑布型软件项目组织架构就有模有样了，领导们很满意。

。。。。。。

此处省略三千字（项目推迟交付，功能不完善，客户不满意）

。。。。。。

总之，领导们很生气，后果很严重。

“变革”：大规模敏捷转型篇

听说最近敏捷(agile)很流行，于是领导去听了场最近很火热的某大规模敏捷转型框架的演讲，决定大刀阔斧进行一场敏捷改革，并邀请某资深敏捷转型教练帮助落地工作。

这位转型教练给大家一番洗脑之后，提出了如下转型方案。

商业分析狮️(BA)

现在升级成产品负责人(Product Owner)

原来写用户功能分析，现在写大型用户故事(Epic)

架构狮️(Architect)

升级成敏捷构架狮️(Agile Architect)

原来写架构文档，现在写大型用户故事架构(Architectural Epic)

技术分析狮️(TechnicalAnalyst)

升级成产品技术负责人(Technical Product Owner)

原来写技术功能文档，现在写用户故事(User Story)

码农团队

升级成Scrum团队

原来码工，现在依旧，还额外多了好几个“大敏捷”会议（听说还要百来号人一起参加）。

发布经理(Release Manager)

现在改名叫DevOps，还额外多招了几个DevOps攻城狮️

原来搞发布协调，现在搞软件自动化装机，配置和发布工作。

系统集成测试(System Testing)

现在升级成敏捷测试狮️(Agile System Tester)

原来搞测试，现在依旧，频率比原来高了点，文档要求减了点。

项目经理(Project Manager)

现在升级成Scrum大神(Scrum Master)

原来负责汇报工作进展，现在多了个敏捷会议主持人的工作。

经过上面一番大规模的培训和角色转变，一场轰轰烈烈的大规模敏捷转型“成功”落地。

尾声：无用论篇

攻城狮们️依旧忙碌，相互之间一如既往的扯皮，会议比原来更多，用户功能的开发时间似乎没有缩短，客户似乎并不满意，敏捷无用论的质疑之火开始燎原。

领导们又开始寻思下一次变革。。。。。。