BT

您是否属于早期采用者或者创新人士?InfoQ正在努力为您设计更多新功能。了解更多

Tech Lead的三重人格

| 作者 熊节 关注 0 他的粉丝 发布于 2009年8月5日. 估计阅读时间: 不到一分钟 | 智能化运维、Serverless、DevOps......2017年有哪些最新运维技术趋势?CNUTCon即将为你揭秘!

很多团队都有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确实做好了他的工作。

相关阅读

[ ThoughtWorks实践集锦(1)] 我和敏捷团队的五个约定

[ ThoughtWorks实践集锦(2)] 如何在敏捷开发中做好数据迁移

[ ThoughtWorks实践集锦(3)] RichClient/RIA原则与实践(上)(下)

[ ThoughtWorks实践集锦(4)] 为什么我们要放弃Subversion

[ ThoughtWorks实践集锦(5)] “持续集成”也需要重构

[ ThoughtWorks实践集锦(6)] Mock不是测试的银弹

[ ThoughtWorks实践集锦(7)] 环境无关的环境


给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家加入到InfoQ中文站用户讨论组中与我们的编辑和其他读者朋友交流。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

受益匪浅的文章 by 李 新

很多事情在工作中都实际碰到,但是由于对个人角色的定位含含糊糊,做起事来,该做的没做,不该做的做了一大堆,遇事没有轻重缓急等等,今天一看,有点感觉了。

fix your bugs by bartuer bartuer

- 15-20 minutes to review all change set last day: then, how many developers in your team? if there are 3 guys, and each have 20 commits, you need review 60 commits, you can go through diff at rate about 100 loc/min ? the time is only meaningful for yourself's work, man.

- how to sync IDE's key bindings, hmm, seems you only use a non-distribute VC for code, one sentence solution: cd ~/emacs.d; git init. if you do not use git, you should use it of couse, if you do not use emacs, you should use it absolutely

分析的很透彻,有很大启发 by 浦 梁

这个角色很重要,今天还在考虑团队凝聚力如何保证,Tech Lead是一重要保障

很棒的文章 by 张 凯峰

总结的好

深有感触 by 郑 伟波

这几点总结的非常到位,归根结底都是为了保证项目的成功和高效。

感同身受! by Chou Jacky

分析得很不错。描述内容和我现在做的职位和工作一模一样!
而我有些时候还需要做一些PM的工作。譬如:项目计划、预算、招人……

透彻,很棒 by 刘 晶洁

工作中的各种问题,都分析到了。非常好!

很好 by Chen David

很到位,很有借鉴

TL不是个好差事呀 by Tarzan Wang Tarzan Wang

TL不是个好差事呀

这个工作职责会不会过多了? by Wang Dong

那么这个人会不会很累?搞了半天会不会发现团队离不开他了?

强烈同感 by 张 鹏

目前处于这个状态中,深有同感!!!

很好的文章,但内容太细了 by Chong (崇桦) Terry

非常同意作者的观点, 其实,更多所谓的TL,应该是指TEAM LEAD而不是单纯的Tech Lead.
TL的工作已经覆盖了多个项目相关职能的工作内容:
TL = 技术决策者 (Tech Lead) + 流程监督人(Scrum Master)+ 干扰过滤器(PM)
个人认为TL,应该是一个决策者,而不是每个具体工作都要自己执行的执行者。一个好的决策者可以做到如本文最后所说的"最终你可能会得到一支这样的团队:其中每个开发者相当平均地扮演一部分tech lead的角色,各种任务随优先级被有效地处理。"

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

12 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT