从零开始—敏捷SCRUM在软件企业中的成功推行历程.docxVIP

从零开始—敏捷SCRUM在软件企业中的成功推行历程--王凌宇摘要简介：本文取自真实的敏捷SCRUM应用实践。笔者认为，敏捷方法的推行实施在企业中是一个系统的工程。因此，本文不是简单地从头到尾的流水式描述，本文从敏捷SCRUM的背景分析，推行准备，推行实施，推行总结几个方面来总结。时间回转到2年前，我，一个做过网络工程项目，信息系统集成项目的项目经理，来到一家软件企业，开始承担某软件系统产品开发项目的项目管理。通过半年多的加班加点，带领团队完成了软件demo版的开发，CCBN展会上，很受客户欢迎。接下来，商务洽谈如火如荼，系统产品化开发迫在眉睫，可是，我深深清楚团队一路挣扎走来的现状，怎么做才能在3个月左右的时间里完成从DEMO版到产品化版本的开发？只有敏捷开发能拯救我。那么，开始自我拯救的征途吧。。。。。。背景分析公司背景公司是一家60人左右的软件公司，以研发、销售软件系统为主营业务。作为一家民营企业，讲究人尽其才，可喜的是公司组织结构分明，部门职责比较明确。负责主管研发的领导有着多年的研发经验，对推行敏捷持支持态度。团队背景项目团队总计10余人。其中包括开发9人，测试4人，管理3人。根据所开发的软件系统特点，将全员分成6个小组，分别是管理组，开发组A, 开发组B，开发组C，测试组，产品组。团队之前一直实行迭代开发，通过半年来的加班加点，终于完成系统DEMO版的开发。但是，已经是谈加班而色变，团队士气漂移不定。团队对敏捷知之甚少。我作为项目经理，在项目中统一协调研发部、测试部、产品部。项目背景本项目主要目的是完成公司主营软件系统的产品化开发。依据IPD流程的定义，目前只是完成了基本的技术开发，下一阶段需要完成技术开发及产品化开发。因为是产品化开发，产品开发面对的是行业内的某一类整体客户群体。所以项目需求宽泛，需求筛选、分析的难度较大。没有固定、明确的客户可以来针对性的沟通交流。虽然已经完成了DEMO版的开发，但是相关业务的具体实现和系统的功能性能指标确定实现等，还需要很长的路要走。公司要求在3个月左右的时间里完成软件系统的技术开发及产品化开发，时间压力很大。如果持续的加班加点，恐怕引起团队震荡，要知道，当时可是刚过完春节的3月份，作为管理者，3月份是一个难捱的月份，也许突然什么时候，就会有团队成员找你沟通，然后从团队内消失离去，那你就能深切体会什么是铁打的营盘流水的兵了@@。推行准备自我准备首先，自己买书，从网上读了大量敏捷方面的内容。在这里，向大家推荐两本书： 硝烟中的Scrum和XP和敏捷项目管理，都是老外写的。前一本深入浅出的介绍了SCRUM实践方法，而后一本从产品开发及项目管理的角度阐述了敏捷。同时，与直接领导也做了大量的交流，最后，把要推广的目标锁定在SCRUM上。为什么？因为SCRUM是当下流行的敏捷开发方式，流行的必然有它流行的理由，SCRUM框架清晰，容易上手，充分体现了敏捷开发的特点；其次，SCRUM开发与项目团队之前的迭代开发有某些相似之处，便于成员接受执行。然后，经过对比后，联系了一家敏捷培训的专业公司，在经过几次的沟通后，确定了让全体团队成员（包括相关领导）正式参加敏捷集训的日期。好了，万事俱备，只欠东风。培训内容准备经过与敏捷培训公司的沟通，决定培训的内容包括如下：重要内容：敏捷开发的讲解，向大家讲明敏捷开发的优势。简单介绍：敏捷项目管理简介，向大家介绍敏捷项目管理的特点。关键内容：SCRUM详细培训，向大家详细培训SCRUM的具体执行方法。推行实施集体培训整个项目团队加上相关领导，在公司聘请专业的培训公司进行了为期2天的集体培训。（我也想时间长点，可是需要Money呀）通过集体培训，整个团队感受了敏捷的气氛，了解了敏捷的含义，并初步了解了SCRUM的框架。下一步，是骡子是马，该出来遛遛了。SCRUM执行培训结束后，团队按照自己项目的实际情况，开始严格按照SCRUM框架执行。图1 SCRUM框架如图1所示，我们项目团队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 backl