正在「部署敏捷」的你是不是「真敏捷」？

至頂網軟體頻道消息：時至今天，相信大家都已經聽說過「敏捷」這個詞。許多公司甚至很可能已有專門的敏捷團隊。大多數軟體驅動的公司希望通過從事敏捷(doing agile)開發來協助解決重大的業務和組織結構問題：諸如各種未兌現的承諾、不盡如人意的質量、缺乏可視性、成本過高、協作性差，以及創新進度緩慢等等。但很可惜，有許多公司發現他們並沒有從敏捷投資中得到預期的結果。事實上，「部署敏捷」，尤其是在團隊層面，與「變敏捷」即成為一個敏捷企業完全是兩回事。坦白來講，僅僅部署敏捷並沒有多少實際價值。

其實這並非敏捷團隊的錯。公司戰略與執行不一致，導致團隊成果與預期南轅北轍是見慣不怪的事情。這些公司一般在組織架構中存在巨大的「脫節」。那些知道如何彌補這一脫節的公司可以確保正確的投資，並以正確的方式組建。但更重要的是，他們可以定期以較低成本改變正在創建的產品，以緊跟市場需求，在開發過程中創造最大價值。這是在規模上實現精益／敏捷對於打造真正的敏捷企業的保證。但要如何實現呢？

對Scrum的迷惘

在提供企業諮詢時，我通常會提出以下三個問題：1)你的團隊結構怎樣？2)團隊的工作流程怎樣？3)你會怎樣計劃？ 典型答案都會關注團隊數量、角色、技術、流程、估算故事價值、sprints長度等等。我們總能改善團隊層面的行為準則，但那又如何？每家公司都可以有Scrum團隊，但絕對不可以迷信Scrum框架會解決公司所面臨的重大問題。事實上，如果你所做的一切只是依賴這些單獨的Scrum團隊，其結果可能比瀑布開發模式更糟糕。

讓我們潛心思考一下。如果你的敏捷團隊的成員認為用瀑布開發模式更好，其中可能的原因就是：在瀑布模式中，當我們對工作所知甚少時，我們會預先作出決策。經驗告訴我們項目將會推遲且超出預算，但我們會知道構建的內容，因為範圍是固定的。與之相比，被稱為「自然法則下的Scrum」(Feral Scrum) 的優化團隊能夠快速交付軟體，而他們則只在Scrum模式下埋頭做著自己的工作。有時，他們與組織的唯一聯繫就是唯一一個跟其他模式共享的產品負責人。他們投入許多資源進行開發，但我們不知道他們要交付的產品是否就是我們目前真正所需要的。

首要問題

我們先不談出色的團隊執行未能解決我們的業務問題，讓我們來看一下如何計劃工作和安排人員。這時候，我們就要談到項目章程、業務案例、資金和資源審批。我們會討論他們計劃的頻率、參與人員以及需要花費的時間和精力。

一位客戶曾告訴我他們的年度計劃批准了商業智能團隊的71個項目，並且該71個項目目前全部仍處於活躍狀態，「因為管理者需要看到整個系統進展」。其中有一半的項目是從上一年度順延下來的。更致命的是，他們告訴我預期今年內不會有一個項目能夠完工！

通過實施看板方案，我們能夠解決這個進行中的工作問題。按照對業務的價值劃分項目優先等級，列出項目必須完成的步驟，以及限制「正在進行中」的工作量。只有在當前的工作完成後，團隊才能接新的工作。一轉眼，項目交付變成可預測了，我們只構建最具有業務價值的部分。我們已經解決了我們的問題，對嗎？答案當然是否定的。

成為敏捷企業

市場每天千變萬化，新的客戶需求層出不窮。一家公司的生存有賴於能夠定期、以較低的成本改變項目組合，以緊追新的業務變化。想要縮短企業選擇最佳方案的時間，並不斷交付予客戶，我們就需要解決戰略與團隊工作之間的脫節問題。

答案就是如何細分舉措，讓團隊與不斷變化的優先重點保持一致、自動化進度報告和選擇能夠推動持續改善的指標。其中的核心就在於季度小組計劃活動Big Room Planning，它讓團隊和領導共同構建每個人可以交付的共享、可實現的發布計劃。由現在開始，每個團隊的工作與戰略變化將會保持一致，Scrum團隊可以「查看」以了解他們正在建模背後依據的基本原理，以及他們的工作如何推動公司戰略的實施。但是，我們還需要具備另外一個條件。

培養企業的敏捷文化

一個敏捷企業必須深諳只有將戰略、能力及文化結合起來，才能實現真正的機構轉變。文化產生於人們的互動方式，因此我們尋求能夠促進不斷學習和改進的互動，而回顧和良好的績效指標能派上用場。

最後，我們不應只是「做敏捷」，更應真正「變敏捷」(being Agile)。我們已具備所有解決重大問題所需的一切條件：包括出色的團隊執行、按價值劃分的優先等級、從戰略到執行的連接，以及滿足我們協調、溝通和改進文化需要的平台。我們應專註於為客戶創優增值，而非只是創建過程。我們已經彌補組織中的缺口，現在我們可以積極引導我們的公司響應市場變化，真正成為一個敏捷企業。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！