SCRUM敏捷开发框架.pptx

,SCRUM-敏捷开发框架,韩冬,前言,对于“敏捷开发”我也是一个初学者，通过看一些资料，总结了一些相对实用的、有可能对我们日常开发管理有帮助的知识，分享给大家。与大家共勉。,目录,入门与进阶,入门,进阶,回顾敏捷开发,打开“敏捷开发”这扇门。,以用户的需求变化为核心，采用迭代、循序渐进的方法进行软件开发。,敏捷宣言,传统项目管理：1.事先对项目计划进行评估、计划、分析。2.反对变更；变更需要重新估计、重新规划。3.严密的合同来减少风险，如果改变需要走CR（ChangeRequest）流程。4.项目作为一个“黑盒子”，对客户与供应商可视性差。5.产品化和测试阶段是分离的。6.文档和计划驱动的方法。7.软件交付时间晚，意识到风险的时间晚。,敏捷项目管理：1.对整个项目做一个粗略的估计，每一次迭代都有详细的计划。2.鼓励变化，客户价值驱动开发。3.信任和赋予权力；合约使变更变得简单和更有价值。4.客户和开发人员之间是紧密的连续的合作关系。5.每次迭代都产生可交付的软件。6.专注于交付软件。7.第一次迭代就可交付能工作的版本，风险发现的早。,敏捷开的收益,提高了生产率；减少“浪费”（不需要的文档，重复工作等），项目的每次迭代都有明确的目标。提高客户满意度；短期内产生成效，按预期交付软件，每次迭代结束产生可以运行的软件。改善员工的满意度；团队精神，减少官僚，能够规划和管理自己的工作，减少“恐慌”，稳定的工作量（可持续的步伐）,IT开发管理方法使用情况,什么是SCRUM,探索SCRUM,SCRUM的角色,在SCRUM中都有哪几类人,产品所有者,Scrum大师,Scrum团队,ProductOwner,ScrumMaster,ScrumTeam,ProductOwner,一般由客户担当，但根据情况也可以是项目经理担当。具体的需求内容及优先级由客户提供或需求部门提供，,随时解答团队工作中产生的各项和产品、业务相关的问题。,创建和维护ProductBacklog(产品需求清单），管理项目的范围。,决定产品有哪些功能。产品的目标。,ScrumTeam,敏捷是建立在信任和授权的基础上，因此团队是自发组织，组员选择自己的任务，而不是别人强制加以分配。他们需要自我激励和对工作的目标进行承诺。,Scrum团队中的角色是不分等级的；不应当出现“我是开发人员我不做测试”。,Scrum团队是职能交叉的，包涵产品交付的所有角色：开发人员、测试人员、设计人员。等,Scrum团队是Scrum的中心角色，产品交付要依靠团队。,Scrum团队最佳规模6-10人,ScrumMaster,服务于ProduceOwner，服务于ScrumTeam,主要职责：评价过程的健康情况，加强Scrum过程，消除障碍，促进过程改进。,ScrumMaster通常由项目组的成员担当，组长或者项目经理。,ScrumMaster负责确保Scrum被理解并实施，为了达到这个目的，ScrumMaster要确保Scrum团队遵循Scrum的理论、实践和规则。ScrumMaster是Scrum团队中的服务式领导。,ScrumMaster应该是专注的、有决心的、有领导才能的。,SCRUM的三个工件,Scrum重要的过程文档,产品需求清单（productBacklog),包括内容：,产品需求清单(ProductBacklog)是Scrum的核心，也是一切的起源。从根本上说，他就是一个需求、故事、或特性等组成的列表，按照重要性的级别进行了排序。他里面包含的是客户想要的东西，并用客户的术语加以描述。产品负责人（ProductOwner)负责产品需求清单(ProductBacklog)列表的内容、可用性和优先级。,功能方面的需求，功能点。非功能方面的需求，如性能改进等。需要修改的bug，上一版本已知的问题。新技术，如支持新的操作系统或平台。问题，日后可能新增的项，新功能。,产品需求清单是不断完善的。在项目进行中随时新增、修改、删除功能，变更优先级。,ProductBacklog示例,序号,优先级，重要程度,需求描述(story),发布人,ProductBacklog示例,ID:序号,Name：名称,Imp：重要程度,Est：估算,Howtodemo：如何演示,Notes：说明，备注。,迭代(冲刺）任务清单（SprintBacklog),能提取多少产品任务清单中的任务取决于Scrum团队能承诺完成多少。,SprintBacklog主要是从产品任务清单（ProductBacklog)中挑选出高优先级的任务，确定本次迭代的任务目标。,承诺总是来自于内部，不能从外部加强。迭代不应当有空闲时间，因此规划的迭代内容要保证工作量是稳定的）依赖的因素较多：团队的能力，技术的成熟度，当前迭代增量的情况。,产品所有者（ProductOwner)定义每个迭代的任务说明、目标。使迭代更具有针对性。,SprintBacklog示例,冲刺目标：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负责整个会议。其他人可以参与，但只允许ScrumMaster和ScrumTeam团队成员讲话。,团队成员之间交流信息。了解项目的真实进展情况。交流风险和存在的问题。面对面的会议加强了承诺。,核心的3个问题：,昨天（上次会议之后）你做了什么？今天（下次会议之前）你准备做什么？有没有障碍？,冲刺评审（SprintReview）,ScrumMaster主持会议，Scrum团队负责演示。会议其他参与者：产品所有者(ProductOwner)必须参加、客户、管理人员、以及其他感兴趣的人，例如其他Scrum团队。,产品Sprint结束时,Scrum团队和相关人员一起评审Sprint的产出。,确保成果与预期的一致，收集反馈。为项目提供一个参考点，根据目前的位置计划下一期的旅程。为下一次迭代提供输入（改正、修改、新的想法），可以由产品所有者（ProductOwner)添加到产品需求清单。,总体时间不超过4个小时。,冲刺回顾（SprintRetrospective）,ScrumMaster主持，持续半天，Scrum团队参加(产品所有者ProductOwner)也可以参加。,回顾的目的是评价本次迭代并酝酿改进，使得下一个迭代进行得更好。,ScrumMaster总结本次迭代；迭代任务清单，重要的事情和决策。每个组员陈述迭代中哪些方法进行的好，哪些需要改进，哪些需要在下一个Sprint中改变。对预估生产率和实际生产率进行比较，如果差异较大的话我们会分析原因。对重要的问题计划相应的措施：团队自己解决，或者提交给公司的管理层。,简单流程：,SCRUM的工作流程,让我们开始Scrum。,可工作的软件,迭代开发,冲刺需求清单SprintBacklog,2-4周迭代,ScrumMaster,产品需求清单ProductBacklog,ProductOwner产品所有者,ScrumTeam,SprintPlanMeeting计划会议,DailyScrum每日立会,SprintReview冲刺评审会,SprintRetrospective冲刺回顾,入门小结,让我们也进行一次短暂的回顾。,1.Scrum概述,1.3个角色。2.3个工件。3.4个活动,流程图,中场休息,清理思路，再接再厉。,进阶,怎样编写ProductBacklog,这不是一件简单的事情。,需要了解的细节,推荐的方法：比较好的方法是ProductOwnderScrum团队、客户管理以及其他相关方（比如其他Scrum团队）举行一次或多次研讨会。,需求的来源：,客户，标书，需求规格说明书。Scrum团队的想法，增强型新功能等。现有产品迭代增量，已知错误，技术问题等。,ScrumMaster或者ProductOwner来促成会议，必须有人要来做。要有效率，要围绕主题、沟通良好、避免不同的假设。承诺并且共通合作，确定优先级。,通常规则为在PPT文档下中英文各使用一种字体以保持全文档统一。这里输入文字，自由替换文字、图片和图标，这里输入文字，自由替换文字、图片和图标，方便编辑易用大方。,需求清单的重要元素,ID:序号,Name：名称,Imp：重要程度,Est：估算,Howtodemo：如何演示,Notes：说明，备注。,要点,初始估算：换算单位是故事点(StoryPoint),大致相当于一个理想的人天。,Imp:重要程度：产品负责人评出一个数值,指示这个故事（Story）有多重要。例如10或150。分数越高越重要。,避免“优先级”这个说法,因为一般说来优先级1都表示“最高”优先级,如果后来有其他更重要的东西就麻烦了。它的优先级评级应该是什么呢?优先级0?优先级-1?重要程度10和20的区别。只代表20比10重要。不是重要2倍。要有一些跨度。,额外的字段：类别（后台系统，优化），组件（服务端，客户端，数据库），请求者（客户，其他项目干系人）,怎样进行SprintPlan,这是一件重要的事情。,Sprint计划会议非常关键。,举办会议的成果：明确Sprint的目标，团队成员名单以及投入程度。产出SprintBacklog,确定好评审（演示）日期。,SprintPlan,产品负责人必须要参加,如果产新品负责人坚持不参加怎么办？,每一个需求（story)都有3个变量，范围，重要程度，估算。其中范围和重要程序需要产品负责人确定。,1.尝试让产品负责人理解，为什么要参加的重要性。2.实验在团队中找一个人，可以充当产品负责人的代表。3.推迟会议日期。直到产品负责人找到时间参会为止。4.换人，尝试说服管理团队重新分配产品负责人。,方法论,如何决定将哪些Story放入Sprint中？,1.本能反应法2.计算生产率法。,Scrummaster:“伙计们,我们在这个sprint里面能完成故事A吗?”(指向产品backlog中最重要的条目)Lisa:“呃。当然可以。我们有三个星期,这只是个微不足道的特性。Scrummaster:“OK,那加上B怎么样?”(指向第二重要的条目)Tom和Lisa一起回答:“自然没问题。”Scrummaster:“OK,那A、B、C一起呢?”Sam(对产品负责人说):“故事C要包括高级错误处理么?”产品负责人:“不,你现在可以跳过它,只需要完成基的错误处理。”Sam:“那C应该没问题。”Scrummaster:“OK,那再加上D呢?”Lisa:“嗯.”Tom:“我觉得能完成。”Scrummaster:“有多少把握?90%?还是50%?”Lisa和Tom:“差不多90%”Scrummaster:“OK,D也加进来。那再加上E呢?”Sam:“也许吧。”Scrummaster:“90%?50%?”Sam:“差不多50%”Lisa:“我没把握。”Scrummaster:“OK,那先把它放一边去。我们要做完A、B、C和D。如果有时间的话当然还可以做完E,不过既然没人指望它能做完,所以我们不会把它算到计划里面来。现在怎么样?”所有人:“OK!”,确定如果sprint时间不长,小团队根据直觉进行估算可以收到很好的效果,举个例子：假设在上个sprint里面,由Tom,Lisa和Sam组成的3人团队在3个星期内工作了45个人-天,一共完成18个故事点。现在我们要为下一个sprint估算一下生产率。新伙计Dave的加入让情况更复杂了。把假期和新成员算上,我们在下个sprint中一共有50个人-天。实际投入真是这样吗？上一次迭代投入程度184540%新迭代的估算生产率50*40%20,故事点：StoryPoint一般大致相当于一个“理想的人天(man-day)”,什么是生产率？在一次迭代开发中能够实际投入的开发量。可投入的开发资源（人天）投入程度（focusfactor)估计速度,如果没有可参考的上一次迭代可设置一个默认投入程度：70%,怎样进行每日立会(DailyScrum),这是站立的“立”。,这是每天必做的一件重要的事情。,找一面尚未使用或者充满无用信息(如陈旧图表或者丑陋的涂鸦)的大墙。清理墙壁(除非不得已才去请求别人许可)。在墙上贴上一张很大很大的纸(至少2x2平方米,大团队需要3x2平方米),神奇的看板,UnDo:未开始做的事情,Doing:正在进行的工作,完成的工作,燃尽图,在一次Sprint结速前已经完成了所有的Backlog。可以从这里选取任务,白色标签在所有黄色标签完成后移动到Do