您好,登錄后才能下訂單哦!
敏捷開發Scrum是什么?一般大家對敏捷開發Scrum的了解可能停留在概念的層面上,而對于Scrum的使用方法了解相對較少。今天就跟大家聊聊Scrum的運用。
1.Scrum簡介
Scrum是一個增量的、迭代的開發過程,名稱來自英式橄欖球的爭球。Scrum的整個開發周期包括若干個小的迭代周期,每個小的迭代周期稱為一個沖刺(SPrint),每個沖刺的長度一般為2到4周。在Scrum中,使用產品訂單來管理產品或項目的需求,產品訂單是一個按照商業價值排序的需求列表,列表條目的體現形式通常為用戶故事。開發團隊總是先開發的是對客戶具有較高價值的需求。在每個沖刺中,開發團隊從產品訂單中挑選最有價值的需求進行開發。沖刺中挑選的需求經過計劃會議上的分析、討論和估算得到一個沖刺的任務列表,我們稱它為沖刺訂單。在每個迭代結束時,開發團隊將交付潛在可交付的產品增量。
Scrum的主要角色有:產品負責人、Scrum主管、開發團隊。Scrum的會議包括:計劃會議、評審會議、回顧會議、每日站立例會。Scrum的文檔有:產品訂單、沖刺訂單、燃盡圖。Scrum方法的運作過程就是產品負責人、Scrum主管、開發團隊依據Scrum必需的文檔,通過Scrum定義的會議方式展開的一輪一輪產品開發的迭代過程。
2.Scrum方法的實際運用
Scrum方法給出的是一個框架,各角色人員如何根據這個框架來實踐Scrum,尤其如何利用好每日站立例會、評審會議、回顧會議,是影響敏捷開發效果的關鍵因素。在Scrum方法的實際運用中,會遇到或多或少的一些具體問題。筆者根據以往自身敏捷開發項目的經驗,對這些問題作簡要的分析,并給出有效的解決辦法。
2.1每日站立例會
每日站立例會是Scrum主管和開發團隊成員必須參加的會議。它是除了面對面溝通之外,開發團隊成員的另一個有效的溝通交流方式。Scrum倡導的每日站立例會平均時間不超過巧分鐘,開發團隊的每個成員需要向Scrum主管回答三個問題:今天完成了哪些工作?明天打算做什么?完成目標是否存在什么障礙?
每日站立例會需要Scrum主管的有效組織。每日站立例會最常見的問題是,團隊成員之間陷入了具體技術問題的討論中,導致會議時間嚴重拖長,影響了會議的效率。還有一種情況是,一個成員匯報所遇到的障礙的時候,其他成員沒有認真聆聽,對一些共有的障礙或者有依賴性的問題沒有引起足夠的重視,導致大家都卡在同樣的問題里,影響了開發的進度。
為使每日站立例會更加有效率,開發團隊的每個成員需要控制好自己的發言時間,一般在3分鐘左右。發言突出要點,簡明扼要,不要詳細論述具體技術問題。一旦發現團隊成員開始討論具體技術問題,Scrum主管應及時給與提醒,這樣可以有效地控制會議時間。為了使每個成員都清楚目前項目的狀況,尤其對可能影響完成目標的障礙有所了解,Scrum主管在每次例會結束之前把記錄下來的障礙向開發團隊總結一遍,讓大家心中有數,確保第二天的開發工作不受廣泛影響。這樣做也有助于Scrum主管在接下來的工作中有效地為團隊去除這些障礙。
2.2評審會議
在每一個沖刺的尾聲需要進行一次評審會議,產品負責人、Scrum主管、開發團隊必須參加評審會議。評審會議的目的是讓開發團隊向產品負責人展示在該沖刺完成的功能,回答與會人員對展示的疑問并記錄所期望的修改。評審會議進程一般不超過4個小時,開發團隊準備的評審展示內容一般不超過1個小時。評審會議包含階段性驗收的意味,如何才能在有限的展示時間內,得到產品負責人的積極認可和有效反饋,是在會議準備階段和會議進行過程中必須注意的問題。
在會議準備階段,開發團隊應該按照本次沖刺的沖刺訂單,組織產品功能的展示點,形成清晰簡要的PPT文檔。在會議現場最好能進行在線實際的功能展示,所以會議前開發團隊要準備好工作站和設備等。同時開發團隊還需要把能展現產品功能效果的圖、表、日志等數據提前保存下來,以防突發情況導致現場展示失敗時無內容可展示。在會議開始時,Scrum主管和開發團隊需要確保所有人員對產品和該沖刺的目標有所了解,如果有人對此不清楚,則先用幾分鐘進行描述。然后,開發團隊按照準備好的PPT文檔,逐個介紹這次沖刺實現的結果,并且展示其功能效果。在展示的過程中,開發團隊應該把重點放在“我們做了什么”,而不是“我們怎么做的”。這樣可以讓產品負責人對產品目前的功能狀況有直觀的了解,而不是陷入到技術細節之中。如果產品負責人想改變某些功能,Scrum主管把這個需求添加到產品訂單中,留待以后的沖刺解決。
2.3回顧會議
回顧會議是在每個沖刺結束之后進行的,通常在評審會議后進行,它通過總結本次沖刺的實踐經驗,為團隊指出日后改進的方面,避免團隊重犯相同的錯誤。Scrum主管、開發團隊必須參加回顧會議。回顧會議是Scrum方法中很重要的會議,利用好回顧會議,可以有效地提高團隊的生產力。回顧會議需要鼓勵團隊成員積極參與,集思廣益,否則,這個會議就會流于形式,達不到預期的效果。
在實際應用中,回顧會議的形式可以采取頭腦風暴法模式。會議開始時,Scrum主管先給團隊成員總結上次沖刺的回顧會議確定的改進內容的執行結果。然后,Scrum主管給每個成員發一張即時貼便簽,讓他們自己思考,回顧本次沖刺中團隊做得好和做得不好且需要改進的地方,各選三點意見寫在便簽上,然后把便簽貼在白板上。等所有成員都把寫好的便簽貼在白板上后,Scrum主管和團隊成員一起逐條討論便簽上的意見,充分理解團隊成員的想法。討論過程中,Scrum主管對相似的意見進行合并,對有依賴相關性的問題進行梳理。回顧會議結束后,Scrum主管就可以得到本次沖刺做得好的地方和需要改進的內容。那些需要改進的內容供下次沖刺的回顧會議進行效果跟蹤。
3.小結
Scrum方法是敏捷開發的一個框架,它并沒有規定具體的實踐方法。Scrum提倡靈活,遵循敏捷開發以人為本的原則,這需要軟件項目管理人員根據企業文化、管理模式、開發團隊的經驗等因素,選擇合適的方案。
看完上述內容,你們對Scrum方法有進一步的了解嗎?如果還想學到更多技能或想了解更多相關內容,歡迎關注億速云行業資訊頻道,感謝各位的閱讀。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。