冯国馨，网名“谷雨霖”。天津大学工学博士、PMP 联合永道高级副总裁兼CTO
　　PMBar IT项目管理实践公益社区创始人、天津大学北京校友会秘书长
　　曾任神州数码网络研发中心副总经理、质量管理部总经理，现任联合永道高级副总裁兼CTO、联合创始人。美国项目管理学会协会PMI会员、中国国家外专局资深专家、中国系统与软件过程改进协会主任专家会员、中国计算机学会软件工程师工作委员会专家组成员、国家应用软件产品质量监督检验中心特聘专家。长期从事项目管理、产品研发、持续改进与团队管理，对教育信息化建设有一定见解。创办IT项目管理实践公益社区，长期积极活跃在CSPI、CSDNCTO俱乐部、IT168等IT管理社区，与用友集团、阿里巴巴集团、盛拓传媒、搜狐集团、安博教育集团、神州数码集团等多家IT单位多次开展沙龙交流活动。
 
　　王立杰，敏捷爱好者、实践者，独立培训师，专注Scrum与XP。2006年开始探索敏捷，应用敏捷，于2009年与许舟平合作出版国内第一本小说体敏捷项目管理图书《敏捷无敌》；2010年进入敏捷咨询培训领域，为诺基亚、北电、爱立信、VMWare、阿尔卡特-朗讯等多家公司提供服务，曾在AgileChina、ScrumGathering、AgileTour等行业会议发表多次主题演讲。

　　《敏捷开发一千零一夜》以多位作者的亲身经历，再现真实的敏捷实施过程，描述各个企业在实施敏捷的过程中，遇到的种种问题、解决的思路及最终得到的经验与教训。这本案例集从不同的视角，为读者展示从大型互联网企业到初创公司、从大型国企到独资外企、从典型的甲方到第三方咨询公司的敏捷历程。这里面既有大的组织的敏捷转型，也有一个小团队或个人的敏捷历程，还涵盖某个敏捷实践或工具的应用描述。
　　本书的特色在于由真实实践提炼，对正在实施敏捷的读者具有很高的参考价值。

　　敏捷是一种方法，更是一种组织能力。那些不懂得敏捷不利用敏捷方法的研发团队，最终将在快速变化、竞争激烈的互联网环境中落败。拥抱敏捷吧，从现在开始！

　　——京东商城高级副总裁 李大学

　　1．展示板和信息系统的巧妙结合
　　敏捷例会的展示板每个团队都会实施得不一样。对于进度跟踪，可以采用观察燃尽图的趋势，也可以融合信息系统的做法。
　　只要不苛刻地挑剔，很多工具都支持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日某项目测试统计数据。
　　……