# 模块二 基础巩固 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 回顾会
* 回到第三步，开启下一轮