敏捷開發從理念原則到商業模式

大師們的確不但要總結一些有關敏捷方法的理論，而且要有切實可行的方法去操作，還要有相應的商業模式的配合，否則總是說敏捷宣言原則實踐或者經驗，沒有一點兒理論和商業模式支援，一遇到有關收費的問題就沒的可講的了，誰為敏捷的交流付費，誰為敏捷的變化付費，如何才能通過第三方信任一個敏捷團隊，這些都是商業模式的問題。

敏捷方法有時需要把各種新鮮的東西都放到敏捷中來講，以為敏捷保羅永珍，有人提個問題，回答得神乎其人，雲山霧罩，讓人覺得漏洞百出就不好了。

或者本來說過程式控制制不是敏捷，結果在實踐中又不得不以形式化過程作為敏捷開發的主要活動。

或者在一個項目中敏捷，到了另外的項目就不敏捷了，有的敏捷項目實際上不敏捷，有的是急功近利而後患無窮，或者毫無規劃而得過且過。

這些負面的東西都會讓人產生懷疑，敏捷到底要提高工作效率還是要降低工作效率。

 

從這篇文章開始，我試圖從理論和商業模式角度描述和總結敏捷，以此將敏捷從概念，起源和已有的實踐中總結出一些東西，至少將敏捷開發方法同相對傳統的軟體工程方法以及各種概念的區別揭示出來，將敏捷的定義，適用範圍、類型、規模、商業模式，約束條件等相對嚴格定義出，而不是感性的實踐經驗。雖然我知道我的定義不一定是非常準確的，也可能有錯誤，但是這個嘗試總比糊塗的，情緒化的敏捷崇拜者更好地對實踐進行指導。

所謂理論基礎元素，本來打算是為形成一套完整的理論服務的，但是寫作過程中，發現以目前的素材，雖然我將一些案例進行總結，但是仍然不能稱為理論，所以暫且改為基礎元素吧，可以作為真正理論需要解決問題和關注點，去逐步發展吧。

 

敏捷的價值觀

首先從觀念上講，如何是敏捷的。

敏捷的價值在於共同的成長，所以，敏捷宣言中第1條和第3條說，個體和互動更重要，客戶參與也更重要。就是將工作中的每個人都平等起來，大家共同完成一個目標，從這兩點上，敏捷的宣言是從哲學上去說，而不是方法學上的。

敏捷的價值還在於在一個哲學基礎上，使用任何方式方法都可以稱為敏捷。所以，敏捷宣言中第2條寫啟動並執行軟體更重要，就是實現目標很重要，第4條寫響應變化更重要，其實第4條是第2條的一個附屬方法，既然實現目標是最重要的，當然目標如果發生改變，我們就要自然要適應這種改變了。

交流也是敏捷中的重要因素，通過交流獲得正確的目標。交流不是單向的，需求調研算不算交流？敏捷的交流應該是雙向的，就是每個人都可能被影響，使用者可能會影響到開發人員，開發人員也會影響到使用者，這是平等的。

然後我們看看不重要的方面，被弱化的4項中，1、過程和工具，2、文檔，3、合約談判，4、遵循計劃，在敏捷開發中，這些內容不是不需要，而是在平等交流下進行確定，也是大家都認為是很舒服去適應的方式方法，標識標誌，所以也無所謂UP還是XP，Scrum還是迭代，只要這個項目的成員包括使用者都認可，那麼就可以使用，或者不使用。

敏捷是一個原則，在這個原則下，會有多種實踐方法，這些方法可能會對症一個敏捷思想的一部分，是不全面的敏捷分支。

敏捷要想成為一種真正的開發理論，一定會包容一切，承載一切，將好的開發方法和過程容納進來，並使其更加高效，而不是排斥或者對立。

 

敏捷的起源

無論是敏捷還是其他理念，一個軟體系統，實現是第一目標，然後可以最佳化和提高，就像人的生存，生存-溫飽-小康。如果我們第一個目標就是小康，那窩頭鹹菜等東西不吃，茅棚草席麻片不去住，人類可能就在大自然中消失了，不會發展到小康。軟體也是一樣，強烈的實現意識，使開發人員在盡l量短的時間內，將第一個版本實現，這是大家共同的目標。

敏捷和傳統的軟體工程分歧在於，軟體需求的實現是要整體設計，還是不要整體設計。

設計的好和壞，是設計者和構架師的水平問題，但設計不設計，是開發理念。

在軟體工程中，每個迭代目標明確後，需要對目標進行分解，然後才能一個模組一個模組地實現，其實這個目標清晰和分解的過程，就是構架的過程。

