今天完成的事情：（一定要写非常细致的内容，比如说学会了盒子模型，了解了Margin） 

根据任务二给出的示例先尝试着写一下用户故事，只是按照上面的板块大致写了部分，后续按照流程走的时候会做修改的

因为之前做的是用户故事的资料收集，所以没来得及把竞品分析的资料做总结，只是大概的看了一下

明天计划的事情：（一定要写非常细致的内容） 

补上任务二的竞品分析，做竞品总结

按照调研的结果修改用户故事

遇到的问题：（遇到什么困难，怎么解决的） 

流程上先写了用户故事，未做用户调研，这两天补上

我认为，草船云的关键词应该是“创业”类型，回家学习的关键词应该是“学习”类型

所以我想用以上两个关键词搜索相关的网站做竞品分析

在选择网站的上面选一些主流企业下的网站，先把出现频率较高的布局模块准备上，后面再做优化

收获：（通过今天的学习，学到了什么知识）

学习了用户关系的相关概念，尝试着用自己的理解去叙述，然后写用户故事

关于用户故事

作为一个<角色>, 我想要<活动>, 以便于<商业价值>

举例：

作为一个“网站管理员”，我想要“统计每天有多少人访问了我的网站”，以便于“我的赞助商了解我的网站会给他们带来什么收益。”

这个是需要产品负责人去构想用户的心理需求，要求最直接的体现出用户的需求，用户故事旨在让产品告别冗长的文档需求，直接明了塑造形象。

Ron Jeffries的3个C

关于用户故事，Ron Jeffries用3个C来描述它：

卡片（Card） – 用户故事一般写在小的记事卡片上。卡片上可能会写上故事的简短描述，工作量估算等。

这个充分的体现出用户故事的特性，让人很容易的与小小的卡片联想起来，卡片适用于充分的但又简短的描述。

交谈（Conversation）- 用户故事背后的细节来源于和客户或者产品负责人的交流沟通。

我主张最直接的面对面交谈，而只有谈话才能让用户一次次去叙述，才能获取客户最真实的想法，任何一个美妙的故事都是需要去讲出来的。

而产品之间的对话不是一次性的，而是持续的有深度的交谈：写故事的时候会有对话，产品宣讲的时候有，估算的时候有，迭代会议的时候有，日常站立会议的时候有、测试的时候有，Scrum流程中最强调交流

口语交流然后书面文档记录获取信息，这才是交谈

确认（Confirmation）- 通过验收测试确认用户故事被正确完成。

我理解为是一个验收标准，有一个验收标准，开发和测试团队就能更好的理解要构建和测试的是什么，产品团队可以确认用户故事的实现是否合符预期。

用户故事的六个特性- INVEST

INVEST = Independent, Negotiable, Valuable, Estimable, Small, Testable

一个好的用户故事应该遵循INVEST原则。

独立性（Independent）— 每一个用户故事都应该独立于其他的用户故事。不然连确定优先级，工作量估算都变得很困难。

可协商性（Negotiable）— 一个用户故事的内容是可以协商的，不是固定的一纸合同。我们需要更多的沟通协调，太细节的用户故事会限制我们与客户的沟通。

有价值（Valuable）— 每个故事必须对客户具有价值（无论是用户还是购买方），故事最好是由用户来讲，这故事才有价值。

可以估算性（Estimable）—开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。要是无法估计那就需要更多的沟通，掌握足够的技能和知识，或者是故事过大，需要再细致化再拆分故事

短小（Small）— 一个好的故事在工作量上要尽量短小，可以确保在一个迭代或Sprint中能够完成。用户故事越大，风险就越大越不可控

可测试性（Testable）—一个用户故事要是可以测试的，以便于确认它是可以完成的，不能够测试，就无法知道它什么时候可以完成。