冲刺阶段 - 项目管理知识点总结（四）-阿里云开发者社区

4. 敏捷专题

4.1 什么是敏捷

敏捷（适应型生命周期）是指采用迭代或增量的方式开发项目产品，在需求不明确的情况下，主动快速的响应变化的一种开发方式

4.2 敏捷开发模型

4.3 敏捷方法VS预测生命周期

4.4 敏捷四大价值观

个体和交互 胜过流程和工具
可工作的软件 胜过面面俱到的文档
客户合作 胜过合同谈判
响应变化 胜过遵循计划

价值1：个体和交互胜于流程和工具

强调以人为本，强调人与人之间的沟通与协作
重视个体潜能的激发和团队的高效协作作
流程和工具重要，但是无法替代有能力的个体和高效的互动

价值2：可工作的软件胜过面面俱到的文档

目标导向，目标就是：可工作的软件
做必要的文档，以传递必要的信息
以小步增量的方式构建产品，做一些设计、分析然后开发、测试以验证设计

价值3：客户合作胜于合同谈判

客户为先，但客户不是上帝，客户更不是敌人
要超越谈判并尝试提升与客户的合作
建立以合作为基础的关系，而不是公司正式的接口

价值4：响应变化胜于遵循计划

拥抱变更、变更是创新的来源
变更创造价值、为客户或产品带来价值
欢迎需求变化、哪怕是在项目后期

4.4 敏捷的12条原则

原则1：我们的首要任务是通过早期和持续交付有价值的软件来满足客户

• 要点：客户满意、有价值、持续交付

原则2：欢迎变更，即使到了开发后期，利用需求变更为客户获得竞争优势

• 要点：持续拥抱变更、保持灵活性以随时适应变化

原则3：经常交付可工作的软件，几周到几个月不等，时间间隔越短越好

• 要点：经常交付、尽早交付、越快越好（1-4周）、消除“惊讶”

原则4：业务人员和开发人员必须自始至终共同完成项目的日常工作

• 要点：业务与开发全程合作、团队与客户需要彼此理解

原则5：由被激励的个体去完成项目。给予需要的支持和环境，相信他们能够完成工作

• 要点：激励、支持，个体比流程更重要

原则6：面对面地交谈是开发团队中最有效的信息交流方式

• 要点：交互式沟通、文档代替不了交谈

原则7：可工作软件是项目进展状况的主要度量

• 要点：度量标准、目标导向、可工作的软件

原则8：提倡可持续的开发。发起人、开发人员和用户应该始终保持步调稳定

• 要点：可持续开发、稳定的速度、不透支明天的精力

原则9：对卓越技术和良好设计的持续关注有助于提高项目的敏捷性

• 要点：保持设计的清晰、高效和变更的灵活性、重构以加强根基

原则10：追求极简化，尽量减少不必要的工作

• 要点：轻文档，轻流程，重产出，重目标（MVP）

原则11：最好的架构、需求和设计都源于自组织的团队

• 要点：共同的目标，共同承担责任，共同解决问题

原则12：团队定期反映如何提高工作效率，然后相应地调整其行为

• 要点：不断学习、持续改进、反思与调整、回顾会议

4.5 敏捷中的3345

3个角色：

产品负责人（Product Owner）
敏捷教练（Scrum Master）
团队（ Scrum Team）

3个工件：

产品待办项（Product Backlog）
迭代功能开发列表（Sprint Backlog）
燃尽图（Burn-down Chart)

4个仪式：

迭代计划会议（Sprint Planning Meeting）
每日站会（Daily Meeting）
迭代评审会议（Sprint Review Meeting）
迭代回顾会议（Sprint Retrospective Meeting）

5个价值观：

承诺 – 愿意对目标做出承诺，并信守承诺
专注 – 全身心的投入到你承诺的工作
开放 – SCRUM中一切信息对所有人开放，让问题无所隐藏
尊重 – 每个人都有独特的背景和经验，尊重他人，信任他人
勇气 – 有勇气做出承诺，履行承诺，敢于拒绝，并接受尊重

4.5.1 3个角色

产品负责人 (Product Owner)

Product Owner的核心工作对团队对外交付的价值负责，是PB列表的唯一责任人。

