image.png
image.png
三种角色
1. 产品负责人（Product Owner）
主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。
2. 流程管理员（Scrum Master）
主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。
3. 开发团队（Scrum Team）
主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到Sprint的目标。
四种会议
1. Sprint Planning Meeting（Sprint计划会议）
从Product Backlog（产品需求列表）中挑选出一些User Story作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个User Story进行细化，形成一个Sprint Backlog；
- 将User Story拆分成一个个开发任务（task）
Product Backlog（产品需求列表）
User Story（用户故事）是用户视角的描述；开发任务是具体可执行的开发工作，这是从开发视角来描述的。这两者会不一样。
- 评估工时
image.png
强调自组织，所以采用纸牌这种方式。一般半天作为一个故事点（天数的两倍），再细化就没有必要了。所以就把纸牌上的数字当做天数好了，这样最方便。
- 排优先级
强调自组织，沟通协调工作都由开发人员自己解决，没有专门的项目居中协调。
- 计划会议控制在4个小时之内，也就是半天（1个故事点）；
2. Daily Scrum Meeting（每日站立会议）
每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint燃尽图）
image.png
image.png
image.png
现在有各种工具来做任务看板，不需要纸片满天飞了。
3. Srpint Review Meeting（演示会议），也称为评审会议
产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum Team的成员都要向他们演示自己完成的软件产品。
同样，这个会议控制在4个小时之内，也就是半天（1个故事点）；
4. Sprint Retrospective Meeting（回顾会议），也称为总结会议
以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中；
参考文章
软件开发模式之敏捷开发（scrum）
个人的一些想法
-
虽然说Scrum反对文山会海，但是并不是说Scrum不需要沟通和文档。相反，Scrum更重视沟通和文档。比如前后端调试的接口文档是必须要的，并且很可能更进一步。比如，让测试将冒烟用例需要的数据直接通过后台输入，开发的时候就完成冒烟测试；
-
计划、演示、总结会议4个小时是需要的；如果在4个小时内还不能达成共识的内容，宁可先移出去，延后执行。可落地比什么都重要。
-
每日站会看上去很简单，实际执行中是最难贯彻的。会有各种变通方式被提出来，不过最后都会使站会流于形式。其实，这是Scrum中最有作用的一个方面。
-
Spring周期建议为3周，另外放1周时间进行产品试用、技术预研、需求和设计评审等工作。一张一迟，有节奏感，才能持续。虽然叫敏捷开发，但是绝对不是简单的快。
-
Scrum强调的是团队的力量，类似于特种小分队，并不突出个人英雄主义。所以，绝大部分的公司业绩考核，比如KPI，对于Scrum的推行不但不是助力，反而是阻力。
-
一个可行的方式是团队考察。比如计划会议结束之后，就应该给出Sprint完成的奖励（就算只有1000元也是有激励效果的）。按时完成，PO接受了产品，就可以兑现。至于这1000元奖励团队内部怎么分配，就像平时的问题和任务沟通一样，团队成员自行解决。
这种看似有缺陷的只有奖励没有惩罚的激励措施，反而是最有效果的。Scrum最核心的是交付产品，但是最吸引开发人员的，却是这种自组织的管理方式。（自己管自己，当然只要奖励没有惩罚，这是人的天性）
