本篇參考：

https://trailhead.salesforce.com/content/learn/modules/salesforce-agile-basics

https://www.scrumcn.com/agile/scrum_guide.html

https://www.scrum.org/resources/what-is-scrum

https://www.atlassian.com/software/jira

前幾天剛考完 development and lifecycle，其中有一部分就是敏捷的內容，加上現在專案基本上也基本嚴格遵循著Scrum框架進行專案開發管理，所以順便整理一下基礎知識。這種知識網上一堆，感興趣的可以去官方或者更詳盡的地方檢視，自己只是整理一下，好記性不如爛筆頭，用於自己後期好好的理解理解，自己學習一下。

一. Agile & Scrum 框架

Plan vs. Adapt: 世界上唯一不變的就是變化本身，專案也是，隨著客戶的需求不斷地清晰不斷調整，或者產品專案上線以後使用者反饋不斷的完善，需求和迭代也是不斷的增強和完善。salesforce本身就具備了很多的feature和tool，也特別適合快速原型去構建專案，然後不斷的迭代，所以salesforce的專案，大部分都是基於敏捷的模式來開發。

接下來說 Scrum， Scrum只是實現敏捷模式的一個主流的框架。我們可以先通過英語單詞來認識一下。

橄欖球比賽的特點： 多人合作，技術複雜、戰術多樣，通過運用個人技術的相互配合，以達攻守的目的。引申到專案，專案中也會面臨著需求不清晰，需求變更等複雜的場景，使用傳統開發的模式，敏捷性不夠，無法做到在瞬息萬變的今天達成更好的交付。通過Scrum的框架的好處是在不斷的小的週期中總結分析問題，從而更好的進行迭代和交付。

二. Scrum框架的335

我們官網也好或者隨便百度一下 Scrum的內容，通常都會發現一堆的文章描述 Scrum的原則，價值觀以及335。這裡就只是提一下335，因為實際專案中瞭解好這些確實可以更好的帶入。

3個角色： PO（產品負責人），Scrum Master(敏捷大師)，Dev Team（開發團隊）
3個工件(artifact)： Product Backlog， SprintBacklog， Increment
5個事件：Sprint，Sprint Plan Meeting，Daily Standup Meeting， Review Meeting， Retrospective Meeting（Sprint回顧會議）

1. 三個角色

PO（產品負責人）：產品負責人的職責是將開發團隊開發的產品價值最大化。如何實現這一點的方式會隨著跨織、Scrum 團隊和團隊成員個體的不同而有所不同。
產品負責人是負責管理產品待辦列表的唯一負責人。產品待辦列表的管理包括：

• 清晰地表述產品待辦列表項；
• 對產品待辦列表項進行排序，使其最好地實現目標和使命；
• 優化開發團隊所執行工作的價值；
• 確保產品待辦列表對所有人是可見、透明和清晰的，同時顯示 Scrum 團隊下一步要做的工作；以及確保開發團隊對產品待辦列表項有足夠深的瞭解。

產品負責人可以親自完成上述工作，或者也可以讓開發團隊來完成。然而無論何者，產品負責人是負最終責任的人。
產品負責人是一個人，而不是一個委員會。產品負責人可能會通過產品待辦列表展現一個委員會的期望要求，但是想要改變產品待辦列表項的優先順序都必須經過產品負責人。實際專案中，PO最常見的是甲方的IT負責人或者IT人員。

Dev Team（開發團隊）：開發團隊具有下列特點：

• 他們是自組織的。沒有人（即使是 Scrum Master）有權告訴開發團隊應該如何把產品待辦列表變成潛在可釋出的功能增量；
• 開發團隊是跨職能的團隊，團隊作為一個整體，擁有建立產品增量所需的全部技能；
• Scrum 不認可開發團隊成員的任何頭銜，不管其承擔何種工作（他們都叫開發人員）。

Scrum 不認可開發團隊中所謂的“子團隊”，無論其需要處理的領域是諸如測試、架構、運維或業務分析；同時，開發團隊中的每個成員也許有特長和專注的領域，但是責任屬於整個開發團隊。當然，這些都是理論上的場景，實際場景大家都清楚。

Scrum Master（敏捷大師）： 負責根據 Scrum 指南中的定義來促進和支援 Scrum。Scrum Master 通過幫助每個人理解 Scrum 理論、實踐、規則和價值來做到這一點。Scrum Master 對 Scrum 團隊而言，他/她是一位服務型領導。Scrum Master 幫助 Scrum 團隊之外的人瞭解他/她如何與 Scrum 團隊互動是有益的，通過改變他/她們與 Scrum 團隊的互動方式來最大化 Scrum 團隊所創造的價值。

