前言

今天来跟大家聊聊一个轻松的话题，与先前我们提过关於时间的主题有点关系，就是当我们听到「有空再说」，或看到程序码区段被写上的 TODO 时，我们可以怎麽面对。

亲爱的，你不会有空的

在我的观察，我们得要先刻意有空，才会有空。

现在有太多干扰存在，人手多机的智慧装置就是显注的例子，它会尽最大的可能补捉时刻的注意力，好似尽心尽力填补着每一段人生空档。使用装置上数位健康的软件，看看我们一天会收到多少通知、在各应用程序花了多少时间，就不难发现时间是如何流走的。

嗯，当然，如果你现正用该装置在看本文，那完全没有问题，很棒！

我们的时间总是会花在意想不到的事情上，在正式的工作上，仍然有许多让你闲不下来、忙不过来的可能性，这种「有空再做」、「有空再说」或「之後再处理」有很大的机率不会再做了。

当「有空再说」出现时，团队必须知道它的性质。若是在讨论各项目的优先顺序或 Brainstorming 时冒出的新想法，一时之间团队无法消化，那把它「记下来」问题就不大，可行的话保有图象或文字记录，若以录音/录影就需要事後整理，可能更没空。这样做的目的是为了留下好的想法，避免「有空再做」这形同咒语般的言语把想法消失掉。

但若它出现在日常的进度确认时，那得小心是否出现了无效的承诺。

「Hay~ 上次提到的 API 可以给我们测试了吗？」
「我还在忙别的，那个有空再说」
「……」

无效承诺

先轻松点，让我们回想一下求学阶段在图书馆的场景，对於一位充满理想与抱负的学生，看着满满的书架心生喜悦，於是借了许多书回家，然後放着。

… 对，就是放着，放到到期再还回去。

相同的概念也可能出现在购书上，尤其现在书籍取得的通路便利与价格实惠，我们可能也买一堆书，然後放着一页也没翻。

上面的例子顶多是向自己承诺，但这个承诺显然没什麽效果，因为它缺了一些东西。

而在工作上我们必须向团队承诺，为了避免这个问题，我们可以透过谈论目标管理时常会提到的 SMART 原则 来提醒，即

Specific (明确)、Measurable (可衡量)、Achievable (可达成)、Relevant (相关) 与 Time-bound (时限)。

其中最单纯且直接的是「时限」，宣达一件事情的预计完成时间，就可以带来不错的效果。

这种估计性的时间，在 Scrum 的运作中，通常应用在拆解後的任务 (Task) 身上，团队为任务估计理想工时。这个工时的意义并不是单纯要让开发人员画押签字，更是一种评估自己工作量的方法，从而避免做出无效的承诺。此外，工时也有助团队成员预期彼此之间的合作方式，达成弹性的时间利用，避免无谓的停等，这也是一种透明的展现。我们可以发现，一个小小工时估计，背後会带动许多事情，读者们怎麽看呢？

再做点延伸，我们也不难发现，无论是 Product Backog Item (PBI) 或 Task，也多少具备 SMART 当中的数项元素，例如：明确的方向、可衡量的验收条件、可达成的做法、相关的资源与理想的时限。

// TODO

让我们把焦点转向 Coding，不知道大家是否好奇，写在程序注解当中的 TODO 究竟会停留多久呢？或许让我们花几分钟时间，随意找一个 Repo 搜寻一下，看看最老的 // TODO 今年几岁了？

有一种 TODO 是 IDE 帮忙产生的，例如 OOP 世界观当中，我们可以定义介面 (Interface)，在开发实作 (Implement) 时多数现代的 IDE 可以帮忙产生出基本程序码框架，之後再按需求填入实作细节，这些被实作的方法 (Method) 可能会被加上 // TODO 注解，或直接在其中抛出错误，避免开发人员遗漏。

而另一种 TODO 则是人为加上的，也是团队应该要注意的，确保这个 TODO 已进入团队视野当中，否则它很容易沉没，随着时间成为一种成本，後进人员进行维护时可能会倒抽一口气，原来还没写完啊！在这个阶段，最容易把关的可能是 Code Reviewer 与 Pair Programming 的导航员。

当然有些工具上的补助可改善这个问题，例如一些 IDE 可以抓取所有出现 TODO 的地方，给你一份待辨清单；团队也可以定义规章，定期来审视这些 TODO，确认它们的现况。

後记

无论有没有空，今天都得说声「教师节快乐！」，快去行动吧，让 TODO 变成 DONE。