敏捷开发-Scrum和实践

先写一段我喜欢的关于敏捷开发的话:
如果30天内无法将Idea转换成具备商业模式及可操作性的项目,
如果2个月内无法找到团队核心并组成初创团队,
如果3个月内你的Idea还没被团队充分理解并预期付诸实践,
如果6个月内你还在筹划半年前的那个Idea,
这个Idea已经过时勒,请下一个,这里是互联网!

更迅捷的项目管理,
更快速的项目决断,
更舒适的用户体验,
更早地实现Idea,
好与不好交由公众来评断,
不要闭门造车以为一切尽在掌握。
— Reinhardt

 大概8年前接收Scrum联盟的培训,然后在项目组推行Scrum流程,先后带过多个团队。下面简要介绍一下Scrum流程,还有一些实践的总结。

  软件开发所面临的挑战和任务是在现有的时间和有效的资源范围内,寻找解决实际问题的切实可行的方案。在众多软件项目中,缺乏合理的时间进度是造成项目滞后的最主要的原因,它比其他所有因素加起来的影响还大。导致这种普遍性灾难的原因是什么呢?

  • 首先:我们对估算技术缺乏有效的研究,更加严肃地说,它反映了一种悄无声息,但并不真实的假设一切都将运作良好。
  • 第二:我们采用的估算技术隐含地假设人和月可以互换,错误地将进度与工作量相互混淆。
  • 第三:由于对自己的估算缺乏信心,软件经理通常不会有耐心持续地进行估算这项工作。
  • 第四:对进度缺少跟踪和监督。在其他工程领域中,经过验证的跟踪技术和常规监督程序在软件工程中常常被认为是无谓的举动。
  • 第五:当意识到进度的偏移时,下意识以及传统的反应是增加人力。这就像使用汽油灭火一样,只会使事情更糟。越来越大的火势需要更多的汽油,从而进入了一场注定会导致灾难的循环

软件开发模式

瀑布开发

 传统的瀑布模式开发假定从项目开始需求就是明确的,严格把软件项目的开发分隔成各个开发阶段。主要的问题是它的严格分级导致的自由度降低,项目早期即作出承诺导致对后期需求的变化难以调整,代价高昂。
 瀑布开发模式的项目周期往往比较长,一般为3-6个月,甚至更长时间,当项目开发完成后,最后交付成果往往不是产品经理或是客户真正想要的,最后只能重新从项目的需求开始,不可控的因素和风险很大。
图片替换文本


敏捷开发

 2001年,十七位关于敏捷方法的发起者和实践者聚集到一起,发表了“敏捷软件开发宣言”。他们强调敏捷开发能够以一种更加简洁、可持续、短周期、高效率的方式进行软件开发,同时希望以敏捷联盟为形式的合作可以帮助到行业中的其他人,帮助他们以更加敏捷的新方式来思考软件开发、方法论以及组织架构。


敏捷宣言: 图片替换文本

敏捷开发的一些思想

  • 迭代式开发和增量交付
    把一个复杂且开发周期很长的开发任务,分解为很多小迭代周期可完成的任务;同时每一次迭代都可以生产或开发出一个可以交付的产品。
    图片替换文本

  • 持续可用的软件
    这样用户能够参与到整个开发过程中,使需求变化和用户反馈能被动态管理并及时集成到产品中。
    图片替换文本

  • 文档的沟通效率,不如面对面的沟通
    面对面,通过白板,是最高效的沟通方式。
    图片替换文本


敏捷项目管理和传统项目管理的对比

图片替换文本

