《敏捷估计与规划》读书笔记

这本书断断续续看了很长时间, 内容非常不错, 基本涵盖了scrum, 用户故事, 迭代计划. 是对项目进行敏捷管理的不错参考. 另外最后一章的案例分析非常赞, 前面的你可以不看, 但是案例一定要看, 看完案例基本上你就可以知道该如何操作敏捷项目管理了

=============我是读书笔记的分割线=============
对大部分不确定性(缺乏知识)而言, 获取知识, 减少不确定性的唯一方法就是通过执行--做一些事情, 构建一些东西或是模拟一些东西--然后获得反馈.

许多项目管理方法是"规划,规划,规划-执行", 而敏捷开发方法是"规划-执行-调整", "规划-执行-调整".

如果一项活动花费了比计划更多的时间, 所有类似的活动都可能花费比计划更多的时间.

应对不确定性的最佳方法是迭代.

你可以在项目的最开始阶段设置一个很短的设计, 建模或者其他阶段. 但只要项目真正开始, 在每次迭代中都会同时进行所有的工作(分析, 设计, 编码, 测试等等)

迭代是受timebox限制的, 意味着即使放弃一些功能, 也必须按时结束迭代.

大多数小组不会把每次迭代的结果都交付给用户; 敏捷开发的目标只是让他们可以交付, 这意味着开发小组每次都会增加一些小功能, 但是增加的每个功能都经过编码, 测试, 达到可以发布的质量.

在每次迭代结束的时候让产品达到潜在可交付状态是很重要的.

要使产品所有者在确定功能优先级时具有最大的灵活性, 就必须在编写功能时让他们之间的技术依赖性最小化.

敏捷开发小组关注完成和交付具有用户价值的功能, 而不是完成孤立的任务(任务最重组合成具有用户价值的功能).

一个用户故事是从系统用户或者客户的角度出发对功能的一段简短描述.

按照大致符合这样一个形式来考虑用户故事是比较有益的: "作为(用户的类型), 我希望可以(能力)以便(业务价值)",比如"作为购书者,我希望可以根据ISBN找到一本书, 以便更快的找到正确的书"

用户故事是轻量级的, 因为不需要一开始就把它们全部收集和记录下来. 与其写下一篇冗长的需求说明书相比, 敏捷开发小组发现采用刚好及时的需求分析方法更有效.

使用基于用户故事的需求分析方法时, 仍可能需要编写文档. 不过, 工作重点在很大程度上从文档编写转移到口头的交流

任何项目开始建立的计划都不是对未来将会发生些什么事情的保证, 事实上, 他只是当前的一个猜测.

在发布中增加更多用户期待的功能, 而减少一些低价值的功能, 可以增加计划的价值.

项目产生的新知识可能是关于产品, 也可能是关于项目本身的, 产品知识可以帮助我们更好的认识产品是什么, 项目知识这是关于技术, 风险的知识.

可以将传统的开发比作10公里长跑, 你知道终点线到底有多少远, 而你的目标就是尽快到达终点. 而在敏捷项目开发项目中, 我们并不知道终点线在哪里, 但知道在某个特定的日期我们应该到达或尽可能接近这个终点, 敏捷开发项目更像是计时赛而不是10公里的比赛: 在60分钟跑的越远越好.

敏捷项目知道何时应该结束, 但是不知道他们要交付什么.

设定和修正目标的时候, 重要的是记住我们无法看到地平线之外的东西, 我们试图规划的内容超出视线越远, 计划的准确性降低的就越迅速.

一个发布计划应该在项目过程中被更新(通常是在每次迭代开始的时候), 以便能反映对发布中应该包含什么内容的当前期待.

在迭代计划中, 我们谈论的是把功能需求转化成经测试的可用软件所需要完成的任务.

开发小组应该将他们的规划地平线限制在不超过接下来的一天, 因此, 他们关注的是对任务的规划, 以及协调个人的活动来完成任务.

敏捷开发小组希望将质量看成不可协调的, 其他的如范围, 进度, 预算则可商量.

故事点是相对的.

