图片

「守望者」第一期《敏捷站会九大坑》正式发布,本公众号回复“守望者”可下载电子书。

本文内容来源:「守望者」第一期《敏捷站会九大坑》引言《谁动了你的“敏捷”》

你们的敏捷试点彻底失败了,大家对敏捷的价值充满了怀疑;

你们热火朝天地敏捷了半年,业务部门依然认为你们没有敏捷;

在你们公司,老板把敏捷当做了一个让大家加班的手段;

多个敏捷小组互相依赖,互相甩锅,内卷严重;

人越招越多,但效率越来越低,原来的密切协作氛围再也找不到了;

你们的站会没有任何价值,大家每天都是在行尸走肉;

大家认为敏捷就是开会,浪费了大量的时间;

计划会开了半天,做了一个大家都不认可的计划;

每天忙于救火,在Bug中找Bug,每天都加班,大家疲劳不堪;

你们的持续集成红灯了,好久没人修复,也没人关心;

需求优先级不断调整,相互冲突,一天一个说法;

你们也在不断地总结回顾,但是问题依然还是很多;

你们搭建起了工具链,强迫大家使用,但敏捷还是老样子;

你们花大价钱请了咨询团队,他们一走,你们立刻就回到了老路;

……

对此,是否你也心有戚戚焉?

你抱怨!

你困惑!

你迷茫!

你失望!

图片

谁动了你的“敏捷”?

也许你自己说不清,也许你更期待高人给你指点迷津,或许,我们可以先回顾一下敏捷的发展简史,从敏捷先哲们的探索之路中或许可以找到答案。

寻找银弹

1967年,Conway 在《How Do Committees Invent?》中提出了康威定律(Conway’s Law),他认为”设计系统的架构受制于产生这些设计的组织的沟通结构”。反过来理解就是“如果系统架构不支持,你无法建立一个高效的组织。”这个定律成为后来划分敏捷协同团队及产品架构设计的重要理论依据。

