大型敏捷,请和你的大老师远离敏捷

随着敏捷开发的流行,近年来各种大型、规模化敏捷框架、敏捷组织设计、业务敏捷也称为大老师们口中的热词,也带来了很多讨论甚至质疑。本文根据笔者Jacky Shen在2019上海和北京敏捷之旅发表演讲所整理。

笔者认为,敏捷的核心是“小而美”,追求“大而全”非常危险而且也达不到敏捷的目标,即“早+准”,在不确定环境中快速反馈来命中商业愿景,提升竞争力。

本文分为以下三个部分:

  • 从敏捷到”大型敏捷”
  • 骨感现实中的复杂性
  • 变革管理及一些原则

一、从敏捷到”大型敏捷”

1.1 回顾敏捷Agile这个词

2001年17位软件行业先驱在美国雪鸟镇聚会,石破天惊地提出了《敏捷开发宣言》,当时的主要关注点包括:

  • 追求响应力与灵活性,即适应性over预测性 (不是单纯地求快,也不是要压榨产能)
  • 以人为本(一群“艺术”家),而非用流程来管控(流水线工人)
  • 提升客户和团队满意度

然而现实中,人们对”敏捷”还有其他期望:

  • “抄竞品抄得快” — (敏捷不见得能帮你少花时间,只让你知道该干嘛)
  • “明年少招点人” — (敏捷不见得提高产能,只是增加了可管理性)
  • “按时上线” — (敏捷不见得确保时间,只是摧毁不切实际的幻想)

笔者认为,我们平时书本和课程谈的各种敏捷方法论、框架实践集,都在描述一种“理想的未来状态”,但是很难说如何在特定组织中能够达到那种状态,所以与敏捷转型(变革管理)是两码事。

1.2 大型敏捷、规模化的意图

  • 某个项目或产品确实需要多于9人(多团队)以上共同完成开发(也有人叫多团队敏捷)
  • 不仅仅是开发部门,而是全IT流程参与,包括需求部门、测试部门、运维部门等(敏捷开发本来就是提倡这样)
  • 不仅仅是IT敏捷,让公司业务、市场部门也参与,更加灵活地响应市场变化,提升业绩 (也有人叫业务敏捷)
  • 不仅仅是单个项目or产品团队,希望其他项目组、部门、业务线全都用起来敏捷模式 (也有人叫组织级敏捷)

然而,大部分公司称不上大型开发:因为通常某个产品组也就10来个人,比较独立。但:

  • 产品开发组之间可能存在技术依赖或使用了共享的模块
  • 不同编程语言、技术栈、中间件、遗留系统、烂代码、耦合、依赖、存储过程、古老的编程语言
  • (由于采购不同供应商导致)技术栈过于分散,人员相互学习交叉工作存在学习投入不足,或者身份差异不允许交叉学习

1.3 大型敏捷框架概览

目前市面上常见大型敏捷框架和方法论一般来说会提到:LeSS, SAFe, DAD, Nexus, Spotify, Scrum@Scale等。我们来看一个有代表性的,适合重型企业的大型敏捷框架 LAFABLE,是Mike Cohn提出的,最新为5.0版本。

怎么样,看到什么问题了吗?

矩阵式的结构中,更多的团队待办列表造成局部优化,似乎产出很高,但是丢了全局优先级视角,很可能延迟了反馈和客户价值,SOS也变成了项目经理的汇报会。诸多新角色,造成更多组织官僚,说白了,监工的中间商比干活儿的人还多,这能敏捷起来吗?

这个框架正如被某些咨询公司推崇的SAFe框架一样(巧合的是,它也推出了5.0)。SAFe的开发价值流(定义、构建、测试、发布)及其ART ,就是多个瀑布式的项目。组织结构的现状里面,一定已经存在类似的结构,相关但不一定在同地的多个部门或团队为同一个产品领域而工作。即ART设计并没引发什么变化,而敏捷的关键在于解耦后重组资源,这才是难点,激进的Craig Larman甚至说“close some sites”(关掉一些城市的办公室)。

SAFe还是以交付视角为主,产品负责人和客户代表被放在了边缘的一角里面,这样是无法牵动业务一起转型的。SAFe的人力绩效那部分建议中,持续反馈是的说法是可以,但源自Attlansian的高底薪是不合经济规律的,高底薪只有行业头部公司才给的出,而且在经济下行周期也难以维系。

1.4 “SAFe is just another RUP” — Ken Schwaber

