敏捷史话(四):敏捷是人的天性 —— Arie van Bennekum

举报
敏捷开发 发表于 2021/01/21 09:43:39 2021/01/21
【摘要】 Arie van Bennekum——作为非科班出身的IT从业者,抓住了敏捷的本质。他始终将人作为关注的焦点,通过不断地推动着敏捷团队的转型达到最佳状态。

本文转自敏捷开发

敏捷是人的天性,是你与生俱来的东西。面对敏捷,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 的身上,我们看到的是:打破常规,需要的不仅是“离经叛道”的勇气,更多的是踽踽独行的实践精神遵守规则,需要的不能是敷衍了事的态度,而是融会贯通的技巧应用

【版权声明】本文为华为云社区用户原创内容,未经允许不得转载,如需转载请自行联系原作者进行授权。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。