很多团队都有tech lead这个角色的存在，但同时很多团队对这个角色都缺乏明确的定义。大多数时候，团队只是指派其中经验最丰富、技术最精熟的开发者来担当tech lead。但除了“tech”的成分之外，这个角色还有“lead”的成分，这就决定了他不仅需要技术上的能力，还要眼观六路耳听八方，才能带领团队──至少是开发者们──取得成功。

　　Tech lead需要关注的事情可谓纷繁芜杂。把这些事情分门别类，我们可以看到，这个角色大致有三方面的职责：技术决策者、流程监督人、干扰过滤器。

　　技术决策者

　　从技术的角度，tech lead需要关注以下三个方面：架构设计、局部设计和关键技术点。

　　参与架构设计

　　系统的架构通常是在项目初期的quickstart阶段设计出来的。这个架构设计包含的都是高层面的内容，例如C/S或B/S的选择、开发平台、编程语言、数据迁移策略、集成点、部署结构等。

　　尽管架构师（architect）是架构设计的主要负责人，tech lead还是会参与设计过程，以获得对系统全局的清晰了解，并且尽早发现架构设计中不合理或者风险较高的部分。

　　主要关注点：

　　选择什么平台和编程语言？
 
　　需要和什么系统集成？需要使用哪些第三方软件或工具？

　　给自己画一张集成架构图：先用虚线圈出为用户提供服务所需的整个系统范围，再用实线圈出将用主要编程工具（例如J2EE或者Ruby on Rails）开发的应用程序，两者之间的其他东西就是你需要集成的目标。找出集成点和集成方式。留住这张图并保持更新，你会经常用到它。

　　如何部署？如何迁移现有数据？

　　开发团队日常部署到什么环境？UAT（用户验收测试）和性能测试的环境由谁部署？生产环境由谁部署？部署的频度如何？开发和测试使用的数据集从何而来？数据迁移是部署过程的一部分吗？除了自动化部署脚本之外还需要什么额外的环节吗？ 团队的技能是否与项目需求匹配？

　　攻克技术难题

　　作为“tech”lead，解决技术上的难题、为团队扫清前进道路，自然是题中应有之义。由于具备对系统全局架构的了解，tech lead能够识别出项目中可能遇到的技术挑战，及时进行研究和实验，尽力使其不对开发工作造成阻碍。

　　主要关注点：

　　集成点是否得到妥善处理？能成功集成吗？用于集成测试的环境到位了吗？出错的情况妥善处理了吗？ 如果技术栈中的某一部分出现问题怎么办？项目中用到的第三方组件有谁熟悉？如果是开源软件，相关的社群在哪里？如果是闭源软件，我们能得到其生产厂商的技术支持吗？

　　确定设计方案

　　敏捷项目中，大部分设计都是在项目过程中做出的，其中有些设计会对系统整体产生较大的影响，有时甚至会改变起初的架构设计。所以贯穿整个项目，tech lead需要保持对系统整体和细部的把握，选择适当的设计方案，或是通过重构让好的设计浮现出来。

　　主要关注点：

　　代码中是否出现明显的bad smell？

　　是否看到明显的大类、长方法或者重复代码？条件逻辑嵌套太深了吗？本应属于模型的逻辑在视图或者控制器里堆积了吗？是否应该考虑做一做对象健身操？（参见《ThoughtWorks文集》，第6章）
 
　　局部设计是否会对系统造成明显的损害？这个设计会严重损害性能吗？它是一个安全漏洞吗？它是难以测试的吗？它损害了系统遵循的概念一致性吗？团队是否正在进行关于设计和重构的讨论？

　　要在局部设计上具备发言权，tech lead就不能脱离开发工作──不写代码的人是无权评价代码的。在讨论细部设计时，tech lead需要把握一个微妙的平衡：既不要过于民主而耗费太多时间，也不要过于集中而使团队成员失去学习和思考的机会。一个好的实践是：每天早上把所有开发者召集起来，用15～20分钟浏览前一天编写的所有代码，这样每个人都有机会在看到bad smell时指出。

　　流程监督人

　　为了保障开发工作顺畅进行，tech lead需要从以下三方面入手来保持对开发流程的关注：开发环境、持续集成和测试。

　　开发环境

