軟體項目開發系列—開篇雜談

最近在整理部門內部的培訓材料，希望通過培訓和在項目中的實踐來提升整個團隊的分析和設計能力，同時也是自己所瞭解的一點知識的總結。

談到軟體開發，一個項目的成敗，關鍵因素是人的因素，人就是一切，或者說幾乎是一切。對於項目的成功來所，項目人員的素質、人員的組織和管理是比其它工具或技術方法更重要。團隊品質直接決定項目的成功和失敗，團隊的溝通能力，協作能力尤為重要，一個高效的團隊一定是溝通能力很強的團隊，我們所從事的軟體項目，其實不是在研發新技術，而是利用別人的研究成果而已，只是成果的應用，說白了沒有什麼“純”技術含量，這裡純加了引號，如今是個知識爆炸的時代，互連網高度發達，你需要什麼資訊，只要有時間，一般都能找到相關內容。所以說軟體項目的開展，更側重於社會性，而不是科學性。軟體開發本身是一個複雜性活動，著名的“沒有銀彈”中介紹過，複雜性是軟體開發的根本屬性，短期內不會有任何的工具或方法會使軟體生產率有數量級的提升。它是一個複雜的純思維的活動，這個世界同時又成千上萬個軟體項目在開展，但是沒有任何兩個是完全一樣的。相同的功能，可以有上百個實現，一個功能，可能用一個類實現，也可能5個、10個類，但是為什麼是5個類，而不是3個，沒有定型的優劣之分。只有掌握了合適的方法，總結前人的經驗成果，研究較好的或經典設計，並在項目中實踐應用，才能逐步提升自己的能力水平。

我們以往的項目中存在的問題，多是需求方面，沒有掌握一個好的需求方法，程式大都是面向過程的，即結構化分析方法，或用著物件導向的工具乾著面向過程的活。這和人員水平有著直接的關係。需求方面，怎樣挖掘用戶深層次需求？用戶所說的是不是就是對的？怎樣確認和驗證需求的正確性？有著一系列的問題。其實是有方法可以解決的。系統分析人員要瞭解甚至精通使用者的業務領域，成為業務專家，但現實往往不是這樣，那我們怎樣驗證需求呢？其實使用者的目標有時使用者自己都不是太清楚，系統分析員需要通過一定的方法引導使用者，和設計人員一起協助使用者逐步地清晰目標，這本身就是一個迭代演化的過程，不是通過需求階段完成後通過簽署需求規格說明書就算完了的。我們可以通過原型，和不同迭代周期的產品，頻繁的使使用者參與反饋，強調使用者的反饋和改寫。在早期降低關鍵風險，最終提供使用者想要的系統。

大家都知道，結構化分析方法在處理一些業務不是太複雜的系統時是快速高效的，但是很難處理高複雜性業務時就難以應付了，這樣在後續維護上造成很大麻煩。這就涉及到了系統分析方法的問題了，面向過程和物件導向本身沒有好壞之分，只有適合不適合，看你用在什麼場合，本質都是我們認識這個世界的方法。這些技術都是重要的，但什麼是面向過程?什麼是物件導向?二者有什麼區別?今天也不早了，我們在下次再討論。

未完待續