现代软件开发,人与人在空间上的距离已经越来越明显地发生了范式转移,在可预见的未来和更久远的时候,远程办公都会是一件经常发生或者常态的协同方式。远程软件开发的最小组织单位是远程小组软件开发,把远程小组软件开发的效能做好,软件公司将在空间上解放了一种新的能力:可以在更大区域间完成软件开发的组织和协同工作,提供一种新的效率。
从2021年5月开始,我在C公司开始组建一个远程协作的团队,2022年我又带领多个小组的研发。每个小组能逐渐形成基本以周为单位的研发和版本发布Sprint,在持续的版本发布基础上,远程小组软件开发的效能能一步步获得增益。下文将一些基本的原则和方法写下来,便于参考。
基本原则
远程小组软件开发除了空间上的分布式,基本上还是一个软件开发的过程。所以在软件开发过程中重要的事情还是重要,学习软件工程的基本方法,熟练掌握工具和流程是基本的原则。如何提升软件开发团队效能的软件工程的书有很多,例如《构建之法》《卓有成效的敏捷》是两本不错的书。
核心的基础
但是远程小组软件开发和现场办公又有一些不同的特点。成员之间不在一个地方,团队Leader做好一个核心的桥梁工作,这些基本原则的详细指导在《构建之法》一书里描述微软的工作方法里有提到。
- 小组内部:
- 充分的授权和信任。研发Leader要尽量建立起和团队成员之间的信任,基于信任和持续有效协作的基础上,逐渐建立充分的授权。远程小组软件开发里面,这点也更为重要。
- 各司其职,为共同的目标而奋斗。有了充分的授权和信任,通过sprint敏捷迭代的方式,基于过程性的跟踪和迭代,让每个人做最擅长的部分,各司其职,但是整体目标是聚合的。
- 跨团队协作:
- 团队Leader要做好跨团队协作的协调和组织。每个小组和其他小组的协作即使是在共同办公空间内,也可能存在各种延迟和沟通问题。远程小组软件开发中,团队Leader对于跨小组的协作要保持尽量高效的协调能力。
- 团队Leader要做好团队成员工作的可见性工作。阶段性必要的让团队成员工作展现出来,形成良性的反馈。
工具/工作流
远程小组软件开发的基本工作流没有什么大的差异。但是相对于纯现场办公小组,有一些必要的工作流:
- 明确地使用Jira管理项目开发sprint
- sprint 有两种:
- 固定发版事件的sprint:例如一周一次。例如学习/问答/社区小组是这样的。
- 另外一种是有sprint项目管理,但是项目的交付是随时完成随时发布的。这取决于项目的性质。例如AI小组是这样的。
- sprint 有两种:
- 定期晨会
- 远程小组软件开发,晨会是少有的团队成员碰面讨论的时间点,定期的晨会非常有必要。如何有效开展晨会,见下一节。
- 使用企业微信的日程管理晨会。
- 不定期的团队聚合现场办公
- 以1-2月为单位,不定期的团队全员现场办公,团队Leader可以根据团队的状态判定什么时候需要汇合。
- 汇合工作一般以解决某个关键项目目标为主,同时在共同的现场协作中,完成目标交付也让团队更有凝聚力。
有效的晨会
一日之计在于晨。
通常在一个地方办公的团队,不会注意到远程小组软件开发晨会可能遇到的各种小细节,但是这些细节是否有效把控,决定了晨会的质量,而晨会的质量也决定了团队的共识的质量,进而会影响到团队的效能。以下这些地方是【重要】的事项,展开描述比较啰嗦,实际上就是十几到30分钟到事情。
- 准时:
- 团队成员应该达成一致:尽可能准时参与约定好的定期晨会,因此团队在设定晨会时间点的时候就要考虑好成员出行的缓冲时间。
- 例如AI小组的成员在长沙比较多,基本上能在9:30左右开始晨会,这个时间点会议室也是充足的,其他线上成员也是能准时在线,跨美国时区也不成问题。
- 如果不能及时到到,提前和主持人说下即可。
- 团队成员应该达成一致:尽可能准时参与约定好的定期晨会,因此团队在设定晨会时间点的时候就要考虑好成员出行的缓冲时间。
- 明确的主持人
- 晨会要有明确的主持人,有效控制进度。
- 会议工具
- 使用企业微信的会议,而不是语音通话,会议一般对多人音频传输做了优化,而直接的语音通话有很大的延迟。
- 必要的时候,使用腾讯会议也可以。
- 投屏
- 主持人必须投屏,因为只有音频的话,需要靠人去想象某个人说的上下文,非常费劲,而对着投屏,就多了一个信道,容易建立上下文。
- 使用Jira的Backlog,Sprint和看板。
- 使用看板是非常有必要的,因为看板明确地把小组软件开发的issue分成了TODO,DOING,DONE三种基本的状态,一目了然。
- 因此,无论是成员主动更改状态,还是主持人根据某个issue的实际状态即时拖动项目issue,都是非常有必要的。
- 有很多人开发issue只有两个状态:“TODO”和”DONE”,这样就不能明确地在晨会上看到中间过程,而远程工作中间过程的明确和即时,对于全员建立共识是非常重要的:进度条在前进并且可控。
- 因此,无论是成员主动更改状态,还是主持人根据某个issue的实际状态即时拖动项目issue,都是非常有必要的。
- 主持人在主持过程中,要尽量保持屏幕展示的是正在讨论的具体的issue
- 例如有A/B/C几个issue,当讨论到哪个Iusse的时候,就明确地点击那个issue,让它的细节展示出来。
- 有的人会觉的没必要,而只是鼠标示意下,这样其实对于屏幕另一端的人来说很不友好,所以越是具体的越是好的:
- 明确地点击A,讨论A,编辑A的状态,结束讨论A
- 明确地点击B,讨论B,编辑B的状态,结束讨论B
- ...
- 有的人会觉的没必要,而只是鼠标示意下,这样其实对于屏幕另一端的人来说很不友好,所以越是具体的越是好的:
- 例如有A/B/C几个issue,当讨论到哪个Iusse的时候,就明确地点击那个issue,让它的细节展示出来。
- 使用看板是非常有必要的,因为看板明确地把小组软件开发的issue分成了TODO,DOING,DONE三种基本的状态,一目了然。
- 讨论的流程
- 如果一个晨会包含研发/产品/运营,顺序上一定是:
- 先过研发isseu,控制在最多15分钟内。
- 研发可以撤了
- 先过研发isseu,控制在最多15分钟内。
- 再过产品/运营需求,可以长一点。
- 如果一个晨会只有研发
- 那么时间可以长一点,一个5人左右的小组,控制在30分钟内够了。
- 纯研发长一点是因为可以多一些的沟通/讨论细节,并且主持人要注意控制时间,不能过于发散。
- 必要的技术讨论是程序员之间的沟通语言,也是建立团队凝聚力的组成部分,但是一定要控制节奏。
- 纯研发长一点是因为可以多一些的沟通/讨论细节,并且主持人要注意控制时间,不能过于发散。
- 那么时间可以长一点,一个5人左右的小组,控制在30分钟内够了。
- 如果一个晨会只有研发
- 如果一个晨会包含研发/产品/运营,顺序上一定是:
- 优先级
- 一个高效能的远程小组软件开发,成员的主动性很重要。
- 在有充分授权和信任的基础上,晨会会为每个成员补充必要的backlog,有不同的类型。
- 例如AI组的backlog是流动的:
- 每天会动态增加,但是完成时间由研发人员根据实际情况确定
- 成员的高效也使得我们能在sprint内动态增加可控的Jira
- 因此晨会的一个重要的目标是:确认M又n个任务,那个是P1的?
- 如果是相对固定sprint目标的团队
- 在完成预计sprint目标的基础上才考虑动态增加issue
- 有时候考虑风险,还会根据情况明确地减少issue
- 例如AI组的backlog是流动的:
- 计划外和需求支持
- 主持人需要明确地询问每个人
- 是否有不在列表上的额外事情在做
- 是否遇到卡点,明确的确定需要支持的资源
- 主持人需要明确地询问每个人
- 鼓励
- 每次晨会的结束,主持人也都会明确咨询非直接研发是否有额外的建议
- 作为Leader/Boss要给出明确地给出鼓励,遇到一些团队难点的地方,要有承担地给出* * 拍板的拆分策略。
项目内的工具和文档
项目内有明确的经常更新的文档。包含构架/环境搭建/开发/测试/部署的全套文档,这样减少成员的互相询问。尽量让某个操作是所有人都能通过文档大部分解决的。
提供项目一致的工具和流程。现代软件开发,有很多时间会堵在环境配置上,项目有好的构架和工具,团队开发效率会差异很大,这点没法在这里展开,但是远程小组软件开发里,工具和环境的流畅很重要,需要研发Leader持续的构建。
紧急事件沟通
远程协作,通过企业微信沟通的很多。
- 尽量保持在工作时间范围内的即时响应
- 团队Leader要及时识别某个沟通发生了延迟,及时协调必要的人和资源。必要时直接打电话。
- 每一次有效拆解问题,并解决都是一次好的协作。
远程问题诊断
遇到复杂问题,必要时可进会议室远程投屏共同解决棘手的问题,做诊断和分析(结对编程)
不定期的团队集合办公
必要的时候,团队一起集合办公,以解决某个重要的交付目标为靶点。
构建团队的凝聚力
例如,AI组的成员会不定期写公开博客,介绍某个重要工作的细节。持续共同作出有价值的事情就是构建团队凝聚力的方式。其他时候多交流,重视成员的成长。
小结
本节讨论了远程小组软件开发过程的组织和流程,光有流程是不够的,下一次我们谈谈工具。软件开发,流程和工具是其中两个重要的骨架。
--end--