整理敏捷開發(fā)實施框架anna

1、精品文檔敏捷開發(fā)實施框架2001年，10位軟件開發(fā)界著名的大師聚集在美國猶他州雪鳥滑雪圣地一起共同發(fā)布了“敏捷宣言”：個體及交互流程與工具、可用的軟件冗長的文檔、客戶協(xié)作合同談判、響應變化!循計劃，敏捷開發(fā)方法才為大眾所熟知。什么是敏捷？敏捷不是方法，而是思想，框架，目的在于“消滅一起工作效率瓶頸”，是在“不斷變化”“不可預測”的環(huán)境中高效、（低耗）、（迅速）地完成“既定目標”?！痉椒ㄕ摰目蚣堋俊疽环N迭代的流程】【現(xiàn)有實踐的集合】【改善溝通的一種方式】【最大化生產力的一種方式】我們對敏捷的理解和實踐:Scrum是Sprint的反復。首先，Scrum整體上是由連續(xù)的開發(fā)區(qū)間-Sprint構成。S

2、print開始前，召開Sprint規(guī)劃會議。此時，利害關系著在一起決定該Sprint做些什么。產品研發(fā)的Sprint的建議長度2到4周，偏重實現(xiàn)客戶需求的項目型sprint，根據實踐總結，sprint長度一般可長可短。計劃會議中，一旦決定了Sprint的實施內容，也就開始了一個Sprint。XSprint中，每天召開DailyScrumMeeting以確認每天的進度。利用DailyScrum和Sprint兩個不同長度的Time-box進行作業(yè)。XSprint結束時，召開Sprint評審會議，審核成果物。最后，在下一個Sprint開始之前召開回顧會（RetrospectiveMeeting）,討

3、論在下個Sprint團隊應該改善的地方。項目結束前，反復進行這樣的工作。這，就是Scrum。包IUP場層容市«產品功能細化押審會反思會2-6周迭代精品文檔精品文檔今天我來談談我對敏捷軟件開發(fā)的實踐總結，說的不到之處，請大家指正。對Scrum框架的熟悉，是實施敏捷scrum的第一步。根據我們中心的敏捷實踐，我歸納為：三個角色，五個會議，三個產出物，兩個過程控制物。【三個角色】敏捷項目管理中，角色分為三種，ProductOwner、ScrumMaster團隊-開發(fā)人員and架構師。為了便于大家理解，我把敏捷研發(fā)過程隱喻為我們在拍電影。用電影角色來形象化定義敏捷中的角色。ProductOw

4、ner故事作者-從業(yè)務角度驅動項目。?確定產品的功能，拆分用戶故事story。?根據市場價值，客戶需求確定功能優(yōu)先級。（accordingtoROI）?決定版本發(fā)布的日期和發(fā)布內容。?每個Sprint,根據需要調整功能和優(yōu)先級（原則上每個Sprint開始前調整，實際中在sprint實施過程中，也有可能調整功能和優(yōu)先級）。?接受或拒絕接受開發(fā)團隊的工作成果。?ProductOwner參與Scrumplanning。?為產品的profitabilityoftheproduct產品盈利能力和ROI負責。（包括市場價值,客戶滿意，開發(fā)成本）其中，投資回報率（RODo在敏捷開發(fā)過程中，最具價值的功能總是

5、被優(yōu)先開發(fā)，這樣能給客戶帶來最大的投資回報率。PO在確定優(yōu)先級排列的時候，是根據ROI來確定。ScrumMaster導演-Team的領導和推進者。?保證團隊資源完全可被利用并且全部是高產出的。?保證各個角色及職責的良好協(xié)作。?解決團隊開發(fā)中的障礙。?做為團隊和外部的接口，屏蔽外界對團隊成員的干擾。?保證開發(fā)過程按計劃進行，組織DailyScrum,SprintReviewandSprintPlanningmeetings。從組織層面，都是SM組織，但是SM應該讓團隊“自組織”，僅指導他們到點開會，怎么樣開會。在我們實踐中，DailyScrum由每個scrum"微"團隊來執(zhí)行

