一区二区三区日韩精品-日韩经典一区二区三区-五月激情综合丁香婷婷-欧美精品中文字幕专区

分享

敏捷開發(fā)Scrum 學(xué)習(xí)筆記,適于移動開發(fā)

 瞎聊瞎看 2014-11-20

         抽空學(xué)習(xí)了下敏捷開發(fā),覺得跟自己的一些想法不謀而合,如果一個團(tuán)隊能實施scrum,那效率一定非常高,非常適合移動開發(fā),Android,IOS,WM等?。簦澹幔黹_發(fā)一個app。希望對大家也有幫助,

  前期可能會覺得有點別扭,但是堅持下來,效果會非常不一樣。你會發(fā)現(xiàn),效果高很多,而且規(guī)范。

  產(chǎn)品backlogScrum的核心,也是一切的起源。從根本上說,它就是一個需求、或故事、或特性等組成的列表,按照重要性的級別進(jìn)行了排序,它里面包含的是客戶想要的東西,并用客戶的術(shù)語加以描述。

         包括以下字段:

 ID統(tǒng)一標(biāo)識符,自增長

 NAME簡短的、描述性的名稱

 Importance產(chǎn)品負(fù)責(zé)人評出一個數(shù)值,指示這個條目有多重要,比如10 – 150,分?jǐn)?shù)越高越重要。

 Initial estimate(初始估算) – 團(tuán)隊的初步估算該條目的工作日。

 How to demo簡單的測試規(guī)范,這段描述可以作為驗收測試的偽碼表示。

 Notes相關(guān)信息、解釋說明和對其它資料的引用等,一般都非常簡短。

 

為了便于產(chǎn)品負(fù)責(zé)人判斷優(yōu)先級別,我們也會在產(chǎn)品backlog中使用一些其它字段

 Track(類別) – 當(dāng)前故事的大致分類,例如后臺系統(tǒng)優(yōu)化。這樣產(chǎn)品負(fù)責(zé)人就可以很容易選出所有的優(yōu)化條目,把他們的級別都設(shè)得比較低。類似的操作執(zhí)行起來都很方便。

Components數(shù)據(jù)庫,服務(wù)器,客戶端。團(tuán)隊或者產(chǎn)品負(fù)責(zé)人可以在這里進(jìn)行標(biāo)識,以明確哪些技術(shù)組件在這個條目的實現(xiàn)中會被包含進(jìn)來。這種做法在多個Scrum團(tuán)隊協(xié)作的時候很有用比如一個后臺系統(tǒng)團(tuán)隊和一個客戶端團(tuán)隊他們很容易知道自己應(yīng)當(dāng)對哪些需求負(fù)責(zé)。

  Requestor(請求者) – 產(chǎn)品負(fù)責(zé)人可能需求記錄是哪個客戶或相關(guān)干系人最先提出了這項需求,在后續(xù)開發(fā)過程中向他提供反饋。

 

 

 

 

 

         產(chǎn)品負(fù)責(zé)人應(yīng)當(dāng)理解每個故事的含義(通常需求都是由他來編寫的,但是有的時候其他人也會添加一些請求,產(chǎn)品負(fù)責(zé)人對它們劃分先后次序)。他不需要知道每個需求具體是如何實現(xiàn)的,但是他要知道為什么這個需求會在這里。

         Sprint計劃會議非常關(guān)鍵,應(yīng)該算是Scrum中最重要的活動。要是它執(zhí)行的不好,整個sprint甚至都會被毀掉。舉辦Sprint計劃會議,是為了讓團(tuán)隊獲得足夠的信息,能夠在幾個星期內(nèi)不受干擾的工作,也是為了讓產(chǎn)品負(fù)責(zé)人能對此有充分的信心。

         Sprint計劃會議成果:

1.  Sprint目標(biāo)。

2.  團(tuán)隊成員名單(以及他們的投入程度,如果不是100%的話)

3.  Sprint backlog(Sprint中包括的需求列表)

4.  確定好sprint演示日期

