軟體開發（團隊管理）

                                                                             軟體項目開發

                  ——管理措施

        最近老闆讓我做一個軟體項目組的管理措施，搜集了多方資料和平時的一些經驗得出以下的一些知識：
        在一個軟體產品發布並使用之後，其中肯定有許多地方不如意和值得改進的地方。客戶在使用的過程中會發現一些問題，提出更高的需求，市場也在發生變化，我們的競爭者也在發展，新的技術不斷地產生，這些因素推動著我們的產品不斷地向前發展，使軟體版本不停地往上增長。這些發展的需求不是一下子提出來的，在客戶使用的過程中發現某些不如意不方便的地方，他們會向我們提出寶貴的意見，而技術人員會把這些需求記錄下來，以便修改或成為下一個版本的新特性或需求。

一個軟體的開發主要分為需求、設計、編碼、測試、維護幾個重要的階段，下面就每個階段的一些管理措施提點愚見：

1．    需求管理

在進入正式開發之前，必須先從使用者處擷取準確的需求。在這上面花費相當時間是很必要的。在軟體項目的開發過程中，需求變更貫穿了軟體項目的整個生命週期，從軟體的項目立項，研發，維護，使用者的經驗在增加，對使用軟體的感受有變化，以及整個行業的新動態，都為軟體帶來不斷完善功能 ，最佳化效能，提高方便使用性的要求。在軟體專案管理過程中，專案經理經常面對使用者的需求變更。如果不能有效處理這些需求變更，專案計劃會一再調整，軟體交付日期一再拖延，項目研發人員計程車氣將越來越低落，將直接導致項目成本增加、品質下降及項目交付日期推後。這決定了項目組必須擁有需求管理原則。

在整個開發週期中期望使用者的需求一直保持不變是不大可能的，因為使用者對於如何應用電腦軟體並沒有一個成熟的經驗。需求變化的原因很多，如：  

　　一開始沒有調研全，需要增加需求； 

　　客戶需求發生了變化，需求必須變化； 

　　需求錯誤； 

需求不清楚。

基於上述的問題，必須對需求進行管理，使需求能夠真正成為軟體工程和管理的基準。 一種比較明智的方法是在簽定開發合約（協議）時把使用者需求的改動和經濟利益掛鈎,如果使用者增加或改動了需求,那麼軟體的交付日期可以延遲,費用也應增加。 

需求是一項複雜的工作，使用的方法也很多，不同的開發方式有不同的方法，這裡簡單介紹一些相關的方法：  

可行性分析：在允許的成本、效能要求下，分析每項需求實施的可行性，提出需求實現相關風險，包括與其它需求的衝突，對外界因素的依賴和技術障礙。  

快速原型：當使用者自身對有的需求不十分清楚時，我們可以建立一個系統原型，使用者通過評價原型更好地理解所要解決的問題。  

圖形分析模型：繪製圖形分析模型是編製軟體需求規格說明重要手段。它們能協助分析人員理清資料、業務模式、工作流程以及他們之間的關係，找出遺漏、冗餘和不一致的需求。這樣的模型包括資料流圖、實體關聯圖、狀態變換圖、對話方塊圖、對象類及互動作用圖。  

資料字典：資料字典是對系統用到的所有資料項目和結構的定義，以確保開發人員使用統一的資料定義。在需求階段，資料字典至少應定義客戶資料項目，確保客戶與開發小組是使用一致的定義和術語。   

2．   設計管理

專案經理把功能模組分配給每個開發人員，每個開發人員把自己相關的功能模組收集起來，同時預估時間，其中主要包括寫文檔的時間、開發時間和單元測試的時間，一般要求精確到工作日。這些資訊返回給專案經理，專案經理再把本小組人員的任務和預估時間發送給管理層，由管理層對此任務及進度進行評估審核，管理層會根據產品發布時間及客戶需求、市場因素等方面作出選擇，可能某些功能由於時間緊急會被延遲到下一個版本中去。若預估出來的時間同預計的產品發布時間有較大衝突，而且此功能是本版本中必須得做的，則開發小組會被要求重新預估時間，加快開發速度來達到這個要求。

雖然這個開發進度時間是一個大概的估計時間，但我們要儘力按照這個開發進度來執行。作為開發人員每個星期寫一篇周記，描述自己本周所做的工作，根據自己的描述來評估我們自己的工作，每個人手上的工作是否按照這個進度在走，是否有人延後了，是否延誤了別人的工作。在周記裡每個人都要報告自己的進度，同時還要報告上個星期做了什麼，正在做什麼，以及下個星期打算做什麼。通過這個周記，會讓你覺得有人在監督你，無形之中迫使你不斷地督促自己不要使任務延後，如果有延後的跡象也會儘早發現而趕上。若某些經過努力不能趕上，那也沒有辦法，只能修改原先的進度表，因為那是我們的估計與現實發生了偏差，我們必須使我們的進度表符合實際情況。

3． 編碼管理

