敏捷是人的天性,是你与生俱来的东西。面对敏捷,Arie van Bennekum 下了这样一个结论。

但这并不意味着人们只能通过天赋获得敏捷,对于想要学习敏捷的人来说,敏捷绝不是仅仅靠学习僵化的框架、实践、过程或技术就行得通的。同样,只有真正采用敏捷思维和文化的组织才会变得更具灵活性和创新性。而 Arie,也在推动着敏捷转型。

传统式工作

1983年,Arie 以一名助产士的身份取得了卫生学学士学位。拿到毕业证以后,他做出了自己的职业规划:从事女性保健行业。即使在这个当时是女性占主导的行业中,作为一名男性的他并不占优势,他也确信自己可以做得很好。事实上,他确实完成得很出色。

两年后,Arie 开始服役。在义务兵期间,由于 Arie 常常不按套路出牌,所以他的教官告诫他,如果不能循规蹈矩,就无法取得成功。但在服役结束前,不被教官看好的他却担任了排长,并赢得了团队和指挥官们的尊重。这件事告诉了他:无论在哪个领域工作,遵循既定的旧式体系并不是成功的必要条件

1987年,Arie 作为 COBOL 开发人员开始从事IT工作,他的职业生涯开启了新的篇章。在这一公司中,Arie 的大部分时间都是在结对编程,进行短周期、有时间限制的交付。而从这家公司辞职后,Arie 加入了一家采用传统工作节奏的IT咨询公司,在一家著名的政府机构从事一个项目,开始了传统式开发模式之旅。

由于工作完成得极为出色,很快,他就由开发人员晋升为技术设计师,这是对他能力的最大肯定。但在进入设计领域后,Arie 也逐渐发现了一个问题:自己离客户越来越远了,“这不能令我感到快乐”。这种情绪一直困扰着他,直到1994年中期,导火索出现了。当时,Arie 参与了一个耗时多年的项目,这个项目将与另外两个为期六个月的技术设计一起交付,但在设计过程中,他发现自己在不断地重复做一件事情:将一份文件翻译成另一份文件,并将其交给能读懂第一份文件的程序员。这种死板的方式带给了他很大的挫败感。“这种方式几乎抹去了我的工作的全部附加价值,简直是在浪费时间、金钱”。他意识到,传统的工作模式正在阻碍着团队的管理优化。

这件事过后,Arie 冒着被辞退的风险做出了一个决定:他去同管理层解释,说自己不想再做这样的工作。但自己究竟要做什么样的工作呢?他一直在思考。直到几周后,答案出现了。Arie 被邀请参与到一个快速应用程序开发(RAD)项目中,这个项目所涉及到的互动、迭代、原型等敏捷的元素给他带来了一个全新的世界。令人遗憾的是,这个新世界并不是完美的:RAD 能够使开发人员通过简单的构建原型,快速地向用户和客户展示可能的解决方案,但这种方法通常是非结构化的,这导致各个 RAD 团队之间彼此孤立、彼此分割。Arie 深知,RAD 方法还需要很多成长的空间。

初识 DSDM

为了完善RAD方法,1994年,业界成立了一个以“共同开发并推动一个独立的 RAD 框架”为目标的 DSDM 联盟,DSDM(动态系统开发方法)诞生了。此时的 Arie 还在寻找更完善的方法。三年后,他加入了一家小公司,该公司拥有自组织的团队、高度授权的成员以及创新的文化环境。也是在这段时间里,Arie 接触到了 DSDM。

DSDM 是一种以用户反馈为基础,并优先考虑快速原型和迭代的软件开发方法,他认为,DSDM 能够以一种真正适合最终用户的方式向客户交付他们切实需要的东西。因此,1997年以来,Arie van Bennekum 经常作为教练参与各个 DSDM 项目,积极参与 DSDM 联盟。目前,他不仅是荷兰比荷卢(Benelux)DSDM 联盟的董事会成员,还拥有多个 DSDM 认证。

Arie 从 DSDM 中学到很多,对于他来说,开发过程中的各个方法论都基于不同的范式,而成功实施的基础,则源于这些方法论中的各种标准惯例。也就是说,如果在一个团队中,每个人所习惯的工作方式各不相同,那么团队要做的第一步就是确保所有人的工作方式是一致的。但如何彻底改变团队的工作方式,这又是一个大问题。

1998年,Arie 第一次将 RAD 引入到客户的团队中时,就发现了类似的问题。不论团队是否决定转变工作方式,亦或是无论如何转变工作方式,总会遭遇到未知来源的阻力:管理层依然坚持着旧的工作方式,包括决策、评估、交付、接受等流程。果不其然,他将 RAD 引入团队中,并在团队内实施了一段时间后,整体的工作效果还是欠佳。不仅是个人,团队也更倾向于退回到旧的工作方式中。

在 Arie 看来,每个人的观点或看法,并不会因为学习了敏捷的各种惯例,就立刻做出改变,如果不改变团队工作的环境和个人的看法,那么,以高压、强迫的方式来改变人们的工作方式只会造成大力反弹,一旦外部压力消失,他们就会回到原来的工作方式。因此,团队转型就意味着首先要从观点、看法转变做起。

