XP开发中的Story Task 与Bug的一些摘录

4，进度表的结构

按照XPlanner的结构而言，主要有Story和Task，一个进度表包含若干Story，一个Story包含若干Task。对于Story的理解可以是Feature也可以是Case，其粒度比Task大，而Task就是我们所说的在该Case下的若干任务。就我们的经验而言，我比较喜欢按照任务的流程进行划分，比如从需求的确定到写设计文档到编码（当然实际Task的粒度要比这几个词汇的粒度小得多，Task粒度应该小，小到以“小时”为单位，而不是以“天”，这稍后为谈到）。然后一个Task至少应该包含以下几项内容：任务名称、任务内容、其所在的Story、任务的实施者、任务的跟踪者、优先级、计划时间、已使用时间、剩余时间、完成任务的实际使用时间等。但我仍然坚持Task也应该保持简单明了，一是一目了然，二是节约时间，三是防止团队成员的抵触情绪，所以Task中需要填写的字段不亦过多。

5，任务粒度要小

任务的粒度绝对不能大，大的是Story而不是Task。推荐的粒度是按“小时”为单位，而不是按“天”为单位，我的一位同事的不错的经验是将任务细化到4小时或8小时以内，并且尽量保持任务的完整性（意思是说，不应该出现事情刚做一半就下班了的情况），这有利于“每日检入”（Daily Check in）和“每日构建”（Daily Build）。粒度太大很明显的缺点是时间估计的误差很大，如果是一个全新的任务（而不是被你重复过无数次的任务）而给出一个“我大概需要三天”的时间估算的参考意义是不大的。另外，我也有一个失败经验，当我用Outlook的“任务”工具为自己指定一个任务时，如果我仅仅指定某个任务应该在未来3天内完成，那么该任务往往被推迟到第三天才真正开始做，甚至被拖延更长的时间，正确的做法是，即便该任务需要3天，那么应该将该任务拆分成3部分（或更多）然后分配到每一天中去，做到今日事今日毕。

如何撰写一个良好的用户例事（How to write a good user story）按道理讲，用户例事是连接团队日复一日工作与玩家收益的最佳渠道。通常很容易能想象出玩家想在游戏里看到什么（比如，“不管我怎样操作我的角色，我要看到超酷的粒子特效。”）。

另一方面，有些工作的内容不是完全符合用户例事的格式。这些东西是玩家不能直接表达出来的，而是迂回的联系到玩家收益上。

对于项目的后期，团队正在处理大量的备受关注的工作，这时Scrum板子的清晰度会被减少，意味着关系到用户的各种收益的例事不能直观的显现出来。Large Animal的团队发现当一个项目进入到开发阶段后期时，很多用户例事最后看起来越来越像围绕着一系列子任务的“超级任务”。
例事，任务，或bug（Stories, tasks, or bugs）在采用敏捷开发模式之前，Large Animal习惯用FogBugz作为任务和bug的共同跟踪工具。尽管这个工具缺乏Scrum的可见性，但是它对于帮助管理大量详细bug报告、减少bug造成的崩溃是非常有效的，特别是在版本处于繁重测试和修订的过程中。

不幸的是，这通常与验证阶段Scrum板上的工作内容重叠。所以，有时会让人觉得很混乱，不知道用哪个工具来跟踪问题。
时间估计（Time estimation）有些事实是不能逃避的，那就是精确估计问题解决方案所花费的时间是很困难的，不论是代码、游戏性还是UI设计。虽然敏捷开发模式使Large Animal的开发过程更舒适、更为可预测，但是估计任务的准确时间仍然是一个进行中的挑战。