第一篇 组织篇
第1章 暴风敏捷项目管理实践
一、暴风的项目危机
作为一个研发团队管理者，或者一个几亿用户的客户端产品负责人，你最怕听到研发团队说什么？排前三位最不希望听到的就是：
（1）由于各种历史问题的原因，这个功能改不了；
（2）如果增加这个产品特性，由于各种原因需要至少2个人研发1个月；
（3）这个月的发版可能不能按时发了，有好多功能没开发完。
当整个公司都为这些问题感到焦虑、无奈甚至无语的时候，不得不去深入地反思，这背后有产品所处生命周期的问题，有设计架构不合理的问题，也有项目交付管理的问题，甚至有配置管理的问题。这就是2010年的暴风影音3产品，一个以万能深入人心，以“1M带宽下在线看720P”的在线高清播放客户端软件，赢得用户广泛使用的播放产品，背后却有着重重的交付危机。
总结大多数互联网创业公司做得最多的事情，就是抓住用户的核心需求，然后快速地做出来，在一个竞争环境下，谁先做出了用户喜欢的功能，谁就能在激烈的竞争中先占领这些用户。而在这种思想的指挥下，什么架构设计，什么项目管理，都不会比先把用户所需要的东西做出来优先级高。如同软件危机促进了软件工程的发展，当互联网创业大军的研发交付受到各种制约时，也推进了敏捷项目管理在国内的实施。
本文不会过多地介绍敏捷项目管理的概念，只是从公司引入敏捷思想、实施敏捷项目管理实践的角度进行描述，中间也会掺杂传统项目管理的一些有效实践。
二、组织级的敏捷初体验
当一个研发团队管理者从战略角度去思考时，分析外部你会去看整个行业、你所在企业在行业中的位置、你的上下游企业的议价能力、竞争对手分析等。像波特五力分析那种在传统行业应用得滚瓜烂熟的分析工具和框架，同样也适用于新兴的互联网软件企业。而企业内部分析也同样可以参照那些已经成熟的战略思考框架。为了在同类竞争对手中建立自己研发团队的核心能力，我们必须去认真地思考我们到底需要什么？毫无疑问，对于互联网软件公司来说，保证质量前提下的交付效率是我们需要打造的核心能力。
交付效率怎么定义？可以定为及时交付率、可以定为项目平均交付周期等，不管怎样，其目标和结果就是，如果在同一起点研发同质化的功能，我们要领先竞争对手1～2个月。这里面需要架构师的努力，研发高手的拼搏，测试高手的奋斗，也需要有一种思想来引领整个团队来达到这个目标，这种思想叫敏捷。
1.在敏捷中寻找出路
先打破一下大家对组织的看法，由于CMMI的侵蚀，大多数人产生了错觉，认为组织一定是整个公司，其实组织可以是整个公司，也可以是公司中的某个团队，例如播放产品、播放研发、播放测试、播放运营四个团队可以称为一个完整的组织。对于一个企业或企业中的某个组织，引入一套管理体系或者某个管理工具来优化管理流程，无外乎两种引入方式。
第一种方式是从“企业自我”出发，循序渐进地进行流程优化。目前，国际国内的一些知名企业，一些知道自身痛处和优化重点的组织，都选择了从“企业自我”出发，循序渐进方式的流程优化和改进。这种方式一般的做法是：先重点总结和反思组织当前的实际业务情况，项目执行过程中遇到的实际问题，然后根据问题的优先级，选择某些方面先开始优化，并针对组织在该阶段的管理水平、团队能力、想要达到的目标和结果等，进行有针对性的培训、辅导、执行和复盘总结，等收到了预期的实际效果时，再逐步开始其他方面的优化和改进。
这种方式的优点是完全尊重了组织现有的能力和文化，循序渐进地进行优化与改进，每一个阶段都能够解决一些实际的问题，并看到流程优化的实际效果。但由于组织这种“优化”文化的形成、技术管理人才的培养往往要经历一个比较漫长的过程，可能遇到的问题是时间周期太长，没有明显的结果。
第二种方式是以体系和管理工具为中心，“拿来主义”地进行流程优化。目前，国内一些企业或组织最常见的方法是所谓“拿来主义”的流程优化。别人实施CMMI，我照搬流程、文档模板过来，现在流行敏捷项目管理，我也照搬过来。用的过程中再逐步地完善和优化，以适合组织的需要。
这种方式一般的过程是：找到参考组织，通常是行业内比较牛的企业，先把整套框架照搬，在组织中进行强制推广，根据实施的效果和组织自身的实际情况，逐步进行完善和优化，最后形成符合组织自己实际要求的、稳定的流程规范。某知名企业在引入IPD时就提出了“先僵化、再固化、最后优化”的思路。
这种方式的优点是效率高，引进速度快。可能遇到的问题是“水土不服”，因为在企业自身的业务方向、团队能力、对于流程规范的理解等条件都不十分成熟的情况下开始实施，容易产生员工的抵触情绪，可能很难深入地推进。
敏捷项目管理的原则是“可工作的软件是衡量项目成功的主要指标”，可工作的软件是一线团队贡献的，不是管理者，所以在引进敏捷项目管理的时候必须让一线员工参与选择和决策。毫无疑问，员工喜欢更轻量级的敏捷项目管理，那里没有废的文档，没有各种报告，只有每个Sprint交付有用的软件。
2.从敏捷立项开始
敏捷项目管理中并没有项目立项这回事，只有Sprint计划会议一说。所谓立项还是沿袭了传统项目管理的说法，可是对任何员工来说，立项是神圣不可侵犯的，立项的项目一定会有人关注问题是怎么解决的，一定会关注项目结果。特别是对于对变更深恶痛绝的研发人员来说，立项了意味着变更要受到管理了，产品不能再随随便便地更改需求了。
一提到立项，很多做过项目，甚至项目经验丰富的项目经理可能立即会联想到一系列规范的过程，其实并不需要那么负责，作为团队的管理者一定要记住不管做什么，一定是以结果为导向，采用最简单、最直接的方式达到目标。那么简化版本的立项应该怎么完成呢？
首先，先共识立项的目的。由于业务不同，团队执行能力不同，管理者在项目管理上的期望不同，立项的目的也是不一样的。在暴风的研发团队中，立项的目的要回答如下一些问题。第一个问题是为什么要做，一般是研发和测试团队来问产品经理的，敏捷的实施让研发和测试人员更加积极，原来的研发人员已经进入了怪圈，产品需求说一，研发就实现一，需求一有验证的逻辑错误，研发就按错误的逻辑实现出来。立项让研发和测试人员活了，让整个团队的成员都有了质疑精神。团队归纳了要做的三类事情：为用户提供有价值的新功能或服务；为改善和提升用户体验的功能的优化；解决Bug。所以只要Sprint的需求用户故事能落实到这三类，这个问题就可以得到解决。第二个问题其实是项目优先级排序的问题，产品经理罗列的N多的用户故事，哪些更重要排在前面，也需要立项的时候回答清楚。项目交付的结果无须解释，但是这个结果要达到什么质量标准是必须在立项前定义清楚的，这里质量标准包括但不限于崩溃率、启动速度、功能的转化率、下载成功率、播放成功率、不可播率等。需求的理解在传统项目管理中需要定义烦琐的需求文档，在初次实施敏捷的暴风研发团队先让产品、研发、测试达成需求的共识是必要的，这样大家可以分头去准备必要的需求文档、设计文档和测试用例。而对于风险好像除了进度风险团队就识别不出其他的风险了。
其次，Sprint计划会应该在立项前面还是立项之后召开呢？抱着尝试的心态，团队选择了立项后开Sprint计划会。选择的理由是，Sprint计划会开完后，到立项的时候如果由于优先级问题，可能会导致原来的计划全部被推翻。“Planning”意思是持续不断地计划，这是对计划最好的描述，不要指望一次会议就把Sprint计划都搞定。所以团队决定多开几次Sprint计划会，在会上再次讨论需求并给出相对靠谱的估算。原本打算按照正常的估算来确定Sprint的长度，但在产品发版周期的强大压力下做了妥协，改为先在Sprint中的用户故事中进行合理的估算，如果在产品规定的Sprint周期长度内实在无法完成，就按用户故事的优先级去掉一些任务。采用什么样的估算方法呢？估算大多数是要靠研发人员的，对于研发人员来说功能点、生产率等统统都不愿意去学习，来点简单实惠的，简化的DELPHI方法更能迎合团队的胃口，这也正是敏捷估算的前提。产品经理在估算中要起到非常重要的作用，不但要将用户故事介绍到大家都能听懂，还要辅助敏捷教练帮助估算人员分析估算偏差的原因。
最后，该定义立项后项目的一些基本规则了。虽然敏捷项目管理倡导“拥抱变化优于遵循计划”，但以国内研发团队的综合能力，尽量少地变更才能保证交付的软件的质量。所以，对于变更的预定是按Sprint周期的，在Sprint的前三分之一时段，可以尽量朝用户体验更好的方向提有用的变更，在三分之一到三分之二时段，团队只接受优化类别的需求变更，在后三分之一时段，拒绝变更。对于开发任务完成的定义，团队采用了“0～100完工进度”下更精确一些来计量任务完工进度的方式，P代表研发任务研发完成，C代表测试通过，T代表产品经理验收通过，这样的完成才是真正意义上的完成。对于每日的敏捷例会，考虑到一些研发人员早晨起不来，团队约定每日早晨10点开始敏捷项目例会，会议时间限定在15分钟。而准备实施敏捷项目管理的团队需要封闭在一个独立的空间里，集体搬到一个会议室进行团队集中。
3.组织级培训的作用
规矩定完了，而且是以一线团队为主进行的规则定义。为了保证试水的顺利，培训是非常必要的。松下幸之助说：“培训很贵，但不培训更贵。”也有很多观点认为，在所有的知识传授方法中培训是效果最差的。这个观点有一定的道理，那是因为大多数公司的培训都停留在为了培训而培训上，没有照顾到被培训者的基础，没有精心地准备培训，培训的过程中只是干巴巴地讲授而缺乏娱乐等。换另外一个角度来思考，以上定义的一些规则，包括如何立项、如何进行Sprint计划、如何估算、如何管理变更等，如何让一个没实施过敏捷项目管理的团队顺利地执行下去？大多数公司都知道流程的推广要经过流程定义、流程培训、流程试点、流程优化、流程推广，这类似于PDCA戴明链的一系列循环，但在定义环节，很多都没有让员工参与，在培训环节，又有多少做到了认真培训？
针对枯燥的概念和流程，很难唤起技术人员的兴趣，怎么才能收到好的培训效果呢？
首先，避免枯燥，增加很多模拟和演练环节。例如，关于如何立项，不妨拿一个即将开展的项目先模拟一次，让大家先提出各种争议，最终由培训老师引导大家回到敏捷立项需要回答的6个问题上，最后每人发一张小卡片，技术人员不需要记忆这6个问题，但经过反复演练，每个人都应该理解这6个问题从哪些角度来思考，从哪些角度来回答。这种模拟和演练同样也适用于Sprint计划会。
其次，针对一些规则，在培训过程中要讲出规则制定的来龙去脉，同时也收集技术人员关于规则的看法，而不是枯燥地介绍规则，一副理所当然规则就这么定了的样子。例如，关于变更的规则，有的技术人员就提出，前三分之一时段允许产品人员实施变更，那怎么界定是朝用户体验更好的方向了？
提出这种问题就给了培训讨论的话题，让大家共同枚举一些改善用户体验的场景及伪改善的场景。
最后就是怎么评价培训做得好不好。评价分两个方面，老师评价学员学习得好不好，以及学员评价老师讲得怎么样。市面上各种各样的反馈表感觉很千篇一律，所以针对培训的评价团队也做了改进，如下表所示。
4.官网升级项目试水
如果要寻找试点项目实施一套新的方法和体系，选择什么样的项目最合适呢？创新精神、学习能力和执行力缺一不可。创新是团队不守旧敢于尝试新的方法，敢于试错；学习能力决定了实施过程中团队学习新事物效率高，理解偏差小；执行力决定了这套方法和体系是做到60分的标准还是更高的标准。再通俗一点讲，项目的负责人和他所带的几个骨干对新事物的态度决定了试点项目实施的效果。我们选择了公司公认的重要项目——官网929升级项目，项目的负责人也是在公司研发团队中具有重要影响力的人物，这个团队的骨干们也都接受了敏捷项目管理和公司定义的一些规则的培训，甚至有些规则这些骨干们也参与了制定。
通常产品经理在功能（用户故事）的选择上都是贪婪的，他们恨不得研发团队在一个Sprint上做完所有的功能，很少有人喜欢去做减法，只有在眼看实现目标渺茫的时候才不得不被动舍弃。在这个试点项目中几乎重演了上面的事实。幸好开始实施敏捷项目管理的敏捷立项，按照规则大家开始对选择的用户故事逐个地争论不休，争论的焦点无非是功能的取舍，当很多争论陷入白热化时，产品经理给出的理由无论在哪个公司也许都千篇一律，“这个功能我们竞品有，所以我们也要有”，“这个功能是我们老大要的，我们说的不算”，“用户可能会喜欢这个功能，有用户反馈说要了”。幸好有务实的敏捷教练和受了新思想培训过的研发负责人，他们把问题拉回到项目立项的目标，也让激烈的争论画上了句号。在一个产品导向型的公司，很多产品经理不会定目标，所以经常能听到的目标是按期发版，必须完成某某功能，版本质量稳定。这三个方向都是正确的，可是完成到什么程度算好呢？经常会有些模糊，试点项目除了质量定了崩溃率限制外，其他两个目标在相对模糊的情况下完成了立项。
估算的实施是试点项目引入敏捷后最为搞笑的一件事，没有采用真正的敏捷扑克，但是流程还是严格地按照简化的DELPHI方法实施的。在实施之前做了个小实验，把所有的用户故事拆分后，让大家公认技术最牛的研发负责人先估算了一遍。记住估算结果后，擦掉数据，换成投影让他在同事们面前再次“表演”一次估算。同样的用户故事，同样的估算人员，同样的约束条件，结果出来后大家一致嘲笑这个技术大牛超级不靠谱。因为两次估算的结果对比了一下，有一半多用户故事的估算结果不一样。当真正的估算开始时，先让研发的同事认领了自己喜欢做的任务，然后每个任务选择自己、一位同事及研发负责人共同按照流程执行估算。流程的执行不存在什么问题，可估算了多个任务后会发现研发人员分为三类，一类是喜欢给自己留Buffer的，明明6小时可完成的任务估算一般给自己要8小时，另外一类是激进的，正常需要16小时完成的任务，他喜欢挑战自己压缩到12小时，最后一类是中规中矩的，不冒进，不保守。
敏捷例会的实施和预想大相径庭，三个标准问题，“从上次会议到现在都完成了哪些工作？”“今天准备完成什么？”“工作中遇到了哪些阻碍？”有很多成员的思维没有转变过来，感觉还是向敏捷教练汇报昨天的工作和今天的计划，而没有互动，明明有些成员之间需要调试接口，而接口中遇到的各种问题都没有暴露出来。更很少有人去关心燃尽图和项目Sprint要达到的目标。至于更新展板也成了敏捷教练一个人的工作，大家似乎并不关注展板上任务的总体进展情况。甚至会发现大多数人属于估算中规中矩或者保守者，每日只完成估算内的8小时工作，甚至在整个项目过程中都很少有估算的偏差。
例会迟到也是开始实施时遇到的难题，似乎研发人员非要用散漫来代表自己独特的气质，或来衬托其作为高手的洒脱。实施敏捷项目管理是团队的事情，更应该注重团队协作，所以按照约定的时间开敏捷例会是应该最先达成共识的问题。针对例会不能准时开的问题，研发负责人发挥了他技术领袖的作用，约定开敏捷例会迟到的每人交50元作为项目活动经费，这对约束纪律起了决定性的作用。目的不是为了罚钱，而是约束大家能承诺兑现，虽然还是有迟到现象，有些成员甚至起哄让经常迟到的人学移动资费可以包月。坚持下来确实提高了大家对敏捷例会的重视。
谈到需求变更，几乎所有的研发人员都谈虎色变，那简直是一个让人深陷的泥潭。这个项目也不例外，按照最初的约定变更应该在项目的前三分之二阶段，团队接受了一些产品经理提出的变更，有的是为了最终产品体验更好，有的是在无奈下妥协接受的变更。到了项目快测试结束的时候，产品经理又提出了变更，这次研发人员理直气壮地拒绝了变更，这次拒绝让研发成员前所未有地兴奋，因为终于找到了合理拒绝变更的理由。拒绝归拒绝，产品经理提出的需求变更想法是非常好的，所以团队讨论后决定将这次变更作为新的用户故事放到下个Sprint中去实现。
5.敏捷项目管理尝试实施度量
很多人对“Business Goal”不是十分理解，因为对于绝大多数IT或互联网公司，很多公司都没有清晰地把业务目标描述清楚，很多公司的业务目标都是销售额增长、利润增长这些财务指标，这必然给公司的研发管理者以无从下手的感觉。因为研发团队和这些指标的贡献不具有直接的相关关系，所以很多研发管理者便只关注项目和项目管理。
如果要实施度量，一定要先理解业务目标，并让度量服务于业务目标。例如，暴风的某个业务线的业务目标是在线VV的增长年度翻倍，而支持这个业务目标的方法是提高影视内容的数量和质量，提高内部运营效率，以及一些和新用户导入或老用户留存相关的重点项目的实施及效果。前两项属于运营管理，可以定义一些指标来度量效果，例如百度排行榜Top 50的影片的采购数量、影片内容的更新效率等。而和重点项目相关的度量指标可以是项目的及时合格交付率、升级效率、用户使用率和用户好评度等。再深入一些，对一个具体的项目，如果实施敏捷项目管理，可以从项目的任务按时完成率、燃尽图、缺陷移除率等方面来实施度量。
有些公司会将度量与考核紧密地绑定在一起，这是一种非常不明智的行为。试想如果考核缺陷率，管理团队会看到什么样的缺陷率报告，而由于不敢报告缺陷数据，会产生多少隐藏在深层的Bug。如果考核任务的按时交付率，一定是上有政策，下有对策，直接把估算打个Buffer，按时交付率的图表会做得很漂亮。而对于数据统计可以，系统自动算出的崩溃率、软件的启动速度等性能数据则可作为考核指标。所以概括来说，人为产生的度量数据不要用来考核；系统产生的人为不能轻易干预的数据，可以用来考核。
也不要迷信度量一定要采用工具，首先有经验的研发团队一定不会度量很多指标，其次也不应该每次都度量同样的指标，度量什么和工具也没有必然的因果关系，只要度量的数据指标能和直接的业务有相关性，那么度量就是有意义的。下图给出了软件公司常用的一些度量指标，从中挑选你认为最能和公司业务指标相关的两三项实施吧！
6.在应用敏捷中复盘和成长
复盘指对局完毕后，复演该盘棋的记录，以检查对局中招法的优劣与得失关键。一般用以自学，或请高手给予指导分析。在软件项目的复盘和总结中，很多公司做得都不得要领，大多数公司由项目经理编写一份项目总结报告提交给相关人员，其实都是为了例行公事，很少有人去看总结文档。下图是试点项目实施敏捷项目管理后的复盘框架。
目标复盘需要回顾当时项目设定的目标是否达到，如果项目的目标设定了卓越和及格两个标准，需要判断项目是及格还是卓越。项目立项时很多指标都可以设定及格和卓越标准，例如，可以设置质量相关的软件稳定性指标，软件的崩溃率在原有比率的基础上降低50%的空间为卓越指标，降低30%为及格指标，也可以设置为产品目标，功能的用户使用率达30%为卓越指标，10%为及格指标等。设置卓越标准的目的是为了激励团队想出更好的方案来达到卓越。这在一个追求卓越的公司和团队中会塑造一种正向的企业文化。
时间轴回顾主要复盘项目中各个检查点是否按时达到，如果有偏差，是当初规划的问题还是执行问题。特别是调研大多数公司的交付团队的高管，问他们最关注什么，八成以上的人都关注软件项目的进度。如果是真正关注进度管理的团队管理者，就更需要按项目的时间轴来认真回顾一下项目的进程。特别是项目目标仅仅及格或者没有达成项目目标的团队，更应该回顾一下规划背后采用的每个核心方法是否正确，根据核心方法分解的每个关键动作执行得到位与否，如果重新来过，是否能更好地完成项目目标。
得与失总结是复盘的关键所在，很多人都不会总结得失，经常将项目结果中做得好的部分作为得，项目中没有做到的部分作为失，这是一种十分偷懒的做法。所以大家看到的很多项目总结报告都会去描述项目的得是项目团队得到了很好锻炼、项目中尝试了某某新方法、项目按期验收等。这些是项目的得吗？或许是，但不是真正的得失总结。真正的得应该总结关键任务的完成及背后付出的努力。例如，项目如果达到了上述的崩溃率在原有比率的基础上降低50%的目标，这是得，因为得的背后有几个主要原因做支撑，原因之一是项目针对收集的崩溃日志做了深入的分析并找出了降低崩溃率的解决方法，原因之二是针对引起崩溃的Bug做了因果分析并且都得到了解决，原因之三是针对潜在的引起崩溃的代码做了代码走查，并且做了相应的代码修改。在这三个核心方法下才导致了我们想要的结果——崩溃率降低。同样失的总结也应该总结关键任务的重大失误和失误背后的原因。
最后一步是形成复盘的结论，这个结论可能是一份报告，也可能是一份复盘过程的纪要，最重要的是希望整个团队在复盘过程中得到学习和成长。
这个试水项目就得出了关于项目敏捷估算的重要结论。估算是每个开发者的必备技能，虽然不能像SEI倡导的PSP（个体软件过程）那样来训练开发人员，但每个人应该针对估算做一个自我总结，根据复盘形成的关于估算偏差原因的总结如下表所示。
三、再次组织级探索
试水之后，敏捷之火已呈燎原之势。很多项目纷纷采用敏捷的方式进行管理。这也让事先人员储备不足的敏捷教练显得捉襟见肘。大量的培训会、敏捷估算会、敏捷例会、Sprint总结会、燃尽图的准备等占用了敏捷教练太多的时间。而不同水平的敏捷教练带领的敏捷项目则出现了分化。高水平的敏捷教练会注重敏捷规划和敏捷例会的质量，及时解决障碍和对一些规则的把握让项目结果能达到卓越的目标，而水平低的教练带领的完全是一种伪敏捷，那里会有强力的变更控制、流于形式的敏捷例会、松散的协作等让项目往往连达到及格都困难。这样整个公司不得不再次进行组织级的探索。
1.展示板和信息系统的巧妙结合
敏捷例会的展示板每个团队都会实施得不一样，下面的两幅图展示了不同的实施方式，左边的图来自《硝烟中的Scrum和XP》，右边的图来自暴风的敏捷团队。相比之下，一个更突出燃尽图，另一个更突出项目的阻碍。对于进度跟踪，可以采用观察燃尽图的趋势，也可以融合信息系统的做法。
只要不苛刻地挑剔，很多工具都支持Scrum敏捷项目管理，从最简单的白板加Excel，到ScrumWiki、Xplanner、GNATS都能支持Scrum的实施。暴风的团队开始就尝试了Redmine这个缺陷管理工具来配合展示板实施敏捷项目管理。没有好不好用的系统，只要运用合理，抱着极简的思维去使用工具，就能最低成本地发挥工具的作用，至于使用信息系统遇到的各种缺陷或者不能满足管理的功能，还是应该报以宽容的态度。但理想和现实往往经常事与愿违，将就用了一段时间后团队终于不能忍受系统功能的不足，于是开发自己的信息系统的呼声愈演愈烈，最终还是决定开发自己的系统。
还是本着极简的思维方式，系统只围绕包括Sprint任务导入、任务完成更新（工时填报）、燃尽图自动生成、问题的生命周期管理这样几个核心功能进行开发。这样也使得任务板和信息系统的信息完全一致，障碍（问题）也得到了有效的跟踪和管理。
2.配置管理的敏捷实践活动
对于暴风影音的官网版本来说，每个月会有多个官网版本发布，一种是提供给用户新特性验证的β版本，根据用户体验后真实的反馈信息，进行后续产品的优化和完善，另外一种是将已经完成验证的功能和新特性合并到稳定的官网版本中。基本每两周就要交付一个版本，每个项目都感觉时间紧、任务重。配置管理在敏捷实践中起到怎样的作用呢？
暴风转码的敏捷团队在版本V2.1刚刚完成用户故事的开发工作，也就是说，产品已经能运行，系统测试工作还未开展。按照估计测试和修改Bug的周期为一周计算，此一周的时间研发人员会很不饱和，按照公司对人员使用率的要求，通常会启动V2.2版本的开发工作。这样会提高研发人员的利用率，但也会带来两个甚至多个版本同时开发的问题，如果没有好的配置管理，代码会混乱不堪，很多人同时并行两个版本的代码开发工作，一方面改V2.1版本的Bug，另一方面开发V2.2版本的新功能。我们通过配置管理工具的代码分支、代码合并来解决代码管理问题。为V2.1开出代码分支，这样两个版本的代码相互隔离，不会彼此干扰。V2.1版本上的Bug修复工作，对于V2.2的开发同样也适用。这样实现了版本的交替开发，提升了开发人员的使用率。通过代码的分支与合并也能处理好“新特性开发”与“产品稳定”的关系。两种版本经常存在交叠。用分支支持交叠，即防止了前者干扰后者，也防止了后者阻滞前者，这样维持了开发效率和产品质量的平衡关系。
在敏捷开发过程中，变更是被鼓励的。而变更一定会体现在代码中，因此在SVN里，加一些控制以保证开发人员做且只做该做的事。方法是让变更集不由开发人员创建，而是由专门的配置管理员创建，然后指定给相应的开发人员完成。配置管理员会和产品经理、开发负责人和测试负责人沟通达成一致，然后在SVN中完成相应的设置。对于一些比较大的任务，需要多个人协同完成，可以为此开分支，分支也由配置管理人员创建，然后要求开发人员在分支上工作，完成相应任务，同时控制修改代码之后的提交。对于分支版本，只有符合本次版本要求的分支才允许合并到主干。这个工作是配置管理员和敏捷团队协作完成的。配置管理实践中最重要的是要摒弃原来所有的控制思想，让配置管理员作为敏捷项目团队中的一员，和团队共同协商如何管理代码、管理变更，而不像实施CMMI过程中有各种控制和审批环节。
3.敏捷中实施Code Review（代码走查）
技术评审活动是不管是否实施敏捷项目管理都需要进行的一种活动，很多人从来没有搞清楚什么是技术评审、什么是管理评审。技术评审包括需求评审、设计评审、代码Review、测试用例评审等和项目直接结果相关的工程活动的评审。管理评审指的是敏捷项目管理的三个仪式：Sprint规划会、每日例会和Sprint评审会。传统项目管理中的项目立项评审、里程碑评审和验收评审也属于管理评审。简单地总结，技术评审是针对软件工程活动的评审，其目的是通过缺陷预防提升软件的质量，管理评审是针对阶段活动是否可认定为结束、下阶段如何开始，其目的是项目管理活动是否有效，交付的成果是否可接受。
如果借助敏捷项目管理的思想“交付可用的软件”，技术评审在敏捷活动中显得尤为重要，从评审的正式程度上划分，技术评审分为正式评审、技术审查和代码走查三种类型，如下表所示。
正式评审通常由项目经理主持，邀请项目的核心成员和外部有经验的专家参加，目的在于定位并消除软件中的缺陷。技术审查或称内部评审，通常由技术负责人召集相关人员参加，一般是在模块或功能完成时进行，目的在于通过对交付模块或功能的技术审查，提出改进意见。代码走查又称代码走读，由代码作者来组织，主要是代码质量分析和编程规则检查。一般是在模块或功能完成的早期进行，作者有一定的想法时，希望从其他开发者那里获得一些帮助或补充。由作者主持，目的是进行缺陷预防，提高代码的质量，很多公司已经成功地实施了Code Review和结对编程。
总结第一轮实施敏捷的试点项目，并没有要求实施代码走查活动，项目负责人和开发人员也没有意识进行Code Review。要么是找借口说进度太紧张时间不够用，要么是不知道如何进行代码走查。第一种纯粹是意识问题，要回答不知道怎么进行代码走查的问题则从代码走查的种类开始着手。代码走查分为两种：一种是交叉代码审查，自己的代码由他人来检查，就像检查作业一样；另一种是代码会审，就是以会议的形式，大家共同审核代码的质量。代码走查主要审查的内容包括：是否符合代码规范，确保所有人写的代码基本一致并符合代码规范；代码满足基本用户故事的要求，检查代码的逻辑实现，确认能实现用户故事；代码满足性能等非功能性需求，非功能性需求一般需要借助一定的工具和Code Review人员的能力，针对编码中对于性能影响的瓶颈给出解决方案；代码简化，提高代码的可读性，能够用公用的方法和公用API实现，则无须每人定义自己的实现代码。
随便抽出某开发人员的1000行代码检查的结果是：代码注释不充分，很多实现逻辑的类和方法没有注释；有些代码性能差，频繁地读/写磁盘I/O；有些代码虽然实现了功能需求，但从逻辑上写得太死，不便于扩展；在约定使用统一代码的写日志功能代码作者定义了自己的代码来实现。看来为了提高质量，代码走查是实施敏捷项目管理一定要执行的工作。
4.被修订的测试报告
测试报告是集成测试阶段每天都需要测试工程师编写的一份重要的信息沟通工具，它的目的是让团队所有成员了解当前Sprint交付软件的质量情况，每个开发人员身上有多少未解决的Bug，以及交付模块的质量情况。回顾试点项目的项目测试报告，大概是从百度上搜索的模板，冗长而不知所云。报告中什么编写目的、背景、测试对象、测试概要、测试用例、测试环境等，光标题就会让人眼花缭乱。从正规性上讲，这样的测试报告提交给最终用户无可厚非，但是给团队内部看就没必要这样讲求全面性和规范性了。再引用敏捷思想“可用的软件重于完备的文档”。所以修订测试报告应该是为团队减轻负担、提高沟通效率的一项优先级非常高的优化活动。
问问团队需要什么样的报告。产品团队回答需要了解当前软件的质量来决策是否可发版，以及有些不好解决的缺陷拿出来让团队共同来决策Bug的处理策略。研发团队回答需要了解每个人身上有多少个未解决的缺陷，Bug整体解决情况和各模块的质量。测试团队关注的是Bug整体解决情况及分解下的按模块、按人员缺陷情况。统一思想后的测试报告包括一个测试情况的基本总结和三个部分。
基本情况总结是整个测试报告中最重要的部分，应该用粗体和红色来描述。要求尽量用一两句话描述清楚当前测试的总体情况。例如，当前测试遇到未解决的严重级别缺陷大于3个，不符合发版需求，其中组件下载功能如果点击取消，必崩。第一部分是Bug移除率的统计，其中累计移除率是了解当前Bug整体解决情况的最好的说明，如下表所示为2010年9月23日某项目测试统计数据。
成功实施敏捷项目管理的团队一定有疑问，为什么实施敏捷后还有集成测试阶段，看上面的数据为什么质量会那么差，似乎和敏捷倡导的交付可用的软件有冲突。带着这些“十万个为什么”不妨思考一下。
没有实施代码走查导致了大量缺陷，造成的直接结果是必须有个集中测试的阶段来把Bug找出来，每个功能和功能之间并不是独立的，开发人员在开发过程中并没有及时沟通导致了接口不一致等诸多Bug，产品人员没有及时确认交付的功能或模块是否可用甚至提出一些变更也导致了一些缺陷。如此多的原因导致这么多缺陷已经解释了上面的为什么，结论是如果敏捷项目管理实施成这样，基本上可以界定为是一场“形似而神不似”的失败的敏捷尝试了。但也可以肯定的是，这份测试数据总结对团队了解项目当前的总体质量起到了一目了然的作用。
第二部分为Bug人员分布，第三部分为Bug模块分布，分别是按人员和按功能模块的缺陷数据总结。按人员的分布可以看出每个人当日解决的Bug数和剩余Bug数，便于提醒团队及时地解决Bug或者相互协助。按模块的Bug数总结便于提醒团队哪个模块的Bug多，除了了解模块的质量外还有助于提示团队及时进行代码走查来彻底解决质量问题。
5.发布规则，绝不让步
经过再一轮的组织级探索，让团队对于敏捷项目管理的基本原则有了更深入的认识。软件开发的残酷现实告诉我们，即使在敏捷项目管理框架下，没有规则的软件开发过程带来的只可能是无法预料的结果。不管是多么有经验的项目团队，在“响应变化胜于遵循计划”一项上都难以做到。一次次失败的教训告诉我们，我们需要在敏捷框架下设定一些基本规则，而在这些基本规则面前，在保证敏捷思想的前提下不能向规则让步。
软件可用规则：上述的代码走查和测试数据告诉我们，在很多情况下我们交付的用户故事可用实际上是带有很多缺陷的，即使强调了PCT原则，团队交付的功能模块还是不完全可用，所以严格的方法是在燃尽图统计时，所有未完成的（即使是P和C状态都完成了的功能）都不进行统计，这和传统的“0-100”进度统计法则一致。让任何一个团队成员都知道积极参与，因为每一个功能交付如果说可用就一定要可用。
目标导向原则：目标导向是充分调动员工工作积极性的最有效的方法，每个目标都设定卓越和及格的标准，在制订敏捷计划时，就需要明确项目如何做到卓越，并让指标认领到个人。例如，手机端每个滑屏操作的卓越标准是任意滑动的展现在0.6秒以下全部完成。对于开发者来说，近期的Sprint目标总是比远期目标来说更容易看到和达到，这会使每一个Sprint员工的工作效率维持在一个较高的水平。
代码提交原则：很多开发人员在提交代码到配置管理系统时往往不注意是否通过了单元测试和自己代码的质量，这样会给其他人员带来或多或少的麻烦。所以为了提升团队效率，代码的提交必须满足两个硬条件，其一是提交的代码必须经过自己的单元测试，其二是确保提交代码后整体代码可编译通过。在这个原则的基础上，如果能自动化完成的工作绝对要减少人工干预，例如，持续集成和自动化测试尽量按策略自动完成。
有话好好说原则：项目成员理解和赞同用户故事的范围、项目目标吗？开发人员大多数时间都不喜欢发表自己的看法和言论，大家不发表言论意味着他们认同项目范围和目标吗？这一点在项目沟通中极为重要，敏捷教练一定要问每个人，让每个人表达自己的观点，让大家有话好好说，有话桌面上说，不可认为不发言就认为是同意。在对项目目标没有一个共同认识的前提下，团队是不可能成功的。
文档极简原则：敏捷思想并不鼓励书写文档。敏捷宣言也宣告“可用的软件重于完备的文档”，但如果一个软件是长期更新和维护的，还是需要必要的文档来将所有有价值的历史信息记录下来的。你如果刚加入一个敏捷团队来接手一个已经迭代了9个Sprint的软件，如果什么都没有你从哪里下手？但是不希望文档过于庞大，能把用户故事的关键点、设计的关键点记录下来就够了，特别是代码每次变更必须用注释描述清楚。
精英团队原则：众所周知国内软件的成熟度偏低，一个公司能数出几个好的产品经理？又有多少技术高手？其实资源很有限。如果实施敏捷项目管理，必须抱着精英团队的原则，不鼓励团队规模过大。团队规模过大，按照n(n−1)/2的沟通渠道计算公式，沟通成本增加，效率极大降低。特别是很多需要技术难点公关比较多的项目，人数多根本解决不了任何问题。
总之，在不违背敏捷思想的前提下，一些必要的规则是保证项目目标能够达到卓越的必要约束，也是促进团队建设和高效协作的基础。
四、持续优化的力量
戴明（W.Edwards.Deming）博士是著名的质量管理专家，很多公司的持续改进都借鉴了戴明博士的管理思想。著名的14要点中描述了“最高管理层必须从短期目标中迷途而返，转回到长远建设的正确方向。也就是把改进产品和服务作为恒久的目的，坚持经营，这需要在所有领域加以持续地改革和创新。”
对于一个拥有庞大用户群的客户端软件，必须不遗余力地持续优化自己的产品体验和服务。所以持续优化成了暴风的主旋律，不论是用户需求的收集，产品功能的开发，还是内部内容的运营，都抱着持续优化的思想，这才是企业持续发展的原动力。
1.看后视镜来管理
软件项目管理有两种方式，一种是根据过去的经验去总结和完善，以此作为借鉴来管理当前的项目，另外一种是根据当前项目的表现来预测项目的未来。这一点在挣值管理里表现得淋漓尽致。使用挣值可以了解当前项目的状况，也可以用挣值管理的三种方法来预测项目的未来。而在敏捷项目管理里预测完全起不到作用，因为其核心思想倡导快速迭代和交付。
燃尽图就像开车时的后视镜，是保证开车安全的重要工具。有效地使用它能指导团队在Sprint规划的进度内交付可用的软件。通过这个后视镜你可以观测到形形色色的项目情形，不同的情形也解释了我们在实施敏捷项目管理过程中遇到的各种问题，斜向下的是理想曲线，这让99%的人想象比较好的燃尽图应该是围绕理想曲线微微上下波动的的形态，真的正确吗？这得问实施敏捷项目管理的一线团队，得看他们是如何通过团队自身对燃尽图的理解而不是靠控制来优化进度的，套用一句流行的广告语“谁用谁知道”。
Kane Mar将燃尽图分为7种情况，在暴风实施敏捷的实践过程中，几乎经历过所有这7种情形，以下是按照暴风实施过程中犯错误由多到少的方式进行排列的。
（1）Fakey-Fakey：仅仅表面完美而已，“金玉其外，败絮其中”。由于软件项目的复杂性导致难以界定直观的目标。大多数情况下，这种图一定充满了传统项目管理的命令与控制，所以感觉燃尽图的每个点都可控，带来的问题使开放的交流变得难以进行。
（2）Never-Never：燃尽图在Sprint的后期突然开始上扬并且不会再下降。国内很多产品经理都是马后炮，开始没有认真想清楚逻辑，等开发交付了实现的功能后才提出各种变更。而开发人员在开发过程中也没有及时地和产品经理确认交付的结果到底应该是什么标准。
（3）Plateau：团队在开始取得了很大的进展，但却在Sprint的后半部分丧失了方向。似乎很多团队都是贯穿“前紧后松”的原则，但紧张地完成工作的背后却丧失了Sprint目标。
（4）Scope-Increase：Sprint中的工作量突然增加。通常这表明团队在Sprint计划会议上没有完全认清工作范围。丢失任务是国内团队中常见的现象，都是越靠近后期越发现很多任务没有在规划之内。
（5）Late-Learner：在这种情况下，燃尽图中会有一个顶峰。通常出现在沟通高效且正在学习Scrum的团队中，因为团队意识到问题的时候比较晚，但团队自身也做出了相应的调整。
（6）Middle-Learner：要比第二种情况稍显成熟。团队在Sprint中边做边学，在中期探寻出大多数任务和复杂性。
（7）Early-Learner：燃尽图开始有一个顶峰，然后是平缓的衰退。团队认识到了早期规划清楚的重要性，然后高效地工作以实现Sprint目标。
2.官网交付周期的大幅优化
对于暴风的官网版本，在暴风影音5发布之后，基本上还是保持每个月一个官网的频率，客户端软件的特点是只有用户升级之后才能使用到新版本带来的功能特性。所以大多数客户端软件都存在经常发版的情况。如果一个公司只讲究交付的版本稳定，一个月一版软件对用户来说也就够用了，但如果公司想鼓励“微创新”持续为用户提供有价值的特性和服务，快速交付就是对内部的一个新挑战。
通常一个官网项目在实施敏捷项目管理的前提下，前期产品规划需要一周时间，开发差不多6～8天，集成测试6～8天，发版前产品验收1～2天，加起来整整一个月。按照帕累托原则，如果压缩通常会压缩那些时长80%的活动，可根据上面的描述很确定从哪里压缩。如果完全不讲规则，产品经理提供明确的需求和目标，团队靠努力半个月完成两个版本并不是困难的事情，但会造成团队士气低落、版本质量下降、后期维护成本高等一系列问题。为了解决上面的一系列问题，团队提出了产品集中规划这个应对方案。简单地讲，集中规划是产品人员尽早地组织研发、测试，敏捷教练一起来集中讨论下一版本的需求。为此团队还设置了集中规划的检查表，如下表所示。
集中规划的作用体现在让产品、研发、测试团队在版本正在开始做的前一周内已经充分理解了需求。大多数公司的产品需求都是立项时没有充分讨论的，所以做的过程中会出现各种理解偏差，甚至有的逻辑根本没想清楚，研发都完成了才发现和之前的版本有重大冲突，变更就成了常见的现象，导致的结果就是开发周期长，测试周期长。集中规划的实施让团队提前做了产品的推演工作，针对大的研发任务和需要调研的问题，在本版开发期间进行调研和技术积累工作，为下一版本的开发做技术准备。对比效果参见下图。
从上图看压缩最大的是集中规划和测试时间，测试能压缩是基于在敏捷项目管理过程中对研发提交任务完成标准的更高要求，在这次改革过程中研发提交的应是经过产品验收的可运行的产品。对产品经理的要求是不需要提需求上的变更，团队可以在开发阶段提出优化类的技术方案和需求，敏捷教练组织团队自行决策优化工作是否在本期完成。经过1个月两个版本的试点工作，团队已经适应了这种集中规划带来的整体交付效率的提升。
3.用Wiki来构建过程资产库
过程资产库是CMMI的说法，通常一个过程资产库包括很多内容，例如标准过程文件集合、一些最佳实践积累、度量库、风险库、培训库、基础平台库、产品成果库等。每个库都分层来进行建设和运营，标准过程库公司按金字塔进行划分。这样的标准过程体系给人的感觉是井然有序，层次划分也是从决策层定的管理规则到团队生命周期的选择指导，再裁剪成团队所需要的过程，应用过程中提供的标准模版、工具和检查单。可能很多人向往这样的管理方式，项目按照这样的过程实施下来风险会降到很低，这对于做行业应用软件的项目型公司非常有效，但对于互联网软件这样的产品型公司来讲会成为效率最大的束缚。
不管是哪种类型的公司，不管是公司高层还是项目团队，都希望做的成果有积累，对于研发人员来说最希望得到积累的是技术，例如一些通用组件、皮肤引擎框架、下载组件等。对于项目负责人来说希望得到用户故事的估算数据、项目中遇到的难点和难点解决方案及项目成功经验和失败教训。对于测试人员来说希望得到哪些用例最效率、Bug的各种分析数据。综合这些需求，实际上团队需要两种数据，一种是结构化的可用来分析的数据，另一种是可以被容易地搜索到并对开发过程起到帮助作用的数据。
Wiki是敏捷项目管理中常用的记录过程的工具，暴风的敏捷项目使用Redmine进行缺陷管理和项目管理，也应用工具提供的Wiki进行资产管理。Redmine是一个灵活的项目管理与缺陷跟踪工具。它是基于Ruby on Rails框架建立的Web应用程序， 页面简单易用， 给敏捷项目管理带来了极大的帮助。使用Wiki进行资产管理的核心思想是“前人栽树，后人乘凉”，发挥团队的力量，靠“团队不停地优化”并借助互联网进行建立、积累、优化和分享的全新的资产管理（也称知识管理）模式。一个人的知识面和学习能力都是有限的。尤其是在IT行业，各种开发技术的半衰期通常只有半年到一年半。所以是对学习过的东西进行整理、记录备份是很重要的，可以方便需要的时候迅速查阅，防止知识遗忘。这就是个人知识管理。
一个人的学习能力是有限的，在项目中必须去学习和掌握的东西超过了个人的记忆速率。特别是针对产品型公司，通过Wiki来追述历史，记录一些关键的需求和设计逻辑，防止遗忘或与前面的需求冲突。团队可以根据自己的工作习惯在立项前完成Wiki框架的建立，可以记录敏捷项目管理的数据，也可以记录敏捷项目管理过程中发生的一些好的现象，还可以记录一些技术难点的解决技巧。下图就是暴风某个项目的Wiki记录，其中测试目标是团队的一项发明，用本版遗留的Bug加上本版代码所有的基准版本的Bug数作为分子、用本版所有的Bug数作为分母来度量项目的质量可信度。在所有影响用户体验的Bug和中等级别以上的Bug都解决后，如果测试目标达到90%，则认为是质量卓越的。大家一定疑虑这个质量目标太低，实则不然，在分子所有不可信的因素中至少有80%的Bug是需求问题，而不是真正意义上的缺陷，但都严格地记录在缺陷中来推动产品经理去思考如何优化需求。
在Wiki中项目资产和知识怎么进行有效的管理呢？没有对知识和项目资产的有效管理，就不可能有项目团队效率的提升。建立自己团队的知识系统架构，即按类别创建合适的Wiki条目，这才是有效的项目资产管理。什么是知识系统架构？简单地说就是储藏知识的目录结构，类似于图书馆的图书分类。这样才有助于未来快速地获取项目中的资料，如果缺乏分类架构，将造成大量时间浪费，达不到通过项目资产管理提高团队效率的目的。每个团队的风格不同，创建知识系统架构的风格也不尽相同，可以以时间轴为思想，也可以以需求、设计、代码、测试这样传统的软件工程阶段为主线进行划分。暴风的创建思路是以产品线的时间轴为一个维度，项目管理、需求、设计、代码心得、测试经验为第二个维度进行创建，优化了Redmine的搜索功能，更方便团队成员进行分类检索。
4.持续集成，自动化构建的探索
在敏捷思想上，是提倡持续集成的，微软在软件开发过程中，提出了每日构建的思想，一度被称为微软产品开发的“心跳”。在暴风，为了追求更高的研发效率，每日构建已经不再能够满足需求，需要研发团队做得更快、更好。所以，在这里倡导实时构建，持续集成。持续集成，不但能减少代码冲突，还能减少每一次集成的变更，即使集成失败也容易定位错误。
经过探索，一次集成中包括下面的一系列动作：在SVN中获取项目的所有源代码、静态分析、编译、运行所有测试、产品打包。一次集成完成后，还会生成一份报告。团队准备了大电视当成显示器来显示不同项目的集成状态，开发人员很容易看到哪些项目进入了集成状态，以及最近一次集成的成功时间。开发人员很容易得知目前自己的项目代码是否是可用和可靠的。如果自己所关心的项目集成状态是失败的，那就给项目团队做了提醒，需要尽快定位失败原因从而让集成状态变成可用。在持续集成工具的选择上，采用的是现在比较流行的开源工具Jenkins。
上图是持续集成流水线的基本模型，流水线贯穿产品的代码开发、产品测试、产品交付（可用软件包）的全过程。虽然看似很完美，但是在实际项目中还是遇到了些麻烦事。
麻烦事一：定义了一次好的集成，从更新代码到静态检查、单元测试、编译打包、最终出报告，项目初期每次集成用30秒、1分钟，但随着代码的增多，单元测试的增多，集成的时间越来越长，甚至超过5分钟，这意味着，开发人员的每次提交都要经过5分钟的等待，在这种情况下，团队如何能保证构建的实时性？
麻烦事二：“我这机器上是好的，怎么你测的时候就有问题了呢？”这句话想必大家一定不会陌生，如果仔细调研一下很容易发现，造成这种现象的原因基本上是因为环境的问题，开发人员的测试往往是在自己的IDE下进行的，而测试人员的测试通常是在测试服务器上进行的，两者之间往往存在着细微的差异，比如代码是否完全一致、数据是否完全一致、平台是否完全一致等。
如何解决以上两个问题，是推广持续集成的课题。经过持续地优化，团队定义了一套属于自己的部署流水线，其中用了一些SVN管理的技巧，以及分层构建、分层测试的思想，如下图所示。
竖轴把一次集成定义了多个层次，这就好比“淘金”，由于做到了实时构建，这样就不可避免地产生了大量的“小版本”，其中很多版本是不可交付的，所以通过一层层筛选，最终能留下的版本，就是团队需要的“金子”。同时在测试这一层把测试分解成单元测试与自动化测试（自动化测试往往很耗时），这样在项目团队里，团队成员约定了集成成功的标准——单元测试通过，也就意味着当提交的代码单元测试通过了，就可以认为代码是好的，可用的。提交代码的开发人员此时不必继续等待，可以继续完成其他的工作。在后续自动化测试失败时，开发人员还是需要放下手头的其他工作进行修复。
分层的原理其实很简单，就是上文提到的“SVN管理的技巧”，把SVN的Tag功能发挥到极致就可以实现，传统的Tag仅仅是对一个不会变的版本进行标记，一旦打了Tag，就意味着代码不能再进行变更。暴风团队用了一个神奇的Tag——“last- success”，既不违背SVN的Tag本身的含义，又能巧妙地把分层集成的任务与SVN版本库紧密地连接在一起，更重要的是，通过这种手段，做到了单一代码来源的原则。下图揭示了任务命名的规律。在触发1010任务时，会在SVN的主干（或者分支）上获取到最近的变更，当1010任务结束时，即编译通过时，我们会在Tags下更新神奇的1010-last-success标签，这样做，不仅仅做到了持续集成的结果可追溯，更为之后的1020任务做了“种子”。
开发测试环境是开发人员跟测试人员进行模块测试的一套环境，注意，此环境不同于开发人员自己本机的测试环境，我们通常把开发自测的环境称为本地测试环境，当开发人员说“自测通过了”，并不仅仅指“本地”测试通过了，而是在“本地”测试通过的情况下，在“开发测试环境”也同样测试通过了。这样就有效地避免了开发与测试之间针对Bug“扯皮”的现象，“我这里可以通过”的说法自然也就不存在了。当功能开发到一定阶段集成测试环境就开始起作用了，在“集成测试环境”中，构建会大大简化，为了避免再次编译产生的不一致性，配置管理员不再对源代码进行二次打包，通过对配置文件进行替换后，直接在“集成测试环境”中进行发布。
演示环境的流程同集成测试环境一样，会在集成环境直接拿编译好的二进制文件。演示环境的意义是什么呢？演示环境是要给客户（产品经理）看的，作用是确定产品是否最终能上线，这个环境通常要调试得比较仔细，它也是上线的最后一关，演示环境会尽量模拟生产环境的各种参数。这里没有选用集成环境做演示，原因在于不希望因为演示而中断集成测试工作，因为谁都不能保证演示能真的成功，互联网行业就像是一个高速向前滚动的轮子，优化工作永远没有终点。
5.度量与流程优化
一个公司的高层技术管理者应该管三件事情：管人、管过程、管技术。如果能推动一个流程优化30%以上的效率，在ROI合理的情况下，就应该毫不犹豫地去做。CMMI 4级中也有过程性能的实践，例如公司Code Review的过程能力是平均每人时发现2～3个设计缺陷，如果改变流程和方法能提升到3～4.5个，那一定不遗余力地去执行，实施流程优化不是为了求稳，而是让流程真正地体现价值。度量在流程优化过程中能起到关键作用，但必须有以下两个前提。
第一个前提是度量所获得的数据必须是真实有效的。很多公司都收集研发过程中的工时数据，要保证工时数据的有效性，一定不要考核这些度量数据，如果增加了考核这些数据就会变得很好看，但却不能真实地反映项目的实际情况。暴风通过两套数据来保证项目中工时数据的准确性，一套是公司自己开发的工时管理系统，敏捷教练将用户故事导入系统中，员工根据自己的任务填报每日完成的工时，部门总监负责工时数据的审批，另外一套是敏捷教练根据每日例会记录的实际工时，两套数据对比之下就能基本保证工时数据的真实性和有效性。
第二个前提是度量数据要具备完整性，特别是度量分析数据。下图描述了两组缺陷数据：缺陷发现数、缺陷发现数和缺陷解决数，如果根据这两组数据来判断软件在第20天是否可以发布，无疑第一组没有参考价值，第二组数据有一定的参考性，但还不算完整。完整的判断应该在第二组数据的基础上加上一条收敛曲线，然后再和暴风的测试通过标准数据进行对比：（1）不能有严重和次严重级别的Bug；（2）Bug的移除率大于97%（移除率在暴风可以根据各个项目的特点自行定义）。这样的度量数据才能真正指导项目，进而指导流程的优化。
在上面两个前提下实施度量也要和公司的业务目标（Business Goal）对应起来，度量和流程改进都是服务于业务目标的。很多公司和管理者都说不清楚业务目标，对这样一个外来的、翻译过来的词汇都一头雾水。拿暴风的无线互联网业务为例，当前的业务目标就是获得用户规模的高速增长，在这个目标下需要研发做的事情是提高研发效率，快速高效地交付对用户有价值的功能，对于用户体验不够优化的功能，能快速地进行优化并让用户感知。
简单地讲，在当前的业务目标下对流程提出的要求是快速交付。上文也介绍了实施集中规划后交付周期的大幅提升，上次优化的是交付周期，从22天优化到了不到15天。如果要在现有基础上再提高50%还有哪些流程可以优化？其实还是有优化空间的，现在实施的自动化测试和持续集成将原来的测试周期压缩了将近一半，这一项还有一定的压缩空间，研发上次完全没有压缩，如果采用结对编程，在增加资源的情况下，研发周期也能进一步优化。所以流程改进永无止境，只要能找到正确的度量方法，在符合业务目标的前提下都能找到优化空间。
五、组织改进中人的因素
公司中重视人的因素起源于人性化管理之父梅奥，他在著名的霍桑实验中提出了两个结论。
（1）影响生产效率的根本因素不是工作条件，而是人本身。人期望自己“被注意”，期望自己是一个重要的存在，因而怀有归属感，这种意识助长了人的有所作为的观念和完成任务的观念，正是这种人的因素导致了劳动生产率的提高。
（2）在决定人们工作效率的因素中，个人为团体所接受的融洽性和安全感较之奖励性工资有更为重要的作用。
霍桑试验的研究结果表明了人不是被动的、孤立的个体，他们的行为不仅仅受工资的刺激，影响生产效率的最重要因素不是待遇和工作条件，而是工作中的人际关系。这个80年前的研究成果对于一个互联网公司有着重要的指导意义，互联网公司追求高效，研发依赖研发人员的能力，流程对于个人能力来说只是起辅助的作用，所以管理上应该更注重人的因素。
1.组织文化对敏捷的支持
组织文化在很多公司都是务虚的一堆词汇，或者是老板文化。如果一个公司想推行组织文化来支持公司的业务战略或者研发战略，不妨认真思考一下公司的战略方向到底是什么，需要塑造什么样的文化来支持战略。下图是战略和组织文化的关联矩阵，杨国安教授在谈论企业持续成功的因素时阐述了“企业持续成功=战略×组织能力”的公式，两者之间是相乘关系，而不是相加，其中一项不行，企业就无法成功。
暴风的研发团队在定“优化”作为文化时就做了上述的对应，为了提高生产率，提高质量和交付的合格率（按时交付并且满足产品需求），优化和这三项的关联度最大，通过员工的优化行为可以砍掉项目中不必要的环节，而只去做对项目目标有直接影响的事情，这样就能提高效率；有优化的意识，经常去审视自己的代码或者团队成员的代码等于直接做了Code Review，再有优化的行为将代码写得简而精，这样也能提高质量；在完成每个任务时都去思考哪些工作可以优化而把任务完成得卓越，这样保证了交付的任务能合格或卓越地交付。所以“优化”可以考虑作为团队内工作的一种文化。
一个企业的文化应该尽量是包容的，而不是单一的文化，例如质量文化、效率文化也很重要。下面的矩阵帮助公司来筛选当前阶段最重要的组织文化应该是什么，筛选的标准根据相对重要程度和当前公司的实力进行相乘，取结果高的最先在公司内推广。暴风的工作习惯是选择当前最为紧急的且重要的事情去做，而不是同一时间面面俱到地做很多事情，任何公司的资源都是有限的，只有这样做才能充分利用资源将事情做到极致。
杨国安教授在《组织能力的杨三角》中提到组织能力需要三个支柱，一是员工思维模式（愿不愿意），二是员工能力（会不会），三是员工治理方式（允不允许）。一个组织或一个团队要具备执行一个战略的能力，需要这三个支柱来建立。第一个支柱是这个团队的人对不对，有没有相应的知识技能和素质？比如暴风做Android端产品，团队成员是否具备Android的开发经验，有没有播放的开发经验，这就是员工能力。 第二个支柱是员工思维，这一群人每天上班工作的时候是不是真的关心这个事情，比如开发Android暴风影音产品，团队是只完成工作还是发自内心地当成自己的产品来做，这是两种完全不同的思维，在暴风，很多团队都把产品当成自己的孩子来呵护，也为产品能得到海量用户的认可而感到骄傲。第三个支柱是员工治理，即允不允许做，就是公司让员工优化也好，做质量也好，那么公司有没有提供相应管理上的资源和支持。
在三个支柱中最重要的是员工思维的问题，公司的业务目标老板们都觉得很重要，但员工心里面想不想配合你走这条路？这是思维模式中一个要解决的问题。很多公司开大会小会每天不断讲，但效果不明显，比如产品经理说页面展现优化得不够好，研发测试员工可能会抵触，如果把微博用户反馈和观察员的真实使用反馈直接给研发人员看，他会真正意识到自己做的产品有问题，这才有效传达了期望员工通过优化提高用户体验的想法，也有助于团队养成优化的思维方式，最终对推行敏捷项目管理提供组织文化上的支持。
2.研发管理“三驾马车”中的人才
汉代以前，军队中还没有骑兵出现，战车是战争的主要工具，士兵乘坐的是两马拉一车的战车。中军统帅的战车由三匹马来拉，也称“三驾马车”。对于研发管理来说，“三驾马车”分别是人才、技术和流程制度。前面多处提出了实施敏捷项目管理后流程制度带来的变革，对于互联网公司来说技术型人才对于任何公司都是稀缺的，这就使如何更好地管理技术型人才成为每个互联网公司必须研究的课题。
暴风人才管理问题的症结在于能带项目团队完成工作的技术人才储备不足，也缺乏有效的人才培养机制。遇到这种问题通常是通过招聘找到外部有经验的技术人才来带领公司内部的员工完成项目工作，新人过来后融入的时间长，而且每次做创新的事情都需要从外部寻找人才。这凸显了互联网公司内部“造血”功能的不足。理性分析之后可能是行业特点所决定的。第一，整个互联网行业的人才多数是技术型人才，技术上单兵作战的能力很强，在成规模的企业中缺乏协作能力和带团队共同完成目标的能力。第二，互联网行业从技术人才转化为管理人才的难度大，人员年轻，没有管理方法，也不愿意去学习管理方法，经常把事情都揽在自己身上，以至于自己成为瓶颈资源。第三，行业人才竞争激烈，特别是对于技术类人才缺乏收入的保障，只要行业内给出现有工资的1.5倍或2倍，人才流失的风险非常大。这些行业因素无疑给人才管理带来了巨大的困难。
公司做了很多努力来提升技术人才的素质和战斗力。第一，政策导向，公司内部发布公司的用人观和人才观，让全员都清楚公司鼓励内部提拔和内部培养，在人员储备上做一些资源冗余。第二，成立项目管理训练营，针对有意愿向管理转型并且具备基本管理素质的人才提供管理的培训，培养技术人才管理的理念、项目管理的知识体系。每年经过内部的培训，实战选拔人才派到外面的培训机构进行再次培训和培养，然后回公司给机会带实际项目，并检验其水平是否有提高。第三，建立公司的资产库，将公司的各项目Wiki成果进行分类，包括项目得失、最佳实践、新技术分享，并且开放给技术人才作为学习平台。第四，给技术人才的分类和职业通道分成两个职业方向（专家序列和管理序列），建立两个序列的任职资格标准。鼓励基层员工按照公司制定的职业规划进行发展。这些努力的管理创新点在于：成体系的内部培养机制。进行技术人才资源冗余，为未来的业务做储备。
再次思考为什么上面的措施有管理可行性？一个企业要长期发展必须依赖自己的培养体系，以及自己的培养体系培养出来的人才。企业“造血”功能不足必定不能支持企业在人才储备和人才资源获取上走得更长远。如果要完成长期的人才体系培养，公司需要有足够的利润作为资源冗余的资本，暴风的经营业绩足够支持现在做人才管理的储备、挖掘和培养。从人才战略的角度考虑，公司发展了5年，有一半业务需要运营型人才，还有另外一半需要创新型技术人才。所以未来组织蓝图上需要“制度型”和“创新型”的区分管理模式。“制度型”更有效地管理了业务和运营类人才，“创新型”则更鼓励研发人才创新和成长。
3.任职资格体系助力研发人员成长
任职资格体系不是绩效考核，它是从员工称职胜任角度出发，对员工能力进行分级分等，以任职资格标准体系来规范员工的培养和选拔，建立员工的职业发展通道，牵引员工不断学习，同时为员工晋升、职业发展、薪酬调整等工作提供重要的参考依据。暴风开始实施任职资格体系是从别的公司参考过来简化处理的，因为互联网视频行业技术的多样性和初期研发团队规模比较小，实施效果并不算好。随着研发团队规模的增长，在招聘和人员晋升上已经显现了作用。
暴风的任职资格体系为研发类员工提供了两条职业发展通道，一条是管理路线，一条是技术专家路线。很多技术人员其实并不想做管理，但行业内很多公司如果不提拔到管理岗位就很难拿到相应的薪酬，两条职业晋升路线解决了薪酬的公平性问题，即使不做任何管理工作，一个高级架构师的薪酬和研发总监是水平相当的，所以员工只需要关注自己是否能达到相应的任职资格要求，而不需要非要去做管理工作。在整个公司实际上也是重技术轻管理的。
任职资格搭起了任务和员工知识技能的桥梁，明确了完成任务需要的行为标准，员工要达到成功需要哪些必备知识与技能；根据行为标准对员工的工作行为进行评估，便于了解员工还需要掌握哪些必备知识。暴风任职资格体系为研发类员工分了五个级别，每个级别下又分了三个小级别（也可以认为是三等）。按照不同的技术方向来编制任职资格的行为标准，例如Web研发工程师任职资格标准、P2P研发工程师任职资格标准等。标准的制定需要先找公司内最符合标准的标杆人物，以标杆人物的行为标准来制定员工的行为要项。初期实施难度大的原因是每个等级很难找到标杆人物，因为某些领域的研发工程师可能只有一个人，所以规模小的研发团队初期实施任职资格体系时尽量采取简化的原则，不必定太多的行为标准。
合理的任职资格评估应该每半年一次，初期实施任职资格评估时需要员工来按照申报的级别来自己准备证据（日常工作中能证明自己符合某条标准的文档、邮件、代码等），主管领导审批后报给评估小组来评估是否达到申报级别。评估过程由申报人按照任职资格标准逐条来陈述自己的证据，评委可以随时提出问题来判断证据是否满足行为标准。这样，一个申报人评估下来需要至少1～1.5小时，评委至少3人，所以投入的资源还是比较多的。后期改进后不需要申报人逐条准备证据，由直接上级按照任职资格标准的模块来阐述申报人是否能够达到行为标准，好处是降低了申报人和评委的工作量，缺陷是没有深入地了解申报人哪些行为需要改进和提高。
很多人力资源界的专家认为冰山模型分成两部分，露出水面的部分叫任职资格管理，水面以下的部分叫胜任素质。尽管这种观点还存在很多争议，但如果实施任职资格管理，任职资格标准的建立应该包括知识、技能、行为、贡献等内容，任职资格的评估除了对员工进行等级评估外，还应该更注重在评估过程中对员工的待改进部分进行指导和提升。这样才能通过任职资格体系真正帮助员工持续地进步。
4.培训项目经理的长期重任
敏捷项目经理的培养对任何公司来说都是一个难题，不要认为会带来Sprint做敏捷规划、能够组织敏捷例会、带领团队进行Sprint总结就是一个敏捷项目经理了，那是大错特错。虽然敏捷项目管理和相对传统的项目管理貌似有些背道而驰，但不意味着传统的项目管理知识、技能、工具、方法不能应用，实际上一个敏捷教练也需要更多的项目管理知识背景和实际带项目的经验。从组织层面培养项目经理不是一朝一夕的事情，很多公司认为建立好标准化的流程，然后做好流程培训，这样工作便和人员不相关。这更是对软件行业从业人员的极大不尊重，即使是同样的流程，由于技术水平的不同执行下来结果会有天差地别。
项目管理训练营是一种很好的培养项目经理的方式，最重要的是坚持不懈的培训机制，以及培训的内容能真正帮助项目经理的成长。培训机制其实并不神秘，结合公司实际情况的基础培训加上公司一些实际项目案例的演练，长期坚持就能提高项目经理的水平。 需要说明的是，这种培训机制不是立竿见影的，需要公司在培训过程中不断地优化培训内容，促成项目经理之间的经验分享，对于每个被培训的项目经理来说整个过程有些枯燥和乏味，“他山之石，可以攻玉”，学习能力强的项目经理在这个过程中学到的不仅仅是一些枯燥的方法和工具，而是其他项目经理在实战过程中解决问题的方法。虽然培训的内容不完全是敏捷项目管理，而是一些IT传统项目管理的知识、工具、技能和方法，但却能让项目经理更理解敏捷的思想。下表是项目管理训练营培训的课表和排期，可以给各公司的PMO和高层管理者借鉴。
5.“求是堂”和干部培养
干部培养是各个公司都去积极实施的一个项目，暴风的干部培养活动主要是“求是堂”。它包括两个活动，听一次课，选一个自己带的项目制定卓越的指标并且达到。如果项目能完成卓越的指标干部就达到毕业标准了。其中课程讲述部分主要讲述两方面的内容：业务管理方法论和研发管理方法论。业务管理的方法论强调业务要有明确的目标，要完成业务目标必须明确核心打法，核心打法和业务目标之间的因果关系要得到证明，每个核心打法要分解成关键动作来支撑。研发管理的方法包括目标、目标量化描述、找到和量化目标之间的差距、寻找缩小差距的要因、制订计划并持续优化五个步骤。例如，研发的目标是提高从点击桌面图标到客户端软件打开的启动速度，首先要定一个合理的目标（启动快），将目标具体量化进行描述（首次启动1.5秒以内），然后寻找差距（当前3～4秒），如果要缩小差距，包括磁盘I/O读/写优化、皮肤加载优化、界面显示优化三个主要因素。最后一步就是进行技术调研，然后制订一个可执行的计划。
业务管理和研发管理有哪些共性和差异呢？谈到管理其实殊途同归，下表对比了业务管理和研发管理方法论之间的共性。一个普通研发人员只需要按照敏捷项目管理的框架认领任务完成项目即可，但研发干部应该经常思考项目的目标。互联网公司不同于传统按合同交付项目的软件企业，在业务规划下有很多项目可以做，但一定要思考完成项目后是否能真正地让用户喜欢，最终达到支持业务的目的。如果一个研发项目交付的结果不能让30%的用户喜欢或者技术指标的优化空间不足50%，那么这个项目的优先级值得考虑。
研发管理和业务管理也有很多差异（参见下表），做业务是0和1的关系，比如去争取一个销售订单，赢了就能签约。研发管理是好与不好的关系，项目都能做完，就看最后的结果是否能得到客户或用户的认同。
杰克·韦尔奇在《赢》中提出了促进公司赢的各种因素，暴风的干部培训也是以“赢”为核心思想的，通过培训让大家掌握业务管理和研发管理的不同方法论，然后各业务的负责人来指导自己的干部队伍去选择他们所带的项目，按照方法论进行预演，帮助干部找到核心打法（要因）和关键动作（执行计划），最终帮助干部带领自己的团队去达到卓越的指标。这样会在公司内让干部有“赢”的欲望，也会带动员工一起获得成功。
·作者简介·
杨立东
PMP，美国加州州立大学富尔顿分校硕士，中欧国际工商学院EMBA，华中科技大学特聘教授。北京暴风科技股份有限公司董事、首席技术官。2011年第二批“中关村高端领军人才聚集工程”科技创新人才。发表学术论文4篇。
曾从事过6年一线Java开发工作，作为项目经理带领过多个大型软件项目，2006年开始从事CMMI咨询和评估工作，服务过的软件企业超过30家，多次举办项目管理、软件度量、敏捷项目管理的公开课，培训人数超过15000人。2008年开始专注于公司级管理工作， 2010年开始总结自己多年的研发管理经验，专注于互联网公司敏捷项目管理的推广和实施。