作者 | 王子琪

敏捷不是“一”種方法

敏捷是一種用于項目管理和軟件開發(fā)的迭代方法，可幫助團隊更快地向客戶交付價值并減少風(fēng)險。它不是將一切都押在“大爆炸”發(fā)布上，而是以小的增量交付成果。不斷評估需求、計劃和結(jié)果，因此能夠快速地響應(yīng)變化。

以上是一段常見的關(guān)乎敏捷的定義。

而當(dāng)我們動態(tài)地看待過去幾十年的敏捷發(fā)展史，光是圍繞敏捷二字產(chǎn)生的框架、實踐、理論等，便是五花八門。

早期的時候，有諸如 Scrum、XP、Crystal method、DSDM、FDD 等框架，又有融合了 TPS 的 Kanban，而后敏捷理念日漸傳開，過度商業(yè)化帶來各種亂象的同時也伴隨著撥亂反正的進(jìn)行，這期間又出現(xiàn)過一些新方法，如Modern Agile， Heart Of Agile等。

另一邊，DevOps運動，精益方法，逆康威行動等也都在如火如荼地進(jìn)行，倘若我們認(rèn)真讀過敏捷宣言背后的十二條原則，也不難發(fā)現(xiàn)敏捷與它們之間的默契。

如此看來，將敏捷說成是單一的方法本身不免過于狹隘。

既然否定了一種定義，勢必要肯定一種定義。社區(qū)中Being Agile not Doing Agile的說法流傳已久，其巧妙之處便在于指出了敏捷本身是一種思維方式。

處于日新月異的技術(shù)環(huán)境下、變化多端的市場中，軟件開發(fā)活動若想能迅速響應(yīng)外界變化來高效地完成商業(yè)目標(biāo)，尋求與VUCA/BANI/RUPT/TUNA（無論你喜歡什么詞）環(huán)境的對抗之道是必然的。

敏捷應(yīng)運而生。

然而因其所對抗的環(huán)境是極度復(fù)雜的、無規(guī)律的，固然敏捷也無法是一種或兩種方法，它首先是價值觀，而后伴隨著方法、框架、實踐等，總體上呈現(xiàn)出隨時代發(fā)展、行業(yè)進(jìn)步、人們對軟件開發(fā)活動認(rèn)知的深化，本身不斷演進(jìn)，并與類似價值觀下的其他理論或方法互相包容的特征。

敏捷不解決軟件的復(fù)雜性

《沒有銀彈：軟體工程的本質(zhì)性與附屬性工作》中曾稱：

沒有任何一項技術(shù)或方法可使軟件工程的生產(chǎn)力在十年內(nèi)提高十倍。

拋開具體的數(shù)字而言，軟件開發(fā)是一項復(fù)雜度高且充滿不確定性的活動的事實依然未變。

從對立統(tǒng)一的角度來看，軟件優(yōu)秀的特質(zhì)通常與其令人苦惱的特質(zhì)是一體兩面的。

軟件的變更成本可以很高或很低，構(gòu)建一款同樣的軟件有數(shù)不勝數(shù)的方式，即便在功能都完全一致的情形下，也存在易于拓展和復(fù)雜僵化兩種截然不同的可能性。這都因為軟件開發(fā)活動本身是一項熵高的活動，倘若構(gòu)建軟件的方式是單一的、按部就班的，便也不存在這樣的區(qū)分。

在XP2002的大會上，一位經(jīng)濟學(xué)家Enrico Zaninotto提到，在軟件開發(fā)和制造過程中，不可逆性是復(fù)雜性主要的驅(qū)動因素之一，敏捷方法通過降低不可逆性來包容復(fù)雜性，而不是解決其他的復(fù)雜性驅(qū)動因素。

這段描述確切地指出了敏捷的根本點，不是解決軟件開發(fā)活動本身的復(fù)雜（目前看來也不可能），而是極盡所能去應(yīng)對。這勢必導(dǎo)致這種應(yīng)對方法本身一定是靈活變通的，它趨向于通過建立對軟件開發(fā)活動特性的把控，從而衍生出具體情境下具體的解決辦法，而非借以單一固化的流程或方法來解決問題。

如果一個希望從敏捷中獲得好處的企業(yè)，僅通過購買咨詢、培訓(xùn)等服務(wù)，而不自發(fā)地在實踐中增強組織對于自身業(yè)務(wù)、軟件開發(fā)本身的認(rèn)知（固然框架和實踐是有用的，即使在對其背后價值邏輯全然不知的情形下，某些實踐也能帶來收益，例如持續(xù)集成），卻也只能受用敏捷能夠帶來好處的九牛一毛。

