Team - 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
行动是绝望的解药!
欢迎转载和引用,但请在明显处保留原文链接和原作者信息!
本博客内容多为个人工作与学习的记录,少数内容来自于网络并略有修改,已尽力标明原文链接和转载说明。如有冒犯,即刻删除!
以所舍,求所得,有所获,方所成。