您现在的位置是:网站首页> 编程开发> 敏捷开发 编程开发

Scrum敏捷开发

2021-08-19敏捷开发 104人已围观

简介一张图看懂 ScrumScrum 工具包括:3个角色、3个工件、5个活动和5个价值观。3个角色01 Product Owner:职责:清楚知道产品的愿景,分为近期和远期。清楚愿景才不至于被干扰带偏道路,才可以清楚的区分重要紧急、重要不紧急、不重要紧急、不重要不紧急事件。我们可以集中精力于重要不紧急事件,这样就能减少重要紧急事件的发生。获取外界的诉求并进行整理成 User Story。外界:用户、运

Scrum敏捷开发

最后更新:2021-10-23 07:35:57

推荐指数

一张图看懂 Scrum

260755327ce94dc285b2bb987da681eb.jpg

Scrum 工具包括:3个角色、3个工件、5个活动和5个价值观。

3个角色

01 Product Owner:

职责:

清楚知道产品的愿景,分为近期和远期。

清楚愿景才不至于被干扰带偏道路,才可以清楚的区分重要紧急、重要不紧急、不重要紧急、不重要不紧急事件。我们可以集中精力于重要不紧急事件,这样就能减少重要紧急事件的发生。

获取外界的诉求并进行整理成 User Story。

外界:用户、运营部门、其他业务方

User Story:需要实现的功能,以客户的角度,描述「我需要功能A,来达到我的什么目的」。

对整理好的 User Story 所需要的资源进行各方协调并得出「是否可行、什么时候可行」的结论。

一个功能的实现,有时候牵涉各个业务系统,往往各个业务系统所对应的Team排期是不一样的,就需要提前进行沟通。尽最大努力避免在开发的过程中才发现问题,这时候才和其他业务系统沟通影响面就很大,其他业务系统人员很可能拒绝进行协助,业务紧急强行协助导致会打乱了其他团队的开发计划。

根据产品的近期目标,对 User Story 进行优先级排序;期间有更好的 Idea 需要对 User Story 优化,这是一个持续的过程。

注意:Story 的优先级只能有一个1,一个2…一个10。不要把这些功能放得同等重要,这期都得全部实现,全部都是1,这样的做法就失去了优先级的意义。仔细的思考,斟酌,比如问自己「少了这个功能会有什么影响——公司会因此损失100万吗?公司会倒吗?」,有时候并没有想的那么紧急,只是先入为主的思想陷入了局限的泥潭失去了大局观。最后一定是能够得出一个唯一序列的优先级排序的。

需求从外界到 PO 手里的时候,不应该一味地紧缩一线开发人员的时间。PO 的责任不能仅仅是满足外界的诉求,还应该考虑 Team 人员的工作状态和情绪,他们可是实现你「蓝图」的一线人员。(公司所有人都致力于目前公司的蓝图,PO 正是在推动着这张大蓝图中的某个模块。)因此 PO 应该全面考虑团队的目前状态,有时督促团队全速前进,有时应该是 Team 的保护伞,这些都是为了实现公司蓝图更好、更快的前行。

初步决定 Team 每个 Sprint 要完成哪些 Story 任务。

这里只能是初步决定,精确的结果需要在下面的 Plan Metting 中 Team 对其进行时间评估,最后根据该个 Sprint 的任务饱和度,进行 Story 的裁剪或增加。有许多情况并非如此,「这个 Sprint 整理的所有的需求都要实现」,没有考虑过公司现在 Team 所配备的资源情况和完成能力才会有这样的决定,这也往往导致了产品——开发之间的诸多矛盾。心理活动,产品:「这么简单的功能都完成不了」,开发:「你行你来呀」。诸多时候我们以 5000 多年以来的人文素养平息了这场风波,妥协的结果就是质量堪忧甚至完不成任务。

在一个 Sprint 开始后结束前,如果有紧急需求进入,需要站出来保护团队,因为往往很多需求都是认为很紧急而已。

尽量避免 Team 受外界影响,这时候插入紧急需要往往会打乱开发节奏,从而引发各种问题和风险。这个「紧急」需求,如果经过讨论和仔细分析后,大家得出的结论还是是紧急并重要的话,那么这个需求形成的 Story 就需要插入此次 Sprint,优先级列表在这个时候就起作用了,可以在此次 Sprint 的优先级列表中移除一些低优先级 Story。

02 Scrum Master:

职责:

协助 Product Owner 整理需求。

开发是最熟悉每个业务流程以及可能的牵涉方的,要完成列表中的 Story,需要协调哪些资源,以及协助评估现在的资源能否顺利完成这些 Story。

作为 Scrum Team 的带头人,需要确保团队的合理运作,清除 Sprint 开发中的障碍,引导 Team 高效的完成每日工作。

组织团队工作,sprint planning meeting、daily standupo meeting、sprint review、retrospective meeting 组织各项会议的开展(该四个会议在5个活动中会详细介绍)。

帮助大家接收敏捷的理念,推动团队按照敏捷价值观和原则所倡导的方法做出决策。