Scrum Master 以各種方式服務於產品負責人，包括：

• 儘可能確保 Scrum 團隊中的每個人都能理解目標、範圍和產品域；
• 找到有效管理產品待辦列表的技巧；
• 幫助 Scrum 團隊理解為何需要清晰且簡明的產品待辦列表項；
• 理解在經驗主義的環境中的產品規劃；
• 確保產品負責人懂得如何來安排產品待辦列表使其達到最大化價值；
• 理解並實踐敏捷性；以及，按要求或需要引導 Scrum 事件。

Scrum Master 以各種方式服務於開發團隊，包括：

• 在自組織和跨職能方面給予開發團隊指導
• 幫助開發團隊創造高價值的產品；
• 移除開發團隊工作進展中的障礙；
• 按要求或需要引導 Scrum 事件；以及，在 Scrum 還未完全採納和理解的組織環境中指導開發團隊。

Scrum Master 以各種方式服務於組織，包括：

• 帶領並指導組織採納 Scrum；
• 在組織範圍內規劃 Scrum 的實施；
• 幫助員工和干係人理解並實施 Scrum 和經驗產品開發；
• 引發能夠提升 Scrum 團隊生產率的改變；以及，與其他 Scrum Master 一起工作，增加組織中 Scrum 應用的有效性。

理論上 Scrum可以由一個PM擔任或者一個團隊成員擔任，而且 Scrum和PO不能為同一個人，因為PO代表客戶的利益，Scrum用於做各方協調工作。但是實際場景中，可能PO和Scrum作為了同一個人，官方會講述這兩種如果都是一個人是不正確的，但是實際的場景還是要應了開篇的話語： 計劃 VS 適應~~~

2. 三個工件

Product Backlog（產品待辦列表）：產品待辦列表由 Product Owner 負責維護，包括增刪及優先順序,使用者故事是其中一種最佳實踐,每項需求都需要描述其外部價值，是一份涵蓋產品中已知所需每項內容的有序列表，它是產品需求變動的唯一來源。產品負責人負責管理產品待辦列表的內容、可用性和排序。產品待辦列表永遠是不完整的。我們經常在專案中聽到的更加熟悉的名字： user story。產品待辦列表我們可以理解成擁有外部價值的一些 user story的集合。

產品待辦列表精化指的是為產品待辦列表項增添細節、估算和排序的動作。這是一個持續的過程，產品負責人和開發團隊協同工作在產品待辦列表項的細節上。在產品待辦列表精化過程中，產品待辦列表項被重新評審和修改。Scrum 團隊決定如何來完成精化以及何時來完成。

SprintBacklog： 排序越高的產品待辦列表項通常比排序低的更清晰同時包含更多細節。根據更清晰的內容和更詳盡的細節資訊就能做出更為準確的估算；同樣，排序越低，則細節資訊越少。一個專案可能幾個月或者更長時間，我們不可能無序的對產品待辦列表進行開發，而是將這個專案週期按照指定週期切割成多個小週期，每個週期按照優先順序和資源做相關的產品列表裡面的user story，每個sprint所作的product back log即可以理解成 sprint backlog.

Increment（可交付產品增量）:產品待辦列表項中那些即將會佔用開發團隊下一個 Sprint 大部分時間的項會被加以精化，因此，任一產品待辦列表項都能夠在 Sprint 的時間盒期限內適當地“完成”。這些能夠被開發團隊在一個 Sprint 中“完成”的產品待辦列表項稱為 Increment。

3.5個事件

Sprint翻譯成什麼？ 衝刺、 迭代、週期？？？無所謂

Sprint 是 Scrum 的核心，其長度（持續時間）為一個月或更短的限時（按需可以設定1周到4周不等），這段時間內構建一個“完成”、可用的和潛在可釋出的產品增量。在整個開發過程期間，Sprint 的長度保持一致。前一個 Sprint 結束後，新的下一個 Sprint 緊接著立即開始。Sprint 由 Sprint 計劃會議、每日 Scrum 站會、開發工作、Sprint 評審會議和 Sprint 回顧會議構成。每個Sprint都可以作為一個小專案來對待，就如同專案一樣，Sprint 被用於完成某些事情。每個 Sprint 都會有一個要構建什麼的目標，還有一份設計過和靈活的計劃用來指導如何做這些事、工作內容和最終產品增量。之所以將Sprint設定在一個月內，是因為當 Sprint 的長度太長的話，對要構建什麼的定義就有可能會改變，複雜性也有可能會增加，同時風險也有可能會增加。Sprint 通過確保至少每月一次對達成目標的進度進行檢視和適應，來實現可預測性。Sprint 同時也把風險限制在一個月的成本上。

