SCRUM敏捷开发框架

SCRUM-敏捷开发框架韩冬2023最新整理收集do

something前言对于“敏捷开发”我也是一个初学者，通过看一些资料，总结了一些相对实用的、有可能对我们日常开发管理有帮助的知识，分享给大家。与大家共勉。目录入门与进阶入门01回顾敏捷开发介绍敏捷开发的基本情况02什么是SCRUMScrum概述03SCRUM的角色在Scrum中都有哪几类人。04SCRUM的三个工件Scrum重要的过程文档。05SCRUM的4个活动Scrum的关键环节。06SCRUM的工作流程让我们开始Scrum进阶01怎样编写PRODUCTBACKLOG这不是一件简单的事情02怎样进行SprintPlan这是一个非常重要的事情。03怎样进行每日立会站立的“立”04SPRINT演示与回顾终于快结束了。05额外的话。终于结束了。回顾敏捷开发打开“敏捷开发”这扇门。客户的需求是不断变化的，要能跟上变化，及时交付成果物。遵循计划往往跟不上变化的节奏。随时应对变化胜过遵循计划大部分的需求来源是客户，如果想通过一纸合同来要求或制约客户（比如你这个功能不在合同里，我不能给你做），不如和客户一起合作共同进行工作。客户协作胜过合同谈判客户要的是精美的软件，而不是要一批精美的文档。个人理解敏捷开发并非抛弃所有文档，而是不建议过度完善和冗余的文档。可以工作的软件胜过完备的文档在日常工作中虽然有工作流程和管理工具辅助我们交流沟通，比如邮件、禅道。但从效率和效果上看远没有面对面沟通有效。人和交互胜过过程和工具什么是敏捷开发以用户的需求变化为核心，采用迭代、循序渐进的方法进行软件开发。敏捷宣言传统项目管理：

1.事先对项目计划进行评估、计划、分析。

2.反对变更；变更需要重新估计、重新规划。

3.严密的合同来减少风险，如果改变需要走CR（ChangeRequest）流程。

4.项目作为一个“黑盒子”，对客户与供应商可视性差。

5.产品化和测试阶段是分离的。

6.文档和计划驱动的方法。

7.软件交付时间晚，意识到风险的时间晚。敏捷项目管理：

1.对整个项目做一个粗略的估计，每一次迭代都有详细的计划。

2.鼓励变化，客户价值驱动开发。

3.信任和赋予权力；合约使变更变得简单和更有价值。

4.客户和开发人员之间是紧密的连续的合作关系。

5.每次迭代都产生可交付的软件。

6.专注于交付软件。

