該文檔的主要目的是爲了在團隊中實施敏捷開發,加速產品交付週期,爲敏捷開發提供相應的規範流程指導而產生的流程設計。運維
本文將適用於全部的開發、測試、產品、運維人員及管理者。測試
product owner也叫產品經理,負責整理user story(用戶故事),定義商業價值,對其進行排序,制定發佈計劃,對產品負責。編碼
scrum master也叫敏捷專家或者敏捷大師, 因涉及到工做量評估和分派任務等工做,通常設計
由敏捷團隊中的開發負責人擔任該角色。主要負責的工做有召開各類會議,協調項目以及部分研發工做。3d
scrum team即敏捷開發團隊,由不一樣技能的成員組成,經過緊密協同,完成每一次迭代的code
目標,交付產品。blog
sprint及敏捷中的每一次迭代衝刺。排序
在整個項目管理中,核心的角色有產品經理、項目經理、研發團隊和測試團隊四種角色,這項目管理
四種角色對應于敏捷開發中的product owner、scrum master、scrum team(DEV和QA)。這幾種角色之間牢牢圍繞產品的需求展開協做,取得成果。開發
【流程解釋】:
sprint制定的目標是否合理,開發、測試之間的配合是否順暢,直接致使了最終交付物的質
量。所以,本文根據過往的產品開發經驗,總結出一套適用於敏捷流程的節奏。
每一個sprint採用6+3+1的節奏。其含義爲:一個sprint包含6天開發工時,3天測試工時,1天上線及next sprint衝刺。
核心代碼在正式編碼以前,須要經過TC(技術委員會)或者Senior Engineer的技術評審,
評審經過以後,須要按照評審經過的方案進行coding。
coding完成以後,通知TC或者Senior Engineer組織code review。code review經過以後,才容許將代碼合併到公共的開發分支。
1) 代碼不容許在master上直接開發。
2) 每次迭代開發開始以前,scrum master負責從master上拉去新的代碼分支,而後將代碼分支告知scrum team全部人員。
3) scrum team成員基於第二步scrum master告知的本迭代的開發分支,拉取屬於我的的開發分支,並在我的開發分支的基礎之上進行開發。
4) scrum team成員開發自測完成以後,向scrum master發起代碼合併請求(從我的代碼分支合併到本迭代的開發分支)。
5) scrum master收到代碼合併請求以後,對代碼進行評審。評審經過以後,執行合併操做。若是合併的過程當中發生衝突,須要對應的開發人員解決衝突以後再提交到遠程倉庫。
6) 代碼合併到開發分支上以後,開始對代碼進行編譯打包,而且提交測試。
7) 分支代碼測試經過以後,在規定的上線窗口期,對分支代碼進行上線。上線成功且穩定以後,須要在上線當天,將開發分支的代碼由scrum master合併至master之上,而且在tag中打上標籤。