把握敏捷的實質

很多人非常推崇敏捷，我也是這樣，我們的團隊採用的就是敏捷開發方法，但是不少同行在討論敏捷的事後，通常把敏捷中的一些形式看得很重，例如迭代、例如story等，這裡就我們的體會來和大家做一些探討。

首先，雖然有很多異議，但是我個人認為軟體開發的基本模型仍然是瀑布法，任何一個軟體系統，它一定要經歷分析、設計、編碼、測試，才能物理上被生產出來，才能成為最終的交付實體交付給客戶，所以無論討論什麼開發模型，歸根到底，其本質仍然離不開這個最基本的瀑布模型。

其次，敏捷開發方法實際上是瀑布模型的一個變種而已。就象很多人貶低PO（程式導向），而推崇OO一樣。軟體系統的本質不過就是演算法＋資料，只不過PO把這個工作做得太早，在巨集觀的層面上就做這種分解，以至於設計出來的系統顯得太剛性了；而OO的好處不過是把這個工作推遲了，先按照物件分解問題域，然後在比較小的顆粒上在做演算法和資料的分離。所以本質上OO也是PO的一種變異。對於敏捷模型來講，與通常的瀑布模型最大的差異就是把一個完整的系統切成若干小份，然後在每個小份裡在採用瀑布模型完成小系統的開發工作，最後拼接成為一個完整的大系統。

所以，敏捷模型與OO方法其實有著異曲同工之妙。在現實中的一個情況是，任何一個系統，在開發伊始，開發人員都是不可能知道完成的最終結果是什麼樣子，而且客戶也說不清楚，開發所依據的需求會在開發的過程中不斷明晰、也在不斷變動，這樣敏捷模型可以保證開發組先把知道的做了，不知道的、或者要變動的部分可以放在後面完成，這樣一個個迭代，步步為營，一直到把開發任務完成。

不過，和瀑布模型一樣，這種基於敏捷、採用迭代模式的開發方法仍然是一種理想的期望。這段時間也和很多朋友聊過這個話題。其實從國外傳過來的敏捷模型在實踐中往往和XP混在一起，我們且不論這種概念是否正確，但是就面向應用場景來講，如果按照這種模式開發系統，那麼其基礎就是要有一群優秀的程式設計師，能夠通過彼此默契地配合來在程式上適應各種需求的變化。事實上，對於一個軟體系統，尤其是行業客戶的應用系統來講，這樣是極度危險的。因為這種模型對開發團隊的要求太高了，每個程式設計師都要是業務專家、都是架構師、都是溝通高手，而在國內的環境下，這種黃金團隊又有多少呢？如果存在，一般肯定是找著投資，自己創業了。

其實，討論開發模型一定不能離開“人”這個因素。每個公司的開發模型之所以有所差別，其實也就是每個公司的人是不同的，人所處的環境也是不同的。一個開發模型的優劣，其實關鍵不是看它採用哪種先進的方法，而是它能夠在多大程度上剔除“人”的因素。所以，從本質上講，其實我是推崇瀑布模型的。因為在瀑布模型的情況下，每一步的成果都是穩定的，這樣，即使人員出現變動，損失的也就是本階段的成果而已。當然，在現實中，瀑布模型確確實實是有著很多弊病，我們要做的其實是利用敏捷的一些思想，來優化傳統的開發方法。所以，說到這裡，我們就有了一個結論，就是瀑布是本，敏捷是末！

開發一個系統，最關鍵的就是通盤考慮，雖然正統的敏捷方法反對這樣做。通盤考慮的事情主要是在業務上，要能夠在較短地時間裡，把握客戶業務的一些抽象模型，建立業務架構，這樣才可能對客戶的需求有所預測，設計的系統才可能就有一些前瞻性。系統開發的一半以上的工作要做業務分析階段完成，開發的難度要能夠通過業務的調整來簡化。其次是架構設計，架構設計絕對不是做程式架構，而是基於業務架構能夠在領域裡建立一些應用層次的通用模型，這樣把系統未來的擴充套件方向和內容給固定下來。這樣業務預測加上系統預測，三分天下，已據其二了。

上面的工作儘量一次做好，做不好的，也要在架構層面進行預測，在這樣的基礎上，再通過迭代，逐步把系統實現，這樣系統開發的成功率自然也就要高出很多了。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/190707/viewspace-612981/，如需轉載，請註明出處，否則將追究法律責任。