5.  確定好時間地點,供舉行每日scrum會議

                           

         整個團(tuán)隊和產(chǎn)品負(fù)責(zé)人都必須參加sprint計劃會議。原因在于,每個需求都含有三個變量,它們兩兩之間都對彼此有著強(qiáng)烈依賴。

        

范圍(Scope)和重要性(Importance)由產(chǎn)品負(fù)責(zé)人設(shè)置。估算(estimate)由團(tuán)隊設(shè)置。在sprint計劃會議上,經(jīng)過團(tuán)隊和產(chǎn)品負(fù)責(zé)人面對面的對話,這三個變量會逐步得到調(diào)整優(yōu)化。會議啟動后,產(chǎn)品負(fù)責(zé)人一般會先概況一下希望在這個sprint中達(dá)成的目標(biāo),還有他認(rèn)為最重要的故事,接下來,團(tuán)隊從最重要的故事開始逐一討論每個故事,一一估算時間。

 

質(zhì)量分為內(nèi)部質(zhì)量和外部質(zhì)量

         外部質(zhì)量 是系統(tǒng)用戶可以感知的。運(yùn)行緩慢、讓人迷糊的用戶界面就屬于外部質(zhì)量低劣。

         內(nèi)部質(zhì)量 指用戶開不到的要素,它們對系統(tǒng)的可維護(hù)性有深遠(yuǎn)影響??删S護(hù)性有深遠(yuǎn)影響??删S護(hù)性包括系統(tǒng)設(shè)計的一致性、測試覆蓋率、代碼可讀性和重構(gòu)等等。

 

一般來說,系統(tǒng)內(nèi)部質(zhì)量優(yōu)秀,外部質(zhì)量仍有可能很差。而內(nèi)部質(zhì)量差的系統(tǒng),外部質(zhì)量肯定也不怎么樣。犧牲內(nèi)部質(zhì)量是一個糟糕透頂?shù)南敕ā,F(xiàn)在節(jié)省下來一點時間,接下來的日子里你就要一直為它付出代價。一旦我們放松要求,允許代碼庫中暗藏問題,后面就很難恢復(fù)質(zhì)量了。

 

 

用生產(chǎn)率計算來估算

         1.得出估算生產(chǎn)率。

         2.計算在不超出估算生產(chǎn)率的情況下可以加入多少故事。

         生產(chǎn)率是“已完成工作總量”的一個衡量方式,其中每一個需求都是用它的原始估算進(jìn)行衡量的。

下圖中,左邊是sprint啟動時的估算生產(chǎn)率,右邊是sprint結(jié)束時的實際生產(chǎn)率。每個矩形都是一個需求,里面的數(shù)字表示這個需求的原始估算。

注意,這里的實際生產(chǎn)率建立在每個故事的原始估算基礎(chǔ)之上,在sprint過程中對需求時間進(jìn)行的修改都被忽略了。敏捷軟件開發(fā)和精益制造的要求:把事情完全做完!達(dá)到可以交付的狀態(tài)!事情只做了一半,它的價值就是0(也許還會是負(fù)數(shù))。

This Sprint’s Estimated velocity:

         (Available Man-Days) * (Focus Factor) = (Estimated Velocity)

投入程度(Focus Factor)用來估算團(tuán)隊會在sprint中投入多少精力。投入程度低,就表示團(tuán)隊估計會受到很大干擾,或者他們覺得自己的時間估算太過理想化。要想得出一個合理的投入程度,最好的辦法就是看看上一個sprint的值(對前幾個sprint取平均值自然更好)

Last Sprint’s Focus Factor:

         (Focus Factor) = (Actual Velocity) / (Available Man-Days)

生產(chǎn)率計算

1,  直覺反應(yīng)、

2,  基于昨日天氣的生產(chǎn)率計算、

3,  基于可用人-天和估算投入程度的生產(chǎn)率計算

在大多數(shù)sprint計劃會議上,大家都會討論產(chǎn)品backlog中的需求細(xì)節(jié)。對故事進(jìn)行估算、重定優(yōu)先級、進(jìn)一步確認(rèn)細(xì)節(jié)、拆分,等等都會在會議上完成。