《敏捷宣言》

对于 Arie 来说,2001年是充满魔幻色彩的一年,也是注定不平凡的一年

 

这年秋天,Arie van Bennekum 作为英国 DSDM 联盟的代表受邀参加雪鸟会议,来到盐城湖,签署了《敏捷宣言》。Arie 说,《敏捷宣言》是对当时几种轻量方法背后的价值与原则的提炼,是这十七个人都认可的最佳实践,而自己至今仍为会议总结出了“敏捷”——这一涵盖所有轻量开发方法的词感到自豪。

此后,随着践行敏捷的队伍不断壮大,业内不断有人对《敏捷宣言》做出更新,Arie 也重新审视了自己的“敏捷宣言”,并在原来的基础上做了一些小的调整。

首先,2001年所签署的《敏捷宣言》的重点是:找到交付更好软件的方法,而 Arie 认为敏捷是一种集成的企业解决方案,它适用于组织的每一个职能,包括从人力资源到技术。因此,他提议将“敏捷宣言”中的“软件”换成“解决方案”,以满足现今组织整体践行敏捷的需求。

其次,将“响应变化高于遵循计划”改为了“响应变化高于遵循死板的计划”,这个变动主要集中在遵循什么样的计划上面。Arie 认为,团队需要有一个合适的计划,只要不固执地遵循计划,并记住它是灵活的,那么当出现新的情况时,它就可以“响应变化”。

敏捷中有一个神话,就是实践敏捷可以做任何我们喜欢做的事情。而 Arie 认为,实践敏捷必须做需要做的事情,敏捷的成功来自质量和纪律。举个例子,一个团队每周只开一次早会,他们觉得每天开会就会造成时间成本的浪费,用时多、效果差,这是一个非常愚蠢的行为。只有每日更新团队的工作进度,才能及时发现并解决日常工作中存在的问题。

大多数情况下,从事敏捷转型的人只关注于以教条的方式实现的一个或几个框架、实践,却忽略了最重要的部分,即实现敏捷和按照敏捷做事的区别。为了实现敏捷,成员、团队必须转换到一个完全不同的范式,其中包括不同的思维方式、工作方式和协作方式。这种转变反过来能够让整个团队从敏捷中获得巨大的好处。

因此,为取得成功,需“达成敏捷”而非去“做敏捷”

Agile TM 转换模型


Arie 始终把人作为关注的焦点、工作的中心
。作为敏捷领导力咨询公司 Wemanity 的精神领袖,他也不断地努力在 Wemanity 内创建、加强敏捷(以人为导向)的文化,以便为 Wemanity 的客户提供最佳价值。

为了使组织变得更加灵活、敏捷,Arie 及其团队开发出了一套集成敏捷转换模型 IATM(Integrated Agile Transformation Model),这是一种经过验证的方法,无论是从个人到领导,还是从企业服务到技术,都可以通过运用它成功转换为新的敏捷范式。

IATM 的流程首先是环境,它将人们带入到变更过程中,真正实现敏捷;然后是团队,要求在一个团队中以高质量和纪律为标准来学习;最后是个人的完善。为了达成最佳效果,Arie 还提出,他们会在开发中做很多简单、定制的活动,从而帮助组织将关注点从伪敏捷转移到真正的敏捷上面,针对某一问题进行具体分析。

如今,ITAM 已帮助财富榜单上众多500强公司成功地完成了敏捷转型,不论是过去还是未来,ITAM 终将继续砥砺前行。

作为一名敏捷布道者,Arie 多年来一直致力于敏捷转型,如何促使敏捷转型团队达到最佳状态,是他一直以来的追求。此外,他在社交媒体账号上也非常活跃(Twitter、Facebook、Linkedln账号:Arie van Bennekum)。在 Arie van Bennekum 的身上,我们看到的是:打破常规,需要的不仅是“离经叛道”的勇气,更多的是踽踽独行的实践精神;遵守规则,需要的不能是敷衍了事的态度,而是融会贯通的技巧应用

