Management Principles of software development

你可以从本文了解到

本文是对《软件设计的 201 个原则》的第7章——软件开发的管理原则的学习

管理 是围绕软件开发的所有工程活动，进行计划（plan）、控制（control）、监视（monitor）和报告（report）的一组活动。

127 好的管理比好的技术更重要

所有伟大的技术（CASE工具、技术、计算机、文字处理器等）都弥补不了拙劣的管理。

好的管理，即使是在资源匮乏的情况下，也能产生巨大的效果。

128 使用恰当的方法

技术问题需要使用技术的方法。

管理问题需要使用管理的方法。

政治问题需要用政治的方法。

切忌用不恰当的方法来解决问题。

129 不要相信你读到的一切

130 理解客户的优先级

很有可能的是，如果客户能按时获得10%的系统功能，那么他们宁愿90%的功能延迟交付。

原则 8 的推论更令人震惊，但很有可能就是这样的。一定要弄明白！

当你和客户沟通时，一定要确认你知道客户的优先级。

这些可以很容易地记录在需求规格说明中（原则 50），但真正的挑战是理解可能不断变化的优先级。

此外，你必须理解客户对于“必要”（essential）、“期望”（desirable）和“可选”（optional）的说明。

131 人是成功的关键

具备合适经验、才能、培训的高技能人才，是在预算内按时完成满足用户需求软件的关键。

根据构造性成本模型（COCOMO）(Boehm, B., Software Enginering Economics, Englewood Cliffs, N.J.: Prentice Hall, 1984)估算，最优秀的人效率是其他人的四倍。

如果最优秀的人花费四倍的薪水，你可以做到收支平衡，而且最终你很可能会得到一个更好地产品（原则 82）。

如果他们的花费没有这么多，你降低了成本，还得到更好的产品。

这是双赢。

在面试候选人时，记住人才质量是无法替代的。

在面试完两个人后，公司经常说，“面试者 x 比 y 更好，但是 y 已经足够好了，并且成本更低”。

你不可能有个全明星阵容的组织，但是，除非你现在拥有的超级明星过多，否则雇佣他们吧！

132 几个好手要强过很多生手

本原则与原则 131 是一致的。原则 131 说你应该总是雇佣最好的工程师。

本原则想说：对一个关键任务，你最好只安排少数有足够经验的工程师，而不是安排许多没有经验的工程师。

另一方面，Manny Lehman 警告说，你不能完全依赖“少数优秀的人”。如果他们离职了呢？

最好的建议是，在一个项目中建立合适的人员配比，并且切忌不要向两个极端发展。

133 倾听你的员工

你必须信任那些为你工作的人。

信任的第一个原则就是倾听。

134 信任你的员工

相互信任是成功管理的要素。

成为一个坏人的机会远远比成为一个好人要多。

抓住每个能让你成为好人的机会。

135 期望优秀

如果你对员工有更高的期待，他们将表现的更好。

136 沟通技巧是必要的

在为你的项目招募成员时，不要低估团队合作和沟通的重要性。

最好的设计师可能会变成差劲的资产，如果他/她不能沟通、说服、倾听和妥协。

137 端茶送水

当你的员工要工作很长时间来完成软件工程的工作时，你应该工作相同的时间。

138 人们的动机是不同的

众所周知，人各不同，负面和正面的激励都起作用，但是正面的激励经常被管理层忽视。

139 让办公室保持安静

最有效率的员工和公司都拥有安静和私密的办公区。

140 人和时间是不可互换的

只用“人-月”来衡量一个项目几乎没有任何意义。

假设你有 10 个人在做一个预期三个月完工的项目。

现在你认为你比计划晚了三个月，也就是说，你预估还需要 60 人月（6个月 * 10个人）。

你不能再加 10 个人并期望项目回到计划上来。

这个原则通常叫做布鲁克斯定律（Brooks’ Law）。

141 软件工程师之间存在巨大的差异

从最好的软件工程师到最差的软件工程师，研发效率（按每人月的代码行来衡量）可能相差 25 倍之多，质量（按每千行代码中发现的错误来衡量）可能相差 10 倍之多。

142 你可以优化任何你想要优化的

事实是，在产品开发过程中，有很多权衡—不同的权衡—要不断进行取舍。与你的员工一起工作，并帮助他们了解你和你的客户的优先级。

143 不显眼地收集数据

数据收集在以下方面极为重要：帮助未来成本预测，评估项目或组织的当前状态，评估管理、过程或技术变更的影响等。

144 每行代码的成本是没用的

145 衡量开发效率没有完美的方法

接受这个事实：完美是不可能的。使用开发效率度量和成本估算模型来确认你的直觉和你的亲身经验。永远不要依靠它们作为你唯一的衡量。

146 剪裁成本估算方法

147 不要设定不切实际的截止日期

不可避免的结局是，一个不切实际的截止日期将无法得到满足。这样截止日期的设立削弱士气，使你的员工不信任你，造成高离职率，并产生其他不良影响。

为了满足日程表的约束，质量通常会被降低。这损害了整个软件行业的信誉。

