Liga譯文 | 一文講清「敏捷路線圖」

語言: CN / TW / HK

儘管許多組織和團隊聲稱自己非常敏捷,但他們仍在使用瀑布的方式規劃產品。為什麼會這樣?我們該如何改變這種「錯誤敏捷」?

原則上,踐行敏捷開發很簡單:構建一個增量測試這個增量瞭解需要改變的資訊將資訊反饋到第一步中,並重復步驟

整個過程可以從兩個方面,將敏捷開發與瀑布開發徹底區分開:第一,儘早且頻繁地交付小批量的可工作的產品第二,根據(一)得到的新變化和資訊,對產品進行恰當的調整。

如下圖所示的敏捷路線圖很常見。時長一年的甘特圖上堆滿了功能,並提前完成了任務分配。研發團隊只能在一個個不間斷的迭代中,實現所有的功能;他們還沒有機會總結已交付的工作並作出調整,就必須立刻進入下一個功能開發。

圖1. 這樣的甘特圖怎麼可能敏捷?

如果前兩個產品功能交付後被證明是錯誤的(這非常有可能發生),難道我們還要按原計劃迭代下去嗎?繼續遵循上面的甘特圖,可能會一錯到底。因為計劃好的路線圖無法幫助我們評估交付效果,識別問題並及時調整。

敏捷開發刻意只關注下一次迭代的即時計劃,但許多團隊構建了一年甚至更長時間的甘特圖,並且羅列了無數個待開發功能和完成截止日期。這樣怎麼會敏捷呢?

01 前瞻性計劃:敏捷刻意忽略的部分

除了當前迭代正在構建的產品外,敏捷方法論不太關注前瞻性的計劃。因為只有這樣才能做到 「實時計劃」 ——我們應該看到什麼是可行/不可行的,並根據反饋的資料決定下一步該怎麼做。

敏捷意味著「能夠快速輕鬆地行動」,而敏捷開發需要被持續引導,逐步提供價值,再根據市場反饋的情況快速調整策略和方向。 這是一個建立在洞察與反應幾乎同步的快速反饋週期,而不是基於前期的大計劃。

但是,組織(尤其是大型或傳統組織)通常不喜歡沒有計劃地工作。沒有計劃的組織會陷入「計劃缺失焦慮症」;更準確地說,組織的領導者會很焦慮。因此,他們會制定一個功能列表,提前做好分配,以確保每個人都能按預定的方式有序地工作。

敏捷的組織應當正面解決計劃缺失的焦慮,但許多團隊沒有這樣做。反而是領導者們認為,過去路線圖和甘特圖很有用,那就應該繼續使用它們。慢慢地,敏捷就變形成「Water-Scrum-Fall」,就像下圖這樣。

圖2. 迭代中的「敏捷式開發」僅是瀑布開發中很小的部分

不幸的是,敏捷的核心——靈活自由地根據新資訊進行調整——被完全忽略了。許多團隊實踐的敏捷並不是真的敏捷,而過去的瀑布式任務列表也演變成了「使用者故事」列表。

02 SAFe:敏捷介面卡

敏捷框架沒有提供任何當前迭代以外的具體規劃建議,而擴充套件框架正填補了這一空白。SAFe 有一個優點:作為從前期瀑布式大計劃到團隊敏捷執行的介面卡,它可以很容易地被理解。

使用 SAFe(或其他擴充套件框架),產品管理團隊提出功能,設計團隊繪製 UI 模型,再發送給管理層審批。當工程師開始編寫程式碼時,管理層會很放心。因為他們已經做好了充分的計劃,而成百上千名程式設計師都會盡職盡責地工作。

通過敏捷擴充套件框架,管理人員可以看到所有計劃中的功能,而開發人員可以在迭代中專注地寫程式碼。這也是敏捷擴充套件框架受歡迎的原因:它們將領導者熟悉的大型計劃,轉換為研發團隊可執行的敏捷迭代。在一些高階管理者看來,這就是最重要的。

事實上,工程團隊已淪為「功能工廠」,他們幾乎失去了所有學習、快速調整和改變的能力。管理者卻真誠地相信,團隊已經完成「敏捷轉型」。

03 敏捷性需要空間來操作

回到前面提到的兩個決定性敏捷特徵:儘早且頻繁地交付小批量的可工作的產品根據(一)得到的新變化和資訊,對產品進行恰當的調整。

第一點比較好理解,幾乎所有資料也都集中在這上面;能夠正確掌握第二點的人要少很多。如果團隊沒有從早期部署的迭代中學習,也沒有將洞察力融入後續的迭代優化,那麼就沒有正確地踐行敏捷——這其實只是**「增量瀑布」**。

正確的敏捷要求組織多次釋出和重新發布相同的功能,並且每次都要從早期的經驗中吸取教訓,使該功能更易於使用、更強大、效能更好或在某些方面更好。 這需要時間,而且這些時間無法在前期被充分估計和預先承諾。

