假装的敏捷,我好累

原文地址:
medium.com/columbus-eg…
翻译君:CODING 敏杰小王子网络

“敏捷已死”,人们一直这么说,但紧接着他们又说:“咱们只是开个玩笑”。其实这些人真正想表达的是你实践敏捷的方式已通过时而且愚不可及,而“真正的”敏捷未死,只不过你们实践敏捷的方式是错误的。所以,我认为理论上的敏捷是“真正的”敏捷。oop

最近我在网上也搜集到了不少古老的辩解:“可是有问题的是 Water-Scrum-Fall,而不是宣言当中的敏捷。” 紧接着 Bob Marshall 直言不讳道:“这位同窗请你闭嘴吧,敏捷宣言就是老调重弹。”他还说了一些我不得不一样意的观点,我思考了一下,下面就是我思考的结论。
阅读参考:
Water-Scrum-fall
www.infoq.cn/article/del…布局

这里有一个对你的测验:敏捷宣言的第一句是什么?不准偷看。不记得了的话,我来告诉你:“咱们正在探索开发软件更好的方式……”就此打住,注意到了吗,它说的是“开发软件”,并无说到“倾斜你的组织”、“偿还转型债务”、“用这种命令和控制废话切断它”、“专一于结果而且在发现领域的工做”、“修复你的中世纪预算系统”,或任何其它人们试图掩盖的更多有价值的东西。但问题是,当人们说敏捷属于整个组织时,它就是修正主义的历史,这是不诚实的。学习

在宣言开始的部分是:“咱们正在发现……”,它并无说:“咱们已从很是……得到……”。你不以为咱们从 2001 年开始意识到,大多数大型组织仍然停留在 1987 年。与流行的见解相反,下面的照片实际上并不是来自 Snowbird 签署的宣言,咱们是否是能够终于中止假装的敏捷了呢?优化

图片

宣言有它的目标,但它不会让你直接到达你要去的地方,因此咱们须要学习。咱们的知识是有保质期的,有时不像咱们预想的那么长。咱们身边总有些同事(一般是领导者)声称他们“没有时间学习”,而你知道他们只是对本身的认知过于自信。因此找一个丰富的书单,关注一些优质的博客,这是一个开始:若是你尚未阅读《Sense & Respond》、《精益企业》、《A Seat at the Table》以及《Everyone Is a Change Agent》,我建议你花时间学一学,也建议你的领导也读一读。
译者注:
《Sense & Respond》探讨了企业必须如何发展意识和应对战略,以利用这个网络化时代的机遇。
《A Seat at the Table》诠释了传统的 CIO 角色是如何与软件开发的敏捷方法相冲突的,探讨了在敏捷环境中 IT 领导人应该是什么样的。
《Everyone Is a Change Agent》介绍了在组织中如何进行变动以及推进变更。ui

开始阅读 John Cutler,Melissa Perri,Bob Marshall,Allen Holub,Laura Klein,Erika Hall,Neil Killick 以及由他们延伸开来的帖子。他们都相互认同(或与我认同)吗?不 —— 但他们很聪明,他们也会让你更聪明。阅读,而且鼓励他人。Fast Company 表示,CEO 平均每一年阅读 60 本书,你的领导读过几本书?而且他们平时都在读些什么呢?(HBR 的文章,Gartner 的报道,以及 Maeve Binchy 的小说都不算数)让咱们面对现实吧,若是你的领导者还在试图经过第六感意会 Scrum,那么大家的组织就会卡在 80 年代和 90 年代没法动弹。翻译

图片

因此让咱们达成共识,敏捷并非研发管理的银弹,团队要作到持续学习。须要说明的是:敏捷一直关注的都是本地优化,为系统带来的收益其实微乎其微。敏捷其实意味着把软件研发团队放到了显微镜下,仅从不少细节的角度去解读研发团队,不少时候这样是不公平的,并且这其实一点都不能提高组织的敏捷程度。有趣的是,Ken Schwaber 想过撤销瀑布流式开发方式带来的伤害,然而敏捷历来没有为企业或者组织提供一个总体可行的替代方案。这其中也有实践和理论存在差距的缘由,在实践中咱们须要务实,这也致使敏捷在实践中常常名不副实,这彷佛也是整个敏捷运动自己存在的问题。不管如何,还有更重要的事情能够学习,包括但不限于 DevOps、Lean UX、精益创业、Design Thinking 等等。设计

你可能会好奇为何 Lean UX 会在这个列表上,由于 Lean UX 注重最后的结果。若是你不知道想要建立什么样的改变,那么你将不知道该如何转变。若是没有明确的改变信号,那么你首先就不能真正“敏捷”,毕竟改变才是敏捷最关注的。也有人说敏捷主要须要即时观察和调整,可是我看到大部分敏捷团队都仅仅停留在机械地往已有工做中增长一些水泥,在 Jira 和 Rally 里倒腾,就像他们以前在其余地方建造砖墙同样。cdn

敏捷本质上倾向于掩盖核心问题,这是一种系统性的,双向都缺少垂直信任。事情在敏捷教练离开后会变得更糟糕,管理层和研发团队因为屁股决定脑壳,双方的沟通变成了鸡同鸭讲。研发团队会以为管理层根本什么都不懂,然而管理层们却在关注任务的精细程度、deadlines 和效率,忽略了不少时候 deadline 和工时预估都是拍脑门定的,其实毫无用处。blog