6、。SprintPlanningmeetings由PO來執(zhí)行。SprintReview是由團隊反饋召開的信息決定，PO具體實施?！緢F隊】演員-交付產品并對其質量負責。根據通信研發(fā)中心實際執(zhí)行情況，我們把團隊延伸為兩個角色：開發(fā)人員和架構師。團隊-開發(fā)人員：?評估工彳量（storypoint）?拆分用戶故事，定義任務（設計，界面，代碼，測試，文檔等）?評估資源利用率和工作時間（在結合資源利用率情況下，評估實際完成sprint需要的時間）?開發(fā)產品（設計，界面，代碼，測試，文檔等）?確保質量（敏捷要求對團隊成員技術能力有較高要求）精品文檔精品文檔?改進流程（每個sprint回顧會議，改進下一個spr

7、int的流程，沒錯，這是團隊共同的責任?。?向ProductOwner演示產品功能。團隊-架構師：?在sprint之前，按照AglieModeling的思路建立系統(tǒng)的架構，這個架構是和團隊一起完成，并歡迎團隊中每一個人為解決方案作出貢獻。?在sprint中，負責具體的重構（架構和關鍵業(yè)務邏輯）?在sprint中，是一個指導者和協(xié)調者，可以確保團隊不會缺少某些經驗或時對某些技術感到不適而簡單的拒絕一種設計方案。也可以在團隊中經常出現(xiàn)不同的意見。還會帶來激烈的爭吵時來幫助團隊打破僵局，重新和諧。?在sprint中，和PM一起從業(yè)務價值的角度解釋團隊用到的技術方案的選擇，所做的技術方案絕不是為了體現(xiàn)

8、技術領先，而是在成熟技術和業(yè)務價值之間做平衡。?在sprint中，story的實現(xiàn)不是工作重點，但是會承擔部分story的實現(xiàn)。在scrum團隊中，“架構師”并非一個職位，尤其不是固定某人，而是傾向于在每個團隊中，都確保要有能主持和協(xié)調編寫架構的人，以防止隊員們各自為戰(zhàn)，符合敏捷的自組織精神的。那實施敏捷研發(fā)和管理的組織，其他管理層在其中的角色如何定義呢？【管理層】制片廠老板-為Scrum團隊搭建良好的環(huán)境。?為Scrum團隊搭建良好的環(huán)境，以確保團隊能夠出色工作?創(chuàng)建結構和穩(wěn)定性?必要時，也會和ScrumMaster一起重組組織結構和指導原則【客戶】制片人-為Scrum團隊提出產品需求的人。

9、?與組織簽訂合同以開發(fā)產品?在內部開發(fā)產品的公司中，批準項目預算?一般是組織中的高級管理人員【最終用戶】觀眾。?根據自己的業(yè)務知識定義產品，并告知團隊自己的期望，提出請求。很多人都可能成為最終用戶?！疚鍌€會議】敏捷項目管理中，五個會議把整個敏捷開發(fā)模式串聯(lián)起來，每個會議都代表著敏捷的一個階段。一、Productbacklog該會議主要是確定產品或項目的用戶故事增量。確定具體的需求，確定做或不做?！緯h流程】：1、用戶故事的討論和增加；2、估算用戶故事。【會議交付物】：最新的PB【注意事項】：精品文檔精品文檔一般召開了此會議，就不用再召開Productbacklog估算會議，新增的用戶故事在本次

