——管理措施
最近老板讓我做一個(gè)軟件項目組的管理措施，搜集了多方資料和平時(shí)的一些經(jīng)驗得出以下的一些知識：
在一個(gè)軟件產(chǎn)品發(fā)布并使用之后，其中肯定有許多地方不如意和值得改進(jìn)的地方?？蛻?hù)在使用的過(guò)程中會(huì )發(fā)現一些問(wèn)題，提出更高的需求，市場(chǎng)也在發(fā)生變化，我們的競爭對手也在發(fā)展，新的技術(shù)不斷地產(chǎn)生，這些因素推動(dòng)著(zhù)我們的產(chǎn)品不斷地向前發(fā)展，使軟件版本不停地往上增長(cháng)。這些發(fā)展的需求不是一下子提出來(lái)的，在客戶(hù)使用的過(guò)程中發(fā)現某些不如意不方便的地方，他們會(huì )向我們提出寶貴的意見(jiàn)，而技術(shù)人員會(huì )把這些需求記錄下來(lái)，以便修改或成為下一個(gè)版本的新特性或需求。
一個(gè)軟件的開(kāi)發(fā)主要分為需求、設計、編碼、測試、維護幾個(gè)重要的階段，下面就每個(gè)階段的一些管理措施提點(diǎn)愚見(jiàn)：
1． 需求管理
在進(jìn)入正式開(kāi)發(fā)之前，必須先從用戶(hù)處獲取準確的需求。在這上面花費相當時(shí)間是很必要的。在軟件項目的開(kāi)發(fā)過(guò)程中，需求變更貫穿了軟件項目的整個(gè)生命周期，從軟件的項目立項，研發(fā)，維護，用戶(hù)的經(jīng)驗在增加，對使用軟件的感受有變化，以及整個(gè)行業(yè)的新動(dòng)態(tài)，都為軟件帶來(lái)不斷完善功能 ，優(yōu)化性能，提高用戶(hù)友好性的要求。在軟件項目管理過(guò)程中，項目經(jīng)理經(jīng)常面對用戶(hù)的需求變更。如果不能有效處理這些需求變更，項目計劃會(huì )一再調整，軟件交付日期一再拖延，項目研發(fā)人員的士氣將越來(lái)越低落，將直接導致項目成本增加、質(zhì)量下降及項目交付日期推后。這決定了項目組必須擁有需求管理策略。
在整個(gè)開(kāi)發(fā)周期中期望用戶(hù)的需求一直保持不變是不大可能的，因為用戶(hù)對于如何應用計算機軟件并沒(méi)有一個(gè)成熟的經(jīng)驗。需求變化的原因很多，如：
一開(kāi)始沒(méi)有調研全，需要增加需求；
客戶(hù)需求發(fā)生了變化，需求必須變化；
需求錯誤；
需求不清楚。
基于上述的問(wèn)題，必須對需求進(jìn)行管理，使需求能夠真正成為軟件工程和管理的基線(xiàn)。 一種比較明智的方法是在簽定開(kāi)發(fā)合同（協(xié)議）時(shí)把用戶(hù)需求的改動(dòng)和經(jīng)濟利益掛鉤,如果用戶(hù)增加或改動(dòng)了需求,那么軟件的交付日期可以推遲,費用也應增加。
需求是一項復雜的工作，使用的方法也很多，不同的開(kāi)發(fā)方式有不同的方法，這里簡(jiǎn)單介紹一些相關(guān)的方法：
可行性分析：在允許的成本、性能要求下，分析每項需求實(shí)施的可行性，提出需求實(shí)現相關(guān)風(fēng)險，包括與其它需求的沖突，對外界因素的依賴(lài)和技術(shù)障礙。
快速原型：當用戶(hù)自身對有的需求不十分清楚時(shí)，我們可以建立一個(gè)系統原型，用戶(hù)通過(guò)評價(jià)原型更好地理解所要解決的問(wèn)題。
圖形分析模型：繪制圖形分析模型是編制軟件需求規格說(shuō)明重要手段。它們能幫助分析人員理清數據、業(yè)務(wù)模式、工作流程以及他們之間的關(guān)系，找出遺漏、冗余和不一致的需求。這樣的模型包括數據流圖、實(shí)體關(guān)系圖、狀態(tài)變換圖、對話(huà)框圖、對象類(lèi)及交互作用圖。
數據字典：數據字典是對系統用到的所有數據項和結構的定義，以確保開(kāi)發(fā)人員使用統一的數據定義。在需求階段，數據字典至少應定義客戶(hù)數據項，確?？蛻?hù)與開(kāi)發(fā)小組是使用一致的定義和術(shù)語(yǔ)。
2． 設計管理
項目經(jīng)理把功能模塊分配給每個(gè)開(kāi)發(fā)人員，每個(gè)開(kāi)發(fā)人員把自己相關(guān)的功能模塊收集起來(lái)，同時(shí)預估時(shí)間，其中主要包括寫(xiě)文檔的時(shí)間、開(kāi)發(fā)時(shí)間和單元測試的時(shí)間，一般要求精確到工作日。這些信息返回給項目經(jīng)理，項目經(jīng)理再把本小組人員的任務(wù)和預估時(shí)間發(fā)送給管理層，由管理層對此任務(wù)及進(jìn)度進(jìn)行評估審核，管理層會(huì )根據產(chǎn)品發(fā)布時(shí)間及客戶(hù)需求、市場(chǎng)因素等方面作出選擇，可能某些功能由于時(shí)間緊急會(huì )被推遲到下一個(gè)版本中去。若預估出來(lái)的時(shí)間同預計的產(chǎn)品發(fā)布時(shí)間有較大沖突，而且此功能是本版本中必須得做的，則開(kāi)發(fā)小組會(huì )被要求重新預估時(shí)間，加快開(kāi)發(fā)速度來(lái)達到這個(gè)要求。
雖然這個(gè)開(kāi)發(fā)進(jìn)度時(shí)間是一個(gè)大概的估計時(shí)間，但我們要盡力按照這個(gè)開(kāi)發(fā)進(jìn)度來(lái)執行。作為開(kāi)發(fā)人員每個(gè)星期寫(xiě)一篇周記，描述自己本周所做的工作，根據自己的描述來(lái)評估我們自己的工作，每個(gè)人手上的工作是否按照這個(gè)進(jìn)度在走，是否有人延后了，是否延誤了別人的工作。在周記里每個(gè)人都要報告自己的進(jìn)度，同時(shí)還要報告上個(gè)星期做了什么，正在做什么，以及下個(gè)星期打算做什么。通過(guò)這個(gè)周記，會(huì )讓你覺(jué)得有人在監督你，無(wú)形之中迫使你不斷地督促自己不要使任務(wù)延后，如果有延后的跡象也會(huì )盡早發(fā)現而趕上。若某些經(jīng)過(guò)努力不能趕上，那也沒(méi)有辦法，只能修改原先的進(jìn)度表，因為那是我們的估計與現實(shí)發(fā)生了偏差，我們必須使我們的進(jìn)度表符合實(shí)際情況。
3． 編碼管理
進(jìn)入編碼工作之后，可能會(huì )發(fā)現前面分析或設計階段的某些錯誤，這時(shí)應返回到前面的階段進(jìn)行必要的修改。由于我們用asp.net(c#)語(yǔ)言進(jìn)行開(kāi)發(fā)，因此我們借助了VS2005工具。關(guān)于代碼風(fēng)格，我們基本上套用VS2005中自動(dòng)的代碼格式編排。良好的編碼習慣有利于我們提高整個(gè)團對的開(kāi)發(fā)效率，比如變量的命名、寫(xiě)代碼時(shí)要對類(lèi)及函數提供詳細的注釋及說(shuō)明等，基本做到看它們的說(shuō)明就能知道這個(gè)變量、類(lèi)或函數的功能以及主要算法的實(shí)現原理。在開(kāi)發(fā)過(guò)程中對主要的模塊要編寫(xiě)單元測試，同時(shí)要單元測試先行，當所有的單元測試代碼通過(guò)時(shí)，此功能也就基本上完成了。
我們采用VSS進(jìn)行代碼管理控制，其中存放了此產(chǎn)品的所有源代碼，各個(gè)部分存放在不同的目錄中。每天早上要求開(kāi)發(fā)人員從VSS中獲取最新的源代碼，然后進(jìn)行編譯并開(kāi)始一天的工作。在下班之前理論上要求員工簽入所有當天修改的代碼，在簽入之前要保證編譯是能通過(guò)的。若有誰(shuí)簽入的代碼導致運行失敗則會(huì )被要求某些懲罰措施或警告。有時(shí)我們編寫(xiě)的代碼涉及到多個(gè)文件，而且此改動(dòng)是比較復雜需要花費多天的工作量，如果現在簽入進(jìn)去可能會(huì )導致項目測試通不過(guò)，因為有些代碼沒(méi)有完全完成，而之前的代碼能測試通過(guò)，而且這些代碼基本上不會(huì )涉及到他人，在這種情況下可以不簽入進(jìn)去，直到全部代碼完成能提交測試時(shí)再一起簽入進(jìn)去。
我們的開(kāi)發(fā)是基于網(wǎng)絡(luò )的，在互聯(lián)網(wǎng)高速發(fā)展的今天，代碼的安全也是一個(gè)不容忽視的問(wèn)題，我們要注意代碼的泄漏和丟失，除了掌握一些基本的安全知識以外，還要進(jìn)行代碼的備份（局域網(wǎng)備份和存儲設備備份），這樣在出現意外的情況下可以及時(shí)的恢復系統的正常運行。
4． 測試管理
在開(kāi)發(fā)人員完成了功能模塊后，測試人員開(kāi)始了測試規劃，確定需要測試哪些方面，如何測試及進(jìn)度安排。測試人員需要寫(xiě)許多測試用例、測試報告等，有些測試代碼需要集成測試，有些可能需要進(jìn)行單獨的測試，目的都是為了使產(chǎn)品符合要求，使開(kāi)發(fā)人員容易找出問(wèn)題所在并改正。產(chǎn)品功能是否符合了要求，是否能被發(fā)布是由測試人員決定的，因此測試人員也比較辛苦，責任重大。通過(guò)了每天的測試，還有一些性能測試、兼容性測試、災難測試等需要在產(chǎn)品發(fā)布前進(jìn)行。在完成這些測試之后由測試人員決定本產(chǎn)品是否能發(fā)布出去了。
由于我們每天進(jìn)行著(zhù)測試，因此經(jīng)常有BUG被測試人員發(fā)現，一旦發(fā)現了新的BUG，就會(huì )被添加進(jìn)測試報告中，同時(shí)注明緊急程度，以便開(kāi)發(fā)人員可以及時(shí)進(jìn)行錯誤BUG的修改。需要指出的是我們對BUG的定義比較廣泛，一些新功能也可以作為BUG被提出，只不過(guò)這些BUG級別比較低，讓它們進(jìn)入到下一個(gè)版本中去實(shí)現。因此BUG的創(chuàng )建者也可以是技術(shù)支持人員、市場(chǎng)人員甚至開(kāi)發(fā)人員本身。關(guān)于開(kāi)發(fā)人員本身，因為他可能會(huì )找出一些BUG，有些是其他開(kāi)發(fā)者的，有些可能是此開(kāi)發(fā)者本身的，把這個(gè)BUG添加進(jìn)測試報告中可以幫助開(kāi)發(fā)人員在以后產(chǎn)生新問(wèn)題時(shí)或類(lèi)似的BUG時(shí)有一個(gè)借鑒和思路。
5． 維護管理
后期的軟件維護和管理也是一個(gè)非常重要的任務(wù)。定期的升級服務(wù)和培訓會(huì )讓客戶(hù)對軟件有個(gè)良好的映像。
6． 組織（團隊）管理
軟件項目開(kāi)發(fā)過(guò)程中注重的是團隊精神的發(fā)揮，我們的目標是一個(gè)軟件、系統而不是幾個(gè)模塊的簡(jiǎn)單組合。在軟件開(kāi)發(fā)管理中，不能采用明令制度的方式來(lái)要求何限制開(kāi)發(fā)人員，必須要有辦法激勵人的內動(dòng)力，而激勵人的內動(dòng)力最好的辦法是將付出和收益緊密的結合。團隊精神的凝聚主要的是信任與尊重。正所謂“用人不疑，疑人不用”，如果沒(méi)有基本的尊重與信任，哪里來(lái)的凝聚力，何謂團隊精神？
軟件項目開(kāi)發(fā)人員應該本著(zhù)態(tài)度第一、效率優(yōu)先的工作原則，在平時(shí)的日常工作和生活中，大腦的休息和充足的睡眠可以保證開(kāi)發(fā)人員有個(gè)良好的心態(tài)和精力。也許在IT行業(yè)來(lái)說(shuō)，程序員加班已經(jīng)成為一種佳話(huà)，一種習俗，但我們要制止長(cháng)期的加班和無(wú)效率的加班，在項目不緊張或者無(wú)項目的情況下可以適當的放松、休息來(lái)調節個(gè)人的情緒和精力。
作為軟件開(kāi)發(fā)人員的大部分時(shí)間是在公司里度過(guò)的，因此公司的生活成了大家主要組成部分。員工之間關(guān)系的融洽，交流的暢通顯得非常重要，同時(shí)大家也不想自己的生活這樣枯燥乏味，一直同機器打交道。溝通無(wú)處不在，交流隨時(shí)發(fā)生，有許多關(guān)系是在工作之外建立起來(lái)的。軟件公司內是很容易產(chǎn)生各種矛盾的，因為這是由你的工作性質(zhì)所決定的，比如測試人員或用戶(hù)會(huì )對你的實(shí)現不滿(mǎn)意，提出各種要求時(shí)，我相信你有時(shí)會(huì )有所抱怨的，無(wú)形之中就產(chǎn)生了對立，發(fā)展到后來(lái)會(huì )有抵觸心理。我相信大部分人都會(huì )有此感受，這不是你的錯，這主要是由我們的工作性質(zhì)決定的。如果你的工作是把財富帶給對方，則對方會(huì )非常歡迎你的到來(lái)，把你奉為財神爺來(lái)對待，同你的關(guān)系會(huì )非常融洽友好。因此我們需要在工作之外來(lái)消除這種對立矛盾的關(guān)系，建立一種融洽的工作氛圍。我們在平時(shí)吃飯的時(shí)候飯桌上大家互相聊天溝通，說(shuō)一些幽默笑話(huà)之類(lèi)的，給我們緊張的工作增加點(diǎn)輕松的氛圍。隔斷時(shí)間大家可以組織一下活動(dòng)，增加了公司的凝聚力。一個(gè)產(chǎn)品發(fā)布后組織一次活動(dòng)，讓繃緊的神經(jīng)松弛一下，更好地迎接下一個(gè)挑戰。
團隊的每個(gè)成員都會(huì )養成寫(xiě)Blog的習慣。經(jīng)常寫(xiě)寫(xiě)Blog，一是可以讓大家都知道自己在做什么事情，二是項目結束時(shí)方便寫(xiě)最后的工作總結（許多工作自己當時(shí)不紀錄也忘記了），三是利于提高自己的水平（工作和學(xué)習寫(xiě)點(diǎn)總結會(huì )系統的總結和歸納思路，進(jìn)步很快）。
附件：
1． C#編碼規范.doc
2． 個(gè)人周記.doc
3． 項目組周報.doc
4． 項目總結報告.doc
5． 測試文件.xls
項目附件下載
聯(lián)系客服