• 清晰的表述产品待办列表项、确保团队成员清晰理解

• 定义需求及需求优先级、验收标准、确保需求的价值

• 定义产品发布内容与日期

• 客户不能直接对PB进行排序，只能提供输入

• PO可以直接拒绝团队的可交付成果

• 如遇到干系人要增加需求，先由PO来判断价值，不能由团队直接决定做不做

敏捷教练(Scrum Master)

Scrum Master的核心工作是帮助团队遵循Scrum 框架，扫除障碍，提供帮助与支持。

• 清除障碍，仆人式的领导

• 团队出现问题与冲突，先团队自组织的解决

• 团队士气低落，SM要去激励团队，此时无法靠自组织

• 保护团队免受外界打扰

• 客户、高层等对敏捷文化、原则误解，需要SM来进行宣导，告知价值的正确性

团队(Scrum Team)

Scrum team 对交付成果负责，在每个 Sprint 结束时交付潜在可发布且“完成”的产品增量。

• 自组织团队，不认可任何头衔，特征符合塔克曼团队发展阶梯模型

• 团队首先要敏捷（5-9人），没有子团队、人多建议分解

• 团队自己决定做什么、做估算，不是由PO或者SM来进行分配或估算

• 质量保证的工作是由团队来做，不是靠PO频繁的检查

• 当团队发现一个好方法的时候，SM引导，然后由团队来决定是否采纳

• 如果团队士气低下，则不能依靠自组织，需要SM的介入

• 拥有解决全部问题的所有技能，SM要培养团队跨职能技能

4.5.2 3个工件

产品待办事项 (Product Backlog)

Product Backlog即产品视角的完整需求清单。

• PO是唯一负责人，包括增删及优先级。

• 用户故事是其中一种最佳实践。

• 每项需求都需要描述其外部价值，并用用户语言加以描述。

• 遇到新需求都要放到PB表中重新排序。

Sprint 待办事项 (Sprint Backlog)

Sprint Backlog即此次迭代周期内规划要完成的内容。

• 来源于Product Backlog。

• 由团队评估和选择Product Backlog中哪些放入Sprint Backlog。

• 团队需要一起定义“完成”的标准。

• 每个团队成员都可以更改Sprint Backlog，是团队的资产。

燃尽图（ Burn-down Chart)

Burn down Chart 显示了Sprint中累积剩余的工作量，是一个反映工作量完成状况的趋势图。

• Sprint开始的时候，团队会定义当前迭代的全部任务。

• 每天结束时，剩余任务会减少。

• 最后一天结束，累积剩余工作是为0，迭代结束。

燃起图（ Burn-up Chart)

Burn up Chart展现项目时间与已完成的工作之间的关系。

• 燃起图有助于展示团队的工作成果

• 可以区分不同角色展现工作量的完成状况。

• 可以度量项目的迭代速率和工作效率。

4.5.3 4个仪式

冲刺（Sprint ）

冲刺或迭代是一个特殊的事件，或者说其一个容器事件，后续四个事件（仪式）包含在其中。

• 固定周期（2-4周），固定时间开始，固定时间结束

• 固定时间盒，如果有需求没做完的也不能延长时间交付

• 按优先级做事，每次交付的是有价值的产品

• 如果当前有一些工作无法完成，尽力按照高优先级的事项先做，等到回顾会再去梳理问的原因，在下一个迭代进行调整。

Sprint规划会 (Sprint Planning Meeting) 时间盒：2小时/周

Sprint规划会的核心议题是定义下一次冲刺要实现的目标和范围。

• 确定 Sprint的目标、工作方法、工作量。

• 对产品backlog 中 item 进行估算，以确定是否放入迭代周期。

• 对于需求不清楚的 item，请 Product Owner 说明。

• 输入是 Product backlog，输出是 Sprint backlog。

• Part1：需要做什么，产品负责人向开发团队介绍排好序的产品待办事项，由整个Scrum团队共同理解这些工作（PO\SM\TEAM）

• Part2：决定如何做，团队成员根据PB，确定产品增量，进行任务分解，并形成Sprint backlog(SM\TEAM)

每日站会 (Sprint Daily Standup) 15分钟/日

站会的目标是促进信息在团队内共享与透明。