Scrum作為敏捷的落地方法之一，用不斷迭代的框架方法來管理複雜產品的開發，成為當前最火的敏捷管理方法。
項目成員會以1-2周的迭代周期（我們稱之為sprint）不斷產出新版本軟體，而在每次迭代完成後，項目成員和利益方再次碰頭確認下次迭代的方向和目標。
Scrum有一套其獨特且固定管理方式，從角色、工件和不同形式的會議三個維度出發，來保證執行過程更高效。
例如，在每次sprints開始前會確立整個過程：迭代規劃、每日站會、迭代演示和回顧。並在sprint期間用可視化工件（看板kanban或燃盡圖burndown）確認進度和收集客戶反饋。
Scrum優勢Scrum從高度規範的框架出發構建了特有的團隊角色和團隊制度，Scrum在框架上有非常的優點可以被借鑑，其中包括：
· 提高透明度和進度可視性：通過每日站會，讓整個團隊相互知道大家在做什麼，是否有遇到問題，是否需要停止某個需求。站會可以很好的幫助項目經理提前知曉項目可能存在的問題或風險，並做好風控。
· 增加團隊協作：沒有項目經理能夠具體告訴Scrum團隊應該在何時做何事。相反，該由Scrum團隊會在每次迭代規劃會議上確認他們每次迭代的內容。Scrum團隊在迭代階段互相合作，了解迭代意義，並在迭代結束後來回顧如何改善協作間出現的問題，增加團隊協作性。
· 擁抱改變：Scrum通過持續溝通和反饋得出客戶故事，並在短時間內的實現產品迭代。因此，Scrum方法相較傳統的瀑布開發更容易作出改變。例如，如果團隊在某一次sprint期間得到新的用戶故事，他們可以在下次迭代規劃會議中提出。
· 節省成本：通過研發和測試最小模型的功能，並和產品經理、Scrum團隊、利益方保持溝通，我們可以儘早發現問題所在並及時作出調整，從而幫助降低開支並提高產品交付質量。
Scrum的缺點
Scrum雖然由很多優點，但並不代表它是完美的。用Scrum來實施敏捷的要求也比較嚴苛，它要求項目經理有豐富的管理經驗，要求Scrum團隊有足夠的交付能力（即準時交付），同時要求整個項目組成員對項目範圍有準確的認識，缺點具體如下：
· 項目範圍蔓延風險：由于敏捷開發沒有具體交付日期，客戶可能會不間斷要求項目組增加新的功能，導致超出項目原本的範圍。
· 對團隊成員要求高：團隊需要事先熟悉Scrum的原則才能更好的去實施。由於Scrum對團隊的角色沒有非常準確的定位，因此最好能有有經驗的成員來做指導。另外每天開站會意味著項目過程中要儘量減少人員流動性。
· Scrum Master可能毀掉一切：Scrum Master與項目經理不同，Scrum Master對團隊沒有權力。他們需要信任他們正在管理的團隊，並且不對團隊做過多的幹涉。如果Scrum Master試圖控制團隊，那麼項目宣告失敗。
· 任務定義不準確帶來的影響：如果項目定義不準確，那麼項目成本和時間就很難估算。另一方面，如果不清楚項目目標，相應的計劃會變得難以執行，衝刺階段也會花更多的時間。
Scrum方法中角色定義
在Scrum中有三個特定的角色。他們是：
· 產品經理：產品經理負責規劃產品，並將研發這種產品的願景傳達給團隊。產品負責人需要整理產品需求清單（backlog），關注市場需求的變化來調整產品需求優先級，確認下次迭代需要交付的功能。與團隊、客戶、利益相關方持續保持溝通和反饋，保證每位項目成員了解項目意義和願景。
· Scrum Master：Scrum Master幫助團隊盡其所能地完成工作。例如：組織會議，處理遇到的障礙和挑戰，與產品經理合作，在下次迭代前準備好backlog，確保團隊遵循Scrum流程。Scrum Master對團隊成員在做的事情沒有權力，但對這一過程擁有權力。例如，Scrum Master不能告訴某人該做什麼，但可以提出新的sprint。
· Scrum團隊：Scrum團隊由五到七名成員組成。與傳統的開發團隊不同，成員們沒有固定角色，比如會由測試人員來做研發。團隊成員間相互幫助、共享成果，旨在完成全部的工作。Scrum團隊需要做好整體規劃，並為每次迭代劃分合適的工作量。
Scrum過程中的步驟
Scrum工作流中一套固定的步驟，其中包括：
· 整理產品需求清單（Product backlog）：產品經理和Scrum團隊進行碰頭，基於用戶故事和需求反饋來確定產品需求的優先級。Backlog並不是代辦事項列表，而是產品的所有功能列表。然後研發團隊在每次迭代階段去完成清單中一部分，最終完成整個項目。
· 確定迭代規劃（Sprint planning）：在每次迭代開始之前，產品經理會在迭代規劃會議上和團隊討論優先級高的功能需求。然後確認有哪些功能將會在下次迭代時完成，並將這些功能從產品需求清單中移至迭代任務清單（Sprint backlog）中。
· 梳理產品需求清單：結束迭代後，產品經理需要和團隊碰頭來確認下次迭代的任務清單。團隊可以利用這個階段剔除相關度低的用戶故事，提出新的用戶故事，再重新評估故事的優先級，或將用戶故事分成更小的任務。這次梳理會議的目的是確保產品需求清單裡的內容足夠詳細，並且和項目目標保持一致。
· 每日站會：每天花15分鐘左右開一次站會，期間團隊每個成員都會討論當前的進度和出現的問題。這個過程有助於團隊保持日常聯繫。
· 迭代演示：在每次迭代結束時，團隊需要向產品經理報告已完成的工作，並做產品現場演示。
· 迭代回顧：在每次迭代結束後，團隊需要開例會總結使用Scrum進行研髮帶來的影響，並探討在下次迭代中是否有能做的更好的地方。
Scrum中使用的工具／工件
除了角色和會議之外，Scrum項目還包括一些工具和工件。例如，團隊使用Scrum板來顯示待辦事項或燃盡圖以顯示出色的工作。最常見的工件和方法有：
· Scrum任務板：我們可以用Scrum任務板使Sprint任務清單形象化。任務板可以用不同的形式來呈現，比較傳統的做法有索引卡，便利貼或白板。Scrum任務板通常分為三列：待辦事項，正在進行中和已完成。團隊需要在整個Sprint過程中不斷更新。例如，如果某人想出新任務，他會寫一張新卡並將其加入到合適的位置。
· 用戶故事：用戶故事是從客戶角度對軟體提出功能的描述。它包括用戶類型細分，他們想要什麼以及他們為什麼需要它。它們遵循相似的結構：作為<用戶類型>，我希望<執行某項任務>以便我能<實現某個目標>。團隊根據這些用戶故事進行研發來滿足用戶需求。
· 燃盡圖（Burndown chart）：豎軸表示迭代任務清單，橫軸表示剩餘時間。剩下工作可以通過不同的點位或其他指標來表示。當事情不按照計劃進行並且影響後續決策時，burndown chart可以在這時給團隊提個醒。
· 大規模Scrum（LeSS）：LeSS框架的規則能幫您在保留Scrum核心原則的前提下，將Scrum規模擴展到數百名開發人員。這些原則直接來源於Scrum，但重點放在不增加額外開銷（如添加更多角色，工件或進程）的情況下進行擴展。
· 時間盒（Timeboxing）：時間盒是團隊為完成目標而規定的時間。提倡到規定時間就停止研發，而非一直研發到目標達成。時間盒迭代通常用於Scrum和極限編程。
· 冰箱（Icebox）：任何沒進入研發階段的用戶故事，我們將其都存儲在冰箱中。
· Scrum vs RUP：雖然Scrum和Rational Unified Process（RUP）都遵循敏捷框架，但RUP更注重對軟體開發範圍，主要裡程碑和具體日期的規定。另外，RUP用到項目生命周期這一概念，在Scrum中同樣適用於每次迭代。
· 精益VS Scrum：Scrum是軟體開發的框架，而精益有助於優化流程。Scrum的主要目標是人員，而精益則集中在這個過程上。他們都被視為敏捷方法，但精益引入了兩個主要概念：消除浪費和改善流程。
如何開始落地Scrum
用Scrum落地實施項目管理就意味著要革新，要改變項目組原來的習慣。作為項目成員，他們需要學習承擔更多責任，當所有項目成員敢於擔保，並且高效完成迭代目標，交付高質量產品，這時就是革新的開始。
首先我們要做的第一步，是定義角色。每個項目必須擁有一位項目經理、一位Scrum Master和Scrum團隊，這時我們可能需要先確認誰來擔任Scrum Master和項目經理，如果這兩個職位已經定好了，接下來我們需要定義他們的工作職責。
文章來源：smartsheet
由明道團隊編譯、整理
您可以點擊【閱讀原文】提交郵箱信息來獲取更多敏捷開發的資料，我們將定期向您郵箱推送相關文章、培訓資料和案例。