實現非軟件IT項目的敏捷交付

“你將如何使用敏捷交付模型管理一個戰略項目？”Elle問道，聲音中有明顯的憤怒，“可以工作的軟件在哪兒？你如何及時展示業務價值？”

這個對話的背景是MotoClaim & Co.正采用一種面向服務的企業理念開展一項重大變革舉措。Elle是整個項目的交付經理，對敏捷并不陌生。我是該計劃的流程咨詢架構師。我們都剛剛從一 個高層管理會議上出來。會上決定，該計劃的第一階段將包括制定一個戰略來執行整個變革以及開發所需的基礎架構。在這個會議上，雖然包括Elle在內的許多 高層管理人員都持懷疑態度，但我還是力爭使用敏捷來執行第一階段。

Elle的問題絕不是MotoClaim & Co.特有的。在我上個十年的敏捷咨詢生涯中，我多次同我的客戶涉眾產生過這種爭論，即使它在敏捷交付方面已相當成熟。當涉及 非軟件 項目時，任何人都更愿意采用迭代方法。所謂非軟件項目，我是指那些不以將可以工作的軟件交付生產為目的的IT項目，比如戰略定義項目、架構項目、內部評估 項目、咨詢項目。雖然對于組織而言，這些項目包含著豐富的內在價值，但通常，它們對于終端用戶而言是不可見的，而且不會影響他們的正常業務。

那么，在非軟件項目中使用敏捷交付有什么問題？首先，如果我們看下現有的敏捷著作，其中的大部分，包括敏捷原則在內，都以盡早和頻繁地交付“可以工作的軟 件”為中心——毫無疑問，可以工作的軟件與交付生產軟件的項目有關。由于非軟件項目不交付可以工作的軟件，所以很難覺察它們與 通過盡早和持續地交付有價值的“軟件”來滿足客戶 、 頻繁地交付“可以工作的軟件” 以及 將“可以工作的軟件”作為衡量進度的主要指標 等敏捷核心原則的契合度。另一個關鍵的原因是多重所有權，戰略項目尤其如此，它們通常會有許多存在利益沖突的知名涉眾。沒有確定的行業指標可以度量非軟件 項目是第三個方面的原因。我見過許多架構項目中途停工，因為業務涉眾覺得項目結果與花費不匹配。因此也就不奇怪，組織為什么經常會發現很難證明敏捷交付適 合于非軟件項目。

你可能會問，“那么，這有什么意義，為什么非要在這些非軟件項目中使用敏捷呢？通常，這些項目都是短期的，只會持續三個月到一年。我們為什么不能簡單地遵循瀑布方法或迭代方法？”要回答這個問題，我們需要從頭說說敏捷實施的基本知識。

我們都知道，不是所有的項目都需要敏捷交付。那么，項目是否采用敏捷有什么判斷標準呢？可以使用Ogunnaike和Ray[1]提供的圖解，我們說，任 何落在“簡單區域（simple zone）”之外的項目都必須使用敏捷。而簡單區域之內的項目使用敏捷幾乎沒有什么價值。為了確定一個項目是否簡單，我們通常對項目進行“敏捷執行能力評 估（Agile Readiness Assessments，縮寫為ARA）”，通過審查各個參數弄清楚以下四個關鍵因素：

• 涉眾對他們的需求了解程度如何？
• 涉眾對他們的技術了解程度如何？
• 不同的涉眾之間存在利益沖突嗎？
• 是不是有很高的失敗風險？

不用說，大部分戰略、架構和咨詢項目在上述四點都存在很大的風險，因此幾乎總是需要高可見性、及早緩解風險、適應不斷的變化以及快速闡述業務價值。這時，使用敏捷既不可否認也毋庸置疑。事實上，我認為，與其它項目相比，敏捷方法更適合非軟件項目。

下一個明顯的問題是“我們如何做到這一點？”在我看來，只要組織停止使用“ 規范的敏捷（prescriptive Agile） ”。雖然敏捷的根本是自適應，而非規范性，但規范的敏捷是現如今存在于敏捷交付領域的主要矛盾修飾法之一。在一篇 見解深刻的文章 中，Abraham Kiggundu寫道：

Arijit Sarbagna的文章[2]也強調了這一概念：“如果你實踐敏捷，那么你一定遇到過那個名為‘規范的Scrum’的不老惡魔。”

