我讨厌说说而已的敏捷

阅读数:1817 2019 年 10 月 28 日 11:16

我讨厌说说而已的敏捷

现在总有人说“敏捷死了”,然后又说“我们是开玩笑的”。他们想表达的意思是,敏捷本身并没有死,是我们的敏捷实践方式出了问题。那么怎么做才是对的?或许真正的敏捷只存在于理论之中?有时候我也会这么说,但现在已经感到厌倦了。

网上有很多替敏捷辩解的观点:“有问题的是瀑布式 scrum ,而不是《敏捷宣言》中所宣扬的敏捷……”但 Bob Marshall 却直言不讳地指出:“《敏捷宣言》已经是老黄历了”。然后他说了一些令我信服的观点,经过一番思考之后,我写下了这篇文章。

知道《敏捷宣言》第一行写的是什么吗?不知道吧?没关系。它是这么说的:“我们正在探索更好的软件开发方法……”请注意,这里说的是“软件开发”,并没有说“如何让组织变得更精益”、“如何偿还向敏捷转型而欠下的债务”、“如何专注结果”、“如何修复老旧的预算系统”,或者其他任何可以增值的东西。

另外请注意,它说的是“我们正在探索……”,并没有说“我们已经……”。从 2001 年发表《敏捷宣言》以来,我们就没有学到什么东西吗?有是有,但大部分企业的状态似乎仍然停留在 1987 年。

《敏捷宣言》自然有它的用意,但不会把你送到你想要去的地方。所以,继续学习吧。我们的知识是有保质期的,而且这些保质期比我们认为的要短得多。我们的同事(通常是领导)经常会说“没时间学习”,可能是因为他们对自己所知道的东西太过于自信了。所以,列一个书单吧。如果你还没读过这些书:“Sense & Respnd”、“Lean Enterprise”、“A Seat at the Table”和“Everyone Is a Change Agent”,那么开始读起来吧,让你的领导也读一读。

你也可以看看这些大师的博客,比如 John Cutler、Melissa Perri、Bob Marshall、Allen Holub、Laura Klein、Erika Hall、Neil Killick,等等。他们的观点会一样吗?或者会和我一样吗?不会。但他们都是聪明人,看他们的博客也会让你变聪明。《Fast Company》杂志说,企业 CEO 平均每年会读 60 本书,那么你的领导会读几本?为什么要让他们读书?因为如果他们的知识不更新,总以旧眼光看待 scrum,那么你也会被死死地禁锢在 80 年代或者 90 年代。

所以,我们要持续学习,不断更新知识,不要把敏捷当成万灵丹。可以这么说:敏捷只为整个系统提供局部优化。敏捷所做的只是把软件开发团队放在一个局部空间,并不会提升整个组织的敏捷性。Ken Schwaber 说,敏捷试图“收拾瀑布开发留下的残局”,但却从未提供全盘可行的替代方案。毕竟实践和理论之间是有差距的。当我们抱怨“AINO”(Agile In Name Only,名义上的敏捷)时,我们要先扪心自问。

我们要面对这样的事实:实践中的敏捷大部分都只是名义上的敏捷。这看起来好像是敏捷运动的错,不是吗?但不管怎样,我们还有很多重要的东西需要学,比如精益用户体验(Lean UX)、精益企业(Lean Enterprise)、超预算(Beyond Budgeting)、约束理论(Theory of Constraints)、产量会计(Throughput Accounting)、设计思维(Design Thinking)、DevOps 和组织治疗(Organizational Therapy),等等。

你可能会问,为什么精益用户体验会排在最前面?因为精益用户体验强调的是结果。如果你不知道要做出怎样的转变,也就不知道该做些什么。如果没有明确的方向,你就无法变得“敏捷”。敏捷的核心就是要快速转变。可能有人会说,“除了这个,还有自省和调整”。话是这么说,但在实践当中,我并没有看到有人进行自省和调整。我只看到敏捷团队不断地从积压待办的任务列表里领取任务,倒腾 Jira 和 Rally,就像搬砖工人一样一块一块地往上砌墙。

敏捷通常会把缺乏垂直信任的核心问题隐藏起来。等敏捷教练离开之后,事情会变得更糟糕。管理层和开发团队之间的沟通变成了鸡同鸭讲。开发团队认为管理层什么都不懂,管理层则认为应该把精力集中在任务范围、截止日期和效率上,却不曾想这些截止日期都是拍脑袋决定的,而预估时间什么的其实是一种浪费。

