我喵了就算

http://blog.monkeypotion.net/gamedev/process/timeboxing

不知道各位讀者有沒有過這樣的經驗：在漫長的暑假或寒假開始之前，雄心壯志地規劃了許多想閱讀的書籍及想完成的計畫，但一轉眼到了假期結束時，卻發現自己什麼事情也沒做，美好而珍貴的假期就這樣不留一片雲彩地溜走了。

或是你接受了主管交派的任務指示，必須在一個月內完成某項工作，然而卻到了最終期限的前幾天，才發現竟然還有許多細節項目仍待處理，於是只好開始燃燒小宇宙般地夙夜匪懈？又或者你總是苦於無法提升自己的工作效能與做事效率？

怎麼會這樣呢？最初在擬定計畫時，不是覺得「二個月的時間很足夠了」嗎？當初自忖合理，甚至覺得游刃有餘的時程估算，為什麼到頭來還是讓我們疲於奔命？為何在許多情況下，我們總是無法達成原先設立的縝密計畫？

「計畫總是趕不上變化。」你說。

然而，所謂的「變化」到底從何而來？這一切的一切，究竟是命運的糾葛，還是我們既生為人類就注定逃不開「時間」對我們的奴役？

無論你的身份是學生、工作者或大老闆，只要你想進一步提升自己的工作效能並且改善工作成效，你就不能不認真用心地熟識它，我們今天的主角——「時間盒」 (Timeboxing)。

打開時間寶盒

幾個月前，我在閱讀幾篇關於敏捷軟體開發框架 Scrum 的文章時，第一次認識了「時間盒」這個有趣的術語。由抽象「時間」與有形「盒子」所組成的辭彙，有著強烈的對比，令人興趣盎然，並想進一步探索其中的奧妙。

在 Scrum 框架中，將每次從「交付工作」到「完成工作」項目的這個循環，稱呼為一次「衝刺」(Sprint)。每次「衝刺」的期限，大多訂立為 2 週至 4 週的時間。以使用 Scrum 流程的遊戲開發者來說，可依照遊戲專案的實際狀況，決定在每次「衝刺」中所計畫完成的工作項目，而這段 2 週至 4 週的期限，就是「衝刺」流程的時間盒。

在 Scrum 裡很重要的一個關鍵是，我們不能夠在「衝刺」執行的途中，加入新的工作項目，更不允許任意增加或減少「衝刺」的時間期限。時間，是固定不變的。就像是把名為「時間」的玩意兒，一絲不苟地傾注入每位工作者的「盒子」裡一樣，我們必須全心專注，必須分毫不差。

「為何選擇 2 週到 4 週這麼短的時限呢？」

對業界的遊戲開發者來說，相信各位也清楚，有許多工作項目很難在短暫的幾週內，就可以見到立竿見影的具體成果。特別是當專案剛啓動時，在遊戲引擎與編輯器的設計建置程序上，往往曠日費時，甚至需要花費一到二個月的時間才能略有小成。所以，若我們擬定 2 週如此短的時程，會不會太過於不合理呢？

在 Scrum 日常運作中，有一項很重要的程序名為「每日站立會議」：在每天早上工作開始之前，整個團隊必須花費 15 分鐘左右的時間，以「站立」的方式交代每個人的工作及所遇到的問題。可能有人會懷疑：為何這個每日工作會議，一定要以站立的方式進行？大家拉張椅子坐下來好好談，這樣不會比較好嗎？

之所以要讓大家站著開會，就是為了確保會議的敏捷度。我想只要有經歷過開會程序的人都知道，在會議中我們最怕的就是冗長、無意義又沒完沒了的發言。無論原因為何，當會議失去原本應有的效用後，就會侵蝕每位與會者的寶貴工作時間。因此在「每日站立會議」中，當團隊成員開始出現「站立難安」的情形時，主會者就該意會到這場會議已經偏離了原來的方向，必須回歸正題並加速進行。

