“敏捷”已然成为一门“大生意”。以 Scrum 联盟认证 Scrum Master 为首，我们看到了成千上万所谓的“敏捷“教练和培训师，以及很多相互竞争的框架和方法，比如“敏捷”领导力培训、“敏捷”项目管理，等等。

或许这些不算是坏事，至少对于企业来说。想要进步的企业通常会进步，即使“敏捷”思想没有得到充分应用，付出的努力也不会白白浪费。至少，企业知道这当中都发生了什么，即使是最不开明的领导层，也会因此知道该怎么做出更好的决策。从这方面来说，事情是好的，我完全赞同。

但对于开发者来说，就不是这么一回事了。当“敏捷”思想没有得到充分应用，只会给开发者带来更多的干扰和更大的压力，消耗他们的时间，让他们感觉像是被鞭子抽着往前赶。这对开发者来说不是好事，而最终也会对企业不利，因为糟糕的“敏捷”实践只会造成更多的缺陷和更缓慢的进展。好的开发者通常会因为这个而离开企业，而对于企业来说，“敏捷”比“不敏捷”更加糟糕。

我的想法来自 Kent Beck 十多年前说过的话——我希望这个世界对于开发者来说是安全的。我骨子里是个开发者，尽管做了多年的管理、咨询和写作工作。我几乎每周都会写代码。看到“敏捷宣言”里所宣扬的想法并没有让开发者的生活变得更好，而是更糟糕，我感到很伤心。企业也没能从“敏捷”中得到应得的好处，我也感到很悲哀，不过我最关心的还是那些参与敏捷实践的人。

多年来，我听到很多开发者吐槽“敏捷”。我试着让他们明白，其实是他们所在的企业没有做好“敏捷”，他们没有按照“敏捷宣言”作者和敏捷软件开发专家说的那样去做。我希望和我有同样想法的人能够救救自己，救救所在的企业，真正理解“敏捷宣言”背后的想法，远离那些到处可见的伪敏捷和暗黑敏捷。

但事与愿违，一些“高级”的敏捷培训和认证以及来自领导力方面的努力或许可以开花结果，但进展缓慢，而且可能永远都触及不到真正的开发者。

是时候尝试一些新的东西了。

开发者应该放弃“敏捷”

开发者会继续在敏捷环境或使用 SAFe 框架的企业里工作。有些人甚至会遭遇隐晦的“敏捷”方法，比如 DAO。或者如果足够幸运的话，他们会遇上更加开明的方法，比如“现代敏捷”或“敏捷之心”，有一些还可能从事极限编程。

话虽如此，我认为开发者应该抛弃任何与“敏捷”方法论相关的想法，而是把注意力放在那些在“敏捷”方法论之下行之有效的软件开发方法上。这些开发方法包括了极限编程，当然，不仅限于此。开发者的工作应该遵循敏捷软件开发的基本原则，正如我们在撰写敏捷宣言时所想的那样。我将这些想法总结如下：

无论管理层认为他们在应用什么样的框架或方法，都要按以下这些方式展开：

每一两周都要交付经过测试的可运行软件。锻炼你的技能，直到可以每天一次、每天两次甚至是每天多次发布可运行的版本。
保持整洁的软件设计。随着规模的增长，软件的架构设计会趋于复杂。有意识地抵制并扭转这种趋势，通过持续小步快跑式的重构来尽可能保持稳定和一致的进度。
将软件的当前增量部分作为与产品领导层对话的基础，告诉他们哪些事情已经就绪，并询问他们希望你接下来要做什么。

对于开发团队来说，这是他们最有可能过上理想生活的方式。让软件保持就绪状态，我们就能够以尽可能最好的结果应对任何一个截止日期。“今天就是截止日期了？我们已经准备好了，可以交付了”。

随着越来越接近截止日期，当我们在商讨接下来要做什么时，我们会将谈话的重点放在接下来要做的最重要的事情上，而不是他们脑子里几乎无穷无尽的想法。从“把所有东西都做出来”到“接下来要做这个”的思维转变有点困难，但这是让开发人员过上美好生活最佳时机。当我们以协作的方式与领导者共事，而不是完全听命于他们，就很有可能把这种焦点转变过来。

