持续集成

    每个人都需要对持续集成负责，有一个人需要负更多的责，这个人就是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确实做好了他的工作。