本系列会专门从团队管理的角度，一方面将曾经提到过的内容加以贯穿，另一方面则会提及之外的一些未提及的内容，比如产品团队与开发团队的互动，测试团队与开发团队的关系与工作方式，等等，以供专门从事团队管理的读者借鉴。
出发点：结果导向
敏捷开发团队的外在行为是“结果导向”，而内在支撑则是“团队工作”（TeamWork）。
所谓结果导向，就是直指结果，而不拘泥于形式。
可以被拘泥的“形式”各式各样，比如方式、方法、流程、文档、部门、分工、职责……都是形式。这些形式本来是设立来帮助实现更好的结果的，但是如果拘泥于此，则可能起到反作用。
如果仔细审视敏捷宣言中右侧的内容，就会发现他们都属于形式，而非结果：
个体与交互 重于 过程和工具
可用的软件 重于 完备的文档
客户协作 重于 合同谈判
响应变化 重于 遵循计划
这些形式曾经保证了众多早期军工、航天、航空项目的成功，但若在任何行业任何项目——比如敏捷开发出现时的互联网行业——拘泥于此，就可能导致失败。
可怕的是，左侧的4条，也是形式而非结果。所以对敏捷宣言的正确理解是：在现今的多数行业中，如果以结果导向为出发点，则左侧的形式胜过右侧的形式。
支撑点：团队工作
为什么说团队工作利于结果导向的实现？
有一个兄弟射雁的例子可以说明：三个兄弟看着大雁飞过，一个说要射下来烤着吃，一个说要炖着吃，另外一个则要炒着吃，三人争执不下，大雁都飞走了。
比如有一个Bug，人们不去分析怎样改正怎样预防，而是讨论是谁的责任；比如有一个任务，人们不去分析怎样做最快，而是讨论应该谁做；比如有一个变更，人们不去分析变更前后甲乙方是否有利，而是讨论应该哪些部门走怎样的流程；比如有一个产品，人们不去分析怎样做才能成功，而是讨论成功后应该怎样考核……就很难直指结果，而陷入部门和个人的纷争之中。
这里倒不是说后者不需要考虑，而是说出发点问题。如果思考问题的第一念头是“我”“我们”“他”“他们”，那么团队协作就建立不起来，敏捷开发也做不好。
本系列的内容
本系列将涉及几种常见团队的关系问题：产品团队与开发团队，设计团队与编码团队，编码团队与测试团队……以及团队内部的工作方式。
其间会引用几个以往见过的以及现在身在其中的团队的做法，并分析其应用的环境、潜在的风险。
几个真实案例
这几个团队都是我自己亲身经历的团队，从质量的角度来分析敏捷团队的工作方式。
第一个是一个较为大型的团队，约有25～30人，研发一个单一产品。
这个团队在一年半的时间里边，从5个人成长为25人，其中有一半人员来自刚毕业不到半年的本科或硕士（在2001年，还很难找到“有10年经验的编程人员”）；在这个团队拥有25名成员的时候，只有1～2个测试人员。
按一般的常理而言，这个产品应该面临很大的质量问题，因为这些新来者应该编写大量的缺陷，而测试人员又严重不足，不足以发现这些缺陷。
但实际情况是，这个产品是我后来经历的所有大型团队中最好的一个，包括后来拥有众多测试人员的团队；此产品运行于CCTV，属于高度实时性和可靠性的产品；此产品在上市7年左右的时候占有市场的60%份额（之后数据不详）……
第二团队个可以说是个团队，也可以说是个个人，是我之后为某家军工企业开发的一个小软件。
“无损检测系统”项目历时3.5个月，涉及步进电机、超声波扫描卡等各种软硬件，尽管就这么多人工，最后甲方说做了个“国内领先的无损检测系统”（只能说可见国内行业底子之差）。
一个人开发，当然只能自己开发自己测试，但是质量却是有史以来最好的，整个项目的测试期只有几天，而交付后一年中客户没有发现过缺陷，只在更换硬件平台后发现一个水土不服的时序问题。
这两个软件，是我自己亲自或近距离参与的项目中质量最好的两个，但奇怪的是他们都没有专业测试人员。
编程人员的降低缺陷的方法
这里先不分析编程人员与测试人员的分工、合作问题，先看看编程人员除了被“测试”之外，自己有哪些方法可以提高质量。
第一个项目的经验
在第一个团队中，由于团队很年轻扩张又很快，所以推行了代码审查的方法，简单而言，就是高手/老手要看新手的代码，后期的制度则是每个人的代码必须有人看过之后，才能提交。在这些提交过程中，很多可能带来日后维护困难或缺陷的代码都被踢了回去。
在这个团队扩张的后期，这种审查制度被凝结在师徒制度中，以把原来“帮忙”做审查变成“审查义务”。这一变化的原因是中间曾经发生过一次“不负责任”的审查，造成一大段两个月的代码未经充分审查就进入代码库，酿成后来的一次现场故障。这种“不负责任”来自于本来就没有设定责任，只是帮忙，所以才发生了组织结构的变化。
在建立师徒制度后，师傅们将对小组的成败包括质量负责。实际上，新人的流动率很高，如果留下垃圾代码，还是要师傅来维护，所以师傅“被迫”很尽责。师傅们普遍的做法是不只在最后才审查代码——因为那时候肯定面临一个烂摊子——而是在前期就指导徒弟编出良好的代码，乃至在更早的时间点介入，做出良好的设计。
这些制度后来演化成松结对编程方法。
第二个项目的经验
第二个项目则是本人做度量最仔细的一个项目。
原因是在离开上一家公司后，我去了一个测试人员众多的企业，但其产品质量却奇差无比，甚至导致后来一个产品被放弃，40人因此离职。所以萌生了一个念头，就是仔细度量一下缺陷是怎么来的，又是怎样被发现的。
针对这个项目有一个100多个检查项的代码检查表，每天对代码进行30～60分钟的代码检查。在整个项目过程中一共有240多个缺陷，不过只有6个发现于系统测试期，9个发现于与硬件的集成测试，63个来自于调试（就是完成编译到按下F5调试成功中发现的问题，一般大家都是不记录的，但这个项目中也被记录下来），剩下的有112+53个来自于“看代码”（有自查和后查两种形式），这个项目没有单元测试活动。
大致结论是只有微乎其微的缺陷是由测试活动发现的，而剩下的缺陷则是由开发活动发现的。
这个项目的数据还揭示出一些有价值的信息：
1. 开发人员可以有效地降低总缺陷率
在为期27天的编码期（这个项目是瀑布式开发）中，千行代码的总缺陷率趋势从第一天的130/千行降低到最后一天的60/千行，说明若开发人员能潜心消除缺陷，那么在很短的时间里就能大幅降低自己代码的总缺陷率；极少有测试活动能做到类似的效果。
2. “所有缺陷无需测试活动即可消除”
下面是当时的“过程效益”分析，所谓过程效益，就是某个过程对消除缺陷的能力。比如如果说“调试”的过程效益是40%，就是说如果有100个缺陷到达调试环节，调试中会发现其中40个，而60个会被漏到后面去。图中的蓝线就是“调试”的过程效益，注意前期的调试缺陷经常很低，表明“调试起来一切正常，但是一测试就发现很多问题”；后期的调试效益经常是100%，这个意思是说在完成调试（就是F5）后，之后再也没有任何人、任何活动从这天编写的代码中发现任何缺陷。
确切说系统测试的6个缺陷，全部发现于前13天的代码中；换一种说法：如果全程都能像后13天一样编写代码，系统测试的缺陷将为0。
“所有缺陷无需测试活动即可消除”这句话被打上引号，是因为它是一种很理想的状态。但是与“所有缺陷可以被某种测试活动消除”相比，我更相信前者。
3. 编程人员可以训练出行之有效的排除缺陷的手段
“自查”的过程效益始终没有达到100%，但是它与调试的作用越来越互补。比如在初期自查+调试后，还有大量缺陷被发现（所以调试的效益很低）；但如果每天仔细分析自己自查发现的缺陷和调试发现的缺陷，就可能在短短一个半月的时间内大幅度提升自身发现缺陷的能力，乃至于到达不把缺陷留给测试环节，更不会留给客户的程度。
从上面图中的数据可以看出来，这个项目的质量不是由一个“能力很强的人”保证的，因为刚开始调试后还是有很多缺陷会留给测试活动发现，只是后来的训练导致了能力的增强。因此人的因素有，但是不是绝对的。
总结
这些项目揭示出来的规律是：程序员应该负责产品质量，他们有能力，也有时间。
第一个项目并没有因为“程序员还要负责质量”而耽误进度或造成功能“太少”影响到市场竞争力；第二个项目甲方后来坦然说“原定计划一年，没想到三个半月就结束了”（此前他们自己曾经尝试2个人研发过一年，此外也了解另外两家竞争对手投入的情况）。
很多人一定认为上述经验有很大的局限性，比如对个人能力的要求很高，其实不然。第一个项目中，那些刚毕业的本科生和研究生与今天动辄工作5、6年乃至10年的程序员的水平不可同日而语；第二个项目中我本人当时工作经验也只有8年，其中做职业程序员的时间则只有4～5年左右，编码量仅在2万行左右。
所以关键还是方法，而不是人；或者说是“使用正确方法的人”就足够了，“使用正确方法的正确的人”不是一个强制条件。
在后续的章节中，会谈到如何在一般情况下，推行这些方法。
此外还会提到，在这种方法大行其道的时候，专业的测试团队是否还有必要存在，以及还有“什么用”，以及应该如何工作。
测试团队的价值
这样看来，敏捷开发的质量保证问题，都被发开团队解决了，测试团队的价值何在？
这个可以从第一个项目组后来的发展来分析。
在整个程序团队大力保证产品质量的同时，项目组也一点点显露出一些问题。
比如每个模块的质量都还不错（有些模块甚至有一些原始的自动单元测试脚本，每次都能对模块进行回归测试），但是整个产品最终集成后，是否能如期完成业务要求，却是未知的。因为各个模块的测试都集中在各模块的质量上，对于所有模块凑在一起的工作结果，却无法验证。而且在原来的团队体系下，师徒团队各自负责一个模块，居然没有人为此负责。
所以我们很需要一个人来团队里边，把整体集成及集成后的测试抓起来。这种工作，与其说是传统的面向质量的测试工作，不如说是一种面向验证的测试工作。就是只要能告诉我们集成在一起是可以工作的，目的就达到了。
测试团队的“发展”
这里边有很多戏剧性的过程。
首先过了一段时间，测试经理（虽然测试组当时只有2个人）想招几个人，原因是要写很多介于代码和脚本之间的语言，来仿真业务。
为什么说是仿真？原因是我们的产品之外，还有一个“订户管理系统”，这个系统的数据，是我们的业务。但由于他们部门的产品也在开发中，所以我们不得不先手工形成一些仿真业务。
这个问题，后来被开发组的人解决了。因为他们编写了一个文本的脚本语言，只需要手工写一些人眼很容易看懂的英文缩写和数字，就能仿真一些业务。
这个脚本语言及其编辑、调试器后来越做越复杂（但因为开发它的开发人员对内部业务很熟悉，所以只花费了前后2周左右的时间），能够自动运行、单步运行、设置断点调试。
有一次，两个测试人员在2天里用脚本编辑器编写了144个测试用例，每个测试用例包含5～128个购买和分组行为，来仿真和测试他们认为可能的各种排列组合。这些测试用例不是我们常常遇到的写在Word或Excel里边的那种，而是用那个脚本编辑器打开，按F5，就会自动执行并吐出结果的那种。
这个工作如果由人力来完成，无论是编写测试用例，还是执行以查看结果，都是几乎不可想象的。
两个测试人员有一次希望大干一番，以便验证一些不是有意构建的用例是否可以通过测试。但最终结果是，这个编辑器和调试器后来被发展成能自动生成测试用例，乃至将用例发给真实机顶盒+IC卡系统和一个仿真的机顶盒+IC卡系统（一个友好的可以F5调试的VC++系统），如果发现区别则自动记录，并继续产生下一个用例。
这段代码因为走的时候没有留下文档而失传了，不过在7年后的一次老同事聚会中了解到，团队在后续的几年中按照这个原理，把很多不同层次的硬件（数字电视里边的，大约有10种之多，个个都是黑底绿字乃至干脆没有屏幕的，非常难缠）都做了纯软件仿真，每个模块做好了，都可以扔进去和仿真硬件集成一番，这些工作大大缩减了最后真枪实弹时候经常出现的莫名其妙的问题，大大缩减了集成和测试时间。
这些程序人员的工作成果，保证了在团队有25人的时候（峰值曾经到达30人），只要两个测试人员就能完成整个系统的功能测试，这个团队发展十分“缓慢”；但是从另外一个角度看，那些为测试团队编写测试代码的人，到底算是开发人员还是测试人员呢？
启示
一个优秀的团队，应该受到关注的应该是质量的高低问题、集成的效率问题、功能验证的效率问题……这些有人买单的问题，而不是开发与测试的分工、如何明确责任、如何对双方进行绩效考核等没人买单的问题。
所以尽管2001年那个时候敏捷开发的概念还不太清晰，但是本着“无我无人”的精神（详见般若敏捷系列之四），很自然地创立了自己的敏捷方法。
这件事情让我回忆起最近正在与很多业界人士合著一本“敏捷开发案例集”，中间有一个讨论时：“到底什么案例是敏捷案例，什么案例不是敏捷案例？”
最后的结论是：“第一个很松：大致有点和敏捷沾边就行；第二个很严：开发方法一定要被证明是优秀的”，换言之如果大家对优秀的开发方法视而不见，而到处找“敏捷开发方法”，就是舍本逐末了。
下一篇，将谈及开发团队的测试团队的组织关系问题，比如专业的测试团队好，还是分散到开发团队中的测试团队好，抑或还存在其他的组织结构等。
整体上有两种测试团队的模型，既然都有存在，自然是各有各的道理。城里城外的人倒不必互相羡慕，只是要观察对面的优点，分析自己的缺点，尝试做点事情补偿一下。
所以，下面多说一点各自的坏处。
独立的测试团队
这个就是著名的与程序团队打架的测试团队。
好处
独立团队，还是能保证一定的“公正性”的，比如在测试的最终，横竖有人能不屈 从于程序团队的要求隐瞒产品质量，而是的确会客观地评价质量。
坏处
当测试团队完全独立于开发团队的时候，常常有几个误区。
1. 程序团队是用来开发功能的，测试团队是用来查找缺陷的
有了这个认识，要让两者打架就不难了。
2. 更多的测试人员=更高的质量
很多公司拥有惊人的测试人员比例，程序和测试基本上能到1：1，这个已经接近了造航天飞机的水平（50：80），但是质量……一般缺陷率都能达到航天飞机的一万倍左右。
1和2是互相促进的，一旦拥有了1的认识，程序团队就对质量不太在乎了，因为后面有人负责测试，有Bug漏掉还要承担责任，所以自己只管按自己的兴趣编写代码就是了；而留下的缺陷越来越多，自然就需要更多的测试人员来解决。
分散的测试团队
好处
每个团队都有测试人员，自然测试活动会被当作家里的事情来看待，有机会在很早的时候就启动测试活动；由于没有后继的测试活动了，也没有人可扯皮了，所以组内的测试活动的效果会比较好。
坏处
常常有这样几个误区。
1. 人员不能共享，测试人员不足
基本出发点，还是认为这几个测试人员是来帮助解决缺陷问题的，因此他们极有可能成为局部的捡垃圾者。
由于只能调用自己的测试人员，当然逐渐地几个人就不够用了，也需要更多的测试人员。
2. 缺少总体质量的把关者
由于所有测试人员都被当作小组的负责质量的人，产品最终所有模块集成在一起的时候，质量由谁负责，就成了个问题；集成后如何验证整体业务（而非技术），也是个问题。
F型测试团队
这是本人“次喜欢”的一种模型。
如果历史问题已经形成，或者说不可能拆分掉专业测试团队，可以考虑这个形状。
F的两个横线，代表分散的测试团队，就是整体上测试团队的人员在项目成立时，分别被指派到程序团队中，协助在早期就提升质量。
而竖线，则表明他们定期向测试经理报告各小组的的进展，分散到各小组的几个测试人员之间也可以频繁通气，以便做好集成准备；并在几个小组都完成了内部的工作时，很方便地接管集成和整体测试工作。
好处
是当团队使用敏捷开发的迭代交付的时候，这几个测试人员还是可以进行很好的持续支持的，比如完成一个版本，就测试一个版本。
由于他们长期在项目组内工作，而且定期通气，所以接管系统测试会变得非常顺畅。
坏处
这个模型有些矩阵式的团队的确在用，不过需要很好的管理，确切说是文化，才能做好。
个人感觉在操作这种团队的时候，整个大项目的经理（同时管理开发和测试的），必须要有很强的管理能力，并随时防止程序团队和测试团队分化。
实际上在很多时候，领导的作用都不再是管事，而是管人，就是如何管理好多个团队之间的关系。
小型测试团队
个人感觉最容易驾驭的团队。
比如有20个人，4～5个程序团队外加1个测试团队。
每个程序团队都各自负责自己的质量（不派驻测试人员），而那个测试团队则只负责业务层面的测试或称为验证，不负责质量。
好处
这种团队基本上是前面那个案例1（参考I和II）中的团队模型，由于当年的团队非常成功，所以非常推荐。
这种团队的集成活动是由开发团队和测试团队一起完成的，两者都为此负有责任；但完成集成后，由测试团队自己做系统级的业务测试。
整体上，是一种很“无我”的敏捷团队。
坏处
这种团队只在上面提到的那个公司见过一次，之后的团队似乎都没有采取这个形式的，表明这种形式不容易自然形成。
不过，鉴于当年的效果如此之好，本人一定会在自己未来的团队中采用这个模型。
而实际上每个公司，与其在那些很容易组建但同时很难做好的团队模型中挣扎，不如去尝试一下真正效果好的团队模型。
很多人都很希望找到一种很容易做到，效果又好的模型（以及任何其他东西）。如果这种模型存在，全国人民都别炒房了，都来开软件公司吧。（本资讯于2016-12-10首次发布）
