从零开始—Scrum团队敏捷转型实战案例

摘要简介：

摘要简介：

本文取自真实的敏捷SCRUM应用实践。笔者认为，敏捷方法的推行实施在企业中是一个系统的工程。本文从敏捷SCRUM的背景分析，推行准备，推行实施，推行总结几个方面来总结。

笔者在一家软件企业，承担某软件系统产品开发项目的项目管理。通过半年多的加班加点，带领团队完成了软件demo版的开发，CCBN展会上，很受客户欢迎。接下来，商务洽谈如火如荼，系统产品化开发迫在眉睫，可是，笔者深深清楚团队一路挣扎走来的现状，怎么做才能在3个月左右的时间里完成从DEMO版到产品化版本的开发？

1 背景分析

1.1 公司背景

公司是一家60人左右的软件公司，以研发、销售软件系统为主营业务。作为一家民营企业，讲究人尽其才，可喜的是公司组织结构分明，部门职责比较明确。

负责主管研发的领导有着多年的研发经验，对推行敏捷持支持态度。

1.2 团队背景

项目团队总计10余人。其中包括开发9人，测试4人，管理3人。根据所开发的软件系统特点，将全员分成6个小组，分别是管理组，开发组A, 开发组B，开发组C，测试组，产品组。

团队之前一直实行迭代开发，通过半年来的加班加点，终于完成系统DEMO版的开发。但是，已经是谈加班而色变，团队士气漂移不定。

团队对敏捷知之甚少。我作为项目经理，在项目中统一协调研发部、测试部、产品部。

1.3 项目背景

本项目主要目的是完成公司主营软件系统的产品化开发。依据IPD流程的定义，目前只是完成了基本的技术开发，下一阶段需要完成技术开发及产品化开发。

因为是产品化开发，产品开发面对的是行业内的某一类整体客户群体。所以项目需求宽泛，需求筛选、分析的难度较大。没有固定、明确的客户可以来针对性的沟通交流。虽然已经完成了DEMO版的开发，但是相关业务的具体实现和系统的功能性能指标确定实现等，还需要很长的路要走。

公司要求在3个月左右的时间里完成软件系统的技术开发及产品化开发，时间压力很大。如果持续的加班加点，恐怕引起团队震荡，要知道，当时可是刚过完春节的3月份，作为管理者，3月份是一个难捱的月份，也许突然什么时候，就会有团队成员找你沟通，然后从团队内消失离去，那你就能深切体会什么是铁打的营盘流水的兵了@@。

2 推行准备

2.1 自我准备

首先，自己买书，从网上读了大量敏捷方面的内容。在这里，向大家推荐两本书： 硝烟中的Scrum和XP和敏捷项目管理，都是老外写的。前一本深入浅出的介绍了SCRUM实践方法，而后一本从产品开发及项目管理的角度阐述了敏捷。

同时，与直接领导也做了大量的交流，最后，把要推广的目标锁定在SCRUM上。为什么？因为SCRUM是当下流行的敏捷开发方式，流行的必然有它流行的理由，SCRUM框架清晰，容易上手，充分体现了敏捷开发的特点；其次，SCRUM开发与项目团队之前的迭代开发有某些相似之处，便于成员接受执行。

然后，经过对比后，联系了一家敏捷培训的专业公司，在经过几次的沟通后，确定了让全体团队成员（包括相关领导）正式参加敏捷集训的日期。

好了，万事俱备，只欠东风。

2.2 培训内容准备

经过与敏捷培训公司的沟通，决定培训的内容包括如下：

重要内容：敏捷开发的讲解，向大家讲明敏捷开发的优势。

简单介绍：敏捷项目管理简介，向大家介绍敏捷项目管理的特点。

关键内容：SCRUM详细培训，向大家详细培训SCRUM的具体执行方法。

3 推行实施

3.1 集体培训

整个项目团队加上相关领导，在公司聘请专业的培训公司进行了为期2天的集体培训。（我也想时间长点，可是需要Money呀）

通过集体培训，整个团队感受了敏捷的气氛，了解了敏捷的含义，并初步了解了SCRUM的框架。

下一步，是骡子是马，该出来遛遛了。

3.2 SCRUM执行

培训结束后，团队按照自己项目的实际情况，开始严格按照SCRUM框架执行。

我们项目团队SCRUM执行如下。

首先，我们定义了SCRUM团队角色：

我由原来的项目经理，转换成Scrum master。

产品经理转换成Product Owner。

团队原来的职能分组仍然保留，但是大家达成一致，要按照敏捷团队高度自主的特性来进行自我管理和要求。

其次，我们确定了我们的SCRUM会议规则：

我们的sprint周期为2周（后来改为3周）；

Sprint 计划会议1、2，sprint评审，回顾会议每次2小时；

每日立会，每天早晨9:15准时开始，每次15分钟。

再次，我们确定了我们要使用的SCRUM工件：

Product backlog; Sprint backlog；看板；燃尽图。

最后我们定义了我们软件系统产品的产品愿景及我们在SCRUM执行中各种“完成”的检验标准，包括：

Product backlog中User story完成的标准；

Sprint backlog中Task完成的标准；

看板任务条移动的标准；

Sprint 评审完成的标准；

产品发布完成的标准。

接下来呢，别看广告看疗效，真是谁用谁知道呀！

3.3 执行小结

项目团队从推行SCRUM开始，经过3个月左右的战斗，终于完成了第一个产品化版本的开发，推向市场后，获得了客户的好评。

