探秘軟體開發的另一極（1）

　　有人形象地將“瀑布式”開發與“敏捷開發”描述成為軟體開發的兩極。瀑布式開發從開發伊始就定義出軟體架構，然後進行模組開發與組裝。敏捷開發則根據細化的需求直接開發軟體，並利用迭代方式逐漸組建出大的軟體系統。

　　對於瀑布式開發，人們耳熟能詳。但是對于敏捷開發這一極，可能所知甚少。日前，ThoughtWorks首席科學家Martin Fowler、ThoughtWorks中國公司總經理Sidney G.Pinney與中國電腦報進階副總編郭旭的一番對話將協助你瞭解敏捷開發的奇妙世界。

　　敏捷開發與人

　　面對軟體成敗的關鍵因素是什麼這一問題，在軟體架構、開發方法與人三個因素中，Martin Fowler毫不猶豫地選擇了人。那麼敏捷開發與人是一個什麼樣的相互依存關係呢？

　　郭旭：您曾提到軟體開發過程中人最重要。那麼，相對於傳統的開發方法而言，敏捷開發對於Team Dev的人員有些什麼特殊的要求？

　　Martin Fowler：目前為止，我們還沒有相關驗證表明什麼樣的人能在敏捷方法裡面表現得更好。但是有一點值得注意，不管採用什麼樣的方法，人的素質與水平都會對項目造成至關重要的影響。

　　郭旭：傳統的軟體開發方法是將架構設計與程式開發分開的。架構設計往往需要具有較高造詣的架構師來實現，需要他對軟體的整體結構非常熟悉，而程式開發可能只需要開發人員掌握程式設計語言就可以了，那麼敏捷開發對開發人員的要求是怎樣的呢？

　　Martin Fowler：首先軟體的設計和編程這兩件事情本來就是非常接近，很難區分開來。傳統軟體開發方法中一定要在這兩者之間劃分一條線，說這部分是設計，那部分是編程，造成的結果往往不是特別好，常常導致一些脫離實際的設計和脫離設計構想的編程實現，我們在很多項目中親眼目睹了這些方面的執行個體。當一個架構師脫離編程實踐很長時間之後，他做出來的架構設計往往變得不切實際，讓程式員很難實現。

　　郭旭：對於一個企業的軟體項目，其業務人員參與與否將決定著敏捷開發的成功與否嗎？

　　Sidney G.Pinney：如果說業務部門能夠參與到開發過程中與Team Dev一起工作的話，敏捷方法將給予他們最大的參與機會。他們將能夠在最短的時間內看到一個軟體是如何由腦子裡的想法變成草圖，再變成程式，最後變成一個可以用的軟體，看到整個系統如何由一小塊一小塊的功能組合起來變成一個大的應用程式，並享受這樣一個樂趣，親眼看到自己在業務上的需求如何變成一個實實在在的軟體。

　　相反，如果業務人員不願意參與到軟體的開發過程中，那麼敏捷開發是很難將一些好的開發方法貫徹進開發過程中的。我個人認為，如果業務人員對軟體不感興趣，不想跟開發人員溝通，不管通過什麼樣的軟體開發方法都不可能得到很好的軟體。

　　郭旭：在採用敏捷方法實施系統開發時，是否要求Team Dev所有人在個人素質、編程能力上都有較高的水準？如果他們的水平高低不同是否會影響系統開發的效果？

　　Sidney G.Pinney：如果團隊的成員都在一個水平上，並且是高水平上，當然是有它的好處。但是對於一個團隊來講，更多的情況是，團隊中有一些人是比較資深的、高水平的，另外一些人則是水平較低、缺乏經驗的。當這樣兩組人結合成一個團隊進行項目開發時，首先應當是新手向高水平成員學習，這是毫無疑問的。但是，某種程度上高水平成員也需要向新手學習，因為新手的思想還處在一個新鮮的狀態，腦子裡不存在一些思維定式。他雖然可能不知道應該做哪些事情，但是可能會有非常新鮮的想法。人是開發過程中最重要的因素，在整個團隊進行協作開發時，應當盡量讓每個成員發揮出最大的能量。

　　誰更適合敏捷方法

　　作者：李琨

　　隨著敏捷開發漸成氣候，許多人提出了這樣的疑問：敏捷開發是否適合自己的研發團隊，適合自己的企業？

　　郭旭：事實上，目前使用敏捷開發的人依然是少數。既然是一個很好的方法，為什麼沒有被開發人員廣泛採用呢？企業使用者為何也甚少使用它？

　　Martin Fowler：敏捷開發仍然是一種比較新的方法。對於企業客戶而言，要採用這種方法實施軟體開發，就需要從事業務的人與實施開發的技術人員更加緊密地結合在一起工作，這將需要企業員工付出很大工作量，這種工作方式被接受也需要一個過程。所以即便有越來越多的人對敏捷開發高度興趣，但是到目前為止也只是少數人在採用它。

