2021-01-26 关于待办事项列表细化的困惑

《敏捷实践指南》中这样描述：

产品负责人为即将进行的迭代准备一些故事。通过会议细化足够的故事。细化过程应该有多长时间，还没达成共识，但提出了三种模式：

1.基于流程的敏捷即时细化。团队将下一张卡片从待办事项列表种拿出来讨论。

2.许多基于迭代的敏捷团队在两周的迭代种用1小时的时间盒讨论。团队选择一个迭代持续时间，为他们提供足够频繁的反馈。

3.基于迭代的敏捷团队的多次细化讨论。团队可以在陌生的产品、产品领域或问题领域使用这一技巧。

细化会议上，产品负责人可以向团队介绍故事创意，让团队了解故事中潜在的挑战或问题。如果产品负责人不确定依赖关系，还可以请求团队对相应功能进行刺探，以了解风险。

产品负责人有很多方法处理待办事项列表的细化准备与会议，其中包括：

1.鼓励团队在开发人员、测试人员、业务分析人员和产品负责人三方面开展合作，一起讨论和撰写故事。

2.把整个故事的概念呈现给团队。团队进行讨论，并根据需要将其细化为许多故事。

3.与团队一起寻找各种方法探索和撰写故事，确保所有的故事都足够小，以便团队能源源不断地交付完成的工作。考虑每天至少完成一个故事。

团队通常有一个目标，就是每周用不超过1小时的时间来为下一批工作细化故事。团队希望把时间尽可能花在工作上，而不是计划上。如果团队需要每周花1小时以上的时间来细化故事，那么，产品负责人可能会过度准备，或者团队可能缺乏评估和细化工作所需的一些关键技能。

一直以来都面临一个困惑：开发人员在迭代中花多长时间去理解、讨论需求？每周1个小时似乎不够，很多时候一两个需求就讨论1个小时。我这里指的故事可能粒度比较大，是一个业务流程。开发人员反应，事先对需求讨论和理解不够，在任务估算与拆分时就比较茫然。