如今敏捷開發已經成為初創企業的標配，如果運用得當，它能大幅提升企業的創新效率。然而在人數眾多、層級複雜的大企業，敏捷開發能實現麼？

誰說只有小企業才能敏捷開發？這5招讓大象也能跳舞
【2016-06-01 BCG波士頓諮詢】

導讀

許多行業的企業都在努力向敏捷開發（Agile）過渡，它是一種不斷更迭的快速軟體開發方法。很多企業看上去都像在運用敏捷開發，但大多數只停留在表面或形式中，比如他們都擁有色彩明朗的會議室，每天都要召開站立會議——但這些並沒有為公司帶來實質性的影響。

敏捷開發常用於初創的軟體公司，開發團隊是整個企業的核心，目標認同、堅持不懈的努力和協作也因此應運而生。但是，對於已經形成管理層級的大企業來說，接納一個獨立自主的跨職能敏捷團隊並不是那麼容易。

不過，有一部分大企業已經找到了使用敏捷的正確方法。他們並沒有拘泥於具體的措施，而是充分領悟了敏捷的基本原則，尤其注重將敏捷團隊融入整個企業組織當中。

企業一旦真正掌握了敏捷的精髓，將獲得驚人的回報。生產力可以提升至過去的三倍。據定量調查的測評結果顯示，員工參與度也有質的提高。此外，新的產品效能只需幾周或者幾個月就可以釋出，而無需花費數個季度甚至年度。創新率提升，產品缺陷和返工的情況減少。採用敏捷開發的第一年，一家銀行的開發團隊將每花費一美元所產生的價值增加了50%，同時研發時間減半，員工參與度增加了三分之一。

為什麼用敏捷開發？

傳統軟體開發的弊病催生了敏捷原則。過去，軟體開發一般都是按順序進行，瀑布式開發（waterfall serving）是其寫照。構思、設計、編碼、測試、運營、維護都歸獨立的小組負責，每個小組要等上游小組完成工作後才能開工。這種思路比較低效。很多情況下，員工將大量的時間用於參加會議和克服部門間的障礙完成工作交接，而不是編寫或測試程式碼。根據經常被援引的《混亂報告》（The Chaos Report），只有不到10%的大規模軟體開發專案能夠按時完成任務且不超預算。

瀑布式理念源於工程學。但是，編寫不同型別的軟體和造橋可不是一回事。河流不會突然改道，可軟體使用者卻經常改變，而且需求不可預測。因此，敏捷依靠的是整合眾多不同的觀點以及支援軟體開發者和企業管理人員之間反覆溝通。

敏捷衍生出許多形式，但最核心的還是一套理念：迭代、實證、跨職能、專注和持續完善。

• 迭代。敏捷的基礎是不斷更迭，直到做對為止。短時間的更迭意味著團隊可以迅速改變方向並且做出反應。發展是可見並且可以預測的，因為是短期衝刺的結果。移交的風險也大大降低。
• 實證。敏捷團隊不怎麼依賴於瀑布式理念常見的規劃、估測和假設，而是更看重A/B測試和其他來自於終端使用者的實時度量標準。衝刺的好處之一是可以快速給出實證反饋，令團隊可以自我修正。敏捷團隊也會測量並密切跟蹤自身的活動。
• 跨職能。敏捷團隊的成員來自各相關部門，比如交易、營銷、開發，在一些行業還會有風險管理部門，來自不同部門的團隊成員密切合作，目的是為了能經常從企業管理者和消費者那裡獲得一手反饋。團隊裡每一個人都有明確的分工和責任。
• 專注。敏捷團隊要完全負起責任。他們不會同時接好幾個專案。也不會在盡責後迅速離開這個專案。在永續性上，他們會產生一種責任感。
• 持續完善。敏捷軟體開發是一個持續的工作過程，為了滿足客戶的需求會不斷更新和試驗。

在大企業，要想將敏捷的這套理念付諸於實踐不是一件易事，因為大企業內部層級較多，比如人力資源、財務和法律部門。企業不要將敏捷視為一種全新的工作形式，而是要將其核心價值理念與現有的軟體開發部門以及企業文化融為一體，必要時可做適當調整。有幾個最佳的實踐方法能夠幫助大企業啟用敏捷的理念體系。這些方法——充分融合了迭代、實證、跨職能、專注和持續完善的特性——符合大企業的現實情況，同時遵循了敏捷的根本原則。

• 迭代。敏捷團隊在固定的時間內完成大量可控的工作，同時創造一個模板。基於對模板的反饋，團隊繼續開始新一輪任務。大企業的技術環境可能無法滿足團隊在兩週時間內完成衝刺的要求，因此許多企業會把衝刺週期延長為四到六週。
• 實證。測試是敏捷模式的基石，可以確保軟體的高質量以及開發活動的高效。大企業，特別是那些初次接觸敏捷的企業可能沒有對測試工具進行大力投入。但是，他們開始為這部分投資建立商業案例時，可以酌情放棄一部分真正的敏捷企業要執行的嚴格測試。
• 跨職能。理想情況下，團隊不應該違反“披薩盒規定”——團隊人數應控制在每個人都能分得一塊披薩。這是為了限制人數，團隊需要的是具備關鍵和互補技能的人才，這樣才能順利完成工作任務。但是，這個規定也可能會讓大企業無法把所有需要的專家囊括到一個團隊裡。因此，這條規定可能會放寬，讓所有實際做貢獻的成員——兼職人員不算在內——都能加入團隊。
• 專注。正常執行的敏捷團隊最重要的一個元素就是“產品負責人”，作為唯一的管理者，產品負責人有權決定範圍、時機、預算分配和產品特性。在純敏捷形式中，負責人需要諮詢指導小組或者管控委員會。但是在大企業中，這部分管理職責可能由兩到三位高管負責，比如一位產品經理、一位商業分析師或專家、可能還有一位“產品主管”。
• 持續完善。敏捷團隊依靠的是回顧、消除障礙和迭代，通過調整和協調工作環境及方法，繼續發掘機遇提高生產力。堅信軟體開發是一項持續（而非固定）進行，沒有終點的工作，這份認同感比具體操作方法更重要。

