Day1 敏捷入门关于敏捷和Scrum你必须知道的那些事儿

Posted 2021-04-25 百丽敏捷工作坊

Day1 【敏捷入门】关于敏捷和Scrum你必须知道的那些事儿

2019-03-19 12:00:40

全世界只有不到 1% 的人会朝着自己的梦想行动

你真是个特别的人

                   

7天训练营-Day1

“敏捷”作为一种新型的管理模式，正在被越来越多的行业实践。

目前，市面上关于敏捷的培训鱼龙混杂，不一致甚至是混淆的信息，往往让学习者迷失了方向。

作为国内首批指导敏捷落地的咨询团队，敏捷行动派通过调研圈内数百位敏捷人，决定推出一套针对敏捷新人的7天训练营。

7天训练营旨在帮助新人接受正统的敏捷知识导入，建立对敏捷管理模式的认知，以理论加案例的课程结构，班主任带学的模式，完成整套敏捷体系的搭建。

Day1的课程我们将着重解决以下5个方向的问题：

1 敏捷到底是什么，它和瀑布有什么区别？

2 敏捷适用于哪些状况，不适用与哪些状况？

3 敏捷宣言究竟是什么呢？

4 敏捷和Scrum的关系是什么?

5 适合实践Scrum的项目有哪些特点？

敏捷VS瀑布

先讲个小故事：

A公司想要开发一款社交软件，

第一种方式：

按照已有的制定计划，需求分析，软件设计，程序编写，软件测试和运行维护的传统开发模式进行，一年后终于将这款可以取代手机短信的软件正式推出。

软件推出市场后一个月，客服频繁收到用户的反馈：聊天的界面不能切换；不能发送图片；无法语音等等。

在被用户质疑，并被一部分用户弃用后，A公司开始重新按照反馈更新软件，才发现很多问题需要推翻之前的版本才能修复，将会耗费很长的时间。

第二种方式：

B公司在考虑做这款社交软件时，并不是按照上述流程进行，而是先按照业务价值对需求排序，团队采用固定周期（2周）的方式根据业务价值优先级排序进行开发，每个月月初（X月1日）内推出一个可以上线的版本。

推出后及时从用户处得到反馈，并且参照用户的反馈建议在第一个版本上作出修改，然后快速推出第二个版本。6个月后就获得了一个市场认可的产品

你觉得哪种方案更好呢？

第一种就是传统的瀑布开发模式。

第二种则是敏捷开发模式。

看完上面的介绍，你对瀑布和敏捷是不是有了一些理解？

瀑布开发

任务已设计制定，并且在工作中使用如Gantt (甘特)图表等工具和Microsoft Project项目管理软件。开发团队预计开发项目的时间是通过累加相关每一步骤而得出的。

     

当项目管理者(stakeholder)全面审核开发计划并表示赞同，开发团队即开始工作。团队成员完成他们所专长的部分工作，即刻转交给其他成员，形成生产流水线的形式。

所以，瀑布开发最大的优点就是极具逻辑性：

在构建之前思考，并全部记录下来，按照计划实施，保持各项事务尽可能的有组织性。

采用瀑布开发这种按照既定模式按部就班的方式时，我们经常会看到团队成员之间出现争执：

“他要求我构建在规范要求中不存在的东西。”

“她经常改变主意。”

“我不可能对我不能控制的东西负任何的责任。”

敏捷开发

敏捷开发方法是，通过自组织的跨职能团队与客户的协作努力，而不断发展需求和解决方案。

它提倡适应性规划、演进式开发、经验主义知识和持续改进, 并鼓励对变化作出快速和灵活的反应。它有以下特性：

迭代的、增量的和演进的

大多数敏捷开发方法将开发工作分成很小的增量, 最大限度地减少前期规划和设计的数量。迭代通常持续较短时间，一般是一周至四周。

在迭代结束时, 将向利益干系人（通常是理解为客户），演示可以工作的产品。这最大限度地降低了整体风险, 并使产品能够快速适应变化。

迭代的目标是在每次迭代结束时都有一个可用的版本 (最少的 Bug)。由于迭代时间很短，可能不能在一个迭代保证有足够的功能来发布产品，因而发布新功能可能需要多次迭代。

高效且面对面的沟通

非常短的反馈循环和调整周期

敏捷软件开发的一个共同特点是每日站立 (也称为每日Scrum)。在简短的会议中, 团队成员将在会议中陈述他们前一天所做的工作、今天打算做的工作以及可能遭遇的任何障碍。

以质量为中心

