如何判断团队是否真正实施Scrum

     Scrum 作为敏捷方法之一，在十多年前由 Ken Schwaber 和 Jeff Sutherland 共同提出，名称来自英式橄榄球，用 Scrum 来类比软件团队在软件开发所展示出来的速度和灵活性。（在橄榄球比赛规则中， Scrum 的目的是在有轻微违规或比赛暂停后，使比赛迅速、安全、公平地重新开始。当球队在场地上以整体队形向前推进时，每个球员都时刻保持对场上全局的判断，橄榄球在队员之间相互传递，奋力实现胜利。）

 

    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 。

 

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

 

    每天，团队都面对面地开 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 、 SprintReview Meeting 和 Sprint Retrospective Meeting 。最终， Scrum 的实践扩展至软件组织的最高层，每一层都基于团队，高层管理者每月组织一次 Scrum meeting 就可以了。

 

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

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

 

    十八问：导致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和领悟其自适应与自组织的精髓。如被誉为世界知识管理运动之父的Takeuchi和Nonaka的原创性文章《The New New Product Development Game》和知识管理三部曲之一的《The Knowledge-Creating Company》（中文版名为《创造知识的企业》）、遗传算法之父和复杂性新科学的先驱者之一Holland的《Hidden Order》（中文版名为《隐秩序》）和《Emergence》（中文版名为《涌现》）。

 

转自：http://tech.it168.com/a2008/1016/208/000000208175.shtml

 

评论

1 楼 samana 2009-06-03  

The Nokia Test
One of the most popular methods to understand if a team is doing SCRUM or not is through the use of what is called “Nokia Test”. It is a very simple yet very strict test and almost 80% of teams who claim to be doing SCRUM do not pass even Level 1. Here is an overview of the test:
LEVEL 1
Iterations must be time-boxed to less than six weeks / Do your sprints start and end on planned dates
Is the software completely tested and working at the end of an iteration
Can the iteration start before specification is complete
LEVEL 2
Does the team know who the product owner is
Is there a product backlog prioritized by business value
Does the product backlog have estimates created by the team
Does the team generate its burndown charts and knows its velocity
Does the team have outside people disrupting the work of the team during the sprint


http://www.agilecollab.com/the-nokia-test