Scrum转型(一) 为什么敏捷和Scrum

1.1 为什么敏捷

由于传统的瀑布模型管理方法无法满足现代某些软件产品开发过程的特点，我们需要使用敏捷的方法（例如，Scrum是一个让我们关注于在短时间里交付高质量商业价值的敏捷框架）。

需求频繁变动，技术不确定，这正式传统管理方法不满足现在软件产品开发的两个突出问题。因为传统管理方法不满足需要，才出现了敏捷的方法。

需求不明确是指：虽然对要做一个怎么的产品有规划，但是并不明确和确定所有的功能细节；并且随着产品的开发，极有可能对产品功能不断地改变以适应最终用户的需求。这种情况经常发生对全新概念的产品的开发过程中。

技术的不确定性指的是：技术的发展日新月异，对于所定义功能的可实现性面临着多重不确定性的因素。

实施Scrum对组织和项目的好处：
1.更高的生产力和更低的成本
2.员工的参与度与工作满意度增加
3.更快的产品上市时间
4.更高的质量
5.项目干系人满意度提升

1.2 什么是敏捷

敏捷方式的核心思想在于迅速把产品投放给用户来为公司带来盈利，敏捷的特点是迭代和增量。

对于公司来说，敏捷开发的目的就是尽早开发出可以工作的产品给用户赢得市场带来的利润。在产品投放市场以后，通过客户的反馈，公司可以继续改进产品功能。而实现这一目的的过程就是，项目被分成若干个迭代，每段时间里开发出一部分产品功能（增量），并且按照计划将这些功能投放到市场成为为公司盈利的产品。与传统管理方法提前做好计划，尽量规避变化的管理方式不同，敏捷拥抱需求和技术的变化，认为需求和技术的不明确和变化是必然的。 

1.4 敏捷宣言

敏捷宣言是敏捷的根本，它由两部分组成，分别是敏捷价值观和敏捷原则。

敏捷宣言：
1.个体和互动高于流程和工具：敏捷强调‘人’，人最清楚如何完成工作，要尊重人的意见和想法。
2.工作的软件高于详尽的文档：这里强调的是要把重点放在工作的软件上，让文档服务于软件，而不是把工作聚焦放在文档上。
3.客户合作高于合同谈判：和合作方创建良好的合作关系共同解决问题要比逐条谈判合同细节更重要。
4.响应变化高于遵循计划：我们认为变化是一件好事，项目是流动的，因此项目有变化是正常的，必须随时调整。

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

1.5 敏捷之伞

按照敏捷之伞的划分，可以将敏捷的各种方法分为两个部分。一个部分是轻量级的方法（服务于单个团队的方法），另一部分是服务于多个敏捷团队的方法。在轻量级方法中，又可以从方法的问题这个角度将它们分为两类，其中，Scrum, Kanban都是生产产品的框架，用于产品开发或工作管理。而XP(极限编程)，FDD(特性驱动开发)则是工程实践类的方法。敏捷之伞的另外一部分是服务于多个团队的方法，根据不同的项目规模和团队之间的耦合度，有多个方法来协调敏捷团队的协同工作（如SAFe,Scrum-of-Scrums,LeSS等）。

Scrum:作为最受欢迎，使用最为广泛的敏捷方法，Scrum是一种迭代的增量化过程，用于产品开发或工作管理。
它是一种可集合各种开发实践的经验化过程框架。

Kanban:是一种源于丰田精益化管理的方法，它是仅次于Scrum的另外一种敏捷开发的框架方法。它有以下特点：流程可视化，
限制WIP(Work In Progress,在制品数量)，度量生产迭代（没有固定时长的迭代）。相对于Scrum更适合于开发新产品，
Kanban则更加适合于运营团队实施敏捷的使用。

XP: 极限编程，XP注重的核心是沟通，简明，反馈和勇气。因为知道计划永远赶不上变化，
XP无需开发人员在软件开始之初期写出很多的文档。XP提倡测试先行，为了将以后出现bug的概率将到最低。
在XP的12个团队实践中，TDD（测试驱动开发）是其中之一。它的原理是在开发功能代码之前，
先编写单元测试用例代码，测试代码确定编写什么产品代码，即通过测试驱动整个开发的进行。