笔者曾经觉得大而全的SAFe框架,能让一些既得利益者能看到好处然后支持变革,是好事。然而,因为资源利益交换摆不上台面的,所以框架能说出来利益对齐都不是真利益。企业级变革都是老板工程,帝王之术自古有之。可能就是换几个诸侯的事情,别说底下没执行力,老板搞不定诸侯们就是改朝换代。

企业级的、原则指导性的框架,如果进化速度过快可能是因为没想明白,或者故意堆砌热词。企业级转型没个2-3年是不会有很大变化的。

该框架底层是Scrum实践为主,其他没看到任何“个体与交互、适应性”的内容,框架的中层及以上就是瀑布大版本规划(10周),更像一个大项目。核心反馈机制弱。没考虑上线以后的维护机制,缺乏人的互动,没有持续需求分析也没有持续改进机制,追求“高大全”,违背敏捷原则#10也违背精益思想。

更别提100人规模的PI Planning大会会议效率低,参与和理解的效果差。(如果只是在启动时开一次可以接受)

相反,敏捷结构追求的是“小团队、自组织、跨职能”,从客户和产品视角拆分、解耦backlog,打破职能孤岛,计划上留有buffer和planB应对变化,机制上允许甩掉包袱,强调透明性及DoD,尽早尽少地做事是关键,追求可持续的快速反馈

美国国防部2019年11月一份报告中指出,非常反对使用诸如SAFe这类“死板、预定义的框架”,因为造成在(某飞行器项目)“研发中过晚地发现多种依赖”,而我们知道,依赖是巨大的风险。

自SAFe打着“规模化敏捷”旗号诞生起,一方面迎合了一些商业利益,各种恰烂饭的“大老师”鼓吹“大敏捷”,使客户组织愈加不敏捷。另一方面,质疑声一直不断。不论是知名敏捷人士,还是发起敏捷宣言的17个人都公开发文反对SAFe。包括Martin Fowler、Dave Snowden、Steve Denning、Marty Cagan、Ken Schwaber、Mike Cohn、Mike Beedle、Ron Jeffries、Dave Thomas等。Martin Fowler甚至公开说:“SAFe=shitty agile for enterprise” (屎一样的企业级敏捷)!

另一个小道消息讲,由于Dean在早期出版的敏捷类书籍中引用了大量他人和社区贡献的文章,但不进行明显的引用说明(欧美很看重这种credit),使得其他敏捷人士心里也不是很愉快,不愿意与Dean来往。

1.5 为什么规模化扩展不是个好主意

  • 产品和创意由小团队协作出来
  • 沟通路径和开销大
  • 全生命周期的总成本(TCO),例如依赖、集成等风险容易后移,导致变更成本高
  • 局部优化易于全局优化
  • 传统组织设计带来了不必要复杂性的幻觉
  • 流程补丁打补丁,但极少去掉补丁
  • 更多层级使团队远离客户
  • 人数过多阻碍了实验性过程之快速反馈

1.6 扩展效率 vs.扩展适应力

左图是传统的层级结构,强调自上而下的命令与控制,讲究去扩展执行效率和资源利用率。右边是数字化和敏捷转型大潮中,为了适应变化的环境,《赋能》书中及Scrum of Scrum描述的更多是去中心化、跨职能、自组织的团队。国内有一个企业案例,就是青岛海尔的“人单合一”组织形式,国外著名的Spotify案例,都是讲究去扩展适应力。

二、骨感现实中的复杂性

失控不可怕,因为混乱是通向新秩序的阶梯;
看似有序和坚固,才是脆弱和混乱的温床。

2.1 上层管理者关注资源分配

越往上的企业管理者,终极关注点必然是“生存永续”。

笔者曾给某跨国企业进行敏捷转型咨询辅导,总部在国外,国内多个城市的研发中心。进去时发现,一个功能特性因为历史原因,被切分的很碎,不同地点的不同团队相互依赖和等待严重。这样的大型组织很难获得快速反馈。

我们帮助管理者描绘了资源/组件分布的现状,使总部的高层领导看清了局面。一段时间后,高层领导下决心关闭了某个城市的办公室(对那里员工来说,被裁员并不开心),重新进行了资源分配和整合,这次组织变革有力推动了整体的敏捷性提升。

2.2 跨地域团队的争宠

要理解跨地域交付团队管理者的“欺上瞒下”,背后是一番好意在为自己团队争得更多发展机会。