五個祕訣幫助大企業向敏捷轉變

從頂層開始

改革離不開企業頂層領導者的支援。高層管理者需要積極參與基礎決策，這些決策事關向敏捷轉變的企業目標以及可能阻礙成功的文化障礙和思維定式。沒有這份決心，原有資金分配、人力資源和資產管理等方法將導致企業追求敏捷的計劃一敗塗地。這就是為什麼企業領導者——而不只是技術人員——必須要負起責任。

敏捷不同於其他轉變：領導者必須調動管理層向一個完全不熟悉的新方向前進。敏捷的快節奏和跨職能特色會把許多高管推出安樂窩。沒有頂層領導者強有力的穩定支援，許多高管和團隊將退回原位。歐洲一家大銀行的CEO告訴我們，他想讓自己的企業像提供金融服務產品的科技公司一樣運轉。

要想飛，你需要試點

在大企業中，敏捷試點專案十分有必要，因為需要通過試點才能決定敏捷是否奏效，企業能否接受敏捷理念。在企業為適應敏捷做出必要調整時，試點發揮了關鍵作用。

例如，在開發過程中，產品負責人需要管理開發者和消費者之間的關係和互動。這個角色既要懂技術又要懂業務。企業裡可能需要兩到三個人一起擔任這個角色，直到培養出具備多種能力的複合型人才為止。

同樣，要在一切情況下都充分進行迭代開發可能比較困難，但開發者和企業管理層之間頻繁的互動和反饋應該成為常態。

通過培養相應的能力，分期開展的數輪行動可以幫助企業創造動力並確保敏捷原則和文化已經滲入企業的方方面面。

管理臨界點

試點階段結束後，下一個階段需要更精細地操作來避免不必要的矛盾：企業雖然口頭上願意採納敏捷，但實際操作起來依舊充滿挑戰。

人力資源的那一套方法，如績效管理或許不適用於管理重在衝刺的跨職能團隊，因為團隊裡面的個體不是最重要的，團隊打拼的結果才是。即便最終的整體開銷比傳統的方案小，敏捷的靈活性也肯定會給預算帶來壓力。因為所需的準備時間長，企業可能還沒有建好相應的IT基礎設施來滿足持續的整合和部署。而且，傳統的開發團隊會心懷怨恨，一部分活動會被外包出去，導致員工失去工作。

這些技術和組織層面的擔憂都是現實存在，而且靠自己的力量無法解決。高層管理者們必須積極促進整合，企業幾乎必然要在培訓和開發上進行投資，以鼓勵正確的文化和行為。

在企業內部推行敏捷有幾個成功的方法。其中有一個極端的例子，媒體音樂流服務提供商Spotify為推動敏捷轉型，從根本上改變了自己的組織結構。該公司的產品傳送組織包括分隊（squad）、部落（tribe）、分部（chapter）和公會（guild）。最基本的單位是分隊——由產品負責人領導的多元化團隊，為共同的目標奮鬥。部落由多個相關的分隊組成。分部則由多支人馬組成，這些人來自不同的分隊，但擁有相似的知識和經驗，他們形成了直線組織。公會則是面向所有人的興趣小組，只要感興趣就可以加入。（見下圖）其他企業則只是簡單地在原有的等級結構中覆蓋跨職能的小組。

只衡量對的東西

敏捷的最終目的是促進業務發展。因此，終極的衡量標準應該與企業的業績相關。如果銀行的敏捷專案目標是降低信用卡申請的撤銷率，那麼撤銷率就應該是最重要的指標。但是為了促進業務發展，企業還需要跟蹤軟體可靠性、安全性、複雜性和規模。

於是，軟體衡量工具登場了。企業可以用這些工具來實際驗證敏捷的生產力和質量提升效果，以及Aigle團隊的整體表現。

永不停止

敏捷是一個不斷提高的活動。這不是一次性的行為。敏捷需要不斷監測和調整，才能確保正常執行。企業需要將敏捷原則融於組織。有許多方法能夠令敏捷保持下去。比如，許多企業打造起一個由敏捷專案負責人組成的團隊，可以分享彼此的最佳實踐經驗。

敏捷的本質是創造正確的氛圍，讓你的員工——特別是開發人員——能夠全力以赴。人們通常認為敏捷只適用於編寫軟體，但它最終可以成為改善企業運營，推動企業不斷髮展的有力工具。

轉自，“即刻”APP，文章來源於微信公眾號“BCG波士頓諮詢”2016-06-01推文。原標題：