30 天内开发出软件

30天内开发出软件

作者/Ken Schwaber & Jeff Sutherland

Ken Schwaber

软件开发专业人士,在过去40年的职业生涯中,曾担任过程序员、分析师、咨询师、产品经理,还做过企业家。一直致力于发展Scrum,并帮助世界各地的机构使用Scrum。他是“敏捷宣言”最早的签署人之一,也是敏捷联盟和Scrum联盟的创始人,目前正努力通过Scrum.org来改善整个软件行业。

Jeff Sutherland

马萨诸塞州剑桥市Scrum Inc.的首席执行官,专门为世界各地的公司提供培训、咨询和辅导服务。同时也是波士顿风险投资公司OpenView Venture Partners的高级顾问,帮助所投资的公司实施Scrum和敏捷实践。多年来,Jeff已在众多软件公司和信息技术机构推广和提升Scrum。

无论是商业组织、政府机构,还是非营利组织,都可能需要通过开发、定制和使用软件来创造价值。假如没有软件的帮助,作为商业领导者,你很难甚至无法实现自己设定的业务目标。尽管软件如此有用,但是一直以来,软件开发都广受诟病,被认为不可靠、高成本、易出错。1这就使你陷入了一个两难的境地:你需要软件,但无法及时得到成本可接受、质量又可靠的可用软件。

12005年4月11日的弗雷斯特报告“企业软件开发无法满足速度和质量需求”指出,企业软件开发公司仍然让人失望:弗雷斯特在2004年秋季的一项调查表明,将近三分之一的受访对象对软件供应商交付定制软件的时间不满意,相同比例的受访对象对最终交付的软件质量感到失望,五分之一的受访对象对软件质量和交付时间都不满意。该调查的692位受访对象均为在IT领域具有影响力、掌控财政大权的人士。

实际上,斯坦迪什组织(Standish Group)在2011年的CHAOS报告中指出,2002年至2010年期间,超过半数的软件项目都被评定为存在缺陷或者是彻底失败,只有37%的项目是成功的(如图所示)。斯坦迪什组织对成功项目的保守定义是:能够按照既定的预算,在承诺的期限之内交付所有需要的功能。而软件适应变化的能力、管理风险的能力以及软件的固有价值均未纳入评估范畴。

{%}

图 传统软件开发存在风险

软件项目的成功率如此之低,你很可能会为那些牵涉到软件开发的重要项目忧心忡忡。软件行业耗时、成本高,又不可预期,早已让你大失所望。如果不是软件那么重要的话,你很可能早就停止在软件上的投资了。

不过,面对这些问题的并不只有你一个,很多机构都有同样的困扰。例如,联邦调查局(FBI)的“哨兵”(Sentinel)项目最近也遇上了麻烦。结果,他们运用Scrum的理念和流程,使项目起死回生。

这里关于“哨兵”项目的资料均来自美国司法部的检察长报告,并且对外公开。如果你认为这只是一个基于政府工作特性的个案,不具有普遍性,那么试想一下:如果一个庞大的政府机构都可以这样彻底地改进软件的开发方式,你的组织同样可以做到。

FBI的“哨兵”项目

FBI针对每一项调查都建立一份档案,其中包含所有创建或者调用的调查记录。2003年,FBI决定将这些档案数字化,并对相关的流程进行自动化管理,这样探员们就可以迅速地比较各个档案,从中找到它们之间的联系。这个项目的名字叫作“哨兵”。

2006年3月,FBI启动了“哨兵”项目,目标用户是3万多人,包括FBI探员、分析师和行政人员。“哨兵”项目的最初预算是4.51亿美元,预期在2009年12月完工。根据FBI的最初计划,“哨兵”项目的开发工作会分为四个阶段。这个项目外包给了洛克希德马丁(Lockheed Martin)公司,这家公司建议使用传统的软件开发流程。

到2010年8月,FBI已经花费了总预算中的4.05亿美元,但是项目只完成了四个阶段中的两个。虽然完成的前两个阶段的确帮助FBI改进了档案的管理系统,但是没有达到他们的预期效果。于是,由于成本和时间的超支,2010年7月,FBI决定停止洛克希德马丁公司在“哨兵”项目剩余两个阶段的开发工作。