故事点估计是对开发该功能所需的工作量, 开发工作的复杂性以及蕴藏的风险等方面的综合.

在敏捷开发项目中, 常常会从并未完整说明的需求开始一次迭代, 这些需求的细节将会在迭代过程中被发现.

敏捷估计与规划的关键原则是先估计出规模然后推算出持续时间.

基于故事点的估计把对工作量的估计和对持续时间的估计完全隔离开来.

虽然工作量和进度密不可分, 但是允许把它们隔离开独立进行估计. 你不再对项目的持续时间进行估计, 你只需要计算或者推算它. 这个区别很微妙但是很重要.

故事点只是对将要进行的工作进行规模估计, 与其说一个项目的持续时间是估计出来的, 不如说是通过求取项目总故事点数, 再除以小组的速度推算出来的.

使用理想日进行估计时, 你需要假定:
所估计的用户故事是你所处理的唯一工作;
你所需要的所有东西在你开始工作的时候会准备好;
不会被打断;

按照耗用日进行估计要求我们考虑在处理这个用户故事时所有可能出现的干扰.

采用理想日进行估计的时候, 最好只为每个用户故事分配单一的估计值. 应该把所有需要的时间加一起. 比如说某个故事需要9个理想日, 而不是说需要4个程序员日, 2个测试人员日和3个产品所有者日

在进行估计的时候, 也应该记住对投入时间递减这一法则. 通常我们花大量的时间得到的一个估计值比起我们花费少量的时间估计的结果不会差很多.

工作量越大, 估计的不确定性越高.

估计的重点不在于绝对的精确, 而在于合理性.

实现一个功能所需的时间是一个关于功能规模(以故事点或者理想日表示的估计)和小组的进度率(以小组的速度来表示)的函数.

以理想日做出的估计会因为开发人员熟练程度的变化而变化, 而故事点不会出现这个问题: 规模就是那么大, 不会发生变化.

如果小组对单纯的规模进行估计存在困难, 我会让他们用理想日开始估计, 然后再让他们转化到故事点上, 我会问"这个功能的规模与我们刚才估计的那个相比怎么样?" 而不是他们需要多少理想日, 大部分小组不会注意到这种逐渐的转变, 而当他们意识到的时候, 他们已经是在用故事点而不是理想日进行思考了.

客户满意度可以分成三种:
必须的功能
线性功能, 越多越好
兴奋点或惊喜点, 未被了解的需求, 因为客户或者用户在看到这些功能之前并不知道自己需要它们.

必须功能没有必要在第一次迭代中就开发出来, 有时候可能部分实现就足够, 因为完成了对必须功能一定程度的支持后, 客户满意度上升的幅度会迅速下降.

对于线性功能, 应该尽可能多的去实现.

如果时间允许, 至少应该确定少量兴奋点的优先级, 把它们包含进发布计划中.

可以通过两个问题来确定一个功能的分类:
如果产品中有这项功能用户会觉得怎么样;
如果没有这项功能用户又会觉得怎样?

对每个问题都采用5点度量的方式进行:
我希望这样
我预期就是这样
我没有意见
我可以忍受这样
我不希望这样

一个项目存在两种不确定性: 目标不确定性和方法不确定性, 目标不确定性可以通过获取更多的产品知识来降低, 方法不确定性可以通过获得更多的有关项目的知识来降低.

瀑布式开发方法会试图先消除所有关于要构建什么的不确定性, 然后再解决如何构建它的不确定性, 这就是"分析是关于要构建什么, 而设计是关于如何构建它". 敏捷开发是同时进行, 只是侧重点不同, 早期更多的解决要构建什么, 而且是最高优先级的, 后期更多解决如何构建, 而且方法逐渐被确定下来.

