远程小组软件开发过程(1):流程

现代软件开发，人与人在空间上的距离已经越来越明显地发生了范式转移，在可预见的未来和更久远的时候，远程办公都会是一件经常发生或者常态的协同方式。远程软件开发的最小组织单位是远程小组软件开发，把远程小组软件开发的效能做好，软件公司将在空间上解放了一种新的能力：可以在更大区域间完成软件开发的组织和协同工作，提供一种新的效率。

CSDN 本身就在北京/长沙之间有两个大的研发团队，即使不考虑少数的个体远程办公，北京和长沙之间的团队协作也是一种远程软件开发过程。因此，我们就更有理由总结远程软件开发过程的经验和有效做法，从中提炼有效的方法，减少空间距离带来的阻力，发挥空间自由带来的效率，从而为软件研发建立坚实的基础。

从2021年5月开始，CSDN AI 小组从组建开始就是一个远程协作的团队，2022年我又带领学习业务研发、社区和问答的小组研发。每个小组能逐渐形成基本以周为单位的研发和版本发布Sprint，在持续的版本发布基础上，远程小组软件开发的效能能一步步获得增益。下文将一些基本的原则和方法写下来，便于参考。

基本原则

远程小组软件开发除了空间上的分布式，基本上还是一个软件开发的过程。所以在软件开发过程中重要的事情还是重要，学习软件工程的基本方法，熟练掌握工具和流程是基本的原则。如何提升软件开发团队效能的软件工程的书有很多，例如《构建之法》《卓有成效的敏捷》是两本不错的书。

核心的基础

但是远程小组软件开发和现场办公又有一些不同的特点。成员之间不在一个地方，团队Leader做好一个核心的桥梁工作，这些基本原则的详细指导在《构建之法》一书里描述微软的工作方法里有提到。

小组内部：
- 充分的授权和信任。研发Leader要尽量建立起和团队成员之间的信任，基于信任和持续有效协作的基础上，逐渐建立充分的授权。远程小组软件开发里面，这点也更为重要。
- 各司其职，为共同的目标而奋斗。有了充分的授权和信任，通过sprint敏捷迭代的方式，基于过程性的跟踪和迭代，让每个人做最擅长的部分，各司其职，但是整体目标是聚合的。
跨团队协作：
- 团队Leader要做好跨团队协作的协调和组织。每个小组和其他小组的协作即使是在共同办公空间内，也可能存在各种延迟和沟通问题。远程小组软件开发中，团队Leader对于跨小组的协作要保持尽量高效的协调能力。
- 团队Leader要做好团队成员工作的可见性工作。阶段性必要的让团队成员工作展现出来，形成良性的反馈。

工具/工作流

远程小组软件开发的基本工作流没有什么大的差异。但是相对于纯现场办公小组，有一些必要的工作流：

明确地使用Jira管理项目开发sprint
- sprint 有两种：
  - 固定发版事件的sprint：例如一周一次。例如学习/问答/社区小组是这样的。
  - 另外一种是有sprint项目管理，但是项目的交付是随时完成随时发布的。这取决于项目的性质。例如AI小组是这样的。
定期晨会
- 远程小组软件开发，晨会是少有的团队成员碰面讨论的时间点，定期的晨会非常有必要。如何有效开展晨会，见下一节。
- 使用企业微信的日程管理晨会。
不定期的团队聚合现场办公
- 以1-2月为单位，不定期的团队全员现场办公，团队Leader可以根据团队的状态判定什么时候需要汇合。
- 汇合工作一般以解决某个关键项目目标为主，同时在共同的现场协作中，完成目标交付也让团队更有凝聚力。

有效的晨会

一日之计在于晨。

通常在一个地方办公的团队，不会注意到远程小组软件开发晨会可能遇到的各种小细节，但是这些细节是否有效把控，决定了晨会的质量，而晨会的质量也决定了团队的共识的质量，进而会影响到团队的效能。以下这些地方是【重要】的事项，展开描述比较啰嗦，实际上就是十几到30分钟到事情。

准时：
- 团队成员应该达成一致：尽可能准时参与约定好的定期晨会，因此团队在设定晨会时间点的时候就要考虑好成员出行的缓冲时间。
  - 例如AI小组的成员在长沙比较多，基本上能在9:30左右开始晨会，这个时间点会议室也是充足的，其他线上成员也是能准时在线，跨美国时区也不成问题。
