《敏捷软件开发实践:估算与计划》第 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 小结估算和计划是关键的,但也是困难和容易出错的。项目早期给出的估算没有项目晚期给出的估算准确。不确定性锥形显示了这一逐渐细化的过程。
计划的目的在于找到一个最佳答案,用于回答“要构建什么”这一产品开发的总体问题。这一答案则综合了功能、资源和进程安排。一个可以减少风险、降低不确定性、为可靠的决策提供支持、建立信任和传递信息的计划流程为解答这个问题提供了支持。
优秀的计划应该足够可靠,可以作为对该产品和项目进行决策的基础。敏捷计划更关注计划的过程而不只是创建一个计划文档。它鼓励修改、产生易于修改的计划文档,并且延续到整个项目周期。
版权声明
本人所读图书的版权属于原著者和译者。这里仅为个人学习使用。但由本人学习整理所形成的音频、图片、文字和视频等的版权为本公众号拥有,任何人不得未经授权转载。 如果你觉得本文有用,欢迎分享给其他人。谢谢。