工作，不僅要求成果，還必須追求越來越高的品質。我們知道在遊戲開發領域中，為了達到理想的品質，無論是遊戲美術、遊戲設計或遊戲引擎的製作，都需要投注相當大量的時間與心力，才有機會達到一款優秀遊戲作品的水準等級。但回過頭來想想，任何一項工作項目，究竟應該安排多少時程才合理呢？是一星期、一個月或三個月？標準到底在哪裡？

如果你認為只要投入更多的工作時間，就能夠得到更好的成果品質的話，你可能忽略了「報酬遞減定律」(Diminishing Returns) 造成的影響效應。如下圖所示，當我們投入時間心力去進行一項工作時，一開始所能獲得的報酬成長幅度相當快速；然而一旦到達某個臨界點後，我們所能得到的報酬就會迅速地趨於平緩。這裡所謂的報酬，也就是我們投入開發時間後所獲得的成果品質。

許多遊戲開發者經常掛在嘴邊的話是：「如果再給我幾星期或幾個月的時間，我一定能夠做出更棒的東西。」是的，只要給我們再更多一點的時間，我們一定能夠將遊戲的品質不斷向上提升。對於完美品質的追求，是沒有極限存在的。但請別忘記，除非你是活在虛擬世界中的可愛人物，否則對我們每個人來說，最好、最多也最珍貴的資源就是——「時間」。

你我都沒有無限的時間可用，時間盒能帶給我們有效而合理的限制，幫助我們戰勝拖延、克服惰性，並且激發潛力。由此可知，Scrum「衝刺」流程制定短為 2 週、長至 4 週的時限，正是為了取得「品質」與「投入」兩者之間的平衡點。

敏捷式計畫

無論是在個人學習或職場工作的層面中，只要我們得到意見回饋的頻率越高，改良進步的機會也就越多；改良進步的機會越多，最終成果的品質也會更高。

如果你是一名跆拳道選手，但你的教練每週只有一天的時間與你一同練習，自然比不上一週七天的共同練習所能得到的效益來得多。因為當教練在選手身旁時，可以立即提供選手各項重要的修正意見與想法回饋。遊戲開發亦然。身為遊戲開發者，如果在接受工作任務後，只是自己悶著頭去做，完全不理會外界的訊息回饋，苦幹了幾個月後，才將最終成果交給上層或玩家檢驗。萬一不幸這些成果與實際期望不符，不僅造成開發時間的浪費與團隊士氣的打擊，也不得不付出的更大的代價進行修改。

在傳統的遊戲開發流程裡，常會將專案里程碑 (Milestone) 的檢核點時程，制訂為 2 個月或 3 個月的期限。舉例來說，如果我們將檢核點時程訂為 2 個月，以一個為期 2 年的遊戲專案來說，共計會經歷 12 次檢核點。而若採用 Scrum 每 2 週一次的「衝刺」流程，在 2 年內將可經歷 48 次檢核點。採用 Scrum 流程所獲得的回饋次數，足足是傳統開發流程的 4 倍之多！

開發時程：2 年

·         Waterfall 傳統流程：2 個月，共計 12 次檢核點。

·         Scrum 衝刺流程：2 星期，共計 48 次檢核點。

為何在敏捷式軟體開發的領域中，會如此強調「迭代性」(Iterative) 的重要性，正是因為迭代循環的次數越多，我們獲得回饋與改善的機會也就越高。只要制訂出合理的時間盒期限，就能夠有效地縮短開發流程的循環時間，使專案領導者能夠敏捷迅速地掌握各種變化並做出應對。

當我們面前擺滿了好幾項工作任務時，在可以自由選擇執行順序的情形下，我們往往會選擇先做「自己喜歡的事情」，而不是去做「真正重要的事情」。因為那些所謂「真正重要的事情」，可能很繁瑣、很沈悶，或者很艱難，所以我們自然會想先從簡單又有趣的任務開始著手進行。