经过分析，笔者认为敏捷SCRUM给团队带来好的改善如下：

1. 团队项目流程方法清晰明确。较之之前的工作流程，SCRUM框架清晰，简洁，能够比较大的程度上减少流程制度给研发团队带来的迟滞。

2. 团队目标感增强。每一个sprint迭代，通过计划会议，都会使团队对sprint时间盒内要完成的工作目标异常清晰。

3. 团队沟通意识加强。SCRUM要求团队是高度自主，自组织管理的。大家在这个组织原则下可以进行更大可能的积极沟通，尤其是研发和测试人员，积极的沟通交流极大地提高了工作效率。

4. 团队成就感增强。每一次sprint评审会议，团队成员都会自豪的展示自己的工作成果，从而提升了成员的自信心和工作热情。

5. 产品质量加强，实现了快速增量交付。周期一致，有节奏感的sprint迭代，严格透明的评审，使团队中的每一个人都能够时刻关注工作质量，从而加强了产品质量。

整体来说，通过SCRUM框架的推行，可以说敏捷的工作理念已经渗入到整个项目团队，整个团队的工作绩效也得到了大幅度提升。而且从始至终，大家基本都保持了积极参与，热情高涨的工作状态（因为不怎么加班的缘故吧-_-！），这对于以创造性为主要特征的研发项目团队来说，无疑是最重要的。

4 推行总结

4.1 没有规矩，不成方圆

任何一个团队，想要做什么事情，必须有自己的工作规则。大企业有完善的流程制度，游击队有自己的战斗方针，可以根据自己的组织规模及实际情况来决定工作方法、规则的繁简，但是必须要有。

因为团队中的成员来自四面八方，不同的教育背景，工作经验、专业技能决定了大家对同一件事的看法必然存在着差异，这是正常现象。但是作为管理者，必须让大家心往一处想，劲往一处使，怎么办？要统一大家的思想，需要制定统一的规则并且去严格执行。所谓“洗脑”，就是这个道理。否则，就会公说公有理，婆说婆有理，最后谁都不服谁，更别说完成既定的工作目标了。

所以，我们的团队选择了统一的敏捷方法论作为我们工作规则制定的依据。

4.2 殚心竭虑，谨慎决策

做事之前，先想想。决策如果失误的话，后面再怎么做，只不过使错误得更离谱。

首先，要分析自己团队的实际情况，分析一下有哪些需要改进的地方。比如在推行敏捷之前，我们的团队是迭代开发、士气低迷；我们的软件开发是开发产品，需求不确定因素很多，但是时间压力还很大，要求成品尽快出来，销售正巴巴等着米下锅呢。

其次，要分析你所选择的新方法是否适合？敏捷SCRUM是很流行，可是，它是否适合我们团队？作为管理者，需要把这个问号想清楚。这就需要管理者自己先要把敏捷、SCRUM等有个较详细的了解，看它们的特点优势是否能够真正应对我们团队的现状。

再次，我们自己分析出来了敏捷可能适合我们的团队，那么下一步，我们需要获取高层领导的支持。任何改进，没有领导的支持，往往会适得其反，事倍功半。

4.3 外来的和尚会念经

这里有两个关键词，第一个是和尚。大家想到念经，大多数第一印象脑海中都会想到和尚，为什么？因为对于念经来说，和尚往往是最专业的。所以，我们要培训、要改进，一定要找个在这方面大家觉得专业的组织或者个人来做。因为专业，所以大家才容易信服。

第二个关键词是外来的。这里的外来可以是职能部门之外的，也可以是公司之外的，但是，一定要是团队之外的。为什么呢？大家对不熟悉的事物，都会存在神秘感，存在神秘感，大家对这个事物的特征、言行举止往往更好奇。陌生的专业人士，会降低大家的心理抵制度，能够大幅提升培训效果。

4.4 虚怀若谷，团队保持空杯心态

能否保持空杯心态，是衡量一个组织、个人学习能力健康度的重要依据。一个人，一个组织要想做出改变，必须先勇于接受外来的变化，只有先接受变化，然后在实践中去检验它的对错，吸取对的东西，扬弃错误的，才能螺旋式的上升，才能从优秀走向卓越。海纳百川，有容乃大。

切记的是，我们不要动不动就凭借自己以往的经验去轻易地下结论、下判断、去否定他人，我们可以在可控的预期内先试试看。

4.5 步步为营，循序渐进

对未来怀有愿景，但是要保持适度的期望值。在具体的方法改进中，要步步为营，不要期望一口就能吃成胖子，欲速则不达。

所以，敏捷的实施也要一步一步慢慢来，因为，敏捷工作方法不单纯是一种具体的工作方法，它还是一种方法论，价值观。对于人来说，改变对事物的看法很容易，改变认识事物的方法则不那么容易。敏捷方法追求自组织的管理，对于大多数团队来说，还是需要有一个渐进的认识、接受的时间过程的。

5 后记

本文描述的经历在10年前，那时候笔者还只是项目经理的角色，很多事情的推行也是从项目管理的角度出发来考虑的。从敏捷实施的成熟度来看，当时，也只是“守、破、离”的守的阶段，只是践行了基本的SCRUM框架，但是现在看起来，当时的成效也达成了公司的业务要求。

不积跬步无以成千里。随着时间的流逝，对于敏捷方法的系统认识，敏捷方法论对软件开发，对项目管理，对组织业务的影响仍然在探索中。

在路上，愿与大家共勉。

敏捷开发

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。