纵观历史,总部的“帝王之术”其实是另一个维度的“敏捷性”。古代统治者就是要多生孩子,优胜劣汰,东边不亮西边亮的意思。这种业务敏捷确实是全局优化,但敏捷性不是通过主动加速反馈获得的,也不是通过模块化组合获得的。而对于单个“孩子”来说,难免会局部优化,看紧自己的一亩三分地。

但如果各区域分家独立运作、解耦,争宠情况就可以得到改善。类似“藩王”,这要看上层的智慧和授权了。

2.3 财大气粗(需求方向的决策权)

决策权混乱是敏捷转型难以深入的一个常见原因,用Scrum的话来说,谁做PO呢?通常取决于谁出钱,谁控制时间表。

那么研发费用谁出?以下以银行为例讨论:

  • 一类是业务部门不直接承担研发费用,技术部门的成本由银行列支

  • 另一类是业务部门承担研发费用,技术部门的项目都由业务部门计价后发起,或者研发完成后对成本内部计价分摊到业务部门。

但是,业务部门不代表企业的整体利益(以银行业为例)

  • 一是国家对银行的技术有严格监管,如服务连续性、信息安全、基础设施建设等等,专业性极强,很难把这些职责交给业务部门去承担;
  • 二是银行的业务部门众多,难免受制于本部门的考核指标、短期利益,提出的很多需求连客户都代表不了,更无法代表银行的整体利益;
  • 三是业务部门由一个个具体的人构成,难免受制于个人的能力和格局,提出的低价值甚至无价值需求比比皆是。

2.4 其他现象

  • 紧急、常规版本怎么设置?开发过程怎么管,要不要版本经理?
    • 但不是说给原来的职位角色都安上一个“敏捷”的帽子
  • 度量报告及对外宣传怎么写?
  • 隶属多供应商的外包人员怎么管理?
  • 外包合同怎么签?
  • 绩效怎么打?

2.5 大型(多团队)开发动态浮现出的靠谱实践

笔者在诺基亚西门子通信工作期间,亲历LeSS框架的生长过程,单个产品线的单个版本涉及数百人协作。这些不是顶层设计出来的,而是慢慢浮现生长的,例如:

  • SCM 分支策略:同时存在多达10几个客户/版本分支而非特性分支,某一个变更需要明确哪些分支才能修改
  • 线上缺陷的路由者:需要有人进行初步筛选分配到合适的产品线或团队
  • 共享模块的负责人/PR Reviewer: 保证多团队修改的代码质量、内部开源模式
  • 多级CI:缩短验证和反馈时间
  • 虚拟架构团队或Cross-functional team:最好的架构出自于自组织团队
  • 组织级障碍清单Impediment Backlog:汇总组织级障碍,拉通解决共同问题,深化变革(不要妄想套用一个静态的组织结构图)
  • 内部敏捷社区:分享、传播、成长
  • 大型遗留系统必须逐步补自动化测试和重构改造
  • 绩效考评中更多增加团队的权重

2.6 越简单,越有效

敏捷原则#10:简明扼要,去掉不必要的工作,是敏捷的本质。

《道德经》曰:“大成若缺”。(数学家)哥德尔的不完备性定理:“无矛盾”和“完备”是不能同时满足的,既完美又统一是不存在的!

再看看SAFe之类大型敏捷,总是想“高大全”,把事情越搞越复杂,经不起实战检验,适得其反。能落地的一定是简单易懂,如果读者的产品确实涉及多团队协作,笔者个人比较推崇LeSS框架。

三、变革管理及一些原则

3.1 变革管理 vs.敏捷方法论

这是两个维度的事情。大家要的不仅是框架,还有咨询和转型路线图(How to do)

  • 组织结构应该是动态的,守破离,不是卖一张Spotify结构图的事情
    • 现状-中短期目标状态(如Scrum)-中期目标状态(多团队敏捷)-长期目标(基于原则生长,因地制宜)
  • 转型路线图在其他类咨询内也能找到(如:人力资源转型、IPD导入)且差不多的
    • 通常先培训和评估,然后小范围试点,接下来分批铺开
    • 任何变革的关键是上层支持,获得权力来移除障碍,也涉及绩效考核的调整
    • 所以变革转型路线图并非敏捷框架图的一部分,而只是咨询解决方案的一部分

3.2 从转型推进者的角度思考

  • 打包服务方案让人安心
  • kotter 8步法
    • 第一步紧迫感最重要,评估现状类似X光扫描,挖掘动力
    • 拿到尚方宝剑
    • 透明化工作和问题,并进行优先级排序
  • 考虑奶酪分配
  • 考虑如何表明(度量)进展和成效

