敏捷開發 & 團隊之日常
一.什麼是敏捷開發
敏捷開發(scrum)是一種以人為核心、迭代、循序漸進的開發方法。在敏捷開發中,軟體專案的構建被切分成多個子專案,各個子專案的成果都經過測試,具備整合和可執行的特徵。換言之,就是把一個大專案分為多個相互聯絡,但也可獨立執行的小專案,並分別完成,在此過程中軟體一直處於可使用狀態。因此敏捷開發是一個用於開發和維持複雜產品的框架 ,是一個增量的、迭代的開發過程。
二 . 敏捷的特點及呈現
❶敏捷開發模型 ✦特點: 不要求需求預先完備定義,支援使用者參與,支援需求的漸進式完善和確認,能夠適應使用者需求的變化。 ✦使用範圍: 需求複雜、難以確定、動態變化的軟體系統。 ❷傳統瀑布模型 ✦特點 簡單,分階段,階段間存在因果關係,不支援使用者參與,要求預先確定需求。 ✦使用範圍: 需求易於完善定義且不易變更的軟體系統。 ❸ 敏捷過程展現
三:Scrum三大角色
➀ 產品負責人PO
主要負責確定產品的功能和達到要求的標準,指定軟體的釋出日期和交付的內容,同時有權力接受或拒絕開發團隊的工作成果。
✚職責:
★ 清晰地表達產品代辦事項列表條目;
★ 對產品代辦事項列表中的條目進行排序,最好地實現目標和使命,並且最大化實現ROI;
★ 確保開發團隊所執行工作的價值;
★ 確保產品代辦事項列表對所有人可見、透明、清晰,並且顯示 Scrum 團隊的下一步工作;
★ 確保開發團隊對產品代辦事項列表中的條目達到一定程度的理解。
➁ Scrum Master
主要負責整個Scrum流程在專案中的順利實施和進行,以及清除擋在客戶和開發工作之間的溝通障礙。
✚職責:
★ 領導並指導組織採用 Scrum;
★ 在組織範圍內計劃 Scrum 的實施;
★ 幫助員工及干係人理解並實施 Scrum 和經驗性產品的開發;
★ 發起能提升Scrum 團隊生產力的變革;
★ 與其他 Scrum Master 一起工作,幫助組織更有效的應用Scrum.
➂ Scrum 開發團隊
主要負責軟體產品在Scrum規定流程下進行開發工作,包括功能實現、測試等團隊,不同職能的團隊人數控制在5~10人左右,相互協作使得最終能達到Sprint的目標。
✚職責:
★ 他們是自組織的,沒有人(即使是 Scrum Master 都不可以)告訴開發團隊如何把產品 代辦事項列表變成潛在可釋出的功能;
★ 開發團隊是跨職能的,團隊作為一個整體擁有創造產品增量所需要的全部技能;
★ Scrum 不認可開發團隊成員的頭銜,無論承擔哪種工作他們都是開發者。此規則無一例外;
★ 開發團隊中的每個成員可以有特長和專注領域,但是責任歸屬於整個開發團隊;
★ 開發團隊不包含如測試或業務分析等負責特定領域的子團隊。
4
◆ 四. Scrum的三個工件和運作模式 ◆
產品待辦事項列表(Product Backlog) |
產品待辦事項列表是一個經排序的持續完善的清單列表,包含所有產品需要的東西,也是產品需求變動的唯一來源。產品負責人負責產品待辦事項列表的內容、可用性和優先順序。 |
待辦事項列表 (Sprint Backlog) |
Sprint 待辦事項列表是一組為當前 Sprint 選出的產品代辦事項列表條目,外加交付產品增量和實現 Sprint 目標的計劃。整個列表將記錄整個開發過程中各個事項的實現情況。 |
燃盡圖 (Burn-down Chart) |
Sprint Burndown Chart 顯示了Sprint中累積剩餘的工作量,它是一個反映工作量完成狀況的趨勢圖。 圖中Y軸代表的是剩餘工作量,X軸代表的是Sprint的工作日。在Sprint開始的時候,Scrum Team會標示和估計在這個Sprint需要完成的詳細的任務。所有這個Sprint中需要完成,但沒有完成的任務的工作量是累積工作量,團隊會根據進展情況每天更新累積工作量,如果在Sprint結束時,累積工作量降低到0,Sprint就成功結束。 |
❶應用Scrum的團隊中,整個開發過程由若干個短的迭代週期組成,一個短的迭代週期稱為一個Sprint,每個Sprint的建議長度是2到4周(唯品花目前使用1周的Sprint). ❷ 在Scrum中,使用產品Backlog來管理產品的需求,產品backlog是一個按照商業價值排序的需求列表,列表條目的體現形式通常為使用者故事。Scrum團隊總是先開發對客戶具有較高價值的需求。 ❸在Sprint中,Scrum團隊從產品Backlog中挑選最高優先順序的需求進行開發。挑選的需求在Sprint計劃會議上經過討論、分析和估算得到相應的任務列表,我們稱它為Sprint backlog. ❹ 在每個迭代結束時,Scrum團隊將遞交潛在可交付的產品增量。
5
Scrum的日常
➀ 我們首先需要確定一個Product Backlog(按優先順序排列的一個產品需求列表),這個是由產品負責人 負責的;
➁Scrum開發團隊(包括產品負責人)根據Product Backlog列表,做工作量的預估和安排;
➂有了Product Backlog列表,我們需要通過 Sprint計劃會議從中挑選出一個Story作為本次迭代完成的目標,這個目標的時間週期是1~4個星期,然後把這個Story進行細化,形成一個Sprint Backlog;
➃ Sprint Backlog是由Scrum開發團隊去完成的,每個成員根據Sprint Backlog再細化成更小的任務(細到每個任務的工作量控制在0.5-1天內能完成),並將細化後的任務以貼便籤到看板的形式體現出來供後續跟進;
➄ 在Scrum開發團隊完成計劃會議上選出的Sprint Backlog過程中,需要進行每日站立會議,每次會議控制在15分鐘左右,每個人都必須發言,並且要向所有成員當面彙報你昨天完成了什麼,並且向所有成員承諾你今天要完成什麼,同時遇到不能解決的問題也可以提出,每個人發言完成後,要同步更新自己負責的看板;
➅ 在Scrum每日站立會議過程中,將參會成員遇到的問題整理到所有人可見的看板中,記錄所有需要跟進的事項;
➆ 當一個Story完成,也就是Sprint Backlog被完成,也就表示一次Sprint完成,這時,我們要進行 評審會議,產品負責人和客戶都要參加(最好本團隊老闆也參加),每一個Scrum開發團隊的成員都要向他們演示自己完成的軟體產品(這個會議非常重要,一定不能取消);
➇最後就是 Sprint回顧會議,也稱為總結會議,以輪流發言方式進行,每個人都要發言,總結並討論改進的地方,放入下一輪Sprint的產品需求中;
⑨ 當一輪Sprint的工作完成時,就開始計劃下一輪的Sprint的工作計劃,直到所有Story都完成為止(計劃好的n輪Sprint計劃);
六:敏捷開發流程的優點
❶ 精確:瀑布模式通常會在產品起點與最終結果之間規劃出一條直線,然後沿著直線不斷往前走。然而當專案到達終點時,使用者通常會發現那已經不是他們想去的地方。而敏捷方法則採用小步快跑,每走完一步再調整併為下一步確定方向,直到真正的終點;
❷ 質量:敏捷方法對每一次迭代週期的質量都有嚴格要求,這些都為敏捷專案的整個開發週期提供了可靠的質量保證;
❸ 速度:敏捷團隊只專注於開發專案中當前最需要的、最具價值的部分。這樣能很快地投入開發。另外,較短的迭代週期使團隊成員能迅速進入開發狀態;
❹豐厚的投資回報率:在敏捷開發過程中,最具價值的功能總是被優先開發,這樣能給客戶帶來最大的投資回報率;
❺高效的自我管理團隊:敏捷開發要求團隊成員必須積極主動,自我管理。在這樣的團隊中工作,每個團隊成員的技術能力、交流、社交、表達和領導能力也都能得以提高。
七:Scrum常見問題總結及解決方案
➀ 故事分解任務過程中任務規劃較粗,會造成在評估時造成工時不準確,存在資源浪費和資源使用不均衡的情況。
團隊把工作拆分成更加細緻的任務,控制在小時級的工作量,不要超過一天。這樣更有利於團隊為了同一個故事而共同努力,也便於協調多人同時參與,可以有效保證團隊資源的均衡利用,同時也便於成員確認每天的進展。
➁ 每日站會過程中,Scrum Master會不自覺的成為主導、主持人的角色,通過問答形式與站會成員交流。
團隊成員面對所有參會人員進行交流,而不是單獨為PMO進行工作彙報,並引導團隊成員自己掌控每日站會,從而帶動整個團隊的參會、工作積極性,同時控制好會議有序高效進行。(前一天做的事情、當天準備做的事情、遇到的問題)。
➂ 個別核心人員遲到或缺席,導致站立會的效率和質量下降。
確定專案的固定站會時間和必須參會人員,原則上缺席需要安排BackUp;若確定缺席,需提前告知團隊成員,以便評估早會是否照常進行還是適當推遲進行;必要時可引入獎罰機制。
➃ 沒有實施Sprint回顧會議,進行問題總結和跟蹤。
固定1-2個迭代週期組織團隊成員發起Sprint回顧會議,藉助回顧的方式與團隊成員共同參與討論,總結出在上一個迭代中遇到的所有問題,並商討產出完整的後續改進方案和流程,重要的一點是在以後的迭代中能夠做到有效地跟蹤並解決這些問題。
➄ 沒有做好Product BackLog管理。
協調各產品經理(Product Owner)統一整理並維護Product BackLog,制定明確的優先順序,使得開發、測試團隊成員能夠清晰、高效地篩選並完成每個Sprint內容。
今日推薦