Scrum敏捷开发

Scrum敏捷开发

敏捷Agile开发

• 敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。它不是一门技术，它是一种软件开发的流程。它包含一批最佳实践，比如看板、Scrum、XP极限编程。TDD。BDD。CI，CD等。
• 敏捷宣言
  • 个体和互动高于流程和工具(Individuals and interactions over processes and tools)
  • 可工作的软件高于详尽的文档(Working software over comprehensive documentation)
  • 客户合作高于合同谈判(Customer collaboration over contract negotiation)
  • 响应变化高于遵循计划(Responding to change over following a plan)
• 敏捷5大价值观(工程师文化)
  • 承诺 Commitment - 愿意对目标做出承诺
  • 专注 Focus – 全身心都用到你承诺的工作上去
  • 开放 Openness – 团队内所有信息对所有人开放
  • 尊重 Respect – 每个人都有他独特的价值和经验
  • 勇气 Courage – 勇于承诺，履行承诺，敢于说不

Scrum敏捷开发

Scrum是一个轻量级的敏捷开发框架。强调自管理、快速反应、快速迭代、价值驱动。 它是一种能积极调动项目开发人员自主性的同时兼顾项目的透明性和效率的管理模式。

Scrum的核心要点（“3355”）:

• 3个角色: Product Owner, Scrum Master, Scrum Team
• 3个工件: Product Backlog, Sprint Backlog, 可交付产品(增量)
• 5个事件: 故事梳理会, Sprint计划会, 每日站会, Sprint评审, Sprint回顾
• 5个价值观: 承诺, 专注, 开放, 尊重, 勇气

我们的领悟 - 小步快跑

• 小团队。小会议。小故事。小项目
• 快速启动。快速验证。快速交付。快速响应变化 

Scrum中的名词解释

• Sprint - 就是一个迭代，也可以叫冲刺
• Product Owner(PO) - 产品负责人
• Scrum Master(SM) - 敏捷教练，就是团队组长
• Scrum Team - 整个scrum团队
• 利益相关方 - 包括终端用户/业务主管/产品支持人员/投资者/外部审计人员/相关项目人员等
• Product Backlog - 就是产品待办事项的总称，可以理解为一个有排序的todo list，具体分为epic/story/task等
• Epic - 史诗，也就是大的功能点
• Story - 用户故事，也就是小的功能点
• Potentially Shippable Product - 潜在可交付产品
• Sprint Planning Meeting - Sprint计划会议
• Daily Scrum Meeting - 每日站会
• Sprint Review - Sprint评审
• Sprint Retrospective - Sprint回顾
• Definition of Done(DoD) - 对story"完成"状态的具体定义
• AC - Acceptance Criteria, 验收标准，用于定义Story的细节
• MVP - 最小价值产品

Scrum准备

搭建Scrum团队

• Scrum团队由跨职能人员搭配组成，以便完成完整的产品功能
• Scrum Team = Product Owner + Scrum Master + Developers（设计 + 程序员 + 测试等)
• 实操指引
  • 一般由产品经理担任PO，由开发leader担任SM
  • Scrum Team的合适的规模是3~9人
  • 在大型项目中，我们可以按照产品功能模块拆分成多个Scrum Team，然后再通过Scrum of Scrums的方式来协调整个项目
  • 在某些复杂的项目中，还可能需要考虑架构师/行业专家/集成商等角色

Scrum TeamProduct OwnerDesignerUIScrum MasterProgrammerTester

Product Owner(PO)的主要职责

1. 把握产品方向，制订产品的roadmap和发版计划
2. 编写PRD文档，编写用户故事(story)
3. 梳理产品backlog，定义优先级
4. 主持发版工作
5. 负责与客户沟通

Scrum Master(SM)的主要职责

1. 负责团队管理工作，如组织每日站会/Sprint计划/Sprint评审等
2. 辅助PO梳理backlog
3. 协调解决团队障碍，帮助团队成果的交付
4. 沟通团队内外事项，保护团队成员免受外部干扰

