DevOps - Scrum

1 - DevOps与敏捷开发

在采用敏捷开发的情况下，所有成员都对服务和产品负责，理解彼此的业务，符合DevOps的组织和文化。
以商业需求为核心，在较短期间内确定开发方针，并持续进行改善，从而逐步推进开发。
以团队整体的输出和业务的成败为共同目标、全员参与、信息共享、持续改进（建议与改善）。

2 - 敏捷开发的推进方式

迭代

• 以1~4周为单位进行短期的服务开发
• 计划plan时，所有团队成员都知道团队的任务，共同讨论出团队的产出成果
• 在迭代中，所有团队成员评审和讨论实际的开发成果，决定发布内容
• 回顾retrospective时，所有相关团队成员回顾并讨论Good、Bad、ActionPoint等

用户故事

• 以文档的形式记录想要实现的功能
• 前身是记录比较粗略的关于需求的史诗故事（epic）
• 通过拆分史诗故事中没有细化的需求，创建用户故事，进而根据用户故事实施开发工作

总的来说，根据用户故事的开发内容确定迭代周期，指定该周期的的工作计划并着手开发，然后所有成员对开发成果进行回顾和评审，之后再开始下一轮迭代。

3 - Scrum团队

Scrum团队包括3个角色，产品负责人，开发团队和Scrum Master。

产品负责人

• 负责是Scrum团队开发的产品价值最大化
• 确定待办事项列表（product backlog）的优先级，整理出最低限度的功能，最大限度地提高产品价值

开发团队

• 负责开发产品需要的功能
• 3~9人组成，沟通成本低，团队自我管理，指定具体的工作计划并进行管理，对开发的功能负责
• 包含各领域的专业人员，没有部门之分，紧密合作

Scrum Master

• Scrum团队的管家，负责对Scrum团队进行优化，在必要时进行改善和教育工作
• 对产品负责人提供支援，排除阻碍开发团队工作进展的因素

4 - Scrum开发流程
发布计划---》冲刺计划---》冲刺---》每日站立会议---》冲刺评审---》冲刺回顾

发布计划

• 产品负责人根据产品待办事项列表确定各功能的优先级，并确定需要多少时间来实现
• 产品待办事项列表根据业务状况、用户变化和开发团队的反馈等随时进行更新
• 发布计划是项目的路线图，在每个冲刺中都被重新评审

冲刺计划

• 将产品待办事项列表中的功能开发映射到实际冲刺中的一个阶段
• 2~4周
• 制作功能和负责人一一对应的冲刺待办事项列表（sprint backlog）
• 指定量化的评估项目，便于回顾

冲刺

• 实际开发，交付成果
• 在此期间，开发内容原则上不会发生变更

每日站立会议

• 每天召开简短会议（15~30分钟），团队成员简要汇报：昨天做了什么、今天要做什么、是否出现了阻碍物
• 阻碍物：阻碍正常工作进展的因素
• 目的在于及时确认并调整开发方向

冲刺评审

• 对交付成果物（直接展示可运行的服务）进行评审
• 必须使用按照冲刺计划完成的交付成果物来演示，不应只使用图片或者文档来说明
• 利益相关者也应广泛参与进来，确认和开发团队之间的沟通是否存在问题

冲刺回顾

• 在团队全员对刚完成的冲刺还有印象、对出现的问题还比较重视时进行回顾
• 总结Good、Bad、ActionPoint等

5 - 参考信息

• Scrum官方权威指南：http://www.scrumcn.com/agile/scrum_guide.html
• Scrum Knowledge Library：http://www.scrumcn.com/agile/scrum-knowledge-library.html