到这个阶段为止,FBI一直在使用传统的开发流程,而现在,他们尝试引入新的流程来获得更好的成效。这个新的流程就是我们在20世纪90年代初创立的Scrum。那份指出只有37%的软件项目成功的CHAOS报告,同时论述了采用传统开发流程和采用敏捷(即Scrum)流程开发项目的结果会有什么区别(如下图所示)。从图中可以看出,采用传统开发流程(瀑布式)的项目中只有14%成功了,而采用敏捷流程的项目成功率有42%。这些敏捷项目不仅满足斯坦迪什组织对成功项目的定义,而且能够更好地适应客户需求的变化,更有效地降低风险,并最终交付更高质量的软件。

{%}

图 敏捷项目的成功率是三倍

2009年,FBI聘请了新的首席信息官和首席技术官,他们都管理过使用敏捷流程进行软件开发的组织,于是决定看看敏捷流程能否带来帮助。2010年,首席技术官向司法部提出他希望改变“哨兵”项目的开发流程,声称新的流程将精简决策过程,并且能够在预算内完成剩余的开发工作。FBI告诉当时的司法部检察长,他们相信可以在12个月内,利用剩余的预算完成“哨兵”项目。根据MITRE的审计显示,如果FBI继续沿用传统开发流程的话,他们将需要额外的3500万美元和6年时间来完成该项目。

于是,FBI将整个“哨兵”项目搬到了位于华盛顿特区的FBI大楼地下室,并且将项目的人数从400人减少到45人,其中15人是程序员。项目重新启动后由首席技术官亲自运营。他要求团队以30天为一个周期,每个周期交付一部分功能,每次交付的功能必须满足最终的功能性和非功能性需求。这是一个“一次发布”的软件。此外,每三个月FBI就将最近三次迭代的功能部署到一个现场试点上。

2011年11月,“哨兵”项目在重新启动新的流程后用不到一年的时间就全部完成了。软件首先部署到FBI的一些试点办公地,其余的办公地将在2012年6月前完成部署。事实是,FBI用了3000万美元和不到12个月的时间完成了“哨兵”项目,并且节省了90%以上的开支。

虽然FBI在“哨兵”项目的前期阶段投入了大量的人力物力,但是开发流程严重阻碍了项目的进展。而实施了Scrum流程以后,虽然工作强度跟以前一样,回报却丰厚得多。如果FBI能这么做,为什么你不可以呢?

错误的方法:预测性流程

FBI在“哨兵”项目初期所使用的流程,就是我们所说的预测性或顺序式的设计流程。实际上,在2005年之前,大多数软件项目仍然使用预测性流程。并不是说这种预测性流程就一定不好,它在特定场景下会更适用,并能取得成功。然而,这些场景只是特例而非常态。例如,已经建立了完整的愿景,愿景中的所有需求已经定义,并且已经策划出实现愿景的详细计划,这时就可以使用预测性流程。但是,只要与原始愿景、需求或者计划略有偏差,就会为项目带来巨大的风险。然而由于商业需求和技术的日新月异,可以说这些因素的变化都是不可避免的。于是,就像斯坦迪什组织在其报告中所述的,86%使用预测性流程的软件项目都未能成功。实际上可以认为,预测性流程的使用是导致软件项目失败的最常见原因。

与我们合作过的组织都在想尽办法提高软件项目的成功率。他们担心软件项目失控,来向我们求助。现有的流程让他们尝到了失败的滋味,却又无计可施。这些软件开发流程浪费了他们大量的人力物力。但由于软件是其主要竞争力来源,他们不得不继续这些项目。

