如何为您的软件开发团队重构和创造新生命

我们的一位客户最近派出了他的大部分海上团队(由我们在乌克兰托管)来进行为期两天的外部Scrum培训。 当大多数团队成员都参加培训时,客户的开发负责人(我们称他为John)与那些留在办公室的人一起度过了一段时间,并表达了他的团队重构构想, 这是使团队更加投入和提高效率的新方法

“所以,伙计们,您想让我告诉您有关开发商天堂的童话吗?”约翰一边抽烟,一边抽烟。 团队的其他成员在我们敖德萨办公室夏季露台上非常热的时候懒洋洋地点了点头。 说完这将是一个长期的故事,约翰沉浸在他的Balkan Delight烟云中,开始了。

“我们有50多个开发人员分布在全球各地,而且我们倾向于在所有地点都保持敏捷。 但是,我们仍然时不时地在该项目上做文章! 在乌克兰,我们开始时只有10个人组成的团队,早期阶段看起来像是我们必须摆脱的自组织混乱。 随着我们在所有地区的发展,并成为一支由全球DevOps推动的,由50多人组成的跨境团队,我们采用了Waterfall模型,因为它可以更好地满足我们的项目要求。 但是没人愿意为Waterfall做好准备,因此我们为团队的方便实施了Scrum。 情况似乎有所改善,但是仍然存在一些对项目所涉及的每个人都显而易见的问题。 问题之一是我们的几个协作团队之间缺乏适当的沟通。 测试人员不能正确测试,初级人员不能很好地进行初级开发,而设计师陷入微管理的泥潭,变得如此缓慢,以至于开发人员无法在数周内继续执行任务!

你们都知道,无论采用哪种方法,都必须完成我们的项目任务,不是吗? 无论是Waterfall,Agile还是XP,它们的数量和质量要求都将保持不变。 因此,Scrum和Waterfall都无法替代我们的常识。 如果生产着火了,我们将不得不扑灭它。 如果遗漏了一些东西或搞砸了,我们自然会退出流程并失去完整性。 而且,随着我们的支持任务随着我们应用程序用户群的增长而增长,您不能拒绝与您的PM进行通信,也不能摆脱我们的技术债务。 确保这种增长是我的首要任务之一! 话虽如此,Scrum和看板都无法将我们从所有这些混乱中解救出来。 系统无法关闭; 它们像任何生物一样呼吸

考虑到我们每个人都想发展和成熟,编写更好,更简洁的代码并处理更具挑战性的任务这一事实,我们需要重构团队以使其正常运行!”

发表此声明后,John环顾四周,看到来自我们其他团队的另外10个人加入并引起了所有人的注意。 约翰深吸了巴尔干的喜悦,然后继续说:

“您知道TCP和UDP之间的区别,不是吗? 尽管UDP更适合于流传输,但是它不能保证传递。 因此,隐喻地说,我希望您结合使用TCP和UDP来显着提高新功能的交付速度。

我们每个分散的项目团队都有一个团队负责人,这个角色通常分配给我们的一名高级开发人员,这些高级开发人员依次向我自己报告[开发负责人],而我向我们的CTO报告。 另外,我们还有其他随机的人,他们总是中断流程并希望进行更改。 一方面,我们所有的软件开发人员似乎都在忙于完成他们的任务,但另一方面,总是有很多人坐在板凳上,而他们却忙于工作或中断驱动的问题解决。 因此,我们的大多数项目都是由于我们作为客户的流程无法在一开始就在我们的组织中正确设置而发生的。 说到这个过程,我们似乎已经制定了一个办法,但是并不能解决很多问题。 关键问题之一是- 当您要编写代码时,由于中断而无法编写代码;而当您可以编写代码时,由于您已经厌倦了解决中断驱动的问题,就不想编写代码了 。”

“那么,您在这里提供什么解决方案?”我们的一位开发人员最后问。

“团队重构 ,” John回答。

“简而言之,我建议团队的结构应采用不同的方式。 团队负责人不能领导团队,因为这是一个高级人员,其能力和经验是项目成功所必需的,并且其时间过于昂贵,无法花费在团队管理上。 如果我们将这个角色分配给或多或少的优秀中级开发人员,甚至是潜在的初级开发人员,该怎么办? 您有想过吗?”