主要的敏捷方法

  • 极限编程 (XP)
    • 加强开发者与用户的沟通需求,让客户全面参与软件的开发设计,保证变化的需求及时得到修正
    • 结对编程,测试驱动开发,持续集成,重构等
  • 精益软件开发(Lean Software Development)
    • 侧重于提高过程中的效率
    • 两个概念:
      • 拉式系统(pull system)。在拉式系统中,一个流水线上的任何一个环节的任务完成后,都会从前一个环节自动提取下一个任务。该模式以客户的需求而不是市场预测来推动工作进程。另一方面,通过精益模式可以最小化未完成工作以及半成品的数量。它们通常被认为是开发过程中的浪费
      • 价值流图(value stream mapping)也经常被应用于软件开发过程中。价值流图能够有效的帮助识别过程中的浪费
  • Scrum
    • Scrum是一个敏捷开发框架。在这个框架中,整个开发过程由若干个短的迭代周期组成,一个短的迭代周期称为一个Sprint

关于Scrum和XP

  Scrum和XP都是敏捷开发的具体方式。你可以采用Scrum方式也可以采用XP方式;Scrum和XP的区别是,Scrum定义了一套框架,偏重于过程,XP则偏重于实践,但是实际中,两者是结合一起应用的,在Scrum中经常引入具体的XP方法。


敏捷宣言遵循的原则

  1. 我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。
  2. 欣然面对需求变化,即使在开发后期也一样。善于掌控变化,帮助客户获得竞争优势。
  3. 经常地交付可工作的软件,相隔几星期或一两个月,倾向于采取较短的周期。
  4. 业务人员和开发人员必须相互合作,项目中的每一天都不例外。
  5. 激发个体的斗志,以他们为核心搭建项目。提供他们所需的环境和支持,相信他们能够达成目标。
  6. 不论团队内外,传递信息效果最好效率也最高的方式是面对面的交谈。
  7. 可工作的软件是进度的首要度量标准。
  8. 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
  9. 对技术精益求精,对设计不断完善,将提高敏捷能力。
  10. 以简洁为本,极力减少不必要工作量。
  11. 最好的架构、需求和设计出自于自组织的团队。
  12. 团队定期地反思如何能提高成效,并依此调整团队的行为

Scrum开发

scrum流程简介

图片替换文本
  1. 产品负责人(Product Owner)建立Product Backlog,并进行优先级排序
  2. 在Spint计划会议上,产品经理从Backlog中挑选Story,讲解需求。团队进行工作量评估,任务拆分
  3. 在sprint迭代进行中,团队每天开“站会”,沟通进度和问题
  4. 在sprint结束时,举行spring评审会议,向相关人员展示开发成果
  5. 最后是Sprint回顾会议,总结并讨论改进的地方,放入下一轮Sprint中去

Scum方法中的工作产出

1. Product Backlog

产品待办事项列表是一个排序的列表,包含所有产品需要的东西,也是产品需求变动的唯一来源。产品负责人负责产品待办事项列表的内容、可用性和优先级。

2. Sprint Backlog

Sprint待办事项列表包含团队需要执行的任务,从而将产品待办事项列表条目转化成“完成”的增量。

3. Release Increment

可交付的软件产品。


Scrum团队的三个角色

1. Scrum Master

  ScrumMaster负责确保Scrum团队遵守Scrum价值、实践和规则;帮助Scrum团队和整个组织实施Scrum;通过指导和引导,教授Scrum团队更高效工作、生产出高质量的产品;帮助Scrum团队理解并采用自管理和跨职能。但是,ScrumMaster不对Scrum团队进行管理,团队是自组织的。

2. 产品负责人(Poduct Owner)

主要负责确定产品的功能和达到要求的标准,负责产品需求的提炼,维护Product Backlog,和Product Backlog的优先级。
通常由产品经理、部门经理、策划人员担任。

3. 团队

以自组织的方式管理,负责产品的开发。
理想的团队规模在5~9个人(不包括Product Owner和Scrum Master)。过小团队在 Sprint 中可能会受到技能限制,导致无法交付复杂的产品。大于 9 人的团队需要过多的协调沟通工作。


Scrum的实施

一个Sprint的周期一般是2~4周,通常3周比较适中。也有互联网公司,小的迭代,采用1周的。

