【图文】scrum 简介_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
评价文档：
scrum 简介
上传于||文档简介
&&面​向​对​象​与​U​M​L​,​课​件​,​软​件​工​程
大小：1.17MB
登录百度文库，专享文档复制特权，财富值每天免费拿！
你可能喜欢JeffSutherlandJeff Sutherland的第一份工作居然是美国空军战斗机飞行员，还曾于1967年获得了“壮志凌云”称号，完成过100次飞越北部越南的作战任务。服役后期，他到斯坦福大学拿下统计学硕士学位，并在美国空军学院教授数学统计Jeff SutherlandKenSchwaberKen Schwaber最初的职业也很特别——商船经理。在随后40多年开发生涯的前10年中，他曾经编写过操作系统，搞过嵌入式，为IBM大型机开发系统软件；先后在芝加哥大学、伊利诺伊理工学院、王安公司实验室工作，并逐渐展现出在软件开发方法上的天赋。在CASE工具和结构化方法热门的时候，他自己创办了ADM公司，从事软件开发方法培训服务。期间，公司开发了软件方法自动化工具MATE，用来生成各种软件流程所需的模板、计划等，生意很好。合作经历Sutherland和Schwaber相识于1980年代早期。1987年，两人开始合作。一天，Sutherland问Schwaber：“你们开发MATE工具都用了现在流行的哪一种方法？”“当然什么都没用，”Schwaber回答，“要不然公司早就完蛋了。”他们意识到问题的严重性，开始与开发者交谈，研究新方法。1993年，Sutherland读到了两位日本管理教授竹内弘高和野中郁次郎介绍制造业里出现的新的产品开发方法Rugby（橄榄球）的文章。这种方法的特点是整个流程都由一个高性能、跨功能的团队执行到底。他受到启发，结合自己多年的经验，与Easel公司的John Scumniotales和Jeff McKenna一起开发了一套方法，取名为Scrum（来源于橄榄球术语，不是缩写）。而Schwaber则从杜邦公司一位化工过程控制专家那里取经，意识到项目分为两种：确定性项目，一切都已经确定，可以自动化生产流程；实验性项目，充满不确定性，哪怕一点微小的变化也会牵一发而动全身，因此只能用各种仪表不断监控，随时做出调整——这就是每日站会的由来。两人在一个IBM项目合作，并做了更详尽的研究，Scrum诞生了。1995年OOPSLA大会上他们第一次向世人介绍了Scrum。可当时，两个人的公司都还在做千年虫和各种重型开发方法咨询方面的业务呢。进入新世纪，互联网带来的巨变使敏捷方法受到了更多开发团队的青睐，而其中Scrum以其扩展性、门槛低、名字和术语更容易被项目经理接受等因素，逐渐成为最受欢迎的敏捷流派。而推出CSM等系列认证，虽然争议颇大，但客观上对Scrum扩大影响力起到了重要作用。今天，Scrum的影响已经远远超出软件开发，成为零售、军事、风险投资甚至学校里完成各种任务的创新方法，正在改变着世界。
Scrum过程Scrum是一个包括了一系列的实践和预定义角色的过程骨架（是一种流程、计划、模式，用于有效率地开发软件）。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。在每一次冲刺（一个15到30 天周期 ，长度由开发团队决定），开发团队创建可用的（可以随时推出）软件的一个增量。每一个冲刺所要实现的特性来自产品订单（product backlog，我觉得翻译成“产品目标”更恰当）， 产品订单（产品目标）是指按照优先级排列的需要完成的工作的概要的需求（目标）。哪些订单项（目标项目）会被加入一次冲刺，由冲刺计划会议决定。 在会议中，产品负责人告诉开发团队他需要完成产品订单中的哪些订单项。开发团队决定在下一次冲刺中他们能够承诺完成多少订单项。 在冲刺的过程中，没有人能够变更冲刺订单（sprint backlog），这意味着在一个冲刺中需求是被冻结的。管理Scrum过程有很多实施方法，从白板上的即时贴到软件包。Scrum最大的好处是它非常容易学习，而且应用Scrum不需要太多的投入。区别之一： 迭代长度的不同XP的一个Sprint的迭代长度大致为1~2周, 而Scrum的迭代长度一般为 2~ 4周.区别之二: 在迭代中, 是否允许修改需求XP在一个迭代中，如果一个User Story(用户素材, 也就是一个需求)还没有实现， 则可以考虑用另外的需求将其替换， 替换的原则是需求实现的时间量是相等的。 而Scrum是不允许这样做的，一旦迭代开工会完毕, 任何需求都不允许添加进来，并有Scrum Master严格把关，不允许开发团队受到干扰区别之三: 在迭代中，User Story是否严格按照优先级别来实现XP是务必要遵守优先级别的。 但Scrum在这点做得很灵活， 可以不按照优先级别来做，Scrum这样处理的理由是： 如果优先问题的解决者，由于其它事情耽搁，不能认领任务，那么整个进度就耽误了。 另外一个原因是，如果按优先级排序的User Story #6和#10，虽然#6优先级高，但是如果#6的实现要依赖于#10，则不得不优先做#10.区别之四:软件的实施过程中，是否采用严格的工程方法，保证进度或者质量Scrum没有对软件的整个实施过程开出工程实践的处方。要求开发者自觉保证，但XP对整个流程方法定义非常严格，规定需要采用TDD, 自动测试， 结对编程，简单设计，重构等约束团队的行为。“猪”角色猪是全身投入项目和Scrum过程的人； they are the ones with "their bacon on the line."产品负责人代表了客户的意愿。这保证了Scrum团队在做从业务角度来说正确的事情。产品负责人编写用户故事，排出优先级，并放入产品订单。Scrum主管（或促进者）Scrum主管促进Scrum过程，他的主要工作是去除那些影响团队交付冲刺目标的障碍。Scrum主管并非团队的领导（由于他们是自我组织的），而是负责屏蔽外界对开发团队的干扰。Scrum主管确保Scrum过程按照初衷使用。Scrum主管是规则的执行者。开发团队负责交付产品的团队。由5至9名具有跨职能技能的人（设计者，开发者等）组成的小团队完成实际的开发工作。。“鸡”角色鸡角色并不是实际Scrum过程的一部分，但是必须考虑他们。敏捷方法的一个重要方面是使得用户和利益相关者参与到过程中的时间。参与每一个冲刺的评审和计划，并提供反馈对于这些人来说是非常重要的。用户软件是为了某些人而创建！就像“假如森林里有一棵树倒下了，但没有人听到，那么它算发出了声音吗”，“假如软件没有被使用，那么它算是被开发出来了么？”利益所有者（客户，提供商）影响项目成功的人，只直接参与冲刺评审过程。经理为产品开发团体架起环境的那个人。
在冲刺中，每一天都会举行项目状况会议，被称为“scrum”或“每日站立会议”。每日站立会议有一些具体的指导原则：会议准时开始。对于迟到者团队常常会制定惩罚措施（例如罚款，做俯卧撑，在脖子上挂橡胶鸡玩具）欢迎所有人参加，但只有"猪"可以发言。不论团队规模大小，会议被限制在15分钟。所有出席者都应站立。（有助于保持会议简短）会议应在固定地点和每天的同一时间举行。在会议上，每个团队成员需要回答三个问题：今天你完成了哪些工作？明天你打算做什么？完成你的目标是否存在什么障碍？（Scrum主管需要记下这些障碍）每一个冲刺完成后，都会举行一次冲刺回顾会议，在会议上所有团队成员都要反思这个冲刺。举行冲刺回顾会议是为了进行持续过程改进。会议的时间限制在4小时。Scrum提倡所有团队成员坐在一起工作，进行口头交流，以及强调项目有关的规范（disciplines），这些有助于创造自我组织的团队。Scrum的一个关键原则是承认客户可以在项目过程中改变主意，变更他们的需求，而预测式和计划式的方法并不能轻易地解决这种不可预见的需求变化。同样，Scrum采用了经验方法– 承认问题无法完全理解或定义，而是关注于如何使得开发团队快速推出和响应不断出现的需求的能力最大化。
产品订单产品订单（product backlog）是整个项目的概要文档。产品订单包括所有所需特性的粗略的描述。产品订单是关于将要创建的什么产品。产品订单是开放的，每个人都可以编辑。产品订单包括粗略的估算，通常以天为单位。估算将帮助产品负责人衡量时间表和优先级（例如，如果"增加拼写检查"特性的估计需要花3天或3个月，将影响产品负责人对该特性的渴望）.冲刺订单冲刺订单（sprint backlog）是大大细化了的文档，包含团队如何实现下一个冲刺的需求的信息。任务被分解为以小时为单位，没有任务可以超过16个小时。如果一个任务超过16个小时，那么它就应该被进一步分解。冲刺订单上的任务不会被分派，而是由团队成员签名认领他们喜爱的任务。燃尽图燃尽图（burn down chart）是一个公开展示的图表，显示当前冲刺中未完成的任务数目，或在冲刺订单上未完成的订单项的数目。不要把燃尽图与挣值图相混淆。燃尽图可以使'冲刺(sprint)'平稳的复盖大部分的迭代周期，且使项目仍然在计划周期内。
以下是一些Scrum的通用实践：客户成为开发团队中的一部分。（例如客户肯定对开发的结果真正感兴趣。）和所有其他形式的敏捷软件过程一样，Scrum有频繁的包含可以工作的功能的中间可交付成果。这使得客户可以更早的得到可以工作的软件，同时使得项目可以变更项目需求以适应不断变化的需求。频繁的风险和缓解计划是由开发团队自己制定。– 在每一个阶段根据承诺进行风险缓解，监测和管理（风险分析）。计划和模块开发的透明 – 让每一个人知道谁负责什么，以及什么时候完成。频繁的进行所有相关人员会议，以跟踪项目进展 – 平衡的（发布，客户，员工，过程）仪表板更新 – 所有相关人员的变更 – 你必须拥有预警机制，例如提前了解可能的延迟或偏差。没有问题会被藏在地毯下。认识到或说出任何没有预见到的问题并不会受到惩罚。在工作场所和工作时间内必须全身心投入。– 完成更多的工作并不意味着需要工作更长时间。
虽然Scrum最初只应用于软件开发，它也可以被成功地应用于其他产业。现在Scrum通常被认为是一种用于开发任何产品或管理人和工作的迭代式的，增量的过程。用于产品开发将Scrum应用于产品开发是在《"T新新产品开发游戏"》（哈佛商业评论 6, 1986年）第一次提出，之后野中郁次郎和竹内弘高合着的《"创造知识的企业"》（牛津大学出版社，1995年）进行了详细的阐述。今天Scrum被用于开发金融产品，互联网产品，以及医药产品。项目管理方法由于市场营销通常以项目的方式运作，许多一般项目管理的原则应用在市场营销上。市场营销也可以像项目管理技术那样进行优化。以Scrum方法进行市场营销被认为有助于克服市场营销经理们所遇到的问题。短时和固定的会议对于小的市场营销团队来说很重要，这是因为团队的每一个成员都可以了解其他人在做些什么，以及整个团队在朝着什么方向前进。Scrum在市场营销中应用可以：在早期发现可能的问题，可以更快地，最小损失地应对问题。 根据Scrum的主要原则 “没有问题被扫入地毯下”，Scrum鼓励每一个团队成员描述他所遇到的困难，而这个困难可能会对整个团队的工作造成影响。降低财务风险。 在每一个冲刺周期的开始，企业所有者可以不付出任何代价的改变任何市场营销的因素：包括增加投资以夸大顾客数量，减少投资直至未知风险被减轻，或用于支持其他活动。使得市场营销计划更灵活。采用冲刺的短期市场营销计划可以更加有效。如果一种促销方法在冲刺过程中显示无效，市场营销经理有机会将其换成另一种促销方法。向每一个团队成员说明每一个小的，但重要的任务的交付时间也变得更容易。使得客户以不同的方式参与。
项目管理软件
禅道项目管理软件，也称ZenTaoPMS，是为了解决众多企业在管理过程中出现的混乱，无序的现象，开发出来的一套项目管理软件。它集产品管理、项目管理、测试管理于一身，同时包含事务管理、组织管理等诸多功能，是中小型企业项目管理的最佳选择！ZenTaoPMS基于国际流行的敏捷项目管理方式——Scrum，同时也融合了PMP中的很多概念，完美地体现了Scrum中迭代开发的精髓，很好地融合了燃尽图的概念。ZenTaoPMS基于LGPL协议，企业或者个人都可以免费获取禅道项目管理软件的源代码并安装使用，并可以结合自己的实际需要进行修改。禅道在遵循SCRUM管理方式基础上，又融入了国内研发现状的很多需求，比如bug管理，测试用例管理，发布管理，文档管理等。因此禅道不仅仅是一款scrum敏捷项目管理工具，更是一款完备的项目管理软件。基于scrum，又不局限于scrum。
为本词条添加和相关影像
互动百科的词条（含所附图片）系由网友上传，如果涉嫌侵权，请与客服联系，我们将按照法律之相关规定及时进行处理。未经许可，禁止商业网站等复制、抓取本站内容；合理使用者，请注明来源于。
登录后使用互动百科的服务，将会得到个性化的提示和帮助，还有机会和专业认证智愿者沟通。
您也可以使用以下网站账号登录：
此词条还可添加&
编辑次数：10次
参与编辑人数：10位
最近更新时间： 03:50:17
贡献光荣榜
扫描二维码用手机浏览词条
保存二维码可印刷到宣传品
扫描二维码用手机浏览词条
保存二维码可印刷到宣传品现在敏捷开发是越来越火了，人人都在谈敏捷，人人都在学习Scrum和XP...
为了不落后他人，于是我也开始学习Scrum，今天主要是对我最近阅读的相关资料，根据自己的理解，用自己的话来讲述Scrum中的各个环节，主要目的有两个，一个是进行知识的总结，另外一个是觉得网上很多学习资料的讲述方式让初学者不太容易理解；所以我决定写一篇扫盲性的博文，同时试着也与园内的朋友一起分享交流一下，希望对初学者有帮助。
&什么是敏捷开发？
敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。
怎么理解呢？首先，我们要理解它不是一门技术，它是一种开发方法，也就是一种软件开发的流程，它会指导我们用规定的环节去一步一步完成项目的开发；而这种开发方式的主要驱动核心是人；它采用的是迭代式开发；
为什么说是以人为核心？
我们大部分人都学过瀑布开发模型，它是以文档为驱动的，为什么呢？因为在瀑布的整个开发过程中，要写大量的文档，把需求文档写出来后，开发人员都是根据文档进行开发的，一切以文档为依据；而敏捷开发它只写有必要的文档，或尽量少写文档，敏捷开发注重的是人与人之间，面对面的交流，所以它强调以人为核心。
什么是迭代？
迭代是指把一个复杂且开发周期很长的开发任务，分解为很多小周期可完成的任务，这样的一个周期就是一次迭代的过程；同时每一次迭代都可以生产或开发出一个可以交付的软件产品。
关于Scrum和XP
前面说了敏捷它是一种指导思想或开发方式，但是它没有明确告诉我们到底采用什么样的流程进行开发，而Scrum和XP就是敏捷开发的具体方式了，你可以采用Scrum方式也可以采用XP方式；Scrum和XP的区别是，Scrum偏重于过程，XP则偏重于实践，但是实际中，两者是结合一起应用的，这里我主要讲Scrum。
什么是Scrum？
Scrum的英文意思是橄榄球运动的一个专业术语，表示“争球”的动作；把一个开发流程的名字取名为Scrum，我想你一定能想象出你的开发团队在开发一个项目时，大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它，你一定会感到非常兴奋的。
而Scrum就是这样的一个开发流程，运用该流程，你就能看到你团队高效的工作。
【Scrum开发流程中的三大角色】
产品负责人（Product Owner）
主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。
流程管理员（Scrum Master）
主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。
开发团队（Scrum Team）
主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到Sprint的目标。
Scrum流程图
//------------------------
下面，我们开始讲具体实施流程，但是在讲之前，我还要对一个英文单词进行讲解。
什么是Sprint？
Sprint是短距离赛跑的意思，这里面指的是一次迭代，而一次迭代的周期是1个月时间（即4个星期），也就是我们要把一次迭代的开发内容以最快的速度完成它，这个过程我们称它为Sprint。
如何进行Scrum开发？
1、我们首先需要确定一个Product Backlog（按优先顺序排列的一个产品需求列表），这个是由Product Owner 负责的；
2、Scrum Team根据Product Backlog列表，做工作量的预估和安排；
3、有了Product Backlog列表，我们需要通过 Sprint Planning Meeting（Sprint计划会议） 来从中挑选出一个Story作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一个Sprint Backlog；
4、Sprint Backlog是由Scrum Team去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量在2天内能完成）；
5、在Scrum Team完成计划会议上选出的Sprint Backlog过程中，需要进行 Daily Scrum Meeting（每日站立会议），每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的&Sprint burn down（Sprint燃尽图）；
6、做到每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本；很多人可能还没有用过自动化的每日集成，其实TFS就有这个功能，它可以支持每次有成员进行签入操作的时候，在服务器上自动获取最新版本，然后在服务器中编译，如果通过则马上再执行单元测试代码，如果也全部通过，则将该版本发布，这时一次正式的签入操作才保存到TFS中，中间有任何失败，都会用邮件通知项目管理人员；
7、当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，这时，我们要进行&Srpint Review Meeting（演示会议），也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum Team的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）；
8、最后就是&Sprint Retrospective&Meeting（回顾会议），也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中；
下面是运用Scrum开发流程中的一些场景图：
上图是一个 Product Backlog 的示例。
上图就是每日的站立会议了，参会人员可以随意姿势站立，任务看板要保证让每个人看到，当每个人发言完后，要走到任务版前更新自己的燃尽图。
任务看版包含 未完成、正在做、已完成 的工作状态，假设你今天把一个未完成的工作已经完成，那么你要把小卡片从未完成区域贴到已完成区域。
每个人的工作进度和完成情况都是公开的，如果有一个人的工作任务在某一个位置放了好几天，大家都能发现他的工作进度出现了什么问题（成员人数最好是5~7个，这样每人可以使用一种专用颜色的标签纸，一眼就可以从任务版看出谁的工作进度快，谁的工作进度慢）
&上图可不是扑克牌，它是计划纸牌，它的作用是防止项目在开发过程中，被某些人所领导。
怎么用的呢？比如A程序员开发一个功能，需要5个小时，B程序员认为只需要半小时，那他们各自取相应的牌，藏在手中，最后摊牌，如果时间差距很大，那么A和B就可以讨论A为什么要5个小时...
敏捷开发的4句宣言
个体与交互 胜过 过程与工具
可以工作的软件 胜过 面面俱到的文挡
客户协作 胜过 合同谈判
响应变化 胜过 遵循计划
阅读(...) 评论()战火中的SCRUM-读书笔记 - 研发管理当前位置:& &&&战火中的SCRUM-读书笔记战火中的SCRUM-读书笔记&&网友分享于：&&浏览：9次硝烟中的SCRUM-读书笔记
硝烟中的SCRUM-读书笔记( 13:57:11)转载标签： scrum实践 分类： IT项目管理& 产品backlog是Scrum的核心，也是一切的起源。从根本上说，它就是一个需求、或故事、或特性等组成的列表，按照重要性的级别进行了排序。它里面包含的是客户想要的东西，并用客户的术语加以描述。我们叫它故事（story），有时候也叫做 backlog条目。 注：对于产品backlog的理解不应该仅仅停留在用户故事层面，产品backlog本身来源于用户故事，体现的是用户能够感知的业务场景。但是产品backlog本身包含了更多的信息，包括优先级，估算，How to Demo(作为测试用例的原型)。产品backlog是有优先级，估算和初步测试的业务场景驱动的需求结合。是后面形成Sprint迭代计划的基础。产品backlog最好的方式就是借助于Excel进行收集，分类和整理。 Sprint计划会议非常关键，应该算是 Scrum中最重要的活动（这当然是我的主观意见）。要是它执行的不好，整个 sprint 甚至都会被毁掉。 举办 Sprint计划会议，是为了让团队获得足够的信息，能够在几个星期内不受干扰地工作，也是为了让产品负责人能对此有充分的信心。这么说可能比较模糊。其实，Sprint 计划会议会产生一些实实在在的成果：sprint 目标。& 团队成员名单（以及他们的投入程度，如果不是 100%的话）。& sprint backlog（即 sprint 中包括的故事列表）。& 确定好 sprint 演示日期。& 确定好时间地点，供举行每日 scrum会议。
注： 在SCRUM中有三个重要的会议，迭代计划会议(Sprint Planning Meeting)；每日晨会(Daily Scrum Meeting)和迭代回顾会议(Sprint Review Meeting)。Sprint计划就是SCRUM中最核心的计划，是大型IT项目管理中的项目主计划的精炼，对于初步优先级和估算已经前置到产品backlog了，Sprint 计划重点就变成了真正迭代周期，迭代故事列表的确定。变成了工作量，优先级，质量和进度这些重要因素的权衡。SCRUM的一个重要角色产品负责人(Product Owner)必须参加Sprint计划会议，以确认目标，优先级和范围。 为什么不能在质量上让步？我尽力把内部质量和外部质量分开。一般来说，系统内部质量优秀，外部质量仍有可能很差。而内部质量差的系统，外部质量肯定也不怎么样。松散的沙滩上怎么可能建起精美的楼阁？ 外部质量是系统用户可以感知的。运行缓慢、让人迷糊的用户界面就属于外部质量低劣。& 内部质量一般指用户看不到的要素，它们对系统的可维护性有深远影响。可维护性包括系统设计的一致性、测试覆盖率、代码可读性和重构等等。
注：质量的问题首先要意识到质量包括了外部质量和内部质量。不能因为进度和多做功能点而牺牲了质量，在SCRUM实践中我们没有看到太多的关于代码质量的实践内容，类似CodeReview，前期通用约定。但是我们看到了技术性工作的内容，对于公用性技术工作的内容书里面建议仍然是放到一个具体的业务场景驱动的故事后面。但是产品Backlog直接驱动的Sprint计划，架构设计方面的内容还是需要落地来做。特别是当存在多个Sprint迭代版本的时候，更需要关注总体设计和架构的介入点。(试着避免技术故事。努力找到一种方式，把技术故事变成可以衡量业务价值的普通故事。这样有助于产品负责人做出正确的权衡。) 在 sprint计划会议之前先为它初步制定一个时间表，可以减少打破时间盒的风险。下面来看一下我们用到的一个典型的时间表。这个日程绝不是强制执行的。Scrum master 根据会议进程的需要，可以对各个阶段的子进程时间安排进行调整。 13:00-13:30。产品负责人对 sprint 目标进行介绍，概括产品 backlog。定下演示的时间地点。 13:30-15:00。团队估算时间，在必要的情况下拆分 backlog条目。产品负责人在必要时修改重要性评分。理清每个条目的含义。所有重要性高的 backlog 条目都要填写“如何演示”。 15:00-16:00。团队选择要放入 sprint 中的故事。计算生产率，用作核查工作安排的基础。 16:00-17:00。为每日 scrum会议（以下简称每日例会）安排固定的时间地点（如果和上次不同的话）。把故事进一步拆分成任务。
注：sprint计划的另外一个重要任务就是，将产品Backlog里面的用户故事拆分到开发人员理解的任务层面。任务是SCRUM在开发阶段管理的最小单位。在这里又不得不返回考虑产品Backlog里面用户故事的粒度。我们对用户故事的理解应该是一个用户可以理解的一个可以独立实现用户价值的最小活动和行为。如果按照一个sprint的迭代周期为一个月来看，一个故事的工作量应该在1人周内，一个任务的工作量应该在1-3人天左右。注意用户故事和任务本身的粒度和规模，否则后续的Sprint进度跟踪中重要的燃尽图(BurnDown Chart)将没有意义。故事是可以交付的东西，是产品负责人所关心的。任务是不可交付的东西，产品负责人对它也不关心。 有一点很重要：产品负责人和团队需要对“完成”有一致的定义。所有代码被 check in 以后，故事就算完成了吗？还是被部署到测试环境中，经过集成测试组的验证以后才算完成？我们尽可能使用这样的定义：“随时可以上线”，不过有时候我们也这样说：“已经部署到测试服务器上，准备进行验收测试”。 最开始我们用的是比较详细的检查列表。现在我们常说“如果Scrum团队中的测试人员说可以，那这个故事就算完成了”。然后责任就到了测试人员身上，他需要保证团队理解了产品负责人的意图，要保证故事的“完成”情况可以符合大家认可的定义。 我们曾经尝试过用多种形式来保存 sprint backlog，包括 Jira、 Excel，还有挂在墙上的任务板。开始我们主要使用 Excel，有很多公开的Excel 模板可以用来管理 sprint backlog——包括自动生成的燃尽图等等。在如何改良基于 Excel 的 sprint backlog 方面，我有很多想法，但此处暂且不提，我也不会在这里举例。下面要仔细描述的，是我们发现管理 sprint backlog 最有效的形式——挂在墙上的任务板！
注：SCRUM中的燃尽图是项目管理中的挣值曲线图的简化，通过燃尽图可以看到整个Sprint的生产率情况，当前我们的进度是提前了还是落后了？以分析和评估风险，调整Sprint中的用户故事列表。SCRUM中上图的进度跟踪看板是一种很重要的可视化项目管理方式。 只要让他们坐到一起，就会有立竿见影的成效。过上一个 sprint，团队就会认为挪到一起是绝妙的主意，“一起”意味着：互相听到：所有人都可以彼此交谈，不必大声喊，不必离开座位。 互相看到：所有人都可以看到彼此，都能看到任务板—不用非得近到可以看清楚内容，但至少可以看到个大概。 隔离：如果你们整个团队突然站起来，自发形成一个激烈的设计讨论，团队外的任何人都不会被打扰到。反之亦然。&& “隔离”并不是意味着这个团队需要被完全隔离起来。在一个格子间的环境中，如果你的团队拥有自己的格子，而且隔间的墙足够大，可以屏蔽墙内外的大多数噪音，这也就足够了。转自 .cn/s/blog_493ahp.html
12345678910
12345678910
12345678910 上一篇：下一篇：文章评论相关解决方案 12345678910 Copyright & &&版权所有