什麼是敏捷？ 通過實踐發展的哲學

最初是為軟件開發團隊設想的，敏捷現在是世界各地行業和公司的首要項目管理方法。 吸引力在於它的簡單性和靈活性：敏捷的缺乏規範性實踐使其高度可採用。 然而，在指導幾家公司的敏捷轉型時，我發現這種靈活性也會導致對敏捷意味著什麼的誤解。 許多公司優先考慮遵循敏捷衍生的框架，而不是理解哲學本身。

相反，組建和指導敏捷團隊的項目經理和教練應該從培訓他們採用敏捷思維開始，從本質上將哲學的核心價值觀和原則內化。 只有這樣，他們才應該根據最能滿足項目需求的方式組合、定製或省略敏捷框架中的實踐。

通過追溯敏捷的歷史發展，並將其創始原則與公司和團隊的具體需求聯繫起來，本文可以幫助項目經理為敏捷轉型創造一個最佳的未來。 正如以下案例所示，敏捷不應被嚴格地視為一種項目管理方法，而是一種在實踐中不斷發展的產品開發理念。

敏捷的前因

2001 年首次編寫的“敏捷軟件開發宣言”是四個核心價值觀和 12 條原則的簡潔集合，是對包含規則和大量文檔的線性、流程繁重的方法的激進回應。 但敏捷的歷史起源於幾十年前的一種簡化工業製造的方法。

1930 年代，貝爾實驗室的物理學家和統計學家 Walter Shewhart 開發了 Plan-Do-Study-Act 模型，它是專注於迭代改進的哲學的前身。 二戰後，他的門生 W. Edwards Deming 將其用於培訓豐田的管理人員。 該方法是豐田生產系統開發不可或缺的一部分，它是精益思維的主要來源，具有高效的構建-測量-學習循環。

在 1970 年代，當 Barry Boehm 提出寬帶 Delphi 技術時，這一概念得到了進一步發展，該技術使用迭代過程來準確客觀地估計開發軟件所需的勞動力和時間。

隨著 1980 年代中期個人電腦的普及，很明顯，軟件作為一種產品和服務將成為人們開展業務的方式的基石。 隨著專業人士開始認真關注軟件工程的增量、迭代方法，敏捷超越了瀑布流程，成為了卓越的開發和管理方法。

研究人員發現，與競爭對手相比，創新速度更快的製造商正在採用多學科、以團隊為導向的方法來推動產品通過其生命週期。 這被廣泛認為是 Jeff Sutherland 於 1993 年發明 Scrum 框架的靈感，這使他能夠按時並在預算內完成表面上不可能的項目，並且錯誤最少。

理論上的敏捷價值觀——源於這些先例——在我在實踐中使用敏捷時得到了證實，強調迭代開發、協作團隊合作和準確估計。

什麼是理論上的敏捷？

隨著公司繼續採用敏捷的工作方式，他們冒著使其比哲學的製定者所預期的更具規範性的風險。 根據我的經驗，希望採用敏捷的領導者過多地關注框架——或特定實踐集及其相關術語——而不是價值觀和原則。

正如在傳授敏捷原則方面先進的從業者所熟知的那樣，每個尋求進行敏捷轉型的組織都必須找到並採用適合他們的方法。 我通過向團隊展示如何遵循宣言的價值觀和原則，然後從 Scrum、看板和極限編程 (XP) 等框架中汲取靈感，在實踐中實施它們，從而促進了這一學習過程。

宣言的原則現在是敏捷項目經理的第二天性：

1. 個人和交互超過流程和工具
2. 綜合文檔之上的工作產品
3. 合同談判中的客戶協作
4. 響應變化而不是遵循計劃

然而，宣言中遵循這些原則的警告經常被忽視：“也就是說，雖然右邊的項目有價值，但我們更看重左邊的項目。” 許多敏捷實踐者最終會忽視右邊的價值，只關注左邊的價值。 結果？ 與盲目遵循流程繁重的框架相反：根本沒有流程，這同樣是有問題的。

在左右項目之間取得適當的平衡已成為我指導敏捷轉型的關鍵。 Apple、Google、Amazon、Facebook 和 Netflix 的管理方法也體現了這一點，它們都沒有訂閱單一的敏捷框架。 他們首先體現了宣言的原則，同時根據最適合他們的方式遵循或更改不同框架的部分； 因此，他們已經適應了市場變化並能夠快速交付新產品。

什麼是實踐中的敏捷？

