Sprint模式

    环境

    你是一名软件开发人员或者一名管理软件开发团队的教练。在此团队中，发现、创造或者实验创新占有很高比例。你正构建或者扩展系统，允许使用清晰的接口、构件（Component）或者对象来划分工作。

    问题

    你想在开发人员不受打扰工作的需要、管理需要，以及客户要看到真实进展的需要之间进行平衡，同时还要贯穿项目始终地控制发展的方向。

    作用力（Forces）

    开发人员需要时间来不受干扰地工作，他们需要后勤支持，也需要使管理者和用户确信正取得实质性的进展。

    首先，到了系统交付的时候，产品已经过时或者需要做较大的改动。问题来源于需求信息大多数在项目开始时收集而来，而用户通过使用系统或中间的发布版本了解大部分情况。

    假设开发过程是一个被明确定义的方法，它能够进行规划和估计。如果项目失败，理所当然地认为开发过程需要更加慎密。然而，这些一步一步的方法并不起作用，因为它们不能应对人员和技术上的不可预见性。因此，由于包含很多的不确定性因素，在项目之初就做出完整的、详细的规范说明、计划或者进度是不可能的。

    过程自动化为管理人员和开发人员增加了管理工作（administrative work），常常导致开发过程和结果并不一致。项目计划展示了活动，但是却不能确保实质性进展或者结果。

    解决方案

    用Sprint划分项目。一个Sprint是大约30天的时间段，在这段时间内将执行经过协定的工作量，产生一个可交付的产品。每个Sprint完成Backlog预先分配的工作量，工作量是根据优先级和在Sprint的时间长度内能完成工作量的近似值分配的。通常，选择高内聚、低耦合的块（chunks）——或者水平的或者垂直的“包”（Packets），确切地说，就是垂直的或水平的构件。

    一般来说，在一个Sprint期间，没有从外界添加到已分配好的Sprint Backlog里的。外界所添加的只是加入到Global Backlog中。但是源自Sprint的障碍（未解决的问题）可以添加到已分配好的Sprint Bcaklog中。Sprint以一个新功能的演示作为结束（Demo After Sprint）。
 
    这就给了开发人员发挥创造力、通过探索设计空间和做出实际工作来学习的空间。不受外界干扰的影响，他们利用机会和洞察力自由调整他们的工作方法。同时，这也通过展示实质性的进展而不是以文档和报告作为进展的证据，来保持管理人员和其他的项目相关利益方的信心。

    译注：在Sprint期间，selected product backlog是保持不变的，仅在Sprint结束后进行调整。在前进过程中，团队可以在Sprint期间自主改变途径和他们工作的方法。

    最终结果是，每个Sprint都产生出一个可见的、可用的交付产品，并向用户进行展示。一个增量可能是中期的，也可能是可交付的，但是它应该是独立的。Sprint的目标是完成尽可能多的优质软件来确实质性进展，而不是用纸上里程碑（paper milestones）作为托辞。

    译注：迭代式开发，以及尽早地以可运行软件进行及时反馈，以便实时纳入用户的反馈意见的战略对软件开发产生了良好的效果。2007年Standish Group发布的报告“There’s Less Development Chaos Today”表明业界项目成功率由1994年的16.2%提高到2006年的35%。

    基本原理（Ratioanle）

  • 没有项目从外界添加到Backlog的事实使开发进展能够“全速前进”，而不需要考虑方向的改变。

  • 在Sprint期间，不对开发人员进行“测试”而是完全授权。信任开发人员完全有能力自主完成工作。

  • 开发团队可以在Sprint期间自主确定软件过程，并且能够适应变化的环境（不同的开发人员、不同的项目阶段、更多的知识等）。

  • Sprint时间间隔短，因此，完成一个Sprint的问题要比完成整个项目的问题简单得多。接受较小的挑战更容易。译注：Sprint的短迭代，往往会主动采用“治而分之”的策略，将项目大问题分解为Sprint小问题，使得容易解决问题，这样使得挑战较小，而较小的挑战容易战胜。

  • 开发人员能够经常得到反馈（在Sprint结束时）。因此，他们能够认识到项目的实际情况，而不会危及到整个项目。

  • 管理者具有完全的控制力，能够在每个Sprint结束时彻底地改变方向。

  • 最终用户通过Sprint结束时的演示，使得密切地参与到整个应用程序的开发中来，但是不允许他们干涉日常的活动。因而，所有权和方向归属于用户，但是又没有他们的持续干涉。

  • 因为Sprint产生可运行的代码，所以项目状态具有可见性的。

    已知应用

　　在Argo，Flemish教育部，自从1997年7月开始，就开始在大量最终用户项目、数据库框架开发、文档管理和工作流中使用Sprint。用持续大约一个月的Sprint来划分Backlog。在每个Sprint结束时，提交一个与所有当前应用程序集成在一起的可运行Smalltalk图像。团队每天在Scrum Meeting上碰面，并且在与规划指导委员会的每月例会演示之后，重新确定Bcklog的优先级。

    译注：Smalltalk被公认为历史上第二个面向对象的程序设计语言，和第一个真正的集成开发环境(IDE)。Smalltalk由Alan Kay，Dan Ingalls，Ted Kaehler，Adele Goldberg等于70年代初在Xerox PARC开发。Smalltalk对其它众多程序设计语言的产生起到了极大的推动作用，主要有：Objective-C，Actor，Java和Ruby等。90年代的许多软件开发思想得益于Smalltalk，例如设计模式、敏捷编程和重构等。

    应用结果

    结果是参与者得到高度的“有效所有权”（effective ownership），其中包括通过演示和确定Backlog优先级进行参与的用户。

    在Sprint结束时，对开始时所做的计划有了非常好的的估计。在评审期间，管理者有机会改变将来的计划。此时，项目是完全灵活的。目标、产品、交付日期以及成本都是可以重新定义。使用Scrum，让我们获得了大量计划之后（post-planning）的灵活性（包括客户和开发人员）。
 
    在整个Scrum期间每天例行的Scrum Meeting上，可能会发现某些团队成员把时间浪费在不具有或者较低生产力的任务上。相反，同样也可能发现人们需要比管理者最初分配的更多时间用在他们的任务上。开发人员可能表现得没有预想的那么熟练或者有经验。然而，Scrum的高可视性使我们能够处理这些问题。这是Scrum方法通过Scrum Meeting和Sprint清晰表现出来的优点。

    而将Backlog分组到Sprint的困难则揭示出管理者或者客户对于优先级还不够清楚。