抽空學(xué)習(xí)了下敏捷開發(fā),覺得跟自己的一些想法不謀而合,如果一個團(tuán)隊能實施scrum,那效率一定非常高,非常適合移動開發(fā),Android,IOS,WM等?。簦澹幔黹_發(fā)一個app。希望對大家也有幫助, 前期可能會覺得有點別扭,但是堅持下來,效果會非常不一樣。你會發(fā)現(xiàn),效果高很多,而且規(guī)范。 產(chǎn)品backlog是Scrum的核心,也是一切的起源。從根本上說,它就是一個需求、或故事、或特性等組成的列表,按照重要性的級別進(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è)定為1到3小時 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)率或是投入程度。 組合使用Scrum和XP 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. 驗收測試周期
解決下一個sprint和bug的沖突 “可以開始構(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ù)上個sprint的bug,所以我們會把投入程度設(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)變化 勝過 遵循計劃
|
|