敏捷是局部優化的嗎？

 據我對敏捷社區中人們擴張敏捷邊界的建議的審視，我認為敏捷正逐漸進入到局部優化的危險之中。

在繼續下去之前，讓我先回顧一下對優化系統和局部優化系統的定義：

“優化系統是在整個系統的價值流之上對系統的優化或對浪費的消除的系統。”

“局部優化系統是在系統的部分價值流對系統的優化或對浪費的消除的系統。這有可能會導致整個系統效率降低。”

項目價值流

敏捷專註於項目價值流，這很正確，我認為沒人會質疑：以敏捷的方式執行項目時項目價值流是最大化的。

那項目之外的價值呢？項目集和公司價值呢？

項目集價值流

如果我通過所聽到的被最頻繁提及的一致的意見來遵循敏捷，那麼就會缺乏下面兩種項目信息：

項目記憶 —— 關於項目是如何規劃和執行的信息。

解決方案記憶 —— 關於項目的技術或功能的解決方案

如果我在便條上寫用戶故事，通過看板進行管理，我的回顧記錄、應用程序和自動化測試用例是最後主要的文檔，那我能回答一下這些問題么？

1. 我怎麼才能查找之前的項目以充分利用機會？我非得先通讀代碼和測試，然後再通過某種方法才能決定如何充分利用機會么？
2. 我怎樣才能回顧之前的項目歷史，查看之前是怎樣進行估算的，以幫助我這次作出更好的估算？
3. 既然我們認識到永遠也沒有足夠的時間去創建出所有的自動化測試用例，我怎麼才能知道如果一個新需求變更是否正在實現某種設計之外的功能，並將產生我無法預期的副作用呢？因為我還沒有自動化測試來確保這個需求變更當前的正確性。
4. 我怎樣才能確保我的解決方案能夠符合多個相互沒有高層認識的項目呢？
5. 如果公司僱員已經完全換血，我有足夠的文檔在未來十年中來維護這些應用程序么？
6. 如果部門中的現實是，在項目進行時部門中許多人都不能專註在項目上。那我怎樣才能管理這樣的部門呢？對於這類情況我需要更多的文檔么？

從本質上說，敏捷軟體開發項目是獨立的項目，主要由全職成員組成，且幾乎沒有跨越項目的監管。這導致了對項目集價值流關注的更大的需求。

公司價值流

或許最近最麻煩的傾向之一是這樣的說法：不應再進行任何估算了，因為它們必然是錯誤且浪費時間的。建議直接啟動項目，在項目進行兩三個迭代之後就可以確認速度了，據此速度給出完成項目的精確估算，並通知客戶。

這一說法是從整個項目的角度來看的。每個啟動的項目都需要商業案例的支持：投入X美元將獲得價值Y的回報，並且這在商業上是可接受的。如果我們不再對項目進行估算，我們將會冒後面這些風險：啟動錯誤的項目；消耗項目的投資，直到我們確定花太多錢了，或是回報的價值太小了。

如果我們真的關心公司長遠的生存能力，那麼宣稱我們不再需要進行估算是荒謬的。這其中隱含了我的信念：用戶故事點必須轉換為小時數。在我與開發人員的討論中，他們要求每個用戶故事都有小時數，以確保他們走在正軌上。

雖然我喜歡拿用戶故事和用戶故事點數來進行估算，但如果我們不把用戶故事點轉換為小時數，那我們就是局部優化的。我們在把開發過程置於滿足商業案例之前。不把與項目的商業案例相關的估算的上下文告訴開發人員，就相當於我們在商業案例和開發人員之間形成一個隔離層。我們會讓項目迭代更加高效，但同時也可能犧牲了滿足商業案例的能力。

但商業案例不正是項目存在的理由嗎？

三種確保敏捷項目不是局部優化的方法

1. 對項目進行估算 —— 確保對項目進行了估算，確保估算被納入了讓項目有存在的理由的商業案例之中。這些估算必須給予它們應有的關心和關注，而不僅僅是為了讓項目通過審批而估算。我對如何對敏捷項目進行估算的建議改天另行探討。
2. 創建輕量級的解決方案架構交付物 —— 確保項目的解決方案架構的定義在高層次上進行，確保所有人都對這一解決方案有統一的認識。而後，這些交付物能用於項目監管，確保一致性並能充分利用項目集中跨項目的機會。
3. 把用戶故事估算轉換為小時數並對時間進行追蹤 —— 將用戶故事轉換為小時數，與開發人員一起設定預期時長，也為業務案例提供信息以確保項目走在正規之上。追蹤時間，這可能會給每個人的日常工作生活帶來不便，但實際上確實對項目集和公司有很大的價值。雖然了解項目的速度可以很好地進行預測和規劃，但無法讓我了解下面這些：

• 何種類型的工作是我們估算不充分的或是花了比預期更長時間的？
• 何種類型的工作是我們估算良好或是只花了比預期更短時間的？
• 何種類型的工作是我們忘了估算的？
• 我們遇到的什麼問題增加了我們完成任務的時間？

總結

“我們以敏捷方式運作項目，是否在犧牲企業長遠目標？”我認為沒人會認為敏捷不是最好的執行項目的方式。但我確實認為有時敏捷僅僅關注項目和項目內的客戶的價值，這可能會導致缺乏對項目集和公司價值的關注。

在對過程進行優化時，我們要確保時刻把整個價值流銘記於心。否則，會有一堆非常成功的項目存在於許多失敗的公司之中。

關於作者

Terry Bunio目前是Protegra的首席顧問。Terry從未想過成為一名項目經理。他的主要職業生涯都是在數據架構方面。隨著時間的推移，Terry發現他喜歡上了幫助建立團隊，增加客戶信賴，促進個人成長，從事項目工作和幫助指導解決方案。這些似乎就是一些人眼中的項目管理。作為一名有實踐經驗的項目經理，Terry以挑戰慣性思維和打破書本上理論的敏捷和現實世界的方法間的平衡而為大家所熟知。Terry致力於遵循精益原則來實現敏捷。

感謝侯伯薇對本文的審校。