想写出零缺陷的软件？学习个人软件开发流程

我正在努力通过减少代码中的缺陷数量，成为一名更优秀的软件开发人员。个人软件开发流程 (PSP) 是少数几个行之有效的实现超低缺陷率的方法之一。过去几个月，我对它进行了深入研究。在这篇文章中，我将告诉你关于 PSP 你需要知道的一切。

个人软件流程（PSP）的承诺

PSP / TSP的创始人 Watts Humphrey宣称，个人和团队遵循他的流程可以实现极高的缺陷率和生产力。他撰写了数本关于这个主题的书籍，但我今天要介绍的是《PSP：软件工程师的自我提升流程》（2005 年）。

这张图表显示了软件开发规范与交付软件缺陷数量之间的高度相关性。正如您所见，PSP/TSP 交付的软件缺陷数量高达惊人的 0.06 个/KLOC，比CMM 2 级左右的普通组织（6.24 个/KLOC）的缺陷数量少了大约 100 倍。这很令人印象深刻，对吧？

汉弗莱进一步声称：

40% 的 TSP 团队报告交付了无缺陷的产品。这些团队的平均生产力提高了 78%（Davis 和 Mullaney，2003）。质量并非免费——它实际上是有回报的。

底线：缺陷会使软件开发速度慢于预期。如果您采用 PSP，并让您的团队采用 TSP，就能显著减少缺陷，并加快软件交付速度。

这似乎违反直觉，但史蒂夫·麦康奈尔在这篇文章中解释了为什么降低缺陷率实际上可以让你更快地交付软件：最快速度的软件质量

当然，只有遵循像 PSP 这样的流程才能获得这些收益。稍后我会详细解释，但我想先稍微绕个弯，讲个故事。

想象一下你的理想工作

想象一下，你是一家真正开明的公司的软件开发人员——我所说的公司远远超出了谷歌、Facebook、亚马逊或任何你认为目前软件开发领域最优秀的公司。

您被指派了一位生产力教练

现在，你的雇主非常重视开发人员的生产力，以至于公司里的每个软件开发人员都配备了一名教练。具体操作如下：你的教练会坐在你身后，每天观察你的工作（不会打扰你）。他会详细记录以下事项：

每项任务所花的时间
编程任务分为需求、需求审查、设计、设计审查、编码、个人代码审查、测试、同行代码审查等类别。
非编程任务也被细分为有意义的类别，如会议、培训、行政等。
您注入和纠正的缺陷都会被记录和分类
您认为其他可能有用的内容

您的教练将代表您进行实验

回家后，你的教练会通过多种工具运行你的工作成果（需求、设计、代码、文档等），以提取更多数据，例如代码中添加和修改的代码行数。他会将来自你的错误跟踪器和其他数据源的其他数据整合并分析，生成有用的报告，当结果具有统计意义时，供你查阅。

教练的职责是帮助你探索如何成为最优秀的程序员。所以，你可以提出实验方案，教练会负责设置一切、收集数据，并向你展示结果。你或许想知道：

如果测试优先开发比测试最后开发更适合您？
设计评审值得付出努力吗？
结对编程对你有用吗？
每周工作超过 40 小时真的能完成更多工作吗？
您的个人代码审查有效吗？

你的教练会很乐意进行这类实验。或者，你的教练可能会建议你尝试一些同事已经做过并取得良好结果的实验。重要的是，你的教练会为你完成所有的数据收集和分析工作，而你只需专注于编程。

听起来是不是很棒？想象一下你的效率会有多高。

不幸的是，这是现实世界，所以你必须成为自己的教练

这就是个人软件过程 (PSP) 的精髓。因此，除了开发软件之外，你还必须学习统计学、提出实验方案、收集数据、进行分析、得出有意义的结论，并根据实验结果调整你的行为。

个人软件流程的正确之处

汉弗莱找到了软件开发中许多问题的根源：

项目经常因为任意设定的、通常不可能的最后期限而失败
项目中缺陷存在的时间越长，修复它的成本就越高
大型项目中的缺陷会不断积累，并导致系统测试中昂贵的调试和计划外的返工
随着项目规模的扩大，调试和缺陷修复时间呈指数级增长
过度依赖测试效率低下、耗时且不可预测

以下是他的解决方案的概述：

因此，目标必须是尽快从需求、设计和代码中消除缺陷。通过在生产每个工作产品后立即对其进行审查和检查，可以最大限度地减少每个阶段的缺陷数量。这也能最大限度地减少返工量和返工成本。这还能提高开发效率和可预测性，并加快开发进度。

