scrum经验

时间:2021-12-05 23:18:24

Scrum是基于过程控制理论的经验方法,倡导自组织团队;其运行框架核心是迭代增量型并行开发,也是“适应性”的软件开发方法。Scrum提供了高度可视化的用于管理软件开发复杂性管理的敏捷项目管理的实践框架或敏捷过程,可以用于对现存软件工程实践的包装,提高软件生产率,改善沟通和合作的方法,使人们协作并注重业务目标。现在Scrum已被众多的软件企业使用,其中不乏有业界知名企业,如Microsoft 、IBM、Google和Nokia等。

作为一名Scrum教练,笔者经常被问到有关Scrum实施以及敏捷开发方面的各类问题,现总结如下,供对此方法有兴趣和有疑问的读者参考。

一问:Scrum的核心特征是什么? 


    一答:基于功能开发而组成的多功能、自组织团队;高度柔性的可视化敏捷项目管理自适应框架;以及支持增量并行开发的30天时间盒迭代。

二问:哪类项目可以使用Scrum? 


    二答:最初Scrum使用于需求难以预测的复杂商务应用产品的开发,但经过10多年的发展,它被应用于所有领域的软件中,从生命攸关的软件到更为随意的软件,都可以使用Scrum。在使用Scrum时,无需讨论工件是什么以及它们的数量,而是讨论需要严谨到什么程度。作为一个指导原则,由整个Scrum团队来决定正规性的程度,并尽可能地低。当然,这需要有丰富的实践经验来判断。

三问:Scrum团队一定是7个人吗? 


    三答:在Scrum中有3个基本的角色:产品所有者Product Owner、开发团队Development Team和ScrumMaster。Scrum团队通常有5~9个成员,典型一个Scrum团队应当有7个成员。但可以由多个团队完成一个项目,即使用Scrum of Scrums实践规则进行拓展项目团队规模:每一个Scrum Team同样有一个代表,通常是Scrum Master,参与Scrum of Scrums会议协调多个Scrum Teams的工作,这些会议类似于Daily Scrum Meeting,但每周召开一次。

四问:看上去Scrum非常简单,可以给我们更简化地总结一下吗? 


    四答:是的,Scrum看上去确实很简单,可以把Scrum总结得非常简单:

团队和项目出资人创建一个团队需要做的所有事情的列表。这可以是一个任务的列表或者特性的列表。这就是Product Backlog。

每个月,团队都努力实现列表最顶端的任务,这一部分是他们估计需要一个月完成的工作。他们把它展开成一个详细的任务列表,叫做Sprint Backlog。这个团队承诺在月底向出资人演示或交付结果。

每天,团队都面对面地开5~10分钟的会,彼此更新各自的状态和排除使他们减慢的路障。这个叫Daily stand-up meeting。

指定一个特别的人担任Scrum Master,这个人的任务是排除或安排别人排除在例会上这个团队提到的任何路障。

但是它的实践执行并不简单,需要获得关键的自适应和坚持Scrum核心价值观——承诺、专注、公开、敬重和勇气。

五问:我们认为,坚守一定的Scrum Meeting模式是必要的;但是执行一段时间后觉得很困难,有些人甚至觉得“恶心”,你对此怎么看? 


    五答:每天举行15~20分钟左右的Scrum meeting是Scrum和项目的心脏。如果出现这一问题,我估计是软件团队倾向于在现有的项目管理方法下诠释Scrum,没有充分理解自我管理、涌现机制、可视性和评估/适应循环的根本原则。

按照“定义的”参考框架去执行Scrum的实践,忽视了从控制转向授权、从命令转向协作,Scrum Master很可能将“自上次Scrum Meeting会后的一天里我做了什么?”理解为“检查团队成员是否完成上次Scrum Meeting中他所布置的任务”,将“从现在到下次Scrum Meeting的一天我将做什么”理解为“告诉团队人员从现在到下次Scrum Meeting的一天应做什么”,将“在工作中遇到了哪些障碍”理解为“他将审核是否能帮助团队完成目标”。而团队成员把Scrum Meeting理解为按顺序报告工作情况的会议。

坚持以下7个基本原则,将有利于有效执行Scrum Meeting:

1 团队信仰自我管理和支持自我管理。

2 他们作为团队共同承诺Sprint目标。

3 他们认识到沟通的重要性,并且通过Daily Scrum Meeting推动沟通。

4 他们理解和拥抱贯穿整个Sprint周期的必要的日常任务变更,相互依赖的会议规则,每日会议允许团队成员管理和响应变化。

5 团队有一位卓有成效的Scrum Master或得到他们授权的领导来决策和问责。

6 团队认为工作可视化很重要,透明改进团队和组织其他团队之间的关系,从而得到更高层次的信任和协作。

7 团队将Daily Scrum Meeting回顾与其他里程碑相联系使会议尽可能有效。

六问:用什么来判断软件团队在真正实施Scrum? 


    六答:对这一问题,Scrum创始人之一Jeff Sutherland用诺基亚测试的8个判断条件来判定是否在真正执行Scrum。这8个判断条件是:

1 你们有固定的迭代周期么?你们的迭代周期是否以某个特定的时间开始并以某个固定的时间结束,且迭代周期必须少于6周?(回答否定的则不符合迭代开发原则)

2 在每个迭代周期结束时,你们能提供可以工作的软件么?(回答否定的则不符合迭代开发原则)

3 在迭代开始之前,你们是否需要必须有一个完整细致的需求说明?(回答肯定的则不符合迭代开发原则)

4 是否将测试作为迭代增量开发的一部分,在开发过程中进行测试?(回答否定的则不符合迭代开发原则)

接下来,用4个附加的Scrum规则来判断是否实现了Scrum:

1 你们是否有产品所有者?是不是有人可以代表客户和你们一起工作?

2 如果有产品所有者的话,他们是否能提供待开发的产品Backlog?且此产品Backlog是否按照优先级来排序的?是否估算过开发这些功能的所需时间?

3 团队在开发过程中是否使用了Burndown图来展示工作量变化、跟踪进度、推算团队开发速度?

4 在迭代过程中,是否能保证项目经理不干涉团队工作?

通过以上8点基本上就可以确定,团队是否真正地实现了Scrum。

七问:在Scrum中我怎样去度量团队绩效? 


    七答:你可以通过速度去度量团队绩效,即在一个Sprint中将需求转化为软件功能的能力。可以是一个Sprint中完成多少Product Backlog Item(包括功能和非功能需求及其他议题),或者转化为1个合适单位货币如10000完成多少Product Backlog Item。

八问:在Scrum中我怎样去度量个人绩效? 


    八答:你不能度量个人绩效,只能度量整个Scrum团队的绩效。Scrum是自我管理的团队,而不是个人组成的组。当然,可能你的软件组织要求这么做,这确实是个棘手的问题,我也没有好的解决方案。对于软件组织这一层面,我建议你首先把度量的焦点聚焦于你生产的软件、真正的开发功能和软件组织用于改进基准和市场价值的能力。而项目这一级别,我建议将完整的个人检查过程简化为3个问题:你对增加组织的价值有什么帮助?你做了什么使客户高兴?你的同事怎么看待你?可以请同事来评估个人贡献,并列出1~10的等级。在Daily Scrum Meeting上,你可以看到谁有贡献,谁没有。

九问:在Sprint期间,如何去修改一个缺陷? 


    九答:Scrum团队的目标之一是在发现缺陷的Sprint中就修复它们。在他们逐渐精通采用30天迭代周期以后,尤其是通过对自动化测试的利用,他们能够达到这个目标。当Scrumt团队成员做出对某项编码任务的估计时,这个估计值就包含了用于修复在实现过程中发现的缺陷的时间,否则就应该确定和估计一个独立的任务(“修复缺陷”)即缺陷作为Product Backlog Item处理。我的偏好是只确定一项任务,但是在它通过所有的测试之前不认为已经完成。

后来发现的(或者在发现它的迭代中没有修复 的)缺陷应该按照与Product Backlog一样的方法来对待。应该按照与Product Backlog一样的方法确定缺陷修复工作的优先级,分配到后续的某次迭代中。只要超出一次迭代的范围,就不再有什么缺陷的概念。修复一个缺陷和增加一个功能只是一件事的两种说法。另外,如果现有团队还需要维护现有产品时,则需要提醒软件团队在做计划时拿出专门的时间处理那种需要马上响应的缺陷修改任务。

