用 KanbanFlow 做時間管理，督促自己工作！！！

用 KanbanFlow 做時間管理

不論上班或私事，我都喜歡使用 kanbanflow.com 這套工具來管理自己的時間與進度。
Kanbanflow 是一個專案管理工具，可以用來協同開發。使用 Kanbanflow 能快速列出清晰易的讀待辦事項（To-Do List），並將待辦事項分成 To-Do、Do Today、In Progress、Done 四種狀態。
你可以把工作與生活瑣事，全部整理成有「明確行動」的待辦清單，讓你能夠一眼清楚所有事務的內容與進度。


 Tips：除了以上四種狀態以外，當然也可以自己新增/刪除新的狀態。

待辦清單不能只是備忘錄，還要清楚列出「下一步行動」

明確化你的下一步行動

使用 KanbanFlow 的時候，強烈建議實施 微亮計畫去管理自己的計劃，讓待辦清單督促自己做事，提升自己做事情的效率效率。

以下摘錄自微亮計畫：
被事情淹沒的時候，先確保有達到基本款，在追求進階版。
基本款：達到基本要求所需要的時間
進階版：達到心滿意足的程度需要的時間

微亮計畫重點:

  1. 盡量一次只做一件事，最多三件事，否則會降低工作效率。
  2. 把一週內想做的事情全部寫上去。
  3. 標出 24 和 48 小時內真的要完成的事情。
  4. 預估個別需要的時間（分「基本款」、「進階版」兩種時間)。
  5. 兩天過後再循環一次



推薦閱讀：
經理人 - TO DO LIST 這樣用才對！
微亮計畫

​

留言

張貼留言

這個網誌中的熱門文章

Git Commit Message 這樣寫會更好，替專案引入規範與範例

圖片
Commit Message 跟寫程式註解還蠻像的， 最好可以寫下「為什麼」你要作這樣的異動， 而不是單單只記錄下你做了「什麼」異動。 Commit Message 最好兼俱 Why 及 What，讓日後進行維護人員更快進入狀況。 Commit Message 這樣寫會更好： 做 issue 的時候，不應該一次 Commit 所有異動！應該獨立 Commit 每個不同意義的異動，這樣 commit 訊息才會跟異動的程式碼有關聯。 每次 Commit 都是針對異動的檔案做說明：Why & What。這樣的 Commit Message 能讓日後的維護人員更快進入狀況 每次 Commit 都加上 issue 編號，方便追蹤相關的程式異動原因。 若 Commit Message 寫得妥當，在閱讀追蹤程式碼的意圖會相當容易。如果只把 Git 當作版本控制，隨意撰寫 Commit Message 就太可惜了！ 不能只把 Git 當作程式碼的 FTP，要把 Git 當作歷史查閱的工具才拿發揮 Git 的功能。 好與不好的真實案例 用一個小插曲證實 Commit 訊息的重要性 上面 PPT 是我在工作中遇到的兩個案例，範例中包含「好的 Commit Message」與「不良的 Commit Message」。 在範例中可見： 良好的 Commit Message: 如何在「一年後」讓維護人員進入狀況 不良的 Commit Message: 如何在「一個月內」讓維護人員找不出程式異動的原因 。 Commit Message 之規範 在撰寫 Git 與 SVN 等版本控制軟體 Commit Message 時，可以參照國外 AngularJS 團隊的規範： AngularJS Git Commit Message Conventions 以下為這套訊息規範的展示與說明： Commit Message 規範範例： Commit Message 規範範例解析： Commit Message 規範組成： Header: < type > ( < scope > ): < subject > - type: 代表 commit 的類別：feat, fix, docs, sty
閱讀完整內容

PHP OO 物件導向基礎教學

PHP OO 基礎教學 此篇教學只是物件導向的基礎與實作，內容只包含類別與物件的操作，讓不熟悉類別的人可以初識物件導向的好處，並且了解物件與類別的特性與關係。 更多物件導向的理論的學習內容會整理到 PHP OO 的進階教學: 淺談物件導向 SOLID 原則對工程師的好處與如何影響能力 再談 SOLID 原則，Why SOLID? PHP OO 物件導向原則:單一職責原則SRP PHP OO 物件導向原則:開放封閉原則OCP PHP OO 物件導向原則:里氏替換原則LSP PHP OO 物件導向原則:介面隔離原則ISP PHP OO 物件導向原則:依賴反轉原則DIP 進階觀念：再談物件導向設計原則: 單一職責原則，定義、解析與實踐 認識物件導向 Object Oriented： 物件導向是一種寫程式的方式，它傾向讓開發者把類似或有關聯的工作或屬性，組織到類別(classes)裡面。這可以讓程式保持遵守  不重複原則** “don’t repeat yourself” (DRY) **，且更容易維護。 “Object-oriented programming is a style of coding that allows developers to group similar tasks into classes.” 不重複的程式(DRY)是物件導向最主要的優點之一，物件導向嚇跑了很多的開發者，因為它帶引入了一些新的語法，並且一看就知道比直譯程式(procedural)還複雜。但是，其實仔細了解一下，OO 實際上是一種非常直觀且是簡化程式最好的方法。 一、認識物件與類別 Understanding Objects and Classes 在開始更深入了解 OOP 之前，一定要先了解  物件(object) 與 類別(class)  的差異。本章節會介紹 類別(class) 的構造，還有其功能與用途。 類別(class)，可以比喻為一間房子的藍圖，類別只是清楚得定義房子的結構與形狀。 物件(object)，可以比喻為一棟真的房子， 物件是類別的實例化 。 資料(data)就像是鋼筋、電線、混泥土等蓋房子的材料。如果沒有按照 藍圖 (類別 class)  來組裝，這些
閱讀完整內容

Gitlab 合併請求 Merge Request 是什麼？

圖片
Gitlab 合併請求（Merge Request ） 一般在團隊開發的時候，為了避免工程師直接對主要 Repo 進行修改，會要求工程師從 專案的主要 Repo 複製一份這個專案的副本（Fork）回來工程師的電腦進行開發/除錯。 工程師開發完成後，如果要把電腦上最新版本的程式碼上傳回 專案的主要 Repo ，就必須對 專案的主要 Repo 發送一個 合併請求 ，請 專案的主要 Repo 管理員進行程式合併。 當合併請求發送出去後， 專案的主要 Repo 管理員可以在管理頁面上看見你的合併請求，這時管理員會進行一次 Code Review，管理員覺得程式沒問題，就會將工程師的程式合併回主線。 若管理員覺得這段程式碼有問題，也可以 Close 這次的 Merge Request 。 另外 Merge Request 等同於 Github 的 Pull Request   - 可參考:  與其它開發者的互動 - 使用 Pull Request（PR） 上述流程如下圖： ​
閱讀完整內容