最近看到朋友分享【35格時間管理】給裝忙的上班族：其實你擁有很多時間這篇文章，覺得跟自己從大學開始就習慣使用的時間規劃方式類似，不過還有蠻多細節可以仔細討論，因此決定來講一下目前的生活方式。
概念
目前的生活方式大概是有著「敏捷精神」存在的方式，雖然有著一定標準的時間規劃但同時也具備了彈性，整體上來說由類似文章一開始提到的「時間格」方式來設定基準，然後搭配 OKR（Objectives and key results）的方式配置，並且用敏捷開發的「敏捷」方式動態調整。
OKR 的方式是參考商業思維學院的用 OKR 設定個人目標，展開個人策略地圖的方式進行設定，使用 Todoist 來管理。
敏捷
敏捷開發中的敏捷（Agile）其實是有「靈活」的意思，簡單來說敏捷開發是希望我們可以「靈活對應開發」為目的所設計，然而如果可以隨意的增減任務還是會造成麻煩，因此會透過衝刺（Sprint）來限制一個時間範圍該分配的任務數量，並且在一個相對短的週期重複調整，進而來達到靈活對應。
另一方面，在我學到的敏捷開發知識中，大多數的會議都會有 Timeboxing（時間箱）的機制，用來避免大家花過多的時間在會議上，而這個概念基本上就是把時間分配成固定單位大小，並且在這個時間單位內專注在某件事情上。
OKR
OKR 的中文是「目標與關鍵成果」從字面上的意思其實可以很清楚的猜測到，我們需要設定一個目標以及對應這個目標的成果，並且以此來進行任務。那麼，商業思維學院的用 OKR 設定個人目標的方法，就能用來幫助我們設定「某段時間內要做出什麼成果」這樣的規劃。
利用這樣的方式，我們可以規劃一個短期、中期、長期的目標，並且設定「達成目標的成果」是如何的，用來評量這個目標的進度跟狀態。
目前我使用的 Todoist 官方有一篇文章介紹如何使用他們的工具來進行 OKR，大家可以參考 OKRs: A Guide to Data-Driven Goal Setting for Individuals and Teams 這篇文章。
以工作為例子，我通常會設定一個「一天一到兩個 Pull Request」這樣的目標，接下來就是思考怎樣在「完成團隊任務」的前提下，不斷調整每天的狀況，讓自己能穩定的產出，以及確保最後團隊能順利交付。
原則
我在 2022 年在台灣的軟體工程師需要什麼？ 這篇文章有簡單提到「原則」卻沒有細講我的理解。簡單來說，原則是一種基準，他不會是一個非常明確的東西而是一種參考的表準，可能類似於「比起金錢，健康更重要」這樣含糊的定義，但我們可以根據這個基準選擇「薪水較少但不會傷害健康」的工作，而不會因為要薪水高低要選擇怎樣的工作而困擾。
因為對不同的事物（工作、生活）有了基準後，我們就可以用「四象限法則」來將每件事情的目標、任務進行分類，如果只是單純區分重要程度、緊急程度是很難馬上判斷出來，然而加上了自身對事物的原則，就可以清楚知道是否重要、緊急。
這邊可能需要個例子，像是我有一個「下班後避免工作，但可以寫程式」的原則在，因此在安排「一年出去玩一次」跟「接一個案子」這兩個目標時，會先處理旅遊的部分，再去完成接案的任務，即使「接案」的目的是「出去玩」
任務
有了原則後，我們就可以參考敏捷開發的方式把「目標」當作是「使用者故事（User Story）」來定義，然後如何實行的「關鍵成果」，就是我們要去達到的「任務」根據原則進行分配。以我個人來說，不會去特別區分「時間」但設定一個恰當的死線還是很重要的，基本上會以「一年」左右為單位。
以我個人未來一到兩年的規劃，是希望能夠「專心研究技術」為了達到這個目的，需要先「不依靠單一收入」跟「彈性工作時間」兩個條件滿足，為此就需要先達成一系列的目標。
- 遠端工作為主，增加時間的彈性
- 以顧問、課程類型的方式增加收入
- 經營自媒體透過贊助方式維持生活
根據這些目標，在「選擇工作」的角度上就可先排除掉無法遠端工作的公司，或者會在上班時間有大量干擾的公司。另一方面，因為需要支撐生活跟其他規劃，因此收入不能中斷，就需要從比較單一的收入轉變為相對多元的收入，這時候符合「專心研究技術」的條件，選擇顧問、課程跟撰寫文章這類方式來增加收入，是有正向的加成效果。
也因此，今年（2022）上半年的「Rails 部署實踐」就此誕生，這就是其中一項任務，以及為什麼要繼續準備 2023 年的 RSpec 系列文章，以及後續可能長達數年的各類技術文章連載，因為這都是計畫的一部分。
審查
不論是敏捷開發或者 OKR 其實都需要「定期審查」來檢視任務的狀況，一般來說我們以一週為衝刺的單位就差不多，在一週的某一天檢視「完成」、「追加」以及「捨棄」的情況，靈活的調整。
從 OKR 的角度去看，我們要看的是當初設定的目標是否有確實達成。從敏捷的角度看，則是要去「增減」任務，以及重新拆分調整到適合當下的狀態，不斷改進到最佳的狀態，因此審查是必要的。
我大多會在週日的上午或者晚上進行審查，可能會移除掉一些「不必要」或者「達成」的任務，並且加入一些新的條件等等。
跟開發軟體不同的地方在於，我們可能會有很多「例行性任務」存在，以文章連載作為例子，我每週都會有一個時間要寫固定數量的文章確保連載正常，在連載結束之前都需要每週執行一次。
整合
現實中，只使用單一技巧來管理時間其實依舊混亂，因此我們需要將這些技巧統整起來搭配使用，這些技巧又剛好負責了不同的「面向」來幫助我們。
最開始的「時間格」某方面來說就是敏捷的「時間箱」可以根據對時間的安排精細度，調整，我自己是以一小時為單位作為基準，同時在安排時間時要記得設置「空檔」因為我們不是機器。
由時間箱提供了「紀律」之後，我們大致上會知道某個時間點應該是要「工作」還是「休息」或者「學習」等等，接下來就可以利用 OKR 的方式設定目標，以及達成目標所需的「關鍵成果」是什麼，這樣就不會漫無目的的前進。
有了目標後，我們就可以善用敏捷的方式「執行」像是「分析目標跟任務」找到該做的事情、如何實踐等等，並且能以「時間箱」的單位資訊來獲取可用的時間進行分配要執行的任務，同時每週的審查可以透過確認目標、執行狀況決定要放棄還是繼續直到完成。
如此一來，我們就獲得了一個非常有目標而且靈活的生活方式。雖然是最近才成型的執行方式，不過也確實是不斷的從我過去對時間分配的經驗中不斷累積變化而來所形成，也幫助我在每年許多研討會的投稿上能順利完成投稿跟演講。
留白是為了休息、獲得彈性他也是一種「任務」給予我們時間的彈性，像是這篇文章就是在這樣的時間所產生。另一方面，「沒有目標」也是一種目標，我在今年的規劃中就有著「能偷懶就偷懶」的原則，因此在許多安排上會以「休假」為前提，而不會像以往追求投稿一定數量的研討會。