在下面的概述中，我修改了宣言價值觀的原始措辭。 對語義的更改有助於闡明我在實踐中如何應用敏捷價值觀。

在第一個值中，我將“個人”一詞替換為“人”，因為敏捷意味著以團隊為導向。 至於第二個，很明顯軟件必須“工作”，所以現在的重點是成功和及時的“交付”。 第三個價值就是“協作”，因為它同樣適用於一起工作的同事和與客戶一起工作的團隊。 最後，“框架”取代了“遵循計劃”，因為這防止了人們認為應該完全放棄計劃的誤解。

人勝於流程

敏捷轉型很困難，主要是因為大多數企業都習慣於嚴格遵循流程。 使用特定的工具集完成一定數量的步驟，而不是開發創新產品，成為最終目標。

看到這種心態催生了一個有利可圖的“敏捷行業”，我感到很沮喪。 正如敏捷創始人 Ward Cunningham 和 Jon Kern 解釋的那樣，許多企業銷售他們聲稱將幫助公司“走向敏捷”的軟件。 但是，敏捷意味著採用一種哲學，而不是使用軟件並遵循它規定的程序。

實現正確的平衡不是要消除程序，而是要找到最能支持每個團隊的開發目標的程序。 對於我的一個客戶，一家大型企業技術組織，我實施了 Disciplined Agile，這是 IBM 開發的一種方法。 它結合了來自多個框架的許多實踐，包括 Scrum 和看板。 它利用了迭代開發，但比傳統敏捷更需要流程，尤其是在開始階段，因為它旨在填補 Scrum 留下的空白。 紀律嚴明的敏捷為該客戶工作，因為該組織非常注重流程。 它讓我能夠與團隊進行中途會面，獲得他們的支持，並說服他們採用 Scrum 工作流程。

我合併了待辦事項細化會議、審查會議和每日例會，以促進團隊內部和團隊間的協作。 待辦事項細化是 Scrum 指南的一部分，但細化會議不是。 我添加這些是為了讓我們能夠就我們計劃在即將到來的 sprint 中實現特定功能的原因進行健康的對話，這對敏捷新手很有幫助。 我還選擇了命名法“里程碑”——瀑布項目管理中使用的一個術語——因為它對客戶來說更熟悉。 評審和每日 Scrum 交互是 Scrum 指南中的常規元素，但我在日程安排、持續時間和流程方面使它們更加結構化。

此外，雖然嚴格遵守 Scrum 會使每個人都完全致力於 Scrum 指南中列出的角色之一，但我客戶團隊中的某些人的技能組合併不能完全適應一個角色。 使用有紀律的敏捷方法，我可以將這些職位的職責分配給多個團隊成員，並創建一個能夠發揮所涉人員優勢的流程。

軟件交付優於文檔

我更喜歡定制的 Scrum 或看板工作流程而不是嚴格遵守任何一個框架的另一個原因是，它們讓我有機會將最小可行產品 (MVP) 作為目標添加到計劃中。 源自精益，創建 MVP 的做法與迭代開發一致，並已成為敏捷從業者中流行的技術。 它允許團隊有效地向用戶交付高質量的軟件和其他商品，然後根據反饋對其進行改進。 將其作為主要基於 Scrum 或看板的混合方法的一部分應用，增強了我的團隊創建滿足客戶需求的產品的能力。

我目前正在與一家美國初創公司合作，並採用這種方法為 NFT 構建加密貨幣市場。 我們專注於創建 MVP，因此我們只編寫目前所需的最少文檔。 雖然這種方法對廣泛的產品都有效，但它對加密貨幣和 NFT 尤其有用，它們屬於一個新的、實驗性的類別，並且正在迅速變化。 無需起草完整的規範和功能，也不必在發布前反復更改它們，我們可以花時間整合用戶反饋來增強我們的市場開發。

合同合作

上述大型企業技術組織在許多固定成本項目中嚴重依賴合同。 合同概述了他們將用於完成工作的方法，以及負責每項任務的具體人員。 一旦簽署，如果沒有冗長的請求過程，就無法更改合同。

在我領導的轉型中，合作優先於這些僵化的協議。 我們實施的計劃用一頁文件代替了合同。 每個人都表示，我們同意在指定的開始和結束日期之間使用敏捷與我們的客戶以及來自不同團隊的團隊成員和同事進行協作。 合作產生的任何結果都會是結果。 我沒有詳細說明成品可能是什麼。 因為我們要求客戶反饋並將其納入我們的產品開發中，所以從我們的計劃文件中刪除規範使我們更容易接受他們的回應，並激勵他們更積極地與我們合作。