FDD：特性驱动开发，FDD是一套针对中小型软件开发项目的开发模式，是一个模型驱动的快速迭代开发过程，
它强调的是简化，实用，易于被开发团队接受，适用于需求经常变动的项目。

Scrum-of-Scrums: SoS是一种管理大型的Scrum团队的技术（团队多于12人，被划分5～10人一组的Scrum小组）。
每个小组都选出一名代表成员去参加所在团队的每日会议。根据不同团队的需求，根据不同团队的需求，
这些代表可以是工程师或ScrumMaster。通过SoS会议达到小组之间的信息同步，解决问题的目的。

SAFe: The Scaled Agile Framework是一个企业及的敏捷管理框架，适用于管理大型的Scrum团队。
SAFe框架提供了三层管理模型，分别由项目组合，项目集，实施团队构成。 

1.6 敏捷怎么工作

1.创建一个人物列表

项目组需要和产品负责人一起讨论，并且由产品负责人创建一个关于‘Scrum电子任务板’应包括的功能列表。在这里我们使用用户故事来描述这些功能，我们称每一个要完成的功能为一个用户故事。

2.给任务标记工作量大小

使用敏捷的估算技术，给这些故事彼此之间相对的任务大小并且估算完成这些故事需要的时间。 

3.给故事设置优先级

项目组需要和产品负责人确认每一个故事的优先级，以便保证一直处理高优先级的任务。

4.开始执行

5.根据项目实际情况更改计划

在项目的进行中，团队先后碰到以下两种情况。

（1）项目进行的比预期的要快。（2）有太多事情要做，时间不够用

此时，项目组可以有以下两个选择。

（1）少做一些，缩减一部分功能范围（推荐做法）。

（2）加紧做，加班也要完成。

1.7 敏捷和瀑布模型的区别

瀑布模型是一个迭代模型，一般情况下将其分为计划，需求分析，概要设计，详细设计，编码以及单元测试，测试，运行维护几个阶段。瀑布模型的迭代是环环相扣的，每个迭代中交互点都是一个里程碑，上一个迭代的结束需要输出结果作为下一个迭代的输入。这样，当某一个阶段出现了不可控的问题的时候，就会导致返工，返回到上一个阶段，甚至会延迟下一个阶段。

瀑布模型的弊端：

1.质量不高
当发现项目已经没有钱和时间的时候，测试已经成为唯一剩下的还没有做的事情。这就意味着项目必须剪掉测试的时间和预算，因此，产品质量就必须定出问题。

2.可见性不高
因为直到项目的最后才能看到产品，在瀑布模型的项目里，你永远不知道你真正在哪。项目的最后20%经常花费80%的时间。

3.太多风险
在项目一开始你就有风险：首先，你有时间安排上的风险，因为你永远不知道项目会在什么时候完成；接下来，你有技术上的风险，
因为你只有在项目的最后测试阶段才会知道你的设计和架构问题；最后你还有产品上的风险，因为你根本不知道是否开发一个正确的产品，
直到项目的后期无论做什么任何变化都已经太晚了。

4.无法应对变化
瀑布模型是环环相扣的迭代模型，是无法应对变化的。

敏捷有以下特点：

1，需求分析，设计，编码和测试的工作是持续进行的。
2，产品开发过程是迭代的。
3，计划更加灵活，可以调整
4，项目成员为了同一个目标努力，做出力所能及的奉献；而不强调‘角色’的分工和明确的职责划分。
5，拥抱变化，及时调整。
6，交付可工作的软件是最重要的衡量项目是否成功的标志。

1.8 什么是Scrum

Scrum是一个框架，在此框架中人们可以解决复杂的自适应难题，同时也能高效并创造性地交付尽可能高价值的产品。Scurm作为一个框架，它的最大特点就是迭代和增量。项目以一个迭代接着一个迭代的方式运转，么哥迭代的产出就是产品增量。在迭代当中，项目组每天都进行检查和调整。每个迭代的工作内容就是实现产品列表上的功能。

