前言

今天來跟大家聊聊一個輕鬆的話題，與先前我們提過關於時間的主題有點關係，就是當我們聽到「有空再說」，或看到程式碼區段被寫上的 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。