一個著名的演員曾在一部流行的印度電影中說過這樣一句話，“宗教無處不在，無法消除。如果你試圖消除一種宗教，那么你本身就會‘成為’宗教。”千 真萬確。多年以來，軟件行業一直像信仰宗教那樣實踐著現在已經過時的瀑布方法，直到敏捷方法向他們展示了自組織團隊和更快的交付能力。雖然敏捷方法成功地 消除了進展緩慢的瀑布方法，但現在，許多組織已經將敏捷作為他們的宗教。這個在宣言中宣稱“人勝過過程”的過程本身現在已經成為一個標準化的、規范的過 程。

“敏捷（to be Agile）的工作”，這是使用敏捷成功交付項目所需要的唯一規范的做法，非軟件項目也不例外。

為了使用敏捷成功地執行一個非軟件項目，我在自己的工作中定義了如下這個“5點議程（five-point agenda）”。雖然這可能不是一個解決方案，但它可幫助我為涉眾設定清晰的期望，理智地執行項目以及挖掘敏捷的好處。雖然這個議程可能看上去與敏捷軟 件交付項目所遵循的原則類似，但當涉及非軟件項目時，它們的用途卻大不相同：

1. 定義“可以工作的軟件” ：雖然這個術語通常被視為一個可執行文件，但它可以用于指代項目生成的任何可以為客戶帶來價值的交付物。例如，它可以是一個改進的路線圖，一個架構原型，一個戰略文檔，或者是一份成本收益分析。
2. 定義“客戶” ：在開發領域，很容易知道誰是終端客戶。然而，在非軟件領域，可能很難確定客戶。通常，客戶是那些與項目有直接或間接利益關系的涉眾。不過，不同于系統的 終端用戶，這個客戶集合可能存在優先級沖突、內部偏見或先入為主的觀念。在這些涉眾中間，有許多人是高層管理人員，甚至是C級高管，這讓這項任務變得更加 困難。選一個可以控制這種復雜性的‘合適’的產品經理至關重要。
3. 定義“完工” ：同項目發起人和產品經理一起確定每個故事/交付物的“完工”標準。對于非軟件項目的許多交付物，由于傳統的質量保證可能并不適用，所以確定成功條件非常 重要。例如，一個架構原型的成功標準可以是關鍵設計評審加演示。這里的問題是，由于這些交付物中的大部分都要后續通過軟件開發項目實現，所以涉眾可能會延 期審批，直到交付物成功地用在了將來的開發項目中。這等于將兩個項目都置于失敗的境地。如果戰略失敗了怎么辦？現在，我們需要面對兩個失敗：一個是已經關 閉的非軟件項目，其戰略交付物無效，二是正在進行中的開發項目由于戰略錯誤而無法繼續。
4. 度量業務價值 ：對于非軟件項目而言，度量或證明已完工工作的業務價值是一個關鍵。由于大部分交付物都以理論或原型的方式存在，所以有一點很重要，就是在項目開始的時候 準備一個企劃案，清楚地描述項目的成本收益，每隔一段時間就對收益進行闡述，最好是在迭代結束的時候。非軟件項目的度量指標應該確定并制度化。例如，一個 架構開發團隊可能會采用風險緩解因子、建議擁有總成本（TCO）、建議節約總成本和“架構相符率（architecture due diligence rate）”等指標。
5. 預測意外 ：眾所周知，戰略或咨詢項目非常多變。這很正常，因為項目發起人和管理人員還處于頭腦風暴模式。項目范圍、目標和目的經常會發生很大的變化。因此，要采用 更短的迭代、聯合研討會、交付物結對開發、連續的專家和同行評審以及理論和思想的適當社會化。資深策略師、架構師或者顧問非常有用，尤其是如果他們對主題 以及整個組織有豐富的經驗。

一旦議程確定，整個項目就很容易使用Scrum或其它過程運行在敏捷模型中。你會驚訝地看到，像結對編程、測試驅動開發和重構，這些沒有可以工作 的軟件就看似無關的標準敏捷技術可以完美地運用到非軟件項目中。我已經在許多不同類型的非軟件項目中成功地使用了這個議程，包括戰略制定、企業架構開發、 業務流程優化、流程定義和制度化、指標開發。下面，我將介紹其中的兩個案例。

