一個政府項目總結
近幾天剛剛交付驗收了一個政府的軟件項目，在這個項目的開發(fā)過程中遇到了不少困難，包括技術上的障礙和一些實際的人為上的問題。一個項目之所以能成功，能讓客戶滿意，領導放心的原因可能大多都差不多，大多都是老生長談的那幾條。但是一個項目失敗的原因卻各有各的不同。下面再根據(jù)自己的體會寫一些項目總結，一為了總結不足，積累經驗，二為了以后項目中避免犯同樣的錯誤。
一.要和客戶有足夠有效的溝通
和客戶的溝通要貫穿整個項目開發(fā)的始終，從立項調研，需求獲取到最后的驗收測試，后期維護。
1.要盡量多的主動跟客戶溝通
客戶一般工作都很忙，所以要通過多種方式和客戶保持溝通，電子郵件，電話，座談，調查，會議等。最初的需求盡量保證有幾次所有與項目相關的部門和人員都能參加的討論會，把他們的各自的工作都描述一下，盡量不要遺漏，都羅列出來，因為這是原始需求。這往往不容易做到，因為政府部門很難抽出時間把各部門人員集中在一起來做這些事情的，但是我們必須得這樣要求他們，要求他們把這個看成一項工作來抓，因為前期工作做不充分，后面的開發(fā)會不會很成功。在對某個功能或者需求不能確定的情況下，最好能整理成列表文檔發(fā)給客戶，讓客戶以電子版的形式重新描述一下發(fā)過來，盡量不要經常打電話騷擾客戶，要集中把要了解東西發(fā)給客戶，以便他們集中精力來處理你問的問題。
2.要盡量保證有效的溝通
每次溝通要有一定的目的性，把溝通交流的結果用文檔的形式保存下來；需求制訂出來要得到客戶的確認，在經過幾次反復之后會得到一個相對比較穩(wěn)定的需求，雖然客戶的需求不可能一直不變，這也是很多人搞項目頭疼的地方，但是我認為客戶的需求實際上是很少改變的，改變的是你對客戶需求的理解。對客戶的每一個要求都要重視，尤其是客戶后來提到的一些改動建議，要讓他們以書面的形式發(fā)過來，必要的時候要求負責人蓋章簽字，我們不能為了下面的下面的一個小辦事員隨便打個電話就對程序做出大的改動。再改動比較大的情況下，我們可以要求客戶對合同的變更追加費用，前提是把需求做為合同的附件加進去，防治最后驗收的時候造成爭執(zhí)。
3.和客戶溝通要找準對象
一般企業(yè)或者政府都有專門負責信息的人員，而且最好要求客戶那邊找一個人專門負責這個項目。這樣找對方了解需求的時候就不會出現(xiàn)不知道找誰的情況，客戶那邊有專人負責會帶來很多好處，這個項目就是因為客戶那邊負責這個項目的人員經常更換而為我們項目的開發(fā)造成了很多的不變。
二.提高開發(fā)效率和保證項目質量
政府的項目一般都是開始的時候不著急，你催他們準備資料他們也不著急，但是一旦他們把資料準備全了，都交給你了就著急了，要求對方在很短的時間內保證質量的把項目交付。所以如何提高開發(fā)效率和保證項目質量是確保項目成功的關鍵。
1.保證良好充分的測試
當然軟件測試的范疇很大，但是為了趕進度我們往往不能不保證進行所有的軟件測試。軟件的測試也是遍布整個項目開發(fā)周期的，我了解了一下TDD，TDD的思想很好，很適合開發(fā)中小型的項目，實施起來也很方便，但是不能純粹的用敏捷開發(fā)的理論，必要的文檔還是需要的。我認為代碼模塊的單元測試，開發(fā)最后階段的集成測試和部署后的整體功能測試和用戶驗收測試是必不可少的。項目進度再緊張也要進行單元測試，只要保證單元測試能通過，以后代碼可以慢慢重構。集成測試保證項目各個模塊能良好的協(xié)作共同完成復雜的任務，這點不能保證的話，展示給客戶的最終功能就不能保證。而功能測試和用戶驗收測試是純粹的黑盒測試，自己內部人員先對照原始客戶的需求進行功能測試，列出BUG列表，經過幾次反復修改后給客戶一個可以進行驗收測試的系統(tǒng)。
2.保證相對必要的文檔以及保證文檔的可用性
每個模塊的文檔要獨立起來，要實現(xiàn)的目標，測試的結果，模塊所用的數(shù)據(jù)庫的結構，存儲過程，設計思路，調用的接口等這些是必須的。我也不建議面面俱到的文檔，但必要的需求文檔，模塊文檔，測試文檔是必須的，我們的項目小的不足以讓我們去學習龐大的RUP什么的。
3.迭代開發(fā)
剛開始可以根據(jù)客戶的需求弄出一個藍圖來，交給客戶看，以便讓客戶能盡量早的知道最終的開發(fā)出來的系統(tǒng)是什么樣子的，這個藍圖要盡量直觀，一般在需求整理完畢后一周就能出來，這也是指導以后開發(fā)工作的東西，要完整的包含所有的域模型，便于開發(fā)人員對問題域的理解。然后把優(yōu)先級最高的一系列功能完整后出一個DEMO版給客戶，要讓客戶盡量早的發(fā)現(xiàn)正在制作的項目和用戶想要的結果的之間的偏離和差距，告訴你后以便你盡早的調整，別等你的正式版出來后用戶發(fā)現(xiàn)這個功能你做的不對，你就傻了，那時候要改動的地方就太多了。然后再弄完善一下給用戶個beta版，這時候就已經接近最終版本了，可能還有一些小BUG。最后把小BUG完善修復一下給客戶正式版1.0讓客戶驗收。至于二期項目以后再說，先把一期項目的余款結了再說，對吧。
4.制訂開發(fā)規(guī)范
開發(fā)規(guī)范訂的太死會限制程序員，每個開發(fā)人員都會有一些習慣，但是為了協(xié)作，制訂一個相對通用的規(guī)范是有必要的。包括文檔的規(guī)范，數(shù)據(jù)庫設計規(guī)范，編碼規(guī)范以及各種命名規(guī)則。盡量用一些業(yè)界通用的規(guī)范，網上都有，我CSDN的博客上也整理了一些，MSDN的類庫開發(fā)人員指南里面也有一些。盡管某些規(guī)范很有爭議，我感覺你也得選擇其中一種來做為你的項目開發(fā)規(guī)范。
5.建立開發(fā)基礎
保證機器和軟件的可用，盡量大的內存，盡量快的處理器，操作系統(tǒng)，開發(fā)工具都要到位，該想到的就得想到，還要給開發(fā)人員一個相對安靜舒適的環(huán)境，最好能很方便的喝到冰箱里的可樂，而且能在累的時候有綠色的植物看。再一個就是建立一個開發(fā)基礎結構，這個也頗有爭議，幾乎每個公司都有自己的系統(tǒng)類庫，開發(fā)框架以及配套的代碼生成工具，這都很好，在開始可以對員工做適當?shù)呐嘤枺屗麄兌寄荏w驗自底向上設計的好處，都能用的上這個架構，你可以在架構中要求開發(fā)人員以指定的方式實現(xiàn)某些通用的任務，比如說日志記錄和錯誤處理等，而不是讓他們使用自己習慣的方式去處理問題，因為.NET的靈活性讓實現(xiàn)一個任務有很多中方案和手段。
小節(jié)：雖然這個帖子沒有討論具體技術，而且都是一些空話套話，并且這些空話套話可能別人也都說的不帶說了，但我感覺還是有必要自己總結一下的。
http://onlytiancai.cnblogs.com/archive/2005/11/03/218335.html