Scrum workflow
收集及整理 User Case
用户故事是描述对用户有价值的功能，好的用户故事应该包括角色、功能和商业价值三个要素。
用户故事通常的格式为：作为一个<角色>, 我想要<功能>, 以便于<商业价值>。一个好的用户故事包括三个要素：
- 角色：谁要使用这个功能。
- 功能：需要完成什么样的功能。
- 价值：为什么需要这个功能，这个功能带来什么样的价值。
用户故事通常按照如下的格式来表达：
中文：作为一个<角色>, 我想要<功能>, 以便于<商业价值>
举例：“作为招聘网站注册用户，我想要查看最近3天发布的招聘信息，以便于我看到最新的招聘信息”。
为了构造好的用户故事，我们关注六个特征。一个优秀的故事应该具备以下特点：
- 独立的（Independent）：我们要尽量避免故事间的相互依赖。在对故事排列优先级时，或者使用故事做计划时，故事间的相互依赖会导致工作量估算变得更加困难。通常我们可以通过两种方法来减少依赖性：1.将相互依赖的故事合并成一个大的、独立的故事；2.用一个不同的方式去分割故事。
- 可讨论的（Negotiable）：故事卡是功能的简短描述，细节将在客户团队和开发团队的讨论中产生。故事卡的作用是提醒开发人员和客户进行关于需求的对话，它并不是具体的需求本事。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。
- 对用户或客户有价值的（Valuable）：用户故事应该很清晰地体现对用户或客户的价值，最好的做法是让客户编写故事。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。
- 可估算的（Estimable）：开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：1.开发人员缺少领域知识；2.开发人员缺少技术知识；3.故事太大了。
- 小的（Small）：一个好的故事在工作量上要尽量小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。
- 可测试的（Testable）：故事必须是可测试的。成功通过测试可以证明开发人员正确地实现了故事。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：用户必须觉得软件很好用。
** 此环节的产出物为「User Case」**
细化需求
PD将 User Case 细化成具体需求，我们可以认为这个过程是定义问题的过程。
** 此环节的产出物为「PRD文档」 **
KickOff Meeting
Kickoff 会议应该控制在最长20分钟以内,为通气会.只讲解需求,不提出任何解决方案
参会人员: 需求方,PD,设计,技术,功能使用方,利益冲突方
出席人员推荐是相关部门 Leader 或者相关负责人
相关参会者必须参加,如果有事,必须指定一个人到场参加,会后由指定的人负责转述相关事宜. 并且认同指定的人做出的任何决定.
在这个会议内，需要传达的信息有如下几点。参会者进行讨论,提出意见. 最终对以下信息明确并达成一致:
- 背景与意义
- 目的与目标
- 做法、功能点概述
- 需要那些资源
- 初步计划(必须清楚 1.时间点,里程碑 2.各个时间需要的资源)
** 此环节的输出物为「对上述信息达成的共识」 **
Solution Design
Done is better than perfect
Move fast and break things
在此环境中PD将依据上一环节达成的共识完成产品原型的设计并针对里程碑完成适当的迭代拆解。同时在整个过程中,要权衡实现原型需要的时间是否符合之前设定的时间点,各个阶段的资源调度是否会有问题。
需要注意的是：
- 解决方案是为了在计划时间内解决计划任务而采取的方案。在制定整个解决方案的过程中要杜绝追求完美.很多时候我们的想法并没有得到用户的认可,也并不知道是否用户一定能认可,所以需要第一时间上一个完成版本获得用户反馈而不是做到自我以为的完美,结果发现80%的功能没人使用.小步快走,才能更快的得到反馈进行改进。
- 根据冰山理论 iceberg_model 你认为的未必真的是你认为的那么简单,所以产生解决方案的过程中,需要充分进行沟通。
举个例子：
付费购买的月费会员系统
假定简单设计的feature list应该包括:
* 会员付费开通
** 支付渠道-支付宝
** 支付渠道-微信
** 支付渠道-银联
* 会员续费
** 手动续费
** 自动续费
* 会员特权
** 特权1
** 特权2
* 等级特权
** 会员等级(成长值)
** 成长累计
** 成长折扣
* 会员积分兑换
方案一:每个功能都开发好后上线版本..耗时4周.
方案二:
1. 开发完成一个支付渠道的会员付费和核心特权 耗时一周 首个里程碑发布
2. 开发会员续费+部分特权 耗时一周 第二个里程碑发布
3. 开发会员等级系统+部分特权 耗时一周 第三个里程碑发布
4. 开发会员积分兑换+部分特权 耗时一周 第四个里程碑发布
理想情况下:
方案二比方案一提早上线3周.意味着可以先一步获取用户的反馈.多获得了3周的付费用户.
试想极端情况:
上线后,发现根本没有用户想为会员买单. 方案一耗时4周得到了这个结论.方案二用了1周.
在精益创业the_lean_startup 这本书中作者提出了杜绝浪费的理念,在提出解决方案的过程中值得参考,看看是否有造成没必要的浪费:
* 问题找错 辛辛苦苦做了一个世界独一无二的可以吹头发的皮鞋，可是用户没这问题，做出来的产品没人要。
* 解决方案做错 辛辛苦苦花了一年做了一个独一无二的可以吹头发的皮鞋，可是用户需要的是可以吹头发的手机，做出来的产品没人要。
* 过早优化 一个可以吹头发的手机都没卖出去，就在苦苦思考如何把它变得更加轻薄，花大把时间精力追求 0.5cm 的设计。
* 过早扩张 一个可以吹头发的皮鞋都没卖出去，就在苦苦思考如何寻找风投，建厂，找地皮，等等。
** 本环节输出物为PRD文档及技术实现方案的概要设计 **
Spring Planning Meeting
- 针对下一迭代周期内计划交付的结果进行排期，每个任务明确到责任人。
- 通过 T-shirt size 法预估耗时。
- 注意预留用于修复bug的时间。
每日站立会议
- 会议准时开始。对于迟到者团队常常会制定惩罚措施（例如罚款，做俯卧撑，在脖子上挂橡胶鸡玩具）
- 不论团队规模大小，会议被限制在15分钟。
- 所有出席者都应站立。（有助于保持会议简短）
- 会议应在固定地点和每天的同一时间举行。
在会议上，每个团队成员需要回答三个问题：
- 昨天你完成了那些工作？
- 今天你打算做什么？
- 完成你的目标是否存在什么障碍？（Scrum主管需要记下这些障碍）
测试 上线 及 验收
参会人应该在 kickoff 会议人基础上包含 测试 及具体开发者.
这一阶段主要是来验证成果是否满足了预期的需求.
没有问题则准备上线,有问题则汇总问题后进入下一个周期循环.
Sprint Retrospective Meeting
- 本Spring迭代内计划交付的功能、成功交付的功能、未交付功能的原因
- 与会者回顾本Spring迭代周期内，觉得做的不错需要保持的点 以及 觉得需要得到改善的点。 （可以是技术上、产品上、协助过程中、流程优化上 任意的point）
线上问题反馈及响应
所有问题请直接反馈给PD或测试, 由 PD或测试 负责记录并根据紧急程度决定是否转达给研发.
针对 Bug 我们暂定4种级别：
1-urgent,系统大面积不可用,必须马上改,需要申请紧急发布
2-high,明显的bug,需要修改,下一次发布修复
3-medium,不严重的bug,时间够时下一次发布修复
4-low ,可以忽略的 bug, 视难度及时间决定
Tech Weekend
每月组织1-2次的（外部或内部）技术分享