确定完成标准(DoD)

• 所谓DoD就是对story完成的具体定义，并且是团队共识
• 示例
  • ✔ 代码完成提交
  • ✔ 代码通过单元测试
  • ✔ 代码通过评审
  • ✔ 功能/非功能测试通过

Scrum核心活动

在Scrum中，有以下活动(如图)是必须有的，它们按固定的节奏在持续不断的Sprint周期中进行。

Sprint	提前半个SprintSprint计划会每日站会Sprint评审Sprint回顾Next Sprint首次故事梳理会(PRD)Next Sprint故事梳理会(若干次)

Sprint

Sprint可以叫做迭代或者冲刺，它就是一个固定的时间周期，具有如下特点：

• 固定周期，2~4周
• 有明确目标(Sprint结束时候交付什么)
• 足够稳定，即保证周期和交付目标不变化
• Sprint是连续的、持续的

实操指引：

• Sprint不是发版周期，它比发版周期小，一个发版周期通常包含多个Sprint
• 固定周期意味着开始日期和结束日期确定好之后，一天都不要改变
• 每个Sprint，团队要留一定的buffer时间(如20%)，便于应对额外工作
• 当确实需要对当前进行中Sprint加入额外工作时，
  • 首先需要有协商（PO，SM，及相关developer）
  • 根据优先级，加入新的Story，同时移除Sprint中等量低优先级的Story
  • 【避免】如果调整后,原来Sprint目标已经无法达成，则终止当前Sprint后重新开始新的Sprint

故事梳理会 Backlog Grooming Meeting

	故事梳理会(Backlog Grooming Meeting)
会议目的	以客户为中心对特性列表进行梳理 需求评审 特性拆分，如把大的特性拆分成足够小的story 分析定义story验收条件 重新预估 重排优先级
输入输出	输入输出Product backlogPRD文档故事梳理会新的backlog列表- 拆分细化- 或调整优先级- 或更新为ready4dev状态
会议内容	会议可以包括下面一项或者多项内容： 需求评审：PO讲解PRD，团队反馈，PO进行澄清 PO分拆特性到story，团队给反馈 PO讲解story详细要求，团队给反馈 PO调整story优先级，团队给反馈 Scrum Master或技术骨干确认story进入ready4dev状态 Scrum Master或技术骨干给出story初步预估工时
会议组织	PO负责召集会议 Scrum Master必选参会 主题相关Scrum Team成员参加(PRD文档初次评审应邀请整个Scrum Team参加) 其他理解需求并能给团队帮助的人参加
会议时间	会议时长：1小时 会议频率：多次，下个Sprint相关的至少要提前半个Sprint周开始
实操指引	多次召开，分主题召开，避免冗长大会 PRD文档包含大的需求逻辑，story层级的细节体现在story卡片中 最终的story是workable的，即team能在story卡片上获取所有必要信息

计划会 Sprint Planning Meeting

	计划会(Sprint planning meeting)
会议目的	为sprint做准备，解答两个问题 做什么(做哪些story) 怎么做(认领/细化/预估工时)
输入输出	输入输出Product backlog1.排好优先级2.Ready4dev计划会Sprint backlog- 已细化- 已认领- 已预估
会议内容	会议可以分下面三个阶段： PO给team介绍他期望在sprint中实现的stories，并做需求澄清 team认领story，并分小组进行细化 Team和PO确认本sprint要完成的stories
会议组织	Scrum Master负责召集会议 Scrum Team参加会议 PO在会议第一和第三阶段必须参加，第二阶段可选参加但要随时能被找到
会议时间	会议时长：1小时 会议频率：Sprint启动前召开
实操指引	Scrum Master要设置周期会议提醒 PO在会前要做足准备，要提前通过多轮故事会，有了一批进入Ready4dev状态的stories(即包含开发需要的一切细节，包括原型/UI/UX) 团队进行认领而不是分配 story的细化和预估要包含测试工作，是开发和测试一起给出承诺 team要留缓冲时间如20%，根据历史数据调整 team的capacity同木桶理论以最短板做出承诺 最后阶段确认sprint可完成内容以team的决定为主，而不是PO的意愿 有余力的同学要认领额外的story，如果这些story能完成则交付，否则移至下个Sprint

