下载掌阅APP，畅读海量书库
立即打开
当一个研发团队管理者从战略角度去思考时，分析外部你会去看整个行业、你所在企业在行业中的位置、你的上下游企业的议价能力、竞争对手分析等。像波特五力分析那种在传统行业应用得滚瓜烂熟的分析工具和框架，同样也适用于新兴的互联网软件企业。而企业内部分析也同样可以参照那些已经成熟的战略思考框架。为了在同类竞争对手中建立自己研发团队的核心能力，我们必须去认真地思考我们到底需要什么？毫无疑问，对于互联网软件公司来说，保证质量前提下的交付效率是我们需要打造的核心能力。
交付效率怎么定义？可以定为及时交付率、可以定为项目平均交付周期等，不管怎样，其目标和结果就是，如果在同一起点研发同质化的功能，我们要领先竞争对手1～2个月。这里面需要架构师的努力，研发高手的拼搏，测试高手的奋斗，也需要有一种思想来引领整个团队来达到这个目标，这种思想叫敏捷。
先打破一下大家对组织的看法，由于CMMI的侵蚀，大多数人产生了错觉，认为组织一定是整个公司，其实组织可以是整个公司，也可以是公司中的某个团队，例如播放产品、播放研发、播放测试、播放运营四个团队可以称为一个完整的组织。对于一个企业或企业中的某个组织，引入一套管理体系或者某个管理工具来优化管理流程，无外乎两种引入方式。
第一种方式是从“企业自我”出发，循序渐进地进行流程优化。目前，国际国内的一些知名企业，一些知道自身痛处和优化重点的组织，都选择了从“企业自我”出发，循序渐进方式的流程优化和改进。这种方式一般的做法是：先重点总结和反思组织当前的实际业务情况，项目执行过程中遇到的实际问题，然后根据问题的优先级，选择某些方面先开始优化，并针对组织在该阶段的管理水平、团队能力、想要达到的目标和结果等，进行有针对性的培训、辅导、执行和复盘总结，等收到了预期的实际效果时，再逐步开始其他方面的优化和改进。
这种方式的优点是完全尊重了组织现有的能力和文化，循序渐进地进行优化与改进，每一个阶段都能够解决一些实际的问题，并看到流程优化的实际效果。但由于组织这种“优化”文化的形成、技术管理人才的培养往往要经历一个比较漫长的过程，可能遇到的问题是时间周期太长，没有明显的结果。
第二种方式是以体系和管理工具为中心，“拿来主义”地进行流程优化。目前，国内一些企业或组织最常见的方法是所谓“拿来主义”的流程优化。别人实施CMMI，我照搬流程、文档模板过来，现在流行敏捷项目管理，我也照搬过来。用的过程中再逐步地完善和优化，以适合组织的需要。
这种方式一般的过程是：找到参考组织，通常是行业内比较牛的企业，先把整套框架照搬，在组织中进行强制推广，根据实施的效果和组织自身的实际情况，逐步进行完善和优化，最后形成符合组织自己实际要求的、稳定的流程规范。某知名企业在引入IPD时就提出了“先僵化、再固化、最后优化”的思路。
这种方式的优点是效率高，引进速度快。可能遇到的问题是“水土不服”，因为在企业自身的业务方向、团队能力、对于流程规范的理解等条件都不十分成熟的情况下开始实施，容易产生员工的抵触情绪，可能很难深入地推进。
敏捷项目管理的原则是“可工作的软件是衡量项目成功的主要指标”，可工作的软件是一线团队贡献的，不是管理者，所以在引进敏捷项目管理的时候必须让一线员工参与选择和决策。毫无疑问，员工喜欢更轻量级的敏捷项目管理，那里没有废的文档，没有各种报告，只有每个Sprint交付有用的软件。
敏捷项目管理中并没有项目立项这回事，只有Sprint计划会议一说。所谓立项还是沿袭了传统项目管理的说法，可是对任何员工来说，立项是神圣不可侵犯的，立项的项目一定会有人关注问题是怎么解决的，一定会关注项目结果。特别是对于对变更深恶痛绝的研发人员来说，立项了意味着变更要受到管理了，产品不能再随随便便地更改需求了。
一提到立项，很多做过项目，甚至项目经验丰富的项目经理可能立即会联想到一系列规范的过程，其实并不需要那么负责，作为团队的管理者一定要记住不管做什么，一定是以结果为导向，采用最简单、最直接的方式达到目标。那么简化版本的立项应该怎么完成呢？
首先，先共识立项的目的。由于业务不同，团队执行能力不同，管理者在项目管理上的期望不同，立项的目的也是不一样的。在暴风的研发团队中，立项的目的要回答如下一些问题。第一个问题是为什么要做，一般是研发和测试团队来问产品经理的，敏捷的实施让研发和测试人员更加积极，原来的研发人员已经进入了怪圈，产品需求说一，研发就实现一，需求一有验证的逻辑错误，研发就按错误的逻辑实现出来。立项让研发和测试人员活了，让整个团队的成员都有了质疑精神。团队归纳了要做的三类事情：为用户提供有价值的新功能或服务；为改善和提升用户体验的功能的优化；解决Bug。所以只要Sprint的需求用户故事能落实到这三类，这个问题就可以得到解决。第二个问题其实是项目优先级排序的问题，产品经理罗列的 N 多的用户故事，哪些更重要排在前面，也需要立项的时候回答清楚。项目交付的结果无须解释，但是这个结果要达到什么质量标准是必须在立项前定义清楚的，这里质量标准包括但不限于崩溃率、启动速度、功能的转化率、下载成功率、播放成功率、不可播率等。需求的理解在传统项目管理中需要定义烦琐的需求文档，在初次实施敏捷的暴风研发团队先让产品、研发、测试达成需求的共识是必要的，这样大家可以分头去准备必要的需求文档、设计文档和测试用例。而对于风险好像除了进度风险团队就识别不出其他的风险了。
其次，Sprint计划会应该在立项前面还是立项之后召开呢？抱着尝试的心态，团队选择了立项后开Sprint计划会。选择的理由是，Sprint计划会开完后，到立项的时候如果由于优先级问题，可能会导致原来的计划全部被推翻。“Planning”意思是持续不断地计划，这是对计划最好的描述，不要指望一次会议就把Sprint计划都搞定。所以团队决定多开几次Sprint计划会，在会上再次讨论需求并给出相对靠谱的估算。原本打算按照正常的估算来确定Sprint的长度，但在产品发版周期的强大压力下做了妥协，改为先在Sprint中的用户故事中进行合理的估算，如果在产品规定的Sprint周期长度内实在无法完成，就按用户故事的优先级去掉一些任务。采用什么样的估算方法呢？估算大多数是要靠研发人员的，对于研发人员来说功能点、生产率等统统都不愿意去学习，来点简单实惠的，简化的DELPHI方法更能迎合团队的胃口，这也正是敏捷估算的前提。产品经理在估算中要起到非常重要的作用，不但要将用户故事介绍到大家都能听懂，还要辅助敏捷教练帮助估算人员分析估算偏差的原因。
最后，该定义立项后项目的一些基本规则了。虽然敏捷项目管理倡导“拥抱变化优于遵循计划”，但以国内研发团队的综合能力，尽量少地变更才能保证交付的软件的质量。所以，对于变更的预定是按Sprint周期的，在Sprint的前三分之一时段，可以尽量朝用户体验更好的方向提有用的变更，在三分之一到三分之二时段，团队只接受优化类别的需求变更，在后三分之一时段，拒绝变更。对于开发任务完成的定义，团队采用了“0～100完工进度”下更精确一些来计量任务完工进度的方式，P代表研发任务研发完成，C代表测试通过，T代表产品经理验收通过，这样的完成才是真正意义上的完成。对于每日的敏捷例会，考虑到一些研发人员早晨起不来，团队约定每日早晨10点开始敏捷项目例会，会议时间限定在15分钟。而准备实施敏捷项目管理的团队需要封闭在一个独立的空间里，集体搬到一个会议室进行团队集中。
规矩定完了，而且是以一线团队为主进行的规则定义。为了保证试水的顺利，培训是非常必要的。松下幸之助说：“培训很贵，但不培训更贵。”也有很多观点认为，在所有的知识传授方法中培训是效果最差的。这个观点有一定的道理，那是因为大多数公司的培训都停留在为了培训而培训上，没有照顾到被培训者的基础，没有精心地准备培训，培训的过程中只是干巴巴地讲授而缺乏娱乐等。换另外一个角度来思考，以上定义的一些规则，包括如何立项、如何进行Sprint计划、如何估算、如何管理变更等，如何让一个没实施过敏捷项目管理的团队顺利地执行下去？大多数公司都知道流程的推广要经过流程定义、流程培训、流程试点、流程优化、流程推广，这类似于PDCA戴明链的一系列循环，但在定义环节，很多都没有让员工参与，在培训环节，又有多少做到了认真培训？
针对枯燥的概念和流程，很难唤起技术人员的兴趣，怎么才能收到好的培训效果呢？
首先，避免枯燥，增加很多模拟和演练环节。例如，关于如何立项，不妨拿一个即将开展的项目先模拟一次，让大家先提出各种争议，最终由培训老师引导大家回到敏捷立项需要回答的6个问题上，最后每人发一张小卡片，技术人员不需要记忆这6个问题，但经过反复演练，每个人都应该理解这6个问题从哪些角度来思考，从哪些角度来回答。这种模拟和演练同样也适用于Sprint计划会。
其次，针对一些规则，在培训过程中要讲出规则制定的来龙去脉，同时也收集技术人员关于规则的看法，而不是枯燥地介绍规则，一副理所当然规则就这么定了的样子。例如，关于变更的规则，有的技术人员就提出，前三分之一时段允许产品人员实施变更，那怎么界定是朝用户体验更好的方向了？
提出这种问题就给了培训讨论的话题，让大家共同枚举一些改善用户体验的场景及伪改善的场景。
最后就是怎么评价培训做得好不好。评价分两个方面，老师评价学员学习得好不好，以及学员评价老师讲得怎么样。市面上各种各样的反馈表感觉很千篇一律，所以针对培训的评价团队也做了改进，如下表所示。
如果要寻找试点项目实施一套新的方法和体系，选择什么样的项目最合适呢？创新精神、学习能力和执行力缺一不可。创新是团队不守旧敢于尝试新的方法，敢于试错；学习能力决定了实施过程中团队学习新事物效率高，理解偏差小；执行力决定了这套方法和体系是做到60分的标准还是更高的标准。再通俗一点讲，项目的负责人和他所带的几个骨干对新事物的态度决定了试点项目实施的效果。我们选择了公司公认的重要项目——官网929升级项目，项目的负责人也是在公司研发团队中具有重要影响力的人物，这个团队的骨干们也都接受了敏捷项目管理和公司定义的一些规则的培训，甚至有些规则这些骨干们也参与了制定。
通常产品经理在功能（用户故事）的选择上都是贪婪的，他们恨不得研发团队在一个Sprint上做完所有的功能，很少有人喜欢去做减法，只有在眼看实现目标渺茫的时候才不得不被动舍弃。在这个试点项目中几乎重演了上面的事实。幸好开始实施敏捷项目管理的敏捷立项，按照规则大家开始对选择的用户故事逐个地争论不休，争论的焦点无非是功能的取舍，当很多争论陷入白热化时，产品经理给出的理由无论在哪个公司也许都千篇一律，“这个功能我们竞品有，所以我们也要有”，“这个功能是我们老大要的，我们说的不算”，“用户可能会喜欢这个功能，有用户反馈说要了”。幸好有务实的敏捷教练和受了新思想培训过的研发负责人，他们把问题拉回到项目立项的目标，也让激烈的争论画上了句号。在一个产品导向型的公司，很多产品经理不会定目标，所以经常能听到的目标是按期发版，必须完成某某功能，版本质量稳定。这三个方向都是正确的，可是完成到什么程度算好呢？经常会有些模糊，试点项目除了质量定了崩溃率限制外，其他两个目标在相对模糊的情况下完成了立项。
估算的实施是试点项目引入敏捷后最为搞笑的一件事，没有采用真正的敏捷扑克，但是流程还是严格地按照简化的DELPHI方法实施的。在实施之前做了个小实验，把所有的用户故事拆分后，让大家公认技术最牛的研发负责人先估算了一遍。记住估算结果后，擦掉数据，换成投影让他在同事们面前再次“表演”一次估算。同样的用户故事，同样的估算人员，同样的约束条件，结果出来后大家一致嘲笑这个技术大牛超级不靠谱。因为两次估算的结果对比了一下，有一半多用户故事的估算结果不一样。当真正的估算开始时，先让研发的同事认领了自己喜欢做的任务，然后每个任务选择自己、一位同事及研发负责人共同按照流程执行估算。流程的执行不存在什么问题，可估算了多个任务后会发现研发人员分为三类，一类是喜欢给自己留Buffer的，明明6小时可完成的任务估算一般给自己要8小时，另外一类是激进的，正常需要16小时完成的任务，他喜欢挑战自己压缩到12小时，最后一类是中规中矩的，不冒进，不保守。
敏捷例会的实施和预想大相径庭，三个标准问题，“从上次会议到现在都完成了哪些工作？”“今天准备完成什么？”“工作中遇到了哪些阻碍？”有很多成员的思维没有转变过来，感觉还是向敏捷教练汇报昨天的工作和今天的计划，而没有互动，明明有些成员之间需要调试接口，而接口中遇到的各种问题都没有暴露出来。更很少有人去关心燃尽图和项目Sprint要达到的目标。至于更新展板也成了敏捷教练一个人的工作，大家似乎并不关注展板上任务的总体进展情况。甚至会发现大多数人属于估算中规中矩或者保守者，每日只完成估算内的8小时工作，甚至在整个项目过程中都很少有估算的偏差。
例会迟到也是开始实施时遇到的难题，似乎研发人员非要用散漫来代表自己独特的气质，或来衬托其作为高手的洒脱。实施敏捷项目管理是团队的事情，更应该注重团队协作，所以按照约定的时间开敏捷例会是应该最先达成共识的问题。针对例会不能准时开的问题，研发负责人发挥了他技术领袖的作用，约定开敏捷例会迟到的每人交50元作为项目活动经费，这对约束纪律起了决定性的作用。目的不是为了罚钱，而是约束大家能承诺兑现，虽然还是有迟到现象，有些成员甚至起哄让经常迟到的人学移动资费可以包月。坚持下来确实提高了大家对敏捷例会的重视。
谈到需求变更，几乎所有的研发人员都谈虎色变，那简直是一个让人深陷的泥潭。这个项目也不例外，按照最初的约定变更应该在项目的前三分之二阶段，团队接受了一些产品经理提出的变更，有的是为了最终产品体验更好，有的是在无奈下妥协接受的变更。到了项目快测试结束的时候，产品经理又提出了变更，这次研发人员理直气壮地拒绝了变更，这次拒绝让研发成员前所未有地兴奋，因为终于找到了合理拒绝变更的理由。拒绝归拒绝，产品经理提出的需求变更想法是非常好的，所以团队讨论后决定将这次变更作为新的用户故事放到下个Sprint中去实现。
很多人对“Business Goal”不是十分理解，因为对于绝大多数IT或互联网公司，很多公司都没有清晰地把业务目标描述清楚，很多公司的业务目标都是销售额增长、利润增长这些财务指标，这必然给公司的研发管理者以无从下手的感觉。因为研发团队和这些指标的贡献不具有直接的相关关系，所以很多研发管理者便只关注项目和项目管理。
如果要实施度量，一定要先理解业务目标，并让度量服务于业务目标。例如，暴风的某个业务线的业务目标是在线VV的增长年度翻倍，而支持这个业务目标的方法是提高影视内容的数量和质量，提高内部运营效率，以及一些和新用户导入或老用户留存相关的重点项目的实施及效果。前两项属于运营管理，可以定义一些指标来度量效果，例如百度排行榜Top 50的影片的采购数量、影片内容的更新效率等。而和重点项目相关的度量指标可以是项目的及时合格交付率、升级效率、用户使用率和用户好评度等。再深入一些，对一个具体的项目，如果实施敏捷项目管理，可以从项目的任务按时完成率、燃尽图、缺陷移除率等方面来实施度量。
有些公司会将度量与考核紧密地绑定在一起，这是一种非常不明智的行为。试想如果考核缺陷率，管理团队会看到什么样的缺陷率报告，而由于不敢报告缺陷数据，会产生多少隐藏在深层的Bug。如果考核任务的按时交付率，一定是上有政策，下有对策，直接把估算打个Buffer，按时交付率的图表会做得很漂亮。而对于数据统计可以，系统自动算出的崩溃率、软件的启动速度等性能数据则可作为考核指标。所以概括来说，人为产生的度量数据不要用来考核；系统产生的人为不能轻易干预的数据，可以用来考核。
也不要迷信度量一定要采用工具，首先有经验的研发团队一定不会度量很多指标，其次也不应该每次都度量同样的指标，度量什么和工具也没有必然的因果关系，只要度量的数据指标能和直接的业务有相关性，那么度量就是有意义的。下图给出了软件公司常用的一些度量指标，从中挑选你认为最能和公司业务指标相关的两三项实施吧！
复盘指对局完毕后，复演该盘棋的记录，以检查对局中招法的优劣与得失关键。一般用以自学，或请高手给予指导分析。在软件项目的复盘和总结中，很多公司做得都不得要领，大多数公司由项目经理编写一份项目总结报告提交给相关人员，其实都是为了例行公事，很少有人去看总结文档。下图是试点项目实施敏捷项目管理后的复盘框架。
目标复盘需要回顾当时项目设定的目标是否达到，如果项目的目标设定了卓越和及格两个标准，需要判断项目是及格还是卓越。项目立项时很多指标都可以设定及格和卓越标准，例如，可以设置质量相关的软件稳定性指标，软件的崩溃率在原有比率的基础上降低50%的空间为卓越指标，降低30%为及格指标，也可以设置为产品目标，功能的用户使用率达30%为卓越指标，10%为及格指标等。设置卓越标准的目的是为了激励团队想出更好的方案来达到卓越。这在一个追求卓越的公司和团队中会塑造一种正向的企业文化。
时间轴回顾主要复盘项目中各个检查点是否按时达到，如果有偏差，是当初规划的问题还是执行问题。特别是调研大多数公司的交付团队的高管，问他们最关注什么，八成以上的人都关注软件项目的进度。如果是真正关注进度管理的团队管理者，就更需要按项目的时间轴来认真回顾一下项目的进程。特别是项目目标仅仅及格或者没有达成项目目标的团队，更应该回顾一下规划背后采用的每个核心方法是否正确，根据核心方法分解的每个关键动作执行得到位与否，如果重新来过，是否能更好地完成项目目标。
得与失总结是复盘的关键所在，很多人都不会总结得失，经常将项目结果中做得好的部分作为得，项目中没有做到的部分作为失，这是一种十分偷懒的做法。所以大家看到的很多项目总结报告都会去描述项目的得是项目团队得到了很好锻炼、项目中尝试了某某新方法、项目按期验收等。这些是项目的得吗？或许是，但不是真正的得失总结。真正的得应该总结关键任务的完成及背后付出的努力。例如，项目如果达到了上述的崩溃率在原有比率的基础上降低50%的目标，这是得，因为得的背后有几个主要原因做支撑，原因之一是项目针对收集的崩溃日志做了深入的分析并找出了降低崩溃率的解决方法，原因之二是针对引起崩溃的Bug做了因果分析并且都得到了解决，原因之三是针对潜在的引起崩溃的代码做了代码走查，并且做了相应的代码修改。在这三个核心方法下才导致了我们想要的结果——崩溃率降低。同样失的总结也应该总结关键任务的重大失误和失误背后的原因。
最后一步是形成复盘的结论，这个结论可能是一份报告，也可能是一份复盘过程的纪要，最重要的是希望整个团队在复盘过程中得到学习和成长。
这个试水项目就得出了关于项目敏捷估算的重要结论。估算是每个开发者的必备技能，虽然不能像SEI倡导的PSP（个体软件过程）那样来训练开发人员，但每个人应该针对估算做一个自我总结，根据复盘形成的关于估算偏差原因的总结如下表所示。
