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