今天完成的事情：

1.首先奉上过任务二“最低标准”三图。

草船云页头。

草船云 页尾。

手机APP。

2.任务要求是，根据示例以及我们将要实现的功能，写出草船云的页头页尾的story。

再参考任务资料中设计规范，根据story画出草船云页头页尾的原型。

手机APP同理。

首先百度一波story，把能读的都读了。

用户故事的六个特性- INVEST

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

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

· 独立性（Independent）— 要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划，确定优先级，工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。

· 可协商性（Negotiable）— 一个用户故事的内容要是可以协商的，用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。

· 有价值（Valuable）— 每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。

· 可以估算性（Estimable）—开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。

· 短小（Small）— 一个好的故事在工作量上要尽量短小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。

· 可测试性（Testable）—一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：软件应该是易于使用的。

其中有一篇，什么是用户story？    https://www.cnblogs.com/henryhappier/archive/2011/02/23/1962617.html  值得一马。

story是只描述那个产品的参与者，需要什么，以及它需要的目的是什么，story的目的是为了确认用户需求。

尝试着写出第一条user story，拿草船云页头为例，从用户需求出发，编写第一个针对用户的需求描述。

作为一个用户，我想要在首页看到banner，以便于我可以快速了解草船云的主要内容。

作为一个用户，我想要直观的看到搜索栏，以便于我能快速找到我想要的。

作为一个用户，我想知道草船云的优势有哪些，以便于我能和其他公司选择对比。

作为一个用户，我想知道草船云的收费标准，以便于我做预算和与其他公司作对比。

作为一个用户，我想要有在线咨询，以便于更清晰的了解他们的产品服务等。

作为一个用户，我想在首页可以注册，以便于以后登录。

作为一个用户，我想要绑定第三方微信，以便于快速登录和保护账号安全性。

草船云页尾。

作为一个用户，我想知道草船云能做什么，以便于我可以快速找到我需要的产品。

作为一个用户，我想知道草船云的微博或是公众号，以便于我能随时随地接收最新讯息推送。

回家学习APP

作为一个用户，我希望能搜索自己想要学习的内容，以便节省时间精力。

作为一个用户，我希望能通过标签筛选课程列表，以便于找到我还想学什么。

作为一个用户，我希望有课程提醒功能，以便于监督我上课。

作为一个用户，我希望能有各种学习圈，以便于学习交流认识更多牛人和分享自己的学习成果。

作为一个用户，我希望系统可以自动推送我学习课程的相关课程，以便于加深对主课程理解。

作为一个用户，我希望有我的信息，以便于我修改个性签名，账户相关等。

作为一个用户，我希望能有测试功能，以便于测试我学习之后的水准。

作为一个用户，我希望能在首页可以直观的查看自己正在学习的课程，以便于节省时间。

作为一个用户，我希望能看到我的水准在所有学习课程里处于什么定位，以便于激励自己努力学习。

作为一个用户，我希望能关注大佬牛人，以便于向他们学习。

3.关于故事点，网上给出的定义是：

故事点是一个度量单位，用于表示完成一个产品待办项或者其他任何某项工作所需的所有工作量的估算结果。

且举了个栗子说明。

然后找出里面最简单的用户故事（这里的“简单”，意思是说实现周期最短）。我们不一定非常精准的判断哪个最简单。只要挑出你觉得最简单的就行了。比如，我们觉得“输入管理密码”是最简单的用户故事。然后我们判断说，这个用户故事算1个“故事点（story point）”。

story card 故事卡的定义。

不过一般我们不会列出清单，而是做出一堆卡片贴在墙上，每张卡片记录一个用户故事，然后将故事点写在卡片上面：

这样的一张卡片就叫“故事卡（story card）”。

那么问题是，输入管理密码是一个用户故事，又同时是一个故事点，那么我们要把小的用户故事，写到大的用户故事（故事卡）里？

之后，围绕故事点开始百度。