7.第一次迭代就可交付能工作的版本，风险发现的早。敏捷PK传统敏捷开的收益提高了生产率；减少“浪费”（不需要的文档，重复工作等），项目的每次迭代都有明确的目标。提高客户满意度；短期内产生成效，按预期交付软件，每次迭代结束产生可以运行的软件。改善员工的满意度；团队精神，减少官僚，能够规划和管理自己的工作，减少“恐慌”，稳定的工作量（可持续的步伐）IT开发管理方法使用情况什么是SCRUM探索SCRUMScrum是一种工作管理的方法，不仅仅限于软件开发，可以用来管理其他活动，不包含技术方法或实践。依赖迭代和增量的敏捷方法。简单，但高度的纪律性。Scrum是管理软件项目中的一个轻量级的敏捷方法，名字来源于橄榄球运动中的scrum过程SCRUM概述SCRUM的角色在SCRUM中都有哪几类人SCRUM的角色产品所有者Scrum大师Scrum团队ProductOwnerScrumMasterScrumTeamProductOwner一般由客户担当，但根据情况也可以是项目经理担当。具体的需求内容及优先级由客户提供或需求部门提供，随时解答团队工作中产生的各项和产品、业务相关的问题。创建和维护ProductBacklog(产品需求清单），管理项目的范围。决定产品有哪些功能。产品的目标。ScrumTeam敏捷是建立在信任和授权的基础上，因此团队是自发组织，组员选择自己的任务，而不是别人强制加以分配。他们需要自我激励和对工作的目标进行承诺。Scrum团队中的角色是不分等级的；不应当出现“我是开发人员我不做测试”。Scrum团队是职能交叉的，包涵产品交付的所有角色：开发人员、测试人员、设计人员。等Scrum团队是Scrum的中心角色，产品交付要依靠团队。Scrum团队最佳规模6-10人ScrumMaster服务于Produce

Owner，服务于Scrum

Team主要职责：评价过程的健康情况，加强Scrum过程，消除障碍，促进过程改进。Scrum

Master通常由项目组的成员担当，组长或者项目经理。Scrum

Master负责确保Scrum被理解并实施，为了达到这个目的，ScrumMaster要确保Scrum团队遵循Scrum的理论、实践和规则。ScrumMaster是Scrum团队中的服务式领导。Scrum

Master应该是专注的、有决心的、有领导才能的。SCRUM的三个工件Scrum重要的过程文档产品需求清单（product

Backlog)包括内容：产品需求清单(Product

Backlog)是Scrum的核心，也是一切的起源。从根本上说，他就是一个需求、故事、或特性等组成的列表，按照重要性的级别进行了排序。他里面包含的是客户想要的东西，并用客户的术语加以描述。产品负责人（Product

Owner)负责产品需求清单(Product

Backlog)列表的内容、可用性和优先级。功能方面的需求，功能点。非功能方面的需求，如性能改进等。需要修改的bug，上一版本已知的问题。新技术，如支持新的操作系统或平台。问题，日后可能新增的项，新功能。产品需求清单是不断完善的。在项目进行中随时新增、修改、删除功能，变更优先级。Product

Backlog示例序号优先级，重要程度需求描述(story)发布人Product

Backlog示例ID:序号Name：名称Imp：重要程度Est：估算How

to

demo：如何演示Notes：说明，备注。迭代(冲刺）任务清单（SprintBacklog)能提取多少产品任务清单中的任务取决于Scrum团队能承诺完成多少。SprintBacklog主要是从产品任务清单（ProductBacklog)中挑选出高优先级的任务，确定本次迭代的任务目标。承诺总是来自于内部，不能从外部加强。迭代不应当有空闲时间，因此规划的迭代内容要保证工作量是稳定的）依赖的因素较多：团队的能力，技术的成熟度，当前迭代增量的情况。产品所有者（ProductOwner)定义每个迭代的任务说明、目标。使迭代更具有针对性。Sprint

