敏捷是知與行的功夫

作者：Thoughtworks洞見 2023-01-13 00:00:47

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

作者 | 王子琪

敏捷不是“一”種方法

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

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

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

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

另一邊，DevOps運(yùn)動，精益方法，逆康威行動等也都在如火如荼地進(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)運(yùn)而生。

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

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

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

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

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

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

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

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

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

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

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

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

敏捷是知與行的功夫

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

一時(shí)間，規(guī)模化敏捷炙手可熱。我們看到SAFE、有LESS、有Scrum@Scale等框架如雨后春筍般冒了出來，這些框架的出現(xiàn)在規(guī)模化敏捷的試驗(yàn)田里率先種下了發(fā)展的新苗，然而另一方面，它們依然立足于理論的高點(diǎn)，只是從象牙塔內(nèi)望向外部混沌真實(shí)的世界。

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

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

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

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

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