正如Dave Thomas在GOTO Reference中對”是否能夠及如何購買敏捷力？”這一問題的回答：

不，你不能，但你能夠購買對此有幫助的潤滑劑。它（指敏捷力）從實踐和經(jīng)驗中得來，你無法單單通過咨詢、讀書、上課等等來獲得，它從不斷的試錯中而來。你需要發(fā)展隱式的知識（一些你難以表述甚至都不知道自己知道的知識）。所以你無法購買敏捷力除非有人能發(fā)明這樣一種機器：戴個頭盔在你頭上，按下按鈕，然后你就能說西班牙語了。不過你能夠購買工具、經(jīng)驗，但你仍需要大量的工作，或許花費數(shù)年才能完成。

敏捷是知與行的功夫

王陽明心學(xué)中有知行合一的認(rèn)識論，即知行原是兩個字，說一個功夫，不可分作兩事。

知之真切篤實處便是行，行之明覺精察處便是知。

相信這樣一個場景大抵不令人覺得陌生：

在進(jìn)行用戶故事工作量估算時，其中一人稱：“我認(rèn)為這個故事的工作量是三個點，因為它涉及到很多結(jié)構(gòu)性的調(diào)整?！?，另一人說：“我贊同你的說法，但在我看來這些調(diào)整在IDE工具的幫助下并不是什么難事，并且我們應(yīng)該盡可能簡單地先做出一個版本，所以我認(rèn)為只有兩個點。”

在這樣討論當(dāng)中，實則揉雜了兩方面的事情。一方面，是對于故事認(rèn)知的拉齊（價值，技術(shù)思路，風(fēng)險，難易程度等），另一方面，是基于共通的認(rèn)知，成本又作何算（所謂的點數(shù)）。

前者叫做澄清，有助于識別風(fēng)險，令團隊對故事達(dá)成一致的認(rèn)知，使后續(xù)落地工作中得以更好的進(jìn)行。同時這樣的過程有利于成員間知識經(jīng)驗的交換。

其關(guān)鍵點在于恰到好處的顆粒度，我們需要討論到這樣一種具體的程度：對價值、風(fēng)險、工作量等等的影響是什么，但無需再更進(jìn)一步。

就上述而言，另一人的說法中，“并且我們應(yīng)該盡可能簡單地先做出一個版本” 這樣的陳述便是不具體的，聽眾無法理解其中“簡單”的程度，而“簡單”的程度恰恰對應(yīng)著不同的價值與成本。

倘若是這樣的描述：“并且我們應(yīng)該盡可能簡單地先做出一個版本，它只應(yīng)該在現(xiàn)有應(yīng)用的XXX處做XXX的修改，而不應(yīng)涉及到XXX以及XXX…”，想必討論的立足點會更為堅實。

而后者稱為估算，誤解頗多的一項技術(shù)，Martin Folwer 在他的一篇bliki，估算的目的中指出：

對于我來說，當(dāng)你面臨重大的決策時，估算就是有價值的。

這反倒是眾多施行估算實踐的人所忽視的一點，他們往往這般回答：我要知道每個迭代我們能夠完成多少工作量！倘若追問然后呢？

便有人說，這樣我就能在開發(fā)人員完成度不達(dá)標(biāo)的時候指著他們的鼻子說，“看，你們自己承諾的，結(jié)果做不完，你們說怎么辦！”

也有人說，我想根據(jù)迭代完成工作量的波動來識別哪個迭代中可能出現(xiàn)了問題（例如交付的平滑程度，技術(shù)債務(wù)堆積產(chǎn)生的負(fù)面影響），這樣的想法有其道理，只不過識別這些問題常有更妥善的方式（比如以分析故事在各階段的停留時長，技術(shù)債的定期評估等）。

還有人說，我希望借此把控項目能在約定時間內(nèi)按約定范圍交付。這乍一看確是穩(wěn)重的想法，然而把按時按范圍當(dāng)作目標(biāo)，本身和敏捷理念相去甚遠(yuǎn)。敏捷始終是奔向價值，時間和預(yù)算只是約束，我們無非是要探尋在有限的時間金錢條件下，做什么是最有價值的，然后又快又好地完成它。倘若我們半年前設(shè)定了一個目標(biāo)，便當(dāng)這個目標(biāo)是不變的圣旨，這樣的思維也是死板教條的。