下面是高管和经理们经常遇到的问题。

  1. 版本发布所需时间越来越长。“提交给客户的每一个版本,其发布所需要的时间、人力和成本越来越多。几年前,一次发布可能需要18个月。现在,同样的一个版本发布需要24个月来开发、打包和部署。尽管如此,我们仍然感觉时间仓促,压力很大。我们觉得投入越来越大,而产出却越来越少。”

  2. 无法按时发布。“我们向客户和市场承诺之后,客户或者潜在客户都按照我们承诺的发布时间制订商业计划。他们需要我们在承诺的时间点,及时交付承诺的功能。然而,我们通常在最后时刻让他们大失所望。他们的计划被打乱,损失了金钱,失去了客户的信任。结果是,我们可能再也无法从他们那里拿到新的项目,他们显然也不会为我们介绍新的客户,他们自己也会寻找新的开发商。”

  3. 在版本发布的最后阶段,软件达到稳定状态需要的时间越来越长。“我们和软件开发组织有明确的约定,确定了固定的交付日期。虽然他们在设定的日期之前达到了他们所谓的‘代码完成’或‘代码冻结’状态,但是软件根本不能用,无法实现所需的功能和性能,让人完全无法接受。我们甚至无法将‘测试版本’交付给小样本客户试用以获得反馈,因为软件中的缺陷实在是太明显了,试用客户拒绝参与测试。我们需要额外的九个月时间来完成版本发布。即便是那样,我们还是没有十足的把握,仍然需要很多帮助,并为各种事情向客户道歉。”

  4. 制订计划的时间太长,而且计划得不准确。“我们发现,由于没有在项目开始之前把计划做得足够好,导致发布版本的时间过长,错过了发布日期。我们没有完全确定并分析清楚需求,而且我们的预估包含了过多猜测。为了解决这些问题,我们不得不花费更多的时间来做计划。在这期间,我们不断产生新的想法,评审计划的过程中也会发现需要重做或澄清的地方。结果是,现在我们花在计划上的时间更多了,然而进度落后和软件难以达到稳定状态的问题仍然非常严重。尽管我们为做计划大费周章,但在开发期间仍会遇到计划期间未能或无法预见的变化。”

  5. 在版本发布中期很难做更改。“目前的开发流程无法适应变化。我们在开始开发时投入了大量的时间做计划,并且断定所有需要的工作都列入了计划中,但后来经常会发现有些非常重要的部分或新的特性必须添加到当前版本中。为了进行这些更改,我们不得不调整已经完成的部分。而这种调整是非常困难的,因为在软件中引起的连锁反应是难以想象的。尽管调整是必要的,但在版本中调整比在一开始调整要多花一百倍的时间。但是我们又能怎么做呢?如果不在当前的版本或者项目中做出调整,恐怕就要等到两年后的新版本才有机会了。”

  6. 质量持续恶化。“我们知道不该向开发人员施压要求按期交付原定和更改后的功能。但是当业务遭受计划、延误、变化问题的三重打击的时候,我们只能告诉开发人员,必须咬紧牙关在限期内交付所有计划中的东西。每当开发人员听到这种指令时,他们通常会用降低软件质量或者减少软件适用性测试的方式来应付我们。结果可想而知,要么回到版本稳定化阶段,要么交付质量差的软件,使组织的声誉受损。”

  7. “死亡行军”损伤士气。“我们现在管理员工的方式很严苛,但这也是不得已而为之。我们必须完成组织的目标和业务,因此项目中的每个人都需要加班,而且周末也要上班。这会使他们的家庭关系和健康受损。后果是,我们很难招到顶级的开发人员,而且眼睁睁看着公司最优秀的开发人员跳槽到其他组织。此外,现有的员工士气低落,工作效率随着工作时间的延长而降低。”

这些例子已经足以让高管和经理们垂头丧气。尽管整个软件行业在20年间投入了大量的努力和金钱,但截至20世纪90年代初,仍然未在软件项目的成功开发上有所突破。

错误的结果:项目失败

传统预测性软件开发流程的使用是导致如此之多项目失败的罪魁祸首。预测性流程也叫瀑布式流程,其可行性依赖于项目计划的准确性和执行的严格性。它必须满足以下条件。

  1. 需求不会变更,而且被完全理解。需求的任何变更都会使计划改变,从而产生连锁反应,最后的结果通常是导致已经完成的工作作废。不幸的是,在典型的软件项目中,35%以上的需求都会变更。一开始,客户会尽力确定所有需求。但商业环境瞬息万变,加上客户对自己实际需求的理解不完整,而且很难在成品完成前完整地描述预期系统,因此需求的变更就不可避免了。

  2. 技术能够正常使用。在软件中使用的所有技术都能按照最初计划的那样可靠地工作。不幸的是,项目中经常会引入从未使用过的技术。可能是单独使用,也可能和其他技术组合使用,或者是不同技术用于同一用途。另外,技术标准有时也会在项目期间改变。

  3. 员工像机器一样可预测并能可靠地工作。计划中包含一系列相互关联的任务,每一项任务都需要专业技术人员根据特定的输入在给定的时间完成。然而一旦需求发生变化,就会产生连锁反应,所有任务都有可能受到波及。更重要的问题是,人并不是机器!人有情绪起伏,有技术水平差异,还有态度和智力的差别,不可能完全按照定义执行任务。因此到了最后,任务的执行情况可能与计划差异较大。