要想收到好的效果,不妨創(chuàng)建一些索引卡,把他們放到墻上(或一張大桌子上)

這種用戶體驗比計算機(jī)和投影儀好得多:

         大家站起來四處走動他們可以更長時間的保持清醒,并留心會議進(jìn)展。

         他們有更多的個人參與感(而不是只有那個拿著鍵盤的家伙才有)

         多個故事可以同時編輯。

         重新劃分優(yōu)先級變得易如反掌 挪動索引卡就行。

         會議結(jié)束后,索引卡可以拿出會議室,貼在墻上的任務(wù)板上。

把需求拆分成任務(wù)后,時間估算就變得更容易(也更精確)

 

不要讓任務(wù)拆分出現(xiàn)在產(chǎn)品backlog,原因有二:

         任務(wù)拆分的隨機(jī)性比較強(qiáng),在sprint進(jìn)行中,它們常常會發(fā)生變化,不斷調(diào)整,所以保持產(chǎn)品backlog的同步很讓人頭大。

         產(chǎn)品負(fù)責(zé)人不需要關(guān)心這種程度的細(xì)節(jié)。

 

使用計劃紙牌做時間估算

         估算是一項團(tuán)隊活動 --- 通常每個成員都會參與所有需求的估算。為啥要每個人都參加?

1,  在計劃的時候,我們一般都還不知道到底誰會來實現(xiàn)哪個需求的哪個部分。

2,  每個需求一般有好幾個人參與,也包括不同類型的專長(用戶界面設(shè)計、編程、測試、等)

3,  團(tuán)隊成員必須要對需求內(nèi)容有一定的理解才能進(jìn)行估算。要求每個人都做估算,我們就可以確保他們都理解了每個條目的內(nèi)容。這樣就為大家在sprint中相互幫助夯實了基礎(chǔ),也有助于需求中的重要問題被盡早發(fā)現(xiàn)。

4,  如果要求每個人都對需求做估算,我們就會常常發(fā)現(xiàn)兩個人對同一需求的估算結(jié)果差異很大。我們應(yīng)該盡早發(fā)現(xiàn)這種問題并就此進(jìn)行討論。

         每個人都會得到如上圖的13張卡片。在估算需求的時候,每個人都選出一張卡片來表示他的時間估算(man-day的方式表示),并把它正面朝下扣在桌上。所有人都完成以后,桌上的紙牌會被同時揭開。這樣每個人都會被迫進(jìn)行自我思考,而不是依賴于其他人估算的結(jié)果。如果在兩個估算之間有著巨大差異,團(tuán)隊就會就辭進(jìn)行討論,并試圖讓大家對需求內(nèi)容達(dá)成共識。他們也許會進(jìn)行任務(wù)分解,之后再重新估算。這樣的循環(huán)會往復(fù)進(jìn)行,知道時間估算趨于一致為止,也就是每個人對這個需求的估算都差不多相同。

         重要的是,我們必須提醒團(tuán)隊成員,他們要對這個故事中所包含的全部工作進(jìn)行估算。而不是他們自己負(fù)責(zé)的部分工作。測試人員不能只估算測試工作。

         有些卡片比較特殊:

1,  0 = “這個故事已經(jīng)完成了或者這個故事根本沒啥東西,幾分鐘就能搞定

2,  = “我一點概念都沒有,沒想法。

3,  咖啡杯 = “我太累了,先歇會吧

 

把需求拆分成任務(wù)

         故事是可以交付的東西,是產(chǎn)品負(fù)責(zé)人所關(guān)心的。任務(wù)是不可交付的東西,產(chǎn)品負(fù)責(zé)人對它也不關(guān)心。

需求拆分成更小的需求

 

 

需求拆分成任務(wù)

1,  新組建的Scrum團(tuán)隊不愿意花時間來預(yù)先把故事拆分成任務(wù)。有些人覺得這像是瀑布式的做法。

2,  有些故事,大家都理解的很清楚,那么預(yù)先拆分還是隨后拆分都一樣簡單。

3,  這種類型的拆分常常可以發(fā)現(xiàn)一些會導(dǎo)致時間估算增加的工作,最后得出的sprint計劃會更貼近現(xiàn)實。