汉弗莱让我相信，他对这个问题各个方面的看法都是正确的。他有数据，而且很有说服力。然而，他给出的方案——也就是解决问题需要做的事情——却并不吸引人，我将在下一节中解释。

为什么几乎没有人实践个人软件流程

对于99.9%的软件开发者来说，个人软件流程（PSP）实在太难遵循了。成为自己的生产力教练所需的自律性超出了大多数人的能力范围，尤其是在缺乏组织支持和推动的情况下。软件开发本身就是一项艰巨的工作，现在，如果你要实践个人软件流程，就需要额外增加思考、记录、数据分析和行为改变等环节。

大多数软件开发者是不会这么做的，除非你拿枪指着他们的头。如果你真的拿枪指着别人的头，PSP 就根本无法运行。他们要么会破坏它，要么干脆辞职。

以下是汉弗莱书中的一段引文，可以让您体会一下 PSP 是多么详细和流程驱动：

PSP 推荐的个人质量管理策略是使用你的计划和历史数据来指导你的工作。也就是说，首先要努力满足 PQI 指南。专注于制作一个全面完整的设计，然后使用第 11 章和第 12 章中介绍的四个 PSP 设计模板来记录该设计。之后，在审查设计时，要留出足够的时间来查找可能存在的缺陷。如果设计工作耗时 4 个小时，则计划至少花费 2 个小时，最好是 3 个小时进行审查。为了高效地完成审查，请根据第 9 章中描述的 PSP 设计审查脚本中的指南来规划审查步骤……

从那里开始……大约150页。我能理解如何使用这种流程创建“几乎无缺陷”的软件，但我很难想象能让一屋子的开发人员自愿采用如此复杂的流程并成功应用。

但这并不是采用的唯一障碍。

采用的额外障碍

个人软件流程旨在作为课堂课程进行讲授

这门课程价格高得令人望而却步。所以，对于大多数人来说，书籍是唯一现实的选择。

您会发现，在没有同学或老师帮助的情况下阅读本书、应用流程、弄清楚如何正确填写所有表格，然后分析数据是很困难的。

本书假设你当前的流程是某种版本的瀑布

TDD 与本书中学习的 PSP 版本并不兼容。编写几行代码、编译、运行、重复直到完成的流程也同样如此。它破坏了你需要计算的统计数据和指标，从而无法获得跟踪进度所需的反馈。想出自己的措施来解决这些问题并非不可能，但这无疑会成为你前进道路上的另一个障碍。

没有编译阶段的语言（python、PHP 等）也会以类似的方式弄乱统计数据。

关于估算的章节对于敏捷/Scrum实践者来说价值不大

PSP 中有一整套估算流程，包括收集数据、分解任务，以及利用历史数据对任务规模进行非常详细的估算，而这些在敏捷/Scrum 时代已经不那么重要了。事实上，我没有发现任何证据表明个人软件过程 (PSP) 的估算方法比召集一群经验丰富的开发人员一起玩计划扑克游戏更好。

在实际项目中收集良好的数据非常困难

如果你要统计缺陷和代码行数，你需要对它们进行良好的定义。乍一看，PSP 似乎有一个相当连贯的答案。但当我真正尝试收集这些数据时，却被各种边缘情况淹没，而我却没有好的答案。

例如，维护过程中发现的缺失需求可能需要一小时才能修复，也可能需要几个月才能修复，但你应该将它们都记录为需求缺陷，并记录修复时间。然后，在统计过程中使用修复时间的算术平均值。因此，即使一个重大的需求缺失不太可能再次发生，也可能会完全扭曲你的统计数据。

垃圾进，垃圾出。非常令人担忧。

顺便说一下，有一些免费软件可以帮助你收集和分析PSP的数据。根据我的经验，这些软件用处不大，但可能比纸质表格要好。

你的组织需要完全参与

学习个人软件流程是一项巨大的投资。我记得我在哪里读到过，普通开发人员需要大约 200 小时的专注学习才能精通 PSP 流程和实践。没有多少组织能够做到这一点。

PSP/TSP 之所以有效，是因为使用者遵循着一套详细的流程。但大多数软件开发都发生在CMM 1 级，因为整个企业都处于 CMM 1 级。我认为，一个混乱的企业不太可能意识到推行一种超级流程驱动的软件开发方法的价值，因为它能提高软件开发人员的生产力和质量。

你可能会说，PSP 中的第一个“P”代表“个人”，你不需要任何组织的支持就可以自己做 PSP。从技术上讲，这或许没错，但这意味着你必须自学，自实践，并且当管理层认为你的项目耗时过长时，你必须顶住组织的所有压力，放弃它。

那么个人软件流程（PSP）是否浪费时间？

