SDLCs 和“白痴动力学”三定律有什么问题？

引言

软件开发生命周期 (SDLC) 和“笨蛋动力学”的 3 条规则。

作者：Tom Shope

有没有注意到市面上有多少种 SDLC？它们有几十种。RUP、TDD、XP、瀑布、螺旋、模型驱动、自上而下、自下而上、演进等等。已经有数百本书籍问世。有课程、教程，甚至还有专门的软件包。有些公司甚至自己内部创建。大多数都有许多阶段和步骤。大多数都产生大量的文档。为什么这么多？很简单，它们不起作用！我的意思是，它们都没有解决它们声称要解决的问题，那就是如何让一群技能水平不一的程序员及时生产出高质量的复杂应用程序和系统。

我的观点是，大多数正式的 SDLC 实际上会无意中降低生产力，并经常完全扼杀开发项目。事实上，我想说，大多数发布和可用的项目之所以能成功，是尽管使用了 SDLC，而不是因为使用了 SDLC。

使用正式的 SDLC 来解决生产高质量软件的问题有一个巨大的缺陷。其基础是建立在一个谬论之上。这个谬论就是你可以从一个平庸的程序员那里获得高质量和及时的代码。这根本不是真的。你认为你可以复制西斯廷教堂吗？希望你回答“不”。那么，如果我们将米开朗基罗在创作过程中所做的每个步骤都记录下来，然后你自己重复这些步骤呢？仍然是“不”对吧？这引出了“Shope 的‘笨蛋动力学’第一定律”

你不能用过程来替代才能或技能。

管理层通常喜欢 SDLC 的想法，因为你不再需要去寻找和培养那些少数有才华、高效率的软件开发人员了。任何人都可以成为优秀的软件开发人员，只要严格执行一个优秀的 SDLC。但这有问题，因为优秀的软件开发是艺术和科学的结合。它绝对不能简化为笨蛋也能遵循的简单步骤。这忽略了过程中的艺术部分。人们在讨论软件开发人员时经常使用“才能”这个词是有原因的。才能通常是无法学习的。

接下来是“Shope 的‘笨蛋动力学’第二定律”

软件开发人员的生产力与他对正式 SDLC 的使用和了解程度成反比。

如果你想雇佣一个高效率的软件开发人员，找一个能通过严格的技术面试，上一份工作收入丰厚，最重要的是，似乎对所有 SDLC 都持低评价的人。事实上，这个人应该对严格遵守正式 SDLC 的想法嗤之以鼻甚至嘲笑。雇佣这样的人，你不会后悔的。我是说所有了解并热爱 SDLC 的软件开发人员都是笨蛋吗？不，当然不是，有些相当聪明；他们只是通常不是高效率的软件开发人员。如果你从事这项工作足够长时间，你就会遇到这样一种开发人员：他们无所不知，可以滔滔不绝地谈论 SDLC 的复杂性，或者可以制作大量精美的架构设计，但似乎从来没有真正产生过多少成果。你知道我在说什么。我的意思是，许多聪明且知识渊博的软件开发人员却相当低效率。

但是等等，你说。当然，遵循一个定义明确的软件开发流程是有价值的。我们肯定能从良好的需求收集、良好的设计、良好的测试等方面受益。我的回答是，是的，当然，这些开发阶段被高效率的软件开发人员所利用。但真正出色、技术娴熟、高效率的软件开发人员不需要布奇先生或朗博先生告诉他们如何做这些事情。最简单的形式，SDLC 只是

• 我需要创建什么？（需求）
• 我该如何编写代码？（分析/设计）
• 编写代码（开发）
• 确保它正常工作（测试）
• 交付给人们使用（发布）
• 如果他们抱怨就进行更改（维护）

我们真的需要某个才华横溢的博士来告诉我们这些吗？优秀的软件开发人员不需要这种帮助。无论如何，谢谢。

