免费下载案例集|20+数字化领先企业人才培养实践经验 了解详情
写点什么

Tech Lead 的三重人格

  • 2009-08-05
  • 本文字数:5051 字

    阅读完需:约 17 分钟

很多团队都有 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 中文站用户讨论组中与我们的编辑和其他读者朋友交流。

2009-08-05 00:2611544

评论

发布
暂无评论
发现更多内容

深入理解JobScheduler与JobService的使用

android 程序员 移动开发

深度探索 Gradle 自动化构建技术(二、Groovy 筑基篇)

android 程序员 移动开发

温故而知新:重新认识Activity的生命周期

android 程序员 移动开发

疫情结束后,会影响程序员年后找工作吗?

android 程序员 移动开发

瞬息万变的技术圈与焦虑的技术人,进阶Android需要掌握的那几个关键技术!

android 程序员 移动开发

滴滴国际化项目 Android 端演进

android 程序员 移动开发

炒冷饭之Https 建立链接

android 程序员 移动开发

玩转AppBarLayout,更酷炫的顶部栏(1)

android 程序员 移动开发

玩转AppBarLayout,更酷炫的顶部栏

android 程序员 移动开发

疫情过后,想找工作的你还不看这份资料就晚了!!史上最强总结

android 程序员 移动开发

深入解析Flutter架构

android 程序员 移动开发

疫情下,中年IT的焦虑

android 程序员 移动开发

深入理解HTTPS协议

android 程序员 移动开发

漫谈MVVM(1)ViewModel_DataBinding核心原理(1)

android 程序员 移动开发

用MVP模式构建Android代码

android 程序员 移动开发

疫情被裁3个月,看我如何拿下腾讯offer(附面经+面试心得

android 程序员 移动开发

深度思考:已经开发8年的你,为何跳槽被多家大厂拒绝?为什么会迷茫Android开发还有什么能学习的

android 程序员 移动开发

【设计模式】第十三篇 - 享元模式 - 连连看的图片共享

Brave

设计模式 享元模式 11月日更

混合开发框架最全对比,为什么我更推荐Flutter?

android 程序员 移动开发

牛掰!阿里P7大佬爆肝半个月,把安卓源码解析编成了508页的PDF

android 程序员 移动开发

疫情下中年IT的焦虑

android 程序员 移动开发

漫谈MVVM(1)ViewModel_DataBinding核心原理

android 程序员 移动开发

炸裂!一次Android实习经历告诉你:老爸不是张一鸣,该用什么技巧进字节

android 程序员 移动开发

深度探索 Gradle 自动化构建技术(四、自定义 Gradle 插件)

android 程序员 移动开发

渣渣二本的辛酸面试之路:从深圳外包到杭州蚂蚁金服,4年小Android的爬坑历程

android 程序员 移动开发

源码解析,Glide加载GIF图的原理竟然这么简单

android 程序员 移动开发

漫谈MVVM(1)ViewModel_DataBinding核心原理(2)

android 程序员 移动开发

盘点2020年Android面试必备知识点

android 程序员 移动开发

EMQ 获评“最具潜力边缘计算企业”,推动边缘计算生态发展

EMQ映云科技

物联网 IoT mqtt

灵魂拷问:Android开发初期之后怎么提升?怎么才能叫精通?方向在哪

android 程序员 移动开发

直播App中Android酷炫礼物动画实现方案(下篇):SVGA由来与Lottie的对比

android 程序员 移动开发

Tech Lead的三重人格_Java_熊节_InfoQ精选文章