“敏捷轉型是根據具體問題的演進過程，也是和各干係人真誠合作的結果。敏捷教練需要在戰壕裏。”
以下是我最近一個項目的敏捷交付模式，它是一個以供應商交付爲主、從0到1搭建整套業務系統的過程。
但這個模式並不是一開始預先設計出來的，而是我們和業務、供應商相互配合演進出來的。所以這個模型圖是一個事後總結。
在這個過程中，我們並沒有像以前那樣在一開始嘗試通過敏捷培訓給業務、供應商“洗腦”，然後根據套路設計全套的模型，要求業務與供應商配合。相反，我們在一開始對“敏捷”隻字不提，而是針對一個個當時面臨的具體交付問題，看看有沒有合適的敏捷、精益的工具和實踐，接着和業務、供應商耐心講解我們想具體怎麼做，對大家有什麼好處，需要大家怎麼配合，然後一起嘗試着去做，遇到新問題及時調整。下面我舉一些例子：
通過JIRA統一管理和跟蹤需求
問題：爲了滿足我們的業務特性和IT的全球架構、安全標準，不管是業務還是IT，對供應商產品都有大量的定製化需求，這些需求需要統一登記，需要討論優先級，從需求、開發、測試到部署的全流程也需要跟蹤。
解決方案：我們推薦了JIRA作爲管理工具，排序後，從JIRA導出需求給供應商進行開發，在JIRA上建立實時的進度板。
好處：需求統一管理，避免混亂；進度可視化，讓所有人都能看到；實現了需求版本化管理。限制在製品
問題：項目一開始我們就收集到了60多個需求，然後一次性地推給了供應商，不斷給他們施壓。但很快我們發現這樣不可行，跟蹤起來也很費勁。
解決方案：我們思考是否可以用敏捷、精益裏的限制在製品的思想，根據供應商在這個項目投入的資源限制每個週期派給他們的需求數量。
好處：供應商可以聚焦在有限的需求，從而提高交付速度，大大減少“跳票”的情況，也使我們的跟蹤輕鬆了很多；把所謂的“高優先級”變成有限資源，迫使我們認真思考哪些需求是當前最迫切的。每週交付計劃會議
問題：需求分別來自不同部門，優先級需要統一。
解決方案：在限制在製品的原則下，我們每週和業務回顧本週交付的情況和下週的交付計劃，然後把這個計劃交給供應商。
好處：確保大家保持一致的優先級，實現價值驅動交付。每日例會
問題：業務需要透明度。同時，由於沒有一個業務代表可以承擔PO的角色，代表所有業務人員做決策。而我們有很多事情需要業務一起集體決策。
解決方案：我們建議每週一、三固定時間和業務舉行簡短的例會。一來，把JIRA看板中的需求進度過一遍，也可以藉此催促業務人員儘快完成測試。二來，有什麼需要決策的，也通過這個會議快速討論形成決策。我們也會和供應商每週二、四進行例會，跟蹤交付計劃中每一個需求的進度和狀態。
好處：進度透明化，所有人都有了全局視角，共同加速需求完成；快速集體決策；確保供應商進度。縮短反饋環
問題：我們發現有一些需求業務覺得很簡單，但供應商做了好幾月都沒做對。而一個需求，需要經歷登記、排序、需求澄清，在供應商那邊要需求確認、設計、開發、測試、發包，然後由我們在公司服務器上部署後才能驗證是否做對，整個鏈條非常長，做錯的成本非常高。而供應商的交付模式還是比較“傳統”，需求、設計、開發、測試、發包都分屬於不同的部門，存在大量的交接。
解決方案：通過走訪供應商，瞭解了他們的交付特點，我們提出了在每個環節增加反饋確認（如下圖）。
好處：縮短反饋環，確保正確交付。
通過這一個個針對具體問題的具體實踐和工具，我們改善了與業務、供應商的協作模式，提升了交付效率。在大家享受到實效的基礎上，我才慢慢地把一些敏捷的理念和原則通過閒聊滲透開去。這是一次成功的落地和轉型。
在這個過程中，我的體會是敏捷教練需要在戰壕裏。在這個項目中，我是IT交付負責人，需要對結果負責。但同時，作爲一個敏捷專家，我當然不會放過任何一個提高交付效率，改善協作方式的機會。但這是一個根據具體問題的演進過程，也是和各干係人真誠合作的結果。
關於這個項目的更多細節，可以參閱我的另一篇文章《與供應商的敏捷初體驗》。
關於作者
就職於世界500強銀行，負責基金服務業務軟件開發與交付
敏捷、精益、DevOps專家
精通極限編程、Scrum、看板方法、測試驅動開發、持續集成、行爲驅動開發、DevOps工具棧
曾在GDevOps、DevOpsDays Meetup、中國軟件技術大會等論壇發表主題演講
著有《獵豹行動：硝煙中的敏捷轉型之旅》一書
購書通道
—
紙質書、電子書在京東、噹噹、亞馬遜等渠道已全面上架，搜索“獵豹行動 硝煙中的敏捷轉型之旅”。
噹噹自營購書碼：
京東自營購書碼：
關注公衆號看其他原創作品
