Test@Office: 每周测试会议

Office PARC负责Word和相关产品的开发。PARC测试团队大约有40~50人，有5个测试领导（Test Lead）和1个测试经理（Test Manager）。测试经理汇报给负责Word和OneNote的副总裁（Vice President），副总裁汇报给向微软商业部门（Microsoft Business Division）的总裁（President）Kurt DelBene，而Kurt汇报给首席执行官Steve Ballmer。

这是一个相对扁平的组织结构。Kurt 领导的团队非常庞大，他们的产品包括Microsoft Office（Word, Excel, PowerPoint, OneNote, Outlook, Access, Publisher, Project, InfoPath, Visio等)，Mac Office, Office Web App，SharePoint, Exchange, Lync (服务器和客户端），Office 365等。测试经理只越过一级就可以向总裁Kurt汇报，这有利于传达研发团队的意见。

测试经理的名叫Mike，是一位非常资深的管理者（其职位是Partner Test Manager）。他亲自主持每周测试会议（Weekly Test Meeting），向PARC测试团队沟通当前进度和本周重点。

周会是一项被广泛采纳的开发实践。Office PARC的测试周会有什么特点呢？以下是我连续两周观察到的内容。

第一周

会场

在周一10点，Office PARC的测试员工进入会场。在我看来，以下几点值得记录。

1. 会场的桌子被摆成U型。某个员工发言时，其他人都可以看到他的表情。
2. 测试经理Mike站在会场中间主持讨论。如果有讨论，他可以随时走到发言者身旁，近距离地交流。
3. 投影仪投射出PowerPoint文档，其内容是本次会议的议题。会后，该文档被保存在内部站点上。
4. 只有少数员工携带笔记本电脑参加会议。在中国微软，几乎所有人都携带笔记本电脑参加会议。
5. 大多数员工携带纸质笔记本参加会议，但是频繁记录者不多。

上周趣事

会议的第一项议题是上周趣事。Mike问：关于上周，大家有什么好玩的事情可以分享？于是，一些员工分享了他们在工作内外的遭遇，并引发阵阵笑声。以我观察，发言者以性格外向或资历较老的员工居多。像我这样初来咋到、性格内向的员工发言的可能性较低。但是，“无关的趣事”使得会场气氛变得轻松，让我觉得这不是一个压抑的“工作会议”。

杂项

会议的第二项议题是Misc（杂项）。议题大多是团队内务，包括欢迎新员工、年中职业讨论（Middle Year Career Discussion）、微软年度反馈（Microsoft Poll）等。

例行议题

在轻松的内容之后，是一系列固定的议题，包括：项目进度、测试自动化情况、Bug情况、本周重点任务等。在我看来，以下几点值得参考。

1. 每一个议题都有固定的负责人（Driver）。他（她）可能是测试领导，也可能是资深员工。他驱动PARC测试团队的一项具体工作，如测试自动化、Service Pack测试、Bug修复等。这使得PARC的测试实践拥有统一的风格，且促进了测试人员之间的交流。
2. 负责人往往会用带标记的表格或各种图形，来传达当前情况。明幻灯片综合了多个负责人提供的数据。
3. 对于里程碑的开发进度，其度量单位是已经完成的功能（Feature）数，而不是已经使用的开发时间。
4. 对于测试进展，其度量指标包括测试工程师的Bug数量和自动化测试通过率。
5. 依据Office的开发计划和当前进展，负责人给出本周的工作内容和重点。在会后，他们还会发送邮件，给出更详细的说明和指导。

插曲

除了例行议题，本周的会议还有两个“插曲”。

第一个插曲是演示一项刚刚开发完毕的新功能。两位测试工程师一边演示，一边回答观众的提问。当时，我的第一反应是，这与Scrum的“Sprint演示”异曲同工。Scrum以2~4周的Sprint为开发单位。每个Sprint结束后，开发团队都要向利益相关人（stakeholder）演示Sprint的成果。这有助于开发团队专注于用户价值、获得可度量的进展、增强团队信心、获得必要反馈。

Office采用的是螺旋开发模型，产品开发由几个里程碑（Milestone）组成。在每个里程碑，程序经理、开发工程师和测试工程师会组成功能小组（Feature Crew），完整的实现并测试一批端到端（end-to-end）的功能。每周例会提供了一个产品演示的固定舞台，使得功能小组能够尽快展示他们的成果，从而获得与Sprint演示相似的收益。

第二个插曲是介绍本周的一个测试活动：Test Focus Day，活动内容是用半天时间，让测试工程师一起测试多人协同编辑。活动组织者是协同编辑的测试工程师，她介绍了活动规则：测试工程师被分成若干个团队，每个团队各自编辑一份文档。在此过程中，工程师要尽力寻找bug，并使得整份文档美观、有趣。测试结束后，Mike作为评审，会选出最佳文档和最佳Bug。

介绍完规则，Mike接过话题。他首先感谢了组织者的工作，然后动员大家发动奇思妙想去编辑美妙的文档。他说了一句令我印象深刻的话：

We always find beautiful bugs in writing beautiful documents of the real world.

第二周

在第二周，PARC测试团队照例举行周会。会议内容是上周趣事、杂项和例行议题。除了上文所提到的内容，还有两点值得记录。

Dogfood

Mike指着投射出的幻灯片说：“这是我用Dogfood Build制作的幻灯片。在过去一周，我一直使用Dogfood Build。”

Dogfood来自于俗语“吃自己的狗食”（Eating your own dogfood），意思是开发团队使用自己正在开发的产品。这是一项有许多收益的活动。

1. 开发者作为用户获得对产品的第一手反馈。这加速了产品的持续改进。
2. Dogfood要求正在开发的产品有较好的质量，不会妨碍日常的使用。这自然要求开发团队能够持续提供质量稳定的构建（Build）。Office vNext尚在开发的早期，就可以应用在日常工作中。这说明Office在每日构建和持续集成上的投入，收到了好的效果。
3. Dogfood有助于推进一些功能的完善。例如Dogfood Build崩溃，Mike不会绝望。因为Office的自动恢复（AutoRecovery）可以挽回大部分修改。不把自动恢复做好，员工很难正真使用Dogfood Build。
4. 在Dogfood过程中，不同职位、不同背景、不同习惯的员工会用不同的方式使用系统。在一个大的团队内实施Dogfood，很可能覆盖独立测试工程师不能覆盖的场景。

Mike的举动鼓励了我：连测试经理都安装并使用Dogfood Build，我也要加入这项活动！于是，我也在自己的机器上安装了Dogfood Build，并每天用它处理邮件和编写文档。从这件事上，我体会到：有效的管理，有时不需要指令或劝说。作为领导，Mike的榜样作用不可低估。

最佳文档和最佳Bug

在“杂项”议题中，Mike拿出2页A4纸，上面写满了他的笔记（系手写，非打印）。他利用周末的时间，仔细阅读了Test Focus Day所产生的所有文档，并记录了每一篇文档的特色。基于笔记，他逐一点评了每篇文档，感谢撰写该文档的团队，并提点出他所喜欢的Bug。

在点评我所在团队的文档时，Mike特别摘录出一句他觉得很搞怪的话。其实，这句话是我写的，是我在文档中放的一个玩笑。这件小事说明Mike仔细地阅读了文档中的每一句话，并做足了功课。

我认为，所谓“正真”的领导重视，就是领导亲自做他声称重要的事情。Mike的言行表明，他非常重视团队协作、Test Focus Day和有价值的Bug。他在最后公布了最佳Bug的获得者和获奖理由，大家将掌声送给获奖的同事。

小结

1. 周会有助于提供稳定的开发节奏。Kent Beck在《极限编程解析（第二版）》中提出了多项实践。在这些实践中，他建议从“周计划”开始敏捷之旅。PARC测试团队的周会沟通了当前情况，并制定了本周计划。
2. 有效的周会需要仔细的准备。PARC测试周会汇聚了多个信息源的数据，绘制了图表，并以此形成行动计划。
3. 好的会议要有好的主持人。Mike的丰富经验和个人魅力提升了会议的效果。