有人总喜欢拿“软件危机”说事。我们无法足够快、足够低成本或足够好的开发软件。我同意埃德斯加·狄克斯特拉(Edsger Wybe Dijkstra)的观点，软件开发确实非常非常复杂。那么我的结论是否指软件成本缘于其复杂性?不，我认为软件成本高的原因来自于使用了错误的行为来管理软件的高成本。

　　控制的误解

　　人们关于控制的最大误解当属项目计划。我认为，软件开发项目管理工具，尤其是微软的Project，是我们犯下的最大错误。至于证据，大家可以了解一下敏捷开发方法。敏捷开发的一个关键元素是削减(或消除)软件开发相关的项目管理愚蠢行为。

　　我认为，软件开发工程一般都非常复杂，一个大的MPP文件并不能削减其复杂性，也不会有助于任何人理解其复杂性。我认为，我们不应该尝试征服这种复杂性，那是一种非常愚蠢的行为。如果你发现自己需要一个非常复杂的文档来征服许多非常复杂的复杂性，你正在犯错。

　　简洁性说明

　　我认为，用户开发经历非常有用，因为它们将软件开发的复杂性简化为我们可以清楚表达和记忆的东西。这让我们更有机会去裂解它。

　　如果用例要求一个大的复杂文档，我们可能正在错过本质的东西。它应该有一个简洁、易记和非常容易写到便笺条上的总结。它可以有一个详细的技术性附录。但它必须有一个简洁、易于表达清楚的总结。

　　如果你无法轻松的解释清楚用例，就说明它有些过于复杂了。

　　架构

　　一个架构图可能非常有帮助。作为地基的架构必须是经过反复分析后确保是正确的。你必须绝对自信它的可行性。就如同任何数学方面的分析，你需要图标和公式，而且你需要展示你的工作。

　　架构不需要故弄玄虚，而需要务实。一些简洁的公式(便于记忆)再加上合理的解析，效果会好的多。

　　工作分解结构(WBS)问题

　　我发现，具有复杂工作分解架构的项目又多加了一层复杂性和无用的管理。软件的成本非常高，那么让我们尝试通过增加管理来削减我们的成本。但是，这种为削减人力而增加人力的做法并没有实际意义。

　　与其浪费时间增加工作量，还不如确定一个人选，由其实现更有效的决策和保持开发进度保持正常。

　　更多的推出局部解决方案，这比每周状态报告更具价值。在理解详细设计过程方面，更多的与产品拥有者交流，比一个精心编写的计划更有价值。

　　反驳项目管理的辩解

　　我们或许会这样为项目管理辩护：通过消除“障碍”或“低效”，它可以让软件开发过程更高效。我也曾经相信这些，但现在我的观点变了。

　　让我们一起看一些项目管理可能会消除的那些所谓障碍：

　　◆用户参与。更确切的说，无需用户参与。我认为项目管理这种做法除了伤害用户外没有其它效果。如果用户不通过积极回答问题或检查近期结果来帮助软件开发，那么开发出来的软件不会创造任何价值。现在就停止工作，发现哪些事情是用户真正需要的。

　　◆技术资源。协调技术资源(数据库管理员的、系统管理员的、独立测试者的等)并不需要一个复杂的计划、状态会议或报告。它只需相关人士之间的几个电话。简单直接而有效。

　　◆决策。项目经理不是产品所有者，也不是用户，也不是技术专业人员，不会理解软件开发过程中的危险所在。实际上，他们只是在一场他们无法完全理解的会话中担当一个服务者的角色。如果他们能够做到不去承担不属于自己的任务而坚持服务理念，这也不错。

　　我不明白我们为何仅仅把重点放在IT项目管理上。敏捷开发人士的观点是正确的。通过真正削减成本和复杂性的做法来削减成本和复杂性，而不是通过增加管理。