1 . 创建和维护Product Backlog

  • 产品待办事项列表是一个排序的列表,包含所有产品需要的东西,也是产品需求变动的唯一来源。产品负责人负责产品待办事项列表的内容、可用性和优先级。
  • 一个持续完善的动态的清单, 最初的版本只列出最初始的和众所周知的需求。随时或通过Backlog refine 会议不断梳理来增添细节、估算和排序。
  • 需要从客户角度描述价值。典型的描述是用户故事(User Story)

User Story

用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素:

  • 角色:谁要使用这个功能。
  • 活动:需要完成什么样的功能。
  • 商业价值:为什么需要这个功能,这个功能带来什么样的价值。

用户故事通常按照如下的格式来表达:

  • 作为一个<角色>, 我想要<活动>, 以便于<商业价值> (As a …, I want …, so that …)
    例子:
  • 作为一个“网站管理员”,我想要“统计每天有多少人访问了我的网站”,以便于“我的赞助商了解我的网站会给他们带来什么收益。”
  • 作为一名“购物者”,我想要“在我的移动钱包中添加一个账户”,以便于“我可以充值”。

User Story划分原则

INVEST规则

  • 独立性(Independent):一定要保证Story在功能上的独立,尽量不要有Story之间的依赖,否则会大大影响将来的开发和测试。
  • 可谈判性(Negotiable):Scrum中的story不是瀑布开始某事中的Contract, Stories不必太过详细,开发人员可以给出适当的建议。
  • 有价值性(Valuable): Story需要体现出对于用户的价值。
  • 可估计性(Estimable):Story应可以估计出Task的开发时间。
  • 大小合适(Sized Right):关于Story的粒度,建议的开发工作量是3-5天(包含针对Story所做的开发者自测工作量),如果Story不能拆分到3-5天的开发粒度,则一定要确保该Story在一个迭代周期内可开发测试完成。(最大别超过8天)
  • 可测试性(Testable):一个用户故事要是可以测试的,以便于确认它是可以完成的。如果一个用户故事不能够测试,那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子:软件应该是易于使用的

2. Sprint计划会议

计划会议分两部分:

  • 1)选择需要在本次Sprint中完成的任务
    从Product Backlog中挑选高优先级的Stroy,Product Owner进行需求讲解,团队对Stroy进行工作量评估
  • 2)对选择的任务(Stroy)进行拆分
    团队把Stroy拆成小的Task,Task通常控制在2天以内

通常一个Sprint的周期是2~4周。

工作量评估方法

在这里插入图片描述

推荐的评估方法是扑克牌评估。扑克牌上的数字代表工作量。

  • Product Owner讲解需求后,每个人各自评估,让后大家一起出牌(没有扑克牌,把工作量写在纸条上;也可以在微信群里,大家一起发工作量)
  • 数值最大的和最小的人可以展开讨论,把认识不一致的地方讨论清楚
  • 大家重新评估,直到达成比较接近的结果

需要注意的几点:

  • Scrum团队一起参与评估。 一起评估能消除对需求理解不一致的地方;促使每个人都进行思考;评估任务的时候,不知道谁会领这个任务
  • Product Owner不参与工作量评估,但是最好在现场,解释需求理解不清楚的地方,并且可以对评估的工作量做出判断

3. 每日站会

  团队每天进行15分钟的碰头会就称为Scrum每日例会。每日例会可以增强交流沟通、省略其他会议、确定并排除开发遇到的障碍、强调和提倡快速决策、提高每个成员对项目的认知程度。
  每日例会在各个Sprint都是在同一时间,同一地点进行。会议上,每个团队成员在任务看板前说3件事:

  1. 已经做了什么
  2. 接下来做什么
  3. 遇到了什么问题

注意事项:

  • 不要超出限制时间
  • 不要讨论技术问题
  • 不要转变会议话题
  • Scrum Master/leader不要提出问题,团队成员不要向 Scrum Master 或管理层人员报告