露台上的家伙们看着对方,想知道约翰刚刚通过烟斗抽了什么烟才想到了这个主意。 但是约翰进一步解释了他的想法:

“如果我们重构并重新定位团队管理流程,该怎么办? 自己看看:高级开发人员的生产力要比初级或中级开发人员的生产力高得多。 当然,并不是所有的高级人员都真正想自己编写代码,但是普通的高级开发人员确实希望每天交付代码! 这很容易解释-您今天要做的工作越多,明天得到的奖金就越多。 但是,由于每天都要处理大量的微型管理麻烦(例如,指导初级人员,帮助同事完成任务,与客户沟通等),因此没有任何高级开发人员可以负担得起仅仅编写代码的费用。 因此,在交付真正优质产品方面,高级开发人员实际上是您的关键资产。 然后,我们缺少能力和经验丰富的人来成长和升级。 他们是中级开发人员,通常缺乏高级团队成员的帮助,也缺乏对公司经理的适当尊重。 中级人员很少像高级同事那样了解流程。 但是我坚持认为高级开发人员不应领导团队 ! 他们应该进行编程和开发,做出决策并对这些决策负责,而中级开发人员可以管理团队合作

我的赞成论点是:

  • 他们越深入到过程中,就越能理解它们。
  • 为了进行适当的管理,中级开发人员将不得不提出很多问题,随着时间的流逝,这些问题将得到完善和调整,以使其成为正确的问题。
  • 中级开发人员比高级开发人员(大多数人只在乎薪酬)更具有工作动力和智慧。
  • 他们将有很好的机会从自己的失败和失败中吸取教训,这总是使我们在做事时变得更强大和更有能力。

如果一切都按照我的计划进行,那么明年我们的本地高级开发人员至少将是今年的两倍。 两年来我们一直没有改变我们的IT招聘方法,这对项目不利。 我们专注于招聘一流的高级开发人员,并每六个月增加预算,而初级人员要花很长时间才能成为中级开发人员,而中级开发人员很少会转换为我们项目的高级开发人员。 发生这种情况是因为我们无聊又疲惫的高级开发人员使他们承担了不清楚,常规和非关键任务的重担,这使他们无法成为高级人。

然后,约翰面对了我们的高级开发人员伊戈尔:“伊戈尔,想象一下每周能够进行30-40个小时的编码,而不是现在的20个小时! 您仍然必须每周工作60多个小时,才能完成我们为您提供的所有超出常规范围的繁琐任务。”

伊戈尔(Igor)对此表示同意,因为他只看到家人最近入睡,并且梦想着早日回家。 同时,John看着我们的中间开发人员Oleg。

“奥列格,想像一下伊戈尔的团队领导。 如果您的工作不那么常规,您是否会变得更加投入和富有成效? 您将能够从背后看到Igor的代码,并了解其背后没有特殊的高级魔术 。”

奥列格的眼睛激动得发亮。 五分钟前,他甚至无法想象自己会成为Igor的领导者。 他非常喜欢这个主意!

现在,约翰转身去看望我们中级质量检查工程师拉娜。

“拉娜,想像一下最终能够了解我们业务流程的所有来龙去脉,以便您的测试人员可以获得质量代码,并为在生产中发现并消除的所有新错误提供薪水奖励。”

拉娜也很高兴,因为现在她知道自己的工作出了什么问题。 在该项目上,她与时髦的前端开发人员(高级)Mark密切合作,后者始终提供高质量的代码。 但是问题在于,他几乎没有时间自己编写代码,并将大部分编码工作外包给了中小型同事,同时帮助市场营销为UI设计师准备了规范(他完全了解UI设计!)。 他忙于沟通和其他事情,很少有时间进行适当的代码审查。 当整个团队都崇拜马克时,Lana遭受了痛苦,因为他留下了许多她发现的无人看管的错误,这阻止了整个团队的前进。

尽管感到疲倦,但他们当晚都无法入睡。 第二天早上,他们都在露台上见面,以确定新的团队结构并创建新的备忘录,并将其粘贴到Scrum董事会上:

团队负责人=团队经理

团队经理=中级开发人员

高级开发人员=代码负责人

你喜欢我的文章吗? 如果您这样做了,请鼓掌并分享! 祝你有美好的一天!