4,  這種預(yù)先拆分可以給每日例會的效率帶來顯著提高

5,  及時拆分不夠精確,而且一旦開始具體工作,事先的拆分結(jié)果也許會發(fā)生變化,但我們依然可以得到以上種種好處。

 

最后界限在哪里

         優(yōu)先級列表:

1,  Sprint目標(biāo)和演示日期。

2,  經(jīng)過團(tuán)隊認(rèn)可、要添加到這個sprint中的需求列表。

3,  Sprint中每個需求的估算值。

4,  Sprint中每個需求的如何演示

5,  生產(chǎn)率和資源計算,用作sprint計劃的現(xiàn)實核查。包括團(tuán)隊成員的名單及每個人的承諾(不然就沒法計算生產(chǎn)率)

6,  明確每日例會固定舉行的時間地點。

7,  把需求拆分成任務(wù)。這個拆分也可以在每日例會上做,不過這回稍稍打亂sprint的流程。

技術(shù)需求:需要完成但又不屬于可交付物的東西,跟任何故事都沒有直接關(guān)聯(lián),不會給產(chǎn)品負(fù)責(zé)人帶來直接的價值。如:安裝持續(xù)構(gòu)建故武器、編寫系統(tǒng)設(shè)計概覽、重構(gòu)DAO層、

Sprint信息頁

Sprint backlog

 

 

 

 

燃盡圖

 

讓團(tuán)隊坐在一起:

            一起意味著:

1.  互相聽到:所有人都可以彼此交談,不必大聲喊,不必離開座位。

2.  互相看到:所有人都可以看到彼此,都能看到任務(wù)版

3.  隔離:如果你們整個團(tuán)隊突然站起來,自發(fā)形成一個激烈的設(shè)計討論,團(tuán)隊外的任何人都不會打擾到。

 

產(chǎn)品負(fù)責(zé)人應(yīng)該離團(tuán)隊很近,既方便團(tuán)隊成員走過來討論問題,他也能隨時踱到任務(wù)版前面去。但是他不應(yīng)該跟團(tuán)隊坐在一起。為什么?因為這樣他就無法控制自己不去關(guān)注具體細(xì)節(jié),團(tuán)隊也無法凝結(jié)成整體(即達(dá)到關(guān)系緊密、自組織、具有超高生產(chǎn)力的狀態(tài))

 

怎樣更新任務(wù)版

無論sprint backlog是什么形式,都要盡力讓整個團(tuán)隊參與到保持sprint backlog及時更新的工作中來,我們曾經(jīng)試過讓Scrum master自己維護(hù)sprint backlog,他就不得不每天都去詢問大家各自剩余的工作估算時間。這種做法的缺點是:

1.  Scrum master把太多時間用在了管理之類的工作上,而不是為團(tuán)隊提供支持,消除他們的障礙

2.  因為團(tuán)隊成員不再關(guān)心sprint backlog ,所以他們就意識不不到sprint的狀態(tài),缺少了反饋,團(tuán)隊整體的敏捷度和精力的集中程度都會下降。

如果sprint backlog設(shè)計得很好,那每個人都應(yīng)該很容易修改它。

 

 

 

怎樣進(jìn)行sprint演示

Sprint演示是Scrum中很重要的一環(huán)。一次做的不錯的演示,即使看上去很一般,也會帶來深遠(yuǎn)影響。

1.  團(tuán)隊的成果得到認(rèn)可,他們會感覺很好。

2.  其他人可以了解你的團(tuán)隊在做些什么。

3.  演示可以吸引相關(guān)干系人的注意,并得到重要反饋。

4.  演示是一種社會活動,不同的團(tuán)隊可以在這里相互交流,討論各自的工作。這很有意義。

5.  做演示會迫使團(tuán)隊真正完成一些工作,進(jìn)行發(fā)布(即使是只在測試環(huán)境中)。如果沒有演示,我們就會總是得到99%完成的工作。有了演示以后,也許我們完成的事情會變少,但它們是真正完成的。這比得到一堆貌似完成的工作要好得多,而且后者還會污染下一個sprint

