关于敏捷失败常见原因的漫谈

[evazou2020]

---

1. 敏捷失败的原因： 在日常生活中，有种有趣的现象：我们更津津乐道于美好的故事，比如提到好莱坞，我们关注的只是大牌明星，却忽略了他们成名其背后的艰辛。对于那些成功的敏捷项目，也是如此。在我们见证成功的同时，却忘记了项目团队孜孜不倦的努力。而所有故事只有成功的那一面吗？No！也许消极的背面没有那么让人喜闻乐见，但是如果我们乐于借鉴就有助于避免重蹈覆辙。 许多报告指出，只有42%的敏捷项目成功于"敏捷"，其他58%的项目在挣扎（50%）或失败（8%）! 那到底是哪些做法上的差异导致其失败呢？行于敏捷或形如敏捷，听起来不同，其实它们非常类似，区别只是在于用法。 让我们来看看一些居首的失败原因，大致可以将它们归纳为PA-SA-WA-KA-DA。 Pseudo Agile (PA)——伪敏捷 当传统组织想在敏捷方法上碰碰运气时，他们通常会培训部分员工来取得一些市面上流行的扩展框架的认证，继而，这些员工会竭力推广并以敏捷化的方式完成日常工作。“瞧！我们也是敏捷！” 然而当他们以类似炫耀般的方式来安稳客户时，敏捷化的努力往往变为徒劳。这种依靠传统的角色定位，自上而下来驱动的工作方式，尽管假以敏捷之名，但是由于其缺乏严肃性往往不会有什么结果。 Superficial Agile (SA)——表面上的敏捷 不知道你有没有遇到过一群人聚在一起热热闹闹的敏捷秀? 这就是我想举的例子 - 肤浅的敏捷。积极的来看，他们还算有自知之明(但这并不妨碍吹嘘他们的敏捷精神)，不幸的是，这并不会让他们产生什么成果。如果你并不希望实践敏捷，并且你更擅长传统的方式，那就应该更专注的贯彻后者，总好过于消极的去实践敏捷。 We Also Know Agile (WAKA)——李逵,还是李鬼 如今我们有了许多的敏捷领袖和布道师。但是当你认真审视，这其中多少是有真才实干，能做到名副其实的，又是另外一回事了。那些富有实战经验的有希望取得不错的成果，反之，另一些仅仅做了些擦边球式的工作，往往不能贡献什么实际价值。记得，我曾见过一些研究员，他们非常自豪的声称也懂得所谓的敏捷，但作为帮助一个稳定的敏捷项目的第一步，却是每周介绍两次新的会议（每次1-1.5小时左右），听取开发人员的问题。简直了！ Do Agile (DA)——形式主义 这是一个古老的故事：上层说,要有"敏捷",就有了"敏捷"。尽管没有任何预算以及自主权方面的支持，尽管交付的产品基本上仍然是原来的那些东西，却仍被贴上"敏捷"的标签。很显然，没人能获得什么好处。(但并不妨碍领导层可以声称"我们的团队也在做敏捷项目,在我们的亲自指挥下进行的哦") 所有的这些场景中，失败的过程都类似。他们尝试，他们受苦，然后在徒劳的尝试中，为了应对期望的压力，他们的交付遭遇了低质量和失败的时间表。最终，等到高层介入想要挽救这一切时，已经太迟了。谁来背锅呢！自然是敏捷咯！没点用！ 这就是前文所述那58%的由来。若想成就于敏捷，你所需的只是常识。如果觉得它有用，便照着Scrum指南，保持开放的心态去学习。菩提本无树，明镜亦非台。本来无一物，何处惹尘埃。 原文作者：Arijit Sarbagna 译者：Worktile 刘亮 Worktile 官网：worktile.com 文章首发于「Worktile官方博客」，转载请注明出处。

2.那什么才是有真才实干的敏捷教练，什么才是真敏捷呢？

• 实践敏捷核心价值观的教练就是实干的
• 我觉得不用纠结概念，是不是带来了真正的收益才是需要关注的
• 符合敏捷核心价值观的团队或组织就是敏捷
• 通过收益倒推是不是由敏捷带来的，如果是，就不用纠结是不是真敏捷了
• 敏捷本身就是一种思想，会指导大家的工作，但不会框死在工作方法，还是需要不断体会思想，不断调整适合自己团队的工作方法
• 敏捷只是把开发量化得更细了，但并没有代表节约时间。

3. 创业项目的敏捷做法 我们在创业期的做法是：1，把设计、计划做了；2，站会跟过程；3，看板跟进度。没做敏捷。 计划确定是倒推出来的 敏捷要求计划时间，现实时间是老板要求的。 那应该先影响老板 创造敏捷环境

4. 需求源头的常见问题 需求是源头，产品经理乱来，团队节奏就容易乱，更不用谈敏捷 说到头来还是目前没有真正的产品负责人，产品经理不是产品负责人 和产品经理吵架，最终都是老板拍板 如果产品经理经常出现这种情况，那么是不是可以认为产品经理向上管理做的不好 产品负责人实际是由(销售，老板，产品经理，运维经理，项目经理)组成的，他们之间要是信息互通不及时，产品经理就乱拍脑袋。

5. 关于老板对敏捷的认识： 老板理解的敏捷一直是快，不是我们说的敏捷。如果时间都是老板定的可以有两种方法处理：1，人员不够的情况下，减需求；2，人员够时，多争取利益。 敏捷是快速交付功能价值，不一定是开发效率高； 快速交付价值，关键是价值没有有效传递 “软件开发”名称中的词汇。发展是对新事物的创造，它本质上是探索性的。 冲突: 提前要求完整的项目定义违反了Scrum经验过程控制的原则。它无视对变化做出反应的价值，这也可能违反确立可持续发展步伐的原则。团队将不可避免地落后于计划，并在项目的最后一个月被要求奉献出他们的夜晚和周末来“赶上”进度。 要求开发团队预估他们从未做过的事情的工作量是没有意义的。此外，这项工作的时间安排：没有一行代码是编写的，但开发人员应该理解项目的每一个细微差别，并准确地估算它。迭代开发的好处就永远不会被认识到。 再没有办法量化价值之前，先看客户需求优先度

6. 敏捷转型的入口和范围： 敏捷不仅仅是开发过程或方式转变，体系建设，组织建设都是需要的，都是有过程的，不是说拿来就马上解决很多遗留问题 这就要分清做事轻重缓急 所以企业敏捷转型是个非常漫长的过程，抓到机会，有突破口，就前进一步，否则就得等待 没有突破口还想向前，势必需要高层的支持 感觉必须把老板拿下才行，其它的就算了吧 所以必须搞上层路线啊，否则，真的不行 然后问题又回来了，“我们推行敏捷不就是要快，节约成本吗？如果不能提高效率，我们费这事干嘛” 这个感觉需要团队负责人以“尊重人”的角度，来跟老板聊了 说服老板不从节约成本思路考虑问题， 老板的思维就是收入 -成本 = 利润，收入提不高，成本就必须降下去 说服老板需要专业人士引导外行改变思想。

7.敏捷的应用误区 错误的理解变成否定敏捷； 因地制宜，不是先有了敏捷的环境，再去推敏捷；