敏捷开发

敏捷为什么会失败之「PA-SA-WAKA-DA」理论


在日常生活中,有种有趣的现象:我们更津津乐道于美好的故事,比如提到好莱坞,我们关注的只是大牌明星,却忽略了他们成名其背后的艰辛。对于那些成功的敏捷项目,也是如此。在我们见证成功的同时,却忘记了项目团队孜孜不倦的努力。而所有故事只有成功的那一面吗?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 刘亮

智齿客服