Sprint演示檢查列表

1.  確保清晰闡述了Sprint目標(biāo)。如果在演示上有些人對產(chǎn)品一無所知,那就花上幾分鐘來進(jìn)行描述。

2.  不要花太多時間準(zhǔn)備演示,尤其是不要做花里胡哨的演講,把那些玩意扔一邊去,集中精力演示可以實際工作的代碼。

3.  節(jié)奏要快,也就是說要把準(zhǔn)備的經(jīng)歷放在保持演示的快節(jié)奏上,而不是讓它看上去好看

4.  讓演示關(guān)注于業(yè)務(wù)層次,不要管技術(shù)細(xì)節(jié)。注意力放在我們做了什么,而不是我們怎么做的

5.  可能的話,讓觀眾自己試一下產(chǎn)品。

6.  不要演示一大堆細(xì)碎的bug修復(fù)和微不足道的特性,你可以提到一些,但是不要演示,因為他們通常會花很長時間。而且會分散大家的注意力,讓他們不能關(guān)注更加重要的需求。

 

Scrum回顧

 回顧是Scrum中第二重要的事件(最重要的是sprint計劃會議),因為這是你做改進(jìn)的最佳時機(jī)。如果沒有回顧,團(tuán)隊就會不斷重犯同樣的錯誤。

 回顧組織:

1.  根據(jù)要討論的內(nèi)容范圍,設(shè)定為13小時

2.  參與者:產(chǎn)品負(fù)責(zé)人,整個團(tuán)隊。

3.  在不受干擾的情況下討論。

4.  一般不要在團(tuán)隊房間中進(jìn)行回顧,因為這往往會分散大家的注意力。

5.  制定某人當(dāng)秘書。

6.  Scrum master 向大家展示sprint backlog ,在團(tuán)隊的幫助下對sprint做總結(jié)。包括重要事件和決策等。

7.  輪流發(fā)言,每個人都有機(jī)會在不被人打斷的情況下講出自己的想法,他認(rèn)為什么是好的,哪些可以做的更好,哪些需要在下個sprint中改變。

8.  我們隊預(yù)估生產(chǎn)率和時機(jī)生產(chǎn)率進(jìn)行比較。如果差異比較大的話,我們會分析原因。

9.  快結(jié)束的時候,Scrum master對具體建議進(jìn)行總結(jié),得出下個sprint需要改進(jìn)的地方。

我們的回顧會議一般沒有太規(guī)整的結(jié)構(gòu),不過潛在的主題都是一樣的:我們怎樣才能在下個sprint中做的更好

Scrum回顧白板:

圖中的三列分別是:

1.  Good : 如果我們可以重做同一個sprint,哪些做法可以保持。

2.  Could have done better: 如果我們可以重做同一個sprint,哪些做法需要改變。

3.  Improvements:有關(guān)將來如何改進(jìn)的具體想法。

第一列和第二列是回顧過去,第三列是展望將來。

團(tuán)隊通過頭腦風(fēng)暴得出所有的想法,寫在即時貼上,如何用圓點投票來決定下一個sprint會著重進(jìn)行哪些改進(jìn)。每個人都有三塊小磁鐵,投票決定下個sprint所要采取措施的優(yōu)先級。他們可以隨意投票,也可以把全部三票投在一件事情上。根據(jù)投票情況,選出幾項重點進(jìn)行過程改進(jìn),在下一個回顧中,跟蹤這些改進(jìn)的執(zhí)行情況。不要想一口吃成個胖子,這一點很重要,每個sprint只關(guān)注幾個改進(jìn)就夠了。

 

定義你的驗收標(biāo)準(zhǔn)

除了普通的產(chǎn)品backlog之外,產(chǎn)品負(fù)責(zé)人還會定義一系列的驗收標(biāo)準(zhǔn),它從合同的角度將產(chǎn)品backlog中重要性級別的含義進(jìn)行了簡單分類。

驗收標(biāo)準(zhǔn)規(guī)則的例子:

1.  所有重要性>= 100的條目都必須在1.0版中發(fā)布,不然我們就會被罰款。

