文档首页 > > 理论实践> 持续规划与设计>

橄榄球与敏捷软件开发

橄榄球与敏捷软件开发

分享
更新时间:2021/02/27 GMT+08:00

什么是Scrum

Scrum是90年代初由施瓦伯和苏瑟兰(Ken Schwaber和Jeff Sutherland博士)共同提出的,现在此方式已被众多大中小型企业使用,其中包括Yahoo!(雅虎)、Microsoft(微软),Google(谷歌)、Lockheed Martin(洛克希德·马丁)、Motorola(摩托罗拉)、SAP(思爱普)、CICSO(思科)、GE Medical(通用医疗)和Capital One(第一资本)。许多使用Scrum的团队都取得了重大的突破,其中更有个别在生产效率和团队职业素养方面得到了彻底的改善。

Scrum与敏捷开发原则

Scrum其实仅仅定义了一个框架(Framework),具体的实践,完全取决于每个团队,并且是完全基于经验进行管理的。我们来看看Scrum是如何符合我们所熟知的敏捷开发原则的。

Scrum遵循的敏捷开发原则有以下几点:

  1. 保持简单:Scrum本身就是简单轻量级的流程,一页纸就能说清楚,与传统模式相比,它能极大简化我们现有的开发流程。
  2. 接受变化:Scrum鼓励将工作细分成小块。它关注的是一小段一小段时间,只有在这些时间段的中间,我们才可以重新调整工作的优先级。
  3. 不断迭代:Scrum需要在小于30天的一次次迭代中构建应用程序。

    不断的反馈和改善——在每一次迭代的末尾,Scrum流程要求我们回顾以前是怎么做的,并且思考我们下次可以做哪些事情来改善流程。

  4. 协作:Scrum鼓励团队成员的协作和沟通。如果没有这些,Scrum就一点用都没有。
  5. 减少浪费:Scrum帮助我们识别做那些只对客户或者团队有价值的事情。

Scrum中的几个关键的定义

  1. 产品需求列表(Product Backlog):这是构建一个产品需要做的所有事情的一个高层次的列表,并按优先级排列,这样可以保证你总是工作在最重要的任务上。
  2. 冲刺(Sprint):一个Sprint就是一次为完成特定目标的迭代,一般是1~3周。之所以叫冲刺Sprint,而不是叫迭代,就是希望大家能够保持一种紧迫感,努力快速完成任务。
  3. 冲刺需求列表(Sprint Backlog):这是Sprint的工作任务列表。一个“冲刺”需求列表包含产品需求列表上最高优先级的一些需求,以及产生的附加任务,每一个任务都应该有一个明确的“完成(Done)”的定义。
  4. 产品负责人(Product Owner):这个人负责维护产品需求列表内容和优先级,还有产品发布计划以及最终的验收。此外,他还要对ROI(投资回报)负责。
  5. Scrum Master:这个人负责执行这个框架流程,帮助大家消除工作障碍,保护团队不受外界打扰,这就像“牧羊犬”保护羊群一样;同时领导团队不断改进工作流程,这一点上,他应该是一个“变革发起者”的角色。
  6. 开发团队(Team):这些就是真正完成具体开发工作的人,一般5~9人规模。对于一次冲刺Sprint中的任务做出承诺,尽最大努力完成。

Scrum流程

作为一个轻量级的流程,简单讲是先建立一个产品“需求列表”,做一个短期“冲刺”计划,并执行这个计划,每天开会讨论计划中的问题和进展, 冲刺完成后演示工作成果,再对该阶段的工作做回顾、反思,接着不断重复以上流程。

如何践行Scrum流程

当你构建产品需求列表时,要创建一个按优先级排列的所有功能的列表,把最重要的功能放在列表的最前面。

最初的计划是非常高层次的,仅仅是我们对客户开始想要的那些功能的粗略认识。一旦认识发生变化,就要及时调整。所以我们不会把里面的东西全部细化,只对最高优先级的部分细化。下一步做Sprint计划。你要从产品需求列表中选出一些优先级最高的,制订一个1~3周的计划,决定如何完成这些任务。然后执行这个计划。

