前言

前两天分享了远距工作的好处与挑战，今天针对应用面来谈谈 Scrum 活动如何在远距工作的情况下执行。

在开始前，再做点补充。我认为远距工作是个机会，纵使它还有不少问题需要克服，事情不总是非黑即白的，希望大家可以多方尝试，为团队找到一个全新的样貌。

选择远距工作不该只是被动因为疫情所迫，它完全可以是一种主动的选择。能否顺利执行，也与团队的文化及能力有相当大的关系。

远距前的准备动作

在切入 Scrum 活动前，还是简单提一下远距工作实行前的注意标的，您可以把它作为一份概略上的检核表，并一一思考应对方案。

心态调整

执行远距工作不会是个人的事情，必须是全团队进入状况。每位成员需要调整自己的「心态」，因为工作模式产生很大的变革，如同在「远距工作停看听：挑战篇」所提到的冲击。

在心态方面，我们可以注意以下项目，并附上前些日子的铁人赛文章作为参考：

• 享受自由，互相信任 (参考「信任与安全感」与「远距工作停看听：好处篇」)
• 团队需展现高度自我管理能力 (参考「管制与自我管理」)
• 目标导向 (参考「远距工作停看听：挑战篇」)
• 保持学习与分享 (参考「冲刺之外的学习」与「学习成长」)

制度建立

我们知道，当团队高度自主时，需要的制度是很少的，但并非所有团队都拥有这般能力，而且除了团队内部，与外部的协调仍然需要制度作为标准。

这可能包含：

• 每日工作流程
• 会议执行方式 (使用什麽工具、跑什麽流程)
• 文件签核流程 (电子化为佳)
• 人员招募方式、聘用流程、到职流程
• 紧急人员调度方案
• 考绩方式调整
• 线上/线下聚会的可能性与相关辨法
• 远距教育训练辨法

基础设施

为了支持日常开发，团队通常会依赖不少基础设置，在进行远距工作前也需要确认，这可能包含：

• 考虑将基础设施移交云端
• 远距连线的安全性议题
• 内部服务是否能让各地成员顺利存取
• 原辨公室设备(如果有)，专人维护的安排
• 团队成员本身的设备是否足够，例如电脑、萤幕、收音设备，需先事先进行调查，亦可准备补助方案

敏捷素养

团队的敏捷素养必须继续保持，特别是：

• 透明度的展现程度
• 回顾更不能少

这样看下来真够大家忙了，甚至不是单一团队的事情。

Scrum 远距进行的工具

接下来以我的经验，分享如何以远距的方式执行 Scrum 活动。

作为重点共通项目「沟通」，它将偏及所有 Scrum 活动，读者可以参阅之前分享过的「沟通这回事：工具软件篇」，以下小章节就不再特别提起。

Daily Scrum

每日的例行会议将改用线上会议工具进行，这可能没什麽特别，团队成员约好固定的时间上线，并完成讨论，在这个过程中建议打开镜头，以增加临场感。

另一种被称为非同步 Dialy (Asynchronous Daily) 的概念也可以考虑，目前也有一些工具可以支援，例如：Range、Status Hero 与 DailyBot 等，虽然它是以文字行式进行，与常规的 Daily Scrum 的精神有些冲突，但也正是文字具备可保存的效果，事後查阅是相当容易的。

Sprint

冲刺本身充满各式各样的软件开发工作，除了基本的通讯软件，原本在实体场域中容易进行的 Pair / Mob Programming 现在也必须借助工具来实现。

以 Pair 来说，我目前用过 CodeTogether 觉得还不错，设定方便，成员可以很快上手，且支援的 IDE 或编辑器符合团队需求，这部份就需要团队自行评估了。

Planning / Review

Planning 会议仰赖线上会议工具，若团队会采用 Planning Poker 则需要如 Pointing Poker
的工具来辅助。线上出牌工具还有许多，我选择它是因为干扰最少、操作直觉，也不需要注册，团队应该可以很快上手。不过在开房前，要注意一下它预设的 Poker 点数是否与团队习惯的一致，若不同则要先手动调整。而它也可以发起一个 Retrospective Session，应用在回顾会议，但目前尚未在团队内应用。

Review 的部分则一样透过线上会议工具来完成，但需要注意展示环境的网路连线是否能顺利存取，避免无法在线上会议室进行展示。

Retrospective

回顾会议由於需要较强的引导活动，因此特别拿来谈。

团队可以尝识 Zoom 的注记功能，搭配在空白投影片上进行文字的撰写、画笔线条、盖章等，增加即时互动性，让成员更有参与感。当然，团队也可以选择透过如 miro 这样的线上白板服务来进行回顾会议。

另外「分组讨论」也是个实用的功能，若您选择的会议工具有支援，可以尝试看看，针对特定议题请团队成员分组 (建议 3 人一组，避免资讯过於偏颇或难以形成共识)，讨论後再进行统整，对於讨论效率上有不错的提升。

Board

作为最有感的可视化看板，现在也必须数位化了。以常见的工具而言，Trello 会是个轻量化的选择，但由於缺乏纵向分隔的能力，可能会使得 PBI (故事) 卡片与任务卡片出现视觉上的混淆，卡片本身也较缺乏结构化的资料栏位，可能不利统整。

也有团队采用更进阶的 Jira，它拥有强大的结构化资料管理、也可以直接绘制 Burndown chart，有它的便利性，但相对成本更高。

小结与後记

在整个远距 Scrum 的过程，团队需要引入相当多的工具软件，这需要团队良好的学习能力，与开放、肯尝试的心。

当工具整理完之後，对照以往在社群看到的分享，应该多少有重叠的部份，如同业界标配一般，期待未来有更多的新工具推出。