前言

利用前幾天的篇幅，簡單的討論敏捷與 Scrum，也傳達了我覺得團隊需要注意的地方。今天再讓我們回到團隊的日常，一個每人都在苦思，難度直逼午餐要吃什麼的問題－－「沒有時間」。

時間不夠嗎

還記得第一次看到 Joey Chen 前輩的一段話 (91 敏捷開發之路的貼文)：

我認同，『沒有時間』是個問題。
問題是，『你做了什麼』來解決這問題？

至今仍然可以記起當時的震撼，這個段話精準點出了問題，同時帶有積極的推力。是時候問問自己，究竟做了些什麼來回應時間不夠的問題呢？

擠出時間的選擇：Side project

來分享我的個人經驗，我時常利用時間做一些不在工作範圍內的事，以 Side project 的方式開發提高工作效率的工具，也將這個想法推薦給夥伴們，至今我們有量身打造的自動化釋出工具、多語系管理工具、程式碼資源統整工具、開發平台與看板資料分析工具等，每個工具都大幅減化工作復雜度，持續性地節省團隊時間，釋放珍貴的創造力，相當感謝團隊成員的努力。

但回頭看看，每個工具也是投入不少工作量，無論是利用工作之外的時間，或利用工作內零碎的時間完成，若在一開始就先思索一番，那很可能被一個「沒時間」給回絕了，於是團隊繼續做著「粗重」的軟體開發工作。

這是一種自動化的體現，我們願意做嗎？

工作態度、能力與時間

若一份工對自己來說沒有任何意義，它單純只是標準工時 8 小時的一種體現 (不同公司算法可能不同，這邊以勞動部標準為例)，那會有很高的機率你覺得時間不夠用，而且你時時都覺得自己在追趕期限。特別在軟體開發這種腦力產業當中，任何工作上的不順利、制度 / 環境 / 需求上的變化，都會帶給你很大的衝擊，這可能來自對工作熱忱的缺乏，也可能是能力尚不能負荷。

一下子就嚴肅起來了，談到能力，經驗與技能累積在軟體開發當中是重要的，特別是在 Scrum 這種快步調，多方協作的情境下，成員有多少的專業能力足以支持？我們可以思考，正在困擾著我們，讓我們覺得時間不夠用的工作任務，與自己的能力是否存在關聯？這不是批評，而是提醒，如果是因為能力關係，那麼加強它可能是符合自己的價值觀上最簡單做法了。

你我應該都同意，在學期間或是各方的專業訓練課程，都是一個開端，往後仍然需要靠自己延續，才能夠迎合這快速進步的時代。若您是位初學者，保有自己對特定領域的熱愛是個起點，把課程作為基石，在上面疊加自己大量的學習與嘗試，這會使得您在業界能更順暢的發揮。學習不會停止，任何工作項目都可能是下一階段的學習大門。當然，如果您已經很認真在學習，能力足夠與否只是個短暫的表象，總有一天會到位的。

我們是否對工作有熱忱，是否愛著努力的目標(如工作、產品、專案)，會很大幅度影響你對時間的感受。總是覺得時間不夠用的讀者，不妨以這個方向思考一下，不要急著落入受害者情節。或許理性的讀者可能會想反駁，這不就是拐個彎要我們加班嗎？從「時間」數字上來看，它可能會是加班，但在鑽研這個問題之前，不如想想：「我是為了誰在工作？」。

倘若你真的需要加班，那希望你是為了消滅加班而加班。

沒時間測試

談「沒時間」怎麼能缺了這個總是沒時間做的事情呢？

敏捷團隊必須重視專業技能的卓越度，但這方面的議題在 Scrum 沒有明確提及，有些團隊可能就遺忘了，殊不知這些都是專業的軟體開發團隊的必要素養，而測試正是其中一環。

話說回來，一提起要做測試 (我們先以自動化單元測試為對象)，顯少有人是笑跟你說好，更多是近乎反射思考的回應「沒時間」，這點除了在工作上很容易觀察，在多數談「測試」的研討會議程中也相當常見，總之，測試這回事就是這麼理所當然的與沒時間綁在一起。

會有這種反應，在我的觀察，其一可能是對測試這門藝術的熟悉度還不高，尚不足以順暢地融入實作。也因此，看到 TDD 像看到鬼、穿插於實作中的測試打亂原有的節奏、實作寫完還得「補」上測試，辛苦得很。

那麼，該怎麼讓團隊接受測試，並開始寫測試？有許多前輩分享了自己經驗，而我也不自稱是測試專家，這邊分享我淺薄的看法：

1. 先說明測試好在哪、為什麼我們要做測試。
2. 安排教練訓練，確保成員掌握基本的測試原則，以及知道如何運用團隊選定的測試框架進行撰寫。
3. 如果團隊有 CI，測試必須在 CI 任務上被觸發上，這是非常重要且必要的。如果沒有 CI，那先去生個 CI，再把測試接上 (喂！)
4. Code coverage 不一定要馬上要求，重點是有「開始」寫測試的行為，看到 Coverage 成長是一個過程，暫時不用要求一定要成長到多少。
5. 承擔時程延誤的可能性，這個過程難免跌跌撞撞，有好的指導者可以縮短陣痛期，如果是自行摸索作必須做好延期的預估。

Scrum 與時間

那麼在 Scrum 的情境下，有什麼與時間相關的議題嗎？

Scrum 這種迭代式的開發模式，每次衝刺不僅是產出價值增量，更要讓它帶起團隊成長的正向循環。衝刺內可以運用的時間並不長，團隊必須善用它，為此必須盡可能抑制意外的發生，這也可以接到剛才談到的自動化測試，如果團隊缺少這種保護機制，那快速運轉的衝刺只是把團隊帶向更危險的境界，我們可能衝很快，但一點防護都沒有。

一旦團隊時常在補洞，大量的間就這樣消耗掉了，團隊總是無法預測這次的改動、增加新功能會導致什麼副作用，久了也無法放心的交付，持續陷入了沒時間的循環。

借這個小主題僅提出測試與時間的關係，單就這一點足夠團隊好好思索。

急病投債

即便再怎麼努力，多少會有迫在眉睫的問題需要團隊立即處理，在沒有足夠的反應時間、無法透過正常手段完成的情況下，團隊自然會應用各種繞道的技術，以欠下技術債為代價來實現短期目標。這很有效，但治標不治本，可以帶來「看起來」還不錯的效果，但千萬記得這只是短期的，能早早還債就還，免得它成為未來時間不夠用的原因，這也屬於團隊應該「擠」一下的範疇。

艾森豪矩陣

談時間、談工作效率，讀者可能多少看過艾森豪矩陣，以四個象限劃分出：「緊急且重要」、「重要但不緊急」、「緊急但不重要」與「不緊急也不重要」。

在時間不夠的情況下，要刪掉哪一類的工作、要優先做什麼工作相信不需要說明，這個分析工具可以幫助你判斷工作項目的先後續序，但還是相對被動了一些，所以現在才提起，希望我們能以更極積的方式來面對時間不足。

小結

時間放著不會自己冒出來的，我們可以選擇多做點什麼(開發工具、調整流程、排除障礙)；也可以少做點什麼，或… 不特別做什麼，但請停止抱怨。