貓也會的「時間管理術」:Timeboxing

圖片來源:blog.vsharing.com

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

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

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

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

然而,所謂的「變化」到底從何而來?這一切的一切,究竟是命運的糾葛,還是我們既生為人類就注定逃不開「時間」對我們的奴役?無論你的身份是學生、工作者或大老闆,只要你想進一步提升自己的工作效能並且改善工作成效,你就不能不認真用心地熟識它,我們今天的主角——「時間盒」 (Timeboxing)

打開時間寶盒

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

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

圖片來源:blog.3back.com

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

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

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

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

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

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

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

圖片來源:gamasutra.com
圖片來源:gamasutra.com

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

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

敏捷式計畫

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

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

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

開發時程:2 年

  • Waterfall 傳統流程:2 個月,共計 12 次檢核點。
  • Scrum 衝刺流程:2 星期,共計 48 次檢核點。
圖片來源:catuslee.com

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

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

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

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

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

  • 自嗨式計畫:我要在 2 個月內讀完《Code Complete》
  • 時間盒計畫:我要 1 星期閱讀 50 頁《Code Complete》,並將閱讀過的內容做出重點摘要與心得筆記。

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

潘朵拉之盒

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

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

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

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

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

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

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

貓也會的「時間盒」

延伸閱讀

13 Replies to “貓也會的「時間管理術」:Timeboxing”

  1. 講到管理 實在令我感觸很深
    大多數遊戲專案管理都是由”製作人”負責(感覺企劃出身較多 下次有機會來個投票看看哪個部門產生製作人的機率比較高)
    敏捷開發的概念 或是核心思想(時間 成本 品質 範圍的取捨、Iterative開發等)
    要讓製作人理解跟要讓牛學會算數這樣的困難

  2. 發人深省的文啊…
    這篇文章的內容令我開始思考自己目前運行的專案要如何進行改進
    不過, 說是以兩周為一個基準, 這個數據有基於人數的多寡嗎?
    如果是兩三個人甚至是一個人, 是否也是基於兩周來進行整個迭代過程呢?

  3. Scrum我們課室有跑過,總共四人週期三個禮拜吧~
    我們四人能力比較好,都有跑到自己所定的衝刺期。
    但是這三個禮拜不包含free week(簡單說就是除錯時期)。
    我們就是一直趕功能,不管品質好不好,其實也沒有QA幫我們測試。
    總共跑了幾個月吧~幾乎某原因就停止此計畫了。
    這計畫主要是增強引擎的功能項目或是開發新工具。
    但是拿到課室的client的game play那邊跑,
    因為我沒負責game play這塊,
    但是從我旁看來這Scrum不適用於此。
    原因在於機動性不足,品質不佳,光這兩點就足於毀掉Scrum這東西。
    上文有提到「在 Scrum 裡很重要的一個關鍵是,我們不能夠在「衝刺」執行的途中,
    加入新的工作項目,更不允許任意增加或減少「衝刺」的時間期限」
    致命點:
    比如:上一次spring做的功能,user要求添加一些小功能來增加工作效率,
    但是主管對user說,等到下一次spring吧~我不能在衝刺期中隨意增加工作項目。
    再比如:上一次spring做的功能有bug,那為了不影響下一次衝刺週期,請自行吸收。
    也就是說free weak時段必須在衝刺期當中擠出來,那如果能力不好的話,
    就開始陷入惡性循環,最終….Scrum?那個不跑了。
    簡單經驗談,還有其他複雜因素不方便在網路上說。

  4. 個人淺見:敏捷式開發對於『自我管理能力不良』,但是經驗豐富能力強的開發人員很有幫助,能夠讓專案在短期間內,不斷累積成果,並且讓成果可視化,由不斷達成每一個小目標,最後累積達成大目標。(當然,方向必須正確才行)

  5. 半路您好:

    想請教,關於敏捷開發中的測試部分,文中並未提到,不曉得您的觀點是?

  6. @Rich:
    倒未必非使用敏捷開發不可,但如果不瞭解成本、品質與規模範圍之間的取捨的話,我不曉得為何這樣還能勝任遊戲製作人的職位哩…… = =a

    @Necromancer:
    Scrum 裡的 2 至 4 週時間盒,並不是一個固定不變的循環週期,而必須視團隊成員數量與專案實際執行狀況進行調整。最重要的是,找出真正適合自己與團隊的流程方法。

    @vamper:
    你提到都是現實中會發生的狀況沒錯。總歸來說,Scrum 並不是萬靈藥,如果團隊無法心悅誠服地學習敏捷式開發流程的思維模式,並視實際狀況進行調整的話,再多的流程與規範也會變成只是在做表面功夫罷了。到最後,還是自己在跑自己的 Mini-Waterfall……囧!

    @鳳凰騎士:
    其實敏捷式開發,特別是 Scrum 框架,非常不適合使用在「自我管理能力不良」的團隊及個人身上。Agile 相關的方法論,大多是建立在具有「高度自我管理意識」的團隊中的創新管理流程。

    @yuxioz:
    可見得要找到會算數的牛比較容易……?(炸)XD

    @小蟹:
    你好,

    若你所指的是遊戲專案的部分,我認為測試程序應歸屬於每個 Sprint 中的一部份。一次 Sprint 就做一次單元測試,經歷數次 Sprint 後,需要另外規劃一段整合測試的時程。

    測試這件事,就像是「還債」一樣。在開發的過程中,遊戲開發者不斷累積「債務」,但很多人只想著在最後完成前一次清償,卻常常會還不出來或甚至導致破產。所以,就像現實世界一樣,我們還是應該在有能力的時候,一點一點的還清債務,才是正確且明智的做法。

    關於 Agile 以及 Scrum 方面的資訊,若各位有興趣的話,可以進一步參考「David Ko的學習之旅」部落格,有相當豐富多元且具實務經驗的心得分享文章。

    感謝各位的意見與迴響~ ^_^

  7. 跑過1~2個專案(雖然專案最後都以失敗為終)~但更能了解scrum的精神所在
    它~只是個框架非律法、規則得一定尊守。
    因此了解scrum後,為自己企業、專案發展自我的scrum是重要的。

    最後覺得,遇到不了解scrum且以死腦筋(失敗還不改變)來帶領整個團隊的頭頭~肯定滅團~XD

  8. @Rio:
    沒錯,如果沒有自我管理的心態與能力,不論再新奇的流程管理制度,也無法發揮良好的效用哪。

    @未來:
    你好,

    最怕的就是只學到 Scrum 的皮,而沒有真正瞭解它的精神所在。Scrum 可將專案中遭遇到的問題與阻礙,更快速且更清楚地揭露出來;但請記得,Scrum 本身並不能解決你的專案的問題。

  9. 這是很好的方式呢?高三因該很實用,真的。相信我
    不過要有很高度的專注、和自我實現的能力呢?

    考統測就來試試看吧!

  10. @禾野:
    先擬定一個短期的讀書計畫和目標,然後用力去實行看看吧!

    說不定過段時間後,你就會發現自己功力大增唷~ :D

Leave a Reply