Scrum的工作方式：在每一个迭代开始的时候，Scrum团队找出他们要做的产品列表条目。然后开始在这些条目上工作。并且在迭代结束的时候完成这些条目成为潜在可发布的产品增量。在日常开发中，我们经常定义迭代名为Sprint 1, Sprint 2,...Sprint N,这里Sprint就是冲刺的意思。

Scrum大概会如下面过程：

冲刺工作前的工作
（1）组建Scrum团队。
（2）首先确定冲刺长度是两周。
（3）准备好产品列表。

冲刺当中的工作
（1）计划：团队从产品列表中选择优先级最高的一两个（具体取决于团队能力和故事的难度）用户故事。
（2）工作于计划的用户故事（）召开每日站会以便随时进行检视和调整
（3）在冲刺结束前完成这些功能，提交潜在可发布的增量（也许立即发布，也许以后发布，什么时候发布取决于产品发布策略）。
（4）召开评审和回顾会议。

1.9 Scrum框架

Scrum通过三个角色----产品负责人，ScrumMaster，开发团队----来完成一系列的流程：计划会议，每日站会，评审会议，回顾会议，工件，产品列表，冲刺列表，潜在可交付产品增量以实现迭代，增量开发。

产品负责人是有授权的产品领导力核心，一方面他担任着产品经理的角色以确保能开发出正确的解决方案，另一方面他还必须和开发团队交流以保证
特性的接受标准有明确的说明（用户故事）并且已经满足后续需要运行测试验收的标准，以确保特性完成（业务分析师和测试人员的部分工作）。
这个角色责任重大，负责构建正确的产品。

ScrumMaster负责帮助每个人理解并乐于接受Scrum的价值观，原则和实践。对于团队和产品负责人来说，ScrumMaster履行的是教练，
过程领导的职责。他负责帮助团队和组织其他成员发展具有组织特色的高效的Scrum方法。

开发团队是主任工程师，开发，测试工程师，数据库管理员，界面设计工程师和其他传统软件开发方法当中定义的不同工作类型的
所有类型的人的跨职能的集合。开发团队负责用正确的方法构建产品。

冲刺（Sprint）是Scrum的核心，它的持续时间为一个月或者更短（两周时间最为普遍），在这段时间内构建产品增量。
在整个开发过程中，Sprint的长度都应尽量保持一致。前一个Sprint结束后，下一个Sprint紧接着立即开始。

潜在可发布产品增量：在冲刺结束时，团队应当得到一个潜在可发布的产品或者产品增量。如果业务上合适，就可以发布；
如果不合适在每次冲刺后发布，可以把多个冲刺的一组特性合并在一起发布。

产品列表：是一个优先级排序的，有粗略估算的，成功开发产品所需特性及其它功能的列表。在产品列表的指导下，
我们总是优先做优先级最高的条目。换句话说就是，当一个冲刺完成时，已完成的条目都是优先级最高的。

冲刺计划会： 一般情况下，产品列表中的工作量远远不是一个短期冲刺内能够完成的。所以冲刺开始的，
团队需要定制计划，说明一下冲刺中要创建产品列表中的哪几个高优先级的特性（生产Spint列表）。

Sprint列表（也称待办列表）：是一组当前Sprint选出的产品待办列表项，同时加上交付产品增量和实现
Scrum目标的计划（包括每个待办列表项完成所需的估算等）。


冲刺评审会和回顾会：在冲刺结束时，团队与利益干系人一起评审已经完成的特性，获得它们的反馈产品负责人和
团队既可以对下一步工作内容进行修改（在评审会上），也可以修改以前的工作方式（在回顾会议上）。评审会议，
如果利益干系人在看到一个完成特性时，意识到自己没有考虑到另一个必须包含在产品中的特性。此时，
产品负责人只要建立一个代表该特性的新条目，并把它以适当的顺序插入到产品列表，留到后面的冲刺中完成。
回顾会上，如果开发团队在回顾冲刺过程中，意识到自己没有考虑到依赖风险导致开发过程不必要的等待时，
开发团队可以提出下一个冲刺计划会上考虑依赖风险并做好相应的控制。