十问:Scrum的局限性是什么,实施中需要注意什么? 


    十答:我们都知道Scrum只是一种敏捷管理的一种实践框架(Framework),任何方法都有其边界和局限性,套用业界流行的一个说法就是“没有银弹”。Scrum为软件开发管理只定义了一个高层次的、易于操作与遵循的非常小的实践集,Scrum避免了说软件团队应该如何开发软件,它坚持认为:人们在自己的工作中和处理问题时,应该像一个成熟的成年人一样,因此它并不涉及具体的软件开发技术和人员沟通、期望管理、问题冲突等管理技能,这些都需要其他相关理论和技能来补充,另外,如同其他项目一样,需要软件团队在其业务领域的专业能力来确保软件项目的成功。

Scrum源于美国软件界,对国内实施强调自组织管理的Scrum需要破除可能习惯于听命行事的组织环境,建立自我约束、自我组织和实现的工作管理方式和组织环境,同时根据Scrum背后的科学原理则可以根据特定的情形进行调整。建议最初时,按Scrum提供的实践框架执行,然后,当积累了丰富实践经验后再根据Scrum提供的避免做什么的说明视实际情形进行调整,到最后,不要在乎自己是否执行Scrum或是其他什么敏捷方法,也就是达到从心所欲不逾矩。

十一问:Scrum中如何看待文档,或是对待写文档的问题有何建议? 


    十一答:这一问题屡屡被提及的是有着非常现实背景,软件组织或软件项目都需要一些软件文档,而在Scrum中没有规定具体的做法。我认为软件文档主要的作用在于理解、沟通和管理要构建的软件,需要交付给用户和软件组织为了方便维护软件和知识产权方面考虑用作保存和传递知识的作用,特殊软件需要满足法律法规的要求。

因此,第一、是否需要文档,标准是该文档是否增值,坚持精益原则,消除不必要的浪费,比如如果设计人员和专家坐在一起,就可以免去设计文档,而是在白板上粗略地勾勒草图,然后用照片记录白板上的图或用可打印的白板将其打印出来。第二,假设该文档只是符合规定(法律、审计或是客户等其他原因的强制需求)的需要,则可以考虑安排部分项目时间交给非核心人员编写文档,避免影响软件开发核心工作的开展。第三,对于理解和沟通所要构建软件的关键文档,原则上用自动化的代码文档工具如Doxygen、JavaDoc或NDoc等,在必要时产生符合代码标准的自解释的源代码文档,并创建自文档化的软件UML图模型。另外,用简明扼要的1~2页的软件架构文档,描述软件的架构,为新来的开发者表示出关键构件和接口。第四,不要奢求需求是完美的,设计文档能够与代码同步更新,或项目计划与项目状态完全匹配,需求文档能够满足后续开发需要即可,总之,软件文档符合精益(Lean)、易理解(Mean)和足够(Enough)的要求,确信在当前环境能够严格地保证沟通需要。还有一个有趣的现象是技术人员基本上都讨厌写文档,但需要指出的是编写精益易理解足够的文档也是职业软件开发者的一项基本功,当然同时,也要避免为了文档而文档,它意味着用于项目的每个文档都应该证明是对项目有意义的。

十二问:Scrum与流行的RUP有什么异同? 


    十二答:这个问题网上好象有专文论述,这里根据我的自己的实践体会简单地说一下,Scrum与RUP都强调需求导向、迭代增量开发和风险驱动,两者可以结合使用。Scrum与RUP的侧重点不同,其中一个表现Scrum反对预定义的过程和预见性的步骤,RUP会有一些可选的但又需要预先定义的活动,如与需求分析、测试等相关的活动,并有先后顺序。需求管理方面Scrum由Product owner管理,RUP则由需求工程师管理;可视化建模方面,scrum团队自定,通常进行敏捷建模,RUP倡导可视化建模;软件体系结构方面,Scrum软件组织或团队自定,RUP则由软件体系中心确定;迭代周期方面,Scrum迭代周期推荐30天,RUP推荐2~6周。

