最近一直在了解和學習敏捷開發的應用，主要學習的還是scrum。寫這篇文章也是為了能對這段時間的學習有個總結。
在談scrum之前，我們可以先簡單了解下敏捷開發。
維基百科是這樣解釋的，敏捷開發是一種從2023年代開始逐漸引起廣泛關注的一些新型軟體開發方法，是一種應對快速變化的需求的一種軟體開發能力。它們的具體名稱、理念、過程、術語都不盡相同，相對於「非敏捷」，更強調程式設計師團隊與業務專家之間的緊密協作、面對面的溝通(認為比書面的文件更有效)、頻繁交付新的軟體版本、緊湊而自我組織型的團隊、能夠很好地適應需求變化的**編寫和團隊組織方法，也更注重軟體開發過程中人的作用。
敏捷開發注重以人為本，擁抱變化，目標明確，每個人資源相匹配。
敏捷軟體開發法支援廣泛的軟體開發生命週期。比如極限程式設計更專注於實踐，scrum、看板則專注於管理工作流程。
接下來我，我們再說說scrum。
上面也提到過， scrum相對來說專注於管理工作流程。對在每一次衝刺或迭代(乙個15到30天的週期，其長度由開發團隊決定)當中，開發團隊建立可用的(可以隨時推出)軟體的乙個增量。每乙個迭代所要實現的功能來自產品訂單。產品訂單按照優先順序排列工作需求。在迭代計畫會議中，產品負責人告訴開發團隊需要完成產品訂單中的哪些訂單項。開發團隊決定在下一次迭代中他們能夠承諾完成多少訂單項。[4] 在迭代的過程中，沒有人能夠變更迭代訂單，這意味著在乙個迭代中需求是被凍結的。
scrum 包含三個重要的角色：
scrum master是scrum教練和團隊的引導人，也是保證整個過程能夠合理動作scrum的核心角色，並且能夠掃清團隊實施遇到的困擾。
產品負責人確保產品的方向，定義產品優先順序、交付時間及產品的商業價值，是整個團隊中的指明燈。
開發團隊是具體執行者。交付產品所需要的各種技能的擁有者。
這三種角色組成了scrum的最小單位。
在團隊開發過程中，關於會議一直是有爭議的地方。我接觸過很多團隊，一種是整個開發過程中只有里程碑或者到某個時間節點時才會全員坐在一起進行某種意義上的交付，另一種則是三四天會開一次，每次時間則在1個小時左右的時間。
對於scrum來說， 會議是整個過程中重要的一環。scrum主張「每日站立會」， 要求每天的同一時間和同一地點進行15分鐘以內的站立會，而每天這個會議有乙個永恆的主題：
昨天完成的工作
今天打算完成的工作
完成工作中需要協助的地方。
這也是由於scrum的乙個重要特性，我們必須能夠掌握每個環節的狀態，確保整個專案鏈能夠在我們的風險控制內。每個人目前的工作內容，計畫都公開透明，最大程度的飽合了工作，同時也把風險及時的暴露出來，能及時調整、規避或者解決問題。
對於實施scrum來說，上面也最關鍵的有兩點特性：
擁抱變化。客戶或者需求方可以在專案過程中改變主意，變更他們的需求，而這些不可預見的因素是確確實實存在的，而如何快速響應不斷變化的需求和快速推出產品也是對整個團隊能力的一大考驗。
快速迭代。在使用scrum時，每次發布都是一次里程碑，在這個變化多端且競爭激烈的時代，沒有任何產品能夠忍受半年或者一年全部需求做完後，再去發布版本。所以，我們也能想像到，每次scrum都會不斷精簡需求，寧可先做幾個簡版上線，也不願意在做完所有功能再上線。
這兩點特性，也間接的證明了，scrum的高容錯率和專注性。每個團隊不可能保證不犯錯誤，而scrum的快速迭代及周期短，從而保證小的錯誤能夠被盡快的發現，而不是等到需要付出一定代價才能解決的錯誤。
所以， 在實施scrum時 經常會強制性的規定週期來做sprint。這種形式充滿了不確定性，但是卻又大大提高每個角色的專注度。如果我們非要事先確定發布週期而且還需要保證需求或功能不能有任何刪減，那麼，這種模式是真的不適合scrum。
說了這麼多， 主要還是在流程上尤其重要，有些環節看似煩瑣，但卻是不可或缺的一步。而在這些環節上都隱藏著乙個重要的角色：scrum master。
為什麼單獨拿出scrum master來說呢？我看了很多參考資料和書，也問了一些人，發現scrum master或許是整個開發過程中職責最不明確但卻最重要的乙個角色： 不參與需求分析、不參與**開發、不參與產品調研。他的職責只有兩個：
保證流程的正確執行以及專案的風險控制。
掃除一切其他人員遇到的障礙。
所以，這是乙個存在感很低，你很容易忽略但又不能不存在的角色。scrum master 關注的不僅僅是某一項工作或者某乙個人，他需要關注團隊中的每乙個人，團隊中的每一項工作，遇到的每乙個問題。這個角色不一定要懂開發技能，也不一定要有產品技能，但它一定會真正理解團隊的痛點，它的選擇永遠是對團隊有利的事。
接下來，我們再簡單的說下這方面應用的工具。
傳統的scrum，會用白板和excel等工具。而現在各種雲上的第三方協作工具也比較廣泛，為避免做廣告的嫌疑，我們就不提具體的第三方協作工具了。使用工具遵循的原則是：
說了這麼多，也需要解釋下，並不是所有的專案都適合scrum。一般使用scrum最好能符合以下幾個特徵：
時間有限，日期比較緊迫
市場需求或者技術變更很快
實驗性的專案
專案很複雜，並且靈活性較強
最後，再附上一張scrum的流程圖
敏捷開發 什麼是敏捷開發？敏捷開發掃盲（詳解）
敏捷開發 scrum 是一種軟體開發的流程，強調快速反應 快速迭代 價值驅動。scrum的英文意思是橄欖球運動的乙個專業術語，表示 爭球 的動作 運用該流程，你就能看到你團隊高效的工作。敏捷開發的特點就是下面4句話 個體與互動 勝過 過程與工具 可以工作的軟體 勝過 面面俱到的文擋 客戶協作 勝過 ...
ipd敏捷開發 IPD 敏捷開發
ipd 敏捷開發 課程目標 通過遊戲 實戰 討論，結合自己當前的實際工作，體會 ipd 系統工程在敏捷開發中的應用 敏捷方法的價值觀 敏捷開發需求管理的必要性和重要性 敏捷開發最佳實踐的組合應用 從而在未來的工作中，能夠靈活地運用這些知識，建立符合自己企業 團隊的工作流程與開發管理模式。課程大綱 1...
敏捷開發 敏捷測試
敏捷測試的定義 首先敏捷測試是敏捷的一種，原有測試定義中通過執行被測系統發現問題，通過測試這種活動能夠提供對被測系統提供度量等概念還是適用的。在傳統的測試定義上，還需要新增 敏捷測試是遵循敏捷宣言的一種測試實踐 強調從客戶的角度，即使用系統的使用者的角度，來測試系統 重點關注持續迭代的測試新開發的功...