docs &
This commit is contained in:
parent
6dada9d542
commit
14d32974b2
BIN
docs/guides/imgs/scrum.png
Normal file
BIN
docs/guides/imgs/scrum.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 320 KiB |
@ -3,6 +3,11 @@
|
|||||||
#### 1. Scrum 简介
|
#### 1. Scrum 简介
|
||||||
Scrum 是一种敏捷的项目管理和产品开发框架,用于帮助团队以迭代和增量的方式交付复杂的产品。它强调跨功能团队的协作、透明和检查。
|
Scrum 是一种敏捷的项目管理和产品开发框架,用于帮助团队以迭代和增量的方式交付复杂的产品。它强调跨功能团队的协作、透明和检查。
|
||||||
|
|
||||||
|
Scrum是一个用于开发和维护复杂产品的框架,是一个增量的、迭代的开发过程,目的是让开发人员像打橄榄球一样迅猛并充满激情,通过团队合作,提高工作效率。通过团队间的有效交互,为企业创造价值。
|
||||||
|
|
||||||
|
Scrum的开发流程:
|
||||||
|
![](./imgs/scrum.png)
|
||||||
|
|
||||||
#### 2. Scrum 的三个角色
|
#### 2. Scrum 的三个角色
|
||||||
- **产品负责人(Product Owner)**:负责定义产品愿景、管理产品待办列表(Product Backlog)并确保团队理解待办事项。
|
- **产品负责人(Product Owner)**:负责定义产品愿景、管理产品待办列表(Product Backlog)并确保团队理解待办事项。
|
||||||
- **Scrum Master**:负责确保Scrum框架被正确理解和实施,帮助团队成员解决阻碍进度的问题。
|
- **Scrum Master**:负责确保Scrum框架被正确理解和实施,帮助团队成员解决阻碍进度的问题。
|
||||||
@ -15,6 +20,45 @@ Scrum 是一种敏捷的项目管理和产品开发框架,用于帮助团队
|
|||||||
- **Sprint Review**:Sprint结束时,团队展示他们完成的工作。
|
- **Sprint Review**:Sprint结束时,团队展示他们完成的工作。
|
||||||
- **Sprint Retrospective**:Sprint结束后,团队回顾并讨论如何改进下一个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 的三个工件
|
#### 4. Scrum 的三个工件
|
||||||
- **产品待办列表(Product Backlog)**:产品负责人维护的一个有序列表,包含所有需要完成的工作项。
|
- **产品待办列表(Product Backlog)**:产品负责人维护的一个有序列表,包含所有需要完成的工作项。
|
||||||
- **Sprint Backlog**:在Sprint Planning期间,团队从产品待办列表中选择的工作项,计划在当前Sprint中完成。
|
- **Sprint Backlog**:在Sprint Planning期间,团队从产品待办列表中选择的工作项,计划在当前Sprint中完成。
|
||||||
@ -46,3 +90,22 @@ Scrum 是一种敏捷的项目管理和产品开发框架,用于帮助团队
|
|||||||
- **多任务处理**:避免多任务,专注于当前的Sprint目标。
|
- **多任务处理**:避免多任务,专注于当前的Sprint目标。
|
||||||
- **沟通不畅**:通过Daily Scrum和其他会议保持团队沟通。
|
- **沟通不畅**:通过Daily Scrum和其他会议保持团队沟通。
|
||||||
- **需求频繁变更**:通过产品待办列表的细化和优先级调整来管理变更。
|
- **需求频繁变更**:通过产品待办列表的细化和优先级调整来管理变更。
|
||||||
|
|
||||||
|
#### 9. 附录: 12原则
|
||||||
|
|
||||||
|
敏捷开发的12原则,这12原则作为敏捷开发对于软件开发流程的指导性纲领,也是对敏捷宣言进行了具有实际操作意义的解释,希望大家在实际应用中仔细体会。
|
||||||
|
|
||||||
|
我们遵循以下准则:
|
||||||
|
|
||||||
|
- 我们的最高目标是,通过尽早和持续地交付有价值的软件来满足客户。
|
||||||
|
- 欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更,帮助客户获得竞争优势。
|
||||||
|
- 要不断交付可用的软件,周期从几周到几个月不等,且越短越好。
|
||||||
|
- 项目过程中,业务人员与开发人员必须在一起工作。
|
||||||
|
- 要善于激励项目人员,给他们以所需要的环境和支持,并相信他们能够完成任务。
|
||||||
|
- 无论是团队内还是团队间,最有效的沟通方法是面对面的交谈。
|
||||||
|
- 可用的软件是衡量进度的主要指标。
|
||||||
|
- 敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
|
||||||
|
- 对技术的精益求精以及对设计的不断完善将提升敏捷性。
|
||||||
|
- 要做到简洁,即尽最大可能减少不必要的工作。这是一门艺术。
|
||||||
|
- 最佳的架构、需求和设计出自于自组织的团队。
|
||||||
|
- 团队要定期反省如何能够做到更有效,并相应地调整团队的行为。
|
@ -3,9 +3,11 @@
|
|||||||
|
|
||||||
### 1. **项目背景与目标设定**
|
### 1. **项目背景与目标设定**
|
||||||
- **定义项目**
|
- **定义项目**
|
||||||
> 基于开源项目paopao-ce,使用其前端,使用spring boot开发后端系统
|
> 基于开源项目[paopao-ce](https://github.com/rocboss/paopao-ce),使用其前端,使用spring boot开发后端系统
|
||||||
- **明确目标**
|
- **明确目标**
|
||||||
> - 了解scrum开发流程,理解scrum开发模式,了解scrum开发模式中的角色和职责,了解scrum开发模式中的 artefact(工件)
|
> - 了解scrum开发流程,理解scrum开发模式
|
||||||
|
|
||||||
|
> - 了解敏捷需求分析和管理
|
||||||
|
|
||||||
> - 掌握基于spring boot框架的开发
|
> - 掌握基于spring boot框架的开发
|
||||||
|
|
||||||
@ -35,11 +37,19 @@
|
|||||||
- **Sprint回顾会议(Sprint Retrospective)**:团队反思过去Sprint的流程,讨论改进措施。
|
- **Sprint回顾会议(Sprint Retrospective)**:团队反思过去Sprint的流程,讨论改进措施。
|
||||||
|
|
||||||
**冲刺周期一的任务**
|
**冲刺周期一的任务**
|
||||||
|
- 冲刺计划会议: 设定冲刺目标以及为冲刺选择用户故事
|
||||||
- [任务3 创建spring boot初始项目](./任务3-Sprint-1-创建spring%20boot初始项目.md)
|
- [任务3 创建spring boot初始项目](./任务3-Sprint-1-创建spring%20boot初始项目.md)
|
||||||
- [任务4-restful接口回应数据的统一封装的实现t](./任务4-Sprint-1-restful接口回应数据的统一封装的实现.md)
|
- [任务4-restful接口回应数据的统一封装的实现t](./任务4-Sprint-1-restful接口回应数据的统一封装的实现.md)
|
||||||
- [任务5-实现统一异常处理](./任务5-Sprint-1-实现统一异常处理.md)
|
- [任务5-实现统一异常处理](./任务5-Sprint-1-实现统一异常处理.md)
|
||||||
- [任务6-注册接口实现](./任务6-Sprint-1-注册接口实现.md)
|
- [任务6-注册接口实现](./任务6-Sprint-1-注册接口实现.md)
|
||||||
- [任务7-基于JWT的用户认证实现](./任务7-Sprint-1-基于JWT的用户认证实现.md)
|
- [任务7-基于JWT的用户认证实现](./任务7-Sprint-1-基于JWT的用户认证实现.md)
|
||||||
|
- [任务8-实现获取当前用户信息接口](./任务8-Sprint-1-获取当前用户信息接口.md)
|
||||||
|
- 评审和反思会议
|
||||||
|
|
||||||
|
**冲刺周期二的任务**
|
||||||
|
- 冲刺计划会议: 设定冲刺目标以及为冲刺选择用户故事
|
||||||
|
- []()
|
||||||
|
- 评审和反思会议
|
||||||
|
|
||||||
### 5. **敏捷实践应用**
|
### 5. **敏捷实践应用**
|
||||||
- **用户故事**:使用用户故事来描述需求,确保团队关注用户价值。
|
- **用户故事**:使用用户故事来描述需求,确保团队关注用户价值。
|
||||||
|
Loading…
Reference in New Issue
Block a user