有時候，先做哪些事並不會造成多大的差異；但有些時候，卻會造成無可挽回的悲劇。例如，對於遊戲程式設計者來說，最有挑戰性也最有樂趣的工作任務，經常是去鑽研遊戲畫面與視覺特效的相關技術。但如果只是醉心於高階 Shader 的炫目應用，將遊戲樂趣元素的驗證擺在後頭才開始進行，或不願製作能大幅提升美術設計者效率的工具，如此不僅會造成專案風險的升高，也無法對開發團隊達到最有效益的貢獻。

所以，當你下次在規劃暑假計畫時，不妨將原來的「二個月」長期計畫，更換為數個「一星期」短程計畫，不但能更敏捷地獲取回饋，也可更迅速地見到成果。而在我們的計畫藍圖中，除了規劃工作項目與執行細節之外，更關鍵的要點在於定義計畫目標。各項計畫怎麼樣才算是完成？做到什麼程度才叫成功？計畫的目標，必須要定義出明確的「完成期限」以及「可量化標準」，才能夠真的算是一項完整的計畫目標。

自嗨式計畫 vs. 時間盒計畫

·         自嗨式計畫：我要在 2 個月內讀完《Code Complete》！

·         時間盒計畫：我要 1 星期閱讀 50 頁《Code Complete》，並將閱讀過的內容做出重點摘要與心得筆記。

「萬一失敗了怎麼辦？」在制訂時間盒與明確的目標後，如果沒有達成計畫的話，該如何是好呢？就來開個檢討會議吧！請放心，這裡沒有任何其他人，這場會議只有你和自己的內心，所以不用害羞也無須困窘，老老實實地對自己說出「為什麼」。「因為我看了太多電視影集。」、「因為最近和男朋友吵架。」、「因為很多很多的原因……」不需要向誰解釋失敗的理由與藉口，自我反省後重新出發，制訂並修改新的時間盒計畫。如果不甘心的話，請拿出實際行動證明吧！

潘朵拉之盒

就像老闆、核融合或電玩遊戲一樣，時間盒既然可以被使用在好的地方，它也可以搖身一變成為邪惡的壞傢伙。

某些身負管理職責的工作者，在認識了時間盒與 Scrum 框架流程的方法後，便開始制訂出相當嚴格而不合理的工作時程：「2 週完成 10 隻角色的骨架動態！2 週完成 100 隻怪物的數值設定！2 週完成地形場景系統！所有的一切都是 2 週完成，簡直是太棒啦！」

只要是意識清醒的人都知道，以上的種種美好想像，只會存在於你的幻想世界中。

時間盒的關鍵，在於「品質」與「成本」之間的平衡。所謂的成本，也就是每位開發者投注其中的時間精力。如果訂立了太短的時間盒，那麼最終完成品的品質將會變得太低；而若是訂立了過長的時間盒，則開發者可能會將時間精力耗費在不重要或優先順序較低的工作任務上。

如果你認為只要縮短了每項功能的製作時程，就能夠加入更多的遊戲功能以及更多的遊戲內容，想必是生活得太過於天真浪漫了。有句話說：「生命自會找到出路。」對於工作者來說亦然如此。痴心妄想的開發期限？等著看最後出包的是誰。一開始就知道無法達成的時程？等價交換守則的另一端叫做「品質」。到最後，看來成果豐碩的「任務完成清單」，可能只是堆積著數量龐大的半調子內容罷了。

「品質」與「成本」分別位於天平的兩端，如何平衡兩者的份量，是所有管理者必須時時刻刻悉心照料的重責大任。請記得在大多數的情況下，我們的目標不是追求極致，而是力持平衡。

除了假期計畫或工作排程之外，你是否還有其他更長期的人生規劃呢？「我要在一年後成為專業的遊戲程式設計者。」或是：「我要在五年內存到人生的第一桶金！！」又或者：「我要在畢業前追到那個我喜歡的女（男）生！！！」無論你的夢想是什麼，只要善加利用「時間盒」，相信各位必定能夠朝著自己的目標大步邁進！衝吧！

貓也會的「時間盒」