企业敏捷化的五大败因_转

Posted 2021-11-23 embedded-linux

转自：企业敏捷化的五大败因   https://mp.weixin.qq.com/s/XGEPJH8_H5KtlHgOd04OoQ

在充满不确定性和焦虑的黑天鹅时代，敏捷（Agile）已经不仅仅是一种软件或产品开发的“术”，更是决定企业数字化转型成败的“道”。但是大量企业在尝试敏捷化的过程中都失败了，原因有很多，包括企业文化和价值观的排异反应，以及方法和实施上的似是而非，舍本逐末。以下是IT专家John Cutler在Medium上发表的一篇干货文章，题为“敏捷为何失效？”，有助于帮助企业找到敏捷化受挫的症结，内容编译如下：

几年前我正在拜访一位亲戚——我那可怜的表弟（一家保险公司的首席执行官），被安利了“敏捷的银弹”后懊悔不已。下面是他的吐槽：

这是一个骗局！我们改变了做事的方式，我们引进了顾问，聘请了大师级的项目经理，没有任何效果，屁用没有！没有问责，我得到的只是借口

我忘记了我当时的回应，但我知道今天我会如何回应。我画了一些图示，其中甚至没有提到敏捷这个词，用来跟我的小表弟沟通一下敏捷的核心概念……

 

1.流程效率

首先，如果我们看一下交货时间，也就是从想法到交付客户的时间 – 你会注意到大部分时间花在“等待”上。只有15％的流程效率（工作时间/提前期）是正常的。疯了吧？然而，我们专注于（相对）可见的……实际用于完成工作的时间很少。敏捷化最好的公司能达到40％。简短截说，要想走得快，你需要解决等待时间过长的问题。

 

2.计划外工作和多任务处理

让团队在计划外工作和任务切换这两件事上消耗75％的精力并不罕见。该团队可能甚至没有履行基本的敏捷原则。这实际上是一笔沉重的开销，并且通常从未在ticketing系统中进行跟踪。这通常是最令团队沮丧的情况，但是被忽视了很久，于是团队接受了令人沮丧的现实。

现在设想一下，如果这是一个“共享服务”，团队既要负责解决生产问题，又要配置新的基础设施，同时还要做“项目”，分分钟就会遇到瓶颈。

经验教训：解决计划外工作的来源，并量化共享服务的经济影响。直觉上共享服务是很有意义的一个模式，但往往会忽视了它需要大量昂贵的前置计划。

 

3. 小杯、中杯和大杯（S、M、L）

这不是让罗永浩抓狂的选择题，而是一个有趣的技巧。绘制大，中，小工作项的完成时间。尝试提升一个级别并专注于实际客户价值（而不是任务）。您在许多组织中会注意到，工作的“大小”与完成时间无关。为什么？有太多其他因素会影响完成工作所需的时间（例如，依赖项，计划外工作，正在进行的大量工作等）

 

4.价值交付

我们花了太多精力来减少所谓的“交付风险”。如果您提供自定义项目并且客户支付现金交付，这是有道理的。在SaaS（软件即服务）中，我们在交付工作时无法获得报酬，只有随着时间的推移，才会获得累计收益。我称之为“效益风险”（做无用功的风险）。

大型组织采用敏捷看不到任何经济利益是很常见的。为什么？虽然产品发展比以前快了，但这与1）做出正确的产品决策，2）获得收益无关。敏捷的核心要点是交付价值而不是降低风险。在项目工作中，风险是“按时/在范围内”。在产品工作中，这种风险是“这玩意是tm坏的”。根源在于：项目主管“交付功能”时犯了集体性的谬误，他们忘记了自己的工作是交付价值！

许多公司采用左侧的模型。很少采用右侧的模型。当他们得到糟糕的结果时，他们会试图将更多的工作塞进系统，从而制造了一个更加悲惨的世界。

 

5.失控的复杂性

降低复杂性的一个方法是把一个易于理解的参考功能传递到整个产品开发系统。如果不管理复杂性/重构/自动化，每年完同样功能的周期将不断延长，

即使你的团队保持完全相同，做同一件事的周期从3天拉长到6周也不是个案。

 

敏捷

敏捷本身不产生价值，除非将它作为持续改进的催化剂。例如，Scrum和SAFe如果不能成为持续改进的催化剂，将毫无价值。为什么？因为减慢你速度的因素不在于你是在Sprint，编写用户故事还是双周演示。我认为那些事情相对没有那么重要（如果你抱着逐步降低风险的想法）。

为了真正从“敏捷”中获益，你需要花费大量的金钱和精力在下面这些事情上：

 

• 做真正重要的工作（交付价值）。

• 落实自动化，工具，部署管道，功能标记等（DevOps）

• 改变你的管理文化

• 调整您为项目提供资金的方式。从基于项目的支出转向基于任务的，逐步加码的支出

• 分配资源以管理复杂性（定期重构和重新架构）

• 映射价值流，并将您的业务视为服务生态

• 重新审视共享服务

没有银弹和万能药。你必须脚踏实地地去实践，同时不要人云亦云。