每日站会 Daily Scrum Meeting

	每日站会(Daily scrum meeting)
会议目的	同步每天的进展 及时排除障碍
输入输出	输入输出无每日站会1.更新Sprint看板2.障碍跟进会
会议内容	每人更新如下信息： 上次会后完成了什么 下次会前做什么 有什么障碍
会议组织	Scrum Master负责召集会议 Scrum Team参加会议
会议时间	会议时长：每人3分钟以内，总时长在15分钟以内 会议频率：Sprint内每天
实操指引	要固定时间和地点，一般建议在每天头尾时间段,Scrum Master要设置周期会议提醒 准时开始，不浪费时间 面对面，所有参会人专心站会 不在站会上解决障碍，后续开跟进会来解决

评审会 Sprint Review Meeting

	评审会(Sprint Review Meeting)
会议目的	检视Sprint成果 看到最新产品状态，了解当前产品处于什么位置 展示新的重要功能，获取正面反馈，增强团队成就感和自信心
输入输出	输入输出可演示的产品评审会关闭的Sprint(移出未完事项)
会议内容	Scrum Team汇报Sprint承诺目标和实际完成情况 Scrum Team演示，PO和利益相关方给出反馈和建议 PO通报当前市场格局或需要加强开发的客户关注事项
会议组织	Scrum Master负责召集会议 Scrum Team必选参会 PO可邀请其他利益相关方参会(如管理层/客户)
会议时间	会议时长：1小时 会议频率：Sprint结束当天
实操指引	按期结束Sprint，Scrum Master要设置周期会议提醒 由Story实现人员来演示说明，而不是PO

回顾会 Sprint Retrospective Meeting

	回顾会(Sprint Retrospective Meeting)
会议目的	审视流程和团队行为，强化好的实践，对不足之处进行优化和改进
输入输出	输入输出无回顾会TOP3改进措施
会议内容	回顾上次会议后改进措施实行情况 每人对最近一个Sprint中提出2~3条反馈 有哪些事情做的好 哪些事情做的不好 整理反馈: 做的好的，强化并继续保持 做的不好的，选择top3，讨论出team一致认同的解决方案
会议组织	Scrum Master负责召集会议 Scrum Team必选参会
会议时间	会议时长：1小时 会议频率：Sprint结束当天
实操指引	对于应用scrum初期团队，回顾会议是保证流程持续改进的必要手段 是Scrum Team内部会议, 一般不邀请其他人员 会议基调： 就事论事，不针对个人 多说我/我们，少说你/你们 相信每个人在当时环境下已经做到最好 对做的好的方面也要收集并强化 可以安排在Sprint评审会后一起进行

Scrum中的Backlog

Backlog就是拆解后的产品需求，按粒度会有不同类型，按流程会有不同状态。

Scrum中的工具和可视化

使用工具可以帮助提高Scrum中各项工作的效率，使用工具可视化更可以提高Scrum过程的透明度，直观清晰的了解进度和问题。比如看板，燃尽图，燃耗图等。

Scrum衡量指标

为评价Scrum团队工作的成效，我们通过一些衡量指标来进行表示，其数据采集自于Scrum活动中生成的内容。

Scrum团队的一天

1. 10点_站会, Scrum team
2. 10点15_有时候_障碍跟进会, Scrum Master, 相关开发人员
3. 14点_有时候_故事梳理会for_next_sprint, PO, Scrum Master, 相关开发人员
4. 18点45_提交代码, Scrum team
5. 19点_更新卡片, Scrum team