Spring Planning Meeting（Sprint 計劃會議）

Daily Scrum Meeting（每日站會）

SprintReview（每個Sprint結束以後的demo等）

SprintRetrospective（Sprint 回顧會議）

簡易版流程：

1. 已經擁有產品backlog清單
2. 進行SPRINT的計劃會議，根據計劃會議，確定當前的這個 SPRINT的BACKLOG
3. 每日站會，對當前SPRINT的story進行狀態追蹤；
4. SPRINT Review會議時，針對潛在可交付產品增量進行demo
5. Sprint Retrospective會議，對當前sprint遇到的問題以及scrum的改進意見等進行討論和不斷的總結

詳細版

專案啟動以後，BA通過和PO以及 stakeholder不斷的梳理需求以後，梳理 / 重新定義/ 變更 Product Backlog

定義 Sprint週期，比如每兩週一個 Sprint週期，每個Sprint開始會進行 Sprint Planning Meeting，根據優先順序等屬性，來將 Product Backlog內容排期到當前的 Sprint Backlog中，並進行assign以及打分等

Daily Scrum會議上，DEV團隊對各自的story進行進度介紹和更新以及問題暴露，Scrum Master/PO針對block的問題找到相關的suggestion或者配合的部門等來解決問題。

隨著 Sprint的不斷進行，潛在“完成”的產品增量成果物將不斷的產出

Sprint Review會議上，可以對完成的成果物進行demo等。

Sprint Retrospective會議上，對這個 Sprint 中遇到的問題，流程上等問題以及好的地方進行整理總結；

進行下一個Sprint週期，重複上述的操作。

我們可以使用Jira來作為Scrum的管理工具，Jira的kanban也更好的去展示user story的狀態，當然，jira的功能遠遠不止於此，感興趣的可以免費註冊1個月賬號。可以在jira上維護 product backlog以及sprint的sprint backlog，然後通過teams來進行約會議實現上面的幾個scrum事件。

比如，我們進行兩週一次的sprint，每週三的早晨９點進行Sprint Plan Meeting，在Sprint Plan Meeting中，我們將Product Backlog中的內容，按照優先順序以及resource情況進行排期，新增或者刪除當前的 sprint backlog。每天早晨9點也進行daily meeting，每個團隊成員去彙報 sprint backlog的status，以及block內容需要協調等等資訊。針對狀態是完成的user story，我們可以隔一週的每週二的下午3點到5點進行 sprint review meeting，當然，我們也可以將retrospective meeting和review meeting一起開，演示一下demo，並且看一下當前 sprint還有哪些沒有完成以及後續的操作。從而保證風險控制在兩週以內，也可以儘快的tracking整體的專案進展和風險狀態。

三. 針對 lifecycle　scrum常見考題

What is a main characteristic of an agile team?
A. The team uses Scrum, Kanban, and Extreme Programming.
B. The team has biweekly sprints to ensure on-time delivery.
C. The team delivers new releases on dates defined in the beginning of the project, following a
project plan
D. The team improves and evolves its processes and frequently delivers value to the endusers.
Answer: D

分析：　敏捷團隊的特性是改進和發展其流程，可以頻繁的交付有價值內容給終端使用者

Universal Containers (UC) is embarking on a large program of work, with different projects and different vendors. UC created a center of excellence (COE) that is struggling with scope creep between the different projects.
What role should the architect suggest be added to the COE?
A. Scrum master
B. Release managers
C. Product owner
D. Change managers
Answer: A

分析：　可以檢視文中的敏捷大師的用處

總結：篇中很多的內容都是ｃｏｐｙ了參考的連結內容，結合著自己的目前的實際專案管理模式進行了一些的自己看的懂的總結。主要針對後期自己去學習使用。篇中有錯誤地方歡迎指出，有不懂歡迎留言。

作者：zero

部落格地址：http://www.cnblogs.com/zero-zyq/

本文歡迎轉載，但未經作者同意必須保留此段宣告，且在文章頁面明顯位置給出原文連線

個人下載了一些相關學習的PDF檔案，如果需要下載請訪問百度雲 點選此處訪問 密碼：jhuy

如果文章的內容對你有幫助，歡迎點贊~

為方便手機端檢視部落格，現正在將部落格遷移至微信公眾號：Salesforce零基礎學習，歡迎各位關注。