2.  所有重要性在50-99之間的條目應(yīng)該在1.0中發(fā)布,不過也許我們可以在緊接著的一個快速發(fā)布版中完成這些。

3.  重要性在25-49之間的條目也都是需要的,不過可以在1.1版中發(fā)布

4.  重要性<25的條目都是不確定的,也許永遠(yuǎn)不會用到。

對最重要的條目進(jìn)行時間估算

為了制定發(fā)布計劃,產(chǎn)品負(fù)責(zé)人需要進(jìn)行時間估算,至少是要估算在合同中包含的故事。跟sprint計劃會議一樣,這是產(chǎn)品負(fù)責(zé)人和團(tuán)隊協(xié)作共同完成的團(tuán)隊進(jìn)行估算,產(chǎn)品負(fù)責(zé)人描述條目內(nèi)容,回答問題。

 

 

 

統(tǒng)計一切因素,生成發(fā)布計劃

有了時間估算和生產(chǎn)率,可以很容易的把產(chǎn)品backlog拆到sprints中:

3sprints=9個星期=2個月。這是我們要向客戶許諾的最后期限么?要視合同情況,范圍限制有多嚴(yán)格,等等而定。我們通常都會增加相當(dāng)多的時間緩沖,以避免糟糕的時間估算、未預(yù)期的問題和未預(yù)期的特性等造成影響。在這種情況下,我們可能會同意把發(fā)布日期定在三個月后,讓我們保留一個月。我們可以每隔三個星期就給客戶演示一些有用的東西,并在過程中邀請他們更改需求。

 

調(diào)整發(fā)布計劃

每個sprint之后,我們都要看一下這個sprint的實際生產(chǎn)率。如果實際生產(chǎn)率跟估算生產(chǎn)率差距很大,我們就會給下面的sprint調(diào)整生產(chǎn)率,更新發(fā)布計劃。如果這會給我們帶來麻煩,產(chǎn)品負(fù)責(zé)人就會跟客戶進(jìn)行談判;或者檢查一下是否能夠在不違反合同的情況下調(diào)整范圍;或者他跟團(tuán)隊一起找出一些方法,通過消除某些在sprint中發(fā)現(xiàn)的嚴(yán)重障礙,提高生產(chǎn)率或是投入程度。

 

 

 

 

 

 

組合使用ScrumXP

Scrum注重的是管理和組織實踐,而XP關(guān)注的是實際的編程實踐。這就是為什么它們可以很好的協(xié)同工作—-- 它們解決的是不同領(lǐng)域的問題,可以互為補(bǔ)充,相得益彰。

 

結(jié)對編程

1.  結(jié)對編程可以提高代碼質(zhì)量。

2.  結(jié)對編程可以讓團(tuán)隊的精力更加集中

3.  結(jié)對編程令人精疲力竭,不能全天都這樣做。

4.  常常更換結(jié)對是有好處的。

5.  結(jié)對編程可以增進(jìn)團(tuán)隊間的知識傳播。速度快到令人難以想象。

6.  有些人就是不習(xí)慣結(jié)對編程。不要因為一個優(yōu)秀的開發(fā)人員不習(xí)慣結(jié)對編程就把他置之不理。

7.  可以把代碼審查座位結(jié)對編程的替代方案。

8.  領(lǐng)航員”(不用鍵盤的家伙)應(yīng)該自己也有一臺機(jī)器。不是用來開發(fā),而是在需要的時候稍稍做一些探索嘗試、當(dāng)司機(jī)”(使用鍵盤的家伙)、遇到難題的時候查看文檔,等等。

9.  不要強(qiáng)制大家使用結(jié)對編程。鼓勵他們,提供合適的工具,讓他們按照自己的節(jié)奏去嘗試。

測試驅(qū)動開發(fā)(TDD)

         測試驅(qū)動開發(fā)意味著你要先寫一個自動測試,然后編寫恰好夠用的代碼,讓它通過這個測試,接著對代碼進(jìn)行重構(gòu),主要是提高它的可讀性和消除重復(fù)。整理一下,然后繼續(xù)。