- 如果不能及时到到，提前和主持人说下即可。
明确的主持人
- 晨会要有明确的主持人，有效控制进度。
会议工具
- 使用企业微信的会议，而不是语音通话，会议一般对多人音频传输做了优化，而直接的语音通话有很大的延迟。
- 必要的时候，使用腾讯会议也可以。
投屏
- 主持人必须投屏，因为只有音频的话，需要靠人去想象某个人说的上下文，非常费劲，而对着投屏，就多了一个信道，容易建立上下文。
- 使用Jira的Backlog，Sprint和看板。
  - 使用看板是非常有必要的，因为看板明确地把小组软件开发的issue分成了TODO，DOING，DONE三种基本的状态，一目了然。
    - 因此，无论是成员主动更改状态，还是主持人根据某个issue的实际状态即时拖动项目issue，都是非常有必要的。
      - 有很多人开发issue只有两个状态：“TODO”和”DONE”，这样就不能明确地在晨会上看到中间过程，而远程工作中间过程的明确和即时，对于全员建立共识是非常重要的：进度条在前进并且可控。
  - 主持人在主持过程中，要尽量保持屏幕展示的是正在讨论的具体的issue
    - 例如有A/B/C几个issue，当讨论到哪个Iusse的时候，就明确地点击那个issue，让它的细节展示出来。
      - 有的人会觉的没必要，而只是鼠标示意下，这样其实对于屏幕另一端的人来说很不友好，所以越是具体的越是好的：
        
        明确地点击A，讨论A，编辑A的状态，结束讨论A
        
        明确地点击B，讨论B，编辑B的状态，结束讨论B
        
        …
讨论的流程
- 如果一个晨会包含研发/产品/运营，顺序上一定是：
  - 先过研发isseu，控制在最多15分钟内。
    - 研发可以撤了
- 再过产品/运营需求，可以长一点。
  - 如果一个晨会只有研发
    - 那么时间可以长一点，一个5人左右的小组，控制在30分钟内够了。
      - 纯研发长一点是因为可以多一些的沟通/讨论细节，并且主持人要注意控制时间，不能过于发散。
        
        必要的技术讨论是程序员之间的沟通语言，也是建立团队凝聚力的组成部分，但是一定要控制节奏。
优先级
- 一个高效能的远程小组软件开发，成员的主动性很重要。
- 在有充分授权和信任的基础上，晨会会为每个成员补充必要的backlog，有不同的类型。
  - 例如AI组的backlog是流动的：
    - 每天会动态增加，但是完成时间由研发人员根据实际情况确定
    - 成员的高效也使得我们能在sprint内动态增加可控的Jira
    - 因此晨会的一个重要的目标是：确认M又n个任务，那个是P1的？
  - 如果是相对固定sprint目标的团队
    - 在完成预计sprint目标的基础上才考虑动态增加issue
    - 有时候考虑风险，还会根据情况明确地减少issue
计划外和需求支持
- 主持人需要明确地询问每个人
  - 是否有不在列表上的额外事情在做
  - 是否遇到卡点，明确的确定需要支持的资源
鼓励
- 每次晨会的结束，主持人也都会明确咨询非直接研发是否有额外的建议
- 作为Leader/Boss要给出明确地给出鼓励，遇到一些团队难点的地方，要有承担地给出* * 拍板的拆分策略。

项目内的工具和文档

项目内有明确的经常更新的文档。包含构架/环境搭建/开发/测试/部署的全套文档，这样减少成员的互相询问。尽量让某个操作是所有人都能通过文档大部分解决的。

提供项目一致的工具和流程。现代软件开发，有很多时间会堵在环境配置上，项目有好的构架和工具，团队开发效率会差异很大，这点没法在这里展开，但是远程小组软件开发里，工具和环境的流畅很重要，需要研发Leader持续的构建。

紧急事件沟通

远程协作，通过企业微信沟通的很多。

尽量保持在工作时间范围内的即时响应
团队Leader要及时识别某个沟通发生了延迟，及时协调必要的人和资源。必要时直接打电话。
每一次有效拆解问题，并解决都是一次好的协作。

远程问题诊断

遇到复杂问题，必要时可进会议室远程投屏共同解决棘手的问题，做诊断和分析（结对编程）

不定期的团队集合办公

必要的时候，团队一起集合办公，以解决某个重要的交付目标为靶点。

构建团队的凝聚力

例如，AI组的成员会不定期写公开博客，介绍某个重要工作的细节。持续共同作出有价值的事情就是构建团队凝聚力的方式。其他时候多交流，重视成员的成长。

小结

本节讨论了远程小组软件开发过程的组织和流程，光有流程是不够的，下一次我们谈谈工具。软件开发，流程和工具是其中两个重要的骨架。

–end–