敏捷史话(四):敏捷是人的天性 —— Arie van Bennekum的更多相关文章

  1. 【 腾讯敏捷转型No.4 】为什么敏捷团队不要超过15人

    早期,腾讯公司的架构是比较简单的.从上至下分别是:公司——商业单元(BU)——部门——组——员工,每个部门基本上就是负责一个大的产品,每个组都是按照专业进行分工和管理,例如:产品组.终端组.后台组.设 ...

  2. 敏捷史话(一):用一半的时间做两倍的事——Scrum之父Jeff Sutherland

    普通的人生大抵相似,传奇的人生各有各的传奇.Jeff就是这样的传奇人物,年近80的他从来没有"廉颇老矣尚能饭否"的英雄迟暮,不久前还精神矍铄地与好几百名中国学生进行线上交流,积极回 ...

  3. 敏捷史话(五):敏捷已逝 —— Dave Thomas

    " 敏捷已逝,但敏捷精神长存.因为所谓的敏捷专家卖给你的是方法论,而不是价值."当多数人都在从"敏捷"身上榨取利益时, Dave Thomas 成为了一位逆行者 ...

  4. 敏捷史话(十二):你现在接触的敏捷也许是“黑暗敏捷”——Ron Jeffries

    他很少提起往事,也不再提及二十年前那场引起软件行业变革的会议,他专注于当下,一直活跃在敏捷领域.八十多岁的他依然运营维护着网站和博客,是极限编程网站 XProgramming.com 的作者,该网站是 ...

  5. 敏捷开发--洞察敏捷模型,从PO的角度看敏捷产品管理

    转自本人运营的公众号“ 携程技术中心PMO”(ID:cso_pmo)       经常有人抱怨的一个问题:敏捷会让团队自组织,要求团队能“一方有难,八方支援”,但是为什么总感觉自己团队虽然实践了敏捷, ...

  6. CODING 助力江苏高速信息实现组织敏捷与研发敏捷,领跑智慧交通新基建

    疫情之下的高速公路管控重任 江苏高速公路信息工程有限公司(以下简称:江苏高速信息)成立于 2002 年,是江苏交通控股旗下,专业从事高速公路领域机电系统集成.智能交通软硬件研发.大数据分析运营的高新技 ...

  7. 敏捷开发 and 敏捷测试

    名词解释 agile: 敏捷的:灵活:敏捷开发. scrum: 扭打,混打:并列争球:参加并列争球. sprint:  冲刺,全速跑. backlog: 积压的工作:积压待办的事务. retrospe ...

  8. 【敏捷0】敏捷项目管理-为什么从敏捷开始?为什么从PMI-ACP开始?

    作为敏捷项目管理的开篇文章,还是先来简单地说一说为什么先从敏捷开始,为什么是以 PMI-ACP 为参考.当然,这一系列的文章可能不可避免地会为 PMI-ACP 做一些广告,但是我想告诉大家的是,敏捷以 ...

  9. 敏捷史话(十四):敏捷之峰的攀登者 —— Jim Highsmith

    "我们希望,一起组成的敏捷联盟能够帮助到其他同行,帮他们用新的更'敏捷'的方式去思考软件开发.方法论和组织.做到这一点,我们就得偿所愿了."Jim Highsmith 在雪鸟会议结 ...

随机推荐

  1. vue 重置data

    Object.assign(this.$data, this.$options.data())

  2. HDU4388-Stone Game II-Nim变形

    http://acm.hdu.edu.cn/showproblem.php?pid=4388 Nim变形,对一个\(n\)个石子的堆,每次取\(k(0<k<n)\)个(注意不能全取光),同 ...

  3. 图像处理论文详解 | Deformable Convolutional Networks | CVPR | 2017

    文章转自同一作者的微信公众号:[机器学习炼丹术] 论文名称:"Deformable Convolutional Networks" 论文链接:https://arxiv.org/a ...

  4. Thymeleaf的th

    th:action 定义后台控制器路径,类似<form>标签的action属性. <form id="login-form" th:action="@{ ...

  5. Typora + 七牛云图床快速配置,告别手动上传图片!

    大家好,我是zeroing,本文将介绍关于 Typora 软件如何配置七牛云图床,实现图片即插即用,可以先看一下最终效果! 可以看到图片借助 Typora 软件自动将本地存储转化为第三方图片网络链接 ...

  6. PHPCMS V9.6.0 SQL注入漏洞分析

    0x01 此SQL注入漏洞与metinfo v6.2.0版本以下SQL盲注漏洞个人认为较为相似.且较为有趣,故在此分析并附上exp. 0x02 首先复现漏洞,环境为: PHP:5.4.45 + Apa ...

  7. SpringBoot从入门到精通教程(一)

    写在前面的话: 在很早之前,记笔记时候,我就一直在思考一个问题,我记笔记是为了什么,我一直想不明白 ,后面发现技术跟新迭代的速度实在太快了,笔记刚纪完,技术又跟新了,于是我想了想干脆边写博客,边记笔记 ...

  8. 【SpringBoot—注解】@requestBody 与@requestparam;@requestBody的加与不加的区别

    一)首先说明xia @requestBody与@requestParam的区别 spring的RequestParam注解接收的参数是来自于requestHeader中,即请求头.都是用来获取请求路径 ...

  9. redo log 有什么作用?

    mysql 为了提升性能不会把每次的修改都实时同步到磁盘,而是会先存到Boffer Pool(缓冲池)里头,把这个当作缓存来用.然后使用后台线程去做缓冲池和磁盘之间的同步. 那么问题来了,如果还没来的 ...

  10. 9条消除if...else的锦囊妙计,助你写出更优雅的代码

    前言 最近在做代码重构,发现了很多代码的烂味道.其他的不多说,今天主要说说那些又臭又长的if...else要如何重构. 在介绍更更优雅的编程之前,让我们一起回顾一下,不好的if...else代码 一. ...