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

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

从2021年5月开始，我在C公司开始组建一个远程协作的团队，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--