故事点事对于规模和复杂度的估算，所以，首先他是一个不精确的值，第二，它应该是一个相对的值，由此来看，故事点是一个粗略的相对估算而不是精确估算。

一个讲的还算明白的链接。

https://blog.csdn.net/superkunkun/article/details/53932934

最后我分析

所谓故事点，就是把一个用户故事，尽可能全面的拆分成数个故事点。每一个故事点，都是其领域完成周期最短，且不可或缺的。也就是说，故事点组成用户故事，用户故事包括其内所有故事点。故事点的实现，就是其父类用户故事的实现。故事点代表了用户故事的工作量。

以上是我最初的理解，这时我忽略了文章中关于时间的概念。

当我看到这篇文章的时候，观念又变了。

https://blog.csdn.net/superkunkun/article/details/53932934

Story points 不是衡量复杂度的一个度量单位，而是一个相对的时间单位。代表的是我们的团队，完善这一个用户故事，所需要的相对story point，这个

相对故事点，是我们通过完成某个故事点测量出来的。

估算一词贯穿整个故事点知识面。由此可见，预估对PM来说是一项很重要的技能。估算出什么功能什么时候可以上线，让大家心里有谱很关键。

4.不是“最低标准”的三图。

草船云页头。

草船云页尾。

回家学习手机APP 一级导航栏原型

明天计划的事情：

完善任务一 任务二，做任务小结，准备开始任务三。

同时围绕story，迭代，storycard，storypoint等关键词，了解相关资料。

去看看storycard的制作过程，要准备什么，怎么做，做成什么样。

遇到的问题：

当开发前，我们才去细化STORY故事，把他变成需求。

或者，开发前，我们扔掉STORY，因为它已经不重要了。

任务中的story  是根据示例和页头页尾信息展示写出来的。

1.那么在实际开发中，story是根据什么写出来的？什么时候写？

2.看了很多博文一以及csdn，还是不太清楚story的流程，

3.比如 我们先针对产品，列出 story 然后制作出 story卡片，

4.在制作卡片的同时我们要做什么？

5.画原型图是卡片制作之前还是之后？

6.story有什么实际功效，他在我们接到任务，到产品上线这个流程中扮演什么角色？

7.故事点怎么写？

8.一张故事卡片中存在大概多少个故事点才算合理?

收获：

详见今天完成的事情

蓝字为老大直播敏捷开发讲到的，就记住这么多。

一个迭代，10到15个story 不能再多了。

每天集成测试

为什么拆成前后端，

1.职位的拆分是为了保证可以并行工作。

2.每个人专注的领域不一样，一个人不可能前后端都关注并且有高水准。

前端做的story 和后端做的story有可能不一样，所以需要沟通。

我有听全程老大讲的敏捷开发，在其中也能摸到我们做实际项目的时候的一些边边角角，因为一边做任务一边听，所以也没记住很多。

从产品经理视角，故事更接近“用户任务、产品功能、解决方案”，需求更接近“问题、用户需求场景”

首先我们并不在一开始就把所有的东西都想清楚，而是仅仅以STORY的方式跟踪记录我们未来要做的事情。

关于任务2后的两个深度思考。

1.什么是用户story？

答：一件用户通过系统完成他一个有价值的目标的事，这样的过程就叫用户故事。这里强调的是通过系统，“故事”并不是什么都行，一定是在一个系统面前，每个用户要完成同样的目标，都要做这个系统设定的例行的事。

2.如何拆分用户story？

也是我的一个问题，去网上搜索了一波，都写的很专业。有些不懂，实际操作的时候到底是怎么做的？

答：拆分用户story 我的理解就是拆分成小的story（或是直接拆分成任务），而拆分模式分为好多种，网上有不赘述。拆分之后的story，故事规模明显变小，同时每个故事都提供了不同价值。拆分的同时也可以先放弃优先级最低的小story。（优先级昨天还不懂，今天听了老大讲之后基本上懂了）

拆分之后的小任务也要符合invest原则。