為了讓管理層參與進來，我要求他們讓我領導一個與一個小客戶合作的小團隊進行概念驗證，該小客戶甚至在任何必要的更改使問題複雜化之前就表示擔心開發時間太長。 通過讓該客戶直接與我們的產品負責人合作，我們能夠在開發過程中進行更改並顯著縮短交付時間。

這些結果說服管理層讓我將計劃推廣到更多團隊。 總體而言，簡化的合同和我們的敏捷工作流程減少了開發和將產品功能推向市場所需的時間。

對框架的適應性

我的另一個客戶，一家健康科技公司，也未能在認識到敏捷價值雙方的重要性方面取得平衡，即響應變化而不是遵循計劃。 然而，在這種情況下，它犯了與我的企業技術客戶所犯的錯誤相反的錯誤：它沒有過於嚴格地遵循流程，而是過度關注靈活性，而在很大程度上忽視了流程。 工程師很少知道他們應該做什麼，因為沒有優先級或時間表。 他們每天都在試圖弄清楚這一點，並在更重要的任務之前完成了不太重要的任務，從而浪費了時間和生產力。

我向 CEO 和 CTO 提議實施 Scrum，並解釋說 sprint 將迫使工程師遵守紀律並以兩週為增量進行計劃，而不是決定每天做什麼。 另外，我建議他們聘請產品負責人，這將解決團隊缺乏產品責任的問題。 我要求高管們給我三到四個月的時間與他們的團隊一起工作，然後他們才能期望看到結果。

在得到他們的認可後，我首先介紹了敏捷的價值觀和原則，然後對團隊進行了產品待辦列表和安排它的不同技術的培訓，包括製作史詩和用戶故事，以及創建子任務。 我們在工作流程中包含的技術和會議與傳統的 Scrum 不同，因為它們沒有出現在 Scrum 指南中。 我將它們整合到計劃中，因為史詩、故事和子任務在培訓期間與團隊產生了共鳴，並且會議促進了富有成效的討論。

我還包括了速度的概念，它是 XP 的一個後期補充，用於測量每個產品迭代中所有用戶故事的總努力估計。 然而，我使用了“能力”這個詞，我更喜歡這個詞，因為它強調團隊成員可以完成多少工作，而不是他們完成任務的速度。

為了估算，我從 T 卹尺碼開始，這是一種衡量項目和任務大小的技術； 隨著團隊的進展，我轉向了故事點，這是一種更傳統的估計技術。 故事點經常被不熟悉敏捷的團隊濫用，他們試圖將它們轉換為工作時間或天數，過度關注時間框架，並根據他們在截止日期前的能力來判斷人們。

T 卹尺碼更加抽象，讓團隊更容易避免這個陷阱。 但是，它也不太精確。 因此，一旦團隊了解瞭如何進行相對估計，我就將它們轉換為更複雜的技術。

當團隊完成兩個衝刺時，高級管理人員能夠看到他們的員工更高效地工作和更有效地溝通。 開發人員第一次與利益相關者和執行管理層接觸。 他們會見了客戶支持團隊，並了解他們實施的功能如何改善用戶的生活。

這種方法很快提高了公司軟件的質量，並將新功能的交付時間從幾個月縮短到幾週。

敏捷的未來是什麼？

COVID-19 大流行創造了一個新的現實，即團隊不再可以在同一地點辦公，這是在敏捷構思時首選的工作方式。 然而，它必須保持這種方式的想法是一個神話：隨著遠程工作變得司空見慣，很明顯，使用視頻會議軟件完全可以實現密切通信。 我現在合作的團隊是完全分佈式的，我正在遠程提供培訓。 一些團隊甚至選擇異步工作，使用 Notion 和 Loom 等工具，以及 Standuply 等 Slack 插件。

分佈式協作模型是新的工作世界，其核心是敏捷性。 為遠程團隊提供的工作與生活平衡對士氣和心理健康有積極影響，從而提高生產力和質量； 它將人員置於流程之上，靈活且適應性強，使其成為典型的敏捷。

敏捷教練、Scrum 大師和項目經理應該回到哲學的根源，並像宣言的製定者那樣呈現它：一套靈活且動態的開發和交付指南。 他們應該教導高管和團隊領導者，雖然他們可以從項目管理中獲得靈感，但他們並沒有真正管理敏捷中的任何事情——他們是在指導團隊並讓他們自由地去做最好的工作。