敏捷、Scrum，这些花哨的词来形容编写交付的软件
无论从哪个角度来看，一般而言，商业应用软件开发人员的声誉都不好。系统几乎不可避免地会延迟交付，甚至根本不交付。一般公司的普通用户每周都会花几个小时抱怨他们被迫忍受的计算机系统。 “为什么要这么做？”、“这到底是什么意思？”这是我每天听到的一些事情。
我花了数年时间编写业务系统，大多数情况下，用户对他们所获得和使用的内容持积极态度。系统按照初始规范编写，经过彻底测试，然后根据需要以商定的成本进行调整（如果需要）。对客户的持续支持和软件公司的持续收入是一个成功的组合。基于详细需求分析的初始规范始终是功能概述，并且不包含任何代码细节，我想我曾经使用过伪代码（当我编写游戏时）。 “这就是我们需要它做的”，通常对我来说就足够了。除此之外，还有一些用户界面模型和大量数据库设计，然后我们就可以开始了。开发生命周期的测试和“调整”阶段非常重要。系统通常按时交付并正常运行。
如今（我从来没想过我会这么说），所有与系统相关的事情都与规划有关，更多的规划，然后是可重用性。对我来说如此陌生的是，这个计划的大部分内容并不是为了满足功能需求，而是为了详细说明我们在编写时如何以及为什么要编写我们所写的内容。希望这是有道理的吗？为什么要用 10 行写一些你可以用 1000 行完成的东西，而你“可能”需要在 2 年后重新使用它？就我个人而言，我从来没有写过任何两年后我无法重写得更好的东西。我一直在学习和进步，当我回顾 12 个月前的代码时，我常常感到畏缩。看着招聘广告，很容易迷失在所要求的方法和技能中，一个人是否有可能知道这么多我经常问自己的事情？另一个问题是他们曾经生产过产品吗？有了所有这些计划并担心重用代码，有什么事情可以完成吗？我知道有一家公司聘请了学术开发人员，他们忙于专注于设计，以至于在任何产品接近准备就绪之前该公司就破产了，说真的！我们可以期望人们容忍多少次延迟，测试阶段从来都不是问题！为什么向我们支付产品费用的公司应该为将在以后的项目中反复使用的代码付费，而不是为他们付费？
不要误会我的意思，我并不是说规划不好，它是系统开发的重要组成部分，但它不是唯一的部分。也许我是老派，但我真正喜欢的部分是编写系统并让它运行。好吧，我知道系统一直在变得越来越大、越来越复杂。大型开发团队是常态。只是我认为，无论你如何计划、想象和集思广益，总会错过一些东西。我们正在努力实现不可能的、完美的系统，但在最坏的情况下，我们实际上没有提供任何系统。不相信我？看看微软。想象一下规划他们的任何应用程序需要花费多少工时？新错误或漏洞多久被发现一次？为什么这些不在设计阶段就被讨论出来呢？开发团队从未想过“漏洞 X”可能会发生。简而言之，除了最基本的系统之外，无论您的逻辑多么合理，几乎不可能为所有可能发生的情况做好计划。为什么在测试过程中没有发现它们？这里的解决方案是老式开发，更少的时间规划（谈论），更多的时间编写和测试吗？更少的时间担心重用代码，更多的时间为客户和客户提供可用的产品？如果微软花更少的时间规划和更多的时间进行测试，他们会变得更好还是更糟？在微软的辩护中，他们非常擅长打补丁，我想他们可以被视为利用我们作为测试人员。也许如果他们花更多时间进行适当的测试，我们就不需要对他们进行测试？
我还没有遇到过的过度计划的最糟糕的例子是我每天使用的金融系统。该系统的实施花费了数百万美元、多年的规划以及谁知道有多少顾问。它由软件行业最大的参与者之一编写，并由专业软件咨询公司改编。最终的结果是系统实际上无法使用，并且离被货架产品取代也不远了。在最低级别上它是如此糟糕，即使是错误的鼠标单击也会挂起应用程序。我不敢相信这个系统在移交之前经过了测试。由于“计划周期”比预期要长，交付的时间已经很晚了。它的作用并没有那么复杂，只是它显然已经计划到了三思而后行的地步。所有这些规划甚至都没有产生一个能够满足用户基本功能要求的系统，但是嘿，我确信他们会在某个地方重新使用该代码。
不管怎样，我刚刚开始攻读文凭，以帮助我理解为什么使用几种不同的规划策略如此重要。为什么要在一天之内写下我可以“正确”花一个月时间做的事情？我知道几年后我会再读到这篇文章并想知道我在想什么；要么我就会对自己说“哇，那是我真正完成我正在写的东西的时候”。不过说真的，我确信到最后我会意识到我哪里出了问题，同时我将继续使用我的 RAD 风格编写应用程序（我很高兴它有一个名字！）虽然不符合每个人的口味，但对我来说效果很好。
注：谁能想到我的开发方法有一个名字，它被归类为敏捷方法论！这是一篇很好的文章，解释了 敏捷方法论 在一些细节上。