它會把開發(fā)-構(gòu)建-測試這三者構(gòu)成的循環(huán)變得奇快無比,同時還可以充當(dāng)一張安全網(wǎng),讓開發(fā)人員有足夠的信心頻繁重構(gòu),伴隨著系統(tǒng)的增長,設(shè)計依然可以保持整潔和簡單。

增量設(shè)計

一開始應(yīng)該保持設(shè)計簡單化,然后不斷進(jìn)行改進(jìn);而不是一開始努力保證它的正確性,然后就凍結(jié)它,不再改變。

代碼標(biāo)準(zhǔn)

絕大多數(shù)程序員都有他們自己特定的編程風(fēng)格。例如他們?nèi)绾翁幚懋惓?,如何注釋代碼,何時返回null等等。有時候這種差異沒什么關(guān)系,但在某些情況下,系統(tǒng)設(shè)計就會因此出現(xiàn)不一致的現(xiàn)象,情況嚴(yán)重,代碼也不容易看懂。這時代碼標(biāo)準(zhǔn)的用處就會凸顯,從造成影響的因素中就可以知道了。

 

 

 

在每個sprint中少做工作來提高質(zhì)量

回到sprint計劃會議上,簡單來說,就是別把太多故事都放到sprint里面去!如果碰到了質(zhì)量問題,或者驗收測試周期太長,干脆就每個sprint少干點!這會自動帶來質(zhì)量提升、驗收測試周期縮短、影響終端用戶的bug減少,并在短期內(nèi)得到更高的生產(chǎn)率,因為團(tuán)隊可以始終關(guān)注與新的東西,而不是不斷修復(fù)出現(xiàn)問題的舊功能。相對于構(gòu)建大量功能,然后不得不在驚慌失措的狀態(tài)下做熱修復(fù)來說,少構(gòu)建一些功能,但是把它弄的穩(wěn)定點兒,這樣做要合算得多。

 

Sprint周期 vs. 驗收測試周期

解決下一個sprintbug的沖突

可以開始構(gòu)建新東西,但是要給‘將舊功能產(chǎn)品化’分配高優(yōu)先級

一般我們完成一個sprint以后就會開始進(jìn)行下一個。但是我們會在接下來的sprint中花一些時間解決過往sprint中留下的bug。如果修復(fù)bug占用了太多時間,從而導(dǎo)致接下來的sprint遭到嚴(yán)重破壞,我們就會分析問題產(chǎn)生的原因以及如何提高質(zhì)量。我們會確保sprint的長度,使之足以完成對上個sprint中一定數(shù)量bug的修復(fù)。隨著時間推移,經(jīng)過幾個月以后,修復(fù)上個sprint遺留bug所有的時間久會減少。而且當(dāng)bug發(fā)生以后,所牽扯的人也更少了,所以不會總是干擾整個團(tuán)隊?,F(xiàn)在這種做法已經(jīng)的到了更多人的認(rèn)可。sprint計劃會議上,考慮到會花時間修復(fù)上個sprintbug,所以我們會把投入程度設(shè)得足夠低。

 

 

 

產(chǎn)品層次的Scrum-of-Scrums

這個會議非常重要。我們一周開一次,有時候頻率會更高。在會議上我們會討論集成問題,團(tuán)隊平衡問題,為下個sprint計劃會議做準(zhǔn)備,等等。

議程安排如下:

1.  每個人圍著桌子坐好,描述一下上周各自的團(tuán)隊都完成了什么事情,這周計劃完成什么事情,遇到了什么障礙。

2.  其他需要討論的跨團(tuán)隊的問題,例如集成。

團(tuán)體層次的Scrum-of-Scrums

會議的形式為:

1.  開發(fā)主管介紹最新情況。例如即將發(fā)生的事件信息。

2.  大循環(huán)。每個產(chǎn)品組都有一個人匯報他們上周完成的工作,這周計劃完成的工作,及碰到的問題。其他人也會作報告。

3.  其他人都可以自由補(bǔ)充任何信息,或者提問問題。

Scrum master檢查列表

         Sprint開始階段

                   Sprint計劃會議之后,創(chuàng)建Sprint信息頁面