　　郭旭：具體到應用，您覺得什麼樣的企業、什麼樣團隊、什麼樣的項目更適合使用敏捷開發這種方法呢？

　　Sidney G.Pinney：實施敏捷開發會給企業帶來很多影響與變化。一個好的企業應該是樂於接受變化的企業，願意通過不斷地改進軟體來促進企業變化，並且能夠從這種變化中感受到一種興奮、快樂。也就是說，敏捷開發要求一個企業擁有適應變化的能力，它給企業帶來的是擁抱變化的能力。因此，適合使用敏捷開發的企業，一定是一個願意接受變化的企業。如果說企業更願意看到自己的業務一萬年不變，那麼給它一個像敏捷開發這樣靈活的方法沒有意義。

　　郭旭：剛才說到在敏捷開發過程中人是最重要的因素，與傳統的軟體開發方法相比，知識庫更多地是積累在開發人員的腦海中，而不是一堆需求分析、概要設計、詳細設計、測試報告等文檔。但是當一個項目結束以後，項目出現問題，或者需要重新進行軟體變更與維護時，發覺對該項目有深刻瞭解的開發人員已經不能回來繼續提供服務時，該怎麼辦？

　　Sidney G.Pinney：確實，在使用敏捷方法開發軟體時，產生的文檔非常少是毫無疑問的。因為我們用技術的手段把更多的知識固化在這個項目中。後來者可以通過閱讀代碼或者是察看項目本身瞭解到項目的很多知識。而對於那些不能在代碼中體現出來的知識，我們會採用交流方式記錄這些知識。在ThoughtWorks的標準工作方法中，有一個專門商務程序用來記錄相應文檔，協助客戶保留關鍵文檔。而這些文檔也往往是客戶真正需要的。

　　為什麼說這些文檔是客戶真正需要的呢？因為這些都是Team Dev在實施開發過程遇到的真正難題，由於當時不明白，才記錄下來。團隊已經掌握的知識只須固化在項目內就可以，而不明白的部分可能是接下來接手項目的人同樣不明白的地方。在傳統的軟體開發過程中留下來的例如詳細設計等文檔，從知識上來講，對於許多人來講往往是多餘的。與此相對，敏捷方法留下的文檔幾乎是沒冗餘的。

　　敏捷開發如何前進

　　至今，仍然只有少部分人在使用敏捷開發。敏捷開發應當如何發展並尋找到自己的商業價值呢？

　　郭旭：敏捷開發方法解決了軟體的適應性問題，但是我們知道軟體工程裡軟體的可複用性也是很關鍵的。請問Martin Fowler先生，軟體的適應性和軟體的可複用性哪個更重要呢？

　　Martin Fowler：應當說軟體的可複用必須建立在軟體是可用的基礎上，軟體首先要解決可用性問題，可複用性對軟體本身提出了更高的要求，更多的軟體是不具備可複用能力的。

　　郭旭：軟體的可複用性與適用性解決的是否是不同領域的問題？

　　Martin Fowler:這兩者相對獨立，並具備太多的可比性。敏捷方法不但能解決軟體的適應性，同樣也能實現軟體的可複用性。

　　現在有很多人也用敏捷的方法開發可複用的軟體，比如一些Java架構也是採用敏捷方法開發的，具有很強的可複用性，而且很多開源軟體也採用了大量的敏捷實踐，雖然他們並沒有明確提出採用哪種方法，但是其開發特徵具有敏捷的特徵。

　　郭旭:如果在項目開發過程中，ThoughtWorks協助客戶學會敏捷開發的方法，客戶將不再需要ThoughtWorks，似乎ThoughtWorks的商業價值也就此中止。相反如果不教會客戶，將導致這樣一種情況的出現，客戶只要有一點業務變化或需求，就需要不斷地尋求ThoughtWorks的協助，讓ThoughtWorks將該客戶綁定，持久實現商業價值。在實際項目運作中，ThoughtWorks是如何?自身商業價值的？

　　Sidney G.Pinney：我們最希望的工作方式是進入這個項目和客戶團隊一起工作，開發出客戶需要的頭一兩個版本，與此同時提高客戶團隊的開發能力，讓他們能夠有能力把後續的開發繼續進行下去，然後我們將離開並尋找下一個項目。因為對於ThoughtWorks人來講，更喜歡去接受新的業務、新的技術、新的挑戰。

　　因此，我們不太喜歡在一個項目上停留非常長的時間，這會讓我們感覺有些缺乏挑戰。所以我們更願意這樣做，就是與客戶團隊共同工作一段時間，教會客戶團隊敏捷開發方法，以後選擇離開這個項目。ThoughtWorks的商業價值不是在於給客戶做持續不斷的系統維護，而是在於教會越來越多的人如何去採用敏捷開發，帶給他們敏捷開發的價值。(n101)

　　作者：李琨