10、會議上會同時做好估算。該會議主要對疑難功能點如果轉化成用戶故事的一個討論溝通會。二、Productbacklog估算會議做好戰(zhàn)略規(guī)劃，知道backlog中各項的大小，這是版本規(guī)劃的必要輸入；如果想知道團隊在一個sprint中能夠完成多少工作，這個數據也是必需的。通過估算會議，團隊成員可以從會議中知道項目接下來的階段會發(fā)生哪些事情。估算會議也修整backlog內容，以合理方式分解backlog各項目，從而獲得更深入的理解。【會議流程】：1 .ProductOwner展示她希望得到估算的ProductBacklog條目2 .團隊根據“標準故事”估算storypoint，團隊聽完PO講解一個故事后，

11、就會根據進行“標準故事”比較，估算這個故事的Point。3 .如果某個Backlog條目過大，需要放到下一個或是后續(xù)的Sprint中，團隊就會將該Backlog條目劃分為較小的幾個Backlog條目，并對新的Backlog進行估算4 .重新估算Backlog中當前沒有完成、但是可能會在接下來Sprint中要完成的條目5 .區(qū)分出下一次估算會議需要澄清的Backlog條目【會議交付物】：1、經過估算的，按價值和風險排列優(yōu)先級的productbacklog。2、更小的backlog。3、需要澄清的問題，達成一致理解?！咀⒁馐马棥浚耗壳?，對story有兩種估算方法：1、估算storypoint用st

12、orypoint故事點，是為了看生產率（也可理解為資源利用率，產出率等）是否有所提升才發(fā)明的。productbacklog估算會議是根據"標準故事"估算storypoint,團隊聽完PO講解一個故事后，就會根據進行“標準故事”比較，估算這個故事的Pointo故事點point是提供給你從全局上“預估”和衡量項目的大小：每個story的point累加值。迭代完成后回顧這次迭代的完成情況：完成了多少個story,完成了多少個point。估算了故事點的團隊，就不再關心到底多久會出來，而是祈禱“反正故事點和上個月一樣多，應該能順利完成吧”這種祈禱，多數情況下是有效的，最后也能完成。S

13、print內的故事點一般是差不多，sprint迭代幾次后，團隊的生產率逐漸提高，故事點可逐漸增加。故事點point是沒有辦法burn的。需要轉化成工作量。工作量出來的時候：story->tasksprintbacklog由領取任務的人，拆分story為task,估計絕對工作量。工作量最大的意義在于提供一個可衡量的參數來考慮一個sprint中能否消化完這么多的pointo工作量也是衡量個體工作效率的指標。但是敏捷前提是對個體要求有較高的工作能力的，敏捷是團隊的行為，雖然敏捷也會帶來一些個體工作效率提升，但只是副作用而已。2、直接估算時間。國內目前真正使用storypoint的企業(yè)很少，幾乎

14、沒有。因為與其去與一個標準故事比較，討論差別，還不如直接估算工作量。唯一遺憾的是沒有辦法看每個人的工作率改進。精品文檔精品文檔二、Sprint計劃會議Sprint計劃會議一般分為兩次舉行。我們簡單的命名為Sprint計劃會議1和Sprint計劃會議2。Sprint計劃會議1:sprint目標，內容，story二次估算，bug,task的point估算。兩個目的：第一個是決定哪些故事需要在這個sprint中完成，是sprint計劃會議的一個主要活動。更具體地說，就是哪些故事需要從productbacklog拷貝到sprintbacklog中。第二個目的是分析該sprintbacklog是本次sp

15、rint會議的第二個主要目的，產品開發(fā)團隊可以從該會議中詳細了解最終用戶的真實需要。在會議結束，團隊將會決定他們在這個sprint結果中能交付哪些東西。補充一下，productbacklog根據我們的長期實踐結果，我們定義為：功能性需求、非功能性需求、bug三大部分?！緯h流程】：1、功能性需求：由PO根據估算和優(yōu)先級，從PB中挑選出該sprint階段內的backlog,在白板上提出。2、非功能性需求：由團隊和PO共同尋找非功能性需求，在白板上提出。3、bug：現(xiàn)場bug或其他版本發(fā)現(xiàn)的bug。4、由PO排列2,3,4闡述內容的優(yōu)先級。5、分析本次SprintBacklog,對1做再次估算，對

