软件开发计划_敏捷软件开发实践：估算与计划读书笔记103第 1 章 计划的目的...

《敏捷软件开发实践：估算与计划》第 1 章 计划的目的，重点和要点的思维导图及文字内容。

第 1 章 计划的目的

1.0 前言

Planning is everything. Plans are nothings.

无论一个软件开发项目的规模与结果如何，估算(Estimating)和计划(Planning)对于项目的成功都是至关重要的。

计划可以指导我们的投资决策；计划可以帮助我们了解在项目特定的阶段需要哪些人参与其中；计划还可以帮助我们了解项目是否在正常进行，从而可以交付用户所需要和期望的功能。

没有计划的话，项目就可能面临无数问题。

计划又是困难的，而且做出的计划常常会出错。

这导致两个极端：要么根本不做任何计划；要么认为计划必须尽善尽美而在计划中投入大量的精力。

不确定性锥形(cone of uncertainty)：在项目的可行性分析阶段，对进度估算的偏差往往可能达到 60%-160%。即一个预期需要 20  周的项目实际上花费的时间可能在 12 周 ~ 32 周之间。而在写下需求后，估算的偏差仍可能达到 +/- 15%。这时预期的 20 周意味着实际上会花 17 周 ~ 23 周。

项目管理协会(PMI)对估算的渐进准确性的看法：PMI 建议首先建立数量级估算(order of magnitude estimate)，误差范围为 + 75%~ - 25%；然后建立概要估算(budgetary estimate)，误差范围为 + 25% ~  - 10%；最后建立确定性估算(definitive estimate)，误差范围为 + 10%~ - 5%。

1.1 为何要进行估算和计划 1.1.0 前言

计划——尤其是持续进行的迭代式的计划——是对价值的探求。

计划就是尝试给产品开发的总体问题：“我们要构建什么？”找到最佳答案。

好的计划过程通过5个活动来支持对价值的探求：

1. 减少风险

2. 降低不确定性

3. 提供更好的决策支持

4. 建立信任

5. 传递信息

1.1.1 减少风险

若项目的风险过高，我们可能会不启动该项目。

有时我们可以通过早期的预防措施来控制某些功能可能包含的风险。

项目团队可以选择马下采取措施消除风险，或者记下这个风险，通过增加工作量的估算值，或用一个范围来表示工作量，以描述更大的不确定性和风险。

1.1.2 降低不确定性

迭代式的计划过程能够帮助团队优化产品的愿景。

大多数项目所面临的最关键风险是开发出错误的产品，但在绝大多数项目中这一风险都被忽视了。

一个失败的项目的标准一定是：项目中没有人提出比最初的需求列表更好的想法。

我们希望鼓励项目团队定期对项目投资、进度表和功能决策进行重新评估。

1.1.3 提供更好的决策支持

估算和计划可以帮助我们进行决策。

估算既可以帮助我们决定是否启动某个项目，也可以帮助我们确保正在开发可能具有最高价值的项目。首先，公司需要对进度和花费进行估算来判定预期的项目是否值得推进。其次，公司还需要项目的估算和计划，来决定推进哪个项目。最终，他们可能会决定推出其中一个，两个都推进，或者由于项目的代价都太高而都中止。

有时候，项目成员的配备规格比项目的计划安排更为重要。

项目计划时所做出的许多决策都是折中后的决定。在每个项目中，我们都会在开发时间和费用之间进行折中 。

我们经常在功能特性与投入的精力、成本和时间之间进行类似的折中。

1.1.4 建立信任

频繁地、可靠地交付承诺的功能可以在产品的开发人员和客户之间建立信任。

可靠的估算使得可靠的交付成为可能。

客户需要估算来做出关键的优先级和折中决策，帮助决定功能特性开发到何种程度。只有开发人员的估算被证实可靠，客户才会愿意在项目开发的早期就做出这种折中。

可靠的估算允许开发人员以可持续的节奏进行工作而使他们受益：代码质量更高且缺陷更少。

1.1.5 传递信息

计划描述完成项目的可能路径之一，可以传递针对项目的期待。

计划可以展示和传递一组对于项目预期的基线，但并不能保证在特定日期和特定成本内完成一组精确的功能集合。

1.2 优秀的计划是什么

优秀的计划就是项目相关方认为足够可靠、可以作为决策基础的计划。

在项目后期，为了对决策支持依旧有效，这个计划需要变得更为精确。

这个计划是有用的，只要它能够预测项目中实际会发生的事情。

这个计划虽然不精确，但是在整个项目过程中可以对它定期进行修正。

1.3 敏捷计划是什么

本书是关于敏捷计划活动而不是敏捷计划文档的。

计划文档(Plans)是文档或者图表，它们只是我们对项目在不确定的将来会如何展开的理解的快照。

计划活动(Planning)是一项活动。敏捷计划将重点从作为结果的计划文档转向了计划活动的过程。

敏捷计划文档是一个我们不仅愿意、而且渴望修改的计划文档。

我们修改计划文档，并不仅仅是为了变更本身，而是因为我们学到一些新的东西或者避免了一个错误：可能是我们了解到用户更需要这个功能而不是那个功能，或者可用性比设想的更重要，或是用新语言开发需要的时间比预期的更长等。

敏捷计划需要易于修改的计划文档。

我们对计划文档的修改并不代表是对日期的改变，日期有可能改也有可能不改。修改计划文档但不改变日期的情况有：放弃某个功能；缩减某个功能解决的问题的范围；在项目中增加一些人员等。

我们应该承认不可能在一个项目开始时就对它进行完整的定义，所以不会在项目的开始时完成所有的计划活动。

敏捷计划是均衡分布在项目的整个过程之上的。发布计划活动设定了交付阶段，然后是一组迭代的计划活动。这整个过程会在项目中重复好几次。

定义敏捷计划时：更关注计划活动而不是计划文档。鼓励修改。产生易于修改的计划文档。延续到整个项目周期。

1.4 小结

估算和计划是关键的，但也是困难和容易出错的。项目早期给出的估算没有项目晚期给出的估算准确。不确定性锥形显示了这一逐渐细化的过程。

计划的目的在于找到一个最佳答案，用于回答“要构建什么”这一产品开发的总体问题。这一答案则综合了功能、资源和进程安排。一个可以减少风险、降低不确定性、为可靠的决策提供支持、建立信任和传递信息的计划流程为解答这个问题提供了支持。

优秀的计划应该足够可靠，可以作为对该产品和项目进行决策的基础。敏捷计划更关注计划的过程而不只是创建一个计划文档。它鼓励修改、产生易于修改的计划文档，并且延续到整个项目周期。

---

版权声明

本人所读图书的版权属于原著者和译者。这里仅为个人学习使用。但由本人学习整理所形成的音频、图片、文字和视频等的版权为本公众号拥有，任何人不得未经授权转载。 如果你觉得本文有用，欢迎分享给其他人。谢谢。

---