本文將介紹scrum的開發流程(scrum development process)
po將使用者故事製作成使用者需求列表，並挑選出最優先項
sprint planning metting，整個團隊討論需求，估算乙個sprint開發時間(1~3周)的需求量，製作成tasks。
tasks確定後，團隊開始進入開發狀態，在這期間，所有的tasks是no changes，不可修改的。(敏捷開發不是對付需求的變動嗎？為什麼需求不做變動？團隊已經把這個使用者的需求製作成tasks，只要變成tasks就開工去做，所以做的時候是明確的，如果需求變來變去，做的就是白工，一直做返工的動作，所以乙個spring 期間是no change，這一點整個團隊和scrum master嚴格遵守)
站立會議：工作透明化，方便了解spirnt進度，對團隊成員中遇到的麻煩進行增派人手，對已完成的其工作的成員可以加入到其他工作進行學習，比如開發者完成模組開發或可配合測試進行工作，共同學習，提高整體開發團隊的能力，反之也一樣。
產品功能細化：是討論下乙個spint週期，我們要做的需求的新增、刪除、修改，而不是本次sprint要做的事
評審會(review meeting)：也就是把sprint的結果(可發布產品)做乙個增量的demo展示給客戶，客戶藉此回饋
反思會：把這次sprint做得好的地方繼承下來，下一次繼續做得更好，把不好的做修正
scrum會比瀑布模型聰明很多嗎？並沒有。瀑布是預期一次就可以做完，scrum分成好幾次，根據專案複雜度調整它的多廣。通過四個會議來強調溝通的重要性。會議最重要的就是溝通和會議記錄做成結果。
在瀑布模式中，每個人都有自己的角色，在不同的時間點分配任務，但是在scrum不這麼認為，所有的角色應該是全職能的，只有三種角色，po代表客戶，團隊有疑問就去問po，它管理所有的需求。在專案開發中，po不斷調整他的需求，但需求製作成tasks時進入sprint週期裡面，需求不做修改。這時候po就調整下乙個sprint的需求，持續地排序，排序按照市場、對手、最有力，是乙個舵手，決定產品開發的方向。再接下來是團隊，全職能的團隊，不去區分你是專案經理、設計師。scrum master通常不做coding，它是保證整個團隊開發過程裡面都能保證scrum的規範，排除對團隊開發中的任何障礙，減少團隊開發中的打斷。
產品待辦pb:客戶需求以使用者故事的形式撰寫、展現。
sp：決定了團隊這個sprint要做多少需求、任務，代辦這個sprint的產能。
增量：乙個衝刺sprint所產出的具體成果，展現給客戶欣賞，並取得回饋，，是乙個潛在可交付的增量，因為還做過使用者測試和比較完成的整合性測試。
product backlog(需求)：需求龐大由po負責，他代表客戶，主管所有需求，持續地做需求的增刪改查，其他人僅可建議，但是只有他有許可權抉擇。
sprint planning meeting(工作解析)：乙個sprint的週期在兩個星期，會給四個小時的工作解析時間。在該時間會分成兩個判斷，第乙個是po對他的需求做明確的說明，團隊針對此提出意見。分析目的正確與否，有無提供足夠的資料。第二部分是團隊拆解，由團隊做時間預估。傳統是由系統分析對客戶的需求進行收集，設計、向下分配任務，而scrum則是讓po說他的需求，團隊進行提問，讓正在做事的人把問題弄清楚。是不是這樣做來達到目的。
scrum很鼓勵成員第二天通過daily scrum來確定今天要做啥，團隊每個人心裡都有數要做什麼事，但是誰每天都有機會去拿不同的工作，做不同的學習，讓每個成員在scrum sprint中得到成長。團隊的共同成長就是最大的獲益。
scrum不是乙個快速開發的方法，但是每次都能提前交卷的原因，就是團隊不斷增強的開發能力。
daily scrum通常講三件事：昨天到現在，昨天我做了些什麼，對團隊有貢獻的事，這個牽扯到工時，一天是工作8個小時呢？還是個小時，scrum不鼓勵加班，scrum鼓勵是對團隊做了什麼有貢獻的事。第二件事是描述今天我準備做什麼？隱含學習和成長，最後是昨天的工作裡有無碰到困難，由團隊成員共同解決。
sprint包含開發測試除錯，解決主要bug，簡單的留給下乙個sprint，需要2個小時以上的bug需要計算工時，這可以更好地在burndownchart上的tasks能夠真正反映出它的效果，當遇到難度高的時候，burndownchart本來就應該不會順暢，然後團隊公同解決的時候，如何把tasks做的更順暢就會掉下來。
增量：客戶的期待，會給sprint取乙個名字，而不是取sprint1、sprint2，而是如何工作的sprint1，會有乙個target，這個目的就是增量。
只看產物，傳統的開發，所有的需求都需要做完。敏捷開發是將重要性進行排列，有些需求是可有可無，但客戶覺得已經足夠了，滿足了他當下的需求，而市場上的價值跟這個時間點跟他的產出物配合得最好，他就可能拿這個產品進行產出，所以並不是把所有的需求都做完，通常來說，一般只有40%的功能被經常用到，大部分功能都是沒有人去使用的。體現需求按優先排列的優點。
tasks都使用看板的方式，顯現真正的工作流程
回顧
scrum架構：3角色+4會議+3產物
每日站立會議：今天要做啥，昨天要做啥，碰到啥困難。這個是在衝刺sprint裡舉行，我在衝刺裡每天都學到東西，所以進度會快。
burndown chart：每日的站立會議後都需要使用burndown chart顯示。
scrum三支柱：透明化，檢驗和調適性，後兩者是團隊成員利用會議來做檢驗和除錯。
問題：1加班有沒有用？只有開始和結束是有用的。開始的時候是為了把問題搞得更清楚，直到後面怎麼做；如果結束時是為了把產品做得更好。
Scrum敏捷開發過程
敏捷開發 agile development 是一種以人為核心 迭代 循序漸進的開發方法。首先，我們要理解它不是一門技術，它是一種開發方法，也就是一種軟體開發的流程，它會指導我們用規定的環節去一步一步完成專案的開發 而這種開發方式的主要驅動核心是人 它採用的是迭代式開發 我們大部分人都學過瀑布開發模...
Scrum 開發過程 是什麼
原文 scrum是乙個敏捷開發框架，是乙個增量迭代的開發過程.在這個框架整個開發周期由若干個小的跌代週期，每個小的的跌代週期稱為乙個sprint，每個sprint的長度2到4周。在每個sprint中，scrum的開發團隊拿到乙個排列好優先順序的需求列表，我們稱它為使用者故事或者叫sprint bac...
Scrum 敏捷開發過程框架介紹
scrum 敏捷開發過程框架介紹 敏捷開發簡介 敏捷宣言 個體與互動 勝過 過程和工具 可用的軟體 勝過 完備的文件 客戶協作 勝過合同談判 響應變化 勝過遵循計畫 敏捷價值觀 溝通，簡單，反饋，勇氣，尊重 什麼是敏捷開發 它是一種軟體開發開發方 可以應對客戶快速變更的需求。它強調以人為核心，採用迭...