下载掌阅APP，畅读海量书库
立即打开
戴明（W．Edwards．Deming）博士是著名的质量管理专家，很多公司的持续改进都借鉴了戴明博士的管理思想。著名的14要点中描述了“最高管理层必须从短期目标中迷途而返，转回到长远建设的正确方向。也就是把改进产品和服务作为恒久的目的，坚持经营，这需要在所有领域加以持续地改革和创新。”
对于一个拥有庞大用户群的客户端软件，必须不遗余力地持续优化自己的产品体验和服务。所以持续优化成了暴风的主旋律，不论是用户需求的收集，产品功能的开发，还是内部内容的运营，都抱着持续优化的思想，这才是企业持续发展的原动力。
软件项目管理有两种方式，一种是根据过去的经验去总结和完善，以此作为借鉴来管理当前的项目，另外一种是根据当前项目的表现来预测项目的未来。这一点在挣值管理里表现得淋漓尽致。使用挣值可以了解当前项目的状况，也可以用挣值管理的三种方法来预测项目的未来。而在敏捷项目管理里预测完全起不到作用，因为其核心思想倡导快速迭代和交付。
燃尽图就像开车时的后视镜，是保证开车安全的重要工具。有效地使用它能指导团队在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目标。
对于暴风的官网版本，在暴风影音5发布之后，基本上还是保持每个月一个官网的频率，客户端软件的特点是只有用户升级之后才能使用到新版本带来的功能特性。所以大多数客户端软件都存在经常发版的情况。如果一个公司只讲究交付的版本稳定，一个月一版软件对用户来说也就够用了，但如果公司想鼓励“微创新”持续为用户提供有价值的特性和服务，快速交付就是对内部的一个新挑战。
通常一个官网项目在实施敏捷项目管理的前提下，前期产品规划需要一周时间，开发差不多6～8天，集成测试6～8天，发版前产品验收1～2天，加起来整整一个月。按照帕累托原则，如果压缩通常会压缩那些时长80%的活动，可根据上面的描述很确定从哪里压缩。如果完全不讲规则，产品经理提供明确的需求和目标，团队靠努力半个月完成两个版本并不是困难的事情，但会造成团队士气低落、版本质量下降、后期维护成本高等一系列问题。为了解决上面的一系列问题，团队提出了产品集中规划这个应对方案。简单地讲，集中规划是产品人员尽早地组织研发、测试，敏捷教练一起来集中讨论下一版本的需求。为此团队还设置了集中规划的检查表，如下表所示。
集中规划的作用体现在让产品、研发、测试团队在版本正在开始做的前一周内已经充分理解了需求。大多数公司的产品需求都是立项时没有充分讨论的，所以做的过程中会出现各种理解偏差，甚至有的逻辑根本没想清楚，研发都完成了才发现和之前的版本有重大冲突，变更就成了常见的现象，导致的结果就是开发周期长，测试周期长。集中规划的实施让团队提前做了产品的推演工作，针对大的研发任务和需要调研的问题，在本版开发期间进行调研和技术积累工作，为下一版本的开发做技术准备。对比效果参见下图。
从上图看压缩最大的是集中规划和测试时间，测试能压缩是基于在敏捷项目管理过程中对研发提交任务完成标准的更高要求，在这次改革过程中研发提交的应是经过产品验收的可运行的产品。对产品经理的要求是不需要提需求上的变更，团队可以在开发阶段提出优化类的技术方案和需求，敏捷教练组织团队自行决策优化工作是否在本期完成。经过1个月两个版本的试点工作，团队已经适应了这种集中规划带来的整体交付效率的提升。
过程资产库是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的搜索功能，更方便团队成员进行分类检索。
在敏捷思想上，是提倡持续集成的，微软在软件开发过程中，提出了每日构建的思想，一度被称为微软产品开发的“心跳”。在暴风，为了追求更高的研发效率，每日构建已经不再能够满足需求，需要研发团队做得更快、更好。所以，在这里倡导实时构建，持续集成。持续集成，不但能减少代码冲突，还能减少每一次集成的变更，即使集成失败也容易定位错误。
经过探索，一次集成中包括下面的一系列动作：在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“扯皮”的现象，“我这里可以通过”的说法自然也就不存在了。当功能开发到一定阶段集成测试环境就开始起作用了，在“集成测试环境”中，构建会大大简化，为了避免再次编译产生的不一致性，配置管理员不再对源代码进行二次打包，通过对配置文件进行替换后，直接在“集成测试环境”中进行发布。
演示环境的流程同集成测试环境一样，会在集成环境直接拿编译好的二进制文件。演示环境的意义是什么呢？演示环境是要给客户（产品经理）看的，作用是确定产品是否最终能上线，这个环境通常要调试得比较仔细，它也是上线的最后一关，演示环境会尽量模拟生产环境的各种参数。这里没有选用集成环境做演示，原因在于不希望因为演示而中断集成测试工作，因为谁都不能保证演示能真的成功，互联网行业就像是一个高速向前滚动的轮子，优化工作永远没有终点。
一个公司的高层技术管理者应该管三件事情：管人、管过程、管技术。如果能推动一个流程优化30%以上的效率，在ROI合理的情况下，就应该毫不犹豫地去做。CMMI 4级中也有过程性能的实践，例如公司Code Review的过程能力是平均每人时发现2～3个设计缺陷，如果改变流程和方法能提升到3～4.5个，那一定不遗余力地去执行，实施流程优化不是为了求稳，而是让流程真正地体现价值。度量在流程优化过程中能起到关键作用，但必须有以下两个前提。
第一个前提是度量所获得的数据必须是真实有效的。很多公司都收集研发过程中的工时数据，要保证工时数据的有效性，一定不要考核这些度量数据，如果增加了考核这些数据就会变得很好看，但却不能真实地反映项目的实际情况。暴风通过两套数据来保证项目中工时数据的准确性，一套是公司自己开发的工时管理系统，敏捷教练将用户故事导入系统中，员工根据自己的任务填报每日完成的工时，部门总监负责工时数据的审批，另外一套是敏捷教练根据每日例会记录的实际工时，两套数据对比之下就能基本保证工时数据的真实性和有效性。
第二个前提是度量数据要具备完整性，特别是度量分析数据。下图描述了两组缺陷数据：缺陷发现数、缺陷发现数和缺陷解决数，如果根据这两组数据来判断软件在第20天是否可以发布，无疑第一组没有参考价值，第二组数据有一定的参考性，但还不算完整。完整的判断应该在第二组数据的基础上加上一条收敛曲线，然后再和暴风的测试通过标准数据进行对比：（1）不能有严重和次严重级别的Bug；（2）Bug的移除率大于97%（移除率在暴风可以根据各个项目的特点自行定义）。这样的度量数据才能真正指导项目，进而指导流程的优化。
在上面两个前提下实施度量也要和公司的业务目标（Business Goal）对应起来，度量和流程改进都是服务于业务目标的。很多公司和管理者都说不清楚业务目标，对这样一个外来的、翻译过来的词汇都一头雾水。拿暴风的无线互联网业务为例，当前的业务目标就是获得用户规模的高速增长，在这个目标下需要研发做的事情是提高研发效率，快速高效地交付对用户有价值的功能，对于用户体验不够优化的功能，能快速地进行优化并让用户感知。
简单地讲，在当前的业务目标下对流程提出的要求是快速交付。上文也介绍了实施集中规划后交付周期的大幅提升，上次优化的是交付周期，从22天优化到了不到15天。如果要在现有基础上再提高50%还有哪些流程可以优化？其实还是有优化空间的，现在实施的自动化测试和持续集成将原来的测试周期压缩了将近一半，这一项还有一定的压缩空间，研发上次完全没有压缩，如果采用结对编程，在增加资源的情况下，研发周期也能进一步优化。所以流程改进永无止境，只要能找到正确的度量方法，在符合业务目标的前提下都能找到优化空间。