特定的工具和技术, 如持续集成、自动化单元测试、结对编程等其他技术，都是旨在提高质量, 提高产品开发的敏捷性。同时要保证至少在每次迭代结束时, 为客户演示可交付的产品。

总结

敏捷开发和瀑布之间的区别之一是质量和测试的方法。在瀑布模型中, 在构建阶段之后总是有一个单独的测试阶段;但是, 在敏捷软件开发中, 测试是在与编程相同的迭代中完成的。

另一个区别是, 传统的 "瀑布" 软件开发通过各种软件开发生命周期 (SDLC) 阶段移动一个项目。当一个阶段全部完成, 再进入下一阶段。

因为测试是在每次迭代中完成的，所以用户可以经常使用这些新发布的产品并验证其价值。在用户了解了更新后的产品的真正价值后, 他们可以对产品的未来做出更好的决定。

在每次迭代中进行必要的评审会议， 可帮助团队不断调整计划, 最大限度地发挥产品交付的价值。这有点类似于 PDCA 的模式。

这种迭代方法支持的是产品思维方式, 而不是项目思维方式。它为整个开发过程中提供了更大的灵活性;而在传统项目中, 需求从一开始就被定义和锁定, 很难去更改它们。迭代产品开发能够根据业务环境或市场要求的变化而适时调整。

Day1-『敏捷入门』

瀑布开发要求有明确的需求，按照需求一步步提前做好规划，在项目运作过程中严格产出各种文档，按着流程一步步走下去。所以瀑布开发一般适用于需求比较明确，且较稳定的大型项目。

敏捷开发的核心是快速迭代，拥抱变化。本着让客户满意的最终目标，主动接受需求变更，其设计的产品更有灵活性。

敏捷的适用VS不适用

敏捷这么厉害，那我们所有开发团队都要用敏捷吗？

NO NO NO!

我们拒绝所有一切盲目高举“敏捷大法好”“敏捷万岁”旗帜的做法。敏捷只是人们工作方式发展产生的其中一种管理模式。

它不是放之四海而皆准，而是量体裁衣。

哪些情况适合用敏捷？

1、产品较复杂，而且不断有新的需求加入。

如果产品的开发与市场关联明显，那么业务需求的变动就会频繁，此时，需求管理的工作就显得特别重要。

敏捷提倡的需求拆分，即复杂的需求拆分成一个个小任务，根据任务的轻重缓急列出优先级，每个任务需要几天的工作量，通过便利贴或是电子看板直接可视化，帮助研发团队提升工作效率。

2、团队规模庞大，沟通协作的效率低。

如果需要多个部门一起协作研发一款产品，团队内部的沟通将会占很大的比重，或许有些功能只需要2-3分钟，有些调整则需要更长时间。

如果有一个固定的时间，让大家定时开站会，大家一起同步目前的进度，并了解到别人的工作可能卡在自己的工作部分，或者是需要一起配合才能完成工作，团队的效率将大幅提升。

3、内部希望高效地管理开发进度。

延迟交付已经成了惯象，事实上，不管是产品经理还是项目负责人，都希望能够准确地掌握各项工作的状态。

敏捷将项目的进度更加清晰得呈现出来，便于我们对项目进行监控和跟踪，从而及时发现问题，及时做出调整，及时试错，快速迭代。

哪些情况不适合用敏捷？

1、工作量较小，且持续时间比较短的项目或产品

比如说明确的修复几个Bug，而且修复也不会引发其他问题，需求很明确，时间也很短促，这种情况就用不着采用敏捷，传统的方法绝对能够很快就解决问题。

2、项目复杂程度高，而且产品属于一次性交付，通常不能返工或者返工的成本非常高昂。

瀑布式最早应用于火箭发射，像这种产品就很难用敏捷去完全实现，你可能需要将其中一些场景或者环节拿出来实施敏捷，而比如说落地施工制造和发射的过程仍旧需要按照瀑布的方法去完成。

Day1-『敏捷入门』

一般来说，符合迭代式开发，要求交付用户价值，而且是高质量的产品时，就可以考虑采用敏捷；

如果时太简单的项目，或者项目复杂且多为一次性交付使用的产品，我们不建议使用敏捷来完成。

敏捷宣言究竟是什么呢？

很久很久以前，大概是第一批90后出生的年代，为了应对已经被很多人诟病的重量级开发方法，一些轻量级软件开发方法已然喷薄欲出。

这中间就包括: 1991年起的快速应用程序开发 (RAD); 