1.  wiki上創(chuàng)建從dashboard指向所創(chuàng)建頁面的鏈接。

2.  把頁面打印出來,貼在通過團(tuán)隊工作區(qū)域之外的墻上,讓經(jīng)過的人都可以看到

給每個發(fā)郵件,聲明新的sprint已經(jīng)啟動。郵件中要包括sprint目標(biāo)和指向sprint信息頁面的鏈接。

更新sprint數(shù)據(jù)文檔。加入估算生產(chǎn)率、團(tuán)隊大小和sprint長度等等。

確保每日Scrum會議可以按時開始和結(jié)束。

為了保證sprint可以如期完成,需要適當(dāng)?shù)卦鰟h故事。確保產(chǎn)品負(fù)責(zé)人了解這些變化

確保團(tuán)隊可以及時得知Sprint backlog和燃盡圖的最新狀況。

確保存在的問題和障礙都能被解決,并報告給產(chǎn)品負(fù)責(zé)人以及開發(fā)主管。

         sprint結(jié)束時

                   進(jìn)行開放式的Sprint演示

                   在演示開始前一兩天,就要通知到每個人。

與整個團(tuán)隊以及產(chǎn)品負(fù)責(zé)人一起開Sprint回顧會議。開發(fā)主管也應(yīng)該受邀參加,他可以把你們的經(jīng)驗教訓(xùn)大范圍傳播開來。

更新sprint數(shù)據(jù)文檔。加入實際生產(chǎn)率和回顧會議中總結(jié)出的關(guān)鍵點。 

過程與工具、面面俱到的文檔、合同談判、遵循計劃

         個體與交互                勝過                 過程與工具

         可以工作的軟件            勝過         面面俱到的文檔

         客戶協(xié)作                           勝過                  合同談判

         響應(yīng)變化                           勝過                  遵循計劃

 

網(wǎng)上有個PangoScrum 現(xiàn)在能支持Android了。大家可以去看看,不開代理也能上。http://androidnewlab./

 

    本站是提供個人知識管理的網(wǎng)絡(luò)存儲空間,所有內(nèi)容均由用戶發(fā)布,不代表本站觀點。請注意甄別內(nèi)容中的聯(lián)系方式、誘導(dǎo)購買等信息,謹(jǐn)防詐騙。如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容,請點擊一鍵舉報。
    轉(zhuǎn)藏 分享 獻(xiàn)花(0

    0條評論

    發(fā)表

    請遵守用戶 評論公約

    類似文章 更多

    国产精品福利一级久久| 亚洲男人天堂成人在线视频 | 免费在线成人激情视频| 欧美国产日产综合精品| 亚洲丁香婷婷久久一区| 千仞雪下面好爽好紧好湿全文| 亚洲人午夜精品射精日韩| 日韩欧美二区中文字幕| 亚洲国产91精品视频| 日本午夜精品视频在线观看| 精品日韩av一区二区三区| 91欧美亚洲视频在线| 午夜精品一区二区三区国产| 东京热男人的天堂社区| 国产精品一区二区三区欧美| 在线观看免费午夜福利| 欧美一区二区三区性视频| 国产成人综合亚洲欧美日韩| 日本人妻中出在线观看| 粉嫩国产美女国产av| 国产av天堂一区二区三区粉嫩| 最新国产欧美精品91| 成人精品视频在线观看不卡| 日本不卡一本二本三区| 麻豆精品在线一区二区三区| 亚洲中文字幕熟女丝袜久久| 四季精品人妻av一区二区三区 | 黑色丝袜脚足国产一区二区| 日韩免费国产91在线| 不卡视频免费一区二区三区| 亚洲一区二区三区av高清| 日韩av生活片一区二区三区| 午夜福利92在线观看| 视频一区日韩经典中文字幕| 黄片在线观看一区二区三区| 国产亚洲成av人在线观看| 开心久久综合激情五月天| 国产日韩久久精品一区| 青青操视频在线播放免费| 亚洲精品av少妇在线观看| 日本欧美视频在线观看免费 |