16、2,3point估算確認。7、PO把story的point累加值，得到本次sprint的point。根據歷史迭代的point數,確定本次sprint內容(發(fā)布的日期和發(fā)布內容)。8、scrum團隊一致認可并通過該SprintBacklog,PO確定本次sprint的目標?！緯h交付物】：?sprint目標?團隊成員名單?sprintbacklog?確定好sprint演示日期?確定好每日立會的時間地點【注意事項】：1、范圍(scope)和重要性(importance)由產品負責人設置。估算(estimate)由團隊進行；2、外部質量是系統(tǒng)用戶可以感知的。內部質量一般指用戶看不到的要素。內部質量不

17、能當做變量而使估算時間縮減。方法：故事的范圍縮減或調整故事的重要性。外部質量列表內部質量用戶可感知的，可操作的功能和性能，該功能和性能可增可減，可快可慢。所以可理解為范圍。用戶是無法感知。是系統(tǒng)的質量運行緩慢系統(tǒng)設計的一致性用戶界面操作模糊代碼可讀性用戶功能點比較大代碼重構安全性，穩(wěn)定性測試文檔精品文檔精品文檔3、在sprint中包含多少故事由團隊決定，而不是產品負責人或其他人。4、PO可以通過調整故事優(yōu)先級和故事范圍（產品負責人判斷出故事A中某些方面實際并不重要，所以他把A分成兩個故事A1和A2,賦給它們不同的重要級別。）來讓故事進入本次sprint。評估階段評估對象評估人評估階段評估流程一

18、次估算1、團隊每個成員根據“標準故事”估算storypoint,團隊聽完PO講解一個故事后，就會根據進行“標準故事”比較，估算這個故事的Point。、人中2、如果某個story過大，PO就要步拆分story,并對新初始階段ProductBacklog的story進行估算。團隊中PB的中的story1Ata13、如果團隊成員的估算值相差很大，團隊成員分別解釋估算值；然后冉重新估算。直到大家的估算值接近某個區(qū)間。最后由責任人決tepoint。4、最后得到經過估算的、分解為更合適粒度的ProductBcaklog。1、story的估算再次估算。spnntBacklog口隊spnnt2、分析backl

19、og,對延伸出來的非功能性需求的point估算。中的story,非功計劃會議/'3、對bug的point估算。能性需求，bug14、每個story的point累加值，得到本次sprint的point。1、sprintbacklog由領取任務的人對story進行任務拆分，并倩計實際工作量。,2、任務接受人如果對工作量沒有異議，按預估時間開始工作；sprintstory拆分后的小加4人、”如果有疑問，和任務拆分人提出時間調整意見，達成一致意見,.領取計劃會以一任務,后，修改工作量。人2一八一，3、詳細的工作重估算出來后，如果和storypoint相左較大，和PO協(xié)商調整任務或者拆分stor

20、y。直到可在一個sprint內完成。二次估算三次估算J5、可利用的資源：全身投入開發(fā)的時間基礎上，考慮寫文檔的時間，會議，技術支持，適當的buffer或者加班時間等。Sprint計劃會議2：功能設計會議，任務拆分，工作量和point合計調整。Sprint計劃會議2以設計工作為主，產品開發(fā)團隊可以為他們要實現(xiàn)的解決方案完成設計工作。會議結束后，團隊知道如何構建當前sprint中要開發(fā)的功能。【會議流程】：1、從第一個backlog條目開始。2、確定對于客戶的需求理解正確。精品文檔精品文檔3、圍繞該bcaklog條目進行設計，并給予下列類似問題：我們需要編寫什么樣的接口？需要創(chuàng)建什么樣的架構？更新

