關於X項目的報告這個項目我是從2005年下半年開始聽說的，是一個規模比較大的項目，項目總共涉及10多個城市，包括了遺留系統的資料轉換、新系統的需求調研、系統設計、系統開發、系統測試、系統實施等流程。正式進入這個項目是在2006年3月，一開始我在做某業務系統的功能部分，後來做業務系統與其他系統的介面部分，期間交替進行著兩三個項目。系統架構基本是照搬其他地方的系統，增加了一些自己的東西，經過06年一年的開發，到07年初，系統上線了2個城市，一直運行至今，其中各種各樣的問題出了很多，五花八門，使人甚是疲倦。背景就介紹到這裡，下面列舉一些我所看到的項目之中的問題以及一些想法。排名不分先後，如有雷同，純屬巧合。:)癥狀1，迭代式瀑布開發。項目伊始，明確要求採用RUP方法，並且貫徹迭代。在計劃中也可以看到各個迭代，但是一年的開發時間，只有4個迭代周期。例如有100個模組，那麼每個迭代中分25個，在最後一個迭代中做整合測試和效能測試，所以我稱之為“迭代式瀑布開發”，這就為後來的部分功能存在功能和效能問題埋下了伏筆。迭代的威力並沒有體現出來。猛藥1，洗腦+扣錢，對項目中從上到下反覆洗腦，並且注重平時檢查，防止重回老路。 癥狀2，空中樓閣。這個系統的資料庫結構是從其他地方挖過來的，挖過來後對這個項目的需求所做的妥協很小。再說說需求，這個項目中的需求只有一份，調研的時間很短，卻要適應多個城市的各種情況，所以最後的結果就是似是而非，這在系統上線時反映的極其明顯，需求震蕩變動，需求文檔垃圾化。猛藥2，需求調研是系統方向，方向都不正確，怎麼能有一個良好的結果。滿足需求的多樣性與系統的複雜度是成正比的，如果為了滿足各個城市的需要，則在需求調研是必須深入瞭解各個地市的差異，並做比較甄別。我一直對需求調研有一種看法，需求調研人員不應該只是開會，巴望著能從會議中得到使用者的需求，做夢。不深入下去，不真正參與使用者的日常工作，怎麼能知道使用者真正需要什麼，使用者需要你給他一些professional的建議。 癥狀3，摸著石頭過河+走鋼絲。如此大的一個項目，眾多的功能，沒有單元測試來保證，尤其在應對頻繁變動的需求時，往往就是開發人員改完簡單測試一下，就交給現場發布，可想而知。猛藥3，真的迭代+每日構建。 癥狀4，溝通還是溝通。開發出來的系統，是由專門的人員來實施，但是問題來了，實施人員對系統的理解甚至還不如使用者。造成開發人員陷入現場的泥潭之中。猛藥4，帶考核的培訓+責任心教育+壓力的教育。 癥狀5，群起而攻之。這個系統十分龐大，與外部其他機構的介面就有10多個，但是這些介面所遵循的規範只有一個，這自然在開發上簡單了，但是造成的工作被動的局面，不同的地方、不同的機構並不會統一這唯一的介面方案。猛藥5，不應迴避需求，對使用者真正的需求避而不見。不存在放之四海而皆準的需求，除非這些需求除了廢話什麼也說明不了。與其四處受敵，不如主動出擊。 癥狀6，建立在沙子上的大廈。遺留改造系統能歡快的跑下來的充分條件是資料。當資料都不準確，甚至漏洞百出時，程式首當其衝會成為受害者。這個系統的資料轉換工作曆時1年，其中真正有效轉換時間也就1-2個月，直到上線前，也沒有對資料進行完整的測試。猛藥6，測唄，還有啥好說的。 癥狀7，我們是戰友而不是敵人。項目中的各個組成部分和使用者之間都是互惠互利的關係，不應成為敵人，一榮俱榮，一損俱損。項目中的各個組成部分來自五湖四海，人在江湖飄啊，怎能不挨刀。猛藥7，加強團隊精神建設，打造“膠凍團隊”。 上面說了一些我自己的體會，有一些其他的癥狀就不在這裡廢話了。對於不同的項目應該會有不同的充要條件，但其中應包括下面這幾個（想到的就寫下了，沒有先後順序）：l 大家認可的目標l 每日構建l 強烈的榮譽感和責任心l 項目組的文化和核心精神l 優秀的過程和方法l 執行能力 Wonder 2007-6-1祝所有的小朋友和即將成為小朋友的小寶寶們六一節快樂！希望你們每個人都能有自己喜歡的禮物。