被强制推行的敏捷

通常，团队所使用的“敏捷”方法是被强加的。大规模“敏捷”方法实际上就是建议强加流程，包括所谓的“SAFe”、可伸缩 Scrum，等等。这些都是针对企业的，要求企业去“推行”它们。

作为一名开发人员，你可以肯定这种方式不会得到顺利推行，也不会实现真正的敏捷。你可能接受不到培训，在工作上也获取不到必要的帮助。你的领导可能会接受培训，一培训就是一两周，他们为这些即将给产品和软件开发带来彻底改变的东西做足了准备。但这条路可能有点难走。

不过，如果你能够稳定地在每一个 Sprint 里把工作做好，把系统打包，运行、测试、集成，然后等待发布，就有可能获得最好的结果。

如果你做不到，我建议你还是在每一个 Sprint 里少做一些事情，直到可以把这一阶段内的东西都做好。但这也很难！因为人们会催促你，要你尽全力往前赶。顶着压力超负荷运作，还不如每次只完成一两件事情，等把它们都做好了，再去做其他的，那么在 Sprint 结束的时候，你才有已经完成的东西拿出手。坦然接受因为未能完成所有事情而遭受的指责，试着让计划和期望更接近现实情况，而不是那些你永远都没有机会去做的东西。

事情不会那么完美，而且在一段时间内，也不会那么有趣，但这是我所知道的最好的生存契机。完成可运行的产品片段是扭转局势最好的方式。如果情况不妙，我们所能做的就是尽我们所能，让事情尽可能好起来。

很显然，在一家开明或者有持续学习意愿的企业，很多东西都会对真正的敏捷持开放态度。生活会更美好，我也希望如此。

我经历过这些，我知道最好的方式是把工作做好，保持软件的可见性，让它运行起来，进行测试和集成，并帮助人们认清现实。

选择你的敏捷方法

敏捷宣言呼吁团队的“自我组织”能力，在最好的情况下，就是指团队可以选择自己的流程。如果我自己创办一家公司，我会让团队自己选择他们想要的流程。

当然，还是有一些限制的，但这种限制不在乎他们的工作方式，而在乎我需要看到什么。我会告诉他们，最多每两周我需要评审一下他们完成的产品片段。他们需要向我展示他们的计划以及已经完成的东西。产品片段必须是可运行的，并且包含我能够看到和理解的功能。我们会讨论下一阶段需要做哪些事情。我还会告诉他们，如果一周可以完成，就不要做两周，如果一天可以完成，就不要做一周。

我会给他们提供帮助，让对产品需求很了解的人帮助他们决定后续的工作。我会给他们提供培训和支持，帮助他们更好地完成工作。我会确保他们有能力去完成我所要求的事情。

当然，我之所以这么做，是因为我心里很清楚这些事情。你可能也会很幸运地遇到类似的情况，至少，你可以选择自己的流程。

如果你有机会做出选择，我建议从极限编程开始。极限编程提供了必要的计划和反馈闭环，还提供了一些基本的技术实践，这些技术实践是你完成目标所必需的。

另外，我建议你时刻对你的需要的东西保持警惕。在我看来，“ATDD、TDD 和重构”这些东西正是你需要的。当然，除了这些，你还需要其他很多东西。保持警惕，当它们出现时，抓住它们。

追求卓越的软件开发是一项终生的活动，即使是极限编程也只触及到表面而已。是否能够走向卓越，这取决于你的团队。

总结

除了极限编程（我们可以把它看成是一种思想而不是方法），我认为开发人员不要拘泥于任何一种“敏捷”方法。正如这些方法在实际当中所体现的那样，它们通常是开发者的敌人，而不是朋友。

不过，敏捷宣言的价值和原则仍然是用来指导软件开发的好方法。从我长久以来的经验来看，无论企业使用了哪一种方法，我都会遵循敏捷宣言的价值和原则。

我把这些作为建议提出来，如果你觉得适合你，可以尝试一下。

原文链接

Developers Should Abandon Agile

创作场景

开发人员应该放弃敏捷