你真的瞭解Scrum嗎？一文總結敏捷管理Scrum

去年11月份進入了一個專案組，這是一個IT開發專案組，發現不少問題：

大家對於專案管理沒有概念，工作經常拖延，有個專案已經拖了一年都沒有交付。

專案的需求經常變動，導致最後做出來的產品使用者不滿意。

員工沒有緊張感，來一天就做一天工作，反正交不交付不關我的事，大家比較懶散。

進入專案以後，就想著從專案管理角度對於團隊進行改造，針對需求變動大，我們決定採用敏捷專案管理，使用scrum框架來管理專案。

傳統專案管理

1）什麼是專案管理

專案管理是專案活動中運用專門的知識、技能、工具和方法，使專案能夠在有限資源限定條件下，實現或超過設定的需求和期望的過程。

2）瀑布式開發模式

瀑布模型式是最典型的預見性的方法，嚴格遵循預先計劃的需求、分析、設計、編碼、測試的步驟順序進行。

這種模式適合於需求明確，文件規範，這樣一步一步走下來，能夠很好地完成任務。

但是我們的專案特點就是需求變化大，這樣不停做，等到最後發現不滿足需求，已經來不及了，於是我們需要轉向敏捷專案管理。

敏捷專案管理

敏捷開發是一種以人為核心、迭代、循序漸進的開發方法，在敏捷開發中，專案的構建被切分成多個子專案，各個子專案的成果都經過測試，具備整合和可執行的特徵。

敏捷專案管理簡化了繁瑣的流程和文件管理，主張團隊內部的面對面溝通和交流。以 Scrum 為代表，簡單、持續整合、不斷交付、價值優先、擁抱變化的原則在面對時刻變化的市場經濟和不斷髮展的技術時變得十分友好。

1）敏捷宣言

2001年2月11日到13日，17位軟體開發領域的領軍人物聚集在美國猶他州的滑雪勝地雪鳥（Snowbird）雪場。經過兩天的討論，“敏捷”（Agile）這個詞為全體聚會者所接受，用以概括一套全新的軟體開發價值觀。

這套價值觀，透過一份簡明扼要的《敏捷宣言》，傳遞給世界，宣告了敏捷開發運動的開始

第一，個體與互動高於流程和工具

流程和工具雖然重要，特別是在大公司裡面，看得特別重，但是他們無法代替有能力的個體已經他們之間的互動產生的能量。

敏捷團隊作為一個整體，他們的目標是快速完成專案，這個時候要發揮每個成員的主觀能動性。

在工作中，大家一起工作，包括產品、開發、測試、在面對面的溝通交流中建立互信，共同完成每個任務。

第二，工作的軟體高於詳盡的文件

能夠工作的軟體比起漂亮的文件更加重要，在敏捷中，小步快跑，不斷迭代，釋出成果，而不是糾結於完美的設計，詳盡的文件。

當然了，也不是完全沒有文件，架構設計，原型、互動設計，這些都是必要的文件。

第三，客戶合作高於合同談判

在我們開發過程中，不斷變化的需求不能體現到合同上，而與客戶的合作，產出符合客戶的需求的成果更為重要。

建立可行的合作框架，而不是糾結於一點一點的談判，這樣更有利於與客戶建立完善的關係，同時把事情做得更好。

第四，響應變化高於遵循計劃

響應變化就是歡迎需求變化，適應客戶的需求，在與客戶的合作過程中，不斷確認需求，不斷改變計劃成為了計劃的一部分。

總體的規劃是有的，但是敏捷就是根據需求改變來調整計劃，透過一個個迭代，得到使用者的成果，同時完成總體規劃。

2) 敏捷十二大原則

我們遵循以下選擇：

第一，我們最重要的目標，是透過及早和持續不斷地交付有價值的軟體使客戶滿意。

第二，欣然面對需求變化，即使在開發後期也一樣。為了客戶的競爭優勢，敏捷過程掌控變化。

第三，經常地交付可工作的軟體，相隔幾星期或一兩個月，傾向於採取較短的週期。

第四，業務人員和開發人員必須相互合作，專案中的每一天都不例外。

第五，激發個體的鬥志，以他們為核心搭建專案。提供所需的環境和支援，輔以信任，從而達成目標。

第六，不論團隊內外，傳遞資訊效果最好效率也最高的方式是面對面的交談。

第七，可工作的軟體是進度的首要度量標準。

第八，敏捷過程倡導可持續開發。責任人、開發人員和使用者要能夠共同維持其步調穩定延續。

第九，堅持不懈地追求技術卓越和良好設計，敏捷能力由此增強。

第十，以簡潔為本，它是極力減少不必要工作量的藝術。

第十一，最好的架構、需求和設計出自自組織團隊。

第十二，團隊定期地反思如何能提高成效，並依此調整自身的行為表現。

3) 敏捷的優點

第一，擁抱變化，敏捷開發高適應性，更加靈活。

第二，充分利用開發的個人優勢，調動開發者的工作熱情，增加產出

第三，管理需求的優先順序，更好地響應客戶需求

第四，改進專案的可見性，最小化風險（短的迭代），快速應對市場

第五，以人為本，改進團隊精神

第六，簡化開發流程，增強軟體質量

4）敏捷的挑戰

第一，由於專案週期長，不能保證人員不更換，沒有文件會造成交接的困難

第二，強烈依賴開發者主動性，對於人員要求更高，否則容易遇到瓶頸

第三，當有多個利益相關者（stakeholder）時難以設定優先順序

敏捷管理有很多不同的方式，極限程式設計、Scrum、DSDM、自適應軟體開發、水晶系列、特徵驅動開發、實效程式設計。下面要介紹的是Scrum。