不，我不这么认为。Humphrey 一针见血地指出了软件开发中的问题。而且 PSP 也充满了好点子。大多数人无法采用个人软件流程（PSP），或者干脆就放弃尝试的原因，和人们在二月份之前放弃减肥或多运动的新年决心是一样的：我们的大脑抗拒彻底的改变。关于这种人类特质，有很多研究，如果你想了解更多，可以读读《改善精神》（The Spirit of Kaizen）或《习惯的力量》（The Power of Habit）。

汉弗莱解决这个问题就像一个工程师试图让机器人更高效地工作，而这正是 PSP 的致命缺陷。软件开发人员是人，不是机器人。

因此，这里有一些关于如何从个人软件流程 (PSP) 中获得更符合人类心理的益处的想法。

1. 遵循建议，但不进行任何跟踪

遵循 PSP 的目标是尽快消除尽可能多的缺陷。当你将工作交给其他人进行同行评审和/或系统测试时，你肯定不希望出现任何错误。Humphrey 建议进行书面需求、个人需求评审、书面设计、个人设计评审、小批量仔细编码、个人代码评审、开发和使用检查表等。

你完全可以不做追踪就完成所有这些工作。他甚至建议了不同任务可以采用的投入比例。这能让你达到每千行代码 0.06 个缺陷吗？不能。但你可能用 20% 的努力就能达到 80% 的目标。

2. 循序渐进地适应 PSP

为了克服大脑中抵制彻底改变的部分，你可以花几个月的时间采用PSP。也许你每两个月就采纳一个章节的建议。与其预先投入200个小时，不如先从5-10个小时开始，看看效果如何。

或者，你可以只追踪足够多的数据，以证明方法 A 优于方法 B。一旦你感到满意，就可以完全停止追踪。例如，如果你想知道个人设计评审是否对你有帮助，你不需要一直进行所有 PSP 追踪。你可以设置一个实验，选择五个任务作为对照，五个任务作为设计评审，运行一到两周，停止追踪，然后根据你的了解来决定采用哪种设计评审方法。

3. 阅读 PSP 书籍，然后遵循一个更有可能长期成功的流程

Steve McConnell 的《快速开发》一书旨在让你的项目处于掌控之中，并更快地交付可用的软件。与 Humphrey 不同，McConnell 并没有忽视人类心理学。事实上，他欣然接受它。我相信大多数团队在考虑采用个人软件流程 (PSP) 之前，早就应该听从 McConnell 的建议了。

《快速开发》中的大部分建议都是针对团队或组织，而不是个人，我认为这才是正确的着眼点。PSP 是针对个人的，但除非几乎所有项目成员都使用它，否则我看不出它能带来什么好结果。例如，如果团队中的每个人都在尽可能快地开发糟糕的软件，那么你为开发无缺陷软件所做的努力对最终软件的质量或交付日期不会有太大影响。

我要做什么

我在一个两人团队里开发电子商务软件。我和我的同事采用了一系列流程，以确保只有高质量的软件才能投入生产。我们在这方面做得很好；去年，我们只发现了4个严重（但很容易修复）的缺陷，以及一些小缺陷。我们的问题是，由于太多缺陷进入了同行代码评审阶段，导致我们有大量返工。

我向同事展示了PSP，他不太愿意采用，尤其是所有的追踪功能。但他愿意在我们的流程中添加设计评审。所以我们会从那里开始，在回顾时逐步改进流程——就像我们一直以来做的那样。

Rod Chapman 录制了一场关于PSP 的精彩演讲，我很喜欢他提出的“向左移动”的想法。如果你想要更快更省钱，应该把 QA 工作移到开发流程的左侧，或者更靠近开发流程的起始位置。我觉得这个主意不错。

其他资源

以下资源可帮助您了解有关 PSP 的更多信息：

总结

除非你正在开发安全关键型软件，或者你获得了优秀的组织支持和赞助，否则很难推荐个人软件流程 (PSP)。大多数开发人员会发现个人软件流程令人难以承受、沮丧，而且与他们的工作需求不太兼容。

另一方面，PSP 充满了好的想法。我知道你们大多数人不会采用它。但这并不妨碍你们运用 PSP 中的一些想法来提升软件质量。我概述了三种替代方法，让你们无需完全遵循个人软件开发流程 (PSP) 即可获得 PSP 的一些优势。希望其中一种方法能吸引你们。

你玩过 PSP 吗？你会尝试 PSP 吗？我很想在评论区听听你的想法。

文章来源：https://dev.to/bosepchuk/want-to-write-defect-free-software-learn-the-personal-software-process-2n2