《2020 年敏捷状态报告》中显示, 现今许多组织还在学习如何实施敏捷. 受访者中也有大约 50% 的人表示, 他们的团队中只有不到一半的人在使用敏捷, 而其中仍有高达 84% 的人承认他们的组织没有达到高水平的能力.
一部分公司或团队在践行敏捷后取得了巨大的成功, 让更多的人趋之若鹜, 纷纷转型敏捷. 但转型敏捷绝非易事, 在这一过程中, 最常见的问题就是团队并未真正理解敏捷原则及核心价值观, 而是一味地照猫画虎. 自然, 照猫画虎最终还是失败了, 这时候经过这一系列变动的团队或成员就开始大肆宣扬 "敏捷无用论": 搞那么多虚头巴脑的招式, 只会浪费更多的人力物力财力, 增加时间成本, 到头来没有什么实质性的用处. 但是, 真的是敏捷无用吗? 还是你用错了敏捷?
敏捷宣言的主要内容是:
个体和互动高于流程和工具;
工作的软件高于详尽的文档;
客户合作高于合同谈判;
响应变化高于遵循计划.
但在很多公司中, 团队打着 "敏捷" 的旗号, 实际行动却严重偏离敏捷宣言及价值观, 最后往往 "欲速则不达". 敏捷宣言合著者 Robert C. Martin 接受采访说, 任何工具或者流程如果让人们在自己的工作环境中感到举步维艰, 那它就不能被称为敏捷. 因此, 这些仅披着一层 "敏捷" 外壳的团队, 只能称之为 "伪敏捷".
当团队或者公司踏入 "伪敏捷" 的怪圈时, 如何发现这一问题, 就是我们要去解决的问题了.
什么是伪敏捷?
1. 极端的敏捷
1)"敏捷" 并不是一味的 "快"
谈到敏捷, 作为一种轻量级方法, 很多人误认为敏捷就是 "快": 快速反应, 快速交付. 因此整个团队只顾追求速度, 认为 "时间紧任务重", 以致于为了追求速度而不得不放弃质量. 这种以快速交付为重心的产品无法满足客户的需求, 甚至无法通过测试的质量鉴定.
2)"敏捷" 并不是一味的 "简洁"
敏捷十二原则中第 10 条为 "以简洁为本, 极力减少不必要工作量的艺术". 有的人就会说了, 既然要提倡简洁, 那么就把不必要的流程简化吧: 每日站会太浪费时间了, 减掉; 回顾会议毫无意义, 减掉; 准备文档太复杂了, 减掉; 敏捷提倡响应变化, 所以不需要计划会议了, 减掉...... 绝对主义者往往会觉得既然要简化就简化的彻底一些, 就要进行大刀阔斧的改革. 然而在一通乱裁之后, 真正有价值的东西被 "淘汰" 了, 留下一群摸不着头脑的程序员在重复繁琐的任务中继续敲代码.
2. 僵化的敏捷
1) 站立会议
每日站会是敏捷团队进行工作互通的桥梁. 每日站会不需要团队成员对自己的工作内容作出详尽而清晰的报告, 只需要用两分钟的时间进行一个简单的陈述, 总时长一般在 15 分钟左右. 这里的 15 分钟只是一个大概的时间, 具体时间会根据每个团队的成员数量以及工作性质而变. 在敏捷的实践过程中, 一些团队将站立会议的概念混淆, 只是死板地遵循 15 分钟会议时间的规定, 不论团队成员数量多少, 要求必须在 15 分钟内结束.
一旦会议时间被刻板化, 这会给团队成员增加很大压力, 促使他们不得已找些零零碎碎的任务来敷衍会议, 因此也就无法达到每日站会促进团队内部交流的目的.
2) 看板
敏捷团队中通常应用看板帮助团队实现任务可视化, 工作状态透明化, 激励团队成员工作, 提高工作专注力及效率. 但是在设置看板后, 也会一个很大的缺陷: 看板处于半闲置状态, 无法得到及时更新, 团队成员无法从看板中获取响应的信息. 这样的结果就是: 看板成为了一个代表敏捷的摆设. 负责人在汇报工作的时候, 一指墙上的看板: 看, 我们团队在转型敏捷. 但实际上, 敏捷的观念有没有深入贯彻, 除了团队内部成员, 其他谁也不知道.
3. 传统型领导的敏捷
之前写过一篇关于规模化敏捷变革的文章, 文中强调了在团队转型规模化敏捷之前, 首先需要领导者转型敏捷. 同样, 在传统团队转型敏捷的过程中, 也需要领导者率先转型敏捷, 具备精益敏捷思维. 只有精益敏捷的领导者才能通过挖掘, 利用团队和个人的长处推动团队的敏捷化.
我曾了解过这样一家公司, 领导者思维延续着传统的瀑布式开发模式. 当整个团队开始转型敏捷的时候, 领导仍在提倡开发流程的前后延续关系, 导致团队在实施敏捷开发的小周期迭代时遇到很大的阻力, 整个团队呈现出一种 "高不成低不就" 的状态. 如果公司内部都没有达成统一的敏捷转型态度, 这时的敏捷团队就会举步维艰.
因此, 要想打破敏捷转型效果不佳的 "诅咒", 就要勇于冲破团队现行模式的桎梏, 识破团队中的 "伪敏捷" 现象, 根据团队的实际情况适当改变策略, 真正做到让敏捷 "活" 起来.
来源: https://www.cnblogs.com/ittranslator/p/13800588.html