綜上而言，敏捷的功夫是知行的功夫，實踐要做，理論也要懂，丟了一個便是全丟。唯有在實踐中豐富我們的認(rèn)知，又用認(rèn)知來指導(dǎo)實踐，反復(fù)循環(huán)，培養(yǎng)既抽象也具體的知識，才能做到真正的敏捷。

敏捷需要管理者響應(yīng)一線需求

也許敏捷先行者們吹噓從敏捷中撈得的好處時，詞藻過于華麗，一些大公司聽在耳中，看著自己每況愈下的財務(wù)報表時，也把目光投向了敏捷。

一時間，規(guī)?；艚葜耸挚蔁?。我們看到SAFE、有LESS、有Scrum@Scale等框架如雨后春筍般冒了出來，這些框架的出現(xiàn)在規(guī)?；艚莸脑囼炋锢锫氏确N下了發(fā)展的新苗，然而另一方面，它們依然立足于理論的高點，只是從象牙塔內(nèi)望向外部混沌真實的世界。

構(gòu)建全功能的團隊自不必多說，長久以來團隊級的敏捷經(jīng)驗充分地印證了這一點。DevOps運動的起源故事也證明了，只制造中間產(chǎn)物的部門或團隊甚至在應(yīng)對一點微小的變化時也是驚人的笨重。

關(guān)于團隊級的敏捷，許多規(guī)模化敏捷框架倒是聰明地借鑒了現(xiàn)有的Scrum、Kanban、XP等方法，而在如何組織多個敏捷團隊這一方面，卻是出奇一致的天馬行空。無論是SAFE的Agile Release Train， LESS的Head Of Product Group，Scrum@Scale的SoS，仿佛從每個敏捷團隊中抽出一兩個關(guān)鍵角色，和遠(yuǎn)離用戶的管理層組成個精英小隊發(fā)號施令，便能引領(lǐng)各個團隊披荊斬棘一往無前。

事實上，倘若團隊自身無法處理好他們的業(yè)務(wù)，需要來自“精英小隊”的指導(dǎo)，這便和從前也并無區(qū)別——整個組織的業(yè)務(wù)依賴于一小波“聰明人”的智慧和大部分“不會動腦”的人形機器。

而如果團隊能夠自己處理的好，他們也不需要“聰明人”的自作聰明，相比之下更重要的是足夠的權(quán)利和資源。

SuperCell的成功令人眼紅，在他們的經(jīng)驗總結(jié)中提到信任而不是控制，CEO Ilkka Paananen說“我是開發(fā)團隊的服務(wù)者?！保?這很好地揭示了大型組織要在實施敏捷時的常見誤區(qū)：管理層不去釋放掌握的權(quán)利和資源，相比支持前臺的業(yè)務(wù)團隊，依然還是控制的思維。在一個大型組織中，倘若我們說要Be Agile的話，不光是要讓一線員工學(xué)會響應(yīng)來自市場的需求，二線的管理者和組織的運營者們也要學(xué)會響應(yīng)來自一線的需求，正如TPS中的拉動生產(chǎn)方式一般。若是到了管理層這就脫節(jié)了，把一線夾在市場的變化和二線的控制之間，是做不出敏捷的。

結(jié)語

事物的發(fā)展時而呈現(xiàn)螺旋上升的特征，在上個世紀(jì)《科學(xué)管理原理》的影響下，誕生了人類工業(yè)進(jìn)程中里程碑式的流水線生產(chǎn)方式，人們一度認(rèn)為，過去人是第一位的，而未來流程是第一位的。

在二十世紀(jì)末的軟件開發(fā)領(lǐng)域，隨著軟件危機的不斷發(fā)酵，流程愈發(fā)顯得僵硬死板，人的重要性又重回臺前。2001年猶他州雪鳥滑雪地的一次聚會中，敏捷方法的發(fā)起者和實踐者們提出了如今我們耳熟能詳?shù)乃膫€價值：

• 個體和互動高于流程和工具
• 工作的軟件高于詳盡的文檔
• 客戶合作高于合同談判
• 響應(yīng)變化高于遵循計劃

而在這段之前，還有這么一句：

我們一直在實踐中探尋更好的軟件開發(fā)方法，身體力行的同時也幫助他人。

我一直以為這是敏捷宣言中最好的一句，它奠定了最基本的出發(fā)點，從工匠的執(zhí)著到價值的尋求，理想主義的光輝下是樸素而務(wù)實的態(tài)度。