最后是“Shope 的‘笨蛋动力学’第三定律”

严格遵守正式的 SDLC 会减缓开发速度并降低质量。

这是因为，通过实施正式的 SDLC，你强迫少数真正有才华和高效率的开发人员遵守一个他们不需要也从中获益甚微的艰苦过程。SDLC 流程在无用且不必要的任务上耗费了大量高效率开发人员的时间。这第三条规则也成立，因为它允许管理层将许多不具备开发任何类型软件能力的人分配到项目中，而这些人却非常擅长遵守 SDLC 的规则、程序和可交付成果。换句话说，他们可以编写需求文档或制定测试计划，但他们无法设计和编写高质量的软件。这些人进一步降低了项目中少数真正熟练的软件开发人员的生产力。此外，管理层对所有这些不必要的人感到沾沾自喜，召开会议，组建委员会，获取反馈，进行研究，制作大量没人阅读的文档，并发送数百封电子邮件。“看看我的项目有多少活动，”他们自言自语道。“我们确实取得了不错的进展。”多么讽刺啊。

回顾Shope的3条“笨蛋动力学”法则

• 你不能用过程来替代才能或技能。
• 软件开发人员的生产力与他对正式 SDLC 的使用和了解程度成反比。
• 严格遵守正式的 SDLC 会减缓开发速度并降低质量。

那么，如果 SDLC 如此低效，为什么管理层如此热爱它们呢？非常好的问题。这种现象有许多原因

• 管理层并不知道所有这些 SDLC 流程和形式主义正在降低生产力，因为通常每个开发团队都有少数几个超级明星，他们最终会克服所有 SDLC 的障碍和挫折，生产出可用的东西。换句话说，少数真正有才华的开发人员将尽管承受 SDLC 流程的负担，但仍能开发出可用的软件。
• 正式的 SDLC 将控制权交还给管理层。管理层不再需要对才华横溢的软件开发明星点头哈腰。管理层知道如何开发软件。没有神秘之处，只需遵循 SDLC 流程即可。SDLC 将控制权从软件开发人员转移到经理手中。
• 正式的 SDLC 允许管理层将软件开发人员视为可互换的资源。既然你可以雇佣任何背景合适的人，只需让他们严格遵循 SDLC 来生产高质量软件，你就不再需要担心雇佣或留住合适的人了。
• 正式的 SDLC 让管理层在上级面前表现良好。高级管理层可以看到 SDLC 流程的实际运作。他们可以看到该流程所产生的 flurry of activity（大量活动）。他们可以看到几十份令人印象深刻的 SDLC 文档。开发管理层可以通过指着复杂的 SDLC 向高级管理层证明软件开发的费用和时间是合理的。当然，这需要很多人和很多时间，看看我们必须做的所有这些事情……
• 最后，正式的 SDLC 给管理层提供了一些事情可做。有许多会议要参加，文件要审阅，委员会要组建，用户反馈要征求等等。有了完善的 SDLC，管理层就忙得不可开交。

总之，我将建议管理层制定一项行动计划，以消除这个问题。

• 找出你员工中的超级明星。这些人就是那些有才能、在软件开发方面效率很高的人。管理层应该已经知道这些人是谁了。
• 请超级明星指出效率低下的员工。应该会找出许多。这个比例不应低于员工的 50%，可能高达 80%。
• 解雇效率低下的员工。
• 大幅提高超级明星员工的工资。
• 完全废除任何现有的 SDLC。（这是最艰难的一步，因为这相当于要求一个典型的开发经理砍掉自己的手臂。）
• 采用新的开发策略，为超级明星提供 50,000 英尺的需求，并要求他们以他们认为合适的任何策略尽快交付软件。
• 所有文档现在都是可选的。
• 所有会议现在都是可选的。

这种策略应该会大大提高生产力，而且令人惊讶的是，也会提高质量。

历史

• 2007年1月3日：首次发布