構架可以分系統構架，大構架和項目內部的構架，不同規模的構架關注不同粒度的部分。如系統構架關注於系統系統之間的關係，而項目內部的構架更接近於代碼結構和設計模式。

由於構架是事先設計的，所以，在開發過程中，混亂和不明確的情況會少得多，但是有些設計可能是過度的，或者多餘的，各個實現之間通過構架完成，耦合小。成員對於全域理解不夠深刻。

由於構架要瞭解軟體需求中的各個方面，並且要設計軟體開發過程中的構架，但是並不實現，所以項目中的一部分人員不必參與，使用者也不能在這個過程中看到他們可以理解的成果，降低了參與度。

如果設計，實現，部署3個主要步驟時間都是30天，那麼最快30天后，使用者才能看到啟動並執行軟體，如果60天后看到軟體，使用者就只能是被培訓了。

而敏捷方法也說，對於目標，通過小的迭代Scrum進行完成，但是敏捷的迭代更小，更盲目一些，更接近表面，所以內部結構往往是混亂的，從而導致必須通過重構，這種特殊構架方式進行設計活動，這樣的結果有一個好處，就是完全避免了過度設計，由於交流的通暢，所有的過程團隊成員更加清楚構架產生的過程，沒有多餘的代碼。

 

如果敏捷方式開發，30天或更長時間實現，30天重構，30天部署，最快在最初幾天內，使用者就可能看到啟動並執行軟體，但是功能和介面有限，使用者可以進一步修改和驗證他的想法，直到軟體成功，軟體的成長使用者可以看到，而當開發人員重構系統時，使用者早已經放心睡覺去了。

 

敏捷開發的概念範圍

“敏捷”僅僅是一個形容行動迅速，反應靈活的形容詞，放在開發這個動名詞前，作為修飾和約束，以區別其他的軟體開發方式。所以敏捷開發關注的是軟體開發活動中原則和方法，甚至都不包含軟體的構架設計實現的具體過程，更不是什麼我們如何用軟體提高工作效率，如何重構等，即使有這些內容，也僅僅是一小部分，不能影響到整個方法。更不是什麼諸如“身手敏捷”中的“敏捷”，或者他敏捷地躲過敵人的子彈，然後開始還擊。

軟體開發方法的研究，是提高軟體工程的品質和開發能力為主要目的，強調軟體開發管理中特性、資源和時間三個要素的平衡統一，並試圖以之協調軟體工程整個生命週期中的各方面關係。

 

敏捷的約束

總結了一些敏捷的方法，我們開始確定敏捷適合範圍，以及商業模式，管理方式。

 

傳統的軟體工程，以需求規格為最終的驗收標準，需要在一定時間，一定投入的條件下，以提交物的方式交付給使用者。這些都是要寫進合約，甚至可以作為呈堂證供，可以經得起法官的審判的。但是到了敏捷的宣言中，客戶合作更勝於合約，就是說，我們在有合約約束的項目中，是無法完成敏捷開發的，我們必須以嚴格的目標管理，進度管理進行過程跟蹤，發現問題和風險及時跟進解決，以期在確定的時間內完成合約要求的目標。

既然合約約定了目標，那麼這個目標就是不能隨意變化的。一旦使用者發現有需求有問題，就要進入複雜的需求變更流程，甚至可能重新簽訂合約。既然需求規格變化這麼困難，那前期的制定工作一定要非常謹慎，所以才會有更多的項目因為沒有需求定義而遲遲無法開始。

敏捷的快捷就在於，他的開發可以很快跟上需求的定義，即使需求沒有完成，哪怕剛剛一個要點，或者不全面，也可以開始敏捷開發。結果是，可能開發出來的東西不是使用者想要的，開發失敗，也可能是開發的結果激發了使用者的需求，使用者有依據去完善他的需求，證明他的需求，使其有了更完整，全面的需求，這時，敏捷開發也會及時跟進，最終達到完美的系統。

從這個意義上講，敏捷的不單是Team Dev，敏捷的也是使用者。如果使用者沒有嘗試過敏捷，敏捷團隊可以通過傳道的方式傳授給他，如果使用者嘗試過敏捷，敏捷團隊可以讓使用者的敏捷更加有效。

這裡的商業模式，傳統軟體工程一般是預付款條件，沒開發前，有預付款，開發過程中，使用者需要在某個裡程碑付一部分，驗收後付一部分，售後保證時間後，再付一部分。由於每次啟動付款程式都是一個非常規行動，所以討要付款是軟體商務工作中一個很費腦筋的事情。