21、哪些表？更新或編寫哪些組件？4、sprintbacklog由領取任務的人對story進行任務拆分task,并估計實際工作量。task接受人如果對工作量沒有異議，按預估時間開始工作；如果有疑問，和任務拆分人提出時間調整意見，達成一致意見后，修改工作量。詳細的工作量估算出來后，如果和storypoint相差較大，和PO協(xié)商調整任務或者拆分story。直到可在一個sprint內完成?！緯h交付物】：?應用設計?架構設計圖和相關圖表?一些任務?確保團隊知道應該如何完成任務（設計）【注意事項】1、敏捷對文檔是輕量級的，對架構設計，接口設計，一些重要功能的設計需要有文檔輸出。敏捷認為所有的中間產品，比如計

22、劃，設計，測試用例等都缺少客戶價值，客戶最像要的價值就是最后可運行的軟件。2、該會議上會延伸出一些非功能性需求，成為本次sprint的backlog。3、非功能性需求超出sprint的工作量，需要再次和PO溝通變更backlog。我們對估算會議和sprint計劃會議1,2的重要內容“story的工作量估算”進行橫向串聯(lián)，得出以下估算流程。二、每日站會每日站會，收集障礙；領取或分配任務；更新任務板和燃盡圖。【會議流程】：1、一個主持者；2、每天早上在同樣的時間和地點3、團隊成員圍成一圈舉行一個會議4、在會議上每一個團隊成員輪流回答：“已完成”“計劃完成”“正在處理”“問題阻礙”（非障礙backl

23、og,是指任務開展中需要開會討論決議的工作，需要其他同事合作或架構師的技術協(xié)助等。）【會議交付物】：?障礙backlog?最新的sprintbacklog?最新的燃盡圖【注意事項】：1、SM不提出問題。精品文檔精品文檔2、不轉變會議話題。3、必須按時開始，遲到者不允許發(fā)言或發(fā)問。4、不討論深入細節(jié)。5、不是對領導的匯報，讓團隊中每個人都了解你的發(fā)言。6、不能單獨討論，自發(fā)的有序的進行發(fā)言。7、SM不要給團隊成員更新任務和燃盡圖。三、Sprint評審會議Sprint評審會議，向最終用戶展示工作成果，團隊成員希望得到反饋，并以之創(chuàng)建或變更backlog條目。我們這里的最終用戶一般以項目經理替代客戶

24、角色。評審會議也根據實踐情況，分成了sprint末的評審和及時跟進性評審（即story的及時性驗收）。sprint末的評審：【會議流程】：1、SMSE持會議，推進會議。2、PO主持會議，提醒本次sprint目標，本次sprint開發(fā)的story。3、開發(fā)團隊展示新功能，并且讓最終用戶嘗試新功能。4、最終用戶的反饋由PO記錄到backlog?！緯h交付物】：?障礙backlog輸入；?來自團隊或最終用戶的反饋為productbacklog輸入【注意事項】：1、不要展示不可能發(fā)布的產品增量。2、SM不要負責展示結果。3、團隊不要針對PO展示。及時跟進性評審：及時跟進性評審是我們針對story的驗收

25、特別良好的敏捷實踐，非會議形式。PO和scrum團隊成員點對點溝通模式。PO對story的完成情況進行需求吻合度驗證。驗證通過，進入測試環(huán)節(jié)，驗證沒通過，團隊需要返工修改。四、Sprint回顧會議Sprint回顧會議也叫反思會，目的是為了吸取經驗教訓，改進迭代過程，重點是改進團隊和組織的工作流程，Scrum團隊如何在下一個Sprint中做得更好?！緯h流程】：1、ScrumMaster首先給大家看SprintBacklog，總結這個Sprint。2、該sprint階段的障礙backlog（在下文中會解釋什么是障礙backlog）的討論。Sprint期間，會不斷產生障礙backlog,我們是用j