那你猜猜哪边会赢呢?两个阵营有两个大相径庭的视角,但有一个阵营得接受另外一个阵营的绩效评估。若是说研发团队就像是在盲人摸象,并讨论大象究竟是什么样的,那管理层就像是盲象踩人,并一致认为人就是扁的。惟一的出路就是认识到管理体系其实也是团队的一部分,别老搞那些本地的细节优化,而是要意识到信任才是第一要素。因此不要仅仅把研发团队放到显微镜下面看,而其余人都躲在小黑屋里不知道在作什么。

再者,在尝试敏捷的时候,必须中止像对待工厂工人同样对待研发团队。咱们不是在制造塑料餐具,咱们是在建立新的软件,咱们须要中止像开一个披萨店同样的管理方式,那种一直使用同一种配方来作披萨的方式是不适用的,咱们是在设计新的配方,是具备创新性的工做,而不只仅是循序渐进那么简单。忽视这份工做的创造性将会致使大量浪费:没人用的功能和没法带来结果的代码。这也暴露了敏捷的另外一个深层缺陷,它假设能够像对待小白鼠同样对待用户:“hey,你如今就用这个没什么用的功能吧,先用着咱们后面会改进的“ ,而后用户就头也不回地走了,将来的产品改进就成了无心义的浪费。

有人会说敏捷也能够做为创造性工做的工做方式,可是就像我刚刚说的,理论和实践是有鸿沟的。若是你真的想为团队作一些创造性的工做,想一想你跟敏捷团队的经历,你是会被团队承认并帮助团队更加精进,仍是常常被领导询问 “可否展现你作这个事情的意义”?就像 Alan Cooper 说的那样,当你常常被要求证实本身的价值时,你要清楚他们是在告诉你,当下的环境是不承认你的价值的。请注意,管理者要求我的贡献者证实本身的价值 —— 但不会问他的代码中有多少实际上会产生的正向结果。换句话说,他们仍然专一于人而不是工做自己,他们可能仍然专一于成本,而不是实际产出的价值。

因此若是你在一个敏捷团队中想作一些创造性的工做,下次被问到如何展现你的价值的时候,试着反问他以下问题:你知道项目延迟的成本是多少么?你使用哪些维度来测算?这个项目想实现哪些实质性的成果?项目中到底哪些资源和代码转化成了实际的成果?若是他们回答不清,能够继续问若是有更快、更便宜的方式来学习构建,而不是机械性的输出代码,大家是否有兴趣学习?大家如今的流水线效率如何?一天要花多少时间参加各类会议?若是有思惟训练和团建活动能在更短的时间内推进更好的决策,大家是否会感兴趣?由于我不会只告诉你我有多重要 —— 我会教你在每件事上创造更多的价值。

这要求的是另一种思惟,形式上更加关注战略层面。就像 Austion Govella 说的那样,敏捷和瀑布流的方式都过于关注构建,而不关注结果评估。若是你所在的组织没法正确的评估产出,你可能须要挪挪窝了。若是他们只是天天埋头苦干,成批的输出代码,仅仅关注成本,那他们仅仅是一个输出功能的工厂而已,伪装只是在创造塑料餐具而不是生产,他们也没法理解你的哪些行为能为团队带来更多增益。由于真正的价值是由研发工做中创造的选择来决定的,而这些选择则是由平常工做的持续学习和探索产生的。你能选择的东西越多则工做弹性越大,相应就会有更多种方法来创造价值。这个项目究竟是想达到什么目标?有没有寻找 3 到 5 种新的方法来实现这个目标?这些都须要经过更长期的规划来推进更好的决策。当只有一种选择时只能埋头苦干,两种选择是两难,但第三种选择的出现表明着能够正视利弊,团队才会真正前进。

并且这也是有理论支持的,你是否听过必要多样性理论(Law of Requisite Variety):在一个系统中,拥有最多选择的那个组件将能决定整个系统的走向。领导者试图将系统控制在最顶层,同时敏捷团队却试图将价值推向更靠近实际用户和客户,摆脱这种内战的方法是要让人们在各个层面都能拥有选择。出路并非寻求敏捷 VS 瀑布流的结果,而是一种明智的由上到下的瀑布流性战略方针,和由下到上的经验驱动战术相辅相成的管理方式。

因此人们应该在乎结果,而不只仅是产出量;更注重战略上的布局而不是一个个规划出来的里程碑。研发团队应该成为真正被信任的产品团队而不只仅是被看成一个项目团队来看待。给予研发团队如下自主性,让他们勇于去探索达成目标的最佳途径。

图片

最后总结一下,虽然吐槽了这么多,是否就意味着敏捷已经开始没落了呢?其实否则,这仅仅是我对如今各个组织或企业在实践敏捷时出现的一些问题的观察,再说若是没有敏捷运动,那我今天在这里所说的大部分结论也都失去了意义。因此我也不但愿敏捷就这么没落,我仅仅是但愿做为敏捷的实践者,咱们能更勇于直面其中的问题。

相关文章
相关标签/搜索