敏捷開發的商業模式，一般是以小時報價。這種計時付費的方式而不是看結果付費的方式，保證了Team Dev可以隨時應對需求的變化，而不以合約為約束。使用者需求的不確定，是通過付更多的計時付費來解決的，你有錢，隨時都可以變。

 

敏捷項目報價模式，小時報價還是固定價格？

所以在敏捷開發項目中，小時報價會成為主流的報價模式，而固定價格會成為敏捷的失敗之源。

按小時報價的好處還在於付費的周期固定，及時使用者和Team Dev覺得不滿意，都可以在這個周期內停止，即使有損失，也不會太大。

作為固定價格的項目，首先固定價格的評估是以開發目標為基礎的，但是使用者對於需求的提供往往不是真正的需求規格，而是一個業務需求，需要有人根據業務需求評估出項目的開發成本，以推算報價。這個需求分析和評估需要一定的時間和經驗，而且評估的準確性也差距非常大，雖然可以通過係數方式緩衝，但往往報價偏低，而往往報價偏低卻得到了使用者的認可，給項目的開始帶來了隱患。系統的需求分析其實也是需要許多工作量的，這個使用者一般不會付費，這樣往往在節省人力的情況下，評估工作也是品質不高。一旦在規定時間內不能完成項目目標，而前期的付費有消耗掉，這個項目可能就要失敗了。

固定價格可以採用敏捷開發嗎？那需要在傳統的合約中進行約束，其提交物不是一個確定的目標，而是一個時間範圍內的成果，這樣，可以使用固定報價，每周期付費，到時間就停止。

還有一種就是固定價格增大緩衝時間，可以增加2倍時間進行報價，即使超過評估的也有時間在後續的緩衝時間端完成。

 

敏捷可以確定開發到期日嗎？

 

如果可以確定開發到期日，那麼敏捷項目可以固定價格嗎？

 

敏捷可以固定需求開發嗎？

 

敏捷和軟體工程

敏捷和軟體工程各種方法的關係

敏捷和CMM，敏捷過程可以通過CMM/ISO認證嗎？

CMM是軟體能力的成熟度等級模型，而不是指需要使用UP或瀑布開發或反覆式開發法，從CMM的層級說明上看，只要一個Team Dev，總結出一些開發方法，並固定到一定的流程，就可以通過一個CMM層級。比如CMM2，要求是可管理的，簡單地說，只要有人去按一定的規範管理開發過程，就可以通過；而CMM3，是可定義級的，就是將開發過程中的包括的要素進行標識定義，並有效管理，減少混亂，就可以通過。

CMM的實質也是比較簡單，他基於Team Dev經驗總結，並將經驗分解整理為多個步驟或者關鍵點，並將這些固定在一個過程管理中，以期望下一個項目能像以往成功項目那樣繼續成功。

至於CMM中實施瀑布開發，還是反覆式開發法，還是敏捷開發，都是Team Dev自己的事情，你可以有文檔，也可以沒有文檔，你可以有每日Standing Meeting，也可以沒有，只要你的過程能保證下一個項目成功。

而敏捷開發提倡個體和互動勝於過程，但是還是有很多敏捷團隊有自己的過程，如每日立會（Standing Meeting），工作日報等，他們認為過程是可以保證開發的順利進行，可以促進交流。所以說，敏捷理論和原則在實踐中，必須落實到可操作的活動中。

至於說認證的問題，並不是敏捷開發理論所要涉及的。

認證是一種商務工作， 兩個互不相識的商業組織，第一次合作時，由於需要瞭解對方，或者一方（甲方）對另外一方（乙方）瞭解。瞭解的方式有很多中，時間成本和風險都有很多差異，其中由一個可信的第三方提供某些能力證明的方式被認為是一種簡單有效方式，甲方無需為這種瞭解支付更多費用，而乙方為了獲得更多商業機會，自己投入成本取得第三方認證，也是容易接受的。

所以，敏捷的認證也是屬於第三方認證，只要甲方認可敏捷，認可頒發認證的第三方機構，以及認證的過程，當然也可以給乙方以商機。

這個第三方機構可以是CMM/ISO組織，也可以是一個新的認證機構，CMM/ISO這樣的組織有一定曆史，信任度比較高，如果他們增加一些認證類別，自然可以很快得到響應。

 

敏捷團隊

敏捷團隊的建設

敏捷團隊的熱情從何而來。

敏捷團隊需要專案經理嗎？

敏捷團隊需要構架師嗎？

敏捷團隊的梯隊模型

敏捷團隊成員如何晉級。