3.3 妥协程度

作为方法论,既然定义的是一个未来理想状态,那就不要太妥协,因为标准(框架和实践)定为100分,现实中能做到60分就不错了。但如果标准(框架和实践)一开始就妥协为60分,现实中能做到20分就不错了。

另一方面,标准要高不能妥协,但实施路线图可以妥协和分阶段。咨询和转型范围不只是一个小系统,而是“整体”,整体意味着80%达标。一般用成熟度模型评估现状,应该包括:教学大纲和考卷两部分,每一级应能独立存在,有可见效果,才能锁定收益。

3.4 商业(研发)组织的共性问题

无论什么敏捷实践或框架,无非是通过建设四大能力域来解决组织的三大问题:

  • 三大问题
    • 决策
    • 协作
    • 能力
  • 四大能力域
    • 需求管理
    • 项目管理
    • 版本管理
    • 质量管理

但敏捷实践的做法与CMMI/瀑布/PMP却是截然不同的,不要被夸夸奇谈的大老师蒙蔽了。尤其那些好处CMMI、敏捷、DevOps通吃的,下次遇到他就说“talk is cheap, show me the code”,写几把代码看看再说。

3.5 基于敏捷原则的Scaling

  • 从一开始就要改变结构 (如定义Scrum角色,开发测试人员坐在一个团队中等)
    • 组织结构以产品(客户价值)为中心进行调整
    • 业务要买账,有动力深度采用
    • 预算和绩效考核调整方向为鼓励相互支持与合作
  • 解耦成小单元,加速信息流动和决策
  • 规模化的关键就是“去规模化”
    • LeSS is More, 组织设计也像我们做的产品一样以少为多,简单是敏捷的本质
  • 扁平化组织结构,减少信息流动的中间商
    • 闭环思维,快速反馈
    • 流程有增也要有减
  • 培养人
  • 管理者先自我觉察,再以身作则,然后授权放手
  • 持续集成CI,必须有!(而持续交付/DevOps却可以晚一点引入)
  • 尽量小地引入变化(如仅少数团队从Scrum和一些XP实践开始)
  • 先用Vertical方式来扩展,PO越少排序越容易。这种扩展方式从干系人角度看还是一个团队,如LeSS引入的Requirement Area
    • (而Horizontal方式会引入更大的复杂度与成本。这种扩展方式从干系人角度看是多个团队,如SAFe引入的Program Level )
  • 以更灵活的方式签署外包合同

3.6 区分组织面对的是复杂问题还是繁杂问题?

参考Cynefin框架,很多问题实际上70年代的精益所要解决的问题,而还未到敏捷的范畴:

  • 譬如加速财务流程,且要考虑低级错误、人为因素、场外因素
  • 譬如团队要解决的只是基本项目管理和交付技能问题,连“瀑布”水平都还远未到达

敏捷的本意是从繁冗的流程与工具中解脱出来,以人为本。可以说是从正规军到特种兵的转变,但是现实中一些团队,不在于规模大小,还处在凭本能做事的起义军水平。在这种情况下,可能先要建立基本的能力和流程,或许瀑布什么的也不错呢。

起义军 正规军 特种兵
本能驱动开发 流程驱动开发 互动驱动开发

3.7 关键:Product Owner/业务需求方是火车头

将熊熊一窝。PO/需求方是决定方向的掌舵人,方向和决策有误,不会有好的成果,所有支持的人员和实践都是空谈

  • 传统业务组织的需求方强势却说不清楚,IT团队理解分析能力不足却试图一次弄清楚,沟通链条长,再加上多部门决策不明,忽视产品经理/产品负责人培养产品的ownership(所有权与担当)缺失
  • 各部门缺乏一致的战略目标和产品定义,所以只能依靠项目经理协调和推动,但是各方或许都藏着留一手

3.8 关键:需求澄清是头号问题,然后是工程能力

现实中,大部分团队还是要解决的是业务说明白,程序听明白的情况,需求澄清、缩短沟通链条的问题就已经不错了,即40年前精益思想所要解决的问题。

  • 需求分析的方法沿用传统的SRS有耗时过长,阅读困难,覆盖不全等问题。从源头降低了整体工程的效率。
  • 采用PRD的方法,去掉各种必要信息,只有原型加简单描述,把问题传递给下游,导致开发过程中反复确认,降低效率。
  • 需求分析的读者有若干种,但是去只通过一种文档试图让所有人获取自己想要的信息。
  • 缺少图形化的表达,通过大量文字,掩盖重要信息,增加理解困难。根源原因是大家惧怕画图。然而一图胜千言。

