個人軟體過程2 項目開發的基本流程

    第一步當然是需求的採集，怎麼做？

    先和使用者交流，弄清楚項目的目標，這個通常是幾句話，使用者的語言，但你必須理解，並且文字記錄下來。然後我們需要做第二件事情，即軟體需要提供哪些功能，來實現項目目標。當然，這和使用者的作業流程、商務規則、具體崗位是有關係的，這裡的產品是一份功能清單。第三個則是功能清單的說明，通常也就是一段話，使用使用者的語言。
    一般沒有必要記錄非常詳細的商務規則，在交流過程中這些通常會變得清晰。我們的問題是：做什嗎？而不要涉及太多的細節。

    這三項工作完成之後，需求也就告一段落。我們的團隊，將至少有一個人，完全明了這個項目的目標、我們需要實現哪些功能、這些功能主要是做什麼的。關於業務細節，可以通過交流然後形成文字、簡單的也可以忽略。但這個過程中，負責需求分析的先生，必須完全能夠說服自己。

 

    此後，劃分階段，這需要一定的經驗。功能清單，對應的工作時間。嗯，是有理想工作日的概念----我個人覺得不用管它，將自己初步測算的時間乘以2就是不錯的選擇。也有人認為此時是比大小的階段，即找出最簡單的功能，將其大小看著1，其他每項功能按比例賦值---嗯，那其實也是很麻煩。雖然那些書生給我們講課的時候，比較鄙視估算時間這一說，但時間畢竟是最直接的的概念。
    估算時間的作用，是考慮分階段完成。
   時間緊張的項目，盡量2周一個階段，略長的則可考慮四周一個階段。

    劃分階段的依據是什嗎？4個原則：1、最快的投入使用；2、均勻分布到每個階段；3、考慮各種風險因素；4、每項功能在每個階段都必須是徹底完成，不要做成半成品
    我們需要在將每個階段的目標用一到三句話記錄下來。

 

    此後我們開始第一個階段，這通常是和使用者交流一個工作日之後1到2天的事情，不要拿起架子做多少多少準備工作。這裡，我不推薦所謂的小組評估功能大小、使用者決定哪些先做哪些後做，這類花頭第一是浪費時間、第二是缺乏可行性。

 

    然後項目負責人，可以考慮為第一階段的各項功能，做使用者體驗設計，並劃分開發工作單位，這裡也需要一定的經驗：1、一項功能，需要考慮哪些事情？菜鳥和老手是有非常大的差異的。2、這些任務的開發順序，盡量要自然一些。3、在這些任務中可能碰到哪些問題，也要列出來。這些問題可能是業務方面的，需要布置文檔任務；可能是技術方面的，需要解決並寫成文檔形式，以免團隊其他人同樣花費時間解決這些問題。4、有哪些地方是需要測試的----不要追求覆蓋全部。

    之後，程式員將開始第一階段的開發工作。
     這裡，對每個程式員來說，首先遇到的或者是資料庫設計、類設計、介面設計這類問題。我們每項功能涉及到哪些表格，這個階段就建立資料庫、設計好這些。類設計原則上是每個程式員針對自己的任務要做的事情，但如果涉及到多個程式員都會遇到的，專案經理必須預先在任務中說明，並且最好先建立空白的類。關於常見的ORM的問題，沒有必要使用某個ORM架構，從我個人的經曆來看，將資料庫當作一個倉庫，放進去、拿出來就行了。出於效能考慮、開發耗時的考慮，依賴某個Orm架構未必是好主意。

    每天專案經理自己判斷，是否有必要詢問哪位：進度慢了？遇到問題了？做的是否有錯？不需要所謂每天的站立會議之類。這個過程中鼓勵程式員多看看項目中其他程式員的代碼，新手初哥，實際上是在模仿的過程中形成團隊接近統一 的風格的。

    至於代碼規範，未必要太講究，只要不是那種慘不忍睹的形式就可以，籠統要求一下，盡量模仿開發環境產生的程式碼的風格就行。專案經理若有時間，或者有耐心，不妨偶爾修改一下程式員的代碼。

 

    程式員完成某項任務，告知專案經理，然後會接到下一項任務。專案經理在合適的時機，執行重要功能測試，並將相應的問題作為bug記錄，並指定人員修複。一項功能的所有任務完成，測試沒有發現問題，開始做下一項，直到這個階段的所有功能開發完畢。此時可以邀請客戶看看效果，一般是由他們自己來操作，記錄下他們的想法和意願，下一階段考慮。

    如此迴圈，直到項目結束。

    小結一下，流程是這樣的：項目目標(幾句話的文檔)->功能清單->劃分階段(包括各階段功能和階段目標說明這樣的文檔)->第一項功能的使用者體驗設計->第一項功能的開發工作單位、問題分配到人-->項目中公用的任務(資料庫、介面體系、公用類設計、說明、安排人員)->程式員逐項完成任務->第一項功能完成->重點功能測試-->開始下一項功能...

   業務細節的文檔，需要寫的時候才寫，作為專案工作安排進去。

    作為專案經理，可以反思一下，自己在編程的時候是什麼狀態：心情不好的時候，是不是會整天沒辦法做事？集中精力做了2個小時，會不會感到頭昏眼花，需要休息3個小時？碰到問題解決不了的時候，連續被掛上好幾天，是不是厭煩到極點，能不能暫時擱置一下？
    其實每個程式員都是這樣的。
    早上可以 出去跑跑步，10分鐘，有氧運動會令大家的心情奇怪的變好一些。程式員進度明顯停滯的時候，要有耐心等待，不要催。可以問問他遇到什麼問題了，可以考慮是否能提出合適的建議。這是很正常的現象。
工作一到兩小時，完全可以集體休息一會，聊聊天。在進度沒有很明顯問題的情況下，不要繃得太緊張。

    進度出現問題的情形下怎麼辦？
    嗯，按照這種過程，一般不會崩潰，因為使用者最需要的功能在前面已經完成了，但你若遇到過於認真的客戶，基本上沒有多少辦法：將不急的功能放在最後，某些功能想辦法說服使用者不做，一些功能用更簡單的辦法實現，要求強手擔負更多的工作，或者專案經理赤膊上陣？我想，這些大家基本上都經曆過。我的意見仍然是：基本上沒有多少辦法-----時間的減少，導致程式品質的下降，是有臨界點的。公司如果在承諾的時間做的是超出能力的工作，軟體過程是不能真正解決這個問題的。

    最後的結果仍然是：加班，前提是專案經理承擔更多。加班的現實作用是增加緊迫感，這可以從外部倒逼程式員有略多的專註工作時間。所謂加班不能解決問題，加班本身就意味著項目失敗這種說法，不適合中國人。

 

     當然，我們需要一套比較簡易的專案管理工具，我使用的是team fundation server，上面提到的階段、功能、任務、問題、bug、測試和原始程式碼控制，基本上都能夠簡單的解決。即使是個人項目，我也使用Tfs。我推薦以基本模式安裝，也就是不用管報表之類的東西，這樣的話備份簡單，備份一個資料庫就行了------複雜的備份過程是很浪費人力、並且抑製備份慾望的，這不安全。

     接下來，我將以私募基金股票分析項目的例子，將上面的過程重現一遍。