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