曾因項目的迫切需要計劃開發一打包軟件,最終卻夭折?，F在回想多有遺撼。不得不令我反思當中的教訓。
我認為要想開發一個成功的軟件兩個大的環境是必不可少的，一個是外部環境，包括公司的支持，領導的鼓勵和擁有一個穩定的，成熟的項目團隊，相對穩定的用戶群體。還有一個是對軟件本身的規劃，包括對需求的明確，系統的架構，工作量的評估，明確的項目計劃和有序的計劃執行。
打包工具的失敗就是一個印證。
打包工具的構想是源于項目中，繁鎖的，重復的人工打包操作，包括從配置庫一下代碼，編譯，打包，上傳FTP等操作，由于打包后進行問題驗證時又時常出問題，所以該過程不得反復多次執行。執行過程中又難免出現放錯文件，漏打文件等不必要的錯誤從而嚴重影響項目進度。
打包工具就是為解決打包過程中的繁鎖操作，提供可視化界面，為打包提供一鍵式操作。一開始構想時好的。但是一開始也是錯的，因為打包工具一開始就缺乏一個可供運作的外部環境。公司不知道有這個項目的存在，或許還稱不上是一個項目，因為它只是我個人提出的一個優化項目流程的簡單方案。但是也由于這個問題，為項目的失敗埋下了一個定時炸彈。
開始對項目進行簡單的規劃后，包括簡單的需求分析，系統的架構。沒有正式的文檔，也沒有對文檔進行評審和風險評估。就開始著手開發了。開發過程中不斷的變更架構（因為一開始就沒有一個好的架構），不斷的變更需求（雖然需求是自己做的），沒改一個地方，對代碼都是翻天覆地的變化，當中的辛酸或許只有我自己才能體會。先拋開架構不說，為什么自己做的需求，自己開發，需求都還會變呢？那是因為在開發過程中，你站在用戶的角度一想，發現那樣做確實不當，得改。這就告訴我們問題越早發現，就越容易被解決。想想如果該需求是在需求文檔中詳細體現出來，在需求評審的時候被發現，那改改文檔也就了事了，等到了開發時才發現這個問題，想想那個時候去改那又會有多大的改動。這也告訴我們好的文檔不僅能有效的指導開發，提高質量。也能更及時的發現問題，避免不必要的改動。更是后期維護升級的一個依據。
當然這些變化還不足以讓一個項目夭折。打包工具一開始規劃其中一部份包含了對開發人員的代碼進行檢視等功能，但由于公司推出了一個工具已經具備這一功能，使得打包工具的這一需求已不在具備這一用戶群體。所以穩定的用戶群體在一個軟件開發過程中也是一個不可忽視的環節。
在項目開發到中期，我被分配到一個實際項目中，由于沒有多余的時間來做這個不被重視的工具，打包工具開始慢慢夭折。從這個事分析，我個人其實也算是這個項目的一個穩定項目團隊。我被分配到其它項目中就算是為這個穩定的團隊帶來了不穩定因素。結果導致項目夭折。可見一個穩定的，成熟的項目團隊在項目中的重要性。
這個項目雖然失敗了，但我從中吸取了很多教訓。如果再給我一次機會來做這個項目，有幾個事情我必須得做。
1,向公司審請，將該項目作為公司內部項目正式立項。確保有一個穩定的外部環境。
2,向廣大用戶(開發人員)收集需求，整理形成軟件的基本規格。
3,明確制定項目計劃，有組織，有目地的進行研發。
4,根據基本規格編寫需求文檔，明確功能點，進行大眾評審，及時發現問題。
5,制定詳細的架構規劃。進行評審。
6,協調有扎實功底的開發人員，確保技術難題被攻破
7,協調有豐富經驗的測試人沒，保證版本質量
作者：caoyinghui1986 發表于2009-8-28 21:27:00
原文鏈接