在    <a href="http://www.open-open.com/lib/view/open1326851369858.html">上篇文章</a>中我们一起回顾了分工历史，对于技术团队影响以及建设全功能团队的必要性 ，在实践篇中我将详细分享一些实践以及我们团队的经验数据。    <h2> 吃自己的狗粮</h2>    <p> 当开发人员坐在测试工作站前，你将会诧异于多少开发人员因为繁琐的步骤而不会安装/升级自己参与制作的软件，多少人认为自己设计的复杂配置是荒唐的。在很多情况下，这都不是安装、配置的问题，而是设计问题，将开发和测试过程分离把痛苦转嫁给了另一个团体（测试、用服、用户），开发人员丧失了亲身使用软件的机会，从而无法发现问题的存在。暴露并修正这些问题，是将开发人员和测试人员进行轮换的主要价值之一。从我们的经验数据看，开发人员可以在一周内掌握大多数的测试技巧，个人的建议是从经验丰富的开发人员开始轮换，一方面他们更能认识到测试的必要性，便于交流，也便于形成表率。另一方面丰富的经验更容易帮助他们察觉到问题的存在。其它的一些要点是：</p>    <ul>     <li>一对一的充分交流，让开发人员认识到进行测试工作的价值和目的。</li>     <li>引导开发对痛点进行思考、改进。改变测试简单、重复的工作面貌，要对开发人员形成挑战。</li>     <li>一周轮换2天持续数周或连续轮换2星期为宜。</li>    </ul>    <h2> 睁开眼睛看大象</h2>    <p> 开发人员习惯于正确性驱动，然而正确的返回结果却不一定是必须的，有时甚至是一种浪费。我们项目所需要处理形如1001的期货时间戳，10代表 2010年，01代表一月份。开发人员自然想到了如何区分1910年、2010年、2110年的问题。于是复杂的内部表达被设计出来，用于推断正确年份。这是必须的么？如果我们能了解到客户最大的压力在于半年后项目能否成功上线替换掉现有无人能够维护的应用，而不是100年后才可能出现的问题，我们是否能在类似的技术决策中，做出更聪明的选择呢？帮助开发/测试角色获取更多的信息，让他们了解到制定需求的上下文，而不仅仅是需求是什么；让他们更高的层面认清各个故事之间的关联，能够分辨可以给客户带来最大价值的任务，这是将开发角色/测试角色与分析角色对换的主要价值。一些要点是：</p>    <ul>     <li>在进行分析工作前，开发人员需要完成多个模块的开发，而测试人员最好完成开发轮岗，否则收效甚微。</li>     <li>分析工作可以兼职进行，我们认为比较有效的方法是每天下午花40分钟让开发/测试人员在教练的带领下有重点的分析一、两个故事。</li>     <li>重点放在提供一套思考框架帮助新手梳理分析思路，我们发现一个有效的方法是结对工作、独立思考、演讲并点评。</li>    </ul>    <p> 根据我们的经验，两周全程跟踪式的结对分析足够帮助新手初步掌握分析思路，教练可以考虑逐渐减少在新手思考过程中的侵入，再经过大概2个月的练习，新手基本可以独立工作。</p>    <h2> 和客户对话</h2>    <p> 在进行过分析角色的轮换后，可以进一步利用需求管理作为主线让团队成员参与到客户交流中，慢慢削弱项目经理的客户联系人角色，其主要价值在于：</p>    <ul>     <li>提升交流质量，一线人员常常比项目经理更了解产品。</li>     <li>展示开发人员的能力，增强客户信心。</li>     <li>弱化项目经理在客户眼中的重要性，为未来平滑的取代项目管理者，减少开销作准备。</li>     <li>帮助技术人员掌握交流技巧、提升团队能力。</li>    </ul>    <p> 个人建议是：</p>    <ul>     <li>从例行的功能展示会（showcase）开始，让每个成员练习从客户的角度进行思考（客户想看什么？），锻炼语言能力，消除与客户交流的恐惧感，并且让客户熟悉开发团队的每个成员，习惯开发团队的交流方式。</li>     <li>由多人分别准备客户进行电话会议中需要讨论的议题，每人深入的思考一、两个问题，通过充分思考弥补经验、技巧上的不足。</li>     <li>结对完成发给客户的邮件，让另一双眼睛检查有没有把该说的问题点到，表达方式、方法是否得当。</li>     <li>提供一套与客户交流的思考框架，并在与客户的交流中不断强化它。我们采用的框架是“客户，交付，流程，员工”，团队成员在思考问题时，首先从这四个点出发再逐层展开。</li>    </ul>    <p> 这项练习需要贯穿项目始终，对于团队成员无差别的进行，我们的经验数据是经过5个月左右的练习，项目经理就不需要出现在与客户的例行电话交流中了。</p>    <h2> 写程序，我行么？</h2>    <p> 测试人员普遍编程技术能力欠缺，同时有常常对编程这一未知的经验产生恐惧。从经验看，如果测试人员不能编写、维护自动化测试，测试工作将很快成为交付瓶颈。通过编程，让测试人员掌握技术，避免瓶颈的出现是测试到开发角色转换的主要价值。我们所采取的步骤是：</p>    <ul>     <li>与测试人员结对完成简单的编码任务，不断树立信心。在这个团队中，我们从设计与实现自动测试框架开始，亲手设计的框架让测试人员更有能力来编写、维护测试，同时增强了编程的信心。</li>     <li>在测试人员消除了编程恐惧、具备编程基础后，安排测试人员与开发人员结对进行功能开发。</li>    </ul>    <p> 在这个过程中，必须首先要帮助测试人员正视编写程序的必要性以及消除恐惧，同时针对每天的工作内容留一些家庭作业的效果也非常好。必须承认的事实是即便在完成轮换后，测试人员较开发人员还有一定距离，然而我们得到了一个意外的收获：进行过轮换后，再讨论需求时，测试人员越来越熟练的使用开发术语与团队交流，越来越多的参与讨论，甚至主导讨论，她开始直接引用核心组件的设计思想来推导测试用例，不断质疑和挑战开发人员，极大的提升了交流的效率和功能实现的质量。从经验数据看，大致需要3个月的时间测试人员可以达到在辅导下完成功能的程度。</p>    <h2> 订最后一颗纽扣</h2>    <p> 前端开发有其独特的知识领域，但这并不意味着任何界面工作都要由前端开发工程师来完成。前后端的分离增加了开发过程中的瓶颈以及人员认知领域中”<a href="/misc/goto?guid=4959500994571621741" target="_blank">Unknown Unknown</a>” 的区域，降低了找到更优解决方案的可能性。前端开发能力的培养特别适合在全团队中无差别的展开：让后端开发人员进行前端开发可以减少瓶颈，积累知识，构造 “T”型知识区。测试人员需要测试界面，所以了解界面是如何工作，可以帮助她们设计出更高质量的用例，对于需求分析人员来说，高保真原型可以用作高效的交流工具。一个有效的方法是全面铺开，引入专家，重点培养，我们所采取的步骤是：</p>    <ul>     <li>要求全团队在业余时间完成一组界面练习，在全团队普及Html, Css和Javascript知识。</li>     <li>引入界面开发专家重点培养一名有兴趣进行界面开发的团队成员，对系统的界面结对进行改进，优化。</li>     <li>在界面开发专家的带领下，全员重新完成之前的界面练习，专家每天用一个小时讲解对应的前端技术并点评作业。</li>    </ul>    <p> 从全面普及知识到引入界面专家再到培养出新人，总共花费3周时间。值得一提的是，在整个过程中，由于之前团队建设的铺垫，其它成员有能力完全分担工作，团队重点培养的开发人员可以不受任何干扰，全职投入到前端开发中，最大程度的利用了界面开发专家的价值，提升了学习效果。</p>    <h2> 上同一艘船</h2>    <p> 项目经理是和技术领袖是作为现场管理者存在的，他们必须能够理解现场，能够通过现场的痕迹找到团队的不足和改进方向。那么，没有什么比卷起袖子参与到一线的工作中更能帮助这些角色理解现场。形成对产品质量和进度的亲身体验。理解现场，有效的管理现场而不是管理数据，而是这些角色轮换到开发、测试或者分析工作的主要价值所在。现场管理人员常常有太多的职责，既要对内负责也要对外负责，一个自然而然的问题是：”没有时间投入一线工作“。我认为现场管理人员的工作主要是两个部分：首先是职责所赋予的管理性事务，譬如状态的汇报，客户的管理等；其次是能力所赋予的工作，作为团队中最有经验的成员，他们需要参与到需求分析、架构设计、决策的制定、培训等活动中。基层管理者应当有意识的主动卸下身上的工作职责，完成到一线角色的转换，从另一个角度看，这个过程就是整个团队能力提升的过程，个人经验是：</p>    <ul>     <li>对职责所赋予的工作，首先做到对团队的状态、开发的进度等尽量的做到自动化、透明化、可视化，让所有人都能获得这些信息，其次通过知识传递，把不涉及敏感内容的工作下放，重点培养一、两名团队成员参与管理。</li>     <li>对能力所赋予的工作，一是针对团队急需提升的能力组织培训，二是通过结对工作传递知识，提升能力，让团队习惯于自行决策，有意识的逐步弱化自己在团队中的重要程度。</li>    </ul>    <p> 我们的的经验数据是大约需要4个星期，新人可以在指导下正确的进行管理实践（正确的做事），这已经可以保证基层管理角色有一定的参与一线工作的时间；而让新人具备辨别团队目前需要什么帮助（做正确的事），进一步将原有的管理角色基本弱化为开发角色，则需要6个月左右的引导和练习。</p>    <h2> 结对工作，不止于结对</h2>    <p> 我完全认可结对工作在知识传递、提升工作正确性方面的作用。我们几乎结对作所有的事情，某种程度上结对工作成为一种文化，成为了思维惯性和一种必然。长期的结对工作让我发现目前的结对方式对于培养新人还不够友好，这里，新人所指代的是广义的新人概念，不仅仅指毕业生，刚刚从事测试工作的开发达人也算是测试新人。目前结对方式的的缺点在于：</p>    <ul>     <li>培养了思维惰性，心理上依赖于别人的带领。</li>     <li>无法从失败中学习。有经验的人常常会跳过很多陷阱，新人的工作经历全是各种成功，一旦独立工作就被这些陷阱打的措不及防。</li>     <li>只见树木不见森林。譬如在TDD的过程中，新手可以看到一个个的方法是如何被设计的，如何从测试中被驱动出来，但很难从他的搭档那里学会如何想到要设计这些方法？从下向上驱动还是从上向下，各有什么区别？为什么这个方法要被放在这个类，而不是那个？</li>    </ul>    <p> 我认为结对工作其中一个被忽略的要点在于让新人在可控的状态下经历失败，获取经验，并且在工作中学会思考问题的方式（如何发现问题？从何处着手？怎么在不同的方案中取舍？从哪里开从哪里开始分析？），而不仅仅是思考问题本身（写什么测试？如何让测试通过？）。从我的观察看，培养新人比较有效的途径是从全程结对工作开始，通过对细节的指导让新人了解工作的主要方式和职责，进行必要的知识贮备，学会如何正确的做事。接下来应当让新人逐渐学会什么是正确的事情。我们的做法是：</p>    <ol>     <li>新人接到任务后，自行思考。</li>     <li>在白板上写下完成任务的主要步骤</li>     <li>向教练讲解主要思路和考虑点，教练通过提问引导他（输入特殊字符会怎样？）</li>     <li>自行完善方案</li>     <li>和教练一起确认方案</li>     <li>教练对整个思考过程进行点评，告诉新人这类问题的思考要点。</li>    </ol>    <p> 整个过程大致耗时半个小时，这种方式的优点是新人对方案非常了解，执行起来不容易跑偏；有机会在可控范围内犯错，成长更快； 新人可以通过不断的练习，有能力通过多个任务逐渐总结出一套思维方式。教练利用这种方法可以通过代码检视和有选择的结对（譬如针对任务中的难度部分结对）同时帮助多人，更有效率。</p>    <h2> 结局</h2>    <p> 在咨询的过程中，我见过太多的团队把目标放在交付上，寄希望于工具、外部力量能够快速的解决问题，往往对小步前进不够耐心，不关心团队的成员。在我们这个90%以上成员没有.Net经验，50%是毕业生的团队中，那些微不足道的改进，一点点的提升，最终造就了这个9个月中没有一天加班，几乎没有缺陷，提前交付的项目，客户甚至愿意为他们的满意额外支付3万美金作为奖励。我把全篇总结为一句话：<strong>把项目目标放在人员能力提升，让项目成功成为能力提升的副产物。<br /> <br /> </strong></p> 转自：    <a href="/misc/goto?guid=4959500994653349641" target="_blank">http://www.infoq.com/cn/articles/hk-build-full-function-team-practice</a>