Backlog示例冲刺目标：SprintGoal任务执行人估算完成状态任务受阻燃尽图（Burn-DownChart)在Sprint开始的时候ScrumTeam会标示和估计在这个Sprint需要完成的详细的任务。所有这个Sprint中需要完成，但没有完成的任务的工作量是累积工作量，团队会根据进展情况每天更新累积工作量，如果在Sprint结束时，累积工作量降低到0，Sprint就成功结束。SprintBurndownChart显示了Sprint中积累剩余的工作量，他是一个反应工作量完成状况的趋势图。Y轴代表的是剩余工作量，X轴代表的是Sprint的工作日。Burn-DownChart示例在冲刺开始时预先估算的时间剩余工作量汇总剩余工作量增加快速下降：进度快SCRUM的4个活动Scrum的关键环节冲刺计划会议（SprintPlanMeeting）决定在Sprint中需要完成哪些工作。产品责任人(ProductOwner)向团队介绍排好序的需求清单。并和开发团队(ScrumTeam)确认在这一次的冲刺(Sprint）中能够完成的需求列表。产品每个Sprint都以Sprint计划会议作为开始，这是一个固定时长的会议，在这个会议中,Scrum团队共同选择和理解在即将到来的Sprint中要完成的工作。最终产生冲刺需求清单(SprintBacklog)每日Scrum会议（DailyScrum）立会最长15分钟，在整个迭代过程中每天定时召开。ScrumMaster负责整个会议。其他人可以参与，但只允许Scrum

Master和Scrum

Team团队成员讲话。团队成员之间交流信息。了解项目的真实进展情况。交流风险和存在的问题。面对面的会议加强了承诺。核心的3个问题：昨天（上次会议之后）你做了什么？今天（下次会议之前）你准备做什么？有没有障碍？冲刺评审（SprintReview）ScrumMaster主持会议，Scrum团队负责演示。会议其他参与者：

产品所有者(ProductOwner)必须参加、客户、管理人员、以及其他感兴趣的人，例如其他Scrum团队。产品Sprint结束时,Scrum团队和相关人员一起评审Sprint的产出。确保成果与预期的一致，收集反馈。为项目提供一个参考点，根据目前的位置计划下一期的旅程。为下一次迭代提供输入（改正、修改、新的想法），可以由产品所有者（ProductOwner)添加到产品需求清单。总体时间不超过4个小时。冲刺回顾（SprintRetrospective）ScrumMaster主持，持续半天，Scrum团队参加(产品所有者ProductOwner)也可以参加。回顾的目的是评价本次迭代并酝酿改进，使得下一个迭代进行得更好。ScrumMaster总结本次迭代；迭代任务清单，重要的事情和决策。每个组员陈述迭代中哪些方法进行的好，哪些需要改进，哪些需要在下一个Sprint中改变。对预估生产率和实际生产率进行比较，如果差异较大的话我们会分析原因。对重要的问题计划相应的措施：团队自己解决，或者提交给公司的管理层。简单流程：SCRUM的工作流程让我们开始Scrum。Scrum整体框架可工作的软件迭代开发冲刺需求清单SprintBacklog2-4周迭代ScrumMaster产品需求清单ProductBacklogProductOwner产品所有者ScrumTeamSprintPlanMeeting计划会议DailyScrum每日立会SprintReview冲刺评审会SprintRetrospective冲刺回顾入门－小结让我们也进行一次短暂的回顾。1.什么是敏捷开发。2.敏捷宣言。3.敏捷和传统开发方式的对比。4.敏捷开发的收益。回顾敏捷开发什么是ScrumScrum重要组成流程框架入门－小结1.Scrum概述1.3个角色。2.3个工件。3.4个活动流程图中场休息清理思路，再接再厉。进阶01怎样编写PRODUCTBACKLOG这不是一件简单的事情02怎样进行SprintPlan这是一个非常重要的事情。03怎样进行每日立会站立的“立”04SPRINT演示与回顾终于快结束了。05额外的话。终于结束了。怎样编写ProductBacklog这不是一件简单的事情。需要了解的细节推荐的方法：比较好的方法是Product

Ownder\Scrum团队、客户／管理以及其他相关方（比如其他Scrum团队）举行一次或多次研讨会。需求的来源：客户，标书，需求规格说明书。Scrum团队的想法，增强型新功能等。现有产品迭代增量，已知错误，技术问题等。ScrumMaster或者ProductOwner来促成会议，必须有人要来做。要有效率，要围绕主题、沟通良好、避免不同的假设。承诺并且共通合作，确定优先级。通常规则为在PPT文档下中英文各使用一种字体以保持全文档统一。这里输入文字，自由替换文字、图片和图标，这里输入文字，自由替换文字、图片和图标，方便编辑易用大方。需求清单的重要元素ID:序号Name：名称Imp：重要程度Est：估算How

to

demo：如何演示Notes：说明，备注。要点初始估算：换算单位是故事点(StoryPoint),大致相当于一个理想的人天。Imp:重要程度：产品负责人评出一个数值,指示这个故事（Story）有多重要。例如10或150。分数越高越重要。避免“优先级”这个说法,因为一般说来优先级1都表示“最高”优先级,如果后来有其他更重要的东西就麻烦了。它的优先级评级应该是什么呢?优先级0?优先级-1?