软件行业已经意识到上述这些困难,而且多年来一直试图增加计划方面的投入以解决这些问题。有时做计划的时间甚至和实际开发的时间一样长,在搜集需求、定义架构以及细化工作计划方面做了大量的工作。

只有计划基于精准且保持不变的信息,前期的所有投入才有价值。因此,这种方法只有在需求完全清楚而且相对稳定,计划也不会变化的情况下才是有效的。假如实际情况并非这样,预测性流程就会失败,因为预测性流程并不适合解决未知和意外的问题,而是用于优化约束问题的。

很多传统制造企业成功地实施了预测性流程模型。这些前期的研究工作对后续重复性地执行计划是有好处的,如生产出一辆辆汽车或者一个个烤箱。然而,对于软件开发来说就不一样了,因为软件开发的计划只执行一次。预测性流程适合制造业的原因是一个流程会制造出大量的产品。而这恰恰是它不适用于软件行业的原因,因为软件开发的一个流程只会生产出一个产品。

斯黛西图(Stacey Graph)是用来评估工作中的确定性和可预测性的有效工具。2斯黛西图用于度量不同维度的工作的确定性和不可预见性,并标示出工作范围。我们用它来为软件开发中的三个维度建模,这三个维度分别是:需求、技术和人,如图所示。

2引用自R. Stacey的Complexity and Emergence in Organizations

{%}

斯黛西图

我们可以把软件开发项目划分成下面三个方面。

  • 需求。无变更风险时确定性最高。随着不明确因素、涌现式描述和可预见性变更的增多,确定性降低。

  • 技术。所用技术为人熟知时确定性最高。随着开发及运营技术复杂度的提升,不同的技术在不同的软件开发和发布阶段通过接口交互,确定性随之降低。

  • 人。确定性随着人员数量的增多而降低。当人员数量超过4个或者5个,甚至达到上百个并经常改变时,确定性不断降低,因为不同的人有不同的意见、态度和情绪。以团队或分组方式工作时,成员间的互动和工作的不可预见性是巨大的。

使用斯黛西图,可以看到软件开发项目是复杂的,有时甚至是混乱的。瀑布式开发和传统软件开发所基于的预测性流程只适用于简单的重复性工作。现在你可以根据收益率(成功率)明确地判断你的流程是否符合需要。如果预测性流程适合你的项目,那么收益率(或者说项目的成功完成率)将高达99.99%。然而,根据斯坦迪什报告,使用预测性流程的软件项目的成功率只有14%。大多数公司无法在如此低的成功率下生存。试想一下,如果通用汽车生产的每七辆车中就有一辆报废,就是14%的成功率。

预测性流程并不适合解决软件开发中的问题,因为软件开发是复杂的,而不是简单的过程。我们可以断定,将预测性流程用于软件开发项目是令我们失败的根本原因。依据是,自从开始应用Scrum以后,软件开发项目的成功率提升了。

人们有时候将工程或桥梁建造等同于软件开发。桥梁建造等工程规范在斯黛西图中位于简单和复杂之间的区域。标准化流程只能使这种工作变得更复杂。工程建造中一共有三种类型的标准化。首先,牛顿定律解释了物体间是如何相互作用的。其次,采用的标准化材料,如木梁、金属支柱和扣件,都有标准的大小以及已知的特性。最后,所有类型的结构都有官方规范和检查标准。而在软件开发中却不存在如上这些标准。而且,随着软件行业的日新月异,这种没有标准的情况将不会改变。

案例分析:PTC

PTC(Parametric Technology Corporation)是一家拥有5000名员工的跨国公司,从事产品生命周期管理软件的开发。其产品基于CAD/CAM(计算机辅助设计/计算机辅助制造)系统,帮助像雷神、BAE系统、空中客车等世界顶级的工程组织管理大型系统的开发,例如空中客车A380的开发。其主要是通过监控所有部件、配件和子配件的配置来进行管理。

