用户故事的困难 - Agile307/agile GitHub Wiki

用户故事已经在业内使用了多年，到目前为止，在与业界交流时，仍然存在着不少困难，试图识别如下。

• 困难1：如何分拆故事？
  往往故事来自于史诗，刚开始比较模糊，到后面发现有许多细节要处理，而一个迭代内来不及处理了， 如果坚持一个故事在一个迭代内能够处理完，那么这个故事就要分拆。 分拆之后，2个故事是存在上下文关联的，如何保持关联追溯？

• 困难2：如何处理关联到以前故事的修改升级？
  物理故事卡片难以长期保存，而故事完成后不定何时需要修改，有些故事上线后马上收到反馈，需要在下个迭代修改； 有些故事上线2个月后，碰到新的要求需要修改。如何查找以前的故事？如何了解本次修改相关的故事？

• 困难3：如何估算故事的大小？
  全新的故事与修改的故事分别如何估算？ 故事的大小与 故事所要花费的工作量是什么关系？ 故事的任务是否需要识别，如何识别？ 对任务仍然需要估算吗？ 如何估算故事的任务？

• 困难4：燃尽图如何绘制？
  如果按故事点作为单位，完成后才算燃尽故事点，那么往往前期的燃尽图比较平坦；如果按剩余工作量工时作为单位， 每天每任务的跟踪显得比较繁琐，而且在开始时识别所有的剩余任务工时是很困难的。

• 困难5：如何直观了解故事之间的关系？
  列表形式的待办列表只从优先级来排序，无法直观的了解故事之间的关系；就算是双列表形式和树形的待办列表也是从优先级排序的，也不能直观了解故事之间的关系。而不了解故事之间的关系，就无法判定优先级，因此单单的列表形式待办列表排故事优先级，需要PO在大脑中进行关联依赖等等分析，或者借助于其它工具或者形式。