　　Tech lead需要保障良好的开发实践得到贯彻，尤其是当团队中有较多缺乏经验的成员时这一点就更显重要。一家公司内部很可能有一些成熟的开发套路，这也使得每个tech lead的责任更重大：如果团队成员在一个项目中没有养成好习惯，受损害的不仅是这一个项目，还有整个公司的习惯套路。

　　主要关注点：

　　如何使开发团队拥有统一的环境？IDE的设置和快捷键如何同步？shell设置和别名如何同步？数据库设置如何保持一致？需要将开发环境虚拟化吗？如何实现一段代码并提交？开发者从哪里获取验收条件？编写代码时应该遵循哪些惯例？功能完成之后是否需要邀请BA/QA快速确认？提交代码之前应该如何进行本地构建和测试？提交时的注释格式有什么要求？

　　ThoughtWorks的很多Ruby on Rails项目都采用“rake commit”这个任务来提交代码。这个任务会从svn服务器更新代码、执行本地构建、运行测试、要求开发者输入符合格式的注释内容、然后提交修改内容。我们通常还会给这个命令指定一个shell别名“rc”，这样我们只需要敲三下键盘就可以开始一次标准的提交。

　　如何结对编程？

　　哪些任务需要结对？哪些任务可以不必结对？结对的轮换合理吗？是否有谁在某一个任务上做了太长时间？是否有谁对某一部分完全不了解？结对过程中大家都全心投入了吗？是否需要用特别的结对方法来引导经验较少的团队成员？需要开发者和QA结对吗？
Tech lead同样需要与团队成员结对，有时是为了理解某一部分的实现，有时是为了指导和帮助队友。Tech lead应该始终牢记自己是开发团队的一份子，每天都应该尽量安排出时间参与结对；同时其他开发者也应该谅解tech lead还有其他职责，不要因此拒绝和他结对。

　　持续集成

　　每个人都需要对持续集成负责，有一个人需要负更多的责，这个人就是tech lead：他要清楚持续集成中每个阶段的用意，当集成失败时他要知道这意味着什么。关于持续集成的设计，我强烈推荐Dave Farley的文章“一键发布”（《ThoughtWorks》文集，第12章）。

　　主要关注点：

　　持续集成环境和生产环境有多大差异？持续集成覆盖哪些阶段？项目各方的关注点在持续集成中都有体现吗？性能测试被覆盖到了吗？打包部署呢？拿到持续集成产出的安装包，我们一定有信心将它部署到生产环境吗？持续集成给开发团队快速而有用的反馈了吗？经常失败的是哪些阶段？随机失败的概率大吗？随机失败会掩盖真正的问题吗？从提交代码到走完所有集成阶段通常需要多长时间？需要使用更大规模的并行集成吗？（例如引入更多的Cruise Agent。）

　　测试

　　测试就是开发者要满足的目标。没有良好的测试，就等于没有良好的目标。作为tech lead，要关注不仅是单元测试，还包括功能测试和各种非功能性需求的测试；不仅是开发者编写的测试，还包括QA乃至客户的测试。当然，从技术的角度出发，tech lead更关注的还是自动化的测试。

　　主要关注点：

　　团队如何实施TDD？测试的粒度和层面合理吗？是否有适当的系统测试？是否有滥用系统测试取代单元测试的倾向？修复bug时先用测试来描述bug了吗？集成点都有测试覆盖吗？数据迁移都有测试覆盖吗？功能测试/验收测试的质量和进度如何？QA和开发者如何借助功能测试沟通？如果功能测试由QA编写，能赶上开发的进度吗？测试代码的质量如何？如果由开发者编写，测试覆盖到所有验收条件了吗？QA能否理解和维护测试代码？是否需要安排QA和开发者结对编写功能测试？ 性能测试得到足够关注了吗？有清晰的性能需求吗？有性能测试描述这些需求吗？如何得到性能测试的结果？

　　我的同事James Bull在“实用主义的性能测试”（《ThoughtWorks文集》，第14章）一文中对性能测试的做法有精彩的论述，此处不再赘述。
　　
　　干扰过滤器

　　在大部分软件项目中，开发者的工作──细部设计和编程实现──都位于关键路径上：它们未必是最有价值的工作（尽管我个人坚持这样认为），但它们一定是最耗时间的工作。换句话说，开发者的时间是否充分用于开发，将决定项目能否按时交付。所以，tech lead的很大一部分责任就是过滤各种干扰，使开发者们全神贯注地编程。尽管项目经理和BA也起到这样的作用，但还是有很多编程之外的事需要“技术人员”来做。

