敏捷的反思

ke, 27 April 2020

[ agile  ]

敏捷

XP和scrum作为敏捷开发里面最重要的两种思想,相辅相成的发展了20多个年头。要了解这两种方式的本质,要先了解发明人。XP的发明人Kent Beck来自美国的软件工程师,TDD(测试驱动开发)的推崇者。在软件领域最出名的是他的Junit单元测试框架。Jeff Sutherland和Ken Schwaber共同发展了scrum的敏捷理念。Jeff Sutherland毕业于西点,11年的军旅生涯里面当了医生,随后涉及到IT领域. Ken Schwaber软件工程师,产品和工业的咨询。
在这里我们可以了解到Kect Beck更偏向于技术,所以在XP里面除了价值,原则外,更看重各种开发的实践。而scrum则更偏向于人,团队,流程。所以我们采用的敏捷一般是XP和scrum的混合方式。既有XP里面的开发实践,也有scrum的关于人,团队,流程的框架。这两种理念相辅相成,共同发展,形成了今天的敏捷。

小规模的敏捷

在90年代末期,没有现在的云计算,没有大数据,没有docker,k8s。受限于当时的软件技术和规模。XP和scrum在当时的环境下不管从价值观,原则和可以落地的工程实践,都比当时普遍采用的瀑布开发方式好上太多。在2000年后敏捷开发方式开始一步一步成为主流的开发方式。后来持续集成,持续交付,精益开发,用户故事地图,实例化需求的发展进一步加强了敏捷的各个部分。 在当时的背景下,采用组织架构的重新划分,架构得持续演进,就可以从component team,变化为feature team. 在feature team里面,team之间依赖少。所以一个个独立的团队自己采用XP和scrum方式进行持续改进。整个组织的交付效率和质量得益于不断提升的单个团队。
唯一的不变就是变化,这句话时刻提醒着我们。随着时间推移,软件的规模越来越大,SaaS,PaaS,大数据,中台化等技术和组织架构的变化。使得小而美的敏捷团队遇到了前所未有的挑战。

规模化的敏捷

软件规模变得越来越大后,遇到的首要问题是团队间需求的依赖问题。一个完整的具有用户价值的功能现在无法由一个团队完成。有时需求会横跨3,4个团队,甚至7,8个团队。团队间就像以前的component team一样依赖起来。整个开发的过程变得臃肿,反应变慢,反馈周期变长。这样敏捷团队的价值观和原则被现实打破。怎么才能短,快的交付有价值的需求,得到反馈,使敏捷的价值重现。所以后来出现了规模化敏捷的思考,就是基于现状找到可以解决的方法。不管从safe,还是less,或者Scrum@Scale,其实本质就是解决两个核心问题。
第一个问题就是:需求怎么对齐,其实也就是依赖团队间目标怎么对齐,怎么协同开发?
第二个问题就是:随着软件规模扩大,团队,团队人数怎么扩张?
针对第一个问题的本质是,如果无法解决团队间开发依赖问题,那么通过在依赖团队间建立统一的product backlog和统一迭代起止时间的方式进行缓解。统一的product backlog可以解决团队之间需求排序优先级的问题,再加上团队之间迭代的起止时间变得一致性,提升沟通,联调的效率,降低协作的成本。 针对第二个问题,还是考虑到团队人数开始变多,沟通渠道变宽,团队整体的透明性,沟通效率变差,团队变得迟缓。所以通过保持小而美的团队,通过一层层把小团队聚合起来,形成更大规模的团队群。上层团队之间的协作依靠团队代表成员(PO代表,scrum master代表,技术代表,测试代表等)进行沟通协作,来提升沟通效率。
当软件规模更大后,所有的规模化方法都是解决协作的问题,沟通效率问题,解决这类问题本身会产生更多的成本(相较于以前的小规模敏捷团队)
所以当组织达到一定规模化,进行敏捷的方式要进行相应的调整,根据每个组织的独特性一般有以下几点:

  1. 优先解决团队开发的依赖
  2. 通过统一product backlog
  3. 统一团队迭代进行依赖缓解(比如集中多个团队的sprint plan)
  4. scrum of scrums, scrum of scrums of scrums(或者其他方法用于同步团队间的进度)
  5. 集体团队回顾(持续改进团队依赖问题)
  6. 持续交付基础设施的完善

说了那么多,其实规模化敏捷也属于一直在探索的道路上,在这条遍布荆棘的道路上,一定要坚持敏捷的价值观和原则,找寻到适合自己组织和团队的方法。