开发者真的需要敏捷开发？

所谓“热门”

“敏捷”俨然成为了热门。毫无疑问，由Scrum Alliance领导的通过ScrumMaster认证的风潮，导致我们现在蜂拥而来成百上千个所谓的“敏捷”教练和培训师，以及许多竞争性的框架和方法。所谓的“敏捷”领导力培训，“敏捷”项目管理产品，等等，层出不穷。

企业的快乐

当然，很多，或者甚至大部分这些产品都不是坏事，至少对于企业是这样的。尝试改进的组织通常确实可以得到改善，而且即使“敏捷”思路应用不当，尝试的过程仍然会为组织带来一些好处。组织至少可以更好地了解正在发生的事情，而这往往会使得即使是最不明智的管理层也能够做出更好的决策。很好，企业方面表示完全赞成。

开发者的痛苦

对于开发人员来说，这画面就没有那么美了，所有实际参与过构建“敏捷”企业产品的人员皆是心有戚戚然。“敏捷”理念的应用不良，往往会对开发者产生更多的干扰，使得他们用于工作的时间更少，压力更大，需求“更快”。这对开发人员来说是不利的，回过头来最终也会对企业造成不利的影响，因为拙劣的“敏捷”会导致更多的缺陷和更慢的进展。通常而言，优秀的开发人员会选择离开这样的组织，从而导致企业效率比之前还没装备“敏捷”时更低。

safe而非SAFe

这一条源自Kent Beck在十多年前所说的话。我希望这个世界对开发者来说是safe的。尽管历经多年的管理、咨询和写作工作，但我的本质依然是开发人员。今天早些时候我就在写代码，哪怕不是每天，至少每周我都会写代码。因此，在《Agile Manifesto》中看到“这会使得开发者的生活变得更糟而不是更好”的观点时，着实让我伤心了一把。虽然企业没有从中得到什么也让我感到难过，但我主要关心的是开发人员。

在过去的几年中，我听到许多开发人员在说“敏捷很糟糕”。而我则帮助那些人理解原因在于他们的组织使用的“敏捷方法”是错误的：企业没有做到Manifesto作者推荐的内容、没有做到Scrum建议的内容、或者没有做到许多敏捷软件开发专家推荐的内容。我希望听到我的解释之后，这些人可以帮助自己和他们的组织接近Manifesto Agile背后的真实想法，远离我们周围所见的各种形式的Faux Agile或Dark Agile。

这并不真正解决问题。虽然诸如“高级”Scrum培训和认证，以及以领导为中心的努力也挺不错，并且可能会随着时间的推移而获得成果，但进展缓慢，并且可能永远不会真正过滤掉“堆积如山的代码” 。

现在是时候接受新的观念了，那就是：

开发人员应摒弃“敏捷”

请注意，开发人员将继续在Scrum条件下或在使用SAFe的组织中工作。有些甚至可能会遇到像“DAD”这样更为晦涩的“敏捷”方法，或者如果幸运的话，采用的是更为开明的方法，如“Modern Agile”或“Heart of Agile”。有些人甚至可能足够幸运到发现自己正在进行极限编程，也被称为“The Scrum That Actually Works”。

能抓老鼠的才是好猫

尽管如此，我认为开发人员应该从任何特定的所谓的“敏捷”方法中解放他们的思想。不管它叫“黑猫”还是“白猫”，能抓老鼠的才是好猫。他们应该将他们的注意力和学习方向转向可以在任何这些“敏捷”方法中工作的软件开发方法。对我而言，开发方法涉及极限编程的使用实践，但不限于此。更一般地说，开发人员的工作应该坚持支持敏捷软件开发的基本原则，正如我们在编写Manifesto时所考虑的那样。这就是我们这篇文章的中心思想。

无论管理层认为他们正在应用什么框架或方法，学会以这种方式工作：

• 每两周生产一次可运行的、经过测试的、可工作的、集成的软件，然后每周生产一次。学习技能直到你可以每天创建一个全新的完全可操作的版本，然后一天两次，甚至一天多次。
• 保持软件的设计简洁。随着它的发展，设计将趋于复杂和笨拙。始终要有意识地抵制和扭转这种趋势，始终以微小的连续步骤进行重构，以便你的进度可以尽可能的稳定和一致。
• 使用当前的软件增量作为你与产品领导和管理人员进行对话的基础。就准备好的事情以及他们希望你下一步做什么来说明问题。

这是一个理智的开发团队的最大希望。软件的整装待发，可以让我们在最后期限内实现最佳结果。“今天是最后期限了？我们已经搞定了，随时可以发布。“

当我们接近截止日期时，当我们争执接下来要做什么时，我们手头的软件会让我们将谈话集中在下一个最重要的事情上，而不是天马行空。将重点从“做所有这些”转变为“接下来做什么”并不容易，但这会让我们的生活变得更容易，而且也使得改变的可能性更大，因为我们是与领导者合作而不仅仅是在他们的指挥下工作。

