#高效的提出自己的需求(idea)

You have an idea, we need a story!

1. 什么是用户故事?

定义:用户故事是从用户的角度来描述用户渴望得到的功能。

2. 一个好的用户故事包括三个要素：

角色：谁要使用这个功能。

活动：需要完成什么样的功能。

商业价值：为什么需要这个功能，这个功能带来什么样的价值。

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

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

比如: 作为一个KeeeWeee用户, 我想要"...", 以便于"..."

商业价值: 商业价值包含客观的价值,比如:Money;也包含隐性的价值.比如:用户是一种隐性的价值,隐性价值一定程度上能够转化为客观价值.

#No, No, No!

当你孕育很久的设计(想法),拿出来和别人分享的时候,却遭到了别人赤裸裸,血淋淋的反驳.

"你的想法不行"

"你的想法N年前就有了"

"You Idiot"

...

1. 否认、嘲笑、谴责

没有人愿意分享自己的想法,导致一个创业公司失去了失去了包容创造的环境和创新的能力,大家沦为苦逼码农.

负面评价使人消极，成长需要鼓励，别扼杀创造力

2. 局内人和局外人

局内人: 融入他人的想法,积极地寻找他人的优点

局外人: 旁观者清; “如果这里这么做，它会发生什么问题吗”, 共同寻找更好的方案

3. 我们该怎么做??

全力提出想法

不要脱离现实，不带个人情绪的思考

乐于分享

多人决策，少数服从多数(不要僵化，自适应)

#高效的工作:

1. 开发流程

用户故事 --> 故事评审 --> 任务拆分+评估 --> 制定迭代计划 --> 验收

2. 用户故事

概化抽象的需求(idea) => 有趣容易理解的故事

3. 故事评审

理解 & 讨论: 确保每个成员能够理解故事

评估: 优先级[客户参与; Importance] & 完成时间[包含故事点s]

故事点: 理想情况下一个人一天可完成的任务

评审: 评审这个迭代要进行的故事.

原则: 1. 少数服从多数. 大部分人认为可做那么必须做，如反之不做(延后处理);

2.客户意见, 故事的重要性级别非常高.

4. 任务拆分

开发成员负责把故事拆分为粒度更小的开发任务[task]，确保一天或两天能够完成。

何为合适: 一个功能, 一个接口, 确保可以测试和验收. 对于后台来说可能是一个可以对接的接口; 对于前端来说可能是一个测试用例

5. 任务评审

任务估时 & 优先级制定

任务优先级制定原则: 需求优先系数(0~20) * 实现难易度系数(0~1)

6. 迭代计划

迭代周期如何计算: 开发时间 + 集成时间 + 验收 + bugs fix

7. 验收

测试用例

每日验收

每天下班前两小时为固定的测试验收时间.

测试用例 & bug反馈

迭代验收 故事完成度评估 迭代完成情况评估

8. 每日例会

每人汇报内容:

昨日工作内容 & 完成情况 & 遇到什么问题

今天的工作