1994年起的统一过程 (UP) 和动态系统开发方法 (DSDM);开始于1995年的Scrum;还有在国内耳熟能详的极限编程 (XP), 也是起始于 1996年。

尽管这些都起源于敏捷宣言发布之前, 但它们现在统称为敏捷软件开发方法。与此同时, 制造业和航空航天也在发生类似的深刻变化。

2001年, 17位软件开发大咖在犹他州雪鸟的一个度假村会面, 重点讨论了这些轻量级开发方法，讨论的结果是他们一起发表了《敏捷软件开发宣言》，至此，敏捷领域的“圣经”就诞生了。

敏捷宣言

敏捷宣言包括4个价值观和12条原则。

敏捷软件开发价值观

这17位大咖结合它们在软件开发和帮助他人开发软件方面的多年经验, 郑重宣布敏捷的价值就是：

个体与互动 高于 流程和工具

工作的软件 高于 详尽的文档

客户合作 高于 合同谈判

响应变化 高于 遵循计划

也就是说, 左边的项目比右边的价值更高，但并不是右边的不重要哦。

正如Scott Ambler所阐明的:

1.工具和流程很重要, 但更重要的是让有能力的人之间更有效的合作。

2.好的文档在帮助人们了解软件是如何构建以及如何使用方面是有非常有用的, 但开发的要点是创建软件, 而不是文档。

3.合同很重要, 但它远不能替代与客户密切合作, 真正发现他们需要什么。

4.项目计划很重要, 但别搞的那么僵化, 无法适应技术或环境的变化，应当及时处理利益相关者的优先事项，促进人们对问题及解决办法的理解。

敏捷运动并不是反方法论的, 事实上, 我们很多人都希望恢复 "方法论" 一词的可信度。

我们要做到平衡，接受建模, 但不是为了在尘土飞扬的公司存储库中归档一些图表；接受文档, 但不包括数百页从未维护和使用过的书卷；制定计划, 但认识到在不确定的环境中规划的局限性。

那些将 XP 或 SCRUM 的支持者或任何其他敏捷方法符号标记为 "黑客" 的人, 既对方法论知之甚少，也不知道黑客一词的初衷要义。

敏捷软件开发的原则

敏捷宣言还包括以下更具实践价值的12项原则:

1.我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。

2.欣然面对需求变化，即使在开发后期也一样。为了使客户获得竞争优势，敏捷掌握过程变化。

3.经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。

4.业务人员和开发人员必须相互合作，项目中的每一天都不例外。

5.激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。

6.不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。

7.可工作的软件是进度的首要度量标准。

8.敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。

9.坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。

10.以简洁为本，它是极力减少不必要工作量的艺术。

11.最好的架构、需求和设计出自自组织团队。

12.团队定期地反思如何能提高成效，并依此调整自身的举止表现。

好了现在大家知道了，在2001年17位软件开发大咖基于已经存在的轻量级软件开发方法在犹他州雪鸟度假村进行讨论，并最终发表了敏捷宣言。

     

但是为什么敏捷往往跟Scrum放到一起呢？我们经常会听到某某公司招聘Scrum Master他们正在做敏捷转型之类的话。让我们来细说一下。

敏捷和Scrum的关系是什么

“Scrum”一词来自1986年的哈佛商业评论文章，其中作者Hirotaka Takeuchi和Ikujiro Nonaka将高性能，跨职能团队与橄榄球队使用的Scrum形成进行了比较。

1993年，Jeff Sutherland和他在Easel公司的团队把1986年那篇文章中的概念与面向对象开发、基于经验的过程控制、迭代和增量开发、软件过程和生产率研究、复杂适应系统中的概念结合起来，创立了用于指导软件开发工作的Scrum过程。

1995年，Ken Schwaber在OOPSLA 1995（Schwaber 1995）上发表第一篇关于Scrum的论文。

Scrum的创始人Jeff Sutherland和Ken Schwaber是2001年发布敏捷宣言的17人中的两人。

另外在敏捷开发的实践过程中, 大部分人认为Scrum 提供了基础, 在Scrum的基础上, 添加其他元素来本地化和适应文化来进行敏捷实践。根据Version One 2018的敏捷报告显示，敏捷开发使用Scrum框架占56%。

简单地说，Scrum是一种大家在敏捷开发中最常使用的框架。

     

Scrum的定义

Scrum是一套简单但功能强大的原则和实践，可帮助团队在短周期内交付产品，实现快速反馈，持续改进和快速适应变化。

