作者 | 王子琪

敏捷不是“一”種方法

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

以上是一段常見的關乎敏捷的定義。

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

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

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

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

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

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

敏捷應運而生。

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

敏捷不解決軟件的復雜性

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

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

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

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

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

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

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

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

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

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

敏捷是知與行的功夫

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

敏捷需要管理者響應一線需求

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

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

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

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

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

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

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

結語

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

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

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

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

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

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