十三问:一提起敏捷方法,为什么通常将Scrum与XP一并谈论? 


    十三答:这大概是XP与Scrum是敏捷方法中被业界采用最为广泛的原因吧。另外,一个值得注意的原因是两者都聚焦于信息价值流和信息沟通,除了迭代长度稍有差别外,大多数Scrum实践与XP是兼容且相互补充,Scrum侧重于项目管理和人,XP有许多工程技术实践,两者相得宜彰。Scrum这种强调项目管理价值与实践而不在乎需求、实现等工程技术用作其他软件开发方法包装器的特征,具有高度适应性和柔性是其他敏捷方法不具有的,因此,它很容易与其他方法进行组合,或者作为其他方法的补充,这一点不是它的弱点,而应当看作其长处。

十四问:我们公司采用CMM/CMMI进行软件过程改进,是否适合实施Scrum? 


    十四答:CMM/CMMI与Scrum或敏捷方法之间的关系是常常被人们关心或经常提起的一个有趣的话题。2002年Scrum创始人 各级ken Schwaber与美国卡内基。梅隆大学软件工程研究所SEI的Paulk Mark曾经评估Scrum如何实现CMM的关键过程域,结论是Scrum实践规则可以满足CMM2级全部和CMM3即的大部分关键过程域。事实上,国内外都有利用Scrum通过CMM/CMMI评估的案例。

通常认为CMM/CMMI之间的区别在于:关注目标不同,CMM/CMMI关注组织级,Scrum关注项目级;基础假设不同,CMM/CMMI假设软件开发可预测与可重复,符合统计过程控制,优化放在最后,Scrum假设软件开发是自适应,高度复杂,需要基于过程控制理论的经验方法,优化一开始就进行。

业界有一个流行观点是将Scrum纳入到一个已经通过CMM/CMMI 3或更高级别评估的组织,看起来比将一个Scrum项目改为CMMI更简单。同时,一些实施Scrum或其他敏捷方法的软件组织对CMMI评估没有兴趣,把CMMI评估看作浪费金钱,也就是说,他们不需要CMMI评估来获得合同,但获得这一评估却需要耗费金钱和时间,我的看法是在现实商业环境中的软件组织是否需要组合CMM/CMMI和Scrum主要不在于理论或其背后的软件哲学理念,而在于业务运作环境所需考虑的优先级。假设您需要组合两者并有通过CMMI评估需要,关键在于找到一个理解如何灵活使用CMMI模型又理解Scrum的CMMI主任评估师。

十五问:如何引入和执行Scrum? 


    十五答:对于第一个项目建议在一个有执行Scrum经验丰富的专家指导下进行。在试点项目的选择上Scrum的创始人鼓励选择最为困难和关键的项目,我个人建议是如果试点项目团队有强烈意愿并获得高层支持是完全可以的。否则,试点项目应该是构建真实的、具有合理的、客观的商业目标的软件,团队规模6~8人为宜,以避免一开始就使用Scrum of Scrums,项目长度通常2~6个月为宜。在项目启动后,外部的项目管理者和潜在使用Scrum的可以邀请其观摩Daily Scrum Meeting、Sprint Planning Meeting 、Sprint Review Meeting和Sprint Retrospective Meeting。最终,Scrum的实践扩展至软件组织的最高层,每一层都基于团队,高层管理者每月组织一次Scrum meeting就可以了。

十六问:Scrum的迭代Sprint周期一定是30天吗? 


    十六答:Scrum的目标是在一系列(3~8个)短期的时间框(time box)内交付尽可能多的优质软件。其中时间框被(固定时间间隔)称为Sprint,典型地,其将持续大约一个月30天的时间。但在许多公司已缩短至两个2周或更短。我建议刚开始实施Scrum时Sprint周期最好固定为30天,随着经验积累可以根据实际进行调整期Spint周期为2~4周。

