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云原生架构师训练营讲什么，怎么讲，讲多久

欢迎各位读者加入微信群一起学习交流，

在公众号后台回复“加群”即可~~