敏捷开发（二） Scrum 实践

归档至github

前言

今天，几位同事带着我先过了一次Scrum 实践，走了一个流程，感觉内容很多，一时估计没法消化，做个笔记。

Scrum简介

Scrum是迭代式增量软件开发过程，通常用于敏捷软件开发。Scrum包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。虽然Scrum是为管理软件开发项目而开发的，它同样可以用于运行软件维护团队，或者作为计划管理方法：Scrum of Scrums.

角色

“猪”角色

• 产品负责人（Product Owner）
  通常由市场部门的人担任

• 敏捷教练 (Scrum Master)
  通常由开发组组长担任

• 开发团队 (Scrum Team)
  包括开发,需求,测试

“鸡”角色

• 用户
  软件是为了某些人而创建！就像“假如森林里有一棵树倒下了，但没有人听到，那么它算发出了声音吗”，“假如软件没有被使用，那么它算是被开发出来了么？”

• 利益所有者 (客户，提供商)
  影响项目成功的人, 但只直接参与冲刺评审过程。

• 管理者
  为产品开发团体架起环境的那个人

流程

启动会议
->每日站会
->show Case
->迭代总结会议

有的地方也写成如下名字：
　冲刺规划会议（Sprint Plan Meeting）
->每日站立会议（Sprint Daily Meeting）
->冲刺复审会议（Sprint Review Meetion）
->冲刺回顾会议（Retrospective Meeting）

启动会议

1.需求
需求需要和PO沟通 主要有如下几点：

• 工作来源：这份工作是谁安排的，要求达到什么目的
• 细节问题：这部分需要做好功课，你需要站在一个开发者的角度，来思考这些细节，这也是为你的开发团队向PO提问。
• 工作量预估

2.用户故事拆分
As For Do 原则

• As（用户角色）： 该功能是为谁设计的，预期用户是哪些人？
  这一点必须收敛和明确，如果某一功能的预期用户太过复杂，说明这一部分的设计是有问题，需要拆分。

• For（价值、目的） : 该功能的实现目的是什么

• Do （过程、行为） : 该部分涉及真实进行的场景

3.故事点
这一部分，涉及到分发任务，最好由开发人员回答，要引导（压榨）开发人员，发掘故事点。

• 全员预估、发现坑、技术教练指导
• 和PO 沟通实施先后顺序
• 用户故事优先级别

每日站会

严格按照Story 的故事点来汇报。Master 需要汇报整个项目进度。

• 昨天做了什么
• 今天准备做什么
• 有什么问题
  要求每个人发言简洁，明确。如果有细节的问题，注意打断然后私下讨论。确保每个人都能集中其工作在某个点上。

show case

As 对象 必须在场
ST 成员各自演示功能

迭代总结会议

• 计划投入、实际投入、延时
• 把大家的想法总结

• 大家反馈完成度
• 谁做的最好？谁有待改进？ why？ 做个记录，有利于成员管理和考核，对好的予以表扬。不足的设法改进。Master 也需要借此对团队成员有一个考量。
• 每个人提建议。
  1.不足的可以改进的地方（注意分类，在逻辑层次需要在一个层面，例如 外部问题，团队管理问题，个人问题，有的问题可以及时和甲方沟通）
  2.好的，可以延续的地方。（如重构）

杂七杂八

• 第一次接触团队，大家互相不熟悉，第一个迭代（冲刺）可以制定工作量70% 这一部分需要和甲方商榷。
• 作为Master 要保持自身的机动性。
• 每个故事点，要尽可能的发掘开发人员的思路。
• 用户故事，或者故事点过大时，要及时切分。
• 纸上得来终觉浅

Reference

http://blog.csdn.net/uxyheaven/article/details/49618097