大故事的分割:
按照用户故事所支持数据的边界来分割大型用户故事
按照大型用户故事中进行的操作对其进行分割, 如将大型故事分割成独立的建立, 读取, 更新和删除操作
考虑把功能性和非功能性需求隔离到不同的用户故事, 从而分割大型用户故事
如果大型用户故事中的小故事具有不同的优先级别, 则可以对他们进行分割.
不要把用户故事分割成: 对用户界面编码; 编写中间代码. 即不要将大型用户故事分割成任务, 而是要寻找一个方法来让一颗曳光弹穿过这个故事.
避免在具有相当规模的功能中增加相关的变化而把事情弄糟, 除非这些变化具有相同的优先级. 比如在处理一个独立的问题时, 修改同一部分代码中存在的错误或者解决其中的一个老问题, 很可能是合适的做法, 但是需要按照和考虑其他功能的优先级时一样的做法来考虑这些事的优先级.

发布计划
在发布规划上建立那种细节水平上的计划是为危险的, 而且会产生误导.

发布计划的对象是用户故事, 它们是对要交付的功能的说明, 而不是要执行的独立的开发任务.

在进行发布规划时, 要把用户故事分解成开发任务还为时过早, 而且对有些用户故事的理解也不充分.

产品所有者的满意条件是由进度, 范围和资源目标的组合来定义的.

项目要么由日期驱动, 要么由功能驱动.

大多数项目要么时间太少, 要么要开发的功能太多, 一般不太可能在可用的时间内完成每个人想要的所有事情

如果在迭代计划中把任务都输入到软件中, 肯定会有一个人掌握着键盘, 对键盘有控制权的人就会拥有巨大的权利

在迭代计划中, 发布计划中的用户故事被分解成了任务, 对迭代计划中的用户故事进行估计时采用的是故事点或者理想日, 而对计划中的任务进行估计则是采用理想小时.

把用户故事变成可用的, 完成的产品所需要进行的所有任务都应该被识别出来.

迭代计划应该只确定那些能够为当前项目带来直接价值的任务.

在敏捷开发中, 对任务的估计应该是团体活动.

所有小组成员共同做出统一的承诺是引向小组成功的关键因素之一

"你们可以承诺交付我们已经讨论过的功能吗?"

大多数小组在计划每天4~6小时的工作量的时候能够取得成功.

速度是粗粒度估计(功能点或理想日)的度量, 它在规划短时间的迭代中的工作时是不够精确的.

不确定性越多, 迭代就应该越短.

小组使用固定的迭代长度时就会形成一种自然的节奏

2周的迭代是最理想的.

一般来说, 项目的实际持续时间会在我们所预想的60%~160%之间

大致的正确比准确的错误要好

对速度预测的步骤:
估计每个人每天可以在项目上的工作小时数
确定在迭代中可以用在项目上的总小时数
随机选择用户故事, 把它们扩展成组成它们的任务, 并确定任务的小时数来填充整个迭代
把上述步骤确定的速度转换成一个范围

跟踪与交流
我们应该只把工作看成尚未开始或已经完成, 而不是看着正在进行, 并保持那样做.

未完成的故事会破坏项目的开发小组和客户之间的信任

在一个项目中, 了解还剩多少事要做远比已经做了多少事有用.

频繁地就计划进行沟通很重要, 因为敏捷计划是频繁更新的.

敏捷估计和规划过程暴露出我们的知识总是不完整的, 要求随着我们了解更多的知识来修正计划

规划中的一个常见的错误就是混淆了对规模的估计和对持续时间的估计

某项工作的规模和完成它所需要的时间是有关系的, 但是很多其他因素也会影响到持续时间, 对于具有不同技能和经验水平的程序员来说, 一定规模的项目所需要的时间量是不一样的.

敏捷估计和规划之所以会成功, 是因为对规模的估计和对持续时间的估计是独立的.

敏捷计划覆盖了3个不同的层次: 发布计划, 迭代计划和当日计划

敏捷估计和规划的12条原则:
让整个小组参与
在不同的层次上进行规划
使用不同的度量单位,让规模和持续时间的估计保持独立
用功能或者日期来体现不确定性. 如果功能量是固定的, 那就用一个不确定的日期范围来表示不确定性, 如果日期是固定的, 就需要表示在要交付的确切功能上的不确定性.
经常重规划
跟踪进度并沟通
承认学习的重要性
规划具有适当规模的功能
确定功能的优先级
把估计和计划建立在事实上
保留一定的缓冲松弛度.
通过前瞻规划协调多个小组