敏捷開發 & 團隊之日常
一．什麼是敏捷開發
敏捷開發（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內容。
今日推薦