案例

案例1：基礎架構開發

為了將現有的遺留平臺現代化并遷移到面向服務的模式，組織著手進行一項大規模的變革計劃。由于組織中現有的所有架構元素均是特定于遺留平臺的，所 以，為了實現面向服務的交付，I.S.領導人希望在初始階段識別、獲取并建立一個基礎架構。按照資深架構師的估計，創造服務開發所需的最基本的架構元素需 要一年的時間。作為一項高風險的任務，I.S.領導人希望在敏捷模型中運行該項目，以便盡早消除風險，建立所有層面的、完整的可見性。

作為描繪項目愿景的一部分，我與關鍵涉眾一起確定了5點議程：

1. 定義“可以工作的軟件” ：對我們而言，每個重要的交付物都是“可以工作的軟件”。確定主要交付物是必不可少的活動，因為待辦事項列表很快就被涉眾和團隊希望通過這個項目提供的東 西填滿了。這既包含基本的基礎元素，也包含高成熟度功能。我們仔細排定優先級，并且，只有在團隊覺得某項工作可以為組織提供可觀的業務價值同時組織也已經 準備好接受這種變化時，我們才會同意交付這項工作。為不同的環境創建技術基礎設施/工具、設計文檔開發以及技術/概念可行性驗證是“ 可以工作的軟件”的主要類型。
2. 定義“客戶” ：由于這個項目是一個企業級項目，我們需要同大量的涉眾共事。我們開發了一個“影響力-興趣網格（influence-interest grid）”[3]，幫助我們理解溝通需求和潛在的變革阻力。我們指定其中一位“興趣高、影響力大”的涉眾作為產品經理。這位產品經理是部門的一名助理副 總裁，他的影響力幫助我們很好地排定了優先級，并讓我們獲得了所需的社會化和支持。
3. 定義“完工” ：每個“可以工作的軟件”都有“完工”標準， 是同各涉眾討論確定的。例如，對于基礎設施創建，我們同企業基礎設施支持團隊一起得出了一組測試用例和抽樣測試數據，用于驗證基礎設施是否正確安裝。對于 設計文檔，企業體系結構委員會（EAB）會進行關鍵設計評審。我們同指定的EAB評審員一起起草了一份詳細的檢查清單，他們會根據這份清單評審文檔。
4. 度量業務價值 ：甚至在項目開始前，一份包含成本收益分析的企劃案就提交給了管理層，清楚地闡述了投資回報率（ROI）。在每一次沖刺中，我們都會對我們同已承諾ROI 的相符度進行高水平的度量（有時候定量，有時候定性）。例如，在創建服務注冊中心后，我們闡述了企劃案中提出的可重用價值的實現。我們實際地創建了一個小 而簡單的生產者-消費者服務場景，清楚地展示了，消費者服務如何通過注冊中心輕松地發現和重用現有服務。
5. 預測意外 ：這更多的是為團隊所接受的一種文化。我們有四周的沖刺，我們不斷地同產品經理一起回顧我們的目標。作為一名Scrum Master，我勤奮地維護著風險和障礙日志，經常與項目發起人進行面對面的交流。有一名具有很高組織影響力的產品經理是有好處的，因為我們可以及時跟進 組織內正在進行的高級戰略變革，并為即將到來的變革做好準備。另外，我們還創建了慣常的組織變革管理規程，那樣，可以對項目范圍和目的變更進行適當地社會 化和系統闡述。

在確定了5點議程后，我們使用Scrum和若干XP、DSDM做法成功地完成了項目，并且用時低于預期。現如今，該組織已經成為一個著名的、面向 服務的解決方案提供商，而且已經接受了“開放組織服務集成成熟度模型（Open Group Service Integration Maturity Model，縮寫為OSIMM）”[4]的五級評估。

案例2：業務流程優化

在對價值鏈進行了多次不成功的升級后，該組織啟動了一項重要的計劃，徹底重建其端到端的業務流程。該項目的第一階段主要包含業務架構工作，設計目 標流程。這是一個高風險的項目，因為變革幾乎會影響到組織的每位成員以及終端客戶。作為一名流程教練，我被要求協助團隊使用敏捷模型執行這一項目。

再一次，我與關鍵涉眾一起確定了5點議程：

