111 lines
7.6 KiB
Markdown
111 lines
7.6 KiB
Markdown
### Scrum 快速入门教程
|
||
|
||
#### 1. Scrum 简介
|
||
Scrum 是一种敏捷的项目管理和产品开发框架，用于帮助团队以迭代和增量的方式交付复杂的产品。它强调跨功能团队的协作、透明和检查。
|
||
|
||
Scrum是一个用于开发和维护复杂产品的框架，是一个增量的、迭代的开发过程，目的是让开发人员像打橄榄球一样迅猛并充满激情，通过团队合作，提高工作效率。通过团队间的有效交互，为企业创造价值。
|
||
|
||
Scrum的开发流程:
|
||
|
||
|
||
#### 2. Scrum 的三个角色
|
||
- **产品负责人（Product Owner）**：负责定义产品愿景、管理产品待办列表（Product Backlog）并确保团队理解待办事项。
|
||
- **Scrum Master**：负责确保Scrum框架被正确理解和实施，帮助团队成员解决阻碍进度的问题。
|
||
- **开发团队（Development Team）**：通常跨功能，包括所有负责交付产品待办列表项的团队成员。
|
||
|
||
#### 3. Scrum 的五个事件
|
||
- **Sprint**：一个时间箱，Scrum团队在此期间内完成一项“完成”的工作。
|
||
- **Sprint Planning**：开始新的Sprint，确定接下来要完成的工作。
|
||
- **Daily Scrum (Stand-up)**：团队成员每天进行短暂的同步会议。
|
||
- **Sprint Review**：Sprint结束时，团队展示他们完成的工作。
|
||
- **Sprint Retrospective**：Sprint结束后，团队回顾并讨论如何改进下一个Sprint。
|
||
|
||
#### 3. 五个会议
|
||
|
||
Scrum 整个开发过程分为五个会议:
|
||
|
||
- **待办事项整理会议（Backlog Grooming Meeting）**
|
||
|
||
迭代计划会议开始之前3天召开，Product Owner与Scrum Master必须参加，关键开发者或架构师需要参加；时间控制在30分钟到1小时。
|
||
|
||
由Product Owner将一批希望团队在下次迭代时实现的用户故事，按照实现顺序描述给在场的团队成员，Scrum Master与在场成员分析用户故事，明确指出团队认为需求不明确的地方，Product Owner现场记录，会后补全，Scrum Master与架构师，还有在场成员分析用户故事需要包含哪些技术任务，Scrum Master先把子任务建立，方便迭代计划会议的时候团队可以更准确地预估任务故事点。
|
||
|
||
会议结束时，Product Owner确保在迭代计划会议开始之前团队提出的问题都能被解决，会议重点如果团队发现需要加强或是完善的地方，Product Owner还有两到三天的时间可以补强，而不是浪费迭代计划会议的时间去做这件事情。
|
||
|
||
- **迭代计划会议（Sprint Planning Meeting）**
|
||
|
||
产品负责人建立产品功能列表（Product Backlog）。产品功能列表是一组条目化需求，它必须从客户价值角度描述，并按优先级排序。
|
||
|
||
Scrum Master召集相关人员召开迭代计划会，迭代计划会在每个迭代第一天召开，目的是选择本次迭代的Backlog和估算本次迭代的工作量。
|
||
|
||
产品负责人逐条讲解最重要的产品功能，开发团队共同估算Backlog所需工作量，直到本迭代工作量达到饱和。产品负责人参与讨论并回答和需求相关的问题，但不干扰估算结果。队员认领任务（或由组长协商分发），独立或与别人一起完成任务；会议时间控制在1-2小时内。
|
||
|
||
- **每日站会（Standup Meeting）**
|
||
|
||
团队内部利用每日立会来沟通进度，15分钟结束，开发团队利用燃尽图来展示整体进度；如无特殊原因，迭代期内无变更，在每日站会上团队成员需要回答以下3个问题：
|
||
|
||
昨天你做了什么?
|
||
今天你将要做什么?
|
||
你有需要帮助的地方吗?
|
||
这些都是团队成员的彼此承诺。
|
||
|
||
- **评审会（Retrospective Meeting）**
|
||
|
||
小组向产品负责人展示迭代工作结果，产品负责人给出评价和反馈。以用户故事是否能成功交付来评价任务完成情况。整个团队都需要参加，ScrumMaster、产品所有者、团队，可能还有客户，时间控制在1-2小时内。
|
||
|
||
- **反思会（Retrospective Meeting）**
|
||
|
||
在每个迭代后召开简短的反思会，总结哪些事情做得好，哪些事情做得不好。做得好的保留，不好的摒弃。会议得出这样的结论：开始做什么、继续做什么、停止做什么，一般控制在15-30分钟。
|
||
|
||
Scrum是一套开发流程，是敏捷的一种，实施主要还是看人，强调是自组织、自驱动的，只有不断的在实际应用中仔细体会，才能理解Scrum的真谛，把Scrum用好。
|
||
|
||
#### 4. Scrum 的三个工件
|
||
- **产品待办列表（Product Backlog）**：产品负责人维护的一个有序列表，包含所有需要完成的工作项。
|
||
- **Sprint Backlog**：在Sprint Planning期间，团队从产品待办列表中选择的工作项，计划在当前Sprint中完成。
|
||
- **增量（Increment）**：Sprint结束时，团队交付的“完成”的产品增量。
|
||
|
||
#### 5. Scrum 的五个价值观
|
||
- **承诺（Commitment）**：团队成员承诺达到Sprint目标。
|
||
- **勇气（Courage）**：团队成员有勇气做出决策和履行承诺。
|
||
- **开放（Openness）**：团队保持透明，对所有利益相关者开放。
|
||
- **专注（Focus）**：团队成员专注于Sprint目标。
|
||
- **尊重（Respect）**：团队成员相互尊重，尊重彼此的工作和贡献。
|
||
|
||
#### 6. 实施Scrum的步骤
|
||
1. **组建团队**：确保团队成员具有所需的跨功能技能。
|
||
2. **定义产品待办列表**：产品负责人创建并维护产品待办列表。
|
||
3. **进行Sprint Planning**：团队决定在下一个Sprint中完成的工作。
|
||
4. **执行Daily Scrum**：每天进行短暂的站立会议，讨论进展和计划。
|
||
5. **完成Sprint**：在Sprint结束时，团队交付增量。
|
||
6. **进行Sprint Review**：团队展示他们的工作，收集反馈。
|
||
7. **进行Sprint Retrospective**：团队回顾Sprint，找出改进点。
|
||
8. **重复**：进入下一个Sprint，持续改进。
|
||
|
||
#### 7. Scrum 的工具和技巧
|
||
- 使用看板（Kanban board）来可视化Sprint Backlog。
|
||
- 使用用户故事、任务和验收标准来定义工作项。
|
||
- 使用燃尽图（Burn-down chart）来跟踪Sprint进度。
|
||
|
||
#### 8. 常见问题和解决方案
|
||
- **多任务处理**：避免多任务，专注于当前的Sprint目标。
|
||
- **沟通不畅**：通过Daily Scrum和其他会议保持团队沟通。
|
||
- **需求频繁变更**：通过产品待办列表的细化和优先级调整来管理变更。
|
||
|
||
#### 9. 附录： 12原则
|
||
|
||
敏捷开发的12原则，这12原则作为敏捷开发对于软件开发流程的指导性纲领，也是对敏捷宣言进行了具有实际操作意义的解释，希望大家在实际应用中仔细体会。
|
||
|
||
我们遵循以下准则：
|
||
|
||
- 我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。
|
||
- 欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。
|
||
- 要不断交付可用的软件，周期从几周到几个月不等，且越短越好。
|
||
- 项目过程中，业务人员与开发人员必须在一起工作。
|
||
- 要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。
|
||
- 无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。
|
||
- 可用的软件是衡量进度的主要指标。
|
||
- 敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
|
||
- 对技术的精益求精以及对设计的不断完善将提升敏捷性。
|
||
- 要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。
|
||
- 最佳的架构、需求和设计出自于自组织的团队。
|
||
- 团队要定期反省如何能够做到更有效，并相应地调整团队的行为。 |