如何判断团队是否真正实施Scrum -- Scrum方法二十问（一） Scrum 使用者强烈推荐

<script type="text/javascript"> </script> <script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"> </script>

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。

    每个月，团队都努力实现列表最顶端的任务，这一部分是他们估计需要一个月完成的工作。他们把它展开成一个详细的任务列表，叫做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或是其他什么敏捷方法，也就是达到从心所欲不逾矩。

<script type="text/javascript"> </script> <script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"> </script>