自20世纪90年代初以来，Scrum一直用于管理复杂产品的工作。 Scrum属于“敏捷”，这是完成任何复杂，创新工作范围的几种方法的总称。这个概念是将大型项目分解为更小的阶段，在过程中进行审查和调整。

Scrum 是一个轻量级、迭代和增量的框架, 用于管理产品开发。它定义了 "一个灵活、全面的产品开发战略, 开发团队作为一个整体工作, 以达成一个共同的目标",对 "传统的、瀑布的方法"的假设与产品开发提出挑战, 并使团队能够通过鼓励所有团队成员, 以及和相关学科之间的日常面对面沟通（包括坐在一起或在线紧密的合作），进行自组织。

Scrum 的一个关键原则是双重认识到客户将改变他们对自己想要或需要什么 (通常称为需求波动) 的想法, 并且会出现不可预知的挑战, 而预测或计划的方法并不适合这样做。

因此, Scrum 采用了基于证据的经验方法--接受无法事先完全理解或定义问题的现状, 专注于如何最大限度地提高团队快速交付、应对新出现的需求和适应新需求的能力。

Day1-『敏捷入门』

关于Scrum的起源，推荐一篇生动活泼的图文版介绍《打飞机最厉害的敏捷教练，了解一下》，Scrum的详细将会在Day2的课程中开展。

什么项目适合使用Scrum

那么，具体哪些项目适合使用Scrum呢？

这也是大家关心的问题。Todd Little,作为敏捷联盟的成员和敏捷项目领导力网络的共同创始人，就提出了一个新项目分类框架，基于项目内在的不确定性和复杂程度将项目分为公牛型，小马型，母牛型或小狗型。

     

小狗队（简单的，低不确定性的团队）

通常是成熟的产品开发小团队，不是特别复杂，无太多不确定性。在这个象限里，还有一些臭鼬型团队，他们可能存在短期的不确定性，但是持续时间非常短。

附加的流程仪式和文档是不必要的，低效的。运行这个象限的项目时，只使用我们所使用的最小核心实践集。对于我们的投资组合，这个象限覆盖了大约60%的项目。

小马队（简单的，高不确定性的项目）

新产品团队，通常既有市场又有技术不确定性。如果团队规模很小，他们就能快速反应，适应不确定性。

大多数项目团队都取得了成功的极限编程，就属于这一象限，大约20%的项目是小马队。

奶牛队（复杂的，低不确定性的项目）

成熟的产品和配套的产品，不断推出大型项目的团队。通常是公司的摇钱树组织。牛是这些项目的一个很好的比喻，它们相当大，但移动并不特别快。

这些项目对敏捷指导的需求通常较少，是否真的需要严格的变更控制以减少影响时，有很多依赖的项目或客户。他们还需要更直接的项目和程序管理，看关键路径和跨团队等问题沟通。对于我们的投资组合，奶牛约占我们项目的10%。

公牛队（复杂的，高不确定性的项目）

非常复杂的项目,不确定性在所有方面都造成了问题。他们需要非常敏捷，以便在不确定性中进行引导。他们需要一些过程仪式来管理项目的复杂性。

公牛的比喻很恰当。这些项目很大，可能会很快失控。期望很高，但不确定性和复杂性也同样高。这些项目需要很多与牛的过程仪式相同，但必须是以支持敏捷转向的方式构建。迭代必须更加频繁，沟通渠道必须非常有效。对于我们的投资组合，奶牛约占我们项目的10%。

该框架可应用于选择试点Scrum项目，选择时则尽可能避免那些被Todd Little称作公牛型的项目（高不确定性和高复杂性的作用）。

敏捷是一种心态

最终, 敏捷是一种以敏捷宣言所载价值观和敏捷宣言背后的12项原则为指导的心态。这些价值观和原则为如何创造和应对变化以及如何应对不确定性提供了指导。

你可以说, 敏捷宣言的第一句概括了整个想法: "我们正在通过这样做和帮助别人来发现开发软件的更好方法"，当你面对不确定因素时, 尝试一些你认为可行的东西, 获得反馈, 并做出相应的调整。

Day1-『敏捷入门』

不是所有的团队都适合Scrum，不是所有的项目都适合Scrum，团队成员不适应更换的成本和项目不适应带来的成本，都是不容忽视的。

所以在实行Scrum前，前期的考察与评估是必须做好。

     

Day2课程预报

理解了敏捷的产生和工作原理，Day2的课程我们将会重点讲述Scrum的开发流程，3355到底是讲什么，为什么有那么多的会议，这些所谓的事件的实际价值是什么，以及落地时的GASP到底是什么，有什么用处。

我们明天见！