下载掌阅APP，畅读海量书库
立即打开
试水之后，敏捷之火已呈燎原之势。很多项目纷纷采用敏捷的方式进行管理。这也让事先人员储备不足的敏捷教练显得捉襟见肘。大量的培训会、敏捷估算会、敏捷例会、Sprint总结会、燃尽图的准备等占用了敏捷教练太多的时间。而不同水平的敏捷教练带领的敏捷项目则出现了分化。高水平的敏捷教练会注重敏捷规划和敏捷例会的质量，及时解决障碍和对一些规则的把握让项目结果能达到卓越的目标，而水平低的教练带领的完全是一种伪敏捷，那里会有强力的变更控制、流于形式的敏捷例会、松散的协作等让项目往往连达到及格都困难。这样整个公司不得不再次进行组织级的探索。
敏捷例会的展示板每个团队都会实施得不一样，下面的两幅图展示了不同的实施方式，左边的图来自《硝烟中的Scrum和XP》，右边的图来自暴风的敏捷团队。相比之下，一个更突出燃尽图，另一个更突出项目的阻碍。对于进度跟踪，可以采用观察燃尽图的趋势，也可以融合信息系统的做法。
只要不苛刻地挑剔，很多工具都支持Scrum敏捷项目管理，从最简单的白板加Excel，到ScrumWiki、Xplanner、GNATS都能支持Scrum的实施。暴风的团队开始就尝试了Redmine这个缺陷管理工具来配合展示板实施敏捷项目管理。没有好不好用的系统，只要运用合理，抱着极简的思维去使用工具，就能最低成本地发挥工具的作用，至于使用信息系统遇到的各种缺陷或者不能满足管理的功能，还是应该报以宽容的态度。但理想和现实往往经常事与愿违，将就用了一段时间后团队终于不能忍受系统功能的不足，于是开发自己的信息系统的呼声愈演愈烈，最终还是决定开发自己的系统。
还是本着极简的思维方式，系统只围绕包括Sprint任务导入、任务完成更新（工时填报）、燃尽图自动生成、问题的生命周期管理这样几个核心功能进行开发。这样也使得任务板和信息系统的信息完全一致，障碍（问题）也得到了有效的跟踪和管理。
对于暴风影音的官网版本来说，每个月会有多个官网版本发布，一种是提供给用户新特性验证的β版本，根据用户体验后真实的反馈信息，进行后续产品的优化和完善，另外一种是将已经完成验证的功能和新特性合并到稳定的官网版本中。基本每两周就要交付一个版本，每个项目都感觉时间紧、任务重。配置管理在敏捷实践中起到怎样的作用呢？
暴风转码的敏捷团队在版本V2.1刚刚完成用户故事的开发工作，也就是说，产品已经能运行，系统测试工作还未开展。按照估计测试和修改Bug的周期为一周计算，此一周的时间研发人员会很不饱和，按照公司对人员使用率的要求，通常会启动V2.2版本的开发工作。这样会提高研发人员的利用率，但也会带来两个甚至多个版本同时开发的问题，如果没有好的配置管理，代码会混乱不堪，很多人同时并行两个版本的代码开发工作，一方面改V2.1版本的Bug，另一方面开发V2.2版本的新功能。我们通过配置管理工具的代码分支、代码合并来解决代码管理问题。为V2.1开出代码分支，这样两个版本的代码相互隔离，不会彼此干扰。V2.1版本上的Bug修复工作，对于V2.2的开发同样也适用。这样实现了版本的交替开发，提升了开发人员的使用率。通过代码的分支与合并也能处理好“新特性开发”与“产品稳定”的关系。两种版本经常存在交叠。用分支支持交叠，即防止了前者干扰后者，也防止了后者阻滞前者，这样维持了开发效率和产品质量的平衡关系。
在敏捷开发过程中，变更是被鼓励的。而变更一定会体现在代码中，因此在SVN里，加一些控制以保证开发人员做且只做该做的事。方法是让变更集不由开发人员创建，而是由专门的配置管理员创建，然后指定给相应的开发人员完成。配置管理员会和产品经理、开发负责人和测试负责人沟通达成一致，然后在SVN中完成相应的设置。对于一些比较大的任务，需要多个人协同完成，可以为此开分支，分支也由配置管理人员创建，然后要求开发人员在分支上工作，完成相应任务，同时控制修改代码之后的提交。对于分支版本，只有符合本次版本要求的分支才允许合并到主干。这个工作是配置管理员和敏捷团队协作完成的。配置管理实践中最重要的是要摒弃原来所有的控制思想，让配置管理员作为敏捷项目团队中的一员，和团队共同协商如何管理代码、管理变更，而不像实施CMMI过程中有各种控制和审批环节。
技术评审活动是不管是否实施敏捷项目管理都需要进行的一种活动，很多人从来没有搞清楚什么是技术评审、什么是管理评审。技术评审包括需求评审、设计评审、代码Review、测试用例评审等和项目直接结果相关的工程活动的评审。管理评审指的是敏捷项目管理的三个仪式：Sprint规划会、每日例会和Sprint评审会。传统项目管理中的项目立项评审、里程碑评审和验收评审也属于管理评审。简单地总结，技术评审是针对软件工程活动的评审，其目的是通过缺陷预防提升软件的质量，管理评审是针对阶段活动是否可认定为结束、下阶段如何开始，其目的是项目管理活动是否有效，交付的成果是否可接受。
如果借助敏捷项目管理的思想“交付可用的软件”，技术评审在敏捷活动中显得尤为重要，从评审的正式程度上划分，技术评审分为正式评审、技术审查和代码走查三种类型，如下表所示。
正式评审通常由项目经理主持，邀请项目的核心成员和外部有经验的专家参加，目的在于定位并消除软件中的缺陷。技术审查或称内部评审，通常由技术负责人召集相关人员参加，一般是在模块或功能完成时进行，目的在于通过对交付模块或功能的技术审查，提出改进意见。代码走查又称代码走读，由代码作者来组织，主要是代码质量分析和编程规则检查。一般是在模块或功能完成的早期进行，作者有一定的想法时，希望从其他开发者那里获得一些帮助或补充。由作者主持，目的是进行缺陷预防，提高代码的质量，很多公司已经成功地实施了Code Review和结对编程。
总结第一轮实施敏捷的试点项目，并没有要求实施代码走查活动，项目负责人和开发人员也没有意识进行Code Review。要么是找借口说进度太紧张时间不够用，要么是不知道如何进行代码走查。第一种纯粹是意识问题，要回答不知道怎么进行代码走查的问题则从代码走查的种类开始着手。代码走查分为两种：一种是交叉代码审查，自己的代码由他人来检查，就像检查作业一样；另一种是代码会审，就是以会议的形式，大家共同审核代码的质量。代码走查主要审查的内容包括：是否符合代码规范，确保所有人写的代码基本一致并符合代码规范；代码满足基本用户故事的要求，检查代码的逻辑实现，确认能实现用户故事；代码满足性能等非功能性需求，非功能性需求一般需要借助一定的工具和Code Review人员的能力，针对编码中对于性能影响的瓶颈给出解决方案；代码简化，提高代码的可读性，能够用公用的方法和公用API实现，则无须每人定义自己的实现代码。
随便抽出某开发人员的1000行代码检查的结果是：代码注释不充分，很多实现逻辑的类和方法没有注释；有些代码性能差，频繁地读/写磁盘I/O；有些代码虽然实现了功能需求，但从逻辑上写得太死，不便于扩展；在约定使用统一代码的写日志功能代码作者定义了自己的代码来实现。看来为了提高质量，代码走查是实施敏捷项目管理一定要执行的工作。
测试报告是集成测试阶段每天都需要测试工程师编写的一份重要的信息沟通工具，它的目的是让团队所有成员了解当前Sprint交付软件的质量情况，每个开发人员身上有多少未解决的Bug，以及交付模块的质量情况。回顾试点项目的项目测试报告，大概是从百度上搜索的模板，冗长而不知所云。报告中什么编写目的、背景、测试对象、测试概要、测试用例、测试环境等，光标题就会让人眼花缭乱。从正规性上讲，这样的测试报告提交给最终用户无可厚非，但是给团队内部看就没必要这样讲求全面性和规范性了。再引用敏捷思想“可用的软件重于完备的文档”。所以修订测试报告应该是为团队减轻负担、提高沟通效率的一项优先级非常高的优化活动。
问问团队需要什么样的报告。产品团队回答需要了解当前软件的质量来决策是否可发版，以及有些不好解决的缺陷拿出来让团队共同来决策Bug的处理策略。研发团队回答需要了解每个人身上有多少个未解决的缺陷，Bug整体解决情况和各模块的质量。测试团队关注的是Bug整体解决情况及分解下的按模块、按人员缺陷情况。统一思想后的测试报告包括一个测试情况的基本总结和三个部分。
基本情况总结是整个测试报告中最重要的部分，应该用粗体和红色来描述。要求尽量用一两句话描述清楚当前测试的总体情况。例如， 当前测试遇到未解决的严重级别缺陷大于3个，不符合发版需求，其中组件下载功能如果点击取消，必崩。 第一部分是Bug移除率的统计，其中累计移除率是了解当前Bug整体解决情况的最好的说明，如下表所示为2010年9月23日某项目测试统计数据。
成功实施敏捷项目管理的团队一定有疑问，为什么实施敏捷后还有集成测试阶段，看上面的数据为什么质量会那么差，似乎和敏捷倡导的交付可用的软件有冲突。带着这些“十万个为什么”不妨思考一下。
没有实施代码走查导致了大量缺陷，造成的直接结果是必须有个集中测试的阶段来把Bug找出来，每个功能和功能之间并不是独立的，开发人员在开发过程中并没有及时沟通导致了接口不一致等诸多Bug，产品人员没有及时确认交付的功能或模块是否可用甚至提出一些变更也导致了一些缺陷。如此多的原因导致这么多缺陷已经解释了上面的为什么，结论是如果敏捷项目管理实施成这样，基本上可以界定为是一场“形似而神不似”的失败的敏捷尝试了。但也可以肯定的是，这份测试数据总结对团队了解项目当前的总体质量起到了一目了然的作用。
第二部分为Bug人员分布，第三部分为Bug模块分布，分别是按人员和按功能模块的缺陷数据总结。按人员的分布可以看出每个人当日解决的Bug数和剩余Bug数，便于提醒团队及时地解决Bug或者相互协助。按模块的Bug数总结便于提醒团队哪个模块的Bug多，除了了解模块的质量外还有助于提示团队及时进行代码走查来彻底解决质量问题。
经过再一轮的组织级探索，让团队对于敏捷项目管理的基本原则有了更深入的认识。软件开发的残酷现实告诉我们，即使在敏捷项目管理框架下，没有规则的软件开发过程带来的只可能是无法预料的结果。不管是多么有经验的项目团队，在“响应变化胜于遵循计划”一项上都难以做到。一次次失败的教训告诉我们，我们需要在敏捷框架下设定一些基本规则，而在这些基本规则面前，在保证敏捷思想的前提下不能向规则让步。
软件可用规则：上述的代码走查和测试数据告诉我们，在很多情况下我们交付的用户故事可用实际上是带有很多缺陷的，即使强调了PCT原则，团队交付的功能模块还是不完全可用，所以严格的方法是在燃尽图统计时，所有未完成的（即使是P和C状态都完成了的功能）都不进行统计，这和传统的“0-100”进度统计法则一致。让任何一个团队成员都知道积极参与，因为每一个功能交付如果说可用就一定要可用。
目标导向原则：目标导向是充分调动员工工作积极性的最有效的方法，每个目标都设定卓越和及格的标准，在制订敏捷计划时，就需要明确项目如何做到卓越，并让指标认领到个人。例如，手机端每个滑屏操作的卓越标准是任意滑动的展现在0.6秒以下全部完成。对于开发者来说，近期的Sprint目标总是比远期目标来说更容易看到和达到，这会使每一个Sprint员工的工作效率维持在一个较高的水平。
代码提交原则：很多开发人员在提交代码到配置管理系统时往往不注意是否通过了单元测试和自己代码的质量，这样会给其他人员带来或多或少的麻烦。所以为了提升团队效率，代码的提交必须满足两个硬条件，其一是提交的代码必须经过自己的单元测试，其二是确保提交代码后整体代码可编译通过。在这个原则的基础上，如果能自动化完成的工作绝对要减少人工干预，例如，持续集成和自动化测试尽量按策略自动完成。
有话好好说原则：项目成员理解和赞同用户故事的范围、项目目标吗？开发人员大多数时间都不喜欢发表自己的看法和言论，大家不发表言论意味着他们认同项目范围和目标吗？这一点在项目沟通中极为重要，敏捷教练一定要问每个人，让每个人表达自己的观点，让大家有话好好说，有话桌面上说，不可认为不发言就认为是同意。在对项目目标没有一个共同认识的前提下，团队是不可能成功的。
文档极简原则：敏捷思想并不鼓励书写文档。敏捷宣言也宣告“可用的软件重于完备的文档”，但如果一个软件是长期更新和维护的，还是需要必要的文档来将所有有价值的历史信息记录下来的。你如果刚加入一个敏捷团队来接手一个已经迭代了9个Sprint的软件，如果什么都没有你从哪里下手？但是不希望文档过于庞大，能把用户故事的关键点、设计的关键点记录下来就够了，特别是代码每次变更必须用注释描述清楚。
精英团队原则：众所周知国内软件的成熟度偏低，一个公司能数出几个好的产品经理？又有多少技术高手？其实资源很有限。如果实施敏捷项目管理，必须抱着精英团队的原则，不鼓励团队规模过大。团队规模过大，按照 n ( n -1)/2的沟通渠道计算公式，沟通成本增加，效率极大降低。特别是很多需要技术难点公关比较多的项目，人数多根本解决不了任何问题。
总之，在不违背敏捷思想的前提下，一些必要的规则是保证项目目标能够达到卓越的必要约束，也是促进团队建设和高效协作的基础。