《敏捷估计与规划》第七部分 案例分析 （读书笔记）

新年后老大（我们部门的项目经理）宣布我和一名要好的同事各带领一个小组尝试敏捷开发流程，我想一方面是探索有效的开发流程，一方面是查看我们另一方面的能力吧所以买了不少书先看这个吧？后面有个案例就先看它了，没法子比较急嘛，希望能找到借鉴的流程。

以下不记录书中的内容，只通过描述，按照理解写出流程：

一、需求：

1.需求分析全员参与；2.需求有系统分析人员提出，当中伴随提问和解答；

3.全员确定需求一同确定、编写用户故事；

用户故事是以用户角度来讲述的对功能的简短说明。例如，“作为用户，我希望能够保存当前游戏”。用户故事就是一些类似的内容。（我觉得这里可以再有 的形容词吧，例如随时保存）。

编写用户故事记录卡片，卡片内容：“作为<用户的类型>，我希望可以<获得的利益-程序的能力>以便<原因>。(可选填写失败保证：<什么情况下必须保证什么利益>)”

如:作为游戏者,我能撤消一步棋,以便取消一步严重错误的走法.

发给开发人员 卡片，使他们可以记录下东西 注释 甚至画一个图画

故事不要太小，如：撤消和恢复合并起来。 （将相关的写在一张卡片上）

不要想一开始就写好所有好故事,开始时大量写故事的原因是让我们都了解--再次声明是在高层次上了解--可能 有那些功能。

大的程序可以分模块 考虑故事

4.估计拥护故事 估计故事点数

根据讨论故事的难度和消耗给出点数,人手一份点数卡,一起亮出给分.

给分不一直就讨论 分数可以确定故事间的比例

过大点数的故事尽量分割以便迭代 先是弱小的 然后弱小的能被增强(比如多种通信方式只实现一种)

当你想调整一个点数的时候,如果调整的太小 比如 8 到 7 那就不要进行了

查看故事时提示 笼统的定义含义很少

查看故事时会发现依赖关系 如:如果我们实现了 xxx这个故事的点数就是1;如果以来不能摆脱你可以先让它有个空功能

0点数为了与空实现合并

5.准备产品调查

　　问卷：

　　你觉得这样如何　　　我希望这样　　　我想就是这样　　　我没有意见　　　我可以忍受　　　　绝对不能这样

　　有用户故事一

　　没用户故事一

　　有用户故事二

　　没用户故事二　　　　

　　

　　这样可以帮我门决定　　必须的　　有吸引力的　　多余的　和缺少的　和为他多付钱的功能　需求

　　不要浪费问题在　很确定的问题上

　　类功能　首先必须的功能　其次觉得越多越好的功能　再次是兴奋点

决定优先级

6迭代和发布规划，第一轮

创建任务卡片，如：

编码状态管理类

16小时 （一天最好按六小时工作时间算）任务卡片通常开始不写人名

让人们对故事做出承诺，在承诺后问今后这段时间会不会有个人的事情要做

首先确定自己在一次迭代期能工作多少小时 通常按一天六小时算

然后预想离开

创建迭代期间离开记录

谁 离开时间

相减获得可承诺时间

用可承诺时间判断可以承诺多少任务卡片

这样 可能就会要求一些任务少的人多承担些别人的任务 队大家的素质有很大要求

每个人尽量填满这次迭代

7发布规划 （多长时间能发布呢？）

根据调查确定优先级

必须的功能

吸引力（多了可能提高价格）

线性的功能（线性功能越多收益越多 汽车马力 卫星频道）

不要试图规划下次迭代 因为下次规划时我们会比现在更清楚

确定下现在的计划

二、设计

这里没有提到设计部分，不过一定用很多面向对象思想，保证了模块间的低偶合、高复用、可扩展、可维护 以保证可迭代的开发。

三、迭代开发（伴随测试和重新规划）

8第一次迭带完成

也许会发现有些任务没能完成,但迭代回顾(对第一次的演示) 依然开始

同时 我们也获得了队伍速度 一次迭代 多少点

得到了更准确的进度

结合以前掌握的知识，觉得这里也许需要一次代码评审，检查代码质量 重构 获得模式保证迭代

9第二次迭代计划

根据速度 大家承包新故事 其中可能有人需要变换角色 这需要敏捷的团队 的队员有较高的素质以便能做些互换工作

10 第二次迭代完成

获得更准确的队伍速度

可能由于需求的变动和新的功能加入 产生范围的蠕变 故事被增加 修改或合并

11修改发布计划

我们可以选择发布一个平凡 按计划制作和发布的系统

我们也可以发布一个更接近需求和真理但会延迟的系统

我们也可以不延迟 因为我们舍弃了一些优先级低的任务

究竟如何 这是该让领导给个建议的时候了

四、仿佛没有提到验收测试

看来敏捷是一个需要团队默契配合的过程

.敏捷的规划更注重 用实际的速度(开发过程中不断精确,因为越是接近后期的计划往往更家准确).

敏捷的开发更 更注重项目是可迭代的，先完成优先级高的 或支持的一组功能的一个 （支持通信方式的一种），敏捷的代码必须保证是可迭代的。模块化的高复用性低偶合 可扩展的

结束