重要程度10和20的区别。只代表20比10重要。不是重要2倍。要有一些跨度。额外的字段：类别（后台系统，优化），组件（服务端，客户端，数据库），请求者（客户，其他项目干系人）怎样进行SprintPlan这是一件重要的事情。如何决定放哪些story到Sprint中方法论产品负责人必须参加会议。产品负责人Sprint计划会议非常关键。举办会议的成果：明确Sprint的目标，团队成员名单以及投入程度。产出SprintBacklog,确定好评审（演示）日期。Sprint

Plan产品负责人必须要参加如果产新品负责人坚持不参加怎么办？每一个需求（story)都有3个变量，范围，重要程度，估算。其中范围和重要程序需要产品负责人确定。1.尝试让产品负责人理解，为什么要参加的重要性。2.实验在团队中找一个人，可以充当产品负责人的代表。3.推迟会议日期。直到产品负责人找到时间参会为止。4.换人，尝试说服管理团队重新分配产品负责人。方法论如何决定将哪些Story放入Sprint中？1.本能反应法2.计算生产率法。Scrummaster:“伙计们,我们在这个sprint里面能完成故事A吗?”(指向产品backlog中最重要的条目)Lisa:“呃。当然可以。我们有三个星期,这只是个微不足道的特性。Scrum

master:“OK,那加上B怎么样?”(指向第二重要的条目)Tom和Lisa一起回答:“自然没问题。”Scrum

master:“OK,那A、B、C一起呢?”Sam(对产品负责人说):“故事C要包括高级错误处理么?”产品负责人:“不,你现在可以跳过它,只需要完成基的错误处理。”Sam:“那C应该没问题。”Scrum

master:“OK,那再加上D呢?”Lisa:“嗯......”Tom:“我觉得能完成。”Scrum

master:“有多少把握?90%?还是50%?”Lisa和Tom:“差不多90%”Scrum

master:“OK,D也加进来。那再加上E呢?”Sam:“也许吧。”Scrummaster:“90%?50%?”Sam:“差不多50%”Lisa:“我没把握。”Scrum

master:“OK,那先把它放一边去。我们要做完A、B、C和D。如果有时间的话当然还可以做完E,不过既然没人指望它能做完,所以我们不会把它算到计划里面来。现在怎么样?”所有人:“OK!”

本能反应法确定如果sprint时间不长,小团队根据直觉进行估算可以收到很好的效果计算生产率法举个例子：假设在上个sprint里面,由Tom,Lisa和Sam组成的3人团队在3个星期内工作了45个人-天,一共完成18个故事点。现在我们要为下一个sprint估算一下生产率。新伙计Dave的加入让情况更复杂了。把假期和新成员算上,我们在下个sprint中一共有50个人-天。实际投入真是这样吗？上一次迭代投入程度＝18／45＝40%新迭代的估算生产率＝50*40%＝20

故事点：StoryPoint一般大致相当于一个“理想的人天(man-day)”什么是生产率？在一次迭代开发中能够实际投入的开发量。可投入的开发资源（人－天）＊投入程度（focusfactor)＝估计速度如果没有可参考的上一次迭代可设置一个默认投入程度：70%怎样进行每日立会(DailyScrum)这是站立的“立”。工欲善其事。怎么布置团队房间还是有一定作用的。燃尽图不一样的看板神奇的看板这是每天必做的一件重要的事情。DailyScrum神奇的看板找一面尚未使用或者充满无用信息(如陈旧图表或者丑陋的涂鸦)的大墙。清理墙壁(除非不得已才去请求别人许可)。在墙上贴上一张很大很大的纸(至少2x2平方米,大团队需要3x2平方米)神奇的看板UnDo:未开始做的事情Doing:正在进行的工作完成的工作燃尽图在一次Sprint结速前已经完成了所有的Backlog。可以从这里选取任务白色标签在所有黄色标签