十七问:Sprint的长度取决于哪些因素? 


    十七答:绝大多数的迭代增量开发方法推荐1~6周的长度。Scrum推荐其迭代Sprint的长度为30天。确实需要调整时,考虑发布的总时间长度、不确定性的多少、获得反馈的难易、优先级可以保持多久不变时间长度、迭代系统开销、紧迫感产生有多快等因素。这里需要特别指出的是国内有企业一开始就执行2周为Sprint周期的企业,因为其执行短周期迭代开发的基础设施(如软件配置管理和自动化测试的基本实践不扎实)不到位而导致退化为瀑布开发的案例。

十八问:导致Scrum项目失败的主要原因是什么? 


    十八答:导致失败的主要原因是软件团队不是自组织团队,团队由项目经理或Scrum Master进行指导和组织。其次,Product Owner或客户不参与每次迭代,不进行需求优先级划分,不参与每次演示,并且不为下一迭代选择具有最高商业价值的项。另外,在迭代期内给团队成员追加新的需求或额外的任务。

十九问:您如何看待Scrum Master认证培训? 


    十九答:敏捷联盟推出Scrum Master认证培训即Scrum Certified Master,事实上其敏捷联盟内部对此也有一些争论。我个人认为您如果有机会参加由那些真正理解Scrum的人负责的为期2天的培训自然是件好事。但我认为把它叫做“认证”会带来一些错误的认识,比如国内外都有参加了Scrum认证后就认为自己是Scrum Certified Master,然后在软件组织内执行Scrum最后导致失败的案例。要真正达到通常意义上的认证,至少你必须进入软件团队,用Scrum工作方式几个月的实践才行,倘若没有任何软件开发经历和理解Scrum背后的哲学体系,仅是接受2天的培训而去推广Scrum,后果不堪设想。另外,如果纯粹为了就业或是获得证书什么的,我认为没有必要参加目前还相对昂贵的认证培训,看看类似的认证培训效用就可以知道了。相信任何理性的软件组织都更看重的是实践能力而非仅仅通过2天培训换来的一纸证书。在这里我特别声明我并不反对任何人任何时候参加任何机构举办的Scrum Master认证培训。

二十问:对于刚刚学习和实施Scrum者有没有可以推荐的读物? 


    二十答:书籍方面目前主要有由Scrum创始人Ken Schwaber主笔的三本书:《Agile Software Development with Scrum》、《Agile Project Management with Scrum》和《The Enterprise and Scrum》。其中《Agile Software Development with Scrum》还得到了Beedle和Sutherland的协助,国内出了影印版中文名为《敏捷软件开发——使用Scrum过程》。《Agile Project Management with Scrum》出了中文版,中文名为《Scrum 敏捷项目管理》,《The Enterprise and Scrum》也已引入英文版。另外著名技术网站infoQ有2本迷你书。我个人倾向推荐《Agile Software Development with Scrum》。

此外,我个人认为在精力和时间允许的情况下最好对Scrum产生重大影响的一些书籍和文章进行研读,这样可以更深入理解Scrum和领悟其自适应与自组织的精髓。