Scrum管理方法

1） Scrum定義

Scrum的英文意思是橄欖球運動的一個專業術語，表示“爭球”的動作；把一個開發流程的名字取名為Scrum，我想你一定能想象出你的開發團隊在開發一個專案時，大家像打橄欖球一樣迅速、富有戰鬥激情、人人你爭我搶地完成它，你一定會感到非常興奮的。

那什麼是Scrum呢？Ken Schwaber and Jeff Sutherland在《Scrum指南》中，對於Scrum是這麼定義的：Scrum 是一個輕量的框架，它透過提供針對複雜問題的自適應解決方案來幫助人們、團隊和組織創造價值。

Scrum 基於經驗主義和精益思維。經驗主義主張知識源自實際經驗以及根據當前觀察到的事物作出的判斷所獲得。精益思維減少浪費，專注於根本。

Scrum 的成功應用取決於人們變得更加精通踐行並內化 5 項價值觀：承諾，專注，開放，尊重和勇氣

2）scrum團隊

第一，產品負責人（Product Owner）從業務角度驅動專案，傳播產品的明確願景，並定義其主要特性。Product Owner 的主要職責是確保團隊只開發對於組織最重要的 Backlog 條目，在 Iteration 中幫助團隊完成自己的工作，不干擾團隊成員，並迅速提供團隊需要的所有資訊

第二，流程管理員（Scrum Master）保護團隊不受外界干擾，是團隊的領導和推進者，負責提升 Scrum 團隊的工作效率，控制 Scrum 中的“檢視和適應”週期過程。與 Product Owner 一起將投資產出最大化，他確保所有的利益相關者都可以理解敏捷和尊重敏捷的理念。

第三，開發團隊（Scrum Team）主要負責軟體產品在Scrum規定流程下進行開發工作，人數控制在5~10人左右，每個成員可能負責不同的技術方面，但要求每成員必須要有很強的自我管理能力，同時具有一定的表達能力；成員可以採用任何工作方式，只要能達到Sprint的目標。

團隊負責交付產品並對其質量負責，團隊與所有提出產品需求的人一起工作，包括客戶和終端使用者，並共同建立 Product Backlog 。團隊按照大家的共識來建立功能設計、測試 Backlog 條目交付產品。

3）Scrum開發流程

這是Scrum開發總流程

第一，我們首先需要確定一個Product Backlog（產品需求列表），這個是由Product Owner負責的。

Product Owner透過與客戶的溝通，可以得到產品的需求列表，這個列表每一行是一個使用者故事（User story），包含名稱，描述，時間估算，優先順序。如果這個時間大於5，可以成為史詩級故事（epic story）

第二，有了Product Backlog列表，我們需要透過 Sprint Planning Meeting（Sprint計劃會議）再從中挑選出一個Story作為本次迭代完成的目標，這個目標的時間週期是1~4個星期，然後把這個Story進行細化，形成一個Sprint Backlog。

在Spring Backlog還包括技術需求，這個不是由Product Owner來建立，而是由技術經理來建立，這是在完成使用者故事的過程中，需要完成的技術需求，例如升級資料庫，最佳化程式碼等等。

Sprint Backlog是由Scrum Team去完成的，每個成員根據Sprint Backlog再細化成更小的任務（細到每個任務的工作量在2天內能完成）。

第三，Scrum Team完成計劃會議上選出的Sprint Backlog過程中，需要進行 Daily Scrum Meeting（每日站立會議），每次會議控制在15分鐘左右，每個人都必須發言，並且要向所有成員當面彙報你昨天完成了什麼，並且向所有成員承諾你今天要完成什麼，同時遇到不能解決的問題也可以提出，每個人回答完成後，更新系統。

每個人更新完個人完成的任務，這樣Scrum Master可以根據完成的進度來繪製燃盡圖，燃盡圖的橫軸表示整個Iteration 的總時間，縱軸表示 Iteration 中所有的任務，其單位可以是小時，人天等。一般來說，燃盡圖有”Iteration燃盡圖”和”Release燃盡圖”之分。

Iteration燃盡圖可以追蹤迭代的進度，如果燃盡圖一直是上升狀態，或當 Iteration 進行一段時間之後，Iteration 燃盡圖上的Y值仍然與 Iteration 剛開始時相差無幾，就說明這個 Iteration 中的 Story 過多，要拿掉一些 Story 以保證這個 Iteration 能順利完成。如果Iteration 燃盡圖下降得很快，例如 Iteration 剛過半時Y值已經接近0了，則說明這個 Iteration 分配的任務太少，還要多加一些任務進來。在 Iteration 計劃會議上，如果團隊對即將要做的任務理解和認識不充分，就很可能導致這兩種情況的出現。（鍛鍊團隊人員的自我估算時間）

Release 燃盡圖：記錄整個Scurm專案的進度，它的橫軸表示這個專案的所有Iteration，縱軸表示各個Iteration開始前，尚未完成的工作，它的單位可以是個（Story 的數量），人天等。

第四，當所有Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，這時，我們要進行 Sprint Review Meeting（演示會議），也稱為評審會議，產品負責人和客戶都要參加（最好本公司老闆也參加），每一個Scrum Team的成員都要向他們演示自己完成的軟體產品。

在這個會議上，產品負責人和客戶會提出意見，如果是小問題，可以完成修復，否則加入到Product Backlog裡面，在下個迭代會議確認是否加入進來做。

最後，把成果釋出給使用者，這樣使用者可以使用，提供反饋。

第五，最後就是 Sprint Retrospective Meeting（回顧會議），也稱為總結會議，以輪流發言方式進行，每個人都要發言，總結並討論改進的地方，放入下一輪Sprint的產品需求中；