不要过高估团队的适应能力,当然也不要过低评估团队的适应能力。推行敏捷定是一个长期的过程,Team 人员有着不同的工作经历,不同的公司不同的文化背景,以及现在公司的企业文化影响,推行一套理念都需要专注于明确的目标(Focus)、反馈(Feedback)、纠正(Fix)——简称为3F原则,然后依此循环,长期的反复的过程。

尽量保证团队在每个Sprint中不被打扰。

如果发现有发现影响团队工作的任务来临,要敢于说「NO」,如果确实是重要紧急的需求,而该 Sprint 工作量已经饱和情况,就有必要协商移除之前优先级最低开始的User Story,以保证工作的顺利进行。

03 Team:

职责:

学习和使用敏捷的理念,反馈工作或流程中存在的问题,甚至提出解决方案。

积极去推动任务的进展,提高自我执行力。

高效的沟通,尽量避免通过第三方传达的沟通方式。

高质量的完成 Sprint 开发需求,按期交付。

3个工作

01 Product Backlog:

指有优先级的产品待办事项列表。Product Owner 收集来自于各方的需要、期望、诉求等等,并整理成 User Story 表达形式到产品待办列表中,评定优先级。

02 Sprint Backlog:

每个 Sprint 的任务开发列表 。

03 Burndown chart:

燃尽图,能够直观的看到在每个 Sprint 剩余工作时间和任务完成情况,有效的把控 Sprint 功能交付的风险。

5个活动

01 Sprint:

冲刺(有的公司叫班车,从起点站发车,到一站后需求完成下车,新需求上车,迭代的过程以此往复),一个固定的时间周期(通常为2w~4w,新项目可以是1w)。

02 Sprint planning meeting:

通过会议得出的本轮迭代任务。Sprint 开始的时候,Product Owner 、 Scrum Master 和 Team 根据团队的资源和能力,从 Product Backlog 中按照优先级选取这个 Sprint 要做的 User Story,并且对 Team 提出的问题进行解释和澄清,最终形成本轮的 Sprint Backlog。Team 负责将这些 User Story 拆分成一个个小的 Task,给出完成每个 Task 的时间估算,一般可在 6 小时内完成(6小时一般是一天的高效时间,其他时间可作为 Buffer),达到可量化。

03 Daily standup meeting:

每日站会,一般选在早上,15分钟左右。每个人讲述进展情况(昨天做了什么,今天准备做什么,遇到什么问题),遇到了 Block 的问题,需要 Scrum Master 出面来扫清障碍保证 Team 能够专注的完成任务。这样能够及时的暴露出开发过程遇到的问题,能够的有效的评估风险以及及时讨论解决方案。通过这样透明化的披露,可以将个人和他人的工作结合起来,会更好的考虑自己的工作是否会影响别人。通过每个人进展的汇报,整个 Team 随时可以了解到离完成我们的 Sprint 目标还有多远。

每个人主动在 To do(准备做)一栏中的选取今日要完成的任务放入 InProgress 一栏并且开工,第二天立会继续按此勾兑,同时将已完成的任务放入 Done(完成)一栏,Blocked 项 Scrum Master 会负责跟踪,和扫除障碍。

04 Sprint review:

在 Sprint 周期结束,需要进行一次评审会议,向 Product Owner 和利益相关方展示完成的功能。回答利益相关者的问题,并记录期望的更改。评审会议可以让其他人了解团队在做些什么,并得到反馈。

05 Retrospective meeting:

回顾会议,通常在 Sprint reivew 会议之后开始。回顾会议是团队内部针对本次 Sprint 内发生的做的好的进行累积,可以改进的、存在问题的作为 Fix 项, Fix 项作为下一轮Sprint任务,也就是持续累积和改进的过程。将好的吸取,不好的改进,那么流程就会越来越完善。

5个价值观

团队内在的灵魂

01 专注:

只专注于每个 Sprint 要完成的事情,团队和个人的能力和精力都是有限的,在有限的时间内专注于最有价值的事情,以取得好的结果。

02 勇气:

团队完成任务的过程中肯定都会遇到一些棘手问题的情况,要有勇气去挑战和面对。

03 公开:

Sprint 的进展,遇到的问题,阻碍都应该对所有人可视化,透明的。这样的团队才能彼此了解,彼此尊重,同时也能暴露问题。

04 承诺:

团队在 Sprint 开始的时候做出承诺,并在迭代中全力完成,达成功能交付。

05 尊重:

尊重各个团队以及团队的人员。不要越界(超出了自己的范畴)议论,「产品觉得这么简单的功能还要那么久才能完成」、「开发觉得 UI 怎么设计得这么 Low」、「UI 觉得这么简单的效果你们都做不出来」等,我们要相信他人能够在这个岗位上就有胜任的能力,要相信他的专业能力。

结语

02be46733f244db9988950c8ddef2bab.png

采取高效的沟通方式,除非情非得已,不要由中间人转接你们各自的诉求,直接沟通,减少交流成本。

Scrum 只是一套工具,实施主要还是看人。其中的流程并非一定完全硬套,工具是死的,实施的人是活的,当然是可以根据公司的情况对某些流程进行调整、替换、甚至删除,总结一套适合团队的流程最要紧。最重要的是定下一套流程规则,然后遵守这套规则,循环往复的发现问题和解决问题,完善流程。



很赞哦! (0)