如果用scrum做sprint plan，怎么确定user story和task

如果用scrum做sprint plan，怎么确定user story和task

总结一下，关于题主的几个问题的回答。

　　如何分析 user story？
　　User story 是从用户的角度提出问题并找到解决方案，进而分解出可执行的 task。假设要给 SegmentFault 加个问卷调查功能，那么就从用户怎么使用问卷入手，从各种交互中最终发现页面具体逻辑和需求，确定需要哪些页面、如何交互、如何呈现，从而完成分解。
　　山寨的说，user story 的源头就是 stakeholder 想要的需求/功能，分解过程就是这个需求怎么用，最终结果是这个需求怎么做。其实，这跟传统的写产品文档没有区别，只是能让整个产品团队都明白需求点的来龙去脉，也许能够更加调动所有人的积极性。
　　就算是设计 api，也可以用 user story，把 api 调用者当做 user 来理解就好。
　　要是不清楚怎么设计 user story 也没关系，能分解的需求就是好需求，定出 task 才是关键。
　　如何分解 task？
　　Task 的关键是要有一个明确的完成条件，比如实现 XX api、实现 YY 功能点等。如果程序员负责写单元测试用例的话，通过单元测试是一个比较明确的完成条件。
　　要足够的小，不能超过 16 小时，或 2 ~ 3 天吧，目的是为了能够很好的控制延期风险。
　　不要太小，半天或一天做个需求最舒服了，太小的话计划所花费的成本可能都大于实现需要的成本了，不划算。
　　Sprint 计划会议如何开展？
　　先准备好差不多成型的需求，如果没有，让少数一两个人先细化的差不多。
　　开会讨论需求，让所有人清楚。有 user story？很好，讲给程序员听，让大家参与进来。没有 user story？无妨，反正明确了需求让程序们做就是。
　　分解 task，确保每个人的 task 足够明确可完成，不是很大，没有失衡。
　　可能要开几次会议，每次发现有任务分解不下去的时候终止会议，下去解决细节问题，等解决后再开会。

支持一下感觉挺不错的