1. 定義“可以工作的軟件” ：自然，目標流程模型是可以工作的軟件的關鍵候選。對于更大、更復雜的流程，團隊會將其分解成多個邏輯階段，每個階段均被視為可以工作的軟件。交付物是使用業務流程工程語言（BPEL）創建的流程模型。
2. 定義“客戶” ：雖然客戶的定義很簡單，而且可以從角色-流程映射中識別，但真正的挑戰在于滿足他們的預期。客戶很多，而且對目標狀態的要求相互非常矛盾。部分人想要更 多的控制權，而其它人則傾向于更大程度的自治。市場部希望產品更靈活，那樣可以增加銷售額，而索賠部門則希望產品不那么靈活，那樣索賠過程更快。我們知 道，產品經理是其中一位業務負責人，但每位業務負責人都要迎合一個特定的部門，并且會偏袒那個部門的需求。在我作為敏捷教練的漫長職業生涯里，這是第一 次，我們真正地同三位產品經理一起翻新整個價值鏈。雖說要“敏捷的工作（being agile）”，但我們仍然設定了一些基本原則。首先，團隊從三位產品經理那里獲得的方向應該始終保持一致。其次，產品經理之間的任何意見分歧要內部解 決，團隊不參與其中。最后，產品經理的任務和決策都有時間限制。
3. 定義“完工” ：這一部分簡單。產品經理們同他們各自的部門交流，準備一份他們希望從新系統獲得的完整的“特性”列表。然后，經過過濾和排定優先級生成一個短列表。該短 列表將在沖刺評審報告期間、團隊在BPEL工具中展示理論上的流程時供業務經理和終端用戶使用。會議上提出的任何新特性都會添加到待辦事項列表中，并排定 其在下個沖刺中的優先級。
4. 度量業務價值 ：度量業務價值并不是非常復雜。當前業務流程的現有模型里指定了每項活動所耗用的最佳、最差和平均時間。這是組織先前完成的一項研究工作的一部分。當創建 目標模型時，我們可以確定時間的減少和其它效率的提升。例如，如果在現有的流程中索賠過程需要兩周，那么在目標流程中，我們可以展示，我們如何通過自動化 處理規則將處理時間縮短到四天。用這種方式闡述業務價值可以確保獲得用戶社區的持續關注和對項目的支持。
5. 預測意外 ：再說一次，這點更多的是一種文化。我們有四個周的沖刺，我們不斷地同三位產品經理回顧我們的目的。我勤奮地維護著風險和障礙日志。我們歡迎所有新需求或 對現有需求的變更。但是，我們設定了一個明確的預期，就是變更的加入取決于它的優先級。所有的客戶都能看到待辦事項列表和燃盡圖。另外，我們還建立了傳統 的組織變更管理規程，那樣，項目范圍和目的的變更可以得到適當地社會化和明確地闡述。

小結

正如上述兩個案例所闡述的那樣，敏捷的使用可以跨越學科邊界，而且非常有效。此外，對于非軟件項目，由于它們固有的風險和復雜性，敏捷交付是必要的。模型可能會變，但敏捷的概念不會變。我們需要遵循整個敏捷宣言，而不是遵循規范的敏捷方法：

• 個體和交互勝過過程和工具；
• 可以工作的軟件（或者交付業務價值）勝過面面俱到的文檔；
• 客戶合作勝過合同談判；
• 響應變化勝過遵循計劃。

請記住——“敏捷的工作，自適應”。

參考資料

[1] Process Dynamics, Modeling, and Control ，英國牛津大學，1992。

[2] 規范的Scrum——這是世界末日或危情時刻的需要嗎？ ，發表于Scrum聯盟社區。

[3]Mitchell, R. K., B. R. Agle和D.J. Wood. (1997)，“ Toward a Theory of Stakeholder Identification and Salience: Defining the Principle of Who and What really Counts .”，發表于 Academy of Management Review 22(4): 853 - 888。

[4] 開放組織服務集成成熟度模型

關于作者

Dipanjan Munshi 是Tata Consultancy Services （TCS）的一名資深流程和質量顧問，有超過17年的IT經驗，而且涉及多個領域，包括保險、金融服務、制造、嵌入式系統、交通和酒店業。他擁有印度奧里薩邦烏特卡爾大學計算機應用專業碩士學位。

查看英文原文: Implementing Agile Delivery for Non-Software IT Projects