2005年,PTC遇上了使用预测性流程有可能遇上的所有麻烦。

  1. 版本发布所需时间越来越长。发布一个版本的时间从18个月增加到24个月,而且看起来当前版本可能需要更长的时间。

  2. 无法按时发布。交付延误长达9个月,而且情况逐步恶化。那些依赖于重要功能准时交付的客户为此感到很不高兴。

  3. 在版本发布的最后阶段,软件达到稳定状态需要的时间越来越长。软件稳定花费的时间至少占了延误期的三分之二。

  4. 制定计划的时间太长,而且计划得不准确。每个版本的计划期都长达6个月,但计划仍然不够准确,经常需要改变。

  5. 在版本发布中期很难做更改。尽管无法确定项目延期以及软件的稳定和质量问题是由项目开始之后的变更引起的,但是大量的变更确实发生了。

  6. 质量持续恶化。这是相当严重的问题,而且情况越来越糟。

  7. “死亡行军”损伤士气。PTC很难招聘到高素质的人员。

PTC的开发部门使用的是瀑布式流程。为了使其更好地工作,他们尝试把需求弄得非常清楚。需求都被记录在一个详细的功能规格说明书里,只有在最终确定后才会让开发部门知道。在确定需求的这段时间里,开发人员并没有什么事情可做。他们要么修复程序错误,要么就因为极度无聊离职了。而测试团队在整个产品完成之前无法进行测试,因此能够进行测试的时间很短。由于发布日期的压力,测试团队被迫发布没有经过充分测试的产品。

Jane Wachutka是PTC Windchill产品开发部门的新任副总裁。刚入职时,她尝试了PTC的瀑布式流程,结果碰到了所有常见的问题。在以前的工作中,她曾引入很多类似帮助FBI完成“哨兵”项目的非瀑布式流程。在这种流程中,一个项目包含一个或多个迭代工作,每一个迭代不超过30天。开发人员被分成多个小组,在每个迭代中选择高价值的需求进行开发,然后将它们作为增量集成到可用的软件中。所有团队开发的增量集成为一个完整的可用增量。在接下来的每个迭代中,都将开发新的增量,并添加到之前的增量中。

Brian Shepherd是PTC产品开发部门的执行副总裁。当Jane在2007年引入新的软件开发流程的时候,Brian曾经有过顾虑。当时,Jane承诺如果Brian允许她引入新的流程,她保证能让开发人员更早地开始工作,降低开发人员的流失率,让测试人员更早地参与工作,在产品未经过完整测试且质量过关之前绝不发布。Jane还强调,可以让开发人员在需求文档还没完善的时候就开始开发,这样产品管理团队可以在开发期间经常检查和试用开发完成的部分,并给予开发团队反馈。于是,Brian同意引入了一套新流程——Scrum敏捷流程,但是同时他也警告Jane:“别搞砸了。”

当Jane第一次告诉她的团队要使用新的流程进行开发的时候,他们也有所顾虑,尤其是开发团队的成员。他们仍然希望开发过程的每一步都是精准的,能够确保满足需求。然而,随着对新流程的日渐熟悉,产品经理们不再试图将完美的需求文档交给开发团队,而是允许开发期间涌现新的需求。由于PTC现在能够在30天内开发出完整的功能,因此开发人员能够在任意适合的迭代中和客户直接交流。他们能够更直接地了解需求,以及如何更好地实现它们。客户也发现了这样的改变,开始在每个迭代中和开发团队一起工作。他们积极参与定义功能,得到了真正想要的功能。

产品管理团队拥有持续变化的三个需求集,分别是为三年、两年和一年的需求集。三年的需求集包含了总体愿景,描述了重要功能。两年的需求集中定义了这些愿景将在哪些版本中具体实现。本年度的需求集中包含了前6个月中每个30天迭代的需求,以及后6个月的目标路线图。每年的需求集都比前一年拥有更多细节。开发人员依照当年的需求集进行工作。他们和PTC的客户协作定义需求细节。整个组织变成了一个富有创造力和生产力的智囊团。

