1. 程式人生 > >我對敏捷開發(Scrum)的理解

我對敏捷開發(Scrum)的理解

參考自:

八分鐘敏捷開發(scrum)掃盲

敏捷開發是一個什麼樣的開發模式

軟體開發模式之敏捷開發(scrum)

一【人員列表】

①產品負責人(Product owner)

負責與客戶直接溝通,得到需求定義並整理成列表,維護這個列表,有權決定一段時期的交付內容和交付時間節點,有權接收和拒絕開發成果

②專案負責人(Scrum owner)

負責消除開發過程中的溝通障礙,建立客戶和開發之間的溝通橋樑,提高需求和產出之間的變現效率

③開發團隊(Scrum team)

開發的主力,人數控制在5~10人之間,可以每個人有不同的技術方向專精。需要每個人具有較強的自我管理能力,並且有一定的溝通能力。重在產出,不在過程

二【產出列表】

①產品需求列表(Product backlog)

產品負責人收集客戶(不論廣義還是狹義客戶)的需求,整理出來的所有待辦事項列表,由產品負責人長期維護,是產品能夠長期持續產出的核心

②迭代計劃(Sprint)

由產品負責人和開發團隊開會溝通,從產品需求列表中,根據優先順序和實現難易度提取一部分需求,作為一次迭代的目標內容,最好控制在1~4周

③故事(Story)

將迭代計劃的內容分解為不同的使用者故事,每個都是獨立的模組,作為本次迭代的任務大塊羅列,每個還可以向下再細分。例如使用者資訊管理的大模組可以分解為使用者資訊修改、使用者頭像上傳、使用者密碼修改、使用者名稱片等story

④迭代任務列表(Sprint backlog)

一個迭代sprint分解出的不同的使用者故事,或者只分解出了一個使用者故事也可以,作為一次迭代任務列表

⑤任務分解(Task)

每個使用者故事可以再分解成更細的顆粒度,分解出來的更細的任務項稱為task,是開發團隊具體要開發的每一項內容,控制在1人/天之內,以便可以當天檢驗成果;如果時間超出了1人/天,說明這個task分解有問題,需要再次細分到1人/天之內

⑥燃盡圖(Burn down)

是視覺化進度監控,通常是在一個白板上面,把每個task寫一個便籤貼上去,分為三個區域:待辦(todo)、進行中(doing)、已完成(done),旁邊還會有個以日和未完成(包括進行中)任務總數為雙軸的線圖(即燃盡圖)。每個成員在迭代開始時自己的任務便籤全部貼在待辦區,開始進行一個任務就貼到進行區,某個任務完成了就貼到完成區。隨著進度的推進,所有任務便籤會漸漸從待辦、進行中轉移到完成區,全部轉移到完成區後,本次迭代就結束了,而燃盡圖的任務總數軸的計量也會變成0(即最終燃盡)

三【會議列表】

①迭代計劃會議(Sprint planning meeting)

在每次迭代開始時進行,由產品負責人發起,開發團隊參與討論,從產品需求列表中挑選出一個或者幾個模組作為story,合併為一個迭代衝刺(sprint),本次sprint總體開發時間控制在1~4周內

②晨會(Daily metting)

每天早晨花15分鐘時間進行每日站立會,每個人都要發言,講述自己昨天計劃完成什麼、實際完成了什麼,沒完成的話是什麼原因、需要什麼幫助,還有承諾今天要完成什麼,晨會過程中或者結束後,都要根據晨會內容更新燃盡圖

③迭代交付評審,演示(Sprint review meeting)

在每個迭代週期結束後,要演示當前交付成果,與會者包括開發團隊、產品負責人、客戶、最好包括老闆。每個開發人員演示自己的成果,由產品負責人和客戶協商是否接受成果

④迭代總結(Sprint retrospective meeting)

迭代交付後,可以有一個輕鬆的會議,輕鬆但是也有重要意義,每個人口述總結本次迭代的問題和經驗,帶入下一次迭代,以期作為積累減少之後開發的風險和提高效率、改進完成度