Go to my github

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

课程链接

https://appsqsyiqlk5791.h5.xiaoeknow.com/v1/course/video/v_5f39bdb8e4b01187873136cf?type=2

知识共享许可协议

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

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

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

posted @ 2021-01-19 23:24  MingsonZheng  阅读(142)  评论(0编辑  收藏  举报