两年之内,Jane对Brian的所有承诺都兑现了。版本发布时间从之前的24个多月降到了12个月,而且交付的产品质量很高。到2011年,PTC已经发生了翻天覆地的变化,无论是对内部还是客户都是透明的。意外情况很少发生,客户知道在什么时候能够得到什么。到了2012年,缺陷率已经几乎降低为零。新的特性、用户界面和工作流功能都被加入到了产品中。整个产品也经过了彻底检查,安全性足以抵御外来的风险。最后,预算和人员需求都降低了超过十个百分点。Brian为软件产品开发部门建造了新的办公室。新的办公场所满足了新流程所需的透明度。现在每个人都在一个开放的空间里,没有独立的办公室,而且所有的墙都是玻璃的。

最近,PTC的首席执行官Jim Heppelmann听取了下属经理们关于提高年度预算的讨论。最后,他打断了他们,并让每个人感谢Jane的部门在提升质量和增加功能的同时降低了软件成本。正因为这样,才为其他部门腾出了提高预算的空间。

有一次,一个以色列客户与Jane和Jim进行电话会议,评估PTC公司的产品。Jane告诉对方的首席执行官,雷神公司正在其全球的子公司中使用PTC的产品,并建议他向雷神的高管咨询,因为她清楚地知道,雷神公司不仅对PTC的产品非常满意,还惊叹于PTC新的流程能够避免意外情况的发生。他们能够与PTC实时合作,随时调整自身的计划,甚至还采纳了PTC的软件开发流程。Jim插话说,Jane忘记提及上一次发布的版本,那是PTC交付的最漂亮的一个版本,并且主要归功于Jane改变了开发流程。

Scrum敏捷框架

Scrum是一个用于管理如软件开发这样的复杂工作的框架。Scrum的结构非常简单,由3个角色、3个工件和5个事件组成(如图所示)。Scrum利用各种规则把这些部分绑定在一起。

{%}

图:Scrum的基础

负责开发软件的团队叫做Scrum团队,由一位软件开发的发起人(产品负责人)、一位经理(Scrum Master)和一些开发人员组成。为了避免混乱,每个Scrum团队只允许有一个产品负责人。产品负责人决定每个迭代(迭代在Scrum中被称为Sprint)要开发的功能,并在每个Sprint结束时评审软件增量是否符合要求。Scrum Master保证项目按照Scrum的方式进行。有些Scrum Master是经过Scrum认证的,有些则拥有成功使用Scrum的重要经验。懂得如何管理Scrum团队和项目是非常重要的。

组建Scrum团队并为Sprint做计划

Scrum Master的首要任务就是找到开发人员并组成开发团队。组成团队的成员必须有能力在Sprint中把产品负责人(产品待办列表)的需要和需求转变成可以工作的软件增量。

Scrum团队的所有成员在组建团队时聚集到一起,互相认识,讨论接下来的工作及后勤事宜。Scrum团队需要了解愿景(即需要和期望的产出),什么样的产出代表成功或失败,有哪些约束条件。团队只需要关注最重要的需求,为接下来的Sprint选择尽可能多并且很有可能完成的需求。(开发人员需要懂得如何将大的需求分解成在Sprint中可执行的精细的开发事项。)

然后,Scrum团队的开发人员估算将需求转化为完整软件功能所需的工作量。由于他们是开发工作的直接参与者,因此由他们进行估算是最合适的。而估算的精确度由他们在一起工作的时间长度,对所用的技术的了解程度,以及对业务问题领域的熟悉程度所决定。

计划结束后,开发人员估算他们在Sprint结束时能够完成的工作。实际上,这是一个经验型的过程:首先预测,然后观察实际能够完成的工作量,最后根据实际产出做决定。

为了尽快开始工作,做计划和估算只能用一天。接下来Scrum团队需要紧密合作,直到每个人都对需要解决的问题和解决方法有十足的把握。也就是说,每个人都需要知道在接下来的Sprint中要开发的是什么。随着开发工作的开始,之前不明确的事情会渐渐变得明了。

开始Sprint——向价值启航

