如何看待重型敏捷管理框架？

敏捷的初衷是以人為本，輕量化管理框架，但是現在隨著敏捷逐步實施到複雜的企業環境中，出現了很多重型的敏捷框架，比如DSDM，SAFE。怎麼看待這種重型框架？

咱實話實說，敏捷這一套東西怎麼起源的，是起源於外包項目管理，外包項目你懂的，就是大公司把自己某一部分不重要功能交給外包公司來做，這些業務不會太大，所以，敏捷先天就是做小項目的。

後來，敏捷這一套搞得風生水起，大公司也覺得這套能解決自己的問題，開始在大項目中搞敏捷，大部分搞得還真是照虎畫貓反類犬。

我個人經歷，某超大公司大型產品（就不點名了），開發團隊分布在兩個國家，幾百人，幾十個小團隊，每個小團隊用scrum來運轉，但是整體看這不敏捷啊，所以還要搞一個scrum of scrum，每個小團隊要彙報自己這個scrum的進度，然後總結到一張excel表裡，為了不丟臉，各組當然會把帳做得漂亮，最後總結的excel里每個scrum的burndown chart都很健康，但是最後交付還是要delay半年。

這看起來根本不敏捷。

1. 敏捷宣言於2001年產生，當時是為了應對傳統瀑布模式對複雜場景下多協作開發挑戰的支持欠缺和日益變化迅速的市場環境。以人為本和輕量化只是敏捷方法與瀑布模式相對的一個特質。

2. 為了應對組織級的敏捷轉型，敏捷方法也在持續演進，比如SAFe,今年升到了4.5版本。敏捷方法已經由最開始覆蓋到的團隊級、研發過程，逐漸演進到了組織級、產品/項目的全價值鏈過程。在這個演進過程中，為了應對更複雜的場景，敏捷方法論本身也必然擴展。更加源於實踐使敏捷方法能夠更好的適應需要。

3. 如果說十年前業界還在爭論敏捷是否有價值，那麼現在業界更多地是彼此在問：你們實施敏捷了嗎？

4. 敏捷方法不是萬能的，是否適用需要客觀的分析應對的場景。

最後，歡迎參看我的知乎專欄《精益敏捷與項目管理踐行路》，謝謝。

這個問題還在思考中，先寫著慢慢修改。

敏捷的理念是以人為本，講究的是減少中間環節的浪費。

問題是按照敏捷Scrum那個從管理學來看粗曠無比的模式來，整個世界就剩三個角色了，SM，Develop team，還有PO。

稍微大點的公司架構哪有這麼簡約。市場，銷售，研發，產品，財務，人事，行政。各個職能部門哪個不重要，哪個不需要在實施項目的時候考慮到。問題是Scrum不像傳統的項目管理方法論，比如PMP，Prince2，那樣有一套如何和項目干係人打交道的模式。

所以，敏捷尤其是Scrum，作為一種項目管理的方法，在項目干係人管理方面有天生的缺陷。因為沒有這方面的指南，所以項目干係人滿意度很大程度上依賴於PO的情商。

一些組織實施Scrum失敗，回歸傳統瀑布模型，很大程度上也是在項目干係人方面出了問題，得不到一些核心公司成員的認可。

在某種程度上，通過擴大Scrum的邊界，界定更大範圍內組織成員如何和Scrum team發生聯繫，可以降低缺乏項目干係人管理的風險。

通過引進Program manager（在不同模式中角色的稱呼不同，比如在SAFE裡面就叫做RTE-release train engineer這個爛名字），可以在維護小範圍團隊Scrum的情況下提升大範圍內組織內成員的滿意度。

這就是一些重型敏捷項目管理框架的價值。