问题通常不在于软件工程师的生产力低下或经理的管理不善。问题在于预先做出的估算很差。

148 避免不可能

Barry Boehm 将“不可能的区域”定义为：预期的产品开发时间与需要消耗的人月数之间的关系。

具体来说，从编写软件需求规格说明到交付产品所花费的时间不会少于 2.15 乘以人月的立方根，即：

T > 2.15 * sqrt[3]{PM}

所有已完成项目中有 99％ 遵守了该规则。是什么让你认为自己可以做得更好？ 如果你仍然认为可以做更好，请参阅原则 3、19、158 和 159。

149 评估之前先要了解

当为你的项目选择指标时，请确保你在测量的与你要实现的目标有关。（请参阅 1993 年 9 月 《IEEE Software》的Manager Column中的开头段落）。这通常需要使用多个指标。

记住：即使每个人都以同一种方式进行衡量某事，这种方式也并非自动适合你。要考虑你的指标。由于所有东西都可以被观察（并且在大多数情况下可以被测量），因此请仔细选择什么是你想要观察（和测量）的。

150 收集生产力数据

少量经过充分理解、认真收集、模型化及演绎的数据，要好于大量没有这些特性的数据。

151 不要忘记团队开发效率

优化所有个体的生产力并不一定会产出最佳的团队生产力。

曼尼·雷曼（Manny Lehman）报告了一项软件开发工作，其中个人生产力增加了两倍，而企业生产力却下降了！

这里有两个教训要总结：首先，不同的措施适用于不同的人。其次，要衡量团队的整体效率，可通过跟踪一些数据（如，按照时间周期和问题难度总结的、反映团队解决突出问题能力的报告）。

152 LOC/PM 与语言无关

通常认为，不管使用哪种语言，程序员平均每人每月可以生成 x 行高质量代码。

C.Jones在《Programming Productivity》（New York: McGraw-Hill, 1986, 第一章）中提出相反的观点。使用高级语言时，实际的生产力当然会大大提高，因为 500 行 Ada 代码可以做的事比 500 行汇编代码多得多。此外，语言选择会极大地影响可维护性（原则 193）。

153 相信排期

一旦建立了可行的排期（原则 146、147 和 148）并分配了适当的资源（原则 157），所有各方都必须相信排期。

最好的建议是，让工程师制定排期。不幸的是，这并不总是可能的。

154 精确的成本估算并不是万无一失的

原因有三个：（1）你，（2）假设（3）概率。

首先，是你。你的领导能力将对实际结果产生重大影响。例如，你可以在五秒钟内破坏团队花了一年时间建立的士气。

其次，你为生成初始估计所做的所有假设可能不都证明是准确的。例如，如果你只有数量更少的合格人才怎么办？如果需求改变怎么办？如果你的关键人物生病了怎么办？如果一半的工作站在你最需要的时候出现故障怎么办？

第三，估计值只是概率分布中的峰值。如果我告诉你我要抛硬币 100 次，并要求你预测出现硬币正面的次数，你很可能会选择 50 次。这是否意味着真的会出现 50 次正面？当然不是。实际上，如果真的刚好出现了 50 次正面，你将感到很惊奇！

155 定期重新评估排期

排期通常在项目启动时设定。其中包括中间期限和产品交付期限。每个阶段完成后，排期必须被重新评估。

一个进度落后的项目很少能在后续阶段恢复到原计划。

作为一名管理者，你的责任是预防灾难。

相反，应与客户和/或上级建立工作关系。要报告每个可能的日期变更（通常是延期），并讨论克服这些困难的可选策略。只有各方的早期干预和参与才能防止延期升级。

156 轻微的低估不总是坏事

假设士气没有削弱，在被认为稍稍落后进度的项目中，其成员会努力工作赶上进度，从而提高生产力。类似地，在被认为稍稍提前进度的项目中，其成员经常会休假、工作更少时间、花更长的时间读邮件、以其他方式放松，从而降低生产力。因此，成本预估本身就会影响项目产出。对任何一个特定的项目，被轻微低估成本对比被轻微高估成本，都会花费更少的资源。然而要注意，如果项目成员认为排期被严重低估了，士气和生产力都会下降。

157 分配合适的资源

不管人员的质量如何，工具、语言或流程的可用性如何，人为强加的进度和不恰当的预算将会毁了一个项目。

如果你试图压缩排期或预算，参与项目的工程师将不会高效地工作，当不可避免的延期发生时，没有人会采取行动，士气将受到影响，并且最重要的是，项目的花费很可能比合理的成本要高。

158 制定详细的项目计划

每个软件项目都需要一个计划。详细程度应该适合于项目的大小和复杂性。

你需要计划的最小集合如下：

• 显示任务之间相互依赖关系的PERT表。

• 显示每个任务的活动何时进行的甘特图。

• 实际里程碑的列表(基于早期的项目，见原则 150)。

• 编写文档和代码的一套标准。

• 各种不同的任务中的人员分配。

一个没有计划的项目，在它开始之前就已经失控了。

正如《爱丽丝梦游仙境》中柴郡猫对爱丽丝所说：“如果你不知道要去哪里，那你也就无法达到那里！”