在Sprint计划会议结束后,第二天Scrum团队就开始开发工作。开发人员会在第一个Sprint里开发出一个软件功能增量。该增量中包含的功能有可能比预期多或少。在Sprint期间,Scrum团队成员互相协作,理清工作。如果开发团队发现最后还有时间剩余,或者剩余的时间不足以完成剩下的工作,Scrum团队就有可能根据情况对需求进行增减。

在Sprint期间,开发人员每天都要开一次15分钟的会议。这个会议被称作每日站会,用于重新计划接下来的工作,总是尽力交付计划的任务。为了使开发人员的生产率达到最高,Sprint的目标必须同时得到开发人员和产品负责人的认同。开发人员必须同意竭尽全力完成需求的软件,在每个新的Sprint开始时重新制订目标。而产品负责人则需要同意在Sprint进行期间不会变更开发人员正在开发的需求,任何在计划之外的事情(例如要求开发人员参加客户会议等)都会等到下一个Sprint再讨论。只有开发人员的工作不被打断,其生产率才可以提高。采用较短周期的Sprint通常可以适应更频繁的需求变更。

进行Sprint评审

在每个Sprint结束时,你需要与Scrum Master以及开发人员一起举行Sprint评审会议。这个会议一定不超过4个小时。Scrum团队和关键的干系人聚集到一起,回顾Sprint中发生的事情和产生的功能增量。评审的内容包括完成的内容、数量、效率以及价值。完成的软件增量必须是完整可用的软件模块。没有彻底完成的产品待办列表项将会重新进入产品待办列表,成为“待办”条目。Sprint评审会议中经常会涌现出新的需求、机遇和挑战,因为评审已完成的功能增量通常能激发新的灵感。

评审的结果可能包含下列内容中的一项或多项。

  • 开始使用完成的功能增量;

  • 决定在下一个Sprint需要做什么,并做好准备;

  • 决定不再继续,终止工作。

通过评审,项目的风险被限制在一个Sprint的投入。在每个Sprint结束时都能交付有价值的内容,并规划下一个Sprint。如果你想要进行下一个Sprint并开发更多的软件增量,那么就需要进行Sprint回顾会议了。

进行Sprint回顾

在每个Sprint中,Scrum团队的所有成员都在努力取得进步,而Sprint回顾会议正提供了讨论如何取得进步的平台。会议不应该超过4个小时。

Sprint回顾会议在Sprint之间的间隙进行。Scrum团队聚集到一起,回顾在上个Sprint中发生的事情,并讨论如何改进工作成果和工作方式。会议内容可能会涉及以下问题:

  • 团队成员之间合作是否融洽,为什么?

  • 团队完成的工作量比预测多还是少,为什么?

  • 团队是否拥有足以完成工作的技能和设施?

  • 开发人员是否能够充分理解需求,为什么?

  • 团队是否能够按照需求完成Sprint的目标,为什么?

  • 在下一个功能增量里有什么可以改进或者移除的?

  • 团队认为Scrum怎么样?

接下来就是让团队确定在下一个Sprint中需要改变的地方,以便提高团队的创造力、效能和生产率。总之,Scrum团队就是要不断进步。Sprint回顾会议是一个让Scrum团队的生活和工作变得更美好的机会。

继续Sprint

Scrum团队继续重复前面描述的过程,直到实现目标,机会最大化,获得投资的回报,或者遇到无法克服的障碍为止(如图)。

{%}

图 Scrum实战

小结

软件开发在过去非常容易失败,其根本原因就是使用了预测性流程来做复杂的工作。当Scrum这样的经验型流程被采用后,软件项目的成功率会大幅提高。

因此,在30天内开发出可用的软件功能是完全有可能的。不要听你的开发人员说这不可能,因为从21世纪伊始,已经有成千上万名开发人员成功做到了。也许软件产品仍然很庞大,但它可以被切分为几个小模块,以30天为周期逐个开发。

 

{%}

《30天软件开发:告别瀑布拥抱敏捷》整体上分为两大部分。第一部分用大量的篇幅分析了瀑布流程的问题,并阐述了迭代增量式的经验型软件开发方法能够解决复杂项目中的问题。如果你是管理者,因为在软件开发中碰到的问题而感到纠结和困扰,想尝试其他办法,那么本书系统介绍的敏捷思维会打开你的思路。第二部分介绍了如何渐进式地向Scrum转型,并分析了一些案例。