敏捷實際是迭代的瀑布模型的變種，這種觀點對嗎？
最近在團隊內做一些敏捷實戰訓練，有人提出了問題，我感覺回答不好，請大家各抒己見。
以下轉自我的個人博客：
首先，理解Scrum時有兩點需要時刻謹記：
1、Scrum只是一個框架，不是具體的方法或流程；
2、Scrum是在保證質量的前提下追求敏捷，絕非為了敏捷而敏捷。
死套書本、不顧質量的開發，都不算敏捷開發，更談不上Scrum。
關於項目負責人（Product Owner），項目負責人是項目的責任人（廢話），這個角色轉成互聯網實際工作中的話大致就是產品經理或項目經理。主要工作是指出要做什麼（劃定範圍），落到實際上就是編寫Backlog中的故事、定義優先順序。（個人感覺有點像簡單的PRD）
關於Scrum Master，這個角色是用來解決項目進行中遇到的問題的。比方說某個成員編程遇到困難，他要處理程序上的問題；某個產品在兩個實現方案中不知如何選擇，他要能立刻指出哪套方案更好好在哪；假如項目推進中其它部門因故要來借人，他需要出面拒絕，如果人家說這是大BOSS的意思，他需要立刻拍案而起和大BOSS討價還價……基本上這個角色不但需要程序、產品、前端、UI、測試樣樣過人，還需要在公司里有地位有資歷。這個這個……大家自行想像吧= =
關於管理。按我的看法，Scrum團隊內其實應當是不存在管理者的，每個成員都是自管理，這對企業和員工提出了比較高的要求，能夠達到的話，本身就能比傳統瀑布式開發尤其是跨部門協作更加敏捷。
按我的理解，Scrum比傳統開發模式能夠敏捷、可控並解決很多問題的最大原因其實不是迭代，也不是項目到故事、故事到任務的拆解，而是從「計劃多久、必須完成」的思路轉換為「周期內能做多少、能做多少就做多少」。我們知道計劃是為了解決散漫無序，一經確定就輕易不得修改，但俗話說計劃趕不上變化。這邊每天飛郵件沒人看，那邊不到時候不著急，這邊需求變更就要部門間扯皮鬥嘴，那邊誰誰老婆生孩子請假其他人就得加班……最後一群人疲憊不堪，產品質量還低下。
如果是Scrum的話，一個迭代周期內按照對故事預估的工作量和重要度來劃定工作範圍，如果做著做著發現比預想的進展要慢，那就把重要度最低的故事從Sprint backlog中剔除；如果做著做著發現比預想的進展要快，那就把原本要放到下一周期中的故事加到這個周期中。根據每天的實際進展情況來隨時調整backlog，保證燃盡圖（Burndown chart）的曲線儘可能接近-45度。這樣做的目的是從實際出發，解決傳統計劃經濟體制下「不切實際」導致的計劃崩潰和計劃對產品的摧毀。
但是backlog無法解決人員散漫、怠工、溝通效率低下等問題，所以有了每日的站立會，每天10到15分鐘（按我感覺5分鐘便已足夠），成員各自說明：1、昨天自己做了什麼。2、今天自己要做什麼。3、自己的工作中遇到哪些問題。每個人只是陳述，不存在你來我往的對談。前兩點解決了大公司病中「大家都不知道對方在做什麼」這個典型問題；最後一點是給Scrum Master的任務，可以解決大公司病中處理問題效率低下的問題。
需要留意的是：為了保證每個人每天都有具體完成的內容可供敘述，所以backlog中故事定義的標準，不是具體的功能，而是工作量。反著說是儘可能保證每個故事的工作量都在2~8個人/日，正著說就是把大的故事拆分、把小的故事合併，標準是工作量在2~8個人/日。工作量雖是粗估（也只能粗估），但為了保證盡量靠譜，Scrum推薦的是翻牌法。如果每個成員都很靠譜，對需求也都很明確，不翻牌也無所謂，但要翻牌就認真翻，別做樣子，這上面花的時間多點不怕。
這樣做的真正好處，按我猜其實就是目標分解法（關鍵詞「山田本一」）。因為如果團隊中的每個人都做到了自管理，那麼散漫怠工等情況並不會出現。通過故事的拆解合併，保證每一兩天都有可供演示的功能，那麼每個小目標演示成功後的喜悅就能夠緩解大目標一眼望不到頭所帶來的疲勞，讓成員始終保持精力充沛。
最後就是最靠譜的迭代了，為了解決溝通低下的問題，公司最低限度也最重要的其實是……調整工位，讓項目成員坐在一起（如果這個都做不到那這個形式高於做事的公司還是別妄談敏捷了），由於每天做的都是具體的故事（故事到任務的拆解完全屬於RD自己的事），內容和目標清晰可見，因此最需要的是隨時、即時溝通，這個只有face to face才行，郵件、OA、IM都是扯淡，是扯淡。
敏捷開發中，可供演示的版本比精美的文檔重要，而文檔要不要寫，其實不在PM，而在研發。貌似每個產品都有過「文檔粗糙，技術打回；文檔精細，技術不看」的囧經歷。這個其實也怪不得技術，粗糙的文檔倒是方便看，但語焉不詳模稜兩可，根本沒法用；精細的文檔倒是面面俱到，但一眼望去文字表格一大坨，動輒幾萬字，換誰也懶得看。所以怎麼寫文檔、要不要寫文檔，全看技術一句話，要是所有成員一床上沒隔閡，什麼都省了。
首先，我本人不關心任何關於理論，口號，和什麼模型，變種之類的討論，我覺得任何能解決實際問題的方法都是好方法，任何能幫助團隊，個人成長的方法論都是值得借鑒的。敏捷是什麼的變種的討論本身就沒有意義。既然李強問道這個問題，我簡單說一下個人觀點。
任何方法，方法論都是從其他的方法上演繹出來的，包括敏捷在內。敏捷中的很多實踐，例如站立會議是從機械加工，零售業借鑒的；故事牆是從機械加工工業，物流行業引入的。
如果是把瀑布式模型和迭代開發相結合就能算作敏捷，這是不正確的。
一個敏捷團隊特點有：有能力快速驗證，價值驅動的做事，團隊自組織，項目持續完善。
這些特點和迭代，瀑布沒有直接的邏輯關係。不對，但是這個問題很現實。
在敏捷中很重要的一個概念是在每一個迭代結束以後，有可交付的產品。
關鍵字：可交付
小瀑布或者迭代瀑布，嚴格來說就是階段性完成工作，這和每個迭代都有可交付產品的概念是不一樣的。
舉個例子，敏捷培訓中常用餐飲的打比方：
小瀑布是：第一個小時準備油鹽醬醋，第二個小時準備材料，第三個小時開始燒菜；敏捷是：第一個小時炒幾份，第二個小時炒幾份，第三個小時炒幾份；當然這樣很多人會說那敏捷裡頭你前兩個迭代不也是沒有做完菜么。
對，這又涉及到比較現實的問題，如何設計Backlog和定義DoD。
我的經驗是，如果你的DoD設定每次都完成不了，Backlog總是變化，一直沒法交付，那就是掉瀑布裡頭去了，即使有迭代的樣子，也不是敏捷。AGILE對團隊最大的挑戰並不是結構和方法, 一個scrum流程, 大部分人兩天就可以完全掌握,但是很少見到能在半年內做到真正Agile的團隊, 這個磨合周期會長達一年甚至無法真正實現, Agile的核心在於commitment 和autonomy, 對team member和scrum master, PO都是一個巨大的挑戰, 尤其對於適應了中國傳統管理文化的團隊更是如此.至於前面的問題,那是根本上的錯誤, 等同於換湯不換藥, 一個sprint做個小項目,如果抱著這樣的觀點去搞Agile,那根本不是Agile.
推薦閱讀：