传统软件开发方法的最终结果是什么?

这是本系列文章的第3部分“为什么要敏捷?”从本质上说，RUP和瀑布方法，即使是在明智的过程规程下完成的，仍然试图成为预测性的软件开发方法。也就是说，在项目开始之前，他们想要提前预测一些事情，比如:软件开发的成本是多少，软件将具有哪些功能，“X”或“Y”功能将如何在屏幕上表达，等等。尽管学术界努力预测软件工程，但在我们看来，这个项目还没有取得成功。Standish Group这家美国知名技术咨询公司出版了《混乱报告》(Chaos Report)。该报告汇总了对数千名项目负责人的采访，汇总了他们对软件开发计划成败的看法。在从美国、德国到日本的所有发达国家，以及印度和日本等技术密集型国家，都有项目被调查近岸/离岸软件开发拉丁美洲国家，如哥伦比亚．

最近的Chaos Report统计发现，只有31%的软件开发项目在时间和预算上是合理的，而平均项目成本是最初估计的189%。尽管学术上有功能点评估、Cocomo I/II、功能点、SLIM等方法，但对软件开发项目成本的预测还是有好几个数量级的错误。错误的预测与预期相悖，并引起不满。但真正的问题是，预测性软件开发方法不仅不起作用，而且实际上会使项目变得更糟，而不是更好。为什么如此?预先编写的文档非常昂贵，并且会减慢项目进度:预先编写文档所涉及的正式内容，将会消耗数千小时的非常聪明和昂贵的资源，无论是在客户端还是开发人员端。请注意，书面交流是人类最低效的交流方式之一(它很慢，需要很长时间才能说清楚，而且很难用书面形式“乒乓”对话)。

因此，软件开发项目往往在会议和关于文档状态的汇报中艰难前行。此外，文档并不能制作软件;编码软件。通常在“传统运行”的开发过程中，团队会向管理层呈现大量的文档、大量的费用，并且没有代码来弥补投资。这是非常令人泄气和冒险的。在最后的分析中，在软件开发项目的这一点上——仅仅编写文档就可能花费几个月的时间——软件可能是一个彻底的失败，而且还没有人知道这一点。传统的软件开发方法管理很重:在基于BRUF和高度具体的书面文档的软件开发项目中，过程是严格的和高度控制的。这需要一个完整的PM致力于管理文书工作，需求变更的正式请求，正式的评估，等等。再一次,钱花在了行政职责上，而不是代码上．

BRUF创造了膨胀的怪物:预见性软件开发方法要求用户在软件开始开发之前理想地预测软件需要的一切。通常，在这样的项目中，一个固定价格的预算是在项目建设之前批准的(即与工作量估算相对应的预算)。客户的主要用户非常清楚，一旦预算被批准，更改预算是多么困难。因此，他们宁可谨慎，也要在软件需求中包含他们认为自己需要和可能需要的一切。斯坦迪什集团(Standish Group)的统计数据表明，在BRUF项目中，膨胀是如此普遍和严重软件上线后，45%的功能很少或从未使用过．想象一下，如果他们的过程没有产生这样反常的动机，软件开发的成本将减少45%，而对业务来说没有实际的、功能性的开销!我们希望以公平的方式结束。传统软件开发方法(如RUP)的负面影响可以通过迭代工作来减轻。

而且，当正确部署时，它们生成的软件几乎没有错误。但他们倾向于生产客户要求的软件，而不是客户需要的软件!

关于Perficient拉丁美洲的更多信息:Perficient是一家世界级的软件供应商合作伙伴，在市场上拥有超过30年的经验。我们专门从事外包和近岸敏捷软件开发，软件维护，质量保证和人员扩充的拉丁美洲和北美。