如果您从事软件工作,这对您来说可能很熟悉:一个工程团队的任务是从头开始设计和构建一个大型的、高度可见的产品或系统。这个团队主要由不太懂制度的新工程师组成,技术领导在这个特定领域没有太多经验。然而,有一个拥有领域知识和一些临时可用性的高级工程师。他们最有效的帮助方式是什么?

以下是这往往是处理:高级工程师进来帮助,但大部分工作本身。他们写一吨的新代码。这是写得很好,但国外的球队,谁没有任何了解为什么任何决定作了 - 他们看到它的完成状态的代码,而不是过程到那里。该代码被移交,现在是他们拥有和维护。他们刚刚成交缺乏的领域专业知识,在自己的代码库知识的缺乏。

让我们回到高级工程师来的时候。如果他们不是编写所有的代码,而是在整个过程中指导团队呢?他们成为团队的一员有几个月的时间,帮助创建票据,提供架构建议,并参加日常的结对编程会议。所有的代码都是团队自己写的,所以最后不会有交接。他们从上到下理解新代码,而且他们在编写代码方面更熟练。他们不仅能够更好地着手下一个项目,还可以成为其他开发人员的资源。与此同时,高级工程师一直在获得实际的反馈,以帮助改进跨组织使用的平台工具,避免平台上的“象牙塔”心态。

这是辅助工程“与工程团队合作,提高他们的速度,建立持久的质量文化。”我们从一个团队走到另一个团队,花足够的时间来帮助开发人员在开发MVP时养成习惯。

这个想法是大约3年前由乔纳森·比德尔亚历克斯Truslow在Python平台团队中,前端平台在一年后采用了该模型。从那时起,PHP,测试支持,和合作伙伴之家平台也开始了Eng团队,到目前为止,我们已经完成了几十个项目,取得了压倒性的积极成果。

我所介绍的概念在所有的辅助工程团队中都是共享的,尽管这些经验来自于我对Frontend Aux Eng的观点,主要关注于JavaScript和React。我已经进行了一年多的嵌入(或约定),与我的团队和其他Aux Eng团队重复这个过程。这是对工程师和工程文化的投资。它在实践中是什么样子的?继续读下去!

是什么造就了一名业余工程师?

我们自称是“渴望学习的谦逊专家”,我们都是平等的工程师、教师、导师和教练。不要说“你的工作做得不够好”,我们说:“让我们把你的技能提升到一个新的水平。”“我们在那里支持和提高Wayfair的工程组织的技能。

我们把大量的笔记,并以完善平台寻求关键的反馈。我们的约定给了我们一个独特的机会,使平台工具更好地使用它们的开发者。而不是假设我们正在构建合适的工具用于团队,我们使用这些工具直接和感觉痛点自己。这种做法导致我们的一些最大的平台,胜裸露的机会。

一个辅助工程师需要在他们的领域有深入的技术知识,平衡人际技能和过程管理。我们坚信成长心态,并且我们使用定期的回顾来获得反馈并发现我们的盲点。

嵌入看起来像什么?

前:审查程序

让团队主动联系我们(而不是我们主动接近他们)是很重要的,这样我们就知道他们与我们的流程一致。他们应该知道他们想从契约中得到什么,即一个可交付的和一组更熟练的开发人员。在团队为他们将要构建的项目提交提案之后,我们在向团队做出承诺之前会经历一个面试阶段,以确保我们的目标和时间线是一致的。我们根据一系列标准评估项目,包括:

  • 商业价值产品本身是否提供可衡量的价值?
  • 技术价值- 是项目战略的平台和工程组织?
  • 可交付成果-在项目结束时我们要展示什么?
  • 时间轴-严格的期限并不理想,养成习惯需要时间。我们希望确保关注的是不断成长的开发人员,而不是匆忙推出产品。

我们也希望能见到个别的开发人员,确保他们都参与进来。我们将与他们进行最密切的合作,因此得到他们的支持是很重要的。

一旦我们接受了建议,并两队都同意一个共同的目标文件,我们就关闭和运行!每个人都有自己的工作流程,所以有一个推广期,我们熟悉每一个开发者和他们的过程。我们移动到它们的空间和工作有充分的时间周一至周四。周五我们回到平台团队写了笔记,为下周做准备,并纳入任何可行的反馈到工具或文档。

