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) 。

版权声明：本文为MingsonZheng原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://www.cnblogs.com/MingsonZheng/p/14300665.html