而TDD/重构等敏捷实践是非常好的,然而在上述主要矛盾解决之前,工程实践并未让人直接感受到收益,也难怪推行不畅了

3.9 关键:敏捷合同(外包开发供应商合作)

  • 多供应商服务于多部门合作,需要由PO来牵头主导统一管理
  • 敏捷合同形式:
    • 包项目 Fixed Scope, Fixed Price
    • 包人头,(带有奖惩的)T&M
    • (例如以UCP计)单位工作固定价格
    • 包人头,(带有预算上限的)T&M
    • 共享损益的目标成本合同

3.10 关键:教练式领导力、文化、软技能

转型的边界就是管理者的理念、认识模式、习惯模式等等。面对新时代新形势,管理者的认知必须升级,教练式领导力可以了解一下。

专业教练通常会利用三个对齐:认知、利益、情感来帮助团队和组织心往一处想。别光谈利益,也别不谈利益。

管理者请永远记得”培养人”,这是长远的效益。

四、参考资料

  1. 常见大型敏捷框架和方法论比较: https://www.slideshare.net/BerndSchiffer/comparing-ways-to-scale-agile-at-agile-product-and-project-manager-meetup
  2. LAFABLE框架: http://www.lafable.com/,中文版:https://www.jackyshen.com/lafable-cn/
  3. 美国国防部2018-2019关于某空军项目失败的调查报告,由USAF首席软件官Nicolas Chaillian签发:https://software.af.mil/dsop/documents/
  4. 敏捷宣言17君子和其他敏捷知名人士公开反对SAFe文章合集:https://mp.weixin.qq.com/s/V-PojzupohQvI7NnAfhUHw,以及https://www.linkedin.com/pulse/safe-lean-agile-modern-management-theory-luca-minudel/
  5. 招商银行的技术业务关系思考,by 夏雷 https://mp.weixin.qq.com/s/9g8WOmNNXQiexTOGJHHMag
  6. 演讲《开思基于LeSS框架的敏捷组织规模化设计与思考》,by 曾庄俊、申健
  7. 系统性团队教练。曌乾组织教练、ICF国际专业教练、系统性团队教练。
  8. 《真正提升软件团队能力的方法,唯有极限编程》, by 熊节 https://mp.weixin.qq.com/s/2iC-MkFnTmymqoVhPExgqw
  9. 《你的Scrum够精益吗?》,by 申健 https://www.jackyshen.com/2017/08/02/is-your-Scrum-lean-enough/
  10. 需求分析工具箱 by 王洪亮 https://mp.weixin.qq.com/s/b7BboFQt9nNMO7vTGfTYdg
  11. TDD练功房 by 熊节 https://mp.weixin.qq.com/s/2w4tvsr5sK8_3Z6eeppWBQ
  12. 中国软件匠艺小组 by 李小波 https://codingstyle.cn
  13. 《甲乙方敏捷合同怎么签》,https://www.uperform.cn/agile-contract/
  14. 《敏捷合同》by Bas Vodde & Craig Larman, LeSS框架创始人, https://www.uperform.cn/introduction-to-agile-contracts-1/
  15. CCSTC商业应用学习发展项目,by 周冰
  16. 《技术团队管理者的软技能》,by 申健 https://www.jackyshen.com/2016/05/04/soft-skills-of-technical-leaders-and-managers
  17. 《Clean Agile》by Uncle Bob,敏捷宣言发起人之一,中文版将于2020年出版。
  18. 《做一些不必规模化的事情》by Paul Graham,Y Combinator孵化器创始人、《黑客与画家》作者,http://paulgraham.com/ds.html
  19. 《为什么用了Scrum但你的组织却还不敏捷?》Michael James,敏捷教练,《Scrum Master Checklist》作者,https://v.qq.com/x/page/t3024y3caup.html
  20. 《大规模Scrum》, by Bas Vodde & Craig Larman, LeSS框架创始人,《敏捷合同》作者
  21. 《赋能》(Team of teams),by Stanley McChrystal
  22. 敏捷精益平衡轮(成熟度模型):https://www.uperform.cn/lean-agile-balanced-wheel/

觉得本文有帮助,长按二维码进行微信打赏