站会时,更新任务看板。
在这里插入图片描述


4. Sprint 演示

  Scrum 团队在会议中向最终用户展示工作成果,团队成员希望得到反馈,并以之创建或变更 Backlog 条目。
  只演示"Done"的任务,即可以随时上线的任务,没有"Done"的任务算失败任务,没有完成,留到下个Sprint,完成后演示。

为什么我们坚持所有的sprint都结束于演示 :

  • 团队的成果得到认可。他们会感觉很好
  • 其他人可以了解你的团队在做些什么
  • 演示可以吸引相关干系人的注意,并得到重要反馈
  • 演示是(或者说应该是)一种社会活动,不同的团队可以在这里相互交流,讨论各自的工作。这很有意义
  • 演示会迫使团队真正完成一些工作,进行发布(即使是只在测试环境中)。如果没有演示,我们就会总是得到些99%完成的工作。有了演示以后,也许我们完成的事情会变少,但它们是真正完成的。这比得到一堆貌似完成的工作要好得多,而且后者还会污染下一个 sprint

5. Sprint 回顾

  Scrum中Sprint计划会议是最重要的事件,第二重要的事件就是回顾会议,因为这是团队做改进的最佳时机。如果没有回顾,就会发现团队在重犯相同的错误。
回顾分两部分:
1)回顾完成的工作
2)准备一个回顾白板,分三列:

  • Good:如果重做同一个sprint,哪些做法可以保持
  • Could have done better:如果重做同一个sprint,哪些做法需要改变
  • Improvements:有关将来如何改进的具体想法

Improvements部分形成改进计划,在后续的Sprint中执行。


Scrum检查列表

图片替换文本

SCRUM理论基础

 Scrum以经验性过程控制理论(经验主义)做为理论基础的过程。经验主义主张知识源于经验, 以及基于已知的东西做决定。
Scrum 采用迭代、增量的方法来优化可预见性并控制风险。

  1. 透明性:在软件开发过程的各个环节保持高度的可见性,影响交付成果的各个方面对于参与交付的所有人、管理生产结果的人保持透明
  2. 检验: 开发过程中的各方面必须做到足够频繁地检验,确保能够及时发现过程中的重大偏差
  3. 适应: 如果检验人员检验的时候发现过程中的一个或多个方面不满足验收标准,并且最终产品是不合格的,那么便需要对过程或是材料进行调整。调整工作必须尽快实施,以减少进一步的偏差

 Scrum中有三个进行检验和适应的时刻:每日例会是用来检验朝向Sprint目标的工作进程,调整以优化次日的工作价值。另外,Sprint评审和计划会议是用来检验朝向发布目标的工作进程,调整以优化下一个Sprint的价值。最后,Sprint回顾会议是用来评审完成的Sprint,并确定什么样的调整可以使下一Sprint的效率更高、结果更令人满意和更易于工作。


一些实践总结

  1. Sprint全员参与需求讲解和Sprint的任务拆分
  2. 大的功能模块,需要一起讨论方案,写架构、设计文档
  3. 一个Sprint中,需求尽量保持稳定
    有大的变更,重新评估时间,调整任务。把紧急的任务放进Sprint,同时移出一些任务,但是Sprint的结束时间最好不变。
  4. Sprint Task由团队成员自己领取,不采用分配的方式
    虽然大的项目中,每个人有自己最熟悉的模块。但是自由领取Task有利于队员去做不同的模块,加快知识传播
  5. 除了产品需求迭代任务,适当安排技术优化任务
    技术优化任务对系统的稳定很重要,而且团队一般有前端开发,后端开发和测试人员,不同的Sprint,前后端、测试的工作量不一定都饱和,可以见缝插针的安排技术优化任务。
  6. 如果团队有固定的客户支持,技术支持任务,把这部分时间预留出来
    比如每周预留1~2天。

参考资料

  1. 硝烟中的Scrum和XP
  2. 敏捷联盟
©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页