查看原文
其他

TW洞见|你懂Tech Lead吗?可知道Tech Lead的三重人格?

熊节 ThoughtWorks洞见 2020-02-27

今日洞见

文章作者来自ThoughtWorks: 熊节。文章转自:http://www.infoq.com/cn/articles/thoughtworks-practice-part8 图片来自网络。

本文所有内容,包括文字、图片和音视频资料,版权均属ThoughtWorks公司所有,任何媒体、网站或个人未经本网协议授权不得转载、链接、转贴或以其他方式复制发布/发表。已经本网协议授权的媒体、网站,在使用时必须注明"内容来源:ThoughtWorks洞见",并指定原文链接,违者本网将依法追究责任。


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

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

技术决策者

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

参与架构设计

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

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

主要关注点:

1、选择什么平台和编程语言?

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

3、如何部署?如何迁移现有数据?
开发团队日常部署到什么环境?UAT(用户验收测试)和性能测试的环境由谁部署?生产环境由谁部署?部署的频度如何?开发和测试使用的数据集从何而来?数据迁移是部署过程的一部分吗?除了自动化部署脚本之外还需要什么额外的环节吗?

4、团队的技能是否与项目需求匹配?

攻克技术难题

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

主要关注点:

1、集成点是否得到妥善处理?
能成功集成吗?用于集成测试的环境到位了吗?出错的情况妥善处理了吗?

2、如果技术栈中的某一部分出现问题怎么办?
项目中用到的第三方组件有谁熟悉?如果是开源软件,相关的社群在哪里?如果是闭源软件,我们能得到其生产厂商的技术支持吗?

确定设计方案

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

主要关注点:

1、代码中是否出现明显的bad smell?
是否看到明显的大类、长方法或者重复代码?条件逻辑嵌套太深了吗?本应属于模型的逻辑在视图或者控制器里堆积了吗?是否应该考虑做一做对象健身操?(参见《ThoughtWorks文集》,第6章)

2、局部设计是否会对系统造成明显的损害?
这个设计会严重损害性能吗?它是一个安全漏洞吗?它是难以测试的吗?它损害了系统遵循的概念一致性吗?

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

流程监督人

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

开发环境

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

主要关注点:

1、如何使开发团队拥有统一的环境?
IDE的设置和快捷键如何同步?shell设置和别名如何同步?数据库设置如何保持一致?需要将开发环境虚拟化吗?

2、如何实现一段代码并提交?
开发者从哪里获取验收条件?编写代码时应该遵循哪些惯例?功能完成之后是否需要邀请BA/QA快速确认?提交代码之前应该如何进行本地构建和测试?提交时的注释格式有什么要求?
ThoughtWorks的很多Ruby on Rails项目都采用“rake commit”这个任务来提交代码。这个任务会从svn服务器更新代码、执行本地构建、运行测试、要求开发者输入符合格式的注释内容、然后提交修改内容。我们通常还会给这个命令指定一个shell别名“rc”,这样我们只需要敲三下键盘就可以开始一次标准的提交。

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

持续集成

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

主要关注点:

1、持续集成环境和生产环境有多大差异?

2、持续集成覆盖哪些阶段?
项目各方的关注点在持续集成中都有体现吗?性能测试被覆盖到了吗?打包部署呢?拿到持续集成产出的安装包,我们一定有信心将它部署到生产环境吗?

3、持续集成给开发团队快速而有用的反馈了吗?
经常失败的是哪些阶段?随机失败的概率大吗?随机失败会掩盖真正的问题吗?从提交代码到走完所有集成阶段通常需要多长时间?需要使用更大规模的并行集成吗?(例如引入更多的Cruise Agent。)

测试

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

主要关注点:

1、团队如何实施TDD?
测试的粒度和层面合理吗?是否有适当的系统测试?是否有滥用系统测试取代单元测试的倾向?修复bug时先用测试来描述bug了吗?集成点都有测试覆盖吗?数据迁移都有测试覆盖吗?

2、功能测试/验收测试的质量和进度如何?
QA和开发者如何借助功能测试沟通?如果功能测试由QA编写,能赶上开发的进度吗?测试代码的质量如何?如果由开发者编写,测试覆盖到所有验收条件了吗?QA能否理解和维护测试代码?是否需要安排QA和开发者结对编写功能测试?

3、性能测试得到足够关注了吗?
有清晰的性能需求吗?有性能测试描述这些需求吗?如何得到性能测试的结果?
我的同事James Bull在“实用主义的性能测试”(《ThoughtWorks文集》,第14章)一文中对性能测试的做法有精彩的论述,此处不再赘述。

干扰过滤器

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

与客户技术团队沟通

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

主要关注点:

1、如何与客户的开发团队交换知识?
有哪些惯例需要遵循?有哪些既有的工具可以利用?如果双方开发者同时开发,如何协作?如何结对编程?如果只需要在开发结束后移交产品,如何做知识传递?如何确保对方保持关注?如果双方不在同一地点,是否需要安排定期的电话会议或视频会议?

2、如何与客户的支持团队协作?
生产或UAT环境的服务器由谁管理?如何交付部署包?客户的测试人员如何进行测试?测试结果如何获取?
运维团队在软件项目中常常被忽视,但他们对产品的成功上线至关重要。通过搭建和维护UAT/性能测试环境,可以尽早地让运维团队参与到项目之中,并且了解部署和日常管理的相关信息,从而使最终的上线变得相对容易。

3、如何与客户的DBA协作?
数据库迁移计划经过DBA复审了吗?DBA是否能获得系统运行时的数据库访问日志?如何与DBA讨论解决数据库相关的问题?
一个好的实践是在每次部署到UAT环境之前将近期的数据库改变总结出来告知DBA,并请他持续关注UAT环境被使用时的数据库日志。如果DBA指出一些明显性能低下或者有其他问题的SQL,应该重视他的意见。

与BA/QA协作

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

主要关注点:

1、Story的内容和工作量估计合理吗?
Story涉及的功能实现起来有多困难?是否有更简单的方式来实现同样的目标?相关的风险大吗?
理论上,工作量估算是由开发者来做的。但有两种原因使得tech lead需要代表开发者来做这件事:(1)找开发者做估算可能打断他们的工作节奏;(2)项目初期可能其他开发者不了解情况,甚至还没有加入项目。同样,如何尽量让所有开发者都感到自己的意见得到尊重,又不过多占用他们的时间,这也是需要平衡的。而代表开发者做估算的准确度也将直接影响tech lead在他们心里的地位。

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

打杂

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

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


欢迎关注
新版技术雷达
各类干货洞见
精选职位招聘
活动预告总结
长按二维码可直接关注我们~

    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存