文：项目管理者联盟 高级顾问 刘羚
北京暴风科技股份有限公司根据自身产品、行业和企业特点，在研发管理上积极推行敏捷项目管理，通过 “站立会议”、“集中规划”，“持续集成”，“代码评审” 等实践，取得了卓有成效的成绩。
推行敏捷项目管理，成绩斐然
北京暴风科技股份有限公司董事、CTO 杨立东先生
众所周知，北京暴风科技股份有限公司（以下简称“暴风”）是业内一家知名的视频播放服提供商，其主打产品“暴风影音”每天为超过2000万的用户提供简单、便捷的互联网视频服务。每个月都要在暴风官网上推出一个新的版本。因此，项目周期非常短，一般是15天，“如此短小的项目，没有办法实施CMMI，只能推行敏捷项目管理”，暴风的CTO杨立东先生如是说。
杨总介绍到，目前暴风所有的项目目标有两个质量标准，一个是卓越标准，一个是及格标准。比如新版暴风影音Android版的界面刷新改成滑屏操作，每一个滑屏的及格标准是1秒，用户感知已经不错，卓越标准提高到0.6秒，用户感知会非常流畅。及时交付率是指达到及格标准，卓越完成率指达到卓越标准。两年前，暴风的项目及时交付率只有50%左右，敏捷项目管理推行仅一年的时间，及时交付率便大幅上升，如今公司同时在做的项目有20多个，及时交付率几乎达到100%，卓越完成率大约是60%，未来的目标是卓越完成率达到90%。
同时提高交付率和质量标准，靠的是什么？“每日站立会议，集中规划、代码评审Code Review、持续集成、项目复盘”等敏捷实践发挥了巨大的作用。
高效的项目例会
当笔者对杨总提出想了解暴风具体的敏捷项目管理实践时，杨总热情得说，“一会儿有个项目晨会，你们正好可以看看。”百闻不如一见，笔者自然是求之不得。于是在对暴风的整体情况作了简短介绍之后，杨总带我们来到外面的研发大厅。
只见10来人正围在一块大玻璃板前，玻璃板上有一个图表，画着“To Do” 、“Doing”、“Done”、“Bumdown Chart” 这么几列，每一列下面都贴着花花绿绿的小纸条,图上方有项目日期，一个小伙子站在中间，正在询问，并时不时得移动着贴纸, 往图上做着标记，甚至拿着一把尺子在丈量，画着那张“Bumdown Chart”即燃尽图。很显然，这是在开项目例会，玻璃板上的图表就是一个项目看板，分别标着该项目组“未完成”，“正在做”，“已完成”的任务，“燃尽图”则表明随着时间变化的剩余工作量。如下图所示，花花绿绿的贴纸上记着“编写测试用例”、“搜索页面：热词”、“Tab页面：Tab主页面交互及动画效果”等任务名称，下面标有姓名和时间。
真是一目了然！杨总在旁介绍说，这样的项目例会每天都开，作为CTO，他不参加会议。项目经理也无须发项目周报之类的报告，他要了解项目进展，只需看任务展板即可。这张图每天要拍个照，以作为追踪项目的依据。杨总介绍到，项目周期一般只有15天，最长的也不会超过3个月，用这种方式跟踪项目足以。传统的项目管理讲究监控，敏捷开发则相信团队，让团队自己监控，领导放手。
这就是敏捷实践中著名的“每日站立会议”，简单却高效。10几人的会议不到15分钟就结束了。每个人只须回答三个问题：“昨天完成了什么，今天要做什么，遇到了哪些障碍需要协助。”
每天面对面的沟通，可以让项目组成员互相了解彼此的进展，从而了解本项目的整体进展。不坐在会议室,眼睛不盯着电脑,而是互相看着其他的成员，每个人的任务状态都清清楚楚。这种做法既会给每个人一种面对面的精神压力，直面项目进展。也容易培养团队的文化，让每个人都意识到：不是一个人在战斗，是一个团队在战斗。
每日站会使用的任务展板
集中规划
“集中规划”的实施为暴风缩短了将近一倍的交付时间。
在暴风，产品经理负责产品需求和规划、确定产品指标、验收测试。研发团队的项目经理负责实现需求。很多公司的产品需求在立项时没有经过充分讨论，过程中会出现各种理解偏差，甚至有的逻辑根本没想清楚，研发都开发完了才发现和之前的版本有重大冲突，变更就成了常见的现象，导致的结果就是开发周期长，测试周期长。
在早些时候的项目实施中，暴风的一个项目通常前期需求讨论需要5天时间，开发6-8天，集成测试6-8天，发版前产品验收1-2天，加起来整整一个月。在确定需求的5天时间里，开发和测试人员直到第4天才参加讨论，效果很差，经常有变更，开发和测试效率低下。
为了应对这个问题，暴风改进了流程，要求产品经理在立项之前一周就做出规划，并尽早组织研发、测试、Scrum Master一起来集中讨论下一版本的需求。集中规划的作用体现在让产品、研发、测试团队在版本正在开始做的前一周内已经充分理解了需求。让团队提前做了产品的推演工作，针对大的研发任务和需要调研的问题，在本版开发期间进行调研和技术积累工作，为下一版本的开发做技术准备。对比效果参见下图：
推行“集中规划”前后对比
从上图可以看出，集中规划后的项目周期总体缩短到15天左右，压缩的时间主要在需求讨论和测试上。产品、研发、测试团队用3天的时间一起讨论下个15天的版本需求，是可以将需求讨论清楚的。测试时间能够压缩基于3个因素，首先是测试团队参与需求讨论有助于理解需求；其次，由于对研发提交任务完成标准提高了要求，测试团队轻松了许多；再次，团队采用了自动化测试平台。
经过1个月两个版本的试点工作，团队就适应了这种集中规划带来的整体交付效率的提升。
除了集中规划，代码评审也被杨总列为效果不错的敏捷实践，并得到宝贵经验。在暴风，代码评审效果最好的方式是最多五个人在一起，由作者讲述，其它人发现缺陷。避免忙于编程，到后期才发现潜在的缺陷。
为什么可以推行敏捷项目管理？
毫无疑问，敏捷项目管理在暴风取得了成功，暴风以敏捷项目管理作为主要的研发管理模式。这是与暴风的业务、技术、项目特点分不开的。
目前暴风现有450人左右，研发团队有200多人，核心人员比例超过30%。“与我从前服务过的软件企业不同”，杨总认真得解释道，“以前的公司对研发的核心技术要求不太高。而互联网产品运行环境过于复杂，技术要求非常高，比如播放技术要求有很强的数学基础，P2P技术需要对网络知识有深入的认识，压缩技术和内容分发技术也相当复杂。这些技术人才都是很奇缺的，因此，一个核心研发人员可以顶好几个人，因此我们招聘必须找技术好的员工。”。
除此之外，敏捷项目管理对人的要求更高，因为敏捷文化的核心思想是相信团队，相信人的主动性。比如传统项目管理模式，是项目经理分配任务，而敏捷项目管理，则是“任务认领”制。敏捷团队将任务贴在小黑板上，由团队成员自己去估算工作量，并主动“认领”任务。这种方式有助于提高研发的积极性，不用担心有人“挑肥拣瘦”。因为那些有难度的“硬骨头”任务，事先会被Scrum Master放到“项目阻碍”池中，核心人员首先应该到“项目阻碍”池中认领任务。因此，在组建团队时，杨总强调会选择那种有主动性，愿意主动承担事情，并且有优化意识，追求卓越的人，这是选人的价值观标准。
不难看出，高素质的员工队伍是暴风推行敏捷项目管理的基础。
推行敏捷项目管理的同时，暴风并没有排斥其他经典管理模型。组织级管理工作仍然离不开CMMI和PMBOK。CMMI中的配置管理、持续集成、项目度量、过程资产库的概念和方法都为杨总的团队采用。PMBOK中的关键路径思想，沟通管理中介绍的那些方法也都在团队中应用。此外，暴风还有个项目经理训练营，杨总会重点培养那些核心骨干，让他们系统学习PMBOK的知识，送他们去考PMP证书，然后持续给这些骨干做有挑战的项目等等。
暴风敏捷项目管理实践