期间:什么队报名

来自JS专家的知识转移很明显,有一个常驻JS专家在手边可以大大提高团队的开发速度。更少的搜索堆栈溢出,更少的梳理内部文档。但是有一个现场JS专家的真正价值是你得到的不仅仅是答案。我们将提供更深入的理解,并帮助开发人员在工作时构建一个健壮的心智模型,这有助于在我们离开后保持熟练程度。

前期软件设计- 嵌入功能有3个月的长期承诺。该团队正在建设一个新产品的MVP,所以软件设计是重中之重。这些都是将维持或许未来几年的应用程序,所以我们强调干净的灵活设计。该产品的需求将演变,所以我们考虑到这一点设计 - 最终的设计是从来没有真正的决赛。我们认识到,我们无法预知一切,我们允许实现本身提供反馈到初步设计。

我们还帮助门票估计,确保:

  • 所有开发人员都要参与评估
  • 我们给出的是比例输入,而不是估算
  • 票证有一个定义良好的范围和验收标准
  • 单元/集成测试包含在每个功能票据中

结对编程-与团队合作意味着我们可以通过合作传递很多知识结对编程。我们主要是这一对的领航员,也就是说,我们解释我们要完成什么,他们写代码。当他们对新话题更加熟悉时,我们的指导就变得不那么明确了,他们更喜欢诱导性的问题而不是直接的回答。

这是搬运重物的地方,对我来说这是最有趣的部分。结对是高度动态的,因人而异。有一些社会导航需要碰巧使它对每个人都有生产力。我喜欢这部分参与带来的挑战和回报。

自动化测试-我们的要求之一是团队同意将编写测试作为流程的一部分。我们认为自动化测试是健康代码库中不可分割的一部分,由于许多团队没有将测试集成到他们的工作流程中,我们很清楚,当开发人员学习工具并进入测试流程时,这会导致短期的速度下降。

这一切都是为了“从慢到快”,虽然写代码_and_测试会加快速度是违反直觉的,但它能工作是因为“速度取决于稳定性”。在我们的指导下,将测试添加到工作流中,开发者和涉众都看到它提高了速度,并将经过良好测试的代码嵌入到流程中。它让开发者对自己的应用程序充满信心,并有信心做出改变。根据我们的经验,测试可以使代码更容易重构,并在将其投入生产之前帮助查找错误。我们经常会听到这样的话:“直到测试失败,我才知道这些事情会相互影响!”

小,频繁的部署这主要是为了减少开发人员和审查人员的认知负荷。对于开发人员来说,小规模的频繁部署意味着部署单个特性,或者进行一些独立的更改——甚至只是一个!类似于单一职责原则,只部署一件事可以更清楚地说明部署的影响。更小的PRs意味着更少的审查疲劳,对变更更直接的理解,以及更快地捕获和修复错误。

住代码评审- 我认为学习和在一个团队工作的最重要的工具代码审查之一。这样做直播是传播最佳实践,做出决定作为一个团队,以及模型留下评论时所需的软技能的绝佳方式。我已经得到了一些伟大的见解看着领域的专家通过审查走,所以这让我得以传承的经验。我们设置了一些基本规则,强调心理安全,例如“假设最好的意图,”和“仿佛笔者在房间评论(他们可能是!)”。没有人试图撕毁任何人失望。初级开发者可以从具有更高级的开发者审核他们的代码学习,而是通过翻转比较初级的人会接触到的模式,他们可能没有看到,否则角色(和可能赶上一些错误呢!)

现场代码审查也使我们有机会,包括邻近的团队,扩展我们的可达我们一般用不超过5个开发团队的工作。我们获得满足邻国的团队成员,并让他们知道我们也可以作为他们的一个资源时,我们有额外的带宽。

之后:与团队建立持久的关系

我们通过推出一款成功的产品来衡量成功,但也通过长期的代码质量和习惯来衡量。在每个嵌入后,我们设置了3个月的检入:

  • 他们对代码的维护有多满意
  • 他们能保持速度吗
  • 这些测试是如何起作用的,或者是否造成了摩擦

因为我们所关注的度量标准并不总是即时的,所以我们渴望得到批评,并寻找我们可以改进和暴露盲点的地方。我们希望在嵌入过程中得到尽可能多的反馈,以改善我们正在做的事情的长期效果。