每天开一次短会,检查Sprint中每个任务的进展状况,对未完成的任务,要求任务所有人给出新的剩余工作量的估算。

  • 关于每日站会

    Scrum Master要让会议开得很短,对于一个5人团队,只要花10分钟就够了。在Sprint完成时,大家聚在一起,展示一下工作成果,这时候一定要让产品负责人知道已经完成了哪些工作,并让他验收。

  • 关于回顾会议

    一个Sprint结束后,做一次反省。从团队的角度来审视哪里做得好,并继续保持,找出不好的地方,寻求改善方法。

  • 关于计划会议

    在一个Sprint做完之后,重新调整一次产品需求列表,尤其是需求的优先级,然后再做计划,开始下一个Sprint。

Scrum要点

  1. 相对于传统的开发模式来讲,敏捷是软件开发中用于应对快速变化的市场和需求,并作出快速反应的一种方式。
  2. Scrum坚持如下的敏捷开发原则:保持简单、接受变化、不断迭代、不断地反馈和改善、协作和减少浪费。
  3. Scrum是一种灵活的软件管理过程,它可以帮助你驾驭迭代、递增的软件开发过程。
  4. Scrum提供了一种经验方法,它使得团队成员能够独立、集中地在创造性的环境下工作。它发现了软件工程的社会意义。Scrum一词来源于橄榄球运动,指"在橄榄球比赛中,双方队员站在一起,当球在他们之间投掷时奋力争球。"
  5. Scrum这一过程是迅速、有适应性、自组织的,它代表了从顺序开发过程以来的重大变化。
  6. Scrum的迭代过程称为Sprint(冲刺),时间为1~3周。
  7. Scrum团队一般由5~9人组成,Scrum团队不仅仅是一个程序员队伍,它还应该包括其他一些角色,如设计人员、测试人员和运维人员等,是一个跨职能、无角色的特性团队。
  8. Scrum包含三类角色:Scrum Master、Product Owner、Dev Team。
  9. Scrum是一个非常轻量级的流程。简单讲是先建立一个产品Backlog(需求列表),做一个短期Sprint(冲刺)计划,执行这个计划,每天开会讨论计划中的问题和进展,冲刺完成后演示工作成果,再对该阶段的工作做回顾、反思。然后继续重复以上流程。

敏捷开发之Scrum方法

敏捷开发的方法有很多,Scrum只是其中一种;不同方法的形式不尽相同,但背后的原则是相对不变的,即敏捷宣言的12条原则。

Scrum、Kanban,SAFe、LeSS等敏捷框架以及DevOps,仔细探究,其原则都有相近之处,所以学习方法与实践,不要只得其形,不得其神;原则就是方法与实践的神,是根本;而具体的方法和实践,要在不同的场景下面适度调整,并非一成不变;背后相对稳定的,是它们所遵循的原则。

Scrum遵循的敏捷开发原则,最重要的是“减少浪费”,来源于精益思想。在唐·雷勒特森(Don Reinertsen)的《产品开发流》(Product Development Flow)中,称之为经济视角。

采用经济视角来看待敏捷开发中的实践,我们会发现许多实践之间是相通的。例如“保持简单”,是因为变化是永恒的,要“拥抱变化”,在变化面前,过度的设计往往会变成了浪费;再比如TDD测试驱动开发,就是先编写满足需求的测试用例,再编写能够通过测试的代码,"保持简单"的设计,同时可以持续"不断的获得反馈"。

关于一个Sprint的长度,从早先建议的2~4周,已经变成了1~3周,并且倾向于越短的迭代,目的是快速获取用户/客户反馈,借以调整产品需求列表(Product Backlog)的内容以及相关优先级。产品开发中最大的浪费,就是开发出用户不需要的功能。这也是“减少浪费”原则的一种体现。

很多人对敏捷开发有误解,认为短周期的交付,不经过传统瀑布模式中各类严格的评审阶段,交付出的产品质量会大打折扣。事实上并非如此。敏捷开发强调“内建质量”(Build Quality In),质量活动贯穿在敏捷的每一个过程中,并且通过例如持续集成、自动化测试、持续交付等活动,形成快速反馈闭环。此外,文中提到完成的定义DoD(Definition Of Done,完成定义),也是内建质量的一种体现,与DoD相对应的,还有DoR(Definition Of Ready,就绪定义)。

本文内容节选自《敏捷无敌之DevOps时代》,作者:王立杰、许舟平、姚冬(清华大学出版社)。

分享:

    相关文档

    相关产品