進入編碼工作之後，可能會發現前面分析或設計階段的某些錯誤，這時應返回到前面的階段進行必要的修改。由於我們用asp.net(c#)語言進行開發，因此我們藉助了VS2005工具。關於代碼風格，我們基本上套用VS2005中自動的代碼格式編排。良好的編碼習慣有利於我們提高整個團對的開發效率，比如變數的命名、寫代碼時要對類及函數提供詳細的注釋及說明等，基本做到看它們的說明就能知道這個變數、類或函數的功能以及主要演算法的實現原理。在開發過程中對主要的模組要編寫單元測試，同時要單元測試先行，當所有的單元測試代碼通過時，此功能也就基本上完成了。

我們採用VSS進行代碼管理控制，其中存放了此產品的所有原始碼，各個部分存放在不同的目錄中。每天早上要求開發人員從VSS中擷取最新的原始碼，然後進行編譯並開始一天的工作。在下班之前理論上要求員工簽入所有當天修改的代碼，在簽入之前要保證編譯是能通過的。若有誰簽入的代碼導致運行失敗則會被要求某些懲罰措施或警告。有時我們編寫的代碼涉及到多個檔案，而且此改動是比較複雜需要花費多天的工作量，如果現在簽入進去可能會導致項目測試通不過，因為有些代碼沒有完全完成，而之前的代碼能測試通過，而且這些代碼基本上不會涉及到他人，在這種情況下可以不簽入進去，直到全部程式碼完成能提交測試時再一起簽入進去。

我們的開發是基於網路的，在互連網高速發展的今天，代碼的安全也是一個不容忽視的問題，我們要注意代碼的泄漏和丟失，除了掌握一些基本的安全知識以外，還要進行代碼的備份（區域網路備份和存放裝置備份），這樣在出現意外的情況下可以及時的恢複系統的正常運行。

4．   測試管理

在開發人員完成了功能模組後，測試人員開始了測試規劃，確定需要測試哪些方面，如何測試及進度安排。測試人員需要寫許多測試案例、測試報告等，有些測試代碼需要整合測試，有些可能需要進行單獨的測試，目的都是為了使產品符合要求，使開發人員容易找出問題所在並改正。產品功能是否符合了要求，是否能被發布是由測試人員決定的，因此測試人員也比較辛苦，責任重大。通過了每天的測試，還有一些效能測試、相容性測試、災難測試等需要在產品發布前進行。在完成這些測試之後由測試人員決定本產品是否能發布出去了。

由於我們每天進行著測試，因此經常有BUG被測試人員發現，一旦發現了新的BUG，就會被添加進測試報告中，同時註明緊急程度，以便開發人員可以及時進行錯誤BUG的修改。需要指出的是我們對BUG的定義比較廣泛，一些新功能也可以作為BUG被提出，只不過這些BUG層級比較低，讓它們進入到下一個版本中去實現。因此BUG的建立者也可以是技術支援人員、市場人員甚至開發人員本身。關於開發人員本身，因為他可能會找出一些BUG，有些是其他開發人員的，有些可能是此開發人員本身的，把這個BUG添加進測試報告中可以協助開發人員在以後產生新問題時或類似的BUG時有一個借鑒和思路。

5．   維護管理

後期的軟體維護和管理也是一個非常重要的任務。週期性升級服務和培訓會讓客戶對軟體有個良好的映像。

6． 組織（團隊）管理

軟體項目開發過程中注重的是團隊精神的發揮，我們的目標是一個軟體、系統而不是幾個模組的簡單組合。在軟體開發管理中，不能採用明令制度的方式來要求何限制開發人員，必須要有辦法激勵人的內動力，而激勵人的內動力最好的辦法是將付出和收益緊密的結合。團隊精神的凝聚主要的是信任與尊重。正所謂“用人不疑，疑人不用”，如果沒有基本的尊重與信任，哪裡來的凝聚力，何謂團隊精神？

軟體項目開發人員應該本著態度第一、效率優先的工作原則，在平時的日常工作和生活中，大腦的休息和充足的睡眠可以保證開發人員有個良好的心態和精力。也許在IT行業來說，程式員加班已經成為一種佳話，一種習俗，但我們要制止長期的加班和無效率的加班，在項目不緊張或者無項目的情況下可以適當的放鬆、休息來調節個人的情緒和精力。

作為軟體開發人員的大部分時間是在公司裡度過的，因此公司的生活成了大家主要組成部分。員工之間關係的融洽，交流的暢通顯得非常重要，同時大家也不想自己的生活這樣枯燥乏味，一直同機器打交道。溝通無處不在，交流隨時發生，有許多關係是在工作之外建立起來的。軟體公司內是很容易產生各種矛盾的，因為這是由你的工作性質所決定的，比如測試人員或使用者會對你的實現不滿意，提出各種要求時，我相信你有時會有所抱怨的，無形之中就產生了對立，發展到後來會有抵觸心理。我相信大部分人都會有此感受，這不是你的錯，這主要是由我們的工作性質決定的。如果你的工作是把財富帶給對方，則對方會非常歡迎你的到來，把你奉為財神爺來對待，同你的關係會非常融洽友好。因此我們需要在工作之外來消除這種對立矛盾的關係，建立一種融洽的工作氛圍。我們在平時吃飯的時候飯桌上大家互相聊天溝通，說一些幽默笑話之類的，給我們緊張的工作增加點輕鬆的氛圍。隔斷時間大家可以組織一下活動，增加了公司的凝聚力。一個產品發布後組織一次活動，讓繃緊的神經鬆弛一下，更好地迎接下一個挑戰。

團隊的每個成員都會養成寫Blog的習慣。經常寫寫Blog，一是可以讓大家都知道自己在做什麼事情，二是項目結束時方便寫最後的工作總結（許多工作自己當時不紀錄也忘記了），三是利於提高自己的水平（工作和學習寫點總結會系統的總結和歸納思路，進步很快）。

附件：

1．              C#編碼規範.doc

2．             個人周記.doc

3．             項目組周報.doc

4．             項目總結報告.doc

5．             測試檔案.xls
項目附件下載