隨著最近Web 2.0的到來,人們對其倍受關注,並進行各方面的討論。然而目前尚未討論徹底的是:比較其它傳統企業軟體開發,Web 2.0具備哪些獨特的開發方式?關於這一話題,Stephen Bryant最近發表的Web 2.0與Enterprises不能混合的5個理由最具代表性。Stephen的觀點基本集中了眾多大型公司在使用Web 2.0時所碰到的各種問題。 文章中,Stephen表達了對“從上至下的創新”的排斥。然而我要指出的是,這一觀點將會導致很多公司拒絕使用Web 2.0與分散化各種Blog,wiki,甚至mash-up。 當Web 2.0這種具有引導方向(pull-oriented)的軟體開發出現時,它將與企業軟體開發系統發生“遭遇戰”,這就是典型的文化衝突。有趣的是,McKinsey最新的報告指出,未來絕大多數的創新將來源於各種形式的引導方向的系統,並且“當這種系統處於中心地位時,執行人員將會重新審察公司的各個方面。” 本月有關TIE事件的well-blogged也提出了很多觀點,其中最具代表的是Web 2.0思想將會引發超乎技術層面的商業運作模式的革新。並且提出,傳統企業開發軟體應學會放棄對某些資料訪問的控制權。當前快速發展的Web 2.0與企業軟體的煩冗處理過程有著本質的區別。 廣為流行的Agile軟體處理過程,包括SCRUM和Lean Software Development已經努力克服傳統軟體開發的臃腫、複雜的中心控制等缺點。老式的設計過程通常包括多餘而繁瑣的程式段,這些程式段阻礙著公司的開發效率。所以,Agile提出一套開發理論,聲稱反饋式迴圈和說明性語言對軟體的發行是相當有用的。 這些天以來,快速發展和廣為流行的Agile軟體開發已經深入人心。著名的Agile Manifesto闡明以下觀點以說明他們設計思想的核心(我們可以看到與Web 2.0概念非常類似): Agile方法的核心
- 基於處理過程與工具之間的相互獨立與互動;
- 基於綜合文檔的軟體;
- 基於合約談判的使用者合作;
- 基於計劃的所有決策。
現在,讓我們看看與建立Web 2.0軟體相關的開發思想。 Web 2.0開發思想
- 經常性地發布:每30分鐘發布一次產品(給成千上萬的使用者)。好處:可以儘快地減少錯誤,並且軟體開發過程將變成具有持久性和平穩性的過程。
- 小型程式段、寬鬆性地聯結:使得更新更加容易,具有更少的危險性。同樣各個部分具有更好地重用性與共用性。
- 輕量級的程式模型:動態語言:比如Rub,以及簡單資料格式,比如:Really Simple Syndication (RSS), Representional State Transfer (REST)都可以使得程式開發、整合、測試以及重用性變得更加容易和更加高效性。
- 使用者可作為建立者:使用者可參與作為Web 2.0中心。為使用者動態提供他們所需要的特性,為他們提供支援線上軟體的資訊。
- 即時反饋和資訊提取:通過觀測使用者正在使用和反饋方法,知道使用者需要的特性和功能,以建立一個逐級完美的產品。
並且你可注意到,Web 2.0已經列舉很多應用於軟體開發的規則,這些規則包括:
- 花費更少的金錢:鼓勵最大限度地利用資源,而最少的投資。
- 更少的人力:在人力資源上作最少的投入,將精力集中在開發產品上。
- 更加具體化:減少沒有必要的設計環節。
問題是:這些規則如何應用到傳統企業軟體開發? Web 2.0軟體開發包括一些小型啟動程式。我已經聽到和看到,這些啟動程式都沒有很好地被譯化為相應的傳統企業軟體。難道Web 2.0軟體不具有“翻譯性”嗎? 簡單的答案是,二者之間仍然存在一個“缺口”。一方面,我們的小型軟體開發人員使用一些極端的開發方法,然而這些方法缺乏相應的資源,開發人員不得不通過快速反饋的方式滿足當前或潛在使用者的各種要求。另一方面,我們的大型軟體開發過程通常都是投入大量的資金與詳細的專案計劃,但收益卻是非常緩慢。 ,雖然Agile/Lean在企業開發中不斷地發展,但比較於Web 2.0,Agile/Lean方法稍顯繁瑣。 我現在不想回答Web 2.0開發技術如何轉換為傳統的企業開發。但我們已經看到,Agile方法近年來已經應用在越來越多的項目中。有些Agile專家,比如Jutta Eckstein,相信Agile方法可有效應用在高達200人的項目開發中。 這就給當前這一創新、快速反饋與低成本的Web開發技術最終能夠轉化為企業開發帶來希望。如果你讀到Marc Hedlund的這篇優秀的報告,你就會發現這些新技術事實將會得到飛速的發展。本文先告一段落,我將在以後跟蹤這一技術並提供更多的資訊。 |