一張圖讓你看懂敏捷 Scrum
敏捷，簡單的釋義，即靈敏、快捷。
「合理的任務規劃」能讓團隊的工作即飽和而又能夠有良好的應變能力（靈敏），團隊需要時刻保持著良好的應變能力，因為我所瞭解的開發團隊一直都面對著一個不確定因素——需求變化快。
「專注」能夠有效提升效率（快捷），當人在多件事情之間來回切換的時候，效率就會顯得低下而且心情還很容易變得糟糕。
接下來將帶給你如何使用敏捷的工具之一 Scrum 幫助你完成「合理的任務規劃」和如何「專注」。
一張圖看懂 Scrum
Scrum 工具包括：3個角色、3個工件、5個活動和5個價值觀。
3個角色
01 Product Owner：
職責：
:radio_button:清楚知道產品的願景，分為近期和遠期。
清楚願景才不至於被幹擾帶偏道路，才可以清楚的區分重要緊急、重要不緊急、不重要緊急、不重要不緊急事件。我們可以集中精力於重要不緊急事件，這樣就能減少重要緊急事件的發生。
:radio_button:獲取外界的訴求並進行整理成 User Story。
外界：使用者、運營部門、其他業務方
User Story：需要實現的功能，以客戶的角度，描述「我需要功能A，來達到我的什麼目的」。
:radio_button:對整理好的 User Story 所需要的資源進行各方協調並得出「是否可行、什麼時候可行」的結論。
一個功能的實現，有時候牽涉各個業務系統，往往各個業務系統所對應的Team排期是不一樣的，就需要提前進行溝通。盡最大努力避免在開發的過程中才發現問題，這時候才和其他業務系統溝通影響面就很大，其他業務系統人員很可能拒絕進行協助，業務緊急強行協助導致會打亂了其他團隊的開發計劃。
:radio_button:根據產品的近期目標，對 User Story 進行優先順序排序；期間有更好的 Idea 需要對 User Story 優化，這是一個持續的過程。
注意：Story 的優先順序只能有一個1，一個2…一個10。不要把這些功能放得同等重要，這期都得全部實現，全部都是1，這樣的做法就失去了優先順序的意義。仔細的思考，斟酌，比如問自己「少了這個功能會有什麼影響——公司會因此損失100萬嗎？公司會倒嗎？」，有時候並沒有想的那麼緊急，只是先入為主的思想陷入了局限的泥潭失去了大局觀。最後一定是能夠得出一個唯一序列的優先順序排序的。
:radio_button:需求從外界到 PO 手裡的時候，不應該一味地緊縮一線開發人員的時間。PO 的責任不能僅僅是滿足外界的訴求，還應該考慮 Team 人員的工作狀態和情緒，他們可是實現你「藍圖」的一線人員。（公司所有人都致力於目前公司的藍圖，PO 正是在推動著這張大藍圖中的某個模組。）因此 PO 應該全面考慮團隊的目前狀態，有時督促團隊全速前進，有時應該是 Team 的保護傘，這些都是為了實現公司藍圖更好、更快的前行。
:radio_button:初步決定 Team 每個 Sprint 要完成哪些 Story 任務。
這裡只能是初步決定，精確的結果需要在下面的 Plan Metting 中 Team 對其進行時間評估，最後根據該個 Sprint 的任務飽和度，進行 Story 的裁剪或增加。有許多情況並非如此，「這個 Sprint 整理的所有的需求都要實現」，沒有考慮過公司現在 Team 所配備的資源情況和完成能力才會有這樣的決定，這也往往導致了產品——開發之間的諸多矛盾。心理活動，產品：「這麼簡單的功能都完成不了」，開發：「你行你來呀」。諸多時候我們以 5000 多年以來的人文素養平息了這場風波，妥協的結果就是質量堪憂甚至完不成任務。
:radio_button:在一個 Sprint 開始後結束前，如果有緊急需求進入，需要站出來保護團隊，因為往往很多需求都是認為很緊急而已。
儘量避免 Team 受外界影響，這時候插入緊急需要往往會打亂開發節奏，從而引發各種問題和風險。這個「緊急」需求，如果經過討論和仔細分析後，大家得出的結論還是是緊急並重要的話，那麼這個需求形成的 Story 就需要插入此次 Sprint，優先順序列表在這個時候就起作用了，可以在此次 Sprint 的優先順序列表中移除一些低優先順序 Story。
02 Scrum Master：
職責：
:radio_button:協助 Product Owner 整理需求。
開發是最熟悉每個業務流程以及可能的牽涉方的，要完成列表中的 Story，需要協調哪些資源，以及協助評估現在的資源能否順利完成這些 Story。
:radio_button:作為 Scrum Team 的帶頭人，需要確保團隊的合理運作，清除 Sprint 開發中的障礙，引導 Team 高效的完成每日工作。
:radio_button:組織團隊工作，sprint planning meeting、daily standupo meeting、sprint review、retrospective meeting 組織各項會議的開展（該四個會議在5個活動中會詳細介紹）。
:radio_button:幫助大家接收敏捷的理念，推動團隊按照敏捷價值觀和原則所倡導的方法做出決策。
不要過高估團隊的適應能力，當然也不要過低評估團隊的適應能力。推行敏捷定是一個長期的過程，Team 人員有著不同的工作經歷，不同的公司不同的文化背景，以及現在公司的企業文化影響，推行一套理念都需要專注於明確的目標（Focus）、反饋（Feedback）、糾正（Fix）——簡稱為3F原則，然後依此迴圈，長期的反覆的過程。
:radio_button:儘量保證團隊在每個Sprint中不被打擾。
如果發現有發現影響團隊工作的任務來臨，要敢於說「NO」，如果確實是重要緊急的需求，而該 Sprint 工作量已經飽和情況，就有必要協商移除之前優先順序最低開始的User Story，以保證工作的順利進行。
03 Team：
職責：
:radio_button:學習和使用敏捷的理念，反饋工作或流程中存在的問題，甚至提出解決方案。
:radio_button:積極去推動任務的進展，提高自我執行力。
:radio_button:高效的溝通，儘量避免通過第三方傳達的溝通方式。
:radio_button:高質量的完成 Sprint 開發需求，按期交付。
3個工作
01 Product Backlog：
指有優先順序的產品待辦事項列表。Product Owner 收集來自於各方的需要、期望、訴求等等，並整理成 User Story 表達形式到產品待辦列表中，評定優先順序。
02 Sprint Backlog：
每個 Sprint 的任務開發列表 。
03 Burndown chart：
燃盡圖，能夠直觀的看到在每個 Sprint 剩餘工作時間和任務完成情況，有效的把控 Sprint 功能交付的風險。
5個活動
01 Sprint：
衝刺（有的公司叫班車，從起點站發車，到一站後需求完成下車，新需求上車，迭代的過程以此往復），一個固定的時間週期（通常為2w~4w，新專案可以是1w）。
02 Sprint planning meeting:
通過會議得出的本輪迭代任務。Sprint 開始的時候，Product Owner 、 Scrum Master 和 Team 根據團隊的資源和能力，從 Product Backlog 中按照優先順序選取這個 Sprint 要做的 User Story，並且對 Team 提出的問題進行解釋和澄清，最終形成本輪的 Sprint Backlog。Team 負責將這些 User Story 拆分成一個個小的 Task，給出完成每個 Task 的時間估算，一般可在 6 小時內完成(6小時一般是一天的高效時間，其他時間可作為 Buffer)，達到可量化。
03 Daily standup meeting:
每日站會，一般選在早上，15分鐘左右。每個人講述進展情況（昨天做了什麼，今天準備做什麼，遇到什麼問題），遇到了 Block 的問題，需要 Scrum Master 出面來掃清障礙保證 Team 能夠專注的完成任務。這樣能夠及時的暴露出開發過程遇到的問題，能夠的有效的評估風險以及及時討論解決方案。通過這樣透明化的披露，可以將個人和他人的工作結合起來，會更好的考慮自己的工作是否會影響別人。通過每個人進展的彙報，整個 Team 隨時可以瞭解到離完成我們的 Sprint 目標還有多遠。
每個人主動在 To do（準備做）一欄中的選取今日要完成的任務放入 InProgress 一欄並且開工，第二天立會繼續按此勾兌，同時將已完成的任務放入 Done（完成）一欄，遇到障礙的任務移入 Blocked。Blocked 項 Scrum Master 會負責跟蹤，和掃除障礙。
04 Sprint review：
在 Sprint 週期結束，需要進行一次評審會議，向 Product Owner 和利益相關方展示完成的功能。回答利益相關者的問題，並記錄期望的更改。評審會議可以讓其他人瞭解團隊在做些什麼，並得到反饋。
05 Retrospective meeting：
回顧會議，通常在 Sprint reivew 會議之後開始。回顧會議是團隊內部針對本次 Sprint 內發生的做的好的進行累積，可以改進的、存在問題的作為 Fix 項， Fix 項作為下一輪Sprint任務，也就是持續累積和改進的過程。將好的吸取，不好的改進，那麼流程就會越來越完善。
5個價值觀
團隊內在的靈魂
01 專注：
只專注於每個 Sprint 要完成的事情，團隊和個人的能力和精力都是有限的，在有限的時間內專注於最有價值的事情，以取得好的結果。
02 勇氣：
團隊完成任務的過程中肯定都會遇到一些棘手問題的情況，要有勇氣去挑戰和麵對。
03 公開：
Sprint 的進展，遇到的問題，阻礙都應該對所有人視覺化，透明的。這樣的團隊才能彼此瞭解，彼此尊重，同時也能暴露問題。
04 承諾：
團隊在 Sprint 開始的時候做出承諾，並在迭代中全力完成，達成功能交付。
05 尊重：
尊重各個團隊以及團隊的人員。不要越界（超出了自己的範疇）議論，「產品覺得這麼簡單的功能還要那麼久才能完成」、「開發覺得 UI 怎麼設計得這麼 Low」、「UI 覺得這麼簡單的效果你們都做不出來」等，我們要相信他人能夠在這個崗位上就有勝任的能力，要相信他的專業能力。
結語
Line"/>
採取高效的溝通方式，除非情非得已，不要由中間人轉接你們各自的訴求，直接溝通，減少交流成本。
Scrum 只是一套工具，實施主要還是看人。其中的流程並非一定完全硬套，工具是死的，實施的人是活的，當然是可以根據公司的情況對某些流程進行調整、替換、甚至刪除，總結一套適合團隊的流程最要緊。最重要的是定下一套流程規則，然後遵守這套規則，迴圈往復的發現問題和解決問題，完善流程。
往往管理更多的是借鑑而非複製，每個公司的文化底蘊以及所處的環境（主要是人員組成）不同，只有因地制宜因材施教才能達到目的。
往期精彩：
