进程在软件开发中的作用

引言

任何软件交付的最终目标都是客户满意。如果客户对交付的软件或项目感到满意，那么使用什么技术、是否遵循了任何流程、使用了什么架构、设计和敏捷方法都不重要。但如果客户不满意，那么所有应用的流程、开发中使用的所有最新技术以及所有应用的（设计模式/架构）方法似乎都变得毫无意义。那么，为什么我们要一直强调使用它们或遵循它们呢？谈论这些事情的重要性是什么？它们对于实时软件开发有多大相关性？

背景

首先，我们应该明白，流程不仅负责及时交付高质量的软件，还使我们能够摆脱客户的许多高期望。我们都知道期望是无限的。如果交付的软件没有问题，客户也满意，那我们就很幸运了。但如果情况恰恰相反，那我们就大麻烦了。因为一旦软件交付，出现这种情况的所有合理理由都只不过是牵强的借口。而且，我们经常面临这种情况。

我们在这里不讨论常见的设计或架构问题，我们将在后面看到是什么导致我们在为任何应用程序创建设计和架构时犯下常见错误。

让我们来讨论让任何客户不满意的常见原因。

交付的软件行为与实际需求不符

这对 IT 界来说是很悲哀的，甚至难以接受，50% 的软件失败仅仅是因为需求管理不足。这类问题属于“启动”和“细化”阶段。启动阶段只提供非常模糊的需求概念，例如项目的业务理由和项目范围等。在细化阶段，强烈要求与客户和利益相关者达成双方一致并获得书面批准，以捕获并冻结需求。因此，在软件交付后，客户就不能对其行为提出异议。他只能提出一些增强或修改建议。所有这些建议都可以轻松地转化为下一阶段的新需求。

交付的软件行为与预期不符

通常，这类问题是由于项目中的风险被忽视或对几乎所有应用程序中都存在的常见问题（如应用程序的实际负载、并发用户数、预期性能、安全性、对外部应用程序的依赖程度等）分析不足造成的。开发团队经常在不考虑这些问题的情况下开始开发。这里可以使用合理的理由来证明所有这些忽视的合理性。但我们应该明白，当我们不成功时，每个人都会关注每一个细微的错误；相反，当我们成功时，没有人会关注即使是大的缺陷（只要它运行顺利）。如果需求是在进行适当的风险分析后捕获和最终确定的，那么这个问题将很少发生。现在，这个问题属于风险分析和缓解计划的范畴。在细化阶段，所有主要风险都应被识别并传达给客户/利益相关者，并由相关人员制定适当的缓解措施。所有这些都有助于确定项目的范围/边界以及项目对外部系统和环境的依赖性。

花费的时间超过了提出的交付日期

很多时候，我们被迫在收集和最终确定需求、没有对项目进行适当规划、没有为项目制定任何风险与缓解计划的情况下开始开发工作。这会导致开发陷入非常混乱的境地，最终导致在截止日期前无法完成。这种情况背后的原因是客户方的不当压力。这里只有一件事能提供帮助，那就是努力说服客户尽量少用流程，并赢得客户对使用流程的信任。

实际使用时出现大量问题

如果所有高风险都未被识别，并且 QA 未完成，那就准备好面对这种情况。有时，由于一些外部因素（如同一服务器上托管的其他应用程序导致我们应用程序性能问题，或者我们的应用程序使用共享的外部数据库，并且由于数据库的一些更改导致我们的应用程序崩溃等），我们的应用程序会发生大量问题。我承认，即使有风险与缓解计划和 QA，这些情况也可能发生。但发生的几率非常小。而且在这个时候，我们至少可以用充分的理由说服客户。一件事是始终遵循最佳实践，并尽量根据应用程序的性质和需求应用设计和开发方法。

任何增强和修改都会导致整个应用程序崩溃

正如我一开始所说，我在这里的目的不是找出常见的设计和架构错误。是的，这些也是导致这种情况的一个原因。在缺乏项目管理流程或开发管理流程的情况下，就会发生这种情况。在一个大型复杂项目中，没有人能在不遵循这些流程的情况下对任何新的变更或增强请求进行影响分析。

结论

如果我们遵循流程，我们将能够最大限度地降低风险，或者至少在最糟糕的情况下我们会有一些合理的解释。最重要的一点是，当利益相关者/客户也在所有流程中扮演其既定的角色时，他们会更容易被说服，理解并同意造成这种情况的原因。因此，流程总是让我们处于安全境地，并帮助利益相关者和客户在最糟糕的情况下相互理解并认识到实际问题（什么）、准确因素（为什么）和真实解决方案（如何）。遵循任何流程的最大挑战是让利益相关者/客户也意识到流程及其对他们而言的重要性。

历史

• 2008 年 1 月 20 日：初始帖子