敏捷不是“一”種方法
“敏捷是一種用於項目管理和軟件開發的迭代方法，可幫助團隊更快地向客戶交付價值並減少風險。 它不是將一切都押在“大爆炸”發佈上，而是以小的增量交付成果。 不斷評估需求、計劃和結果，因此能夠快速地響應變化。”
以上是一段常見的關乎敏捷的定義。
而當我們動態地看待過去幾十年的敏捷發展史，光是圍繞敏捷二字產生的框架、實踐、理論等，便是五花八門。
早期的時候，有諸如 Scrum、XP、Crystal method、DSDM、FDD 等框架，又有融合了 TPS 的 Kanban，而後敏捷理念日漸傳開，過度商業化帶來各種亂象的同時也伴隨着撥亂反正的進行，這期間又出現過一些新方法，如Modern Agile， Heart Of Agile等。
另一邊，DevOps運動，精益方法，逆康威行動等也都在如火如荼地進行，倘若我們認真讀過敏捷宣言背後的十二條原則，也不難發現敏捷與它們之間的默契。
如此看來，將敏捷說成是單一的方法本身不免過於狹隘。
既然否定了一種定義，勢必要肯定一種定義。社區中Being Agile not Doing Agile的說法流傳已久，其巧妙之處便在於指出了敏捷本身是一種思維方式。
處於日新月異的技術環境下、變化多端的市場中，軟件開發活動若想能迅速響應外界變化來高效地完成商業目標，尋求與VUCA/BANI/RUPT/TUNA（無論你喜歡什麼詞）環境的對抗之道是必然的。
敏捷應運而生。
然而因其所對抗的環境是極度複雜的、無規律的，固然敏捷也無法是一種或兩種方法，它首先是價值觀，而後伴隨着方法、框架、實踐等，總體上呈現出隨時代發展、行業進步、人們對軟件開發活動認知的深化，本身不斷演進，並與類似價值觀下的其他理論或方法互相包容的特徵。
敏捷不解決軟件的複雜性
“沒有任何一項技術或方法可使軟件工程的生產力在十年內提高十倍。”
拋開具體的數字而言，軟件開發是一項複雜度高且充滿不確定性的活動的事實依然未變。
從對立統一的角度來看，軟件優秀的特質通常與其令人苦惱的特質是一體兩面的。
軟件的變更成本可以很高或很低，構建一款同樣的軟件有數不勝數的方式，即便在功能都完全一致的情形下，也存在易於拓展和複雜僵化兩種截然不同的可能性。這都因爲軟件開發活動本身是一項熵高的活動，倘若構建軟件的方式是單一的、按部就班的，便也不存在這樣的區分。
在XP2002的大會上，一位經濟學家Enrico Zaninotto提到，在軟件開發和製造過程中，不可逆性是複雜性主要的驅動因素之一，敏捷方法通過降低不可逆性來包容複雜性，而不是解決其他的複雜性驅動因素。
這段描述確切地指出了敏捷的根本點，不是解決軟件開發活動本身的複雜（目前看來也不可能），而是極盡所能去應對。這勢必導致這種應對方法本身一定是靈活變通的，它趨向於通過建立對軟件開發活動特性的把控，從而衍生出具體情境下具體的解決辦法，而非藉以單一固化的流程或方法來解決問題。
如果一個希望從敏捷中獲得好處的企業，僅通過購買諮詢、培訓等服務，而不自發地在實踐中增強組織對於自身業務、軟件開發本身的認知（固然框架和實踐是有用的，即使在對其背後價值邏輯全然不知的情形下，某些實踐也能帶來收益，例如持續集成），卻也只能受用敏捷能夠帶來好處的九牛一毛。
正如Dave Thomas在GOTO Reference中對”是否能夠及如何購買敏捷力？”這一問題的回答：
“不，你不能，但你能夠購買對此有幫助的潤滑劑。它（指敏捷力）從實踐和經驗中得來，你無法單單通過諮詢、讀書、上課等等來獲得，它從不斷的試錯中而來。你需要發展隱式的知識（一些你難以表述甚至都不知道自己知道的知識）。
所以你無法購買敏捷力除非有人能發明這樣一種機器：戴個頭盔在你頭上，按下按鈕，然後你就能說西班牙語了。不過你能夠購買工具、經驗，但你仍需要大量的工作，或許花費數年才能完成。”
敏捷是知與行的功夫
王陽明心學中有知行合一的認識論，即知行原是兩個字，說一個功夫，不可分作兩事。
“知之真切篤實處便是行，行之明覺精察處便是知”
相信這樣一個場景大抵不令人覺得陌生，
在進行用戶故事工作量估算時，其中一人稱：“我認爲這個故事的工作量是三個點，因爲它涉及到很多結構性的調整。”，另一人說：“我贊同你的說法，但在我看來這些調整在IDE工具的幫助下並不是什麼難事，並且我們應該儘可能簡單地先做出一個版本，所以我認爲只有兩個點。”
在這樣討論當中，實則揉雜了兩方面的事情。一方面，是對於故事認知的拉齊（價值，技術思路，風險，難易程度等），另一方面，是基於共通的認知，成本又作何算（所謂的點數）。
前者叫做澄清，有助於識別風險，令團隊對故事達成一致的認知，使後續落地工作中得以更好的進行。同時這樣的過程有利於成員間知識經驗的交換。
其關鍵點在於恰到好處的顆粒度，我們需要討論到這樣一種具體的程度：對價值、風險、工作量等等的影響是什麼，但無需再更進一步。
就上述而言，另一人的說法中，“並且我們應該儘可能簡單地先做出一個版本” 這樣的陳述便是不具體的，聽衆無法理解其中“簡單”的程度，而“簡單”的程度恰恰對應着不同的價值與成本。
倘若是這樣的描述：“並且我們應該儘可能簡單地先做出一個版本，它只應該在現有應用的XXX處做XXX的修改，而不應涉及到XXX以及XXX…”，想必討論的立足點會更爲堅實。
而後者稱爲估算，誤解頗多的一項技術，Martin Folwer 在他的一篇bliki，估算的目的中指出：
“對於我來說，當你面臨重大的決策時，估算就是有價值的”
這反倒是衆多施行估算實踐的人所忽視的一點，他們往往這般回答：我要知道每個迭代我們能夠完成多少工作量！倘若追問然後呢？
便有人說，這樣我就能在開發人員完成度不達標的時候指着他們的鼻子說，“看，你們自己承諾的，結果做不完，你們說怎麼辦！”
也有人說，我想根據迭代完成工作量的波動來識別哪個迭代中可能出現了問題（例如交付的平滑程度，技術債務堆積產生的負面影響），這樣的想法有其道理，只不過識別這些問題常有更妥善的方式（比如以分析故事在各階段的停留時長，技術債的定期評估等）。
還有人說，我希望藉此把控項目能在約定時間內按約定範圍交付。這乍一看確是穩重的想法，然而把按時按範圍當作目標，本身和敏捷理念相去甚遠。敏捷始終是奔向價值，時間和預算只是約束，我們無非是要探尋在有限的時間金錢條件下，做什麼是最有價值的，然後又快又好地完成它。倘若我們半年前設定了一個目標，便當這個目標是不變的聖旨，這樣的思維也是死板教條的。
綜上而言，敏捷的功夫是知行的功夫，實踐要做，理論也要懂，丟了一個便是全丟。唯有在實踐中豐富我們的認知，又用認知來指導實踐，反覆循環，培養既抽象也具體的知識，才能做到真正的敏捷。
敏捷需要管理者響應一線需求
也許敏捷先行者們吹噓從敏捷中撈得的好處時，詞藻過於華麗，一些大公司聽在耳中，看着自己每況愈下的財務報表時，也把目光投向了敏捷。
一時間，規模化敏捷炙手可熱。我們看到SAFE、有LESS、有Scrum@Scale等框架如雨後春筍般冒了出來，這些框架的出現在規模化敏捷的試驗田裏率先種下了發展的新苗，然而另一方面，它們依然立足於理論的高點，只是從象牙塔內望向外部混沌真實的世界。
構建全功能的團隊自不必多說，長久以來團隊級的敏捷經驗充分地印證了這一點。DevOps運動的起源故事也證明了，只製造中間產物的部門或團隊甚至在應對一點微小的變化時也是驚人的笨重。
關於團隊級的敏捷，許多規模化敏捷框架倒是聰明地借鑑了現有的Scrum、Kanban、XP等方法，而在如何組織多個敏捷團隊這一方面，卻是出奇一致的天馬行空。無論是SAFE的Agile Release Train， LESS的Head Of Product Group，Scrum@Scale的SoS，彷彿從每個敏捷團隊中抽出一兩個關鍵角色，和遠離用戶的管理層組成個精英小隊發號施令，便能引領各個團隊披荊斬棘一往無前。
事實上，倘若團隊自身無法處理好他們的業務，需要來自“精英小隊”的指導，這便和從前也並無區別——整個組織的業務依賴於一小波“聰明人”的智慧和大部分“不會動腦”的人形機器。
而如果團隊能夠自己處理的好，他們也不需要“聰明人”的自作聰明，相比之下更重要的是足夠的權利和資源。
SuperCell的成功令人眼紅，在他們的經驗總結中提到信任而不是控制，CEO Ilkka Paananen說“我是開發團隊的服務者。”， 這很好地揭示了大型組織要在實施敏捷時的常見誤區：管理層不去釋放掌握的權利和資源，相比支持前臺的業務團隊，依然還是控制的思維。在一個大型組織中，倘若我們說要Be Agile的話，不光是要讓一線員工學會響應來自市場的需求，二線的管理者和組織的運營者們也要學會響應來自一線的需求，正如TPS中的拉動生產方式一般。若是到了管理層這就脫節了，把一線夾在市場的變化和二線的控制之間，是做不出敏捷的。
結語
事物的發展時而呈現螺旋上升的特徵，在上個世紀《科學管理原理》的影響下，誕生了人類工業進程中里程碑式的流水線生產方式，人們一度認爲，過去人是第一位的，而未來流程是第一位的。
在二十世紀末的軟件開發領域，隨着軟件危機的不斷髮酵，流程愈發顯得僵硬死板，人的重要性又重回臺前。2001年猶他州雪鳥滑雪地的一次聚會中，敏捷方法的發起者和實踐者們提出瞭如今我們耳熟能詳的四個價值：
“個體和互動 高於 流程和工具
工作的軟件 高於 詳盡的文檔
客戶合作 高於 合同談判
響應變化 高於 遵循計劃”
而在這段之前，還有這麼一句：
“我們一直在實踐中探尋更好的軟件開發方法，身體力行的同時也幫助他人”
我一直以爲這是敏捷宣言中最好的一句，它奠定了最基本的出發點，從工匠的執着到價值的尋求，理想主義的光輝下是樸素而務實的態度。
文/Thoughtworks 王子琪
原文鏈接：https://insights.thoughtworks.cn/agility-knowing-doing/