.NET 云原生架构师训练营（模块二 基础巩固 Scrum 团队）--学习笔记

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 回顾会
• 回到第三步，开启下一轮

本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。

欢迎转载、使用、重新发布，但务必保留文章署名 郑子铭 （包含链接： http://www.cnblogs.com/MingsonZheng/ ），不得用于商业目的，基于本文修改后的作品务必以相同的许可发布。

如有任何疑问，请与我联系 (MingsonZheng@outlook.com) 。