2.7.3 Scrum 团队
- 理想的环境
- 团队章程
- 如何组建 Scrum 团队
- 产品待办事项列表
- 用户故事
- 敏捷开发流程
理想的环境
- 5-9人
- 100%
- 跨职能
- 在一起
- 自组织
自组织
- 目标
- 授权
- 沟通
- 可视化
- 辅导
- 奖励
要我做 => 我想做，我要做，我要做好
团队章程
- 团队价值观：速度与工作时间
- 工作协议：例如：“就绪”定义，“完成”定义
- 基础规则：例如：会议规则
- 团队规范：迟到、冲突
- 坦诚、高效沟通
- 包容
- 相互帮助
- 简洁、反馈、尊重
如何组建 Scrum 团队
- 先确定 scrum master 人选，再由 SM 组建其他团队成员
- SM 应该由熟悉 scrum 流程和敏捷原理的人担当
- 根据项目的需要决定团队中要拥有哪些技能
- 团队中没有 team lead 这样的强势领导
- 选取能力较强的人作为团队成员
- 崇尚全栈工程师
产品待办事项列表
用户故事
- 三个要素
- 3C 原则
- 拆分原则
- 拆分关键点
三个要素
- 角色：站在用户角度描述需求的一种方式，谁要使用这个功能
- 活动：从操作场景描述，需要完成什么样的功能
- 商业价值：为什么要这个功能，带来什么样的价值
典型描述句式：中文：作为一个 XXX <客户角色>，我需要 XXX <功能>，带来 XXX 好处<商业价值>
英文：As a, I want to , so that
3C 原则
- 卡片（Card）：卡片上可能会写上故事的简短描述，规则和完成标准
- 交谈（Conversation）：用户故事背后的细节来源于和客户或产品负责人的交流沟通
- 确认（Confirmation）：通过验收测试确认用户故事被正确完成
拆分原则
- I：Independent，可独立交付给客户
- N：Negotiable，便于与客户交流
- V：Valuable，对客户有价值
- E：Estimate，能估计出工作量
- S：Small，分解到最底层的用户故事粒度尽量小，至少在一个迭代中能完成
- T：Testable，可测试
拆分关键点
- 周期控制在 1·5 个工作日，一般在 1 个工作日
- 识别关键路径上的 Story，并做风险管理，避免影响项目进度
- Story 下 Task 分解由模块负责人组织开发一起分解并做工作量评估
- 每个 Story 要有负责人，一般由工作量较多的人负责，可以由研发认领
敏捷开发流程
- PO 和开发团队对产品业务目标达成共识
- PO 负责建立并维护产品待办需求列表，并排优先级
- PO 在每轮迭代前，先 review 需求列表，并筛选高优先级需求进入本轮迭代开发内
- 开发团队细化、拆分本轮迭代需求，并按照需求优先级，依次在本轮迭代内完成
- 开发团队每日站会同步更新开发进展，并持续集成，使开发任务进展透明可见。站会时团队成员应自个解释进展，而非 SM 代替解释
- PO 对每轮迭代（比如：2周）交付的可工作的软件进行现场验收和反馈
- Sprint 回顾会
- 回到第三步，开启下一轮
课程链接
.NET云原生架构师训练营讲什么，怎么讲，讲多久
