04用户故事与敏捷方法笔记之四

本次阅读笔记为第二部分第十章和第十一章的感想

第十章迭代计划

迭代计划：在讨论故事时，我们要从故事中分解出任务。当讨论过所有故事，并且接受所有任务后，开发人员单独估计他们承担的任务，以确保他们不会做出过于乐观的承诺。

而在讨论故事时过分地深入每个故事的细节会让会议变得冗长、低效，因为会议中不是每个人都需要聆听所有故事的所有细节。

在分解任务过程中，我们要注意以下几点。尽管故事的确可以小到作为工作单位，但将他们分解出更小的任务，一般更符合项目协作的需要。故事是对用户或客户有价值的功能的描述，它们并不是开发人员的待办事项。分解任务有助于发现那些可能会被遗忘的任务。一个故事点任务分解其实是即时设计中的一次短脉冲，而这些短脉冲的集合取代了瀑布过程的前期设计阶段。

在这里，开发员的职责就变成了负责参加迭代计划会议。负责帮助把所有故事划分为任务，而不只是自己想做的故事。负责为认领的任务承担责任。负责确保承担适当工作量的工作。在整轮迭代中，负责监控自己剩余的工作，同时也要监控队友剩余的工作。如果很快就能完成自己的工作，就有责任帮助队友承担部分工作。

在第十一章 测量并监控数据中

完成一个任务或故事所花费的实际小时数对当次的速率没有影响。每日燃尽图在迭代中十分有用，它展示了迭代中每天剩余的小时数。设计及检测一个平均每个故事点出现的缺陷数目的图表可以帮助我们发现团队速率的提高是不是以牺牲质量为代价。