每日站会是整个Scrum里面非常有特色的一个会议。开发团队一个限制在15分钟内的会议。名副其实，
每日站会需要每天都举行。这个会议的目的是实现开发团队每天对完成Sprint目标的进度和
Sprint待办列表的工作进度趋势的检视，并且作出相应的调整和适应。

ScrumMaster在正式开始Sprint 1之前和团队一起确认了Sprint的长度，开始和结束时间，各个会议的具体时间和与会人员，产品列表和Sprint列表中所应该包括的内容等。在Sprint 1 开始的第一天，SM按照与大家约定组织召开项目组的第一个会议。在会议上，产品负责人向开发团队解释了产品列表当中优先级最高的几个用户故事，并且表示这些用户故事是他希望可以尽快完成的功能。在会议上，开发团队的工程师们向产品负责人提出用户故事对应的一些功能性的问题。在对功能清晰以后，SM指导开发团队开始对每一个用户故事的工作量进行估算。SM帮助大家澄清如何才能进行正确的估算，估算后的结果如何记录，估算和实际工作量之间的关系等问题。

下面是一份团队转型的评估要素：

1 表示完全不不符合 6 表示完全符合

分数< 27: 项目不适合转型

27<分数<40:项目适合转型

分数>40:项目非常适合转型

 对于第7点的解释：如果以前的项目做的很糟糕，感觉已经无药可救，那么转型带来的变化再在糟糕也不会比以前糟糕了，所以说在这种团队非常适合转型。

 对于第8点的解释：因为试点团队的转型对公司未来整体转型具有重要意义，所以我们建议一定要在重点项目上进行试点，这样才能暴露问题。在非重要项目中进行转型，无法积累足够的经验，也就无法引起足够的重视。

1.10 实践类问题

1.10.1 我可以同时实践Scrum和PRINCE2吗 

PRINCE2是一个过程驱动的项目管理方法论。它是基于7个基本原则的：持续的业务验证，经验学习，角色与责任，按阶段管理，例外管理，关注产品，根据项目环境剪裁。PRINCE2关注于项目的计划和控制。推荐《敏控创变》讲解柔实践Scrum和PRINCE2。

1.10.2 Scrum是否可以部分应用

Scrum就像下国际象棋要么遵守游戏规则，要么不遵守。如果只使用部分Scrum管理项目，那就不叫Scrum项目。不建议公司对Scrum团队定制太多的“流程”，“规定”，“标准”，只要Scrum团队按照《Scrum指南》里的各部分去做就好，应该尽量给各个团队留下足够的管理空间。

1.10.3 我什么时候不能用Scrum

1.当你的项目不用Scurm也能运行的很好的时候
2.当团队跨国或者有外包参与的时候，Scrum就很难管理了
3.一些对需求很清晰的项目，也不必非要使用Scrum

1.10.4 Scrum可以在大型组织中实践吗

通常在大型组织中最大的阻碍就是人们拒绝任何改变。很多人都不相信Scrum真的对组织有用。大多数的组织都认为自己很特别，Scrum的规则不适用于他们。另外一些你可能听到争议是：质量控制对我们执行Scrum太重要了，我们的项目太复杂了以至于不能Scrum，高管不支持Scrum。。。在种时候，最好的办法是尝试从很小的变动开始，证明变化有效，然后慢慢推广。所以，在大型组织中推广Scrum容易吗？当然不，但是可以在大型组织可以推广Scrum吗？当然可以～

1.10.5 Scrum是一个框架不是一个方法

框架和方法之间的差别就在于，方式是一个防止四海皆准的，格式化的途径，就好比PRINCE2，PMP都是方法；但是框架相比之下就更灵活，它是一个平台，根据环境的不同，它可以提供一系列不同的途径。对于Scrum框架来说，遵守它的规则是最重要的。而它的所有规则都在《Scrum指南》当中。

到此敏捷Scrum入门相关的知识介绍完了～～