赢,赢,赢了

主机团队从契约中得到最明显的好处,但是辅助工程模型的好处是全面的。

主机团队如何获益

  • 软件架构
  • 扩展对具有深入领域和机构知识的平台工程师的访问
  • 养成持久的习惯——编写测试和小而频繁的部署。
  • 接触新的模式和技术

公司如何获益

我们就像聘请了顾问,但在工程组织的长期健康发展的既得利益。

  • 健康的整体代码库
  • 更多的测试覆盖率
  • 最佳实践的交叉授粉
  • 增长我们的开发人员
  • 为平台提供实际反馈,以确保我们在为开发者提供合适的工作

AuxEngineer如何获益

这项工作是嵌入式开发令人兴奋的挑战。这是一个强烈的经验,被预计将在广泛的议题和技术的常驻专家。

  • 对特性团队和平台团队都有影响
  • 使用代码基的许多不同部分
  • 作为教练/导师的奖励
  • 直接影响业务
  • 高挑战,高增长

有几件事情我已经学会

心理安全是成功的关键

最重要的会议是与每个开发人员一对一的非正式介绍。就我的个人过程而言,我喜欢了解他们的背景,他们想要从事或学习的任何具体内容,以及他们的乐趣所在。我们的一个既定目标是与这些团队建立持久的关系,这从信任和心理安全开始。让人们知道我们在那里帮助和支持他们是很重要的。

其中有一个问题我经常得到的是“怎么这么开发商对你的感觉在那里?”在我所有的埋件我从来没有觉得什么,但欢迎,我的属性,建立信任出了大门。

我的工作不是什么都知道

专家知道的想法一切是有害的几个原因。其一,这是不现实的 - 没有人知道一切的一切。也许,更重要的是,这种心态假定知识是静态的。它加强的想法,即使是专家总是在学习和成长是很重要的。

我的工作想办法弥补你知识上的不足。如果我在同一领域有知识缺口,那么我的工作就是填补这个缺口,为你消除障碍。这可能意味着研究,找一个知道的人,或者自己开发一个解决方案。

随着时间的推移,我发现,对开发人员来说,看着你解决一些你不知道的问题实际上更有帮助,尽管这会让你很不舒服。它表明,即使是高级开发人员也有知识缺口,并拉开了我自己调试或解决未知问题的过程的帷幕。

我们对过程有独特的看法

Wayfair上有几十个工程团队。通过与来自组织中所有不同部分的团队合作,我们对所有不同类型的流程都有了广泛的了解。我们可以看到什么有效,什么无效,并且我们可以交叉授粉最佳实践和过程改进。

给一个人一个答案,然后你用一天时间解开他们的思绪……

我总是不得不克制直接给出答案的冲动。我不得不提醒自己,我们的使命是长期可持续发展,给开发者一个答案只会在当下有所帮助。更有效的方法是问一些指导性的问题,帮助开发人员自己找到解决方案。得到自己的答案更有意义,也更有可能坚持下去。

技术支持支持

辅助工程可以是一个强烈的经验,所以我们彼此依靠的支持。我们是一个团队的半游牧民族,所以它经常相互重新连接是非常重要的。我们嵌入周一至周四,然后返回“家”为平台团队周五至汇报彼此。

制作一个退出

因为我们只有每个团队几个月,我们有一个很短的时间,以提升他们的技能,让他们更加自给自足,当它的时候了。成功的标志是,当我们能够从过渡东道主球队的地步顺利离开,他们几乎没有注意到我们都走了,像荷马褪色钻进了灌木丛。与大人们的经历后离开是苦乐参半,但在有限的时间使我们更加专注于互动。当它已经结束了,没有什么比看到一个成功推出,看到工程师有较高的影响,往往是对别人的资源更有价值。

你可以雇佣专家,也可以培养他们。对于像Wayfair这样规模的公司来说,有大量潜在的专家,从我在这里看到的情况来看,很多人都有提升自己技能的动力。辅助工程是一种积极主动、亲力亲为的方式来投资我们的开发人员,培养我们自己的专家,并不断提高标准。

感谢您对这篇文章对您的宝贵意见:

弗朗索瓦•沃德

艺术Buldauskas

亚历山大•布林

乔纳森·比德尔

图片由Marvin Meyer https://unsplash.com/license