Scrum敏捷項(xiàng)目管理知識(shí)_第1頁(yè)
Scrum敏捷項(xiàng)目管理知識(shí)_第2頁(yè)
Scrum敏捷項(xiàng)目管理知識(shí)_第3頁(yè)
Scrum敏捷項(xiàng)目管理知識(shí)_第4頁(yè)
Scrum敏捷項(xiàng)目管理知識(shí)_第5頁(yè)
已閱讀5頁(yè),還剩21頁(yè)未讀 繼續(xù)免費(fèi)閱讀

下載本文檔

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

文檔簡(jiǎn)介

-.z.SCRUM敏捷管理知識(shí)什么是scrumScrum是一個(gè)用于開發(fā)和維持復(fù)雜產(chǎn)品的框架,是一個(gè)增量的、迭代的開發(fā)過(guò)程。在這個(gè)框架中,整個(gè)開發(fā)過(guò)程由若干個(gè)短的迭代周期組成,一個(gè)短的迭代周期稱為一個(gè)Sprint,每個(gè)Sprint的建議長(zhǎng)度是2到4周(互聯(lián)網(wǎng)產(chǎn)品研發(fā)可以使用1周的Sprint)。在Scrum中,使用產(chǎn)品Backlog來(lái)管理產(chǎn)品的需求,產(chǎn)品backlog是一個(gè)按照商業(yè)價(jià)值排序的需求列表,列表?xiàng)l目的體現(xiàn)形式通常為用戶故事。Scrum團(tuán)隊(duì)總是先開發(fā)對(duì)客戶具有較高價(jià)值的需求。在Sprint中,Scrum團(tuán)隊(duì)從產(chǎn)品Backlog中挑選最高優(yōu)先級(jí)的需求進(jìn)行開發(fā)。挑選的需求在Sprint計(jì)劃會(huì)議上經(jīng)過(guò)討論、分析和估算得到相應(yīng)的任務(wù)列表,我們稱它為Sprintbacklog。在每個(gè)迭代結(jié)束時(shí),Scrum團(tuán)隊(duì)將遞交潛在可交付的產(chǎn)品增量。Scrum起源于軟件開發(fā)項(xiàng)目,但它適用于任何復(fù)雜的或是創(chuàng)新性的項(xiàng)目。Scrum流程如下圖:SCRUM框架包括3個(gè)角色、3個(gè)工件、5個(gè)活動(dòng)、5個(gè)價(jià)值,具體說(shuō)明如下:3個(gè)角色產(chǎn)品負(fù)責(zé)人(ProductOwner)ScrumMasterScrum團(tuán)隊(duì)3個(gè)工件產(chǎn)品Backlog(ProductBacklog)SprintBacklog產(chǎn)品增量(Increment)5個(gè)活動(dòng)產(chǎn)品Backlog梳理會(huì)議(ProductBacklogRefinement)Sprint計(jì)劃會(huì)議(SprintPlanningMeeting)每日站會(huì)(DailyScrumMeeting)Sprint評(píng)審會(huì)議(SprintReviewMeeting)Sprint回顧會(huì)議(SprintRetrospectiveMeeting)5個(gè)價(jià)值承諾–愿意對(duì)目標(biāo)做出承諾專注–把你的心思和能力都用到你承諾的工作上去開放–Scrum把項(xiàng)目中的一切開放給每個(gè)人看尊重–每個(gè)人都有他獨(dú)特的背景和經(jīng)驗(yàn)勇氣–有勇氣做出承諾,履行承諾,接受別人的尊重SCRUM理論基礎(chǔ)Scrum以經(jīng)驗(yàn)性過(guò)程控制理論(經(jīng)驗(yàn)主義)做為理論基礎(chǔ)的過(guò)程。經(jīng)驗(yàn)主義主張知識(shí)源于經(jīng)驗(yàn),以及基于已知的東西做決定。Scrum采用迭代、增量的方法來(lái)優(yōu)化可預(yù)見性并控制風(fēng)險(xiǎn)。Scrum的三大支柱支撐起每個(gè)經(jīng)驗(yàn)性過(guò)程控制的實(shí)現(xiàn):透明性、檢驗(yàn)和適應(yīng)。Scrum的三大支柱如下:第一:透明性(Transparency)透明度是指,在軟件開發(fā)過(guò)程的各個(gè)環(huán)節(jié)保持高度的可見性,影響交付成果的各個(gè)方面對(duì)于參與交付的所有人、管理生產(chǎn)結(jié)果的人保持透明。管理生產(chǎn)成果的人不僅要能夠看到過(guò)程的這些方面,而且必須理解他們看到的內(nèi)容。也就是說(shuō),當(dāng)*個(gè)人在檢驗(yàn)一個(gè)過(guò)程,并確信*一個(gè)任務(wù)已經(jīng)完成時(shí),這個(gè)完成必須等同于他們對(duì)完成的定義。第二:檢驗(yàn)(Inspection)開發(fā)過(guò)程中的各方面必須做到足夠頻繁地檢驗(yàn),確保能夠及時(shí)發(fā)現(xiàn)過(guò)程中的重大偏差。在確定檢驗(yàn)頻率時(shí),需要考慮到檢驗(yàn)會(huì)引起所有過(guò)程發(fā)生變化。當(dāng)規(guī)定的檢驗(yàn)頻率超出了過(guò)程檢驗(yàn)所能容許的程度,則就會(huì)出現(xiàn)問(wèn)題。幸運(yùn)的是,軟件開發(fā)并不會(huì)出現(xiàn)這種情況。另一個(gè)因素就是檢驗(yàn)工作成果人員的技能水平和積極性。第三:適應(yīng)(Adaptation)如果檢驗(yàn)人員檢驗(yàn)的時(shí)候發(fā)現(xiàn)過(guò)程中的一個(gè)或多個(gè)方面不滿足驗(yàn)收標(biāo)準(zhǔn),并且最終產(chǎn)品是不合格的,則便需要對(duì)過(guò)程或是材料進(jìn)行調(diào)整。調(diào)整工作必須盡快實(shí)施,以減少進(jìn)一步的偏差。Scrum中通過(guò)三個(gè)活動(dòng)進(jìn)行檢驗(yàn)和適應(yīng):每日例會(huì)檢驗(yàn)Sprint目標(biāo)的進(jìn)展,做出調(diào)整,從而優(yōu)化次日的工作價(jià)值;Sprint評(píng)審和計(jì)劃會(huì)議檢驗(yàn)發(fā)布目標(biāo)的進(jìn)展,做出調(diào)整,從而優(yōu)化下一個(gè)Sprint的工作價(jià)值;Sprint回顧會(huì)議是用來(lái)回顧已經(jīng)完成的Sprint,并且確定做出什么樣的改善可以使接下來(lái)的Sprint更加高效、更加令人滿意,并且工作更快樂(lè)。SCRUM術(shù)語(yǔ)Scrum:Scrum無(wú)對(duì)應(yīng)中文翻譯Agile:敏捷Lean:精益Iterative:迭代式的Iteration:迭代AgileManifesto:敏捷宣言Empirical:經(jīng)驗(yàn)性的EmpiricalProcess:經(jīng)驗(yàn)性過(guò)程Transparency:透明性InspectandAdapt:檢視與調(diào)整Sprint:原意為沖刺,Scrum中的Sprint無(wú)對(duì)應(yīng)中文翻譯,指一個(gè)迭代SprintGoal:Sprint目標(biāo)ProductOwner:產(chǎn)品負(fù)責(zé)人簡(jiǎn)稱POScrumMaster:簡(jiǎn)稱SM,一般不翻譯DevelopmentTeam:Scrum開發(fā)團(tuán)隊(duì)ScrumTeam:指PO,SM和開發(fā)團(tuán)隊(duì)ScrumRoles:Scrum角色,指PO,SM和開發(fā)團(tuán)隊(duì)Emergent:涌現(xiàn)的ProductBacklog:產(chǎn)品待辦列表,指需求清單SprintBacklog:Sprint待辦列表,指Sprint任務(wù)清單SprintBurn-downChart:Sprint燃盡圖,團(tuán)隊(duì)用于做Sprint內(nèi)的進(jìn)展跟蹤ReleaseBurn-downChart:發(fā)布燃盡圖,產(chǎn)品負(fù)責(zé)人做發(fā)布進(jìn)展跟蹤SprintPlanningMeeting:Sprint計(jì)劃會(huì)議DailyScrumMeeting:每日站會(huì)SprintReviewMeeting:Sprint評(píng)審會(huì)議SprintRetrospectiveMeeting:Sprint回顧會(huì)議ProductBacklogRefinement:產(chǎn)品待辦列表梳理ProductBacklogItem:產(chǎn)品待辦清單條目,簡(jiǎn)稱PBIUserStory:用戶故事,指一條需求StoryPoint:衡量用戶故事的工作量大小的計(jì)量單位Velocity:團(tuán)隊(duì)速度SprintTask:實(shí)現(xiàn)一條需求需要做的一個(gè)技術(shù)任務(wù)DefinitionofDone:DoD,完成的定義Stakeholders:干系人Backlog:待辦列表Artifact:工件Estimation:估算Collaboration:協(xié)作ScalingScrum:大規(guī)模ScrumSCRUM起源Scrum的原始含義Scrum原始含義是指英式橄欖球次要犯規(guī)時(shí)在犯規(guī)地點(diǎn)對(duì)陣爭(zhēng)球。爭(zhēng)球雙方各有8個(gè)隊(duì)員參與,各方出3名前鋒隊(duì)員,并肩各站成一橫排,面對(duì)面躬身互相頂肩,中間形成一條通道,其他前鋒隊(duì)員分別站在后面,后排隊(duì)員用肩頂住前鋒隊(duì)員的臀部,組成3、2、3或3、4、1陣形。然后,由犯規(guī)隊(duì)的對(duì)方隊(duì)員在對(duì)陣一側(cè)1碼外,用雙手低手將球拋入通道,不得有利于本隊(duì)。當(dāng)球拋入通道時(shí),前排的3對(duì)前鋒隊(duì)員互相抗擠,爭(zhēng)相踢球給本方前衛(wèi)或后衛(wèi)隊(duì)員,前衛(wèi)和后衛(wèi)隊(duì)員必須等候前鋒將球踢回后,方可移動(dòng)。1986Scrum這個(gè)詞匯首次應(yīng)用于產(chǎn)品開發(fā)1986年,竹內(nèi)弘高和野中郁次郎在NewNewProductDevelopmentGame文章首次提到將Scrum應(yīng)用與產(chǎn)品開發(fā),他們指出:傳統(tǒng)的"接力式”的開發(fā)模式已經(jīng)不能滿足快速靈活的市場(chǎng)需求,而整體或"橄欖球式”的方法——團(tuán)隊(duì)作為一個(gè)整體前進(jìn),在團(tuán)隊(duì)的內(nèi)部傳球并保持前進(jìn),這也許可以更好的滿足當(dāng)前激烈的市場(chǎng)競(jìng)爭(zhēng)。1993年JeffSutherland首次將Scrum用于軟件開發(fā)敏捷思想深受日本工業(yè)界最佳實(shí)踐的影響,尤其是豐田和本田公司推行的精益原則,以及竹內(nèi)弘高和野中郁次郎開發(fā)的知識(shí)管理策略。受到以上思想的影響,以及對(duì)世界范圍內(nèi)軟件項(xiàng)目的研究,JeffSutherland在1993年首次在Easel公司定義了用于了軟件開發(fā)行業(yè)的Scrum流程,并開始實(shí)施。1995年JeffSutherland和KenSchwaber規(guī)范化了Scrum框架,并在OOPSLA95上公開發(fā)布。2001年敏捷宣言及原則發(fā)布、敏捷聯(lián)盟成立,Scrum是其中一種敏捷方法。2001年,KenSchwaber和MikeBeedle推出第一本Scrum書籍《Scrum敏捷軟件開發(fā)》。2002年KenSchwaber和MikeCohn共同創(chuàng)辦了Scrum聯(lián)盟。經(jīng)驗(yàn)性過(guò)程軟件開發(fā)是一個(gè)復(fù)雜的活動(dòng),在軟件產(chǎn)品開發(fā)的過(guò)程中不僅存在著需求的不確定性,也存在著技術(shù)的不確定性,再加上參與軟件開發(fā)的主體通常是由多人組成的軟件開發(fā)團(tuán)隊(duì),加上人的因素,就讓整個(gè)軟件開發(fā)的活動(dòng)變得非常復(fù)雜。如下圖所示,軟件開發(fā)活動(dòng)通常處在下圖的很復(fù)雜的區(qū)域。圖-01為了管理軟件開發(fā)的活動(dòng),我們會(huì)引入過(guò)程控制來(lái)管理它。過(guò)程控制通常有兩種方式,第一種方式是預(yù)定義的過(guò)程,第二種方式是經(jīng)驗(yàn)性過(guò)程。我們所熟知的是預(yù)定義的過(guò)程,它通常是使用已知的方法解決已知的問(wèn)題。制造業(yè)的生產(chǎn)線就是典型的預(yù)定義過(guò)程,例如生產(chǎn)餅干、啤酒、汽車的生產(chǎn)線等。預(yù)定義的過(guò)程的特點(diǎn)是給予固定的輸入,得到固定的輸出,過(guò)程可重復(fù)。它的優(yōu)勢(shì)在于可以大規(guī)模批量生產(chǎn)。預(yù)定義過(guò)程的缺點(diǎn)在于一旦過(guò)程定義出現(xiàn)錯(cuò)誤,或產(chǎn)品設(shè)計(jì)上存在瑕疵,會(huì)造成比較大的損失。圖-02如果我們期望解決的問(wèn)題比較復(fù)雜,并且存在著較大的不確定性的時(shí)候,我們需要使用經(jīng)驗(yàn)性過(guò)程。經(jīng)驗(yàn)性過(guò)程的特點(diǎn)是過(guò)程是不能夠完全預(yù)先定義好,結(jié)果是不可預(yù)知的,生產(chǎn)過(guò)程是不可重復(fù)的。比如研究一項(xiàng)新技術(shù),下一盤棋,踢一場(chǎng)球賽,在過(guò)程運(yùn)行當(dāng)中,我們需要通過(guò)不斷的獲得真實(shí)的反饋,然后進(jìn)行適應(yīng)和調(diào)整,使得過(guò)程能夠產(chǎn)出我們需要的結(jié)果。"在過(guò)程運(yùn)行機(jī)制相當(dāng)簡(jiǎn)單易懂的情況下,典型的做法是采用預(yù)定義的建模方式。如果過(guò)程復(fù)雜程度超出預(yù)定義方式的能力范圍,便應(yīng)用經(jīng)驗(yàn)性方式。”《過(guò)程動(dòng)態(tài)學(xué)、建模與控制》軟件產(chǎn)品的研發(fā)通常存在多很多的不確定性,并且生產(chǎn)的過(guò)程非常的復(fù)雜,所以更適合使用經(jīng)驗(yàn)性過(guò)程來(lái)管理。Scrum以經(jīng)驗(yàn)性過(guò)程控制理論做為理論基礎(chǔ)的過(guò)程。Scrum采用迭代、增量的方法來(lái)優(yōu)化可預(yù)見性并控制風(fēng)險(xiǎn)。Scrum過(guò)程框架的基石包括如下三個(gè)方面:第一:透明性(Transparency)透明度是指,在軟件開發(fā)過(guò)程的各個(gè)環(huán)節(jié)保持高度的可見性,影響交付成果的各個(gè)方面對(duì)于參與交付的所有人、管理生產(chǎn)結(jié)果的人保持透明。管理生產(chǎn)成果的人不僅要能夠看到過(guò)程的這些方面,而且必須理解他們看到的內(nèi)容。也就是說(shuō),當(dāng)*個(gè)人在檢驗(yàn)一個(gè)過(guò)程,并確信*一個(gè)任務(wù)已經(jīng)完成時(shí),這個(gè)完成必須等同于他們對(duì)完成的定義。第二:檢驗(yàn)(Inspection)開發(fā)過(guò)程中的各方面必須做到足夠頻繁地檢驗(yàn),確保能夠及時(shí)發(fā)現(xiàn)過(guò)程中的重大偏差。在確定檢驗(yàn)頻率時(shí),需要考慮到檢驗(yàn)會(huì)引起所有過(guò)程發(fā)生變化。當(dāng)規(guī)定的檢驗(yàn)頻率超出了過(guò)程檢驗(yàn)所能容許的程度,則就會(huì)出現(xiàn)問(wèn)題。幸運(yùn)的是,軟件開發(fā)并不會(huì)出現(xiàn)這種情況。另一個(gè)因素就是檢驗(yàn)工作成果人員的技能水平和積極性。第三:適應(yīng)(Adaptation)如果檢驗(yàn)人員檢驗(yàn)的時(shí)候發(fā)現(xiàn)過(guò)程中的一個(gè)或多個(gè)方面不滿足驗(yàn)收標(biāo)準(zhǔn),并且最終產(chǎn)品是不合格的,則便需要對(duì)過(guò)程或是材料進(jìn)行調(diào)整。調(diào)整工作必須盡快實(shí)施,以減少進(jìn)一步的偏差。Scrum中通過(guò)三個(gè)活動(dòng)進(jìn)行檢驗(yàn)和適應(yīng):每日例會(huì)檢驗(yàn)Sprint目標(biāo)的進(jìn)展,做出調(diào)整,從而優(yōu)化次日的工作價(jià)值;Sprint評(píng)審和計(jì)劃會(huì)議檢驗(yàn)發(fā)布目標(biāo)的進(jìn)展,做出調(diào)整,從而優(yōu)化下一個(gè)Sprint的工作價(jià)值;Sprint回顧會(huì)議是用來(lái)回顧已經(jīng)完成的Sprint,并且確定做出什么樣的改善可以使接下來(lái)的Sprint更加高效、更加令人滿意,并且工作更快樂(lè)。SCRUM團(tuán)隊(duì)的三個(gè)角色Scrum團(tuán)隊(duì)中包括三個(gè)角色,他們分別是產(chǎn)品負(fù)責(zé)人、開發(fā)團(tuán)隊(duì)和ScrumMaster。Scrum團(tuán)隊(duì)是自組織、跨職能的完整團(tuán)隊(duì)。自組織團(tuán)隊(duì)決定如何最好地完成他們的工作,而不是由團(tuán)隊(duì)外的其他人來(lái)指揮他們??缏毮艿膱F(tuán)隊(duì)擁有完成工作所需要的全部技能,不需要依賴團(tuán)隊(duì)外部的人。Scrum團(tuán)隊(duì)模式的目的是最大限度地優(yōu)化適應(yīng)性、創(chuàng)造性和生產(chǎn)力。Scrum團(tuán)隊(duì)通過(guò)迭代和增量交付產(chǎn)品功能的方法最大化反饋的機(jī)會(huì)。增量交付潛在可交付的產(chǎn)品增量保證了每個(gè)迭代都有潛在可發(fā)布的版本。Scrum角色之:產(chǎn)品負(fù)責(zé)人產(chǎn)品負(fù)責(zé)人負(fù)責(zé)最大化產(chǎn)品以及開發(fā)團(tuán)隊(duì)工作的價(jià)值。實(shí)現(xiàn)這一點(diǎn)的方式會(huì)隨著組織、Scrum團(tuán)隊(duì)以及單個(gè)團(tuán)隊(duì)成員的不同而不同。產(chǎn)品負(fù)責(zé)人是管理產(chǎn)品待辦事項(xiàng)列表的唯一責(zé)任人。產(chǎn)品待辦事項(xiàng)列表的管理包括:清晰地表達(dá)產(chǎn)品代辦事項(xiàng)列表?xiàng)l目對(duì)產(chǎn)品代辦事項(xiàng)列表中的條目進(jìn)行排序,最好地實(shí)現(xiàn)目標(biāo)和使命確保開發(fā)團(tuán)隊(duì)所執(zhí)行工作的價(jià)值確保產(chǎn)品代辦事項(xiàng)列表對(duì)所有人可見、透明、清晰,并且顯示Scrum團(tuán)隊(duì)的下一步工作確保開發(fā)團(tuán)隊(duì)對(duì)產(chǎn)品代辦事項(xiàng)列表中的條目達(dá)到一定程度的理解產(chǎn)品負(fù)責(zé)人可以親自完成上述工作,也可以讓開發(fā)團(tuán)隊(duì)來(lái)完成。然而,產(chǎn)品負(fù)責(zé)人是負(fù)責(zé)任者。產(chǎn)品負(fù)責(zé)人是一個(gè)人,而不是一個(gè)委員會(huì)。產(chǎn)品負(fù)責(zé)人可能會(huì)在產(chǎn)品代辦事項(xiàng)列表中體現(xiàn)一個(gè)委員會(huì)的需求,但要想改變*條目的優(yōu)先級(jí)必須先說(shuō)服產(chǎn)品負(fù)責(zé)人。為保證產(chǎn)品負(fù)責(zé)人的工作取得成功,組織中的所有人員都必須尊重他的決定。產(chǎn)品負(fù)責(zé)人所作的決定在產(chǎn)品待辦事項(xiàng)列表的內(nèi)容和排序中要清晰可見。任何人都不得要求開發(fā)團(tuán)隊(duì)按照另一套需求開展工作,開發(fā)團(tuán)隊(duì)也不允許聽從任何其他人的指令。Scrum角色之:開發(fā)團(tuán)隊(duì)開發(fā)團(tuán)隊(duì)包含了專業(yè)人員,負(fù)責(zé)在每個(gè)Sprint的結(jié)尾交付潛在可發(fā)布的"完成”產(chǎn)品增量。只有開發(fā)團(tuán)隊(duì)的成員才能創(chuàng)造增量。開發(fā)團(tuán)隊(duì)由組織構(gòu)建并授權(quán),來(lái)組織和管理他們的工作。所產(chǎn)生的協(xié)同工作能最大化開發(fā)團(tuán)隊(duì)的整體效率和效力。開發(fā)團(tuán)隊(duì)有以下幾個(gè)特點(diǎn):他們是自組織的,沒(méi)有人(即使是ScrumMaster都不可以)告訴開發(fā)團(tuán)隊(duì)如何把產(chǎn)品代辦事項(xiàng)列表變成潛在可發(fā)布的功能。開發(fā)團(tuán)隊(duì)是跨職能的,團(tuán)隊(duì)作為一個(gè)整體擁有創(chuàng)造產(chǎn)品增量所需要的全部技能。Scrum不認(rèn)可開發(fā)團(tuán)隊(duì)成員的頭銜,無(wú)論承擔(dān)哪種工作他們都是開發(fā)者。此規(guī)則無(wú)一例外。開發(fā)團(tuán)隊(duì)中的每個(gè)成員可以有特長(zhǎng)和專注領(lǐng)域,但是責(zé)任歸屬于整個(gè)開發(fā)團(tuán)隊(duì)開發(fā)團(tuán)隊(duì)不包含如測(cè)試或業(yè)務(wù)分析等負(fù)責(zé)特定領(lǐng)域的子團(tuán)隊(duì)。開發(fā)團(tuán)隊(duì)的規(guī)模開發(fā)團(tuán)隊(duì)最佳規(guī)模是小到足以保持敏捷性,大到足以完成重要工作。少于3人的開發(fā)團(tuán)隊(duì)沒(méi)有足夠的交互,因而所獲得的生產(chǎn)力增長(zhǎng)也不會(huì)很大。小團(tuán)隊(duì)在Sprint中可能會(huì)受到技能限制,從而導(dǎo)致無(wú)法交付可發(fā)布的產(chǎn)品增量。大于9人的團(tuán)隊(duì)需要過(guò)多的協(xié)調(diào)溝通工作。大型團(tuán)隊(duì)會(huì)產(chǎn)生太多復(fù)雜性,不便于經(jīng)驗(yàn)過(guò)程管理。產(chǎn)品負(fù)責(zé)人和ScrumMaster的角色不包含在此數(shù)字中,除非他們也參與執(zhí)行Sprint代表事項(xiàng)列表中的工作。Scrum角色之:ScrumMasterScrumMaster負(fù)責(zé)確保Scrum被理解并實(shí)施。為了達(dá)到這個(gè)目的,ScrumMaster要確保Scrum團(tuán)隊(duì)遵循Scrum的理論、實(shí)踐和規(guī)則。ScrumMaster是Scrum團(tuán)隊(duì)中的服務(wù)式領(lǐng)導(dǎo)。ScrumMaster幫助Scrum團(tuán)隊(duì)外的人員了解他們?nèi)绾闻cScrum團(tuán)隊(duì)交互是有益的。ScrumMaster通過(guò)改變這些交互來(lái)最大化Scrum團(tuán)隊(duì)所創(chuàng)造的價(jià)值。ScrumMaster服務(wù)于產(chǎn)品負(fù)責(zé)人ScrumMaster以各種方式服務(wù)于產(chǎn)品負(fù)責(zé)人,包括:找到有效管理產(chǎn)品代辦事項(xiàng)列表的技巧清晰地和開發(fā)團(tuán)隊(duì)溝通愿景、目標(biāo)和產(chǎn)品代表事項(xiàng)列表?xiàng)l目教導(dǎo)開發(fā)團(tuán)隊(duì)創(chuàng)建清晰簡(jiǎn)明的產(chǎn)品代表事項(xiàng)列表?xiàng)l目在經(jīng)驗(yàn)主義環(huán)境中理解長(zhǎng)期的產(chǎn)品規(guī)劃理解并實(shí)踐敏捷按需推動(dòng)Scrum活動(dòng)ScrumMaster服務(wù)于開發(fā)團(tuán)隊(duì)ScrumMaster以各種方式服務(wù)于開發(fā)團(tuán)隊(duì),包括:指導(dǎo)開發(fā)團(tuán)隊(duì)自組織和跨職能教導(dǎo)并領(lǐng)導(dǎo)開發(fā)團(tuán)隊(duì)創(chuàng)造高價(jià)值的產(chǎn)品移除開發(fā)團(tuán)隊(duì)進(jìn)展過(guò)程中的障礙按需推動(dòng)Scrum活動(dòng)在Scrum還未完全被采納和理解的組織環(huán)境下指導(dǎo)開發(fā)團(tuán)隊(duì)ScrumMaster服務(wù)于組織ScrumMaster以各種方式服務(wù)于組織,包括:領(lǐng)導(dǎo)并指導(dǎo)組織采用Scrum在組織范圍內(nèi)計(jì)劃Scrum的實(shí)施幫助員工及干系人理解并實(shí)施Scrum和經(jīng)驗(yàn)性產(chǎn)品開發(fā)發(fā)起能提升Scrum團(tuán)隊(duì)生產(chǎn)力的變革與其他ScrumMaster一起工作,幫助組織更有效的應(yīng)用ScrumSCRUM的三個(gè)工件Scrum的工件以不同的方式展現(xiàn)工作和價(jià)值,可以用來(lái)提供透明性以及檢驗(yàn)和適應(yīng)的機(jī)會(huì)。Scrum中所定義的工件能最大化關(guān)鍵信息的透明性,來(lái)保證Scrum團(tuán)隊(duì)成功地交付完成的增量。ProductBacklog–產(chǎn)品待辦事項(xiàng)列表產(chǎn)品待辦事項(xiàng)列表是一個(gè)排序的列表,包含所有產(chǎn)品需要的東西,也是產(chǎn)品需求變動(dòng)的唯一來(lái)源。產(chǎn)品負(fù)責(zé)人負(fù)責(zé)產(chǎn)品待辦事項(xiàng)列表的內(nèi)容、可用性和優(yōu)先級(jí)。產(chǎn)品待辦事項(xiàng)列表是一個(gè)持續(xù)完善的清單,最初的版本只列出最初始的和眾所周知的需求。產(chǎn)品待辦事項(xiàng)列表根據(jù)產(chǎn)品和開發(fā)環(huán)境的變化而演進(jìn)。待辦事項(xiàng)列表是動(dòng)態(tài)的,它經(jīng)常發(fā)生變化以識(shí)別使產(chǎn)品合理、有競(jìng)爭(zhēng)力和有用所必需的東西。只要產(chǎn)品存在,產(chǎn)品待辦事項(xiàng)列表就存在。產(chǎn)品待辦事項(xiàng)列表列出了所有的特性、功能、需求、改進(jìn)方法和缺陷修復(fù)等對(duì)未來(lái)發(fā)布產(chǎn)品進(jìn)行的改變。產(chǎn)品待辦事項(xiàng)列表?xiàng)l目包含描述、次序和估算的特征。產(chǎn)品待辦事項(xiàng)列表通常以價(jià)值、風(fēng)險(xiǎn)、優(yōu)先級(jí)和必須性排序。它是一個(gè)按照優(yōu)先級(jí)由高到低排列的一個(gè)序列,每個(gè)條目有唯一的順序。排在頂部的產(chǎn)品待辦事項(xiàng)列表?xiàng)l目需要立即進(jìn)行開發(fā)。排序越高,產(chǎn)品待辦事項(xiàng)列表?xiàng)l目越緊急,就越需要仔細(xì)斟酌,并且對(duì)其價(jià)值的意見越一致。排序越高的產(chǎn)品待辦事項(xiàng)列表?xiàng)l目比排序低的更清晰、更具體。根據(jù)更清晰的內(nèi)容和更詳盡的信息就能做出更準(zhǔn)確的估算。優(yōu)先級(jí)越低,細(xì)節(jié)信息越少。開發(fā)團(tuán)隊(duì)在接下來(lái)的Sprint中將要進(jìn)行開發(fā)的產(chǎn)品待辦事項(xiàng)列表?xiàng)l目是細(xì)粒度的,已經(jīng)被分解過(guò),因此,任何一個(gè)條目在Sprint的時(shí)間盒內(nèi)都可以被"完成”。開發(fā)團(tuán)隊(duì)在一個(gè)Sprint中可以"完成”的產(chǎn)品待辦事項(xiàng)列表?xiàng)l目被認(rèn)為是"準(zhǔn)備好的”或者"可執(zhí)行的”,能在Sprint計(jì)劃會(huì)議中被選擇。隨著產(chǎn)品的使用、價(jià)值的獲取以及市場(chǎng)的反饋,產(chǎn)品待辦事項(xiàng)列表變成了更大、更詳盡的列表。因?yàn)樾枨笥肋h(yuǎn)不會(huì)停止改變,所以產(chǎn)品待辦事項(xiàng)列表是個(gè)不斷更新的工件。業(yè)務(wù)需求、市場(chǎng)形勢(shì)和技術(shù)的變化都會(huì)引起產(chǎn)品待辦事項(xiàng)列表的變化。若干個(gè)Scrum團(tuán)隊(duì)常常會(huì)一起開發(fā)*個(gè)產(chǎn)品。但描述下一步產(chǎn)品開發(fā)工作的產(chǎn)品待辦事項(xiàng)列表只能有一個(gè)。則這就需要使用對(duì)產(chǎn)品待辦事項(xiàng)列表?xiàng)l目進(jìn)行分組的屬性。通過(guò)產(chǎn)品Backlog地梳理來(lái)增添細(xì)節(jié)、估算和排序。這是一個(gè)持續(xù)不斷的過(guò)程,產(chǎn)品負(fù)責(zé)人和開發(fā)團(tuán)隊(duì)協(xié)作討論產(chǎn)品代表事項(xiàng)列表?xiàng)l目的細(xì)節(jié)。在產(chǎn)品待辦事項(xiàng)列表梳理的時(shí)候,條目會(huì)被評(píng)審和修改。然而,產(chǎn)品負(fù)責(zé)人可以隨時(shí)更新產(chǎn)品代辦事項(xiàng)列表?xiàng)l目或酌情決定。梳理在Sprint中是一項(xiàng)兼職活動(dòng),在產(chǎn)品負(fù)責(zé)人和開發(fā)團(tuán)隊(duì)之間展開。通常,開發(fā)團(tuán)隊(duì)有自行優(yōu)化的領(lǐng)域知識(shí)。然而,何時(shí)如何完成優(yōu)化是Scrum團(tuán)隊(duì)的決定。優(yōu)化通常占用不超過(guò)開發(fā)團(tuán)隊(duì)10%的時(shí)間。開發(fā)團(tuán)隊(duì)負(fù)責(zé)所有的估算工作。產(chǎn)品負(fù)責(zé)人可以通過(guò)協(xié)助團(tuán)隊(duì)權(quán)衡取舍來(lái)影響他們的決定。但是,最后的估算是由執(zhí)行工作的人來(lái)決定的。監(jiān)控向目標(biāo)前進(jìn)的進(jìn)度在任何時(shí)間,達(dá)成目標(biāo)的剩余工作量是可以被累計(jì)的。產(chǎn)品負(fù)責(zé)人至少在每個(gè)Sprint評(píng)審的時(shí)候追蹤剩余工作總量。產(chǎn)品負(fù)責(zé)人把這個(gè)數(shù)量與之前Sprint評(píng)審時(shí)的剩余工作量做比較,來(lái)評(píng)估在希望的時(shí)間點(diǎn)完成預(yù)計(jì)工作達(dá)成目標(biāo)的進(jìn)度。這份信息對(duì)所有的干系人都透明。Scrum不考慮已經(jīng)花在產(chǎn)品代辦事項(xiàng)列表?xiàng)l目上的工作時(shí)間。我們只關(guān)心剩余工作和日期這兩個(gè)變量。各種趨勢(shì)燃盡圖、燃燒圖和其他計(jì)劃實(shí)踐都能用來(lái)預(yù)測(cè)進(jìn)度。它們已經(jīng)被證實(shí)有用。然而,這并不能代替經(jīng)驗(yàn)主義的重要性。在復(fù)雜的環(huán)境下,將要發(fā)生的東西是未知的,只有已經(jīng)發(fā)生的事情才能用來(lái)做前瞻式的決策。SPRINTBACKLOGSprint代辦事項(xiàng)列表是一組為當(dāng)前Sprint選出的產(chǎn)品代辦事項(xiàng)列表?xiàng)l目,外加交付產(chǎn)品增量和實(shí)現(xiàn)Sprint目標(biāo)的計(jì)劃。Sprint代辦事項(xiàng)列表是開發(fā)團(tuán)隊(duì)對(duì)于哪些功能要包含在下個(gè)增量中,以及交付那些功能所需工作的預(yù)計(jì)。Sprint代辦事項(xiàng)列表定義了開發(fā)團(tuán)隊(duì)把產(chǎn)品代辦事項(xiàng)列表?xiàng)l目轉(zhuǎn)換成"完成”的增量所需要執(zhí)行的工作。Sprint代辦事項(xiàng)列表使開發(fā)團(tuán)隊(duì)確定的、達(dá)到Sprint目標(biāo)所需的工作清晰可見。Sprint代辦事項(xiàng)列表是一份足夠具體的計(jì)劃,使得進(jìn)度上的改變能在每日例會(huì)中得到理解。開發(fā)團(tuán)隊(duì)在整個(gè)Sprint中都會(huì)修改Sprint代辦事項(xiàng)列表,Sprint代辦事項(xiàng)列表也會(huì)在Sprint的進(jìn)程中慢慢顯現(xiàn),比如開發(fā)團(tuán)隊(duì)按照計(jì)劃工作并對(duì)完成Sprint目標(biāo)所需的工作有更多的了解。當(dāng)出現(xiàn)新工作時(shí),開發(fā)團(tuán)隊(duì)需要將其追加到Sprint待辦事項(xiàng)列表中去。隨著任務(wù)進(jìn)行或者被完成,需要更新每項(xiàng)任務(wù)的估算剩余工作量。如果計(jì)劃中*個(gè)部分失去開發(fā)的意義,就可以將其除去。在Sprint內(nèi)只有開發(fā)團(tuán)隊(duì)可以對(duì)Sprint待辦事項(xiàng)列表進(jìn)行修改。Sprint待辦事項(xiàng)列表是高度可見的,是對(duì)團(tuán)隊(duì)計(jì)劃在當(dāng)前Sprint內(nèi)完成工作的實(shí)時(shí)反映,并且,該列表只屬于開發(fā)團(tuán)隊(duì)。ProductBacklog功能點(diǎn)被放到Sprint的固定周期中,SprintBacklog會(huì)因?yàn)槿缦略虬l(fā)生變化:1.隨著時(shí)間的變化,開發(fā)團(tuán)隊(duì)對(duì)于需求有了更好的理解,有可能發(fā)現(xiàn)需要增加一些新的任務(wù)到SprintBacklog中。2.程序缺陷做為新的任務(wù)加進(jìn)來(lái),這個(gè)都做為承諾提交任務(wù)中未完成的工作。ProductOwner也許會(huì)和Scrumteam一起工作,以幫助team更好的理解Sprint的目標(biāo),ScrumMaster和team也許會(huì)覺得小的調(diào)整不會(huì)影響sprint的進(jìn)度,但會(huì)給客戶帶來(lái)更多商業(yè)價(jià)值。監(jiān)控Sprint進(jìn)度在Sprint中的任意時(shí)間點(diǎn),Sprint待辦事項(xiàng)列表的所有剩余工作總和都可以被計(jì)算。開發(fā)團(tuán)隊(duì)至少在每日例會(huì)時(shí)追蹤所有的剩余工作。開發(fā)團(tuán)隊(duì)每天追蹤剩余總和并預(yù)測(cè)達(dá)成Sprint目標(biāo)的可能性。通過(guò)在Sprint中不斷追蹤剩余工作,開發(fā)團(tuán)隊(duì)可以管理自己的進(jìn)度。Scrum不考慮已經(jīng)花在Sprint待辦事項(xiàng)列表上的工作時(shí)間。我們只關(guān)心剩余工作和日期這兩個(gè)變量。燃盡圖(BURN-DOWNCHART)Sprint燃盡圖(SprintBurn-downChart)SprintBurndownChart顯示了Sprint中累積剩余的工作量,它是一個(gè)反映工作量完成狀況的趨勢(shì)圖。圖中Y軸代表的是剩余工作量,*軸代表的是Sprint的工作日。在Sprint開始的時(shí)候,ScrumTeam會(huì)標(biāo)示和估計(jì)在這個(gè)Sprint需要完成的詳細(xì)的任務(wù)。所有這個(gè)Sprint中需要完成,但沒(méi)有完成的任務(wù)的工作量是累積工作量,團(tuán)隊(duì)會(huì)根據(jù)進(jìn)展情況每天更新累積工作量,如果在Sprint結(jié)束時(shí),累積工作量降低到0,Sprint就成功結(jié)束。由于在Sprint的剛開始的時(shí)候,增加的任務(wù)工作量可能大于完成的任務(wù)工作量,所以燃盡圖有可能略微呈上升趨勢(shì)。發(fā)布燃盡圖(ReleaseBurn-downChart)在Scrum項(xiàng)目中,團(tuán)隊(duì)通過(guò)每個(gè)Sprint結(jié)束時(shí)更新的發(fā)布燃盡圖來(lái)跟蹤整個(gè)發(fā)布計(jì)劃的進(jìn)展。發(fā)布燃盡圖記錄了在一段時(shí)間內(nèi)產(chǎn)品Backlog的總剩余估算工作量的變化趨勢(shì)。*軸代表的項(xiàng)目周期,以Sprint為單位,Y軸代表的是剩余工作量,通常以用戶故事點(diǎn)、理想人天或者team-days為單位。SCRUM的五個(gè)活動(dòng)Scrum活動(dòng):產(chǎn)品待辦事項(xiàng)列表梳理產(chǎn)品待辦事項(xiàng)通常會(huì)很大,也很寬泛,而且想法會(huì)變來(lái)變?nèi)ァ?yōu)先級(jí)也會(huì)變化,所以產(chǎn)品待辦事項(xiàng)列表梳理是一個(gè)貫穿整個(gè)Scrum項(xiàng)目始終的活動(dòng)。該活動(dòng)包含但不限于以下的內(nèi)容:保持產(chǎn)品待辦事項(xiàng)列表有序把看起來(lái)不再重要的事項(xiàng)移除或者降級(jí)增加或提升涌現(xiàn)出來(lái)的或變得更重要的事項(xiàng)將事項(xiàng)分解成更小的事項(xiàng)將事項(xiàng)歸并為更大的事項(xiàng)對(duì)事項(xiàng)進(jìn)行估算產(chǎn)品待辦事項(xiàng)列表梳理的一個(gè)最大好處是為即將到來(lái)的幾個(gè)Sprint做準(zhǔn)備。為此,梳理時(shí)會(huì)特別關(guān)注那些即將被實(shí)現(xiàn)的事項(xiàng)。需要考慮不少因素,這包括但不限于以下的內(nèi)容:理想情況下,下一個(gè)Sprint的備選事項(xiàng)都應(yīng)該提升"商業(yè)價(jià)值”。開發(fā)團(tuán)隊(duì)需要能夠在一個(gè)Sprint內(nèi)完成每一個(gè)事項(xiàng)。每個(gè)人都需要清楚預(yù)期產(chǎn)出是什么。產(chǎn)品開發(fā)決定了,有可能需要其它的技能和輸入。因此,產(chǎn)品待辦事項(xiàng)列表梳理最好是所有團(tuán)隊(duì)成員都參與的活動(dòng),而不單單是產(chǎn)品負(fù)責(zé)人。Scrum活動(dòng):Sprint計(jì)劃會(huì)議每個(gè)Sprint都以Sprint計(jì)劃會(huì)議作為開始,這是一個(gè)固定時(shí)長(zhǎng)的會(huì)議,在這個(gè)會(huì)議中,Scrum團(tuán)隊(duì)共同選擇和理解在即將到來(lái)的Sprint中要完成的工作。整個(gè)團(tuán)隊(duì)都要參加Sprint計(jì)劃會(huì)議。針對(duì)排好序的產(chǎn)品待辦事項(xiàng)列表(ProductBacklog),產(chǎn)品負(fù)責(zé)人和開發(fā)團(tuán)隊(duì)成員討論每個(gè)事項(xiàng),并對(duì)該事項(xiàng)達(dá)成共識(shí),包括根據(jù)當(dāng)前的"完成的定義”,為了完成該事項(xiàng)所需要完成的所有事情。所有的Scrum會(huì)議都是限定時(shí)的。Sprint計(jì)劃會(huì)議推薦時(shí)是Sprint中的每周對(duì)應(yīng)兩?時(shí)或者更少(譯者注:比如,一個(gè)Sprint包含2個(gè)星期,則Sprint計(jì)劃會(huì)議時(shí)長(zhǎng)應(yīng)為4個(gè)小時(shí)或者更少)。因?yàn)闀?huì)議是限制時(shí)長(zhǎng)的,Sprint計(jì)劃會(huì)議的成功?分依賴于產(chǎn)品待辦事項(xiàng)列表的質(zhì)量。這就是產(chǎn)品待辦事項(xiàng)列表梳理十分重要的原因。在Scrum中,Sprint計(jì)劃會(huì)議有兩部分:決定在Sprint中需要完成哪些工作決定這些工作如何完成第一部分:需要完成哪些工作"在會(huì)議的第一部分,產(chǎn)品負(fù)責(zé)人向開發(fā)團(tuán)隊(duì)介紹排好序的產(chǎn)品待辦事項(xiàng),整個(gè)Scrum團(tuán)隊(duì)共同理解這些工作。Sprint中需要完成的產(chǎn)品待辦事項(xiàng)數(shù)目完全由開發(fā)團(tuán)隊(duì)決定。為了決定做多少,開發(fā)團(tuán)隊(duì)需要考慮當(dāng)前產(chǎn)品增量的狀態(tài),團(tuán)隊(duì)過(guò)去的工作情況,團(tuán)隊(duì)當(dāng)前的生產(chǎn)能力,以及排好序的產(chǎn)品待辦事項(xiàng)列表。做多少工作只能由開發(fā)團(tuán)隊(duì)決定。產(chǎn)品負(fù)責(zé)人或任何其它人,都不能給開發(fā)團(tuán)隊(duì)強(qiáng)加更多的工作量。通常Sprint都有個(gè)目標(biāo),稱作Sprint目標(biāo)。這將十分有效地幫助大家更加專注于需要完成的工作的本質(zhì),而不必花太多精力去關(guān)注那些對(duì)于我們需要完成的工作并不重要的?小細(xì)節(jié)。第二部分:如何完成工作"在會(huì)議的第二部分?里,開發(fā)團(tuán)隊(duì)需要根據(jù)當(dāng)前的"完成的定義”一起決定如何實(shí)現(xiàn)下一個(gè)產(chǎn)品增量。他們進(jìn)?行?足夠的設(shè)計(jì)和計(jì)劃,從而有信心可以在Sprint中完成所有工作。頭幾天的工作會(huì)被分解成?小的單元,每個(gè)工作單元不超過(guò)一天。之后要完成的工作可以稍?大些,以后再對(duì)它們進(jìn)?行分解。決定如何完成工作是開發(fā)團(tuán)隊(duì)的職責(zé),決定做什么則是產(chǎn)品負(fù)責(zé)人的職責(zé)。在計(jì)劃會(huì)議的第二部分,產(chǎn)品負(fù)責(zé)人可以繼續(xù)留下來(lái)回答問(wèn)題,以及澄清一些誤解。不管怎樣,團(tuán)隊(duì)?wèi)?yīng)該很容易找到產(chǎn)品負(fù)責(zé)人。Sprint計(jì)劃會(huì)議的產(chǎn)出Sprint計(jì)劃會(huì)議最終需要Scrum團(tuán)隊(duì)對(duì)Sprint需要完成工作的數(shù)量和復(fù)雜度達(dá)成共識(shí),并預(yù)期在一個(gè)合理的條件范圍內(nèi)完成它們。開發(fā)團(tuán)隊(duì)預(yù)測(cè)并共同承諾他們要完成的工作量??偠?言之:在Sprint計(jì)劃會(huì)議中,開發(fā)團(tuán)隊(duì)和產(chǎn)品負(fù)責(zé)人一起考慮并討論產(chǎn)品待辦事項(xiàng),確保他們對(duì)這些事項(xiàng)的理解,選擇一些他們預(yù)測(cè)能完成的事項(xiàng),創(chuàng)建足夠詳細(xì)的計(jì)劃來(lái)確保他們能夠完成這些事項(xiàng)。最終產(chǎn)生的待辦事項(xiàng)列表就是"Sprint待辦事項(xiàng)列表(SprintBacklog)”。Scrum活動(dòng):每日Scrum會(huì)議開發(fā)團(tuán)隊(duì)是自組織的。開發(fā)團(tuán)隊(duì)通過(guò)每日Scrum會(huì)議來(lái)確認(rèn)他們?nèi)匀豢梢詫?shí)現(xiàn)Sprint的目標(biāo)。這個(gè)會(huì)議每天在同樣的時(shí)間和同樣的地點(diǎn)召開。每一個(gè)開發(fā)團(tuán)隊(duì)成員需要提供以下三點(diǎn)信息:從上一個(gè)每日Scrum到現(xiàn)在,我完成了什么;從現(xiàn)在到下一個(gè)每日Scrum,我計(jì)劃完成什么;有什么阻礙了我的進(jìn)展。每日Scrum中可能有簡(jiǎn)要的問(wèn)題澄清和回答,但是不應(yīng)該有任何話題的討論。通常,許多團(tuán)隊(duì)會(huì)在每日Scrum之后?馬上開會(huì)處理他們遇到的任何問(wèn)題。每日Scrum既不是向管理層匯報(bào),也不是向產(chǎn)品負(fù)責(zé)?人或者ScrumMaster匯報(bào)。它是一個(gè)開發(fā)團(tuán)隊(duì)內(nèi)部的溝通會(huì)議,來(lái)保證他們對(duì)現(xiàn)狀有一致的了解。只有Scrum團(tuán)隊(duì)的成員,包括ScrumMaster和產(chǎn)品負(fù)責(zé)?人,可以在會(huì)議中發(fā)?言。其他感興趣的?人可以來(lái)旁聽。在必要時(shí),開發(fā)團(tuán)隊(duì)會(huì)基于會(huì)議中的發(fā)現(xiàn)重新組織他們的工作來(lái)完成Sprint的??目標(biāo)。每日Scrum是Scrum的一個(gè)關(guān)鍵組成部分,它可以帶來(lái)透明性,信任和更好的績(jī)效。它能幫助快速發(fā)現(xiàn)問(wèn)題,并促進(jìn)團(tuán)隊(duì)的自組織和自?立。所有Scrum會(huì)議都是限定時(shí)長(zhǎng)的。每日Scrum通常不超過(guò)15分鐘。Scrum活動(dòng):Sprint評(píng)審會(huì)議Sprint結(jié)束時(shí),Scrum團(tuán)隊(duì)和相關(guān)?人員一起評(píng)審Sprint的產(chǎn)出。所有Scrum會(huì)議都是限定時(shí)長(zhǎng)的,Sprint評(píng)審會(huì)議的推薦時(shí)長(zhǎng)是Sprint中的每一周對(duì)應(yīng)一個(gè)小時(shí)(譯者注:?比如,一個(gè)Sprint包含2個(gè)星期,則Sprint評(píng)審會(huì)議時(shí)長(zhǎng)為2個(gè)小時(shí))。討論圍繞著Sprint中完成的產(chǎn)品增量。由于Sprint的產(chǎn)出會(huì)涉及到一些?人的"利益”,因此一個(gè)明智的做法是邀請(qǐng)他們參加這個(gè)會(huì)議,這會(huì)很有幫助。這個(gè)會(huì)議是個(gè)?非正式的會(huì)議,幫助?大家了解我們??目前進(jìn)展到哪?里,并一起討論我們下一步如何推進(jìn)。每個(gè)?人都可以在Sprint評(píng)審會(huì)議上發(fā)表意?見。當(dāng)然,產(chǎn)品負(fù)責(zé)?人會(huì)對(duì)未來(lái)做出最終的決定,并適當(dāng)?shù)卣{(diào)整產(chǎn)品待辦事項(xiàng)列表(ProductBacklog)。團(tuán)隊(duì)會(huì)找到他們自己的方式來(lái)開Sprint評(píng)審會(huì)議。通常會(huì)演?示產(chǎn)品增量,整個(gè)小組也會(huì)經(jīng)常討論他們?cè)赟print中觀察到了什么、有哪些新的產(chǎn)品想法出現(xiàn)。他們還會(huì)討論產(chǎn)品待辦事項(xiàng)列表的狀態(tài)、可能的完成日期以及在這些日期前能完成什么。Sprint評(píng)審會(huì)議向每個(gè)?人展?示了當(dāng)前產(chǎn)品增量的概況。因此,通常都會(huì)在Sprint評(píng)審會(huì)議中調(diào)整產(chǎn)品待辦事項(xiàng)列表。Scrum活動(dòng):Sprint回顧會(huì)議在每個(gè)Sprint結(jié)束后,Scrum團(tuán)隊(duì)會(huì)聚在一起開Sprint回顧會(huì)議,目的是回顧一下團(tuán)隊(duì)在流程人際關(guān)系以及工具方面做得如何。團(tuán)隊(duì)識(shí)別出哪些做得好,哪些做得不好,并找出潛在的改進(jìn)事項(xiàng),為將來(lái)的改進(jìn)制定計(jì)劃。所有的Scrum會(huì)議都是限定時(shí)長(zhǎng)的,Sprint回顧會(huì)議的推薦時(shí)長(zhǎng)是Sprint中的每一周對(duì)應(yīng)一個(gè)小時(shí)(譯者注:?比如,一個(gè)Sprint包含2個(gè)星期,則Sprint回顧會(huì)議時(shí)長(zhǎng)為2個(gè)小時(shí))。Scrum團(tuán)隊(duì)總是在Scrum的框架內(nèi),改進(jìn)他們自己的流程。SCRUM的五個(gè)價(jià)值觀承諾–愿意對(duì)目標(biāo)做出承諾專注–把你的心思和能力都用到你承諾的工作上去開放–Scrum把項(xiàng)目中的一切開放給每個(gè)人看尊重–每個(gè)人都有他獨(dú)特的背景和經(jīng)驗(yàn)勇氣–有勇氣做出承諾,履行承諾,接受別人的尊重SCRUM的四大支柱迭代開發(fā)在Scrum的開發(fā)模式下,我們將開發(fā)周期分成多個(gè)1-4周的迭代,每個(gè)迭代都交付一些增量的可工作的功能。迭代的長(zhǎng)度是固定的,如果我們選擇了1周的迭代,則保持它的長(zhǎng)度不要發(fā)生變化,在整個(gè)產(chǎn)品開發(fā)周期內(nèi)每個(gè)迭代都是1周的長(zhǎng)度。這里需要強(qiáng)調(diào)的是在每個(gè)迭代必須產(chǎn)出可工作的增量功能,而不是第一個(gè)迭代做需求、第二個(gè)迭代做設(shè)計(jì)、第三個(gè)迭代做代碼。增量交付增量是一個(gè)Sprint及以前所有Sprint中完成的所有產(chǎn)品代辦事項(xiàng)列表?xiàng)l目的總和。在Sprint的結(jié)尾,新的增量必須"完成”,這意味著它必須可用并且達(dá)到了Scrum團(tuán)隊(duì)"完成”的定義的標(biāo)準(zhǔn)。無(wú)論產(chǎn)品負(fù)責(zé)人是否決定真正發(fā)布它,增量必須可用。增量是從用戶的角度來(lái)描述的,它意味著從用戶的角度可工作。自組織團(tuán)隊(duì)Scrum團(tuán)隊(duì)是一個(gè)自組織的團(tuán)隊(duì),傳統(tǒng)的命令與控制式的團(tuán)隊(duì)只有執(zhí)行任務(wù)的權(quán)利,而自組織團(tuán)隊(duì)有權(quán)進(jìn)行設(shè)計(jì)、計(jì)劃和執(zhí)行任務(wù),自組織團(tuán)隊(duì)還需要自己監(jiān)督和管理他們的工程過(guò)程和進(jìn)度,自組織團(tuán)隊(duì)自己決定團(tuán)隊(duì)內(nèi)如何開展工作,決定誰(shuí)來(lái)做什么,即分工協(xié)作的方式。高優(yōu)先級(jí)的需求驅(qū)動(dòng)在Scrum中,我們使用ProductBacklog來(lái)管理需求,ProductBacklog是一個(gè)需求的清單,ProductBacklog中的需求是漸進(jìn)明細(xì)的,Backlog當(dāng)中的條目必須按照商業(yè)價(jià)值的高低排序。Scrum團(tuán)隊(duì)在開發(fā)需求的時(shí)候,從Backlog最上層的高優(yōu)先級(jí)的需求開始開發(fā)。在Scrum中,只要有足夠1-2個(gè)Sprint開發(fā)的細(xì)化了的高優(yōu)先級(jí)的需求,我們就可以啟動(dòng)Sprint了,而不必等到所有的需求都細(xì)化之后。我們可以在開發(fā)期間通過(guò)Backlog的梳理來(lái)逐步的細(xì)化需求。SCRUM團(tuán)隊(duì)在傳統(tǒng)的工作方式下,開發(fā)團(tuán)隊(duì)會(huì)有很多不同的角色,比如項(xiàng)目經(jīng)理、產(chǎn)品經(jīng)理、架構(gòu)師、設(shè)計(jì)師、用戶體驗(yàn)設(shè)計(jì)師,程序員,測(cè)試人員,DBA等等。但是,在Scrum的工作方式下,總共只有三個(gè)角色,這三個(gè)角色分別是產(chǎn)品負(fù)責(zé)人(PO),ScrumMaster和開發(fā)團(tuán)隊(duì)。我們通??梢砸詣濤堉鄣膱F(tuán)隊(duì)角色來(lái)類比Scrum的角色,劃龍舟通常有舵手、鼓手、劃槳團(tuán)隊(duì)三個(gè)角色。Scrum中的PO就是舵手的角色,他對(duì)產(chǎn)品的方向負(fù)責(zé),對(duì)產(chǎn)品的Why和What負(fù)責(zé),對(duì)產(chǎn)品的愿景,產(chǎn)品包括哪些主要的特性負(fù)責(zé)。Scrum中的ScrumMaster鼓手的角色,他幫助團(tuán)隊(duì)保持高昂的士氣,并進(jìn)行良好的協(xié)作,他是一個(gè)Scrum的專家,團(tuán)隊(duì)的教練,團(tuán)隊(duì)的服務(wù)式領(lǐng)導(dǎo)。Scrum中的團(tuán)隊(duì),對(duì)應(yīng)到龍舟賽的劃槳團(tuán)隊(duì),團(tuán)隊(duì)必須協(xié)調(diào)一致,作為一個(gè)整體前進(jìn),在這樣的環(huán)境下單打獨(dú)斗,各自為政沒(méi)有任何勝算。Scrum的開發(fā)團(tuán)隊(duì)對(duì)實(shí)現(xiàn)Sprint目標(biāo)需要做的所有事情負(fù)責(zé),包括技術(shù)方案和決策,團(tuán)隊(duì)分工(誰(shuí)做什么),執(zhí)行Sprint開發(fā)任務(wù)等,而且作為自組織的團(tuán)隊(duì),他們也對(duì)他們的工作進(jìn)度的跟蹤和管理負(fù)責(zé)。Scrum開發(fā)團(tuán)隊(duì)的主要職責(zé)包括如下五個(gè)方面:執(zhí)行Sprint梳理產(chǎn)品Backlog做Sprint計(jì)劃每天跟進(jìn)工作進(jìn)展,并對(duì)他們的工作做檢查和調(diào)整每個(gè)迭代對(duì)產(chǎn)品和團(tuán)隊(duì)的工作過(guò)程做檢查和調(diào)整開發(fā)團(tuán)隊(duì)有如下10方面的特征:自組織多元化、跨職能的完整團(tuán)隊(duì)團(tuán)隊(duì)成員符合T型技能,即一專多長(zhǎng)持續(xù)改進(jìn)最大限制的溝通透明溝通2個(gè)披薩的團(tuán)隊(duì)大小(5-9人)專注、投入按照可持續(xù)的節(jié)奏工作團(tuán)隊(duì)長(zhǎng)期存在,人員穩(wěn)定自組織團(tuán)隊(duì)什么是自組織團(tuán)隊(duì)?自組織團(tuán)隊(duì)是敏捷軟件開發(fā)的基本觀念。敏捷宣言的原則中提到:"最好的架構(gòu)、需求和設(shè)計(jì)出于自組織團(tuán)隊(duì)”。自組織團(tuán)隊(duì)也叫做自管理團(tuán)隊(duì)、或者被授權(quán)的團(tuán)隊(duì)。團(tuán)隊(duì)被授權(quán)自己管理他們的工作過(guò)程和進(jìn)度、并且團(tuán)隊(duì)決定如何完成工作。自組織團(tuán)隊(duì)和經(jīng)理領(lǐng)導(dǎo)的團(tuán)隊(duì)的區(qū)別對(duì)于經(jīng)理領(lǐng)導(dǎo)的團(tuán)隊(duì)來(lái)說(shuō),團(tuán)隊(duì)成員被分配任務(wù),團(tuán)隊(duì)成員只有執(zhí)行任務(wù)的權(quán)利。對(duì)于經(jīng)理領(lǐng)導(dǎo)的團(tuán)隊(duì)來(lái)說(shuō),管理者除了要確定目標(biāo)、方向,團(tuán)隊(duì)的上下文(組織結(jié)構(gòu)、團(tuán)隊(duì)結(jié)構(gòu)、團(tuán)隊(duì)組成),還需要監(jiān)督和管理團(tuán)隊(duì)的過(guò)程和進(jìn)度,分配任務(wù)即確定誰(shuí)做什么。這種團(tuán)隊(duì)的管理方式,更多的是命令與控制,以及微觀管理。對(duì)于自組織團(tuán)隊(duì)來(lái)說(shuō),他們擁有如下權(quán)利:團(tuán)隊(duì)決定誰(shuí)做什么,即任務(wù)的分配團(tuán)隊(duì)決定如何做,如何實(shí)現(xiàn)目標(biāo),即團(tuán)隊(duì)做技術(shù)決策團(tuán)隊(duì)需要在確保目標(biāo)的前提下制定團(tuán)隊(duì)內(nèi)的行為準(zhǔn)則團(tuán)隊(duì)有義務(wù)保持過(guò)程的透明性團(tuán)隊(duì)監(jiān)督和管理他們的過(guò)程和進(jìn)度在自組織團(tuán)隊(duì)的環(huán)境下,管理層關(guān)注在如下幾個(gè)方面:確定團(tuán)隊(duì)目標(biāo)和愿景確定團(tuán)隊(duì)上下文,組織結(jié)構(gòu)、團(tuán)隊(duì)結(jié)構(gòu)、團(tuán)隊(duì)組成提供環(huán)境和支持(安全感、良好的團(tuán)隊(duì)空間、氛圍,技能輔導(dǎo)等)授權(quán)團(tuán)隊(duì)訓(xùn)練協(xié)作對(duì)于自組織團(tuán)隊(duì)的普遍誤解:誤解1:團(tuán)隊(duì)自己決定目標(biāo)是什么;糾正:管理層決定團(tuán)隊(duì)目標(biāo)誤解2:團(tuán)隊(duì)自己決定誰(shuí)進(jìn)入團(tuán)隊(duì);糾正:管理層決定團(tuán)隊(duì)上下文誤解3:團(tuán)隊(duì)自己設(shè)計(jì)團(tuán)隊(duì)結(jié)構(gòu);糾正:管理層決定團(tuán)隊(duì)上下文誤解4:自組織團(tuán)隊(duì)不需要管理者;糾正:管理者從微觀管理轉(zhuǎn)向目標(biāo)驅(qū)動(dòng)、授權(quán)團(tuán)隊(duì)的管理方式誤解5:自組織團(tuán)隊(duì)需要員工更加主動(dòng);糾正:自組織讓團(tuán)隊(duì)更加主動(dòng),每個(gè)人都不喜歡被命令和控制,每個(gè)人期望有成就感、期望被認(rèn)可誤解6:自組織團(tuán)隊(duì)想干什么就干什么;糾正:管理層決定團(tuán)隊(duì)目標(biāo),團(tuán)隊(duì)決定如何實(shí)現(xiàn)目標(biāo)一個(gè)自組織的團(tuán)隊(duì)通常由不同職能專業(yè)、思考方式和行為模式的成員組成,也就是說(shuō)它是跨職能的團(tuán)隊(duì)。自組織的團(tuán)隊(duì)不是與生俱來(lái)的,打造一個(gè)團(tuán)隊(duì)需要一個(gè)過(guò)程,打造一個(gè)自組織團(tuán)隊(duì)也是一樣。打造自組織團(tuán)隊(duì),首先要讓團(tuán)隊(duì)需要完全自主;其次,有了自主,管理者需要引導(dǎo)團(tuán)隊(duì)持續(xù)改進(jìn),幫助團(tuán)隊(duì)持續(xù)地挑戰(zhàn)更高的目標(biāo);第三,給團(tuán)隊(duì)提供環(huán)境和支持,引導(dǎo)團(tuán)隊(duì)往正確地方向邁進(jìn)。特性團(tuán)隊(duì)如果我們的產(chǎn)品開發(fā)團(tuán)隊(duì)只有在10人以內(nèi),我們使用一個(gè)跨職能的Scrum團(tuán)隊(duì),可以很容易地按照scrum和敏捷的方式開發(fā)產(chǎn)品。但是,如果產(chǎn)品團(tuán)隊(duì)規(guī)模較大,比如是幾十人,甚至幾百人的開發(fā)團(tuán)隊(duì)的時(shí)候,我們就需要考慮團(tuán)隊(duì)的結(jié)構(gòu)和組織方式。在一個(gè)大的開發(fā)組織中,Scrum會(huì)把大的開發(fā)團(tuán)隊(duì)劃分成多個(gè)5-9人的小團(tuán)隊(duì),則我們應(yīng)該按照什么方式來(lái)劃分呢?在傳統(tǒng)的開發(fā)模式下,我們習(xí)慣于按照系統(tǒng)的架構(gòu)模塊,或者系統(tǒng)分層組織團(tuán)隊(duì),也有的團(tuán)隊(duì)按照系統(tǒng)需求、開發(fā)、測(cè)試結(jié)合系統(tǒng)架構(gòu)混合組織的方式。這種團(tuán)隊(duì)組織的方式,我們稱之為組件團(tuán)隊(duì),是指每個(gè)團(tuán)隊(duì)只是完成系統(tǒng)功能的*一個(gè)部件,而不是一個(gè)端到端用戶可見的功能。組件團(tuán)隊(duì)看起來(lái)像這個(gè)樣子:按照Scrum和敏捷的交付模式,組件團(tuán)隊(duì)有如下一些限制:第一:按照組件來(lái)組織團(tuán)隊(duì),很難避免團(tuán)隊(duì)之間的依賴,跨團(tuán)隊(duì)的協(xié)調(diào)和依賴管理更加復(fù)雜,不利于跨組件或者各個(gè)層之間的溝通。第二:每個(gè)團(tuán)隊(duì)專注在自己的模塊,由于各模塊、或分層需求工作量的不同,很容易產(chǎn)生等待,并且容易產(chǎn)生低價(jià)值的交付。第三:由于職責(zé)單一,限制了學(xué)習(xí),使得專業(yè)更加單一化第四:Sprint結(jié)束的時(shí)候無(wú)法提交可交付的增量產(chǎn)品功能,延遲價(jià)值交付按照Scrum和敏捷的交付模式,以用戶為中心,按照用戶場(chǎng)景作為邊界來(lái)組織團(tuán)隊(duì)是比較推薦的做法。這種以用戶為中心的團(tuán)隊(duì)叫做特性團(tuán)隊(duì)。特性團(tuán)隊(duì)的特點(diǎn):長(zhǎng)期穩(wěn)定的團(tuán)隊(duì),逐個(gè)端到端完成客戶特性以客戶為中心的特性驅(qū)動(dòng)跨職能、完整團(tuán)隊(duì)共享代碼庫(kù),統(tǒng)一的持續(xù)集成擁有通用型專家特性團(tuán)隊(duì)看起來(lái)像這個(gè)樣子:特性團(tuán)隊(duì)的好處:團(tuán)隊(duì)內(nèi)可以做到端到端,所以減少了等待,周期加快比較容易在一個(gè)Sprint中交付可用的產(chǎn)品增量減少了團(tuán)隊(duì)之間依賴,計(jì)劃會(huì)更容易責(zé)任范圍的擴(kuò)大,各種不同領(lǐng)域的專家在一個(gè)團(tuán)隊(duì),增加了個(gè)人學(xué)習(xí)和團(tuán)隊(duì)學(xué)習(xí)的機(jī)會(huì)用戶故事什么是用戶故事?用戶故事是從用戶的角度來(lái)描述用戶渴望得到的功能。一個(gè)好的用戶故事包括三個(gè)要素:1.角色:誰(shuí)要使用這個(gè)功能。2.活動(dòng):需要完成什么樣的功能。3.商業(yè)價(jià)值:為什么需要這個(gè)功能,這個(gè)功能帶來(lái)什么樣的價(jià)值。用戶故事通常按照如下的格式來(lái)表達(dá):英文:Asa,Iwantto,sothat.中文:作為一個(gè)<角色>,我想要<活動(dòng)>,以便于<商業(yè)價(jià)值>舉例:作為一個(gè)"網(wǎng)站管理員”,我想要"統(tǒng)計(jì)每天有多少人訪問(wèn)了我的網(wǎng)站”,以便于"我的贊助商了解我的網(wǎng)站會(huì)給他們帶來(lái)什么收益?!毙枰⒁獾氖怯脩艄适虏荒軌蚴褂眉夹g(shù)語(yǔ)言來(lái)描述,要使用用戶可以理解的業(yè)務(wù)語(yǔ)言來(lái)描述。RonJeffries的3個(gè)C關(guān)于用戶故事,RonJeffries用3個(gè)C來(lái)描述它:卡片(Card)–用戶故事一般寫在小的記事卡片上。卡片上可能會(huì)寫上故事的簡(jiǎn)短描述,工作量估算等。交談(Conversation)-用戶故事背后的細(xì)節(jié)來(lái)源于和客戶或者產(chǎn)品負(fù)責(zé)人的交流溝通。確認(rèn)(Confirmation)-通過(guò)驗(yàn)收測(cè)試確認(rèn)用戶故事被正確完成。用戶故事的六個(gè)特性-INVESTINVEST=Independent,Negotiable,Valuable,Estimable,Small,Testable一個(gè)好的用戶故事應(yīng)該遵循INVEST原則,分別如下:獨(dú)立性(Independent)—要盡可能的讓一個(gè)用戶故事獨(dú)立于其他的用戶故事。用戶故事之間的依賴使得制定計(jì)劃,確定優(yōu)先級(jí),工作量估算都變得很困難。通常我們可以通過(guò)組合用戶故事和分解用戶故事來(lái)減少依賴性??蓞f(xié)商性(Negotiable)—一個(gè)用戶故事的內(nèi)容要是可以協(xié)商的,用戶故事不是合同。一個(gè)用戶故事卡片上只是對(duì)用戶故事的一個(gè)簡(jiǎn)短的描述,不包括太多的細(xì)節(jié)。具體的細(xì)節(jié)在溝通階段產(chǎn)出。一個(gè)用戶故事卡帶有了太多的細(xì)節(jié),實(shí)際上限制了和用戶的溝通。有價(jià)值(Valuable)—每個(gè)故事必須對(duì)客戶具有價(jià)值(無(wú)論是用戶還是購(gòu)買方)。一個(gè)讓用戶故事有價(jià)值的好方法是讓客戶來(lái)寫下它們。一旦一個(gè)客戶意識(shí)到這是一個(gè)用戶故事并不是一個(gè)契約而且可以進(jìn)行協(xié)商的時(shí)候,他們將非常樂(lè)意寫下故事??晒浪阈裕‥stimable)—開發(fā)團(tuán)隊(duì)需要去估計(jì)一個(gè)用戶故事以便確定優(yōu)先級(jí),工作量,安排計(jì)劃。但是讓開發(fā)者難以估計(jì)故事的問(wèn)題來(lái)自:對(duì)于領(lǐng)域知識(shí)的缺乏(這種情況下需要更多的溝通),或者故事太大了(這時(shí)需要把故事切分成小些的)。短小(Small)—一個(gè)好的故事在工作量上要盡量短小,最好不要超過(guò)10個(gè)理想人/天的工作量,至少要確保的是在一個(gè)迭代或Sprint中能夠完成。用戶故事越大,在安排計(jì)劃,工作量估算等方面的風(fēng)險(xiǎn)就會(huì)越大??蓽y(cè)試性(Testable)—一個(gè)用戶故事要是可以測(cè)試的,以便于確認(rèn)它是可以完成的。如果一個(gè)用戶故事不能夠測(cè)試,則你就無(wú)法知道它什么時(shí)候可以完成。一個(gè)不可測(cè)試的用戶故事例子:軟件應(yīng)該是易于使用的。敏捷估算無(wú)論是團(tuán)隊(duì)研發(fā)一款產(chǎn)品或者開發(fā)*一個(gè)項(xiàng)目,我們都需要回答"我們大概什么時(shí)間能夠完成?”,或者到*一個(gè)時(shí)間點(diǎn),我們能夠做到什么程度,因此和傳統(tǒng)的開發(fā)模式一樣,我們?cè)诠ぷ鏖_始之前需要對(duì)我們需要做的事情進(jìn)行工作量的估算。相對(duì)與傳統(tǒng)的工作量估算方式,敏捷估算有如下幾個(gè)特點(diǎn):團(tuán)隊(duì)集體估算在Scrum的開發(fā)過(guò)程中,團(tuán)隊(duì)共擔(dān)責(zé)任,集體承諾每個(gè)Sprint的工作,因此對(duì)于工作量的估算敏捷團(tuán)隊(duì)采用集體估算的方式。集體估算,通常采用估算撲克作為工具,團(tuán)隊(duì)通過(guò)玩估算游戲進(jìn)行集體估算。使用估算撲克來(lái)做工作量估算是最有效,也是非常有趣的一種估算方式。估算撲克由一組類似斐波納契數(shù)列的數(shù)字組成,這些數(shù)字包括:0,0.5,1,2,3,5,8,20,40,",∞,每幅撲克有四組這樣的數(shù)字,可供4個(gè)人使用。估算撲克的使用方法:每個(gè)團(tuán)隊(duì)成員拿到一組卡片,包括0,0.5,1,2,3,5,8,13,20,40,",∞,共計(jì)12張。產(chǎn)品負(fù)責(zé)人或者一名團(tuán)隊(duì)成員扮演閱讀者的角色,他負(fù)責(zé)閱讀需要估算產(chǎn)品Backlog的條目,并且詢問(wèn)大家是否有疑問(wèn)。團(tuán)隊(duì)討論這個(gè)條目。當(dāng)團(tuán)隊(duì)理解了這個(gè)條目之后,每個(gè)團(tuán)隊(duì)成員按照自己的想法給出估算結(jié)果,并且選擇對(duì)應(yīng)的撲克出牌,估算結(jié)果不能告訴其他人,出牌時(shí)數(shù)字朝下扣在桌面上。所有人都出牌之后,閱讀者向大家確認(rèn)是否都已經(jīng)確定估算結(jié)果,確認(rèn)后,數(shù)”1,2,3″,大家同時(shí)展示估算結(jié)果。團(tuán)隊(duì)評(píng)估不同的估算結(jié)果.我們是否想法一致?我們是否存在分歧?有沒(méi)有什么是我沒(méi)有考慮到的?討論之后可以再估算一輪,最終團(tuán)隊(duì)需要達(dá)成一致?;氐降诙?,開始估算下一個(gè)條目。關(guān)注Scrum中文網(wǎng)微信公眾號(hào)可以獲得微信版估算撲克。2.估算大小,而不是估算時(shí)間周期,使用相對(duì)估算,而不是絕對(duì)估算一瓶礦泉水,讓一個(gè)3歲的小妹妹把它喝完所花的時(shí)間和一個(gè)成年人把它喝完所花的時(shí)間肯定不一樣,因此同一項(xiàng)工作,不同能力的人完成它花費(fèi)的時(shí)間顯然是不一樣的。如果我們要估算從家到公司的絕對(duì)距離時(shí)多少公里,您可能不一定知道,但是如果您時(shí)做地鐵上班,從家里到公司有多少站,你一定很容易知道,當(dāng)我們知道有多少站之后,我們就可以大概清楚路上需要花多長(zhǎng)時(shí)間了。敏捷估算時(shí),我們不會(huì)估算絕對(duì)時(shí)間和周期,我們估算大小,和相對(duì)值,也就是倍數(shù)。敏捷估算時(shí),我們使用故事點(diǎn)作為計(jì)量單位,它是一個(gè)倍數(shù),我們會(huì)先找一個(gè)我們認(rèn)為最小的一個(gè)功能的大小作為參考基準(zhǔn),定義為1個(gè)故事點(diǎn),把其它的故事和它做比較,如果是2倍大小,就是2個(gè)故事點(diǎn),如果是5倍大小,就是5個(gè)故事點(diǎn)。3.記錄每個(gè)Sprint的團(tuán)隊(duì)速度團(tuán)隊(duì)速率是一個(gè)Scrum團(tuán)隊(duì)在一個(gè)Sprint中實(shí)際完成的故事點(diǎn)數(shù),通過(guò)團(tuán)隊(duì)速率可以知道團(tuán)隊(duì)做的有多快。新開始的項(xiàng)目或產(chǎn)品開發(fā),或者是新團(tuán)隊(duì),沒(méi)有初始速度,我們可以做1-2個(gè)Sprint測(cè)算一個(gè)速度,作為初始速度。在Sprint執(zhí)行過(guò)程中,我們要記錄每個(gè)Sprint的速度,為以后的計(jì)劃做參考。我們估算了產(chǎn)品Backlog的故事點(diǎn)總數(shù),然后又知道了每個(gè)Sprint團(tuán)隊(duì)的平均速度,則我們就可以推算我們大概需要多少個(gè)Sprint可以做完,這樣我們就得到了周期。SpringScrum是一種迭代和增量式的產(chǎn)品開發(fā)方法,Scrum通過(guò)Sprint來(lái)實(shí)現(xiàn)迭代。一個(gè)Sprint是指一個(gè)1周-4周的迭代,它是一個(gè)時(shí)間盒。Sprint的長(zhǎng)度一旦確定,保持不變。Sprint的產(chǎn)出是"完成”的、可用的、潛在可發(fā)布的產(chǎn)品增量。Sprint在整個(gè)開發(fā)過(guò)程中的周期一致。新的Sprint在上一個(gè)Sprint完成之后立即開始。Sprint包含并由Sprint計(jì)劃會(huì)議、每日站會(huì)、開發(fā)工作、Sprint評(píng)審會(huì)議和Sprint回顧會(huì)議構(gòu)成。Scrum采用迭代增量的方式,是因?yàn)樾枨笫怯楷F(xiàn)的,我們對(duì)產(chǎn)品和需求的理解是漸進(jìn)式的,Sprint長(zhǎng)度越長(zhǎng),我們需要預(yù)測(cè)的越多,復(fù)雜度會(huì)提升、風(fēng)險(xiǎn)也會(huì)增加,所以Sprint的長(zhǎng)度最多不超過(guò)4周。越來(lái)越多的團(tuán)隊(duì)使用2周的Sprint,很多市場(chǎng)變化快、競(jìng)爭(zhēng)激烈的領(lǐng)域,比如互聯(lián)網(wǎng)和移動(dòng)互聯(lián)網(wǎng)產(chǎn)品開發(fā)團(tuán)隊(duì)也會(huì)使用1周的迭代。在Sprint進(jìn)行過(guò)程中,如下內(nèi)容不能發(fā)生變化:Sprint的目標(biāo)Sprint的質(zhì)量目標(biāo)和驗(yàn)收標(biāo)準(zhǔn)開發(fā)團(tuán)隊(duì)的組成集中優(yōu)勢(shì)兵力各個(gè)擊破在Sprint執(zhí)行的過(guò)程中,團(tuán)隊(duì)要避免一個(gè)蘿卜一個(gè)坑的工作方式,團(tuán)隊(duì)要協(xié)作,并且要集中優(yōu)勢(shì)兵力各個(gè)擊破。團(tuán)隊(duì)按照蜂擁式(Swarming)的工作方式,團(tuán)隊(duì)先集中工作在少數(shù)幾個(gè)需求上面,協(xié)作完成它們,然后在開始下一批需求。按照這樣的方式一方面可以加強(qiáng)團(tuán)隊(duì)協(xié)作,另外也有利于及早完成一些需求,讓這些需求及早驗(yàn)收。取消一個(gè)SprintSprint可以在Sprint時(shí)間盒結(jié)束之前取消。只有產(chǎn)品負(fù)責(zé)人才有取消Sprint的權(quán)力,但他做這樣的決定也可能是受到利益干系人、團(tuán)隊(duì)或是ScrumMaster的影響。如果*個(gè)Sprint的目標(biāo)過(guò)時(shí)了,則就需要取消該Sprint。比如公司的發(fā)展方向,或是市場(chǎng)、技術(shù)等情況發(fā)生了變化,這些變化都可能導(dǎo)致取消Sprint??偟膩?lái)說(shuō),如果*個(gè)Sprint對(duì)于其所在環(huán)境來(lái)說(shuō)失去了價(jià)值和意義,則它就應(yīng)該被取消。然而,因?yàn)镾print周期都較短,所以很少發(fā)生取消Sprint的情況。當(dāng)*個(gè)Sprint被取消時(shí),任何做完和"完成”的產(chǎn)品待辦事項(xiàng)列表?xiàng)l目都需要評(píng)審。假如有些條目已經(jīng)潛在可交付,那產(chǎn)品負(fù)責(zé)人就會(huì)采納它。所有未完成的條目就都要放回到產(chǎn)品待辦事項(xiàng)列表中,并重新估算?;ㄔ谒鼈兩砩系墓ぷ鲿?huì)迅速貶值,所以需要頻繁地重估。取消

溫馨提示

  • 1. 本站所有資源如無(wú)特殊說(shuō)明,都需要本地電腦安裝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ù)覽,若沒(méi)有圖紙預(yù)覽就沒(méi)有圖紙。
  • 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)論