scrum经验的更多相关文章

  1. Scrum Guide - Scrum指南中文版

    现在公司在使用敏捷开发模式进行日常的开发和管理工作,所以我看了下Ken Schwaber的<Scrum Guide>这本小册子,原本是英文的,这里提供中文的,以供日后复习和参考. Scru ...

  2. CSM&lpar;Certified Scrum Master&rpar; 敏捷认证是什么?

    Scrum 是用于开发和持续支持复杂产品的一个框架.Scrum 基于试验性过程控制理论,借鉴了精益思想.时间盒.模块化设计等,并完整地体现了敏捷宣言和敏捷原则.Scrum 采用一种迭代.增量式的方法来 ...

  3. Scrum转型&lpar;二&rpar; Scrum的角色

    1.1 ScurmMaster 作为Scrum流程的*和布道者,ScrumMaster在Scrum团队中起到至关重要的作用,他们确保团队使用正确的流程,确保团队正确地召开各种会议,他们训练团队的敏 ...

  4. Sprint评审会议不是Sprint演示会议

    最近,Innolution公司的执行总监.Essential Scrum的作者Ken Rubin在其公司博客上撰写了一篇题为It’s a Sprint Review Not a Sprint Demo ...

  5. 《硝烟中的Scrum和XP》:作者主导Scrum过程的实战经验,四星推荐

    本书作者是开发团队Leader,本书记录了他带领团队实施Scurm过程中的经验教训.全书短小精悍,言简意赅. 以下是书中一些观点信息的摘抄: 1:Nokia总结出的迭代开发的基本要求:1.1:迭代要有 ...

  6. Scrum立会报告&plus;燃尽图(十月十六日总第七次):总结工作经验,商讨未来策略

    此作业要求参见:https://edu.cnblogs.com/campus/nenu/2018fall/homework/2197 Scrum立会master:李文涛 一.小组介绍 组长:付佳 组员 ...

  7. 敏捷测试模式之Scrum及其实践

    一.    敏捷开发模式简介 敏捷是近年来软件研发领域很火的一个词,采用敏捷开发模式的研发团队是越来越多了,尤其是敏捷模式中的Scrum更是佼佼者大行其道,这表明敏捷模式确有其好处,能给企业带来效率的 ...

  8. 软件工程的引入:Scrum开发框架总结

    俗话说,自己写的代码,6个月后也是别人的代码……复习!复习!复习!涉及的知识点如下: 软件工程概念 敏捷开发过程scrum 一.什么是软件工程?请用一句话描述. 软件工程是一门研究性的学科:它用工程化 ...

  9. SOA架构设计经验分享—架构、职责、数据一致性

    阅读目录: 1.背景介绍 2.SOA的架构层次 2.1.应用服务(原子服务) 2.2.组合服务 2.3.业务服务(编排服务) 3.SOA化的重构 3.1.保留服务空间,为了将来服务的组合 4.运用DD ...

随机推荐

  1. pc端与移动端的区别

    移动设备和PC本身有区别: 1.屏幕尺寸不同,屏幕大小导致显示的内容页不一样. 2.网络速度不同:手机分2G.3G.4G.WIFI等,我们要少用图片,JS.动画等等,用户打不开一样起不了作用. 3.使 ...

  2. jmeter 中的 Beanshell 使用

    一.操作变量:通过使内置对象vars可以对变量进行存取操作 a) vars.get("name"):从jmeter中获得变量值 b) vars.put("key&quot ...

  3. ASP&period;Net的导出Excel的快速方法,DataTable导出Excel(亲测,非原创)

    //使用方法 ExcelHelper.dataTableToCsv(dt,@"D:\1212.xls");System.Diagnostics.Process.Start(@&qu ...

  4. 在虚拟机安装64位系统提示&comma;此主机支持Intel VT-x&comma;但Intel VT-x处于禁用状态

    进入BIOS - Security - Virtualization - Intel (R) Virtualization Technology 将 Disabled 改为 Enabled 即可

  5. 基于GBT28181:SIP协议组件开发-----------第一篇环境搭建

    原创文章,引用请保证原文完整性,尊重作者劳动,原文地址http://www.cnblogs.com/qq1269122125/p/3930018.html,qq:1269122125. SIP协议在安 ...

  6. 如何给sublime text3安装汉化包?so easy 哦

    这是我本人亲身测试过的,肯定有效,没用的话怪我咯. 首先安装package control,然后安装汉化包即可,很简单哦!!! 1.安装package control:打开sublime,使用快捷键: ...

  7. 从Nest到Nesk -- 模块化Node框架的实践

    文: 达孚(沪江Web前端架构师) 本文原创,转至沪江技术 首先上一下项目地址(:>): Nest:https://github.com/nestjs/nest Nesk:https://git ...

  8. 关于return的一些了解

    写return是一种清晰的风格,可以防止一些意外的错误. 所以书上只说应该写,而不是必须写. 如果符合某个条件要退出的话,可以用return返回,否则可以不写这句代码的,当程序执行到"}&q ...

  9. golang 关于 interface 的学习整理

    Golang-interface(四 反射) go语言学习-reflect反射理解和简单使用 为什么在Go语言中要慎用interface{} golang将interface{}转换为struct g ...

  10. Python初次实现MapReduce——WordCount

    前言 Hadoop 本身是用 Java 开发的,所以之前的MapReduce代码小练都是由Java代码编写,但是通过Hadoop Streaming,我们可以使用任意语言来编写程序,让Hadoop 运 ...