笔记《敏捷估计与规划》第7部分 案例分析

第7部分 案例分析

第23章 案例分析
P242 等待美工 -- 说明会议必须所有团队成员都参加，虽然美工对于算法引擎不会有帮助，但是她会有助于帮助团队产生一个好的产品。

P245 团队一起确定需求。

P246 不记录在电脑表格里，而是用卡片（可以方便的画图，加入注释等等）。

P246 合并较小的故事

P247 显而易见的原因可以不用写“以便于……”。

P247 根据游戏前，中，后来构思需求 ---可以通过一些阶段来统一团队思考需求的方向。

P248 不必太在意故事属于哪个阶段。所谓“阶段”只是辅助人们思考而已。

P249 建立Backlog--->估计--->产品调查。

23.2 估计用户的故事
P250 开始的一，二个用例不好估计，可以在后面重新更新这些用例的估计。

P250 团队根据每个故事，询问其细节，进而进行估计。--->通常包括界面，获取需求，非功能需求

P250--P251 "开始游戏"的界面并不需要十分精美，因为有另外一个用户故事"让界面赏心悦目" ---可以将需求和非功能需求分开。分开的好处是：两个故事的优先级可以并不相同，因此我们可以先完成一个已经实现功能，但是比较丑陋的版本，稍后的迭代 中在完成精美的版本。

P251 "恢复游戏"是2 --- 1界面，读xml，设定棋子。

P252 "与弱小对手交手"，要考虑测试。 --- 对于一个算法，或有点儿逻辑的问题，我们都需要考虑测试。

P254 讲"与弱小对手交手"的故事分解为3个小故事 -- 注意它们的分解方法。

P255 ……注明"总是只采用……" 的满意条件。

P255 不对“与高级电脑游戏”进行故事分离，而是在更接近它的时候在处理。

P256 注意，在估计“双人对战”的用例中，讲“弱小引擎”中的一个“自动判断胜利条件”分离出来了。 ---- 说明，如果某个故事被公用，它有可能被隔离出来。

P256 注意估计“双人对战”时，虽然用到了“撤销、恢复”，“请求提示”的功能，但是并没有加入这些故事的工作量，因此是3. ----说明，故事之间可以有依赖，而这依赖并不计入到该故事的工作量中，但是我们可能需要记录该依赖关系。

P257 注意“请求提示”需要“算法引擎”依赖。但是却可以通过下面的方法来解除依赖！！！！
1，让“请求帮助”给出一个随机的位置。
2，加入“得到有用的帮助” ---- 用来将算法引擎加入到“”的故事。 该故事的工作量为0， 只是用来提醒而已。
说明，我们可以通过“无效”--->“有效”的方法分开依赖。

＋＋＋＋＋

佳为好友 2012-12-23 10:03 发表评论