1970年, Winston Royce 的著作《Managing the Development of Large Software Systems》发表,瀑布式开发方式第一次被正式提出。Royce从此也被称为“瀑布之父”,成为大家口诛笔伐的对象,但其实他比较冤,他建议的其实是do it twice,一个两次瀑布的迭代模型,如下图的那行英文小字。(原文可见https://wenku.baidu.com/view/128cc117844769eae009ed7e.html)

1974年,E.A.Edmods发表论文介绍自适应性软件开发(ASD),提倡拥抱变化,通过协作和学习来应对复杂系统。

图片

1975年,Fred Brooks 提出“没有银弹No Silver Bullet”,出版《人月神话》,相关问题与理念激发起软件行业从业者对轻量级方法的探索。他提出的“Brooks定律”,即“投入更多的人到一项延迟的工作上,可以导致该项工作更加延迟!”虽然很多人认同这一点,但依然抑制不住往落后项目加人的冲动。直到后来,动态系统开发方法(DSDM)提出了敏捷倒三角形,强调有限时间、有限资源,只做有限需求,方才有所缓解。

图片

1976年,Glenford Myers的著作《软件可靠性(Software Reliability)》出版,其中阐述了一条“公理”——“不应该由开发者来测试自己的代码”,这意味着需要多个角色协作才能保证质量,这跟后期的“全面质量管理”运动不谋而合。

1980年,在Harlan Mills主编的文集中进行了关于增量开发的实质性讨论。在Dyer的文章中明确指出“软件工程的原则是,每个迭代完成的功能要尽可能地与其他迭代解耦。”

1980年,源于丰田生产系统的“可视化控制(visual control)”概念,是 “信息辐射器(information radiators)”的最早概念,现在我们讲“基本经验的过程控制”的三大支柱——“透明、检视、调整”,其实都跟可视化直接关联。

1984年,随着对“瀑布”顺序式方法的批判,作为替代物的“增量方法”变得越来越突出。一个很好的例子是,早期在《软件工程中基于知识的沟通过程》上一篇文章倡导使用增量开发,具体原因是“不存在完整和稳定的需求规格”。

1985年,Tom Gilb提出了首个有明确命名的、用于替代“瀑布”的增量开发方法——进化交付模型(Evolutionary Delivery Model),绰号是“进化(Evo)”。

1986年,Barry Boehm提出了“软件开发和优化的螺旋模型”,提倡通过合适的方法(尽管展示的“典型”例子是基于原型,但不仅限于原型法)来识别和减少风险。

1986年,竹内弘高和野中郁次郎在《哈佛商业评论》发表了他们的文章《新新产品开发游戏(The New New Product Development Game)》。这篇文章描述了一种类似橄榄球球队工作模式的方法, “产品开发过程是在一个精心挑选的多学科团队的持续互动中产生的,团队成员从头到尾都在一起工作”,“ 这种团队自我组织,自我管理,有能力决定如何开展工作,并获得了根据自己决定做事的授权”。这篇文章经常被引用为Scrum框架的灵感来源。

图片

1987年,Ivar Jacobson成立了Objective Systems公司。他吸纳了增量迭代的思想,开发出Objectory过程,并且把过程当软件卖,价格卖到$25,000一份,以至于Ivar Jacobson不想在Addison-Wesley等出版社出书公开他的方法,因为卖一本书才能得到3美元。(无敌哥题外话:看来写书不赚钱,这是大师们早就验证过的哈!所以,现在能够潜心写书的都是有情怀的人!)这是Ivar2015年来中国参加创新应用与软件基础设施大会做演讲时的场景。

图片

1988年,“时间盒(timebox)”被描述为Scott Schultz的“快速迭代开发成型”法的基石,这种方法应用于杜邦公司的副业——信息工程协会。现在我讲述Scrum框架的起源时,会经常提到Timebox。

百家争鸣

1991年,James Martin在其著作《快速应用开发》中描述的RAD(快速应用开发)方法,或许是第一种把时间盒和迭代(较宽松意义上的“整个软件开发过程的一次重复”)紧密结合在一起的方法。这本书描述了时间盒的细节。

1992年,在一次拜访Whitesmiths公司时,Larry Constantine创造和报道了“活力二人组(Dynamic Duo)”这个术语:“每一台终端前有两位程序员!当然,实际上只能由一位程序员来操作键盘编辑代码,但他们两个是并肩作战的。”这其实是关于结对编程最早的记录,现在我们经常用“你开车,我导航”来比喻,但是这里面的核心是“并肩作战”。

1994年,在Rational工作的Rumbaugh和Booch开始合并OMT和Booch方法。随后,Jacobson带着他的OOSE方法学也加入了Rational公司,一同参与这项工作,他们三个人被称为“三友”(three amigo),一起开发UML。最终提出了”Rational Unified Process” (RUP)以及4+1视图模型。RUP的中心思想是:用例驱动、架构为中心、迭代和增量。这项工作对整个业界造成了很大的冲击,因为在此之前,各种方法学的拥护者觉得没有必要放弃自己已经采用的方法,而接受统一的流程,但RUP在国内外还是影响了很大一批人。这也是吸引我后来加入IBM Rational团队的关键点,毕竟在软件工程领域,虽然RUP最终败给了敏捷,但Rational在方法论及工具方面的沉淀,还是独领风骚很多年,使RUP成为软件团队中流传最广的软件过程模型,也成为团队学习软件工程和实施过程改进的重要资料。

图片

1995年,Alistair Cockburn发表了文章《应用开发中人类因素的增长(Growth of human factors in application development》,提出了为什么迭代方法会逐渐被接受的主要原因之一,就是软件开发的瓶颈正在转向(个人和组织)学习,并且人类学习本质上是一个迭代和试错的过程。

1995年,在OOPSLA‘95 会议上,Sutherland和Schwaber共同发表论文,系统介绍了Scrum方法,这正式标志了Scrum的诞生。Scrum框架目前能够成为团队级敏捷的主流框架,跟它之前及这之后的兼收并蓄,有着极大关系。

图片

1996年,Kent Beck为了挽救Chrysler Comprehensive Compensation (C3)项目而创建了XP(eXtreme Programming)过程,虽然Chrysler最终取消了该项目,但是Ron Jeffries和Ward Cunningham等人参与到了XP的工作中,几位大牛的加持,从此奠基了XP实践的历史地位。

图片

1997年,Ken Schwaber描述了“每日Scrum站会(daily scrum)”(这在其早期的著作中并未出现,例如1995年的文章《Scrum开发过程(SCRUM Development Process)》),这个活动后来被Mike Beedle重新整理到了世界第一本Scrum书中。

1997年,Alistair Cockburn基于IBM的一个研究项目的委托,正式提出Crystal方法。Alistair建立了一个二维坐标系,垂直因素是舒适度(C),可自由支配资金(D),基本资金(E)和项目寿命(L),水平因素是“团队规模”,划分出了不同颜色的水晶,代表不同的团队规模,对水晶方法的细分能够帮助团队更加高效地完成软件开发与项目管理,其中透明水晶(Crystal Clear)是敏捷小团队的适宜模式。

图片

1998年,Jeff De Luca和Peter Code正式提出FDD方法。FDD方法非常适用于团队成员水平参差不齐的情况,因为最有经验的可以做主要编程人员。不过如果在一个小团队里,大家水平都差不多,可能会出现资源浪费的情况。

1998年,持续集成和“每日站立会议(daily stand-up)”被列入极限编程的核心实践。

1999年,Martin Fowler 著作《Refactoring: Improving the Design of Existing Code》出版,对敏捷开发中的“重构”实践首次进行系统化阐述。

图片

1999年,Kent Beck在其著作《解析极限编程(Extreme Programming Explained)》中创造了“大可视化图表(Big Visible Chart)”这个术语,尽管后来他把此归结于Martin Fowler。(无敌哥题外话:这才是大师们的谦让之风啊!)

2000年,Ken Schwaber首次描述了“燃尽图(burndown chart)”。在富达投资集团工作时,他试图为Scrum团队提供一个简单的工具包,于是发明了燃尽图,并在其网站上做了正式描述。

2000年,术语“团队速率(velocity)”被添加到极限编程,用于替代先前的、被认为过于复杂的概念——“负载系数(load factor)”。

敏捷诞生

2000年春,Kent Beck组织了一次会议,地点在俄勒冈州的罗格里夫酒店,参会者包括极限编程的支持者们和一些“圈外人”,正是这次会议导致了后来在雪鸟的聚会。在罗格里夫会议上,参会者们宣称了对一系列“轻量”方法论的支持,但没有发表什么正式声明。2000年期间一系列论文都被归类到“轻”或“轻量”流程,其中很多都提到“轻量级方法论,如极限编程、适应性软件开发、水晶系列和Scrum”。大家交流后发现,没人真正喜欢“轻”这个名号,但这似乎是当时约定俗成的称呼。

2000年9月,来自芝加哥Object Mentor公司的Bob大叔用一封电子邮件吹响了下次会议的集合哨。“我想召集一个为期2天的小型会议,时间是2001年1月或2月,地点在芝加哥,目的是让所有轻量级方法论的领袖们汇聚一堂。你们都被邀请了。如果您们觉得还有谁该来,请告诉我。” Bob建立了一个Wiki网站,由此开始了热烈的讨论。很快,Alistair Cockburn就用一封书信加入了讨论,他表达了对“轻”这种提法的不满:“我不介意用‘轻’来描述方法论的轻重程度,但我并不愿意因参加一个轻量级方法学家会议而被看作是轻量级的。这听起来有点像一群干瘦、低能、并无足轻重的人在试图回忆起某个特定的日子。”关于会议地点的争论最为激烈。芝加哥让人不爽,既冷又无趣;犹他州的雪鸟,虽然也冷,但至少对那些想滑雪的人来说还挺有意思,像Martin Fowler在第一天滑雪就滑个头朝地;加勒比的安圭拉岛,暖和又好玩,但路途太远。最后还是可以滑雪的雪鸟胜出,不过有些人(例如Ron Jeffries)还是希望下次能去个暖和点的地方。

图片

2001年2月11日至13日,在美国犹他州瓦萨奇山雪鸟滑雪胜地,17位从事软件开发或者帮助他人从事软件开发的人相聚一堂,交谈、滑雪、休闲,当然还有聚餐。他们试图找到共识,最终的成果就是《敏捷软件开发宣言》(Manifesto for Agile Software Development)。参会者们包括来自于极限编程、Scrum、DSDM、自适应软件开发、水晶系列、特征驱动开发、实效编程的代表们,还包括了希望找到文档驱动、重型软件开发过程的替代品的一些推动者。由全体参会者签署的《敏捷软件开发宣言》(Manifesto for Agile Software Development)成为了重要标志,因为这么大一帮无政府主义者能聚到一起实在是太不容易。只有英国人Martin Fowler表达了对“敏捷”这个词的担心,他认为多数美国人都不知道“敏捷”这个词如何发音。Alistair Cockburn和很多参会者一样,最初有很大的担忧。“我个人没有期望本次敏捷达人们的聚会能够达成任何实质性共识。”会后,他再次分享了自己的感受。“对我来说,很开心宣言能够最终定稿。而让我感到惊讶的是其他人也同样开心,因此我们的确达成了某种实质性共识。”从此,标志着敏捷方法的正式诞生。

图片

百花齐放

2001年,Ken Schwaber和Mike Beedle推出第一本Scrum书籍《Scrum敏捷软件开发》,系统化介绍了Scrum开发方法,标志着Scrum方法的完善。回想2004年,我也是一边读这本书,一边带着团队玩Scrum,可谓无知者无畏!

图片

2001年,Cruise Control,作为第一款“持续集成服务器(continuous integration server)”,在开源许可协议下发布。它能自动监测源代码仓库,触发构建和测试过程,并把执行结果和测试报告档案发送给开发人员。(注:虽然Jenkins目前更流行,但是这个工具代表着CI的落地,后文咱们再讲)

2001年,Bill Wake的一篇文章指出了敏捷团队所使用的两种不同喜好的估算——相对估算和绝对估算(relative and absolute estimation)。

2002年,计划扑克的当前形式在James Grenning的一篇文章中被列出,这正是2001年相对估算方式的落地实践。

2002年,Bill Wake的早期文章提到请注意团队内对于一些常用术语理解可能不一致的问题,例如“完成(Done)”。这一概念,后来被扩展为“完成的定义(Definition Of Done)”。

2003年,Mary和Tom Poppendieck夫妇的著作《精益软件开发(Lean Software Development)》将“敏捷任务板(Agile task board)”描述为“软件看板系统(software kanban system)”。同时,提出了精益软件开发的7项原则(1.消除浪费;2.内建质量;3. 创建知识;4.推迟决策;5.快速交付;6.对人尊重;7.整体优化),第一次系统化地将精益理念引入到软件开发中。

图片

2003年,用于快速评估用户故事的INVEST检查单来自Bill Wake的一篇文章,该文章还为用户故事分解得到的技术任务改写了SMART缩写(Specific具体的,Measurable可衡量的,Achievable可实现的,Relevant相关的,Time-boxed时间盒的)。(注:是跟你想的SMART不一样,我们敏捷嘛!所以是Time-boxed)

2004年,Kent Beck提出“完整团队(Whole Team)”作为之前名为“现场客户”的实践的新名称,我猜测这应该是把“现场客户”给纳入到团队之中来看待了。

2004年,INVEST首字母缩略语成为Mike Cohn的著作《用户故事与敏捷方法(User Stories applied)》中推荐的技术之一,在第二章详细讨论了这个技巧。

2004年,David Aderson的第一个软件看板系统在微软公司XIT软件维护团队中实施。这为后续看板方法的提出,奠定了实践基础。

2005年,计划扑克技术在Scrum社区中开始流行,这归功于Mike Cohn的著作《敏捷估算与规划(Agile Estimating and Planning)》,这是其中做计划的多个技术中的一个。

图片

2005年,术语“Backlog梳理(backlog grooming)”最早记录的使用源自Mike Cohn在“Scrum开发邮件列表上”的观点;几年之后,这个实践才被更正式地描述。

2005年,Alistair Cockburn和Jim Highsmith领导的小组撰写了项目经理原则的增补版,向项目经理介绍敏捷开发方法。这本书对于社区影响力还是很大的,现在被ACP列为官方认证参考书籍之一。

2005年,Jeff Patton在文章《It’s All in How You Slice It》明确表达了故事地图(story mapping)的概念,但并没有给出这个名字。

2006年, Esther Derby和Diana Larsen出版《敏捷回顾(Agile Retrospectives)》,填补了对敏捷回顾的空白。

2007年,社区发布了看板团队的最早几份实践报告,这些团队使用了一套特别的称为“看板 (KANBAN)”的修订方案(没有迭代,没有估算,持续地带着WIP限制的任务板),其中包括来自Corbis(David Anderson)和BueTech(Arlo Belshee)的报告。这其实也是对基于迭代的敏捷方法的极大补充,毕竟之前的方法论都是以迭代为主型的;KANBAN方式提出这种基于流的工作方式,更加灵活,毕竟增量可大可小,对于不好做计划的敏捷项目,是一个福音。

2008年,Cem Kaner给出了“探索性测试(Exploratory Testing)”的一个新定义,反映了这种测试方法的不断完善。

2008年,Agile 2008大会专门设置了一个论坛来讨论“用户体验(User Experience)”的相关实践,比如可用性测试(usability testing)、用户画像(personas),以及纸上原型(paper prototyping)。

2008年,Jeff Patton的文章《新的用户故事Backlog是一张地图(The new user story backlog is a map)》图文并茂地详尽描述了“故事地图(story mapping)”实践。

图片

2008年10月,虽然最初提到团队开始使用“就绪的定义(Definition of Ready)”的时间是在年初,但第一次正式的说明似乎是从十月开始的,并且很快就被纳入了“官方”的Scrum培训材料。

2009年,无敌哥携手许舟平,出版了国内第一本小说体敏捷巨著《敏捷无敌》,以主人公阿捷学习敏捷的艰难历程为主线,展示了一个团队实现敏捷转型的全过程。

持续交付

​2009年6月,美国圣荷西,第二届Velocity大会上一个名为“10+ Deploys Per Day: Dev and Ops Cooperation at Flickr”的演讲,轰动世界,后来几乎所有的和DevOps相关的资料都会把这个演讲作为DevOps萌发的标志。这个演讲提出了DevOps的“一个中心,两个基本点”——以业务敏捷为中心,构造适应快速发布软件的工具(Tools)和文化(Culture)。

图片

2009年,持续部署(continuous deployment)”实践已经确立,尽管仍有些争议,特别是Timothy Fitz的文章《IMVU的持续部署(Continuous Deployment at IMVU)》。争议是啥不重要,但这篇文章不仅在敏捷领域变得非常重要,在创业圈也很火热,因为IMVU就是写出《精益创业》的Eric的创业项目。

2009年, Don Reinertsen 出版《产品流式开发的原则(The Principles of Product Development Flow)》,揭示产品开发流的本质,并提出相匹配的175条原则方法,讨论了排队论、延迟成本、加权最短作业优先算法(WSJF)等;这本书对于后来很多规模化敏捷方法论都产生了深远影响,但很奇怪的是,国内一直没有人引进这本书的中文翻译。

图片

2010年,David J. Anderson 正式出版《看板方法:科技企业渐进变革成功之道》(KANBAN– Successful Evolutionary Change for Your Technology Business) ,代表Kanban方法作为一个正式敏捷方法论日臻完善。

2010年,《持续交付》的作者Jez Humble参加了第二届DevOpsDays 并做了 “持续交付”的演讲。从本质上说《持续交付》中所提到的实践给开发团队如何与运维团队协作,给出了最佳实践。如果《持续交付》早两年问世,也许不会出现 DevOps。然而,随着 DevOps 理念的传播,DevOps 概念的外延越来越广,已经超出了持续交付本身所涵盖的范畴。

2011年,“Backlog梳理(backlog grooming)”实践升级为Scrum的官方元素,并纳入了《Scrum指南(the Scrum Guide)》。

2011年圣诞节过后,这年的第一场雪,比以往来得要晚一些,几个程序员大叔在McDonald的豪华包间里做了一个艰难的决定:mv -f hudson jenkins。于是,影响整个敏捷界的持续集成工具Jenkins就诞生了!这段历史比较狗血,正所谓惹谁千万不要惹程序员!Jenkins 前身叫做Hudson,Hudson是在2004年的夏天由Sun公司开发的(就是开发Java的那家),2005年2月开源并发布了第一个版本。Hudson发布的时候,CruiseControl是CI界的老大哥,咱们前文说过,但是很快,在大约2007年的时候Hudson已经超越CruiseControl。2008年5月的JavaOne大会上,Hudson获得了开发解决方案类的Duke’s Choice奖项。从此,小弟翻身做大哥,Hudson成为CI的代名词。2009年6月,乌龟壳(Oracle)收购Sun,所有人都炸裂了。2010年9月,乌龟壳公司偷偷把Hudson®™变成了注册商标。2010年11月,Hudson社区的核心开发人员发现并angry了,双方进行了不太友好的会谈,不出意料的谈崩了。所以,就出现了前面的场景!

2012年,敏捷大师Gojko Adzi在《Impact Mappping》一书中提出的,形式如下图所示,通过Why->Who-> How -> What四个层次的分析法,以结构化的形式显示,将业务目标(Why)和产品功能(What)之间建立关联,让团队清晰的看到每一个功能对业务目标的实现是怎样的影响路径,确保团队做的每一个产品功能都是有价值的。

图片

2014年,Jeff Patton正式出版《用户故事地图,User Story Mapping: Discover the Whole Story, Build the Right Product 》,对这一实践进行了系统化的阐述,为业界对 Product Backlog 的梳理方式打开了一扇新的窗口,更加利于不同角色的系统,解决了长期困扰我们“只见树木,不见森林”的问题。

2017年,Janet Gregory和Lisa Crispin建立了对“敏捷测试(Agile Testing)”的定义,标志着该主题的第一个简洁的定义。

规模化敏捷

1996年,Scrum of Scrums模式,最早在IDX Systems(现为GE Healthcare)上实施。Jeff Sutherland当时是工程部高级副总裁,肯·施瓦伯(Ken Schwaber)担任顾问以帮助推广Scrum。该项目涉及到八个业务部门,而每个部门都有多个产品线。每个产品都有自己的Scrum of Scrums。一些产品有多个Scrum of Scrums和更高级别的Scrum of Scrums。每个产品都必须以三个月或更短的发布周期投放市场。所有产品每六个月必须进行一次完全集成,升级和部署,以支持像斯坦福医疗系统等区域性医疗保健供应商。从此示例可以明显看出,可以存在多个甚至是并行的Scrum of Scrums,而每日Scrum of Scrums(当做会议)都可以分为具有独立焦点的子会议。

2001年,最早提到Scrum of Scrums的出版物是在“Cutter IT Journal:伟大的方法论辩论”,它也出现在2011年的Scrum论文中。

2005年以来,Craig Larman和Bas Vodde一直与许多组织合作,将Scrum,精益和敏捷开发扩展到大型产品组。他们将从这项研究中获得的经验和知识转化为一个名为“大规模Scrum(LeSS)”的敏捷框架草案。虽然许多思想领袖已经提出了这样的指导,但Craig和Bas认为“Scrum”作为一个框架具有有效采用敏捷所需的所有要素,而不管规模如何。可用的角色,流程和工件集足以成功实施Agile。因此,他们制定了LeSS,没有额外的术语或复杂的文物,力求保持简洁。

图片

2011年,Dean Leffingwell作为SAFe(Scaled Agile Framework,规模化敏捷框架)首席方法论专家,正式发布1.0版。在随后的几年内,SAFe融入了敏捷、精益、系统思考、设计思维、精益创业、DevOps等核心理念与思想,形成了SAFe的四大核心价值观及十大原则,覆盖团队、项目群、解决方案和投资组合等四个层级。特别是关于敏捷发布火车(Agile Release Train)的概念及PI Planning(项目群增量计划会议)实践,在规模化敏捷方向非常具备代表性。(题外话,其实,Dean本身跟RUP是有非常大的渊源的,因为他创始的RequisitePro被Rational收购,后来成为IBM Rational的VP。在他推出SAFe时,社区有人戏言“曾经的RUP小子又回来了”!借此来抨击SAFe过于庞大,不够敏捷,不过这件事只能是仁者见仁智者见智啦。)

图片

2012 年,还在IBM Rational团队的Scott Ambler与Mark Lines提出了规范敏捷交付(Disciplined Agile Delivery,DAD)过程框架,这也是一个规模化敏捷框架。对的,你没看错,又是出自Rational团队!行业当时认为用这个方法会比传统的RUP方式在企业级软件生产与交付时拥有更高的效率,而且Gartner还做了特别推荐。

图片

2012年11月,知名敏捷教练Henrik Kniberg发布了一篇博客,“Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds(Spotify的部落、小队、分会和公会式的大规模敏捷)”,这篇文章及后续讲Spotify研发过程、工程文化的另外两篇文章一起,构成了Spotify模式三部曲,一时成为坊间要闻,创造了规模化敏捷的Spotify模式,成为很多公司竞相模仿的一种形式。

图片

2015年,Ken Schwaber对外发布Nexus规模化敏捷框架,“规模化的Scrum框架(Nexus)仍然是Scrum”。这句话听起来很熟悉,因为另一个规模化敏捷框架也宣称 “LeSS也是Scrum”。

2016年,SAFe发布4.0版本,从收集到的案例数据里面,总结出在生产效率、产品上市时间、交付质量、员工满意度等多方面成果显著。

2018年3月,CMMI2.0明确提出对敏捷的支持。

2018年, Jeff Sutherland 跟Scrum联盟合作,一起创作并发布了[email protected],它结合了最小可行的管理机构 (MVB),这是 Mozilla 和 Spotify 推广的一种敏捷开发方法。

2019年8月, 美国项目管理协会(PMI)宣布收购 DA,算是在ACP认证之外,补全了规模化敏捷。

2019年12月,SAFe发布5.0版,正式提出业务敏捷的七大能力,转型背后的双操作系统概念令人眼前一亮,受到众多500强公司的追捧。国内社区对于SAFe的推广,不得不提及李建昊老师,他最早创立了中国SAFe社区,并搞了多次SAFe峰会,作为SPCT,还为国内培养了多位SPC,我也是那会儿成为SPC的。2016年,正好适逢Dean Leffingwell来中国,作为非时空交集的IBM Rational同事,跟他聊起Rational的一些人物及趣事时,依然还是很有话题感。

图片

2020年4月,Jeremiah Lee(Spotify前员工),他在自己的博客写了一篇文章《Spotify doesn’t use “the Spotify model”and neither should you.》,即“Spotify自己也没有采用Spotify模式,建议大家也不要乱用”。真可谓一石激起千层浪。当他2017年在斯德哥尔摩总部面试产品管理职位时,招聘人员让他大吃一惊。招聘人员告诫他不要指望Spotify是一个敏捷的乌托邦。后来他加入了这家公司,在经历的18个月里,公司规模扩大了两倍,达到3000人。他认识到,著名的Squad(小分队)模式只是一种理想,从来没有完全实施过。他目睹了公司领导逐渐过渡到更传统的管理结构后而产生的组织混乱。

2021年7月,翘首以待的《项目管理知识体系指南》(PMBOK)第七版终于发布了,新版本主要增加了敏捷相关内容,据说新的PMP考试中,敏捷将会占据一半内容。这可以说得上是一次极大的革新与颠覆,打破了唯项目管理讲项目管理,纳入了许多通用管理学、管理心理学、产品设计理论的知识和理念,比如“神奇的数字7”——敏捷团队成员数量 最好为7±2。敏捷的发展简史终于回顾完了!我肯定还遗漏了很多内容。

不知道你有没有注意到,许多人为了寻求“敏捷”,一直在坚持不懈地努力,或自己亲身实践,或帮助他人,从未停止,毕竟“敏捷”只是一个目标,其实,我们所有人都是追求“她”的路上!

Being Agile!

现在你明白谁动了你的“敏捷”吗?

其实没有其他人,那个人只能是你自己!

在这个不断变化的世界,“敏捷”也在不断演进,无数的人也正在创造着无数种“敏捷”。

或许你不信,接下来我们会给你讲一个叫《敏捷漂流记》的故事,里面有很多好玩的人物,一个家伙叫“郭靖”,他好像有一个叫“洪七公”的师傅,也有一个师傅叫“柯镇恶”,虽然武功不咋样。嗯,对的!“黄蓉”必须要在才行!“黄岛主”、“杨过”、“小龙女”应该也会出现吧。至于“虚竹”、“乔峰”、“段誉”、“张无忌”等大侠是否在,要看缘分了……作为敏捷江湖人物,他们都特别喜欢玩一种叫“漂流瓶”的暗器,每次遇到些奇遇,就会用自己的独家心法写出来,放入“漂流瓶”,扔入敏捷江湖,以求扬名立万。

让我们一起来捡拾漂流瓶吧!

图片

属于你的“敏捷”没准会出现在这些漂流瓶中,也可能在你自己之后的行动中,还可能来自于你自己的思考,无论如何,只要你保持一个开放的心态,享受求知之路的乐趣,一定会找到属于你自己的“敏捷”!

参考文章:

  1. 头条号 – 振振有词abc ,通过一篇文章来了解“敏捷”的发展历程:https://www.toutiao.com/i6508526703231369736/
  2.  敏捷十年简史回顾——影响敏捷开发历程的27件事:https://www.cnblogs.com/cly84920/archive/2010/10/14/4426664.html
  3. 敏捷宣言诞生记:https://www.scrumcn.com/agile/%E6%95%8F%E6%8D%B7%E5%AE%A3%E8%A8%80%E8%AF%9E%E7%94%9F%E8%AE%B0.html
  4. Jenkins简介起源介绍:https://blog.csdn.net/u010597230/article/details/108372753
  5. 【Scrum模式语言5】Scrum of Scrums:https://blog.csdn.net/ScrumDavid/article/details/122121821
  6. 如何使用Scrum管理企业級规模的开发团队:https://blog.csdn.net/chktsang/article/details/96977058

图片

无敌哥

中国DevOps社区核心组织者

最新著作《京东敏捷实践指南》《敏捷无敌之DevOps时代》

2022年3月18日于京城 随笔

Category敏捷
Tags,

©2022 中国DevOps社区版权所有;本站内容许可 CC 4.0

关注社区:                        
跳至工具栏