怎么写userstory _userstory

1. 如果用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 足够明确可完成，不是很大，没有失衡。
可能要开几次会议，每次发现有任务分解不下去的时候终止会议，下去解决细节问题，等解决后再开会。
2. 什么是用户故事用户故事（user story）是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素：
1. 角色：谁要使用这个功能。
2. 活动：需要完成什么样的功能。
3. 商业价值：为什么需要这个功能，这个功能带来什么样的价值。
用户故事通常按照如下的格式来表达：
英文：
As a , I want to , so that .
中文：
作为一个，我想要，以便于
举例：
作为一个“网站管理员”，我想要“统计每天有多少人访问了我的网站”，以便于“我的赞助商了解我的网站会给他们带来什么收益。”
需要注意的是用户故事不能够使用技术语言来描述，要使用用户可以理解的业务语言来描述。
Ron Jeffries的3个C
关于用户故事，Ron Jeffries用3个C来描述它：
卡片（Card） - 用户故事一般写在小的记事卡片上。卡片上可能会写上故事的简短描述，工作量估算等。
交谈（Conversation）- 用户故事背后的细节来源于和客户或者产品负责人的交流沟通。
确认（Confirmation）- 通过验收测试确认用户故事被正确完成。
3. 不要盲目执行任务,要领会用户故事（如何写用很多敏捷团队将故事点和复杂度点作为同义词来使用，他们相信这比使用“小时”更好，因为这些点数是基于复杂度和相对大小的。
Mike Cohn则表示，使用故事点来描述特性的开发复杂度是不对的，应该使用工作量。Mike提到：我发现太多的团队认为，故事点应该基于用户故事或特性的复杂度，而不是开发所需的工作量。
这些团队通常将“故事点”定义为“复杂度点”，这看起来不错，可能还更精确，但却是错误的。故事点与特性的复杂度无关，而与开发特性所花费的工作量有关。