敏捷实施流程

#高效的提出本身的需求(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. 每日例会

每人汇报内容:

昨日工做内容 & 完成状况 & 遇到什么问题

今天的工做