吃自己的狗粮
当开发人员坐在测试工作站前，你将会诧异于多少开发人员因为繁琐的步骤而不会安装/升级自己参与制作的软件，多少人认为自己设计的复杂配置是荒唐的。在很多情况下，这都不是安装、配置的问题，而是设计问题，将开发和测试过程分离把痛苦转嫁给了另一个团体（测试、用服、用户），开发人员丧失了亲身使用软件的机会，从而无法发现问题的存在。暴露并修正这些问题，是将开发人员和测试人员进行轮换的主要价值之一。从我们的经验数据看，开发人员可以在一周内掌握大多数的测试技巧，个人的建议是从经验丰富的开发人员开始轮换，一方面他们更能认识到测试的必要性，便于交流，也便于形成表率。另一方面丰富的经验更容易帮助他们察觉到问题的存在。其它的一些要点是：
- 一对一的充分交流，让开发人员认识到进行测试工作的价值和目的。
- 引导开发对痛点进行思考、改进。改变测试简单、重复的工作面貌，要对开发人员形成挑战。
- 一周轮换2天持续数周或连续轮换2星期为宜。
睁开眼睛看大象
开发人员习惯于正确性驱动，然而正确的返回结果却不一定是必须的，有时甚至是一种浪费。我们项目所需要处理形如1001的期货时间戳，10代表2010年，01代表一月份。开发人员自然想到了如何区分1910年、2010年、2110年的问题。于是复杂的内部表达被设计出来，用于推断正确年份。这是必须的么？如果我们能了解到客户最大的压力在于半年后项目能否成功上线替换掉现有无人能够维护的应用，而不是100年后才可能出现的问题，我们是否能在类似的技术决策中，做出更聪明的选择呢？帮助开发/测试角色获取更多的信息，让他们了解到制定需求的上下文，而不仅仅是需求是什么；让他们更高的层面认清各个故事之间的关联，能够分辨可以给客户带来最大价值的任务，这是将开发角色/测试角色与分析角色对换的主要价值。一些要点是：
- 在进行分析工作前，开发人员需要完成多个模块的开发，而测试人员最好完成开发轮岗，否则收效甚微。
- 分析工作可以兼职进行，我们认为比较有效的方法是每天下午花40分钟让开发/测试人员在教练的带领有重点的分析一、两个故事。
- 重点放在提供一套思考框架帮助新手梳理分析思路，我们发现一个有效的方法是结对工作、独立思考、演讲并点评。（参见结对工作，不止与结对一节）
根据我们的经验，两周全程跟踪式的结对分析足够帮助新手初步掌握分析思路，教练可以考虑逐渐减少在新手思考过程中的侵入，再经过大概2个月的练习，新手基本可以独立工作。
和客户对话
在进行过分析角色的轮换后，可以进一步利用需求管理作为主线让团队成员参与到客户交流中，慢慢削弱项目经理的客户联系人角色，其主要价值在于：
- 提升交流质量，一线人员常常比项目经理更了解产品。
- 展示开发人员的能力，增强客户信心。
- 弱化项目经理在客户眼中的重要性，为未来平滑的取代项目管理者，减少开销作准备。
- 帮助技术人员掌握交流技巧、提升团队能力。
个人建议是：
- 从例行的功能展示会（showcase）开始，让每个成员练习从客户的角度进行思考（客户想看什么？），锻炼语言能力，消除与客户交流的恐惧感，并且让客户熟悉开发团队的每个成员，习惯开发团队的交流方式。
- 由多人分别准备客户进行电话会议中需要讨论的议题，每人深入思考的一、两个问题，通过充分思考弥补经验、技巧上的不足。
- 结对完成发给客户的邮件，让另一双眼睛检查有没有把该说的问题点到，表达方式、方法是否得当。
- 提供一套与客户交流的思考框架，并在与客户的交流中不断强化它。我们采用的框架是“客户，交付，流程，员工”，团队成员在思考问题时，首先从这四个点出发再逐层展开。
这项练习需要贯穿项目始终，对于团队成员无差别的进行，我们的经验数据是经过5个月左右的练习，项目经理就不需要出现在与客户的例行电话交流中了。
写程序，我行么？
测试人员普遍编程技术能力欠缺，同时有常常对编程这一未知的经验产生恐惧。从经验看，如果测试人员不能编写、维护自动化测试，测试工作将很快成为交付瓶颈。通过编程，让测试人员掌握技术，避免瓶颈的出现是测试到开发角色转换的主要价值。我们所采取的步骤是：
- 与测试人员结对完成简单的编码任务，不断树立信心。在这个团队中，我们