Sprint Planning 冲刺计划会议简介
Sprint Planning （冲刺计划会议），又叫规划会议。此会议通过 Scrum 团队的集体沟通讨论，确定接下来的 Sprint 中要完成的待开发项，把它们组成一个 Sprint Backlog。这些待开发项都是从 Product Backlog 中挑选的。
- Product Backlog：产品功能特性列表
- Sprint Backlog：迭代任务列表，可以细化为更小的开发任务 Task
可以规划一个 Sprint Backlog，也可以规划多个，根据产品规划路线图、产品开发进度、团队任务量等等多种因素来确定。
Sprint计划会议目的
- 设定目标：设定 Sprint 迭代的计划、目标和期望的成果。
- 理解需求：对于待开发的需求，需要团队成员的理解是一致的。
- 估算工作量：对 Sprint Backlog 中待开发项进行估算，有的待开发项需进一步细化然后估算。最后估算整个 Sprint 的工作量。
- 承诺：团队对完成 Sprint（冲刺）目标做出承诺，并达成一致。
Sprint计划会议内容
1、Sprint 目标，确定 Sprint Goal
产品负责人提议如何在这次的 Sprint 中增加产品的价值。然后，与 Scrum 团队共同讨论并制定本次冲刺的目标 - Sprint Goal，最后确定下目标。
2、待办项选择，这次 Sprint 迭代要完成哪些待开发项
Scrum 开发团队和产品负责人一起讨论，按优先级顺序从 Product Backlog 中选取待开发项，放入到当前 Sprint 中，组成 Sprint Backlog。
在此过程中，可以对 Sprint Backlog 中的待开发项进一步细化、拆解，分解为更小的开发 Task，这样容易估算工作量，也容易完成开发任务。
3、任务拆分，估算工作量，制定开发计划，分配开发任务，领取任务
可以将一些待开发项拆分为更小的开发项。比如把大的 Epic 拆分为 Feature（特性），在把 Feature 拆分为更具体更小的 User Story（用户故事）。比如把用户故事拆分为程序员的开发任务 Task，便于开发人员开发和估算。
待开发项或 更小的开发 Task，对它们的工作量进行估算，通常以天或小时为单位。
确定每个待开发任务的执行顺序、所需资源和依赖关系。
澄清待开发项，确保团队成员对它的理解是一致的。
团队成员根据自己的技能和兴趣领取工作 Task。
制定开发计划，可以用甘特图、燃起图来跟踪项目完成情况。
一般一个 Sprint 的迭代开发周期是 1 - 4 周。
4、定义验收标准
定义验收标准，确保团队成员对 “完成” 有共同的理解。
- DoD - Definition of Done ，完成的定义
- Acceptance Criteria，验收标准
Sprint计划会议注意事项
- 明确会议议程：在开始会议前，明确会议的议程和目标，并通知所有参与者分享。
- 时间控制：对一个为期 2 周的 Sprint，会议时间通常持续 2 - 4 个小时，以此类推。
- 利益相关者参与：产品负责人、Scrum Master、开发团队，以及邀请必要的与此次会议有关的人员，也要注意限制参与人数。因为人数越多，一是浪费无关人员时间，二是讨论事情复杂增大。
- 透明沟通：要确保所有的沟通都是开发和透明的。
- 避免过度承诺：团队应该避免选择过多的开发任务，而无法完成冲刺目标。
- 冲刺计划灵活性：冲刺计划灵活性，以适应 Sprint 中需求的变更。
开发项与用户故事的拆分
大开发项的拆分
对 Sprint 中需求开发项的拆分和细化。
比如从 Product Backlog 中挑选的大的 Epic（史诗），拆分为多个具体的 Feature（特性），特性进一步拆分为更小、更具体的 User Story（用户故事）。每个用户故事都是站在用户角度的最小可交付的工作项。
在把用户故拆分为开发任务（Task）。
- Epic：史诗，更大更高层次的用户故事。可以是多个功能集合，对业务产生显著价值。
- Feature：特性，可以看着是关联用户故事的集合，组合提供某种业务价值。
- User Story：用户故事，站在用户角度对功能的描述，给用户带来什么价值。
用户故事拆分
用户故事拆分方法有哪些呢，下面来看有哪些方法。
1、基于流程步骤拆分
按照用户完成一个业务流程步骤来拆分用户故事。梳理出清晰的用户操作路径。
比如：常见的 "用户下单购买商品" 的用户故事，可以拆分为
- 用户浏览商品列表
- 用户查看商品详情
- 将商品加入购物车
- 购物车商品结算
- 选择支付方式完成支付
等更小的用户故事。这里每一个子故事代表了“下单购买商品”流程中的一个一个关键步骤，开发人员就可以根据这些子故事来进行系统功能的开发。
2、基于用户角色拆分
当一个系统涉及多个角色和系统交互时，可以根据不同的角色来拆分用户故事。这样可以明确角色在系统中的功能需求和角色权限。
比如：比如 ERP 系统的开发，在这个系统中有管理员、销售人员和仓库管理人员等不同的角色。对于“库存管理”这个用户故事，可以拆分为
- 管理员设置库存预警阙值
- 销售人员查询库存数量以确定销售策略
- 仓库管理人员，根据收货单更新库存数量
等这些子用户故事，开发人员可以根据每个角色的需求进行功能开发。
3、基于功能特性拆分
按照开发的系统提供的功能特性来进行拆分。这种方法有助于聚焦系统具体功能模块。
比如：在社交媒体软件上“用户发布内容”的用户故事，可以拆分为
- 用户发布文字内容
- 用户发布图片内容
- 用户发布视频内容
- 编辑已发布的内容
等子用户故事，开发人员可以根据每个功能特性来进行开发。
比如“发布图片内容”的子故事，支持哪些图片格式？这就是业务规则。
4、其它一些拆分方法
其它一些方法有哪些：
- 基于规则和约束拆分
- 基于数据边界
- 基于功能依赖顺序
开发任务的拆分
细化研发工程师开发的任务（Task），比如一个需求开发，把它所有的开发任务都列出来：
- 用户文档、页面设计、前端、功能的编码、测试、Bug修复、测试验收、部署等。
比如需求功能的编码，有哪些步骤？
有多少个功能需要开发？对应程序中的功能模块有哪些？程序编码设计？功能模块里的类有哪些？需要提前设计吗？等等，程序开发人员都可以进一步细化开发任务（Task）。
如果你使用 CICD Pipeline 集成开发测试交付流水线，那么需要写的测试脚本就有很多。
总之，统统列出来，便于估算开发时长。
说明：不仅有对用户故事的拆分，拆分为更小功能，还有对开发任务的拆分。
