用户故事与敏捷方法—用户故事不良症兆

故事太小

症状：经常需要调整估算

解决方法：一定程度上合并故事

 

故事相互依赖

症状：故事相互依赖，所以很难做迭代计划

解决方法：把相互依赖的故事合并成一个故事

 

镀金

症状：开发人员在迭代计划中实现了计划外的功能，或者仅仅凭借自己的感觉实现故事，实际的功能超出了实际的需要。

解决方法：提高项目组中每个人任务的可见性，这样团队就自我约束，减少镀金。

 

细节太多

症状：在实现故事之前花太多功夫去收集整理故事细节

解决方法：小卡片记录，“如果总是需要写满小卡片，那下一次就用一个更小的卡片”——迫使故事作者有一事的减少记录更多的故事细节

 

过早考虑用户界面细节

症状：在想怒早起编写的用户故事就已经包含用户界面细节

解决方法：尽量避免

 

想得太远

症状：不是出于团队规模和地域的考虑，希望用软件而不是小卡片记录故事；建议用更精准的方法来估算

 

故事划分太过频繁

症状：在在迭代计划的时候为了确保迭代工作量合适，频繁的划分用户故事。

解决方法：如果感觉划分故事太过频繁，应该考虑扫描剩余的故事，找到真正需要划分的故事。

 

客户很难为故事安排优先级

症状：安排优先级太困难（为什么？）——可能故事太大或者用户故事体现不出商业价值

解决方法：最好让客户来写用户故事

 

客户不愿意写用户故事，也不愿意为故事安排优先级

症状：项目客户不愿意承担写用户故事和安排优先级的责任