159 及时更新你的计划

有一个过时的计划比完全没有计划更糟糕。当你没有计划时，你应该知道你已经失控了。

一份写得好的计划应该列举风险、潜在风险正成为威胁的警告信号、为减少威胁而制定的应急计划（原则 162 ）。

随着项目的进行，如果预期的风险成为威胁，要实施应急计划并更新项目计划。

真正的挑战是那些不可预见的变化。在这种时候，人们常常需要重新做计划。

在这种时候，人们常常需要全面地重新规划整个项目的其余部分，包括新的假设、新的风险、新的应急计划、新的排期、新的里程碑、新的人力资源分配等等。

160 避免驻波

遵循原则 159 (保持你的计划是最新的)的一个奇怪的副作用是驻波。

不要因为你只是落后了几天，就认为问题会消失。所有的项目都是"一天一天地落后"。

161 知晓十大风险

• 人员短缺（原则 131）。

• 不切实际的排期（原则 148）。

• 不理解需求（原则 40）。

• 开发糟糕的用户界面（原则 42）。

• 当客户并不需要时尝试镀金（原则 67）。

• 不控制需求变更（原则 179 和 189）。

• 缺乏可重用的或者接口化的组件。

• 外部执行任务不足。(由外部承包商完成的任务不满足要求。)

• 糟糕的响应时间。

• 试图超越当前计算机技术的能力。

162 预先了解风险

在项目计划的早期阶段，要梳理与你项目相关的最大风险列表。

对于每个风险，要量化其真正发生会带来的破坏程度，并量化这种损失发生的可能性。

这两个数字的乘积，是你对特定风险的风险敞口。

在项目开始时，构建一个决策树，梳理所有可能降低风险敞口的方法。

然后要么立刻对可能造成的后果采取行动；要么制定计划，在风险敞口超过可接受范围时，采取各种措施。

163 使用适当的流程模型

软件项目中可以使用很多流程模型：瀑布模型、一次性原型、增量开发、螺旋模型、操作原型等等。

没有任何一种流程模型适用于公司中的所有项目。

每个项目都必须选择一个最适合它的流程。

164 方法无法挽救你

那些以往表现不佳的组织，在采用最新流行的方法后仍然会表现不佳。

作为一名管理者，要提防那些声称基于新的方法将大大提高质量或生产力的虚假的预言家。

采用新的方法并没有错，但一个公司如果过去“失败”过（不论是生产力还是质量），在寻找解决方案之前，请尝试找出失败的根源。

你现在使用的方法，很可能不是问题的根源！

165 没有奇迹般提升效率的秘密

软件行业的生产力正在适度提高（每年 3% 至 5％）。事实是，我们有一种简单的方法来降低需求工程的成本：就是不做！对所有其它阶段也是如此。实际上，只通过不开发软件，我们就可以节省很多钱！

你应该会对可削减几个百分点成本或提高几个百分点质量的工具、语言和方法感到满意。然而，如果不了解对客户满意度的影响，降低成本毫无意义。

166 了解进度的含义

下面是一些衡量进度的有意义的标准：

• BCWP：“已完成工作预算费用”（Budgeted cost of work performed）衡量你预期目前已完成的工作会花费多少。

• ACWP：“已完成工作实际费用”（Actual cost of work performed）衡量你在项目中实际花费了多少。

• BCWE：“预期工作预算费用”（Budgeted cost of work expected）衡量你预期花费多少。

• (BCWP-BCWE)/BCWE：它体现了真实的技术状态。值大于零表示你比排期提前的百分比。值小于零表示落后排期的百分比。

• (BCWP-ACWP)/BCWP：它体现真实的预算状态。值大于零表示低于预算的百分比。值小于零表示超出预算的百分比。

167 按差异管理

当你汇报进度时（无论是书面、口头、正式还是非正式），只需汇报计划和实际之间的差异。

通过这种方式，可以将注意力和资源放在有问题的地方。

168 不要过度使用你的硬件

要注意硬件限制对软件开发成本的巨大影响。

尤其是，有数据显示，当内存或 CPU 使用率接近 90% 时，软件开发成本将 翻倍 ！

当接近 95% 时，成本将会增加 两倍 ！

如果你的环境使你必须压缩每个字内存和 CPU 周期，那么一定要相应地增加排期。

169 对硬件的演化要乐观

170 对软件的进化要悲观

171 认为灾难是不可能的想法往往导致灾难

最大的管理灾难会在你认为不会发生的时候出现。

172 做项目总结

忘记过去的人注定会重蹈覆辙。——乔治·桑塔亚纳（George Santayana）, 1908

每个项目都有问题。

原则 125 涉及记录、分析技术错误并从中学习。

本原则用于对管理错误或者整体的技术错误进行同样的操作。

在每个项目结束时，给所有的项目关键参与者一个3–4天的任务来分析项目中出现的每一个问题。

总的来说，主要思路是记录、分析所有不符合预期的事情并从中学习。

同时，记录下你认为将来可以采取的不同措施以预防问题发生。

未来的项目将会极大受益。