【本周】軟體開發中的時間管理—我的時間到哪裡去了？

  “對不起，項目要延遲一周”

“我們的項目延遲了，但是我找不到原因”

“我們已經完成了80%的東西，項目按計劃進行，但是系統還不能跑起來”

你是不是遇到過這些情況呢？有時候我們的項目要延遲，有時候項目延遲了卻找不到原因，有時候項目按照計劃進行但是客戶詢問進展的時候我們卻拿不出一個成型的東西。這裡所有的狀況的原因都可以歸結于---時間資源緊缺。

怎樣的有效的利用時間？安排滿滿的計劃就算是有效利用麼？這就是我們的本周話題：軟體開發中的時間管理。

我們來分析上面的問題：項目為什麼延遲？為什麼找不到延遲的原因？這說明項目執行計劃是沒有做到足夠細化的，這裡說的細化并不是一個極端，而是細化到這樣一個程度：通過它你可以有足夠的線索來對項目進度實行監控，對計劃做出實時調整。這就是我們說的第一點：<b>軟體開發過程中最基礎的時間管理是安排一個幫助你能掌控大局的任務時間表。</b>

下一個問題，我們的項目沒有延遲，我們的客戶或者測試人員詢問的時候我們卻拿不出一個可以暫時能跑起來的系統。很無奈，我們說沒有延遲，好像隻有我們自己相信自己。當然開發過程不能讓外界力量左右，但是，為什麼不能先出來一個可預覽的系統呢？這就是第二點：軟體開發中的時間管理很重要的一點是---<b>開發任務的優先級：優先級處理的作用就是幫助你用最小的投入獲得收益最大化。</b>

<b></b>

<b>怎樣安排任務的優先級呢？</b>我的文章總是要給出一個可執行的方案，而不僅僅是提出問題，我的答案是：<b>CEARVR</b>

<b>CEARVR</b><b>是軍事打擊中總結出的原則，有的寫成：CARVER</b><b>，我按照思考順序做了一個調整。CAERVR</b><b>是經過血肉檢驗的實踐原則，在軟體開發過程中進行實踐，會感覺到這個原則的偉大。</b>

<b> </b>

<b>C</b><b>：Criticality</b><b>重要性；</b>一個郵件發送接收的dll會影響整個流程是不是能夠順利跑通，那麼它是具有重要性的。一個處理頁面中文繁簡體的dll相比之下可以推遲一下實作時間。

<b>E</b><b>：Effect </b><b>影響性；</b>開發本身有deadline，前台和背景管理頁面的頁面美化工作都沒有做，但是背景管理頁面暫時有開發人員負責，是不是美化影響不是很大。前台頁面是系統的門面，其影響巨大，是以要優先。

<b>A</b><b>：Accessibilty </b><b>可進入性；</b>任務可以直接着手解決, 還是有一些在做它之前必須完成的事?如果你要寫的Service需要十幾個dll的引用，而這些dll還沒有完成，那麼我們認為這個Service是沒有Accessbility的。

<b>R</b><b>：</b><b>Return </b><b>回報；</b>軍事上很注重一個軍事行動的回報，因為每一次軍事行動的代價都是很大的。沒有适當的回報，這次軍事行動就是失敗的。一句話将就是你花費多少成本說會多少回報？一味的提高單元測試覆寫率，而影響了開發進度就是沒有回報的，或者回報率很低的；因為對于使用者你告訴他你的單元測試覆寫率達到89%，他不感興趣，他要反問你：項目能不能按期傳遞？

<b>V</b><b>：</b><b>Vulnerability</b><b>易完成性</b>； 你的目标容易實作麼？這個任務需要多少人多長時間？

<b>R</b><b>：</b><b>Recognizability </b><b>具體性</b>；“星期一系統要完成80%”“星期二整個流程要跑通”這樣的計劃描述方式是沒有意義的，因為它缺少最基本的可操作性：一方面任務的内容是不具體的，另一方面可度量而無法度量。對于與你協作的同僚更郁悶：我具體要做點什麼呢？

<b>總結：開發過程中進行時間管理，有一張時間表是十分重要的，而且它需要有一個你能夠接受的細化。時間表上安排任務是有優先級的，如果需要一個安排優先級的建議，我推薦：</b><b>CEARVR</b><b>；</b>