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