因此,要想成功地洞悉變化,完成迭代優化,團隊需要在計劃中做到以下三點。

  1. 計劃實現的路徑必須是可塑的。 定義一個願景或最終目標,但允許具體的功能和內容在執行時可以有所變化。 我們無法準確預測一個功能會如何運轉,所以需要測試它。敏捷團隊要允許每個功能能被反覆加工、打磨或擴充套件幾次,直到真正實現它。

  2. 計劃需要為調整和優化留出彈性空間。 如果時間已經全部按計劃分配完,就需要刪掉一些東西。正確的策略是在一開始就不要填滿所有時間,讓它保持開放狀態;可以為新想法整理一個新佇列,直到時間允許,再進入迭代分配。後文的 「Now-Next-Later」也會詳細講解這一方法。

  3. 領導的支援。 這通常是三點中最難實現的。

04 領導力是敏捷性的關鍵

最具影響力的成功因素是組織展示和激勵的領導正規化。 —— Agile 2

很多領導層都認為敏捷是團隊內部的事情。這種假設肯定是錯誤的,而領導們也需要以敏捷的方式行事。在專案過程中,如果要為團隊提供調整的空間,領導者就要接受臨時的計劃。「可塑性強的路徑」和「允許調整的彈性空間」印證了這點。

管理者要有足夠的勇氣和決心,才能對團隊說:“我們不打算在這個迭代將你們的工作填滿;你們需要跟著資料走,看看自己的工作成果。”

如果領導者要真正擁抱敏捷,他們就需要做出根本性的改變。這遵循精益創業的精神:建立一個專案、測試它、從資料中學習、並將這些經驗直接反饋到後續的專案中

同時,領導者也要有勇氣,接受這些事實:團隊不會在外部干擾下提前確定工作,也不會一輪接一輪無縫地進行功能開發。團隊需要更多實驗性、創造性和跨職能的工作。

這同樣意味著,領導者需要快速響應、批准通過更多碎片化的需求變更。他們要探索出更靈活地工作方法,以便為團隊提供及時審批。這無疑會打破官僚主義的枷鎖,而由領導者們組成的小團隊則能更快、更獨立地監督和批准自己團隊的工作。

05 Now-Next-Later 模型

更常用的敏捷路線圖工具是 「Now-Next-Later」模型。甘特圖中層層疊疊的功能集可以歸納總結為三個模組。

  • Now:我們正在積極工作的事情。
  • Next:「Now」完成後,即將開始的工作。
  • Later:其他所有未分配和未承諾的功能。

將新的需求、功能和工作按模組規劃好,比擠進擁擠的甘特圖要容易得多。我們可以很輕鬆地在每個模組中留出彈性容量空間,以便後續根據最新資訊做出調整。

圖3. 一個典型的「Now-Next-Later」路線圖。

可以看到,「Now」中的專案定義得比「Next」更加詳細,「Later」是定義和描述最少的。每個模組的時間跨度可以自由決定,但最好跨度大一些,儘量覆蓋多個迭代和優化週期;建議的時間週期是每個模組 6 周或者一個季度

正確地使用「Now-Next-Later」,既能讓我們適應短期變化,為後續工作和 Bug 修復留出空間,也能適應長期變化,改變我們對哪些功能要從模組中取出的想法。

但它不會消除干係人要求儘快交付功能的壓力。這也是為什麼領導者需要自己擁抱敏捷,才能讓團隊成功。領導者需要通過自己的努力,倡導敏捷的工作方式,並以同樣的標準要求自己。

06 結論

許多自稱敏捷的組織,他們提前計劃了大量功能列表——通常提前一整年——並告訴團隊要以小批量的方式交付。這不是敏捷,這是增量瀑布。

敏捷開發的核心特徵是小批量地交付可工作的產品,從早期迭代中獲得洞察力,並在後續迭代中進一步完善和優化相同的功能。 其中的關鍵在於我們無法預知和確定什麼是可行的,什麼是行不通的;這需要洞察和跟蹤資料。打造一款優秀的產品,我們要一邊走,一邊制定計劃。這與一年長的甘特圖完全不同。

「Now-Next-Later」只有與團隊自主權相結合時才有意義。這樣才能使團隊發現計劃的調整空間,及時做出應對。

想要靈活地工作,在做計劃時要注意建立高度靈活的路線圖留出充足的彈性空間用於響應調整,以及獲得領導層的積極支援。利用好這三點,就可以持續地引導專案,而不是在前期就將它固定下來。這就是敏捷真正的意義所在。


原文作者:Raj Nagappan
文章出處:Medium

瞭解更多敏捷開發、專案管理、行業動態等訊息,關注我們 LigaAI@oschina 或點選LigaAI - 新一代智慧研發協作平臺,線上申請體驗我們的產品。