26、ira中的obstacle問題類型來進行記錄和跟蹤。本次會議上就要對這個sprint階段內的障礙backlog進行討論和解決。3、該sprint內工作方式，方法，過程的回顧。與會人員輪流發(fā)言，每個人都有機會發(fā)表自己的意見：發(fā)現(xiàn)什么是好的，什么是不好的。有哪些好的做法可以啟動，哪些不好的做法不能再繼續(xù)下去了。4、重大事件，重大缺陷的回顧總結。目前我們的實踐是在會議上對blocker和Critical的bug在各版本間進行clone，保持truck和個branches的版本穩(wěn)定。（這個任務僅作為我們敏捷實施在中的過渡性流程，等敏捷實踐越來越成熟，這個流程會逐漸淡化到消失）5、知識分享。精品文檔精品

27、文檔【會議交付物】：ScrumMaster總結下一個sprint改進的要點。我們的實踐是會議的產出由項目管理工程師在下一個sprint中進行持續(xù)跟蹤和改進觀察；同時對需要會后完成的改進要點，記錄到障礙backlog中，進行后續(xù)改進探索。【注意事項】：Sprint回顧會議通常是最容易被忽略的。實際上，在敏捷框架匯總，Sprint回顧會議的重要性僅次于Sprint計劃會議，是第二重要的會議?；仡檿h是Scrum團隊協(xié)作進步，sprint方式方法，流程改進的最好的機會。如果不開Sprint回顧會議，不久以后你就會發(fā)現(xiàn)，你的團隊在不斷地犯著同樣的錯誤，sprint的腳步會永遠持續(xù)不前?！救齻€產出物】工

28、作產品定位內容范圍注思ProductBacklog?ID統(tǒng)一標識符1、如何解決問題的應該是開發(fā)團修華,庫加、隊，產品負責人只需要關注業(yè)務目、.?Name七稱（摘要）產品待開發(fā)項標。即PB是描述怎樣使用而非怎樣D+D.日?Importance重要性排序（客戶由、生ProductBacklog是制危。從客戶價值角度理伍值優(yōu)先級）尸2、高優(yōu)先級的條目應有較詳盡的描解的產品功能列？1n由alestimate初如估算述，低優(yōu)先級的條目可只有一個名表。它就是一個需（storypoint人日）稱。求、或故事、或特？Howtodemo如何做演示（駟3、不需要保證初始估算值絕對無誤性等組成的列表，收標準）（比如

29、兩個故事點的故事就應該花按照重要性的級別兩天時間），而是要保證相對的正進行了排序。？N0tes_注解確性（即，兩個點的故事所花費的時間應該是四個點的故事所需的一半。工作產品定位內咨范圍注思SprintBacklog【SP中的功能性需求story（除PB中的字段外，進入sprint的story新增以下字段）：?story詳細闡述沖刺待開發(fā)項？規(guī)劃版本1、傳統(tǒng)的sprint只有PB中的SprintBacklog是？story拆分成任務story。那是非常理想狀態(tài)卜的從開發(fā)技術角度理？執(zhí)行人sprint沖刺。根據實踐，我們加入解的迭代開發(fā)任？具體估算工作量了非功能性需求和bug。務。在一輪迭代中？發(fā)

30、完成時間2、故事拆分成任務，避免拆分成更要完成的故事。？交付時間小的故事?！維P中的非功能性需求taskbug現(xiàn)在bug或者其他版本的bug工作產品定位內咨范圍注思精品文檔精品文檔WorkingSoftware可工作軟件WorkingSoftware是可交付的軟件產品?測試報告?安裝手冊?配置手冊?維護手冊?用戶操作手冊?安裝包done的標準是任務可以發(fā)布（編碼、測試、部署、文檔等），而不是僅僅編碼完成。所有done的集成，構成WorkingSoftware?！緝蓚€過程控制物】一、燃盡圖燃盡圖是敏捷開發(fā)過程中的進度管理工具圖。展示剩余待完成工作與時間的關系，每日立會后更新燃盡圖。未完成工作（Backlog）標識在縱坐標軸上，時間標識在橫坐標軸上，可以用來協(xié)助預測項目所有