那么这两者谁会赢?他们看问题的视角完全不同,但无奈的是,其中一方的绩效评估是由另一方决定的。开发团队就像是盲人摸象,他们可能摸到不同的部位,然后得出不同的结论。而管理层则是瞎了眼的大象踩在了人身上,他们得出了一致的结论:人是扁的。解决这个问题的唯一办法是要认识到整个团队是一个完整的系统,不要只是做局部优化,而且要把信任放在首位。

开发团队不是工厂生产流水线上的工人,我们不是在生产什么塑料餐具,我们生产的是软件产品。我们不能用经营披萨店的方式来运营团队。做披萨和开发软件是不一样的,做披萨用的是同样的菜谱做出同样的披萨,而开发软件是一项具有创新性的活动,我们要自己设计菜谱。或者说开发软件是一个发现的旅程,不仅仅是按部就班地交付东西那么简单。如果意识不到这一点,就会造成巨大的浪费:开发出来的功能没有人用,开发团队付出的努力得不到相应的结果。这暴露出了敏捷的另一个深层问题:把用户当小白鼠,让他们先把产品用起来,后续再加以改进。但面对糟糕的产品,用户头也不回地走了,后续的产品改进纯粹就是在浪费资源,因为用户根本不买账。

有人会说,敏捷其实也关注创新性的工作。如果你主要从事设计或创新性方面的工作,那么请回答以下这些问题:在跟敏捷团队合作的时候,他们是怎么对待你的?他们认为你会给他们带来价值并帮助他们进行自省和调整吗?或者他们有要你体现出你存在的价值吗?Alan Cooper 说过,如果你被要求体现出存在的价值,那无异于是在告诉你:在这个系统里,你是没有价值的。请注意,他们要开发人员证明自己的价值,而不关心开发人员写了多少可以带来正向结果的代码。换句话说,他们关注的仍然是人,而不是工作本身。他们仍然关注成本,而不是价值,所以有很多价值从指缝间悄悄溜走了。

如果下次还有人要你“证明自己的价值”,你可以问他们:延期交付的成本是怎样的?怎么评估这些成本?具体的目标是什么?达成这些目标所对应的工作量占了总工作量多大比例?如果他们回答不上来,你可以继续问:如果有更好更快的办法可以知道该做些什么,而不是仅仅是机械式地交付代码,他们愿意学吗?他们的工作流效率是怎样的?他们在不必要的会议上浪费了多少时间?如果有一些做法可以在更短的时间内推动更好的决策,他们有兴趣去学习吗?

这是另外一种思维方式,一种元思考,一种战略性思考。Austin Govella 说,敏捷和瀑布关心的是如何构建软件产品。如果他们只是埋头交付代码,关注成本问题,他们就永远都不会意识到他们只能获得更多自己关注的东西(也就是成本)。他们变成了一个交付软件功能的工厂,就像是在生产塑料餐具。但其实你可以有其他选择,你可以做更有价值的事情,而有价值的事情需要去发现。当你发现了更多选择,也就获得了更多可以产生正向结果的途径。想要达到怎样的目标?有没有找到三五种达成目标的方式?当只有一种选择的时候,你没得选择;当有两个选择的时候,你陷入了两难的境地;当有三个甚至更多的选择的时候,你总能选择其中一条路走到你想去的地方。

你有听说过“必要多样性定律”(Law of Requisite Variety)吗?这个定律指出,在一个系统中,具有最多选项的组件将拥有系统的控制权。基于这个定律,我们可以这么想:管理层想要在顶端控制整个系统,而敏捷团队想要向实际的用户交付价值,如果想要结束这种对立局面,就要让处于各个层面的人都有的选择。解决办法不是在敏捷或者瀑布之间二选一,而是要将自上而下的瀑布策略和自下而上的经验驱动策略相结合。

说了这么多,总结一下解决办法:有清晰的目标,不要太过关注产出,用路线图代替里程碑,与可信任的产品团队合作,发现获得价值的最短路劲。

所以,这意味着敏捷要“死”了吗?当然不是,我认为敏捷还没有死,我也不希望它死掉。敏捷运动的价值在于它可以帮助实现文中提到的一些想法。但需要注意的是,敏捷运动和敏捷实践是两码事,敏捷实践实际上比敏捷运动要早出现几十年。

原文链接

Dear agile I’m tired of pretending

评论

发布