一篇短文再談「敏捷」

僅以此文用來抒發一些對於行業現象的批判。

 

敏捷是如今十分流行的軟件研發模式，而且正在成爲業界主流。下圖來自於2018年軟件測試行業報告，能夠看到在受訪測試人員中，工做于敏捷或類敏捷項目中的比例已經高達89%。

將測試融入敏捷模式中，根據敏捷項目的模式進行調整，實現「敏捷測試」，是成熟的測試團隊必須具有的能力。

 

在談論敏捷測試以前，首先要搞清究竟什麼是敏捷。

敏捷，漢語名詞解釋指反應（多指動做或言行）迅速快捷，關鍵在於快字。也正是因爲這一特色，很是適用於小步快跑的現今項目節奏，也使得敏捷得以大行其道。作項目，必談敏捷，不敏捷項目經理出門都很差意思跟人打招呼。

然而，許多（危言聳聽的說，甚至是大多數）項目對於敏捷的理解和應用都是產生了誤差的。對於某些項目組織者而言，敏捷就像是一棵救命稻草，使得他們能夠名正言順的拋棄掉他們認爲的那些繁文縟節，自覺得是的將團隊力量投入到他們認爲最有價值的領域中去。這樣的敏捷，蔑視流程，蔑視管理，蔑視全部的準備和規劃，到頭來項目只能是亂成一團。

敏捷是行之有效的理念和模式，但必須被正確的看待和使用。

 

當咱們談論敏捷，咱們到底在談論什麼

有一些理論體系中，會將敏捷和一些常見的軟件生命模型並列而談，認爲敏捷與瀑布模型、迭代模型同樣是一種「模型」。但筆者認爲，與其認爲敏捷是一種模型，不如說是一種顛覆性理念。敏捷這一律念所對比的，並非軟件生命模型，而是更基礎的，軟件研發的組織辦法：「軟件工程」。

軟件產業的發展，經歷許多個階段，從早期的軟件開發=編程，到上世紀70年代，逐漸誕生了工程體系。到如今，軟件工程已是行業的一種標準理念了。

咱們不妨回過頭來問一句，爲何軟件的研發要採用「工程」式的組織？

咱們不去糾結其名詞解釋，工程這個詞一般的用法在什麼場景下面呢？他被用的最多的一個領域可能就是：基礎建設「工程」，好比蓋房子，裝修--典型的工程式管理。

咱們能夠對比一下軟件研發和基建項目的類同性：經過一行一行代碼的積累，與一磚一瓦的將一棟建築搭建起來，是否是很是近似呢？！

因而就以下圖所示，咱們將軟件研發過程與基建工程作了一個類比：

這種類比是很是ok的，確實咱們能夠按照基建工程的組織形式，將軟件研發一樣進行工程式管理。到如今爲止，「軟件工程」已是咱們行業內的標準定義和模式了。

在工程思惟導向下，許多「精益生產」領域的理論體系也在被不斷的融入軟件研發行業內，好比PMP項目管理，好比CMMi成熟度模型，等等。

 

——————————————————————————分割一下——————————————————————————————————————————

 

可是，隨着社會節奏的加快，業內的人士逐漸發現了工程式管理的弊端。好比，繁文縟節的項目組織、計劃、設計階段所花費的投入，甚至遠高於實際的產品生產。

這個時候咱們再回過頭去審視咱們關於軟件工程和基建工程的對比，他們真的是一毛同樣的嗎？

蓋一棟房子，咱們須要嚴密的工程規劃，設計，須要嚴格按照計劃進行建築材料的採購，須要嚴格按照結構設計的要求進行施工。規劃和設計中出現的一點不合理，均可能會動搖後續的工做的根基；施工過程當中的一點點不嚴謹，均可能造就成一項豆腐渣工程。

那麼軟件研發是否是也一樣如此？是否是一個產品功能特性，採用A方法完成和B方法完成會產生根本性問題？是否是少寫幾行代碼，就必定會致使產品的崩潰？是否是沒有設計圖紙，工程師就徹底沒法開展施工（編碼）工做？

你會發現這些問題的答案所有都是否認的，軟件研發與基礎建設工程絕非徹底類同，衡量軟件研發的成功與否，甚至只有一條標準：用戶的滿意。

換一個角度來講，傳統工程意義上的軟件研發，將軟件視做一種待售產品，他與其餘的商品生產過程並沒有二樣。那麼精益生產的理念，流水線式的生產車間管理也被引入軟件研發過程。軟件真的與工廠裏流水線上生產的產品同樣嗎？絕對不同，軟件的需求具備高度定製的特性，不一樣的企業不一樣的人不一樣的羣體，須要不一樣的軟件，絕非日用產品那般千篇一概。隨着理念的更新和升級，如今的業界更多認爲，與其說軟件是一種產品，軟件更是一種服務。用作服務的思想去作軟件研發，也是敏捷的出發點之一。

因此從這個角度而言，軟件究竟經過怎麼樣的過程被研發出來，並不重要，重要的是研發出來的軟件要符合用戶需求。閉門造車，循規蹈矩，工廠車間式的軟件研發，已經不能適應當今的許多項目需求。

 

咱們能夠看看，敏捷四宣言都在談論什麼：

1. 人員交流重於過程與工具（Individuals and interactions over processes and tools）
2. 軟件產品重於長篇大論（Working software over comprehensive documentation）
3. 客戶協做重於合同談判（Customer collaboration over contract negotiation）
4. 隨機應變重於循規蹈矩（Responding to change over following a plan）

對於這些敏捷宣揚的理念，若是不理解敏捷的上述背景，就會產生應用的誤差。

好比說第二點：軟件產品重於長篇大論，強調說複雜的文檔不是軟件研發的核心，產品自己纔是咱們的最終目標。指的實際上是咱們不該該過度追求複雜的文檔，指的是文檔形式的轉變，而不是不要文檔！敏捷項目有着本身適用的文檔組織形式，好比敏捷需求更傾向於使用用戶故事形式，而非傳統意義上的PRD。

再好比說第四點：隨機應變重於循規蹈矩，強調說不該該死板的遵循計劃，而是應該擁抱變化。他談論的問題核心在於變化的處理和應對，而不是毫無計劃，雜亂無章！

好比傳統意義上的軟件研發，可能耗費一兩年一個軟件才最終問世，而在這一兩年的時間內，這個軟件究竟是否符合市場定位和用戶需求，這一判斷是含糊的，由於這個過程當中最終用戶始終也沒有看到軟件的成品。而敏捷則強調對於用戶需求的強響應，經過引入衝刺週期的形式，將龐大的軟件開發過程拆分紅爲期2-4周的階段，快速的產出基礎產品。快速的將基礎產品推向市場和用戶，讓用戶來評判產品的適用度，若是市場滿意度低，一個字：改。

擁抱變化，這纔是敏捷。

 

最後總結一下：

敏捷的核心在於靈敏迅捷，在於快速。快速的終極目標不是爲了快速而快速，不是爲了偷工減料而快速，不是由於你管理能力低下，不少事情你組織很差，因此乾脆拋棄這些你沒能力作好的事情來達到快速目的。不是由於敏捷因此能夠不要需求，由於敏捷因此該作的事情不作，不要以敏捷爲藉口來達到偷懶的目的，這是無知和無恥的表現！

快速是爲了更好的需求響應，爲了更好的提供服務，這纔是敏捷。