《编程匠艺》读书笔记之十九

第二十一章 软件时间范围估计的魔术

• 虽然很多人对进行软件估计不赞成，但是毫无疑问，它是非常重要的。
• 估计的质量主要取决于你对所要估计的任务理解的有多好，也就是说，你真正理解的有多好，而不是你认为自己理解的有多好。
• 软件时间范围估计需要进行有根据的推测，每次估计都应该伴有你对结果的强烈信心。
• 良好的估计是推理出的，有根据的，而糟糕的估计则无异于在黑暗中进行探索。
  
  之所以很多人认为进行估计很难，是因为：
• 有大量的变数需要考虑。
• 需求可能会在你的脚下发生改变，使得软件需要的时间范围扩大了。
• 如果不知道所有相关的工作，你就不能给出一个准确的估计。
• 很少有项目是从一张白纸开始的，你必须在估计开发工作要花多长时间之前，就先认真的了解现有的系统。
• 如果这项任务没有任何经验可以借鉴，那么要想推测出开发过程需要多少时间就会变得更加困难，因为你所作出的估计不基于任何先前的经验。
• 许多项目都依赖于第三方，这种依赖关系也可能会成为一场噩梦。
  
  
• 进行时间范围的估计确实是一件困难的事情，不要低估所需的工作量，要清楚作出糟糕估计的后果。
• 你需要在悲观和乐观之间找到一个平衡点，一个更加现实的情况。
• 我们的时间估计必须建立在现实的基础上，而不是建立在一厢情愿的基础上。
• 每个人都希望更短的开发时间范围，但是在给定的时间范围内可能完成哪些技术工作这方面，不要拿自己开玩笑，在你必须交付产品代码的情况下，不要承诺一个只能拼凑出代码的时间范围。
• 在理想的世界中，应该在进行证明项目可以在合理的时间内完成的可行性审查之后，在确定项目的截止日期，但是在现实世界中，这样是很罕见的。
  
  我们可以使用的一些用来更加准确的进行估计的手段：
• 将任务尽可能分解成最小的单位，高效的通过首次系统设计。
• 当你得到一个不错的解决方案，并且它的各个组成部分都可以得到正确理解时，为每一个小人物提供一个时间范围估计，以“人时”或“人天”为单位。
• 当你完成了所有的时间范围估计后，将这些时间放在一起，汇总它们的用时，这样就可以得到一个更加准确的估计。
  
• 要毫不留情的对大型任务进行分解，直到得到粒度非常小的、可以估计的工作单元。
  
  
• 你应该单独划出一段合理的时间来进行时间估计，要考虑交付软件爱你所需的所有活动，这非常重要。
• 编程不仅仅是剪裁代码，不要忘记在时间范围估计中包含测试和文档开发。
  
  为了作出更加精确的估计，必须考虑以下问题：
• 一个项目越具体，范围越明确，就越容易进行估计。
• 所需的功能越多，指定估计时间的难度就越大。
• 如果你没有完全理解整个问题，那么你的估计一定会很糟糕。
• 如果这个任务需要依赖于第三方的输入，那么估计活动就会比较困难。
• 不同的人做同一项工作的速度不会一样。
• 不要接受来自上游的压力而表现的过于乐观，这一点非常重要！
• 绝对不要事先就计划加班加点。
  
  
• 一个比较好的估计方法：让团队中所有的开发人员对计划中的所有任务给出一个粗略的估计，然后计算出平均值，这个估计值不会有太大的偏差。
• 项目计划就是将任务在开发人员中间进行分配，并计算出如何分配开发的工作量；计划中另外一个重要部分就是风险管理——面对不确定性和隐藏的陷阱制订出一个安全又明智的计划。
• 随着工作的不断前行和项目截止日期的即将临近，工程师们废寝忘食，而收效甚微，进行严格测试的想法被排挤出去，一切都以按时让某些东西快点走出大门为目的，疯狂而急促。糟糕的估计是导致这场软件混乱的罪魁祸首。
• 不管工程师多么优秀，你都可以造就以为更优秀的管理人员来破坏他或她的艰苦工作。
  
  我们可以采取以下手段，来保证估计能够正确的被执行：
• 启动一个新项目时，检查一下分配的时间范围是否真的切合实际。
• 参考时间表——这很重要。如果你能达到自己设定的内部里程碑，那么你跟进外部可见时间计划的可能性就越大。很多时候结果看上去一切发展正常，但是忽然之间项目晚了好多时间，其实在以前的某一天项目就落后了，只是没有人愿意承认。
• 在必要的范围内做尽可能多的工作，除此之外不要多做。
• 探求模块化的细致设计可以减少组件之间的相互依赖性，及早的在组件接口的问题上达成一致的意见。
• 编写优秀的代码，就必须有一套全面的单元测试。
• 留心变更的需求和设计规范，并跟踪这些变更将如何影响你的时间计划。
• 严格限制分散精力的事项。培养一种有助于完成工作的开发文化，要相互尊重对方的大脑空间，确保每次会议的召开都确实是必要的，不要把开发人员拖入毫无目的、浪费时间的聚会中。
• 保持一种积极乐观的方法。
  
  
• 当一个时间范围估计有问题后，不要为了加快进度而盲目的投入过多的开发人力。
  
  一个高质量的开发计划包含以下特质：
• 准确。
• 粒度精细。
• 意见统一。
• 可见。
• 受监控。
  
  
• 优秀的程序员：1. 在可靠的组件分解基础之上，通过考虑开发过程的各个方面，作出良好的时间范围估计；2. 努力制作出经过测试并完全文档化，并且符合时间范围要求的代码；3. 及早的提出时间范围问题，以便这些问题能够得到处理。
• 糟糕的程序员：1. 只依靠直觉和胆量，作出一厢情愿的估计；2. 可以在自己估计的时间范围内匆忙完成代码的编写，但是无法作出产品级、无bug的代码；3. 认为承认在时间范围内无法完成任务是一种软弱的表现，并且会愚蠢的拼命赶上时间——当失败时，他们会看上去傻气十足。