摘要:任何工具或者流程如果让人们在自己的工作环境中感到举步维艰,那它就不能被称为敏捷,只能称之为“伪敏捷”。

《2020年敏捷状态报告》中显示,现今许多组织还在学习如何实施敏捷。受访者中也有大约50%的人表示,他们的团队中只有不到一半的人在使用敏捷,而其中仍有高达84%的人承认他们的组织没有达到高水平的能力。

一部分公司或团队在践行敏捷后取得了巨大的成功,让更多的人趋之若鹜,纷纷转型敏捷。但转型敏捷绝非易事,在这一过程中,最常见的问题就是团队并未真正理解敏捷原则及核心价值观,而是一味地照猫画虎。自然,照猫画虎最终还是失败了,这时候经过这一系列变动的团队或成员就开始大肆宣扬“敏捷无用论”:搞那么多虚头巴脑的招式,只会浪费更多的人力物力财力,增加时间成本,到头来没有什么实质性的用处。但是,真的是敏捷无用吗?还是你用错了敏捷?

敏捷宣言的主要内容是:

  • 个体和互动高于流程和工具;
  • 工作的软件高于详尽的文档;
  • 客户合作高于合同谈判;
  • 响应变化高于遵循计划。

但在很多公司中,团队打着“敏捷”的旗号,实际行动却严重偏离敏捷宣言及价值观,最后往往“欲速则不达”。敏捷宣言合著者Robert C. Martin接受采访说,任何工具或者流程如果让人们在自己的工作环境中感到举步维艰,那它就不能被称为敏捷。因此,这些仅披着一层“敏捷”外壳的团队,只能称之为“伪敏捷”。

当团队或者公司踏入“伪敏捷”的怪圈时,如何发现这一问题,就是我们要去解决的问题了。

什么是伪敏捷?

1.极端的敏捷

1)“敏捷”并不是一味的“快”

谈到敏捷,作为一种轻量级方法,很多人误认为敏捷就是“快”:快速反应、快速交付。因此整个团队只顾追求速度,认为“时间紧任务重”,以致于为了追求速度而不得不放弃质量。这种以快速交付为重心的产品无法满足客户的需求,甚至无法通过测试的质量鉴定。

2)“敏捷”并不是一味的“简洁”

敏捷十二原则中第10条为“以简洁为本,极力减少不必要工作量的艺术”。有的人就会说了,既然要提倡简洁,那么就把不必要的流程简化吧:每日站会太浪费时间了,减掉;回顾会议毫无意义,减掉;准备文档太复杂了,减掉;敏捷提倡响应变化,所以不需要计划会议了,减掉……绝对主义者往往会觉得既然要简化就简化的彻底一些,就要进行大刀阔斧的改革。然而在一通乱裁之后,真正有价值的东西被“淘汰”了,留下一群摸不着头脑的程序员在重复繁琐的任务中继续敲代码。

2.僵化的敏捷

1)站立会议

每日站会是敏捷团队进行工作互通的桥梁。每日站会不需要团队成员对自己的工作内容作出详尽而清晰的报告,只需要用两分钟的时间进行一个简单的陈述,总时长一般在15分钟左右。这里的15分钟只是一个大概的时间,具体时间会根据每个团队的成员数量以及工作性质而变。在敏捷的实践过程中,一些团队将站立会议的概念混淆,只是死板地遵循15分钟会议时间的规定,不论团队成员数量多少,要求必须在15分钟内结束。

一旦会议时间被刻板化,这会给团队成员增加很大压力,促使他们不得已找些零零碎碎的任务来敷衍会议,因此也就无法达到每日站会促进团队内部交流的目的。

2)看板

敏捷团队中通常应用看板帮助团队实现任务可视化、工作状态透明化,激励团队成员工作、提高工作专注力及效率。但是在设置看板后,也会一个很大的缺陷:看板处于半闲置状态,无法得到及时更新,团队成员无法从看板中获取响应的信息。这样的结果就是:看板成为了一个代表敏捷的摆设。负责人在汇报工作的时候,一指墙上的看板:看,我们团队在转型敏捷。但实际上,敏捷的观念有没有深入贯彻,除了团队内部成员,其他谁也不知道。

3.传统型领导的敏捷

之前写过一篇关于规模化敏捷变革的文章,文中强调了在团队转型规模化敏捷之前,首先需要领导者转型敏捷。同样,在传统团队转型敏捷的过程中,也需要领导者率先转型敏捷,具备精益敏捷思维。只有精益敏捷的领导者才能通过挖掘、利用团队和个人的长处推动团队的敏捷化。

我曾了解过这样一家公司,领导者思维延续着传统的瀑布式开发模式。当整个团队开始转型敏捷的时候,领导仍在提倡开发流程的前后延续关系,导致团队在实施敏捷开发的小周期迭代时遇到很大的阻力,整个团队呈现出一种“高不成低不就”的状态。如果公司内部都没有达成统一的敏捷转型态度,这时的敏捷团队就会举步维艰。

因此,要想打破敏捷转型效果不佳的“诅咒”,就要勇于冲破团队现行模式的桎梏,识破团队中的“伪敏捷”现象,根据团队的实际情况适当改变策略,真正做到让敏捷“活”起来。

点击关注,第一时间了解华为云新鲜技术~


华为云开发者联盟
1.4k 声望1.8k 粉丝

生于云,长于云,让开发者成为决定性力量