Scrum敏捷軟件開發(fā)過程說明_第1頁(yè)
Scrum敏捷軟件開發(fā)過程說明_第2頁(yè)
Scrum敏捷軟件開發(fā)過程說明_第3頁(yè)
Scrum敏捷軟件開發(fā)過程說明_第4頁(yè)
Scrum敏捷軟件開發(fā)過程說明_第5頁(yè)
已閱讀5頁(yè),還剩80頁(yè)未讀, 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請(qǐng)進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡(jiǎn)介

Scrum敏捷軟件開發(fā)過程2008-12-03JinghuaLiQualityManagerTietoEnatorCorporationT&MMDRMID2目錄什么是敏捷軟件開發(fā)?敏捷方法的工程方案敏捷工程管理和傳統(tǒng)工程管理為什么使用敏捷?Scrum概述Scrum的角色Scrum實(shí)踐和工作產(chǎn)品敏捷開發(fā)中的估計(jì)方法測(cè)試驅(qū)動(dòng)開發(fā)Scrum應(yīng)用支持工具和模版一些常見的誤解敏捷開發(fā)方法4什么是敏捷軟件開發(fā)?敏捷軟件開發(fā)是軟件工程的一個(gè)概念框架.有許多建立在敏捷概念上的方法,如Scrum和ExtremeProgramming(XP).與僵化的、重量級(jí)的、官僚式的方法形成對(duì)照,比方瀑布模型〔指純粹形式的〕最大限度地降低短期固定時(shí)間的迭代式軟件的開發(fā)風(fēng)險(xiǎn).5敏捷宣言〔2001年〕人和交互勝過過程和工具.Individualsandinteractionsoverprocessesandtools可以工作的軟件勝過完備的文檔.Workingsoftwareovercomprehensivedocuments客戶協(xié)作勝過合同談判.Customercollaborationovercontractnegotiation隨時(shí)應(yīng)對(duì)變化勝過遵循方案.Respondingtochangeoverfollowingaplan6敏捷過程的限制敏捷軟件開發(fā)過程包含過程、原那么、工具,和最重要的-人因此誠(chéng)信是根底沒有過程能夠?qū)φ\(chéng)信進(jìn)行有效地約束誠(chéng)信與否是有效實(shí)施敏捷過程的最大限制7使用敏捷方法的工程方案ProductBacklog(Features)5213858∑32InitialSizeEstimatesAsStoryPointsLongtermplanning(bestguessatthemoment):32SPoffunctionality,TeamVelocity8SP/Sprint4SprintsTargetSprintforeachPBLitemset,feasibleimplementationOrder.SprintBacklog(Tasks)85831“Sprintful”oftop-priorityPBLtothenextSprintMoreaccurateestimatesasmanhoursShorttermplanning(commitmentbyTeam):MaybeconstantlyupdatedScopefrozennewPBLitemstonextSprint8敏捷工程管理和傳統(tǒng)工程管理傳統(tǒng)工程管理:事先對(duì)整個(gè)工程進(jìn)行估計(jì)、方案、分析反對(duì)變更;變更需要重新估計(jì)、重新規(guī)劃嚴(yán)密的合同來減少風(fēng)險(xiǎn),如果改變需求要走CR流程.工程作為一個(gè)“黑盒子”,對(duì)客戶與供給商的可視性差.產(chǎn)品化和測(cè)試階段是別離的.文檔和方案驅(qū)動(dòng)的方法.軟件交付時(shí)間晚,意識(shí)到風(fēng)險(xiǎn)的時(shí)間晚.敏捷工程管理:對(duì)整個(gè)工程做一個(gè)粗略的估計(jì),每一次迭代都有詳細(xì)的方案.鼓勵(lì)變化,客戶價(jià)值驅(qū)動(dòng)開發(fā).信任和賦予權(quán)力;合約使變更變得簡(jiǎn)單,增加價(jià)值.客戶和開發(fā)人員之間是緊密的連續(xù)的合作關(guān)系每次迭代都產(chǎn)生可交付的軟件專注于交付軟件.第一次迭代就可交付能工作的版本,風(fēng)險(xiǎn)發(fā)現(xiàn)的早.9為什么采用敏捷?–預(yù)期的收益采用敏捷方法得當(dāng)?shù)脑?,可以:更加透?隨時(shí)跟蹤工程的狀態(tài)和進(jìn)展情況,及早發(fā)現(xiàn)問題和風(fēng)險(xiǎn).快速交付,每次迭代都能交付可運(yùn)行的軟件.最高風(fēng)險(xiǎn)和最高優(yōu)先級(jí)的需求,最優(yōu)先進(jìn)行開發(fā).改善應(yīng)對(duì)變更能力,減少大量的重方案.改善工程溝通.更好的客戶參與,防止錯(cuò)誤的假設(shè).總之:提高了生產(chǎn)率;減少“浪費(fèi)”〔不需要的文檔,重復(fù)工作等〕,工程的每次迭代都有明確的目標(biāo).提高客戶滿意度;短期內(nèi)產(chǎn)生成效,按預(yù)期交付軟件,每次迭代結(jié)束產(chǎn)生可以運(yùn)行的軟件.改善員工的滿意度;團(tuán)隊(duì)精神,減少官僚,能夠規(guī)劃和管理自己的工作,減少“恐慌”,穩(wěn)定的工作量〔可持續(xù)的步伐〕.10敏捷方法何時(shí)有效?公司和客戶一致認(rèn)為應(yīng)當(dāng)使用敏捷方法,雙方都能理解敏捷方法.敏捷方法對(duì)需求不完整以及經(jīng)常變換的工程比較有效.工程可以劃分成固定時(shí)間間隔的迭代,并且可以凍結(jié)正在進(jìn)行的迭代的范圍公司和客戶都有能力擔(dān)當(dāng)角色尤其是ProductOwner和ScrumMaster.工程的人員結(jié)構(gòu)能夠分成6到10人的團(tuán)隊(duì),最好每個(gè)工作地點(diǎn)一個(gè)小組.團(tuán)隊(duì)成員能夠以自組織的方式工作.工程的合同允許變更.固定價(jià)格的工程可以使用敏捷,但應(yīng)當(dāng)盡量防止。最好在按時(shí)間和材料付費(fèi)或者按月付費(fèi)的工程中進(jìn)行使用、變更工程的范圍不需要高級(jí)管理層的批準(zhǔn).11警告?。?!敏捷開發(fā)過程是一個(gè)艱苦的過程AgileWorkisHardWork這種狀態(tài)也許會(huì)存在很長(zhǎng)時(shí)間!!不舒服疑惑有挫折感Scrum概述13Scrum概述(1/3)Scrum是管理軟件工程的一個(gè)輕量級(jí)的敏捷方法,名字來源于橄欖球運(yùn)動(dòng)中的scrum過程簡(jiǎn)單,但高度的紀(jì)律性依賴迭代和增量的敏捷方法.Scrum是一種工作管理的方法,不僅僅限于軟件開發(fā),可以用來管理其它活動(dòng).Scrum不包含技術(shù)方法或?qū)嵺`.14Scrum概述(2/3)–工程的階段工程分成增量的迭代過程,在Scrum中稱為迭代任務(wù)清單,通常持續(xù)2-4周的時(shí)間.Sprint的時(shí)間是限定好的;不能從外部改變正在進(jìn)行中的sprint持續(xù)時(shí)間和范圍.每個(gè)sprint都可以產(chǎn)生可交付的迭代,即測(cè)試過并具備文檔的的功能點(diǎn)原那么上,當(dāng)產(chǎn)品開發(fā)到一定程度時(shí),如實(shí)現(xiàn)了足夠的客戶價(jià)值,工程可以在任何一個(gè)sprint后結(jié)束,.如同任何工程,敏捷的工程有三個(gè)主要階段:產(chǎn)品定義(規(guī)劃);運(yùn)行Sprints所需要的準(zhǔn)備、規(guī)劃、技術(shù)分析.執(zhí)行Sprints(執(zhí)行):在增量時(shí)間段內(nèi)實(shí)現(xiàn)需求(產(chǎn)品需求清單).結(jié)束:準(zhǔn)備最終發(fā)布,結(jié)束工程15Scrum概述(3/3)SprintPlanningMeeting:NextSprintGoalSprintBacklogUpdatedProductBacklogDailyScrummeetings:WhatdidyoudoyesterdayWhatwillyoudotoday?Whatobstaclesareinyourway?Source:DailyScrumSprintRetrospectiveShippableProductIncrementScrum角色、實(shí)踐和工作產(chǎn)品17Scrum中的三種角色ProductOwner-產(chǎn)品所有者個(gè)人:代表所有的干系人ScrumMaster:個(gè)人:負(fù)責(zé)指導(dǎo)過程的執(zhí)行ScrumTeam–Scrum團(tuán)隊(duì):承諾完成工作,向干系人交付產(chǎn)品價(jià)值18Scrum角色–Scrum團(tuán)隊(duì)Scrum團(tuán)隊(duì)是Scrum的中心角色,產(chǎn)品交付要依靠團(tuán)隊(duì).Scrum團(tuán)隊(duì)自我組織、自我管理Scrum團(tuán)隊(duì)是職能交叉的,包含產(chǎn)品交付的所有角色:開發(fā)人員、測(cè)試人員、buildmanagers,文檔編寫,界面設(shè)計(jì)人員.Scrum團(tuán)隊(duì)中的角色是不分等級(jí)的;不應(yīng)當(dāng)出現(xiàn)“我是開發(fā)人員我不作測(cè)試”.團(tuán)隊(duì)按照最有利于工程的原那么來分擔(dān)責(zé)任(如組件的所有權(quán)等).敏捷是建立在信任和授權(quán)的根底上,因此團(tuán)隊(duì)是自發(fā)組織的,組員選擇自己的任務(wù),而不是別人強(qiáng)制加以分配的.另一方面,Scrum團(tuán)隊(duì)有交付的責(zé)任,他們需要能夠自我鼓勵(lì)和對(duì)工作目標(biāo)進(jìn)行承諾.團(tuán)隊(duì)最正確規(guī)模:6-10人19Scrum角色–Scrum團(tuán)隊(duì)主要職責(zé)參與迭代任務(wù)清單的創(chuàng)立執(zhí)行為干系人創(chuàng)造價(jià)值的工作根據(jù)團(tuán)隊(duì)的承諾完成所需的各項(xiàng)任務(wù)將工作中的各項(xiàng)障礙迅速與ScrumMaster進(jìn)行溝通全面參與所有的各項(xiàng)會(huì)議更新任務(wù)狀態(tài)自發(fā)選擇任務(wù)標(biāo)識(shí)任務(wù)的完成標(biāo)識(shí)發(fā)現(xiàn)的新的任務(wù)與其它團(tuán)隊(duì)共同進(jìn)行工作20Scrum角色–ScrumMasterScrumMaster不是一個(gè)管理者,而是一個(gè)教練和推動(dòng)者-Scrum團(tuán)隊(duì)是一種自發(fā)的組織,是自我管理的.ScrumMaster的角色通常由工程組的成員擔(dān)當(dāng),組長(zhǎng)或者工程經(jīng)理。ScrumMaster應(yīng)當(dāng)是工程中的成員.主要職責(zé):評(píng)價(jià)過程的健康狀況加強(qiáng)過程消除障礙促進(jìn)過程改進(jìn)支持團(tuán)隊(duì)開發(fā)ScrumMaster的主要工作是做決策、消除障礙,保證團(tuán)隊(duì)能順利交付產(chǎn)品21Scrum角色–ScrumMasterScrumMaster還有如下責(zé)任與其它角色配合.訓(xùn)練團(tuán)隊(duì),提高生產(chǎn)率.培訓(xùn)產(chǎn)品所有者和干系人,確保Scrum流程的執(zhí)行確保一切工作按照既定的標(biāo)準(zhǔn)來運(yùn)行.規(guī)劃并進(jìn)行必要的改進(jìn).推動(dòng)會(huì)議的召開.維護(hù)障礙列表維護(hù)Scrum過程改進(jìn)列表優(yōu)秀的ScrumMaster應(yīng)當(dāng)是專注的,、有決心的、有領(lǐng)導(dǎo)才能.22Scrum角色–ProductOwner產(chǎn)品所有者代表投資方的利益,確保交付的產(chǎn)品與期望的一致〔提供更好的投資回報(bào)).ProductOwner決定產(chǎn)品具有哪些功能.ProductOwner’s的主要責(zé)任是創(chuàng)立和維護(hù)產(chǎn)品需求清單,即管理工程的范圍.ProductOwner不斷的把產(chǎn)品需求清單按優(yōu)先級(jí)進(jìn)行排序,使得最重要的功能能優(yōu)先實(shí)現(xiàn).對(duì)于團(tuán)隊(duì)來說,只有一個(gè)需求集。所有的需求申請(qǐng)都?xì)w口到ProductOwner管理商業(yè)價(jià)值〔投資回報(bào)〕ProductOwner還有如下責(zé)任:方案工程的發(fā)布,什么時(shí)間、向什么人等.對(duì)每次Sprint的結(jié)果進(jìn)行評(píng)審和批準(zhǔn)23Scrum角色–ProductOwner參與Scrum會(huì)議迭代方案會(huì)議團(tuán)隊(duì)進(jìn)展跟蹤會(huì)議迭代評(píng)審和回憶會(huì)議能夠隨時(shí)答復(fù)團(tuán)隊(duì)工作中產(chǎn)生的各項(xiàng)和產(chǎn)品/業(yè)務(wù)相關(guān)的問題ProductOwner的角色一般由客戶擔(dān)當(dāng),作為效勞提供商的公司無法設(shè)定優(yōu)先級(jí).24Scrum角色–客戶與管理層客戶和管理的角色是可選的,需要時(shí)才設(shè)立客戶:是產(chǎn)品的最終用戶通過ProductOwner來設(shè)定對(duì)產(chǎn)品的期望把當(dāng)前的業(yè)務(wù)傳達(dá)給工程.管理層:公司高級(jí)管理層,代表公司在工程中的利益.通過ProductOwner來傳達(dá)公司的利益和優(yōu)先級(jí)〔priorities〕25產(chǎn)品需求清單ProductBacklog(1/4)–概論根本上,產(chǎn)品需求清單是為了實(shí)現(xiàn)產(chǎn)品的功能所需要的工作的列表,包括:功能方面的需求;功能點(diǎn).非功能方面的需求,如性能改進(jìn).要修改的Bug;上一版本的錯(cuò)誤.新技術(shù),如支持新的操作系統(tǒng)或者平臺(tái).問題;日后的不確定項(xiàng),如新的功能.產(chǎn)品需求清單是不斷完善的.ProductOwner在工程進(jìn)行過程中可以隨時(shí)更新:增加、刪除、修改功能,變更優(yōu)先級(jí)等.下一次迭代中要包含較高優(yōu)先級(jí)的需求.產(chǎn)品需求清單也可稱為UserStories(用例),因?yàn)樗鼈兡軌蚪o產(chǎn)品的用戶帶來價(jià)值.在一次迭代中要能夠?qū)崿F(xiàn)產(chǎn)品需求清單,如果不能全部實(shí)現(xiàn)要進(jìn)行分解.26產(chǎn)品需求清單(2/4)–構(gòu)成ProductOwner負(fù)責(zé)創(chuàng)立最初的產(chǎn)品需求清單,一開始是不完整的.最初的清單應(yīng)當(dāng)包含足夠的需求.清單應(yīng)當(dāng)包含多少需求,取決于定價(jià)模型(black-box,更多的方案時(shí)間).產(chǎn)品需求清單來源于:客戶;標(biāo)書,需求規(guī)格說明等.Scrum團(tuán)隊(duì)的想法;增強(qiáng)型新功能等.現(xiàn)有產(chǎn)品的迭代增量;錯(cuò)誤,技術(shù)問題等.比較好的做法是ProductOwner、Scrum團(tuán)隊(duì)、客戶/管理以及其它相關(guān)方〔如相關(guān)的Scrum團(tuán)隊(duì)〕舉行一次或者屢次研討會(huì)ScrumMaster或者ProductOwner來促成會(huì)議的召開,必須要有人來做.要有效率、要圍繞主題、溝通良好、防止不同的假設(shè),承諾并且共通合作,確定優(yōu)先級(jí).27產(chǎn)品需求清單(3/4)–估計(jì)Scrum團(tuán)隊(duì)對(duì)產(chǎn)品需求清單的每一項(xiàng)的規(guī)模提供初步的估計(jì),通常采用事件點(diǎn)作為單位StoryPoints(模糊的).也可采用人天或者人小時(shí)作為單位,但容易混淆:a)實(shí)際的規(guī)模b)時(shí)間的單位.精確的估計(jì)值可以在Sprint規(guī)劃時(shí)給出,當(dāng)前階段沒有足夠的信息.規(guī)模的相對(duì)值才有意義.這個(gè)估計(jì)值有助于確定優(yōu)先級(jí);所需時(shí)間團(tuán)隊(duì)速度產(chǎn)品規(guī)模28產(chǎn)品需求清單(4/4)–優(yōu)先級(jí)優(yōu)先級(jí)是產(chǎn)品需求清單中的主要問題.優(yōu)先級(jí)不但反映了客戶的價(jià)值也反映了風(fēng)險(xiǎn).產(chǎn)品所有者-PO設(shè)定優(yōu)先級(jí).清單中的每一項(xiàng)的優(yōu)先級(jí)是唯一的,但可以對(duì)它們進(jìn)行分類優(yōu)先級(jí)可以在工程的任何時(shí)候進(jìn)行更改;如新的重要的功能可以直接給較高的優(yōu)先級(jí).確定優(yōu)先級(jí)考慮:價(jià)值風(fēng)險(xiǎn)依賴關(guān)系29產(chǎn)品需求清單–例如PriorityID,likeinanyrequirementsdocumentDescriptionoftheitem=UserStoryThesewilllikelyendupinthefirstSprint30版本發(fā)布方案在Scrum中,不是每個(gè)Sprints都要發(fā)布一個(gè)版本.迭代的結(jié)果主要是要實(shí)現(xiàn)功能的演示,不一定就是發(fā)布的版本.版本發(fā)布方案決定了每次迭代應(yīng)當(dāng)包含產(chǎn)品需求清單的哪些功能.根據(jù)現(xiàn)有的信息制定的工程總體的長(zhǎng)期的方案.根據(jù)產(chǎn)品需求清單和團(tuán)隊(duì)的進(jìn)度來決定(實(shí)施的范圍/迭代,e.g.inStoryPoints).Scrum團(tuán)隊(duì)參與版本發(fā)布方案的制定;架構(gòu)、風(fēng)險(xiǎn)、依賴性決定了可行的實(shí)現(xiàn)順序.版本發(fā)布方案很大程度上依賴于客戶的時(shí)間表和發(fā)布周期,即什么時(shí)候客戶的產(chǎn)品需要包含我們的模塊〔交付物〕.版本發(fā)布方案不是一成不變的;每個(gè)迭代結(jié)束后都可以更改.31完成的定義當(dāng)?shù)蝿?wù)清單上的任務(wù)都完成時(shí),變?yōu)椤耙淹瓿伞睜顟B(tài)定義“已完成”的含義是非常重要的,例如:如何記錄軟件的變化.使用什么樣的代碼分析工具,發(fā)現(xiàn)的問題應(yīng)當(dāng)如何處理.進(jìn)行了什么樣的測(cè)試,結(jié)果是如何記錄的,通過標(biāo)準(zhǔn)〔如覆蓋率、修正的錯(cuò)誤〕是什么.定義“已完成”意味著定義質(zhì)量上的需求.“已完成”是0/1變量:完成或者未完成.所有的任務(wù)〔task)都完成了迭代任務(wù)才算完成.在第一個(gè)迭代開始之前應(yīng)該定義好,因?yàn)樗鼤?huì)影響工作量,而且必須文檔化,這樣團(tuán)隊(duì)和產(chǎn)品所有者的理解是一致的.32完成的定義 完成的范圍隨著團(tuán)隊(duì)的成熟程度會(huì)逐漸發(fā)生變化計(jì)劃分析架構(gòu)設(shè)計(jì)開發(fā)測(cè)試性能指標(biāo)驗(yàn)收試運(yùn)行代碼評(píng)審支持文檔集成用戶文檔潛在的可交付的軟件33完成的定義-Example完成的定義遵循編碼標(biāo)準(zhǔn)能在模擬器上演示使用PCLint進(jìn)行靜態(tài)代碼分析具有EUnit測(cè)試套件的通過率和執(zhí)行率.或者使用結(jié)對(duì)編程,或者進(jìn)行代碼走查34迭代任務(wù)清單規(guī)劃(1/5)–總論迭代任務(wù)清單規(guī)劃的主要目的是從產(chǎn)品任務(wù)清單中挑選高優(yōu)先級(jí)的任務(wù)包含在下一次迭代中,即確定迭代的范圍.至于能夠包含多少產(chǎn)品任務(wù)清單中的任務(wù)取決于Scum團(tuán)隊(duì)能夠承諾完成多少.承諾總是來自于內(nèi)部,不能從外部強(qiáng)加.迭代不應(yīng)當(dāng)有空閑時(shí)間,因此規(guī)劃迭代范圍時(shí)要保證工作量是穩(wěn)定的(進(jìn)度是持續(xù)的速度).依賴多個(gè)因素;團(tuán)隊(duì)的能力,技術(shù)的成熟度,當(dāng)前迭代增量的情況等.迭代的范圍在迭代任務(wù)清單中描述;團(tuán)隊(duì)設(shè)定優(yōu)先級(jí).產(chǎn)品所有者PO定義每個(gè)迭代的任務(wù)說明〔missionstatement〕,目標(biāo)(sprintgoal),使迭代更具有針對(duì)性,如.“實(shí)現(xiàn)一個(gè)可擴(kuò)展的列表控件,其工程是可以選擇的”35Sprint迭代方案(2/5)–輸入和輸出SprintPlanningMeetingProductBacklogTeamCapabilitiesBusinessConditionsTechnologyCurrentProductSprintBacklogProductOwnerScrumTeamManagementCustomersSprintGoal36迭代任務(wù)清單規(guī)劃(3/5)–邏輯迭代任務(wù)清單規(guī)劃是“鐵三角”法那么的另一個(gè)例子在Scrum,邊界是一個(gè)變量,因?yàn)?資源(Scrum團(tuán)隊(duì))是確定的.進(jìn)度表〔迭代的時(shí)間〕是不能變的.質(zhì)量是無法協(xié)商的團(tuán)隊(duì)在一個(gè)迭代內(nèi)能完成的任務(wù),可以用團(tuán)隊(duì)進(jìn)度來衡量(StoryPoints/Sprint).如果可能的話利用同一個(gè)團(tuán)隊(duì)上個(gè)迭代的進(jìn)度,“yesterday’sweather”.30-daysprint20workdays1dayforplanning,1forreview/retrospective=18workdays5personsinteam90theoreticalmandays7.5-hourworkingday,average85%toprojectwork90*7.5*0.85=574manhours5%reservedforre-estimationandre-planning545manhours37迭代任務(wù)清單規(guī)劃(4/5)–規(guī)劃會(huì)議召開迭代任務(wù)清單規(guī)劃會(huì)議的目的是確定迭代的邊界.時(shí)間是限定的,最長(zhǎng)時(shí)間是一個(gè)工作日(對(duì)持續(xù)4個(gè)星期的迭代,迭代持續(xù)的時(shí)間越短,用在規(guī)劃上的時(shí)間也應(yīng)該越少.由ScrumMaster推動(dòng)會(huì)議.由于會(huì)議時(shí)間有限,ProductOwner和Scrum團(tuán)隊(duì)都應(yīng)該事前進(jìn)行準(zhǔn)備.前提:產(chǎn)品需求清單是有效的〔valid〕;最新的,標(biāo)注了優(yōu)先級(jí)并且表述清楚.規(guī)劃會(huì)議要解決兩個(gè)問題:下次迭代要做什么.確定迭代的目標(biāo),包含產(chǎn)品需求清單上高優(yōu)先級(jí)的功能.給Bug修改留一定的余地怎么樣實(shí)現(xiàn)下次增量所需要的功能.改進(jìn)設(shè)計(jì)以實(shí)現(xiàn)產(chǎn)品需求清單上的功能.38迭代任務(wù)清單規(guī)劃(5/5)–工作流程產(chǎn)品所有者向團(tuán)隊(duì)介紹起草的產(chǎn)品需求清單和迭代目標(biāo).產(chǎn)品所有者傳達(dá)迭代的起止日期.Scrum團(tuán)隊(duì)從產(chǎn)品需求清單中選取高優(yōu)先級(jí)的功能作為迭代的任務(wù),如果有必要,更新其規(guī)模估計(jì).Scrum團(tuán)隊(duì)改進(jìn)架構(gòu)和設(shè)計(jì)以便能夠?qū)崿F(xiàn)提出的產(chǎn)品需求.Scrum團(tuán)隊(duì)把產(chǎn)品需求清單的每一項(xiàng)劃分成小的任務(wù),并估算每個(gè)任務(wù)要花費(fèi)的小時(shí)數(shù).“撲克規(guī)劃”方法是估算工作量的有效方法.Scrum團(tuán)隊(duì)決定一個(gè)迭代中能夠?qū)崿F(xiàn)產(chǎn)品需求清單的多少功能產(chǎn)品所有者和Scrum團(tuán)隊(duì)明確了各自要承擔(dān)的義務(wù).39SprintBacklog例如PersonsworkingonthetaskDescriptionofthetaskEffortestimateTaskblockedbyanimpedimentSprintgoalMeetsthedefinitionofdone40執(zhí)行迭代任務(wù)清單執(zhí)行迭代任務(wù)清單意味著團(tuán)隊(duì)在迭代期間自行開發(fā).團(tuán)隊(duì)清楚要到達(dá)什么的目標(biāo)以及怎樣到達(dá)目標(biāo).每人每一時(shí)間只有一個(gè)任務(wù)團(tuán)隊(duì)是自發(fā)組織的;成員自己挑選任務(wù),ScrumMaster提供指導(dǎo)并去除障礙.不能從外部改變迭代的范圍或者迭代的周期.為了到達(dá)迭代的目標(biāo),團(tuán)隊(duì)可以增加、刪除任務(wù)或者改變其優(yōu)先次序.如果要重新設(shè)定迭代的范圍時(shí)需要產(chǎn)品所有者的配合.迭代周期短,意味著工期緊;應(yīng)該把重點(diǎn)放在剩余的工作和風(fēng)險(xiǎn)的消除,要區(qū)分任務(wù)的優(yōu)先級(jí),重要的事情應(yīng)領(lǐng)先做.迭代應(yīng)當(dāng)?shù)竭_(dá)工程的質(zhì)量要求(definitionof“done”);沒有獨(dú)立的測(cè)試階段.41迭代進(jìn)度圖-BurndownChartScrum注重成果,它關(guān)心的是要花多少時(shí)間到達(dá)目標(biāo),而不是已經(jīng)花費(fèi)的時(shí)間;.團(tuán)隊(duì)能否在既定的時(shí)間到達(dá)迭代的目標(biāo),可以查看要完成產(chǎn)品需求清單的功能所剩余的工作Remainingwork=EstimatetoComplete(ETC).描述剩余工作量和時(shí)間關(guān)系的圖表稱為SprintBurndown圖,是Scrum中非常重要的控制方法(controlmeasure).給Scrum團(tuán)隊(duì)和產(chǎn)品所有者提供直觀的信息.術(shù)語burndown說明Scrum團(tuán)隊(duì)在迭代過程中消耗剩余工作的能力;迭代結(jié)束時(shí)其值為0.每個(gè)任務(wù)〔task〕的工作量由Scrum團(tuán)隊(duì)來估計(jì).每天都要進(jìn)行估計(jì),以便進(jìn)行跟蹤.可以使用電子表格或者專門的工具〔如ScrumWorks〕42迭代進(jìn)度圖-BurndownChartIdealburndown.Actualburndown.Remainingworkincreasing

Tasksunderestimatedand/orworkremainingnotupdated.TasksremovedfromtheSprintBacklogtomeetSprintGoalfasterdecline.Sumofremainingwork[h]foralltasksintheSprintBacklogonaparticularday.Initialestimate(752h)InthebeginningoftheSprint43迭代進(jìn)度圖-BurndownChart44Scrum每日例會(huì)(1/4)–小雞和豬的故事Achickenandapigaretogetherwhenthechickensays,"Let'sstartarestaurant!“Thepigthinksitoverandsays,"Whatwouldwecallthisrestaurant?“Thechickensays,"Hamn'Eggs!“Thepigsays,"Nothanks.I'dbecommitted,butyou'donlybeinvolved!“InaDailySprint,onlyScrumMasterandScrumTeamarecommitted,andthusallowedtospeak.Othersareonlyinvolved.45Scrum每日例會(huì)(2/4)–概述例會(huì)最長(zhǎng)15分鐘,在整個(gè)迭代過程中每天的同一時(shí)間召開.團(tuán)隊(duì)成員之間交流信息.了解工程的真實(shí)的進(jìn)展情況交流風(fēng)險(xiǎn)和存在的問題.面對(duì)面的會(huì)議加強(qiáng)了承諾.ScrumMaster負(fù)責(zé)整個(gè)會(huì)議(會(huì)議地點(diǎn),邀請(qǐng)等).其他人可以參與,但只允許ScrumMaster和Scrum團(tuán)隊(duì)成員講話(小雞和豬).例會(huì)之前團(tuán)隊(duì)要更新工作量估計(jì),使進(jìn)度表保持最新.46Scrum每日例會(huì)(3/4)–形式為使會(huì)議簡(jiǎn)短而富有成效,要遵循嚴(yán)格的規(guī)程每個(gè)成員向其他人匯報(bào)以下內(nèi)容:上次會(huì)議以后所做的工作?下次會(huì)議之前要做的工作?工作中是否有什么障礙?如果出現(xiàn)其它的問題〔如設(shè)計(jì)的問題〕,應(yīng)當(dāng)在會(huì)議后處理.紀(jì)錄會(huì)議紀(jì)要,例如wiki.要養(yǎng)成良好的會(huì)議習(xí)慣47Scrum每日例會(huì)(4/4)48障礙根本上,任何阻止團(tuán)隊(duì)正常工作的,都可稱之為障礙,例如:無法訪問信息系統(tǒng).所需要的信息不能及時(shí)提供或者提供的不正確,如界面規(guī)格或者其它軟件模塊不到位或不正確開發(fā)環(huán)境或者原型系統(tǒng)出現(xiàn)問題其他的任務(wù)分配:培訓(xùn),售前支持缺乏必要的信息或者相應(yīng)的知識(shí)對(duì)于團(tuán)隊(duì)提出的各項(xiàng)障礙,ScrumMaster要以列表形式進(jìn)行記錄,49誰來去除障礙?每個(gè)人自我管理、自我組織的團(tuán)隊(duì)ScrumMaster產(chǎn)品所有者管理層其他相關(guān)的干系人ScrumMaster負(fù)責(zé)確定障礙已經(jīng)去除,不一定親自自己去除50去除障礙某些障礙是浪費(fèi)局部地完成工作額外的過程額外的功能任務(wù)轉(zhuǎn)換等待缺陷去除障礙的過程是團(tuán)隊(duì)和組織學(xué)習(xí)的過程51浪費(fèi)產(chǎn)生的原因多問幾個(gè)“為什么”對(duì)于每個(gè)標(biāo)識(shí)的障礙或者浪費(fèi),問一問“為什么”浪費(fèi)會(huì)存在多問幾個(gè)“為什么”,找到造成浪費(fèi)的根本原因52迭代中的同步工作每次迭代不是小的瀑布工程而是,每件事情同時(shí)都做一點(diǎn)53迭代的非正常終止在Scrum中,結(jié)束正在進(jìn)行的迭代是一種極端的行為,只有在萬不得以的情況下才能這么做.有時(shí)候確實(shí)需要停下來重新規(guī)劃,而不是一味的蠻干(bangingyourheadagainstthewall).迭代終止可能由下面的人發(fā)起:Scrum團(tuán)隊(duì),如果他們認(rèn)為達(dá)不到目標(biāo)或者目標(biāo)不清楚.ScrumMaster,如果迭代沒有進(jìn)展,或者無法克服某個(gè)困難.客戶/管理層,如果目標(biāo)已經(jīng)陳舊/過時(shí)(目標(biāo)產(chǎn)品被取消,平臺(tái)過時(shí)),或者其它的原因(資源問題等).迭代終止以后,啟動(dòng)新迭代的方案.導(dǎo)致迭代終止的原因不應(yīng)該在新的迭代中再次出現(xiàn).要考慮到合同方面的問題,如時(shí)間表的變更等.54迭代評(píng)審–概述迭代評(píng)審,在迭代結(jié)束后進(jìn)行,展示迭代的成果(功能運(yùn)行).確保成果與預(yù)期的一致,收集反響為工程提供一個(gè)參考點(diǎn),根據(jù)目前的位置方案下一期的旅程為下次迭代提供輸入〔改正、修改、新的想法可以由產(chǎn)品所有者添加到產(chǎn)品需求清單.與其它Scrum會(huì)議一樣,ScrumMaster主持迭代評(píng)審會(huì)議,Scrum團(tuán)隊(duì)負(fù)責(zé)演示.參加會(huì)議的其他人包括:產(chǎn)品所有者ProductOwner(必須參加)、客戶、管理人員,以及其它感興趣的人,例如其他Scrum團(tuán)隊(duì)(注意保密協(xié)議的要求).評(píng)審會(huì)議的時(shí)間是固定的:最長(zhǎng)4個(gè)小時(shí).評(píng)審會(huì)議應(yīng)當(dāng)是非正式的、創(chuàng)造性的,不用幻燈片等正式的東西.55迭代評(píng)審–流程在評(píng)審會(huì)議召開之前,團(tuán)隊(duì)要做好準(zhǔn)備:有組織、有效地進(jìn)行演示,不要超過4個(gè)小時(shí).誰來演示,演示什么,怎樣演示?方案準(zhǔn)備的時(shí)間不要超過一個(gè)小時(shí).迭代評(píng)審流程的一個(gè)例子:ScrumMaster介紹本次迭代的總體情況.目標(biāo)和清單vs.實(shí)際的結(jié)果,如果存在差距,原因是什么.Scrum團(tuán)隊(duì)簡(jiǎn)要介紹所涉及的技術(shù)問題,如架構(gòu)及其變更.Scrum團(tuán)隊(duì)演示已經(jīng)實(shí)現(xiàn)的功能:演示并進(jìn)行功能說明在場(chǎng)的人能夠親自嘗試使用不同的功能.ScrumMaster推動(dòng)自由討論,集思廣益.迭代評(píng)審應(yīng)當(dāng)是互動(dòng)的;有問題提出,問題解答,并歡送提出想法和建議.56迭代評(píng)審–可能的措施產(chǎn)品所有者根據(jù)評(píng)審的結(jié)果可能采取如下行動(dòng):更新產(chǎn)品需求清單,重新設(shè)定優(yōu)先級(jí):包含沒有按方案實(shí)現(xiàn)的功能(進(jìn)度比預(yù)期的要慢,任務(wù)未完成).不在方案中當(dāng)卻已經(jīng)實(shí)現(xiàn)的功能(進(jìn)度比預(yù)期的快).迭代評(píng)審中出現(xiàn)的新的想法.與ScrumMaster一起解決團(tuán)隊(duì)的變動(dòng)問題.要求把演示的功能,或者把上次迭代的功能,作為一個(gè)版本發(fā)布給客戶.決定工程不再持續(xù)下去,不再進(jìn)行迭代;認(rèn)為產(chǎn)品已完備.要求把產(chǎn)品需求清單授權(quán)給另外的團(tuán)隊(duì)來一起工作.……57迭代回憶會(huì)議SprintRetrospective回憶的目的是評(píng)價(jià)本次迭代并醞釀改進(jìn),使得下一個(gè)迭代進(jìn)行的更好.類似于工程的最終評(píng)審,但經(jīng)常舉行.障礙列表具有很好的參考價(jià)值!ScrumMaster主持召開,持續(xù)半天,Scrum團(tuán)隊(duì)參加(產(chǎn)品所有者也可參加).簡(jiǎn)單流程:ScrumMaster總結(jié)本次迭代;迭代任務(wù)清單,重要的事情和決策,預(yù)期的/實(shí)際進(jìn)度.每個(gè)組員陳述迭代中那些方法進(jìn)行的較好、哪些需要改進(jìn),ScrumMaster進(jìn)行記錄.對(duì)重要的問題方案相應(yīng)的措施:團(tuán)隊(duì)自己解決,或者提交給公司的管理層.Scrum方法應(yīng)用59敏捷開發(fā)中使用撲克Poker方法進(jìn)行估計(jì)(1/3)盡管名字有好笑,但卻非??煽亢陀行?可以來估算產(chǎn)品需求清單中每項(xiàng)的規(guī)模〔規(guī)模估算:用例點(diǎn)storypoint〕以及迭代任務(wù)清單中任務(wù)的估計(jì)(工作量估算:人時(shí)).ScrumMaster推動(dòng)活動(dòng)的進(jìn)行,一個(gè)以上的專家參與估算,而且最好是工程團(tuán)隊(duì)中的人.估算時(shí)使用卡片:寫有一系列的離散數(shù)據(jù),如0,1,2,3,5,8,13,?(無法估計(jì)).60敏捷開發(fā)中使用撲克Poker方法進(jìn)行估計(jì)(2/3)前提條件:提前準(zhǔn)備好要估算的任務(wù)、UserStories等;迭代任務(wù)清單和產(chǎn)品需求清單都已經(jīng)起草好.對(duì)某個(gè)任務(wù)最有經(jīng)驗(yàn)的開發(fā)者做一個(gè)簡(jiǎn)短的概述.可以通過簡(jiǎn)短的討論澄清任務(wù)的具體含義,找出存在的風(fēng)險(xiǎn)以及不確定性.各自對(duì)任務(wù)進(jìn)行估計(jì),所有的人將寫有各自估計(jì)數(shù)據(jù)的撲克/卡片扣上。(單位事先進(jìn)行約定:工時(shí)、事件點(diǎn)).大家同時(shí)把撲克/卡片翻過來.如果撲克/卡片上的數(shù)差距比較明顯(如一個(gè)13,2個(gè)5,一個(gè)1),就要討論一下為什么會(huì)出現(xiàn)這么大的差距,估計(jì)值所基于的假定要進(jìn)行澄清.如果差距較小(如三個(gè)8兩個(gè)5),主持人幫助確定最終的估值.對(duì)于不確定性,估算數(shù)據(jù)中可以多包含一些余量.不斷的重復(fù)該過程直到達(dá)成一致.將這些估值記錄到相應(yīng)的文檔中(產(chǎn)品需求清單,迭代任務(wù)清單).61敏捷開發(fā)中使用撲克Poker方法進(jìn)行估計(jì)(3/3)為什么使用離散的數(shù)字?比使用任意數(shù)字更加容易進(jìn)行估算.在整個(gè)工程中或者迭代中,每個(gè)人估計(jì)值的錯(cuò)誤會(huì)相互抵消掉.對(duì)每個(gè)任務(wù),16小時(shí)是上限,不確定性會(huì)隨著規(guī)模的增加而增加.為什么要有“?”.將較大的任務(wù)進(jìn)行分解,幫助更加精確的估計(jì)同時(shí)減少不確定性.為什么要“討論并重復(fù)”?弄清不同的假設(shè)(利用重用代碼或者重新編碼)和可能的誤解更為可靠的估計(jì).對(duì)于那些偏離平均值的估計(jì),即使由有經(jīng)驗(yàn)的人給出的,也必須要有充分的理由.62練習(xí)在一個(gè)小時(shí)之內(nèi)編寫一個(gè)三只小豬的連環(huán)畫冊(cè)使用Scrum實(shí)踐自組織團(tuán)隊(duì)迭代每日Scrum會(huì)議產(chǎn)品需求清單迭代任務(wù)清單63練習(xí)-進(jìn)度安排5分鐘:迭代目標(biāo)團(tuán)隊(duì)與產(chǎn)品所有者共同協(xié)作,從產(chǎn)品需求列表中選擇本次迭代要完成的工程5分鐘:迭代任務(wù)清單團(tuán)隊(duì)從所選擇的產(chǎn)品需求列表中產(chǎn)生任務(wù)10分鐘:第一天團(tuán)隊(duì)完成任務(wù)和產(chǎn)品需求列表中的工程產(chǎn)品所有者負(fù)責(zé)答復(fù)以下問題5分鐘:“每日”“Scrum會(huì)議每個(gè)人答復(fù)三個(gè)問題10分鐘:第二天團(tuán)隊(duì)繼續(xù)完成任務(wù)和產(chǎn)品需求列表中的工程產(chǎn)品所有者負(fù)責(zé)答復(fù)以下問題5分鐘:“每日”“Scrum會(huì)議每個(gè)人答復(fù)三個(gè)問題10分鐘:第三天團(tuán)隊(duì)完成產(chǎn)品的一個(gè)版本產(chǎn)品所有者負(fù)責(zé)答復(fù)以下問題每組5分鐘:演示團(tuán)隊(duì)向產(chǎn)品所有者展示完成的連環(huán)畫冊(cè)64練習(xí)–給出優(yōu)先級(jí)的產(chǎn)品需求清單展示根本的故事用鉛筆畫展示的故事每頁(yè)圖畫配有說明給出寫有標(biāo)題的封面故事用9頁(yè)進(jìn)行說明展示版權(quán)信息添加色彩廣告教小孩數(shù)數(shù)1,2,3寓教于樂:鞏固的重要性封皮吸引人硬的封皮3D效果的卡通形象展示所有的故事內(nèi)容產(chǎn)品所有者-ProductOwner充分考慮市場(chǎng)情況,對(duì)產(chǎn)品進(jìn)行規(guī)劃并進(jìn)行簡(jiǎn)要地說明規(guī)劃當(dāng)前該產(chǎn)品如何占有更多的市場(chǎng)份額規(guī)劃今后該產(chǎn)品的開展前景Scrum團(tuán)隊(duì)根據(jù)產(chǎn)品所有者的產(chǎn)品規(guī)劃進(jìn)行開發(fā)65測(cè)試驅(qū)動(dòng)開發(fā)TestDrivenDevelopment什么是測(cè)試驅(qū)動(dòng)?一種能夠支持Scrum的敏捷實(shí)踐方法,開發(fā)滿足DoD的軟件首先創(chuàng)立測(cè)試用例,然后開發(fā)軟件通過測(cè)試(在開發(fā)代碼前,首先編寫測(cè)試代碼)一種設(shè)計(jì)軟件的方法,而不僅僅是一種測(cè)試方法所創(chuàng)立的測(cè)試用例用來指導(dǎo)和約束工程中的各項(xiàng)工作,對(duì)未來的各項(xiàng)工作提供一個(gè)平安的保護(hù)不需要測(cè)試的工作不需要完成所創(chuàng)立的測(cè)試用例通常替代詳細(xì)的業(yè)務(wù)和技術(shù)需求定測(cè)試也有效地驅(qū)動(dòng)設(shè)計(jì),使設(shè)計(jì)更加趨向于可行的設(shè)計(jì)通常情況下需要自動(dòng)測(cè)試的支持(EUnit,JUnitetc.).對(duì)于UI軟件應(yīng)用TDD方法有一定的困難66測(cè)試驅(qū)動(dòng)開發(fā)–TDD測(cè)試用例的作用:確定所要完成的工作溝通工具產(chǎn)生一致的結(jié)果對(duì)軟件開發(fā)提供一個(gè)平安的保障67Scrum的核心反響檢查接受結(jié)對(duì)編程單體測(cè)試階段發(fā)布每日Scrum會(huì)議迭代演示68應(yīng)用(1/4)–概述根本原那么:不能只挑自己喜歡的,不管其它的Scrum非常簡(jiǎn)單,為了有效地發(fā)揮作用,應(yīng)當(dāng)具備:所有的角色.所有的實(shí)踐.所有的產(chǎn)品.Scrum可以進(jìn)行裁剪,但應(yīng)當(dāng)明白裁剪對(duì)工程的影響需要經(jīng)驗(yàn)和仔細(xì)考慮.69應(yīng)用(2/4)–大型/跨地域工程6到10人在同一房間進(jìn)行工作時(shí),Scrum能夠發(fā)揮最大效用.Scrum也可應(yīng)用在大型的跨地域的工程.一些指導(dǎo)原那么:將大的工程分成多個(gè)團(tuán)隊(duì),每個(gè)團(tuán)隊(duì)6到10人,有各自的ScrumMaster.對(duì)跨地域的工程,盡量不要把一個(gè)Scrum團(tuán)隊(duì)分到多個(gè)地方,一個(gè)Scrum團(tuán)隊(duì)就在一個(gè)地方,有自己的ScrumMaster.但是,如果團(tuán)隊(duì)的跨地域是不可防止的,可以使用網(wǎng)絡(luò)工具遠(yuǎn)程召開Scrum例會(huì).劃分團(tuán)隊(duì)時(shí),團(tuán)隊(duì)之間應(yīng)該有一個(gè)“自然界面”,如為防止混亂,不同的團(tuán)隊(duì)負(fù)責(zé)產(chǎn)品的不同局部.對(duì)于整個(gè)工程/產(chǎn)品:一個(gè)產(chǎn)品/工程只能有一個(gè)產(chǎn)品所有者和產(chǎn)品需求清單.團(tuán)隊(duì)之間的協(xié)調(diào)利用ScrumofScrums方法70應(yīng)用(3/4)-ScrumofScrumsScrumTeam6-10personsScrumTeam6-10personsScrumTeam6-10personsScrumofScrums“ScrumonTeamLevel”1-3times/week,orondemandEachteamrepresentedbydedicatedpersons(onlyoneifnoissuestoescalate)ProjectdividedtoScrumteamsbasedonprojectsizeorgeographicallocationScrumTeamshaveDailyScrummeetings,ScrumofScrumscanbeheldlessfrequently.Teleandvideoconferencingutilizedasneeded.71應(yīng)用(4/4)–固定價(jià)格的工程Scrum不鼓勵(lì)固定價(jià)格的工程每次迭代時(shí)進(jìn)行工程預(yù)算,產(chǎn)品需求清單可以根據(jù)當(dāng)前的優(yōu)先級(jí)進(jìn)行調(diào)整.某些工程中,客戶需要我們對(duì)整個(gè)工程給一個(gè)報(bào)價(jià)或者預(yù)算.價(jià)格固定限制了靈活性(對(duì)變化的響應(yīng)):如果價(jià)格和進(jìn)度是固定的,那么整個(gè)工程的范圍也是固定的(PB).必須對(duì)工程所有的迭代都進(jìn)行詳細(xì)的方案和規(guī)模估計(jì).變更工程的范圍,以及隨之而來的預(yù)算/進(jìn)度的變更需要提交CR.當(dāng)然可以改變產(chǎn)品需求清單的優(yōu)先級(jí),或者不改變工作量前提下把其中的某一項(xiàng)換成另一項(xiàng).仍然可以使用Scrum,并從中獲益72支持工具和模版TasksnotstartedTasksinprogressTaskscompleted(done)PrioritySprintGoalSprintBurndownChartTasks:DescriptionResponsiblepersonWorkremaining73一些常見的誤解敏捷是拯救任何工程的銀彈.敏捷方法只有運(yùn)用得當(dāng)才有效果.敏捷意味著ad-hochacking,不需要任何文檔.敏捷是有嚴(yán)格要求的,也是面向質(zhì)量的根據(jù)溝通的需要產(chǎn)生相應(yīng)的文檔.敏捷只是開發(fā)者的問題根本的開發(fā)方法與傳統(tǒng)相比有顯著不同,影響工程的各個(gè)方面:合同,角色,定價(jià)模型,工程管理等.采用敏捷方法的開發(fā)組/工程不需要制定方案敏捷工程需要經(jīng)常制定方案,但是不需要試圖超前制定工程方案,通常這也是不可能的.敏捷工程的范圍可以隨時(shí)改變.變更可以等到下一次迭代開始,當(dāng)前正在進(jìn)行中的迭代不能變更只對(duì)小工程適用在中型和大型的工程中一樣取得了成功74敏捷開發(fā)各階段的主要活動(dòng)JinghuaLi

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請(qǐng)下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請(qǐng)聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁(yè)內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫(kù)網(wǎng)僅提供信息存儲(chǔ)空間,僅對(duì)用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對(duì)用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對(duì)任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請(qǐng)與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對(duì)自己和他人造成任何形式的傷害或損失。

評(píng)論

0/150

提交評(píng)論