路宁(luning)的博客

    敏捷开发中有一项实践是结对编程（Pair Programing），指的是两个人坐在一起共同开发一项任务，这样做的目的常常被解释为便于传递知识，提高软件质量。

    结对的两个人是需要经常换的，不同的团队往往有不同的Switch策略。有的做完一个Story再换，一般要2、3天或更长；有的团队每1、2天换一次，不管有没有做完Story；有的团队确保每个Story有一个Owner，他始终不离开这个Story；还有的团队坚持每半天全体换一次Pair。

    不断的切换工作内容（Switch Tasks）往往被认为会降低工作效率，不容易集中精力做好一件事情，是一种浪费。精益生产中有7种典型的浪费，其中一种是“运输”。Mary Poppendieck和Tom Poppendieck在他们的《Lean Software Development》一书中阐述了软件开发中与之对应的7种浪费，与运输对应的就是Switch Tasks。这么看来，频繁的Switch Pair就是一种浪费了吧？

    要搞清楚这个问题，首先我们要搞清楚Switch Task导致了什么浪费，浪费出现在新人要花时间弄清楚要做什么，已经做了那些，怎么做的，另一个人也要花时间解释，对应的，在彻底离开一个Story之前可能还需要一些交接和说明工作。这就是所谓的“切换时间”，简单说是从停止编写前一个Story的代码到开始正式编写下一个Story代码之间的时间，这才是我们要找的浪费。

    因此，频繁的Switch Pair不是浪费，Switch过程中的“切换时间”才是浪费。如果频繁的Switch Pair一定会导致更多的“切换时间”，我们才可以说它是浪费。我们质疑的正式这一点!

    精益生产和丰田生产方式（Toyota Production System，TPS）中有“换型时间”的概念，这是指在机器设备准备换产另外一个型号的产品时，从完成上一个型号最后一件合格产品到生产出下一个型号第一件合格产品所花的时间。比如一台设备需要5个小时进行清理，调整和更换工装，才能生产另外一种零件，可以想像此时工厂无法频繁换产，可能的结果就是一次尽量多地生产一种型号产品，减少换产的次数。但丰田生产方式认为频繁换产是必要的，因此坚持通过改用小型设备，改造现有设备，发明专门工具等方式，缩短换产时间（从5个小时缩短到了20分钟），此时工厂就能从容地根据客户的实际需求进行换产了。

    像精益生产和丰田生产方式一样，敏捷开发认为，频繁的Switch是有价值的，同时它也并不会必然导致“切换时间”的累计增加。减少切换时间的方法很多，比如：
    * 尽量小的Story
    * 标准化。编码、开发环境和配置、知识技能等等的标准化（标准化也即智慧共享，并不意味着很少变化）
    * 简单设计
    归根结底是要保持“简单设计”，代码要简单，目标是没有重复的逻辑，团队中的每个成员都能看懂任何部分的代码，简单到只需要极短的切换时间。

    简单意味着高质量，它是频繁Switch的目的，频繁Switch则是实现简单的手段。

    频繁Switch让问题（复杂性）更容易暴露出来，当Switch的过程中出现下列现象时，就说明有问题了：
    * 有人开始发牢骚，甚至要骂人
    * 紧皱眉头，不断在文件间切换，没有写代码（切换时间长）
    * 看着代码无奈地苦笑
    * Story要超出预测几倍的时间才能完成
    * Bug明显增多
    这些现象往往说明代码中有问题了，可能是因为复杂难懂的代码，责任不清的类，重复实现的逻辑，含义不清的测试和没有测试的逻辑等，技术问题进而会导致士气低落，责任感降低等团队问题。可见，增加Switch的频率是有风险的，要量团队之力而为之。

    出现问题时需要勇敢地去解决问题，而不是简单地降低Switch的频率，很低的Switch频率容易让问题隐藏起来。

    Switch频率到什么程度合适呢？这主要取决于目前代码的质量，项目类型和团队成员的能力。简单地说，这个频率要能逼出问题，但不能太多，必须是团队可控的程度。

    Switch作为保持简单性和高质量的手段，重点不仅是找到Switch频率的一个平衡点，而是不断调整这个平衡点，视较长的“切换时间”为复杂性的表现，持续逼出并解决问题。