人在江湖

通常情况下，团队使用的“敏捷”方法往往是强制的。实际上大规模的“敏捷”方法似乎就是建议强制的。这里包括所谓的“SAFe”方法、Scaled Scrum和LeSS等等。这些方法进入到企业，就像蝴蝶的翅膀，引发了一场龙卷风。

作为开发人员，你可以肯定的是，这样推出方法是不会顺利的，也没有以一种真正的敏捷方式进行。你不可能接受培训，得到的教导微乎其微，更不用说提供的真正可用于完成工作的帮助了。可能你的领导已经接受过培训，甚至用了整整一周时间，以便于他们可以准备好面对组织生产方法和软件开发中出现的彻底改变。总而言之，道路是崎岖的。

现实软件是你唯一的救赎。——Leia

但是，如果你可以可靠地选择在“Sprint”或“boxcar”的过程中完成工作，或者无论你发布什么，列车售票员都开始调用时间段并完成该工作，将其打包为可运行，已测试，已集成，即将推出的新系统版本，那么你将能尽最大努力实现这个目标。

放慢交付速度

如果你不能很好地解决这个问题，那么我建议你在每个时间段内减少工作量，直到工作批量足够小到你实际能够完成。这很难！总是会有人死命地催你“跑快点”。尽你所能吧！在压力下签署超出能力范围的工作量，我的建议是从事一两项工作，直到完全完成——完全打包、经过测试和可工作——然后再做另一项工作，以便在boxcar的最后你有绝对可以称之为“完工”的内容。不要采取广撒网的策略，以免最后反而一事无成，尝试从现实出发来制定计划和期望，不要幻想那些虽然是要求的但从来没有机会做的事情。

这个过程肯定不是完美的，至少一段时间内如此，甚至可能也不会很有趣。然而，这是我知道的在代码山中生存下来的最好机会。拥有完成的可运行的产品片段是我知道可能改变代码山这种状况的最佳方式。在糟糕的情况下，我们所能做的就是尽我们所能，努力让事情往好的方面发展。

显然，在一个更开明的组织中，或在一个保持学习的组织中，事物才会越来越接纳真正的Manifesto敏捷思想。我们的编码生活将得以改善，这正是我的期盼。

我一直处于这样的处境中，除了离开之外，我所知道的最好的就是做好工作，让软件保持可见，可运行，经受得住测试和整合，并帮助人们实现现实事务。

选择一种方法

Manifesto呼吁“自组织的”团队，最好的情况就是，团队选择适合自己的流程。如果我创办一家公司，那就让团队自己选择他们想要的流程。

要求结果，而不是特定的过程

然而，这是有限制条件的，限制不在于他们如何选择工作，而在于我需要看到结果。我会清楚地说明，至多每两周，我会回顾他们正在运行的测试产品的片段。他们会展示给我看他们计划构建什么，以及他们已经构建好了什么。这样的要求使得他们不得不实实在在地致力于工作，并包含我可以理解的可见功能。我们会谈论他们在下一个时间段应该做什么。我会清楚地说明一周回顾一次优于两周回顾一次，一天回顾一次优于一周回顾一次。

提供帮助

我会为他们提供帮助。我会提供一个与业务需求紧密联系的人，他将帮助他们决定下一步要做哪些工作。我会提供培训和支持，以帮助他们需要完成的工作。我会确保他们有能力做我要求他们做的事情。

当然，我会这样做是因为我知道怎么做。如果你够幸运的话，可能正处于与此类似的情况中——至少可以选择自己的流程。

看我极限编程！

如果你有机会选择，我建议你从极限编程开始。它包含所有你需要的规划和反馈循环，包含完成我们在此讨论的那些基本技术实践，帮助完成我所要求的工作。

建议随时保持警惕，注意你所需的其他东西。 “ATDD，TDD和重构”就是我认为需要注意的东西，当然可能你知道更好的。但是，你还需要许许多多其他的东西。保持警惕，以便于可以随时识别并获取。

制作出卓越的软件是一项终身的活动。即使是极限编程——我所知道的最好的官方命名的方法——我也只是略懂皮毛而已。走向卓越取决于你的团队及其成员。

总结

我真的认为软件开发人员不应该遵守任何类型的“敏捷”方法。因为这些方法体现在实际中时通常是软件开发的敌人，而不是朋友。

然而，敏捷软件开发宣言的价值和原则仍然提供了我所知道的构建软件的最佳方式，并且根据我资深又丰富多彩的经验，无论大型组织使用何种方法，我都会遵循这些价值观和原则。

最后声明，我以建议的形式提出这一意见。请按照你认为合适的方式去做。