　　与客户技术团队沟通

　　大多数定制开发项目都会涉及到客户方的技术团队：开发、测试、DBA、运维、支持，等等。光把系统做好还不够，你还得把做好的系统交到他们手上，项目才真算完成──“交到他们手上”这件事就得由tech lead来负责。

　　主要关注点：

　　如何与客户的开发团队交换知识？

　　有哪些惯例需要遵循？有哪些既有的工具可以利用？如果双方开发者同时开发，如何协作？如何结对编程？如果只需要在开发结束后移交产品，如何做知识传递？如何确保对方保持关注？如果双方不在同一地点，是否需要安排定期的电话会议或视频会议？
如何与客户的支持团队协作？生产或UAT环境的服务器由谁管理？如何交付部署包？客户的测试人员如何进行测试？测试结果如何获取？

　　运维团队在软件项目中常常被忽视，但他们对产品的成功上线至关重要。通过搭建和维护UAT/性能测试环境，可以尽早地让运维团队参与到项目之中，并且了解部署和日常管理的相关信息，从而使最终的上线变得相对容易。

　　如何与客户的DBA协作？数据库迁移计划经过DBA复审了吗？DBA是否能获得系统运行时的数据库访问日志？如何与DBA讨论解决数据库相关的问题？

　　一个好的实践是在每次部署到UAT环境之前将近期的数据库改变总结出来告知DBA，并请他持续关注UAT环境被使用时的数据库日志。如果DBA指出一些明显性能低下或者有其他问题的SQL，应该重视他的意见。

　　与BA/QA协作

　　团队内部的“干扰源”主要是BA和QA。BA和QA往往缺乏技术背景，如果他们经常用一些“愚蠢”的问题去打断开发者的工作，开发者们可能会觉得他们添乱多过帮忙。这时tech lead就得表现出更多的耐心，先过滤掉那些没有营养的问题，从而让开发者们觉得与BA/QA的沟通是有帮助的。

　　主要关注点：

　　Story的内容和工作量估计合理吗？Story涉及的功能实现起来有多困难？是否有更简单的方式来实现同样的目标？相关的风险大吗？

　　理论上，工作量估算是由开发者来做的。但有两种原因使得tech lead需要代表开发者来做这件事：（1）找开发者做估算可能打断他们的工作节奏；（2）项目初期可能其他开发者不了解情况，甚至还没有加入项目。同样，如何尽量让所有开发者都感到自己的意见得到尊重，又不过多占用他们的时间，这也是需要平衡的。而代表开发者做估算的准确度也将直接影响tech lead在他们心里的地位。

　　QA的工作需要帮助吗？

　　QA发现bug时会如何处理？他发现的bug经常是“误报”吗？需要帮助他编写自动化测试吗？需要帮助他做性能测试吗？

　　打杂

　　其他所有需要由“技术人员”来做的事，tech lead都应该有自己一肩挑的准备──例如查一下数据库里有哪些不符合业务规则的数据，生成一份CSV文件，小小改动一下界面，甚至倾听一下客户和项目经理的抱怨再给他们一点“技术性”的安慰，等等。

　　但这不表示你就总是应该把这些事一肩挑。Tech lead这个角色的微妙之处就在于：他仍然是“技术人员”，和所有的开发者一样。换句话说，tech lead能做的事，其他开发者也应该能做。所以，再一次地，你应该有一个平衡：把一部分杂事自己消化掉，不让它们干扰开发者的正常工作；另一部分杂事则分配给开发者去做，让他们感到自己除了编程之外还参与了项目的其他方面，同时也给自己挤出一点时间做其他更重要的事。

　　小结

　　在我所经历过的大部分项目里，tech lead都是个超级忙的家伙──看这篇文章就不难理解为什么。人们期望tech lead做的事很多，而且在项目的各个阶段还有所不同，一个人要肩负这样的期望确实不容易。

　　不过只要意识到“tech lead”只是一顶很多开发者都可以戴的帽子，随着项目的进展，你就可以慢慢地把更多的责任放在整个团队的肩上──只要不至于造成损害，于是自己也有了更多的时间来编程。最终你可能会得到一支这样的团队：其中每个开发者相当平均地扮演一部分tech lead的角色，各种任务随优先级被有效地处理。这时你就可以说，这个项目的tech lead确实做好了他的工作。