作者：Alesia Krush是软件开发公司ObjectStyle的营销和传播经理。几年前我写过一篇文章（https://www./agile/agile-scrum-kanban-lean-xp-comparison），详细介绍了各种敏捷方法之间的区别。那篇文章由DZone.com重新发表，其中一则评论如下：Alex Euka：任何这些方法对开发人员来说都过时了。 在开发人员的实际工作中，没有人遵守。 拜托，请发明对管理人员和开发人员社区来说比这些框架更有用的东西。不然开发人员想要回过头去，他们已经在回过头去使用经过实践检验的聪明想法，而不是所有这些受到Kanban、Scrum、敏捷和XXX限制的框架。
没过多久，我在Reddit网站上偶然发现了这个题为《简而言之，为什么许多开发人员不喜欢敏捷？》的帖子。在该帖子中，许多开发人员表达了他们对敏捷的“感受”。以下是这则讨论的几个重点内容：重点内容1：敏捷=随意的目标和不切实际的截至日期。重点内容2：敏捷=“繁文缛节”，没有开发人员发挥创造力的空间。那么，敏捷运动到底出了什么问题？它的最终目的不应该是“人员比流程更重要”，并最终消除所有官僚作风和中间环节吗？Robert C. Martin是2001年拟定原始《敏捷宣言》（Agile Manifesto）的人之一，他在这个话题上有很多话要说。谈到敏捷的历史和未来时，他指出，敏捷——Kent Beck及其他发明者最初设想的一种方法——长期以来被一大批通过认证的Scrum master和不了解软件怎么开发的业务人员所劫持（就好比城市里的孩子不知道土豆怎么变成薯片）。[敏捷]认证变成了这个“诱人的歌声”；坦率地说，它吸引了所有不该吸引的人。敏捷是由技术人员开发的。它是软件行业的产物——程序员坐在那个房间里，搞出了《敏捷宣言》和敏捷原理。随后出现了认证。通过认证，成群结队的项目经理开始获得认证。他们会在课堂里坐上两天，拿来一张纸，觉得敏捷很重要。而他们实际上接管了敏捷运动……敏捷运动朝着项目管理方面急剧转移。于是据Robert C. Martin声称，敏捷方法最初是由程序员为程序员创建的。但是现在它已经偏离了轨道。现在看到的是分裂（敏捷方法的最初想法被缺乏思考的管理所污染）后出现了反向运动。这股反向运动就是软件工艺（Software Craftsmanship），它也有其宣言。很显然，它试图回到敏捷的最初承诺，据Kent Beck声称，这个承诺就是填补业务人员与编程人员之间的鸿沟。它还竭力解决敏捷的症结所在，即催促开发人员不仅交付“可运行的软件”，还交付“精心设计的软件”。这就引出了下一个重点……请原谅我使用了Cherchez la这个法语单词。我所要表达的意思是，找出造成敏捷问题根本原因的技术债务。下面是炮轰敏捷方法的其中一篇文章的读者评论：我从没听到有人说过，但是我一直以来看到的是：敏捷是推迟棘手项目的根本原因。它堆积了技术债务，堆得又快又高，原因是我们专注于可还原、可扣除、可简化的问题。而当这堆技术债务倒塌时，也就是它变得政治化的时候，我们非常糟糕地回到了起点。Robert C. Martin在另一次会议上也猛烈抨击了技术债务问题（附有强调）：你需要让你保持干净的东西，因为你需要防止代码腐烂的机制。我们在房间里有几个开发人员？其中多少人的进度因步伐过快的Scrum团队生成的错误代码而大大降低？如果你迈得太快，专注于讲完故事，一个个故事讲完后……代码就会腐烂，腐烂速度与你迈进的步伐一样快。因此，一年后会出现步伐开始放慢的情况。不是由于你工作不如以前拼命——你在付出极大的努力，而是你不能强迫代码接受下一项新功能。现在，没有任何一个头脑清醒的程序员想要编写糟糕拙劣的代码。然而，想要新功能尽快交付的业务人员常常迫使他们这么干。因此，最终团队无法像以前那样快地迈进了。项目经理/ Scrum master/敏捷专家是否明白这一点？一些人明白，但是很多人不明白。因此，开发人员有责任向经理提出这个问题，免得他们草率编写的“大杂烩式代码”要了某人的命。当然，并非所有软件都有可能严重伤害人（感谢上帝！），但是也有可能造成间接损害。有一次，我还在一家电信公司工作时，一名女士打电话给客户服务部门，抱怨由于联系不畅，她订购不了需要的一些紧需药品。因此，在理想环境下（如果你想要“搞好”敏捷），应该让开发人员有足够的时间来清理/重构，并仔细考虑功能，以便使软件易于长期维护。敏捷方法已经存在了近二十年。大量的案例研究表明，敏捷方法可以改善公司的流程和软件质量：思科的严重/主要软件缺陷减少了40%，英国电信能够将交付周期从12个月缩短至90天，这完全归功于敏捷方法。你可能会说，也许是大公司有人力和财力来明确管理技术债务，小公司则没有。因此，这是每个人最终都需要做出的取舍……我敢肯定，你们中许多人都很熟悉网上盛传的这个视频，即以不同的速度绘制蜘蛛侠。如果你对开发人员催促得过紧，你获得的那种软件其质量也就可想而知。 那么，敏捷能否重新实现填补业务人员与程序员之间的那条鸿沟这个初始使命？我猜想，只有我们开始关注在一些地方出现的不必要的官僚作风和一些项目上不断积累的技术债务，这一幕才会发生。对于敏捷出问题，许多开发人员最近一直在表示担忧，其中包括像Robert C. Martin和Kent Beck（拟定《敏捷宣言》的两个人）这样的知名人士。敏捷方法最常被提到的一些问题是：敏捷忽视技术债务；像Scrum这样的框架完全是“繁文缛节”，它们根本不应该是这样；程序员被要求恪守随意的估计和截止日期，却永远没有时间仔细考虑他们在开发的功能。因此，如果我们能够承认这些问题，并努力解决这些问题，也许我们挽救得了敏捷方法。
|
