极客视点
极客时间编辑部
极客时间编辑部
113245 人已学习
免费领取
课程目录
已完结/共 3766 讲
2020年09月 (90讲)
时长 05:33
2020年08月 (93讲)
2020年07月 (93讲)
时长 05:51
2020年06月 (90讲)
2020年05月 (93讲)
2020年04月 (90讲)
2020年03月 (92讲)
时长 04:14
2020年02月 (87讲)
2020年01月 (91讲)
时长 00:00
2019年12月 (93讲)
2019年11月 (89讲)
2019年10月 (92讲)
2019年09月 (90讲)
时长 00:00
2019年08月 (91讲)
2019年07月 (92讲)
时长 03:45
2019年06月 (90讲)
2019年05月 (99讲)
2019年04月 (114讲)
2019年03月 (122讲)
2019年02月 (102讲)
2019年01月 (104讲)
2018年12月 (98讲)
2018年11月 (105讲)
时长 01:23
2018年10月 (123讲)
时长 02:06
2018年09月 (119讲)
2018年08月 (123讲)
2018年07月 (124讲)
2018年06月 (119讲)
时长 02:11
2018年05月 (124讲)
时长 03:16
2018年04月 (120讲)
2018年03月 (124讲)
2018年02月 (112讲)
2018年01月 (124讲)
时长 02:30
时长 02:34
2017年12月 (124讲)
时长 03:09
2017年11月 (120讲)
2017年10月 (86讲)
时长 03:18
时长 03:31
时长 04:25
极客视点
15
15
1.0x
00:00/05:26
登录|注册

高效软件开发团队的4个特质

讲述:初明明大小:4.97M时长:05:26
你好,欢迎收听极客视点。
在一个高效软件团队中工作到底是什么感受呢?最近,开发者丹妮斯·余(Denise Yu)在其个人博客分享了她的经验。丹妮斯·余曾在一些不健康的团队工作过,也曾在一些非常优秀的团队工作过,她总结出高效软件开发团队所具备的 4 个特质,InfoQ 对其进行了翻译,供你参考。

高度的心理安全感

根据我的观察,具有高度心理安全感的软件团队会有以下某些行为:
定期回顾:在“什么进展不顺利?”这一栏里列出适当数量的事项。健康的团队应该能够公开地反省并自我批评,因为每个人都明白,建设性的反馈是为了不断改进。
个人不会在一个问题上花很多时间。他们会有一个或明或暗的“奋斗时间窗”,在这个时间之后,他们会向同伴寻求帮助,他们知道,自己不会因此而得到负面评价。
个人从看得见的输出中分离出他们对团队的价值。在健康的团队中,大家接受这样一个事实:改进是增量的、渐进的,贡献是对团队整体结果的贡献,而不是对特定输出比如代码行数的贡献,表现出来就是“这是我们交付的”,而不是“这是我交付的”。此外,具有高度心理安全感的团队可以讨论价值的含义,以及价值为什么不仅仅是几行代码。
带薪休假时间和病假时间往往会更长,这很有趣。这可能是他们信念的一种体现,他们相信,团队的其他成员可以在他们不在的情况下继续做出正确的决策。

良好的开发规范

我永远不会有一个完整的 GitHub 心智模型。它太庞大了,有太多的逻辑路径,花费过多的时间学习代码的所有部分,并不能使我的工作做得更好。而且,它可能明天就又变了。
因此,当我必须收集足够的上下文信息以实现下一个特性或 Bug 修复时,我会依赖于代码中已有构件的准确性,这些构件是在我之前从事这些工作的人留下的。
良好的软件开发规范意味着需要额外花一些时间来记录当前的上下文信息,这可能表现在:
描述性地提交信息。至少,做到每个提交信息都包含一个动词。有些团队甚至更进一步,要求每次提交都可以跟踪到问题编号。
遵循语言和框架约定、可以表明意图的类名和方法名;
单元测试带有有用的描述信息,使用符合实际的变量名和数据;
在问题跟踪系统中就相关特性反复沟通,而不是在 Slack DM 和其他地方。今后,入职不满 6 个月的团队新成员将无法访问这些地方。
最后,良好的开发规范事关同理心。工件越整洁,团队成员就可以越快地了解上下文,花在上下文切换和探查上的认知精力也就越少。

主动重新分配“经验点”

在一个角色扮演游戏《火焰徽章》中,组建军队的方式和组建均衡的软件开发团队之间有很多相似之处。
在游戏中,我拥有自己的核心团队,我非常喜欢将所有角色都均衡升级。如果我获得了一个等级较低的新角色,但他有一套技能或亲和力可以给队伍做补充,我就会给他升级,这样他就可以在地图上到处移动而不用担心敌人的攻击。如果我的角色一开始就有一个很高的等级,我就会避免让他们与较弱的敌人战斗,因为这只会占用经验点,而这些经验点会让我的低等级角色受益更多。
我倾向于认为,软件团队中也存在类似的原则。如果你的团队里已经有很多优秀的开发人员,那么你应该注意,不要总是只安排他们去处理困难的工作。在健康的团队中,上下文再分配也是他们工作的一部分,这样一来,一个缺乏经验的工程师也可以获得一些有价值的经验点。如果每个人都觉得自己至少在某种程度上具备了应对任何挑战的能力,那么这将提高整个团队的生产力和士气。

慷慨大方的交流

同事之间慷慨大方的交流意味着,我们假设任何时候任何人问问题时:
已经做了基本的研究,如已经用谷歌进行了搜索;
或者他们是因为在任何地方都无法找到答案才找人问。因为这个地方很难找,或者根本不存在。
在慷慨的互动中,给出答案之前,回答者会确认他们对问题的假设,进而核实提问者的上下文层级和意图。采用慷慨的交流方式有非常积极的影响:首先,注意到交流时所使用的词汇减少了吗?他们实际上可以更快地得到答案。其次,没有产生不必要的摩擦。两个人团结一致消除了不确定性,而不是纠结于每个人知道多少,如果是后者,也许最终他们也可以得出答案,但同时也失去了一些信任和善意。
以上就是今天的内容,如果你有在高效软件开发团队工作的经验,或者花时间做过这方面的研究总结,欢迎留言你的感受和想法。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结
该免费文章来自《极客视点》,如需阅读全部文章,
请先领取课程
免费领取
登录 后留言

全部留言(1)

  • 最新
  • 精选
  • li3huo
    如果有一个经常摸鱼的人就很难维持这种氛围了
收起评论
大纲
固定大纲
高度的心理安全感
良好的开发规范
主动重新分配“经验点”
慷慨大方的交流
显示
设置
留言
1
收藏
43
沉浸
阅读
分享
手机端
快捷键
回顶部