【正文】 會(huì)的紀(jì)律會(huì)議時(shí)間最多不超過15分鐘。所有的團(tuán)隊(duì)成員自覺按時(shí)到場(chǎng)，因?yàn)闀?huì)議很短，按時(shí)召開按時(shí)結(jié)束是很重要的。團(tuán)隊(duì)需要建立他們的工作協(xié)議來確保團(tuán)隊(duì)成員按時(shí)出席，并且遵守站會(huì)紀(jì)律，比如團(tuán)隊(duì)可以商量對(duì)于遲到的人員要有一些讓他們改進(jìn)的措施，比如適當(dāng)?shù)慕o一些罰金，多少由團(tuán)隊(duì)共同決定，這些錢如何支配也由團(tuán)隊(duì)共同決定， 或者做俯臥撐、掛一個(gè)遲到的牌子等等。每日站會(huì)一定要站著開，每個(gè)人要精神集中，不能有懶散的表現(xiàn)。每個(gè)人回答三個(gè)問題：我昨天完成了什么任務(wù)？我今天打算做什么任務(wù)？我遇到了哪些障礙或困難？同一時(shí)間只能有一個(gè)人發(fā)言，會(huì)上只說和這三個(gè)問題相關(guān)的話題，任何跑題的討論，需要被ScrumMaster制止。一些的確需要討論的問題，可以先記錄下來，會(huì)后作為專題來討論。為什么每日站會(huì)沒有效果？每日站會(huì)和傳統(tǒng)的項(xiàng)目會(huì)議有如下幾點(diǎn)不同：1. 不會(huì)有ScrumMaster或者其他任何人來指派任務(wù)。2. 團(tuán)隊(duì)成員不是向ScrumMaster匯報(bào)情況，每日站會(huì)是團(tuán)隊(duì)自己的會(huì)。3. 團(tuán)隊(duì)成員不會(huì)在會(huì)上討論或者解決問題，大家會(huì)把問題記錄下來，會(huì)后找相關(guān)的人討論或召開具體的討論會(huì)議。4. 任何團(tuán)隊(duì)之外的人不得發(fā)言或干擾會(huì)議。Scrum的最基本原則是“Inspect and Adapt”(檢視然后適應(yīng))，如果什么事情做得很好，問問自己為什么，然后尋找提升的辦法。如果每日站會(huì)沒有效果，檢查一下這些規(guī)則：你是不是每天在認(rèn)真開每日站會(huì)？如果不是為什么？如果你改變了Scrum的一些基本的規(guī)則，你可能會(huì)面臨一些風(fēng)險(xiǎn)，因?yàn)檫@些規(guī)則都是經(jīng)過錘煉和項(xiàng)目考驗(yàn)的一些通用規(guī)則。所以第一步，你可以先按照書本上的方式來做。如果這還不夠，參考一下其他人的實(shí)踐經(jīng)驗(yàn)，比如：Martin Fowler’s 《Patterns of Daily Standup Meetings》你如何知道每日站會(huì)起到了很好的效果？一個(gè)好的每日站會(huì)有如下幾個(gè)特點(diǎn)：1. ScrumMaster不會(huì)逐個(gè)的問每個(gè)人問題，如果是，那么這個(gè)會(huì)議已經(jīng)淪為了報(bào)告會(huì)。2. 團(tuán)隊(duì)成員互相交流，不是向ScrumMaster報(bào)告。3. 每日站會(huì)都會(huì)在15分鐘以內(nèi)完成。如果你遵守了規(guī)則并按照正確的方式開會(huì)，你就不需要再擔(dān)心超時(shí)了。4. 站會(huì)結(jié)束后，ScrumMaster知道哪些問題需要幫助團(tuán)隊(duì)成員解決。一個(gè)自組織的團(tuán)隊(duì)有一個(gè)非常明顯的每天的節(jié)奏：Daily Scrum之前非常安靜，每日站會(huì)之后會(huì)有一段活躍的討論，到中餐前的時(shí)候就慢慢安靜下來了。午飯之后會(huì)有另外一個(gè)階段的活躍討論，當(dāng)下班前慢慢的安靜下來。這就是一個(gè)自組織團(tuán)隊(duì)的脈沖。如果你能夠感受到這個(gè)節(jié)奏，則說明團(tuán)隊(duì)是很健康的，每日站會(huì)起到了很好的效果?！巴瓿伞钡亩x當(dāng)產(chǎn)品代辦事項(xiàng)列表?xiàng)l目或者增量被描述為“完成”的時(shí)候,每個(gè)人都必須理解“完 成”意味著什么。雖然這在不同的 Scrum 團(tuán)隊(duì)之間會(huì)有巨大的差別,但是團(tuán)隊(duì)成員必須對(duì) 完成工作意味著什么有相同的理解,這樣才能保證透明性。這就是 Scrum 團(tuán)隊(duì)的“完成” 定義,用來評(píng)估產(chǎn)品增量在什么時(shí)候完成。這個(gè)定義也同時(shí)被用來指導(dǎo)開發(fā)團(tuán)隊(duì)了解在 Sprint 計(jì)劃會(huì)議的時(shí)候他們能選擇多少 產(chǎn)品代辦事項(xiàng)列表?xiàng)l目。每個(gè) Sprint 的目標(biāo)都是交付遵循 Scrum 團(tuán)隊(duì)當(dāng)前的“完成”定 義的潛在可交付功能增量。開發(fā)團(tuán)隊(duì)在每個(gè) Sprint 交付產(chǎn)品功能增量。這個(gè)增量是可用的,所以產(chǎn)品負(fù)責(zé)人可以選擇立即發(fā)布它。每個(gè)增量都附加于之前所有增量并經(jīng)過充分測(cè)試,以此保證所有的增量都能工作。隨著 Scrum 團(tuán)隊(duì)的成熟,我們預(yù)期“完成”的定義會(huì)擴(kuò)大,包含更嚴(yán)厲標(biāo)準(zhǔn)來保證高質(zhì)量。需要注意的是，如果在每個(gè)迭代，我們對(duì)“完成”的標(biāo)準(zhǔn)要求過低，那么這會(huì)導(dǎo)致在每個(gè)迭代，我們都會(huì)遺留一些完成外的工作，完成外的工作持續(xù)累計(jì)會(huì)增加項(xiàng)目的風(fēng)險(xiǎn)，有可能導(dǎo)致產(chǎn)品負(fù)責(zé)人決定發(fā)布的時(shí)候，產(chǎn)品卻因?yàn)槔鄯e了過多的完成外的工作而無法發(fā)布，以致于我們還需要一個(gè)額外的Sprint來使它穩(wěn)定。SCRUM MASTER檢查單一位合格的ScrumMaster通常能夠同時(shí)處理2到3個(gè)團(tuán)隊(duì)的事務(wù)。如果你愿意把你的角色限制在組織會(huì)議，控制時(shí)間盒以及處理團(tuán)隊(duì)成員提出的障礙的話，你可以將這個(gè)角色當(dāng)作成兼職來對(duì)待。在這種情況下，團(tuán)隊(duì)仍然有可能達(dá)到預(yù)期的目標(biāo)，而且有可能不會(huì)發(fā)生什么重大事故。但是如果你展望團(tuán)隊(duì)能夠做到你之前無法想象的事情的時(shí)候，你就成為了一位出色的ScrumMaster。一位出色的ScrumMaster一次能夠負(fù)責(zé)一個(gè)團(tuán)隊(duì)。我們推薦每個(gè)7人左右的團(tuán)隊(duì)都有一位專職的ScrumMaster，尤其是剛開始實(shí)施Scrum的時(shí)候。如果你還沒有發(fā)現(xiàn)你能夠做的事情的話，嘗試聆聽Product Owner，團(tuán)隊(duì)還有團(tuán)隊(duì)以外的公司成員的想法。下面我列出了一些ScrumMaster常忽略的東西。Product Owner干得怎么樣？ 你可以通過幫助Product Owner維護(hù)產(chǎn)品待辦事列表和發(fā)布計(jì)劃來提高他的效率。（需要注意的是只有Product Owner才能給待辦事列表里面的項(xiàng)目排列優(yōu)先級(jí)。） 產(chǎn)品待辦事列表里面的項(xiàng)目已經(jīng)根據(jù)Product Owner的最新想法排好優(yōu)先級(jí)了嗎？是不是所有來自股東的需求都已經(jīng)被待辦事列表中的項(xiàng)目涵蓋了？要記得待辦事列表是涌現(xiàn)的。 產(chǎn)品待辦事列表的大小是否還能夠維護(hù)呢？為了使列表更容易維護(hù)，應(yīng)該將細(xì)粒度的項(xiàng)目放在靠前的位置，而把粗粒度的項(xiàng)目放在底部。但是要注意的是如果在分析需求上面花費(fèi)過多的時(shí)間，效果只會(huì)適得其反，因?yàn)槟愕男枨髸?huì)在團(tuán)隊(duì)和客戶/股東的持續(xù)談話中發(fā)生變化。 需求（特別是在產(chǎn)品待辦事列表最頂端的需求）能夠以獨(dú)立的、有價(jià)值的、可協(xié)商的、可估計(jì)的、可測(cè)試的小粒度用戶展現(xiàn)出來嗎？ 你是否已經(jīng)讓你的Product Owner了解什么是技術(shù)債務(wù)以及如何避免嗎？其中一個(gè)方法就是把自動(dòng)化測(cè)試和重構(gòu)這兩項(xiàng)任務(wù)加入到每個(gè)待辦事列表項(xiàng)目的完成的定義中。 待辦事列表是不是能讓所有股東都能夠看懂？ 如果你正在使用自動(dòng)工具來管理你的待辦事列表，想一下它真的能夠幫助你嗎？自動(dòng)化的管理工具有可能成為ScrumMaster了解信息的障礙。 你能夠通過有效地把信息打印出來然后傳達(dá)給其他人嗎？ 你能夠通過制訂可視化圖表來傳達(dá)足夠的信息嗎？ 你有曾經(jīng)幫助過Product Owner整理待辦事列表項(xiàng)目，然后分配到不同的版本中去嗎？ 是否所有人（包括股東和團(tuán)隊(duì)）都知道目前的團(tuán)隊(duì)速率是否能夠趕上發(fā)布的計(jì)劃呢？ Product Owner有根據(jù)上次Sprint評(píng)審會(huì)議來調(diào)整發(fā)布計(jì)劃嗎？通常Product Owner應(yīng)該至少在個(gè)Sprint之后調(diào)整發(fā)布計(jì)劃，一般來說會(huì)把一些工作放到后面的版本中，原因是發(fā)現(xiàn)了一些更重要的工作要做。你可以在每個(gè)Sprint評(píng)審會(huì)議的時(shí)候給大家展示Mike Cohn的產(chǎn)品和版本燃盡圖，這樣就可以更早地發(fā)現(xiàn)當(dāng)前的進(jìn)度是不是能夠符合預(yù)期。團(tuán)隊(duì)做得怎么樣？ 團(tuán)隊(duì)成員是否在大多數(shù)時(shí)間里都能夠進(jìn)入“流”的狀體？下面是這種狀態(tài)的一些特征（摘錄自Flow: The Psychology of Optimal Experience by Mihaly Csikszentmihalyi）：有清晰的目標(biāo)（）；集中且專注，高度集中在某個(gè)特定的領(lǐng)域或事物上；失去自我意識(shí)，完全沉浸在動(dòng)作和興趣中；扭曲的時(shí)間感受，只能感受到主觀世界的時(shí)間；直接和立即的反饋（無論是成功還是失敗都能夠馬上感知到，以馬上對(duì)行為進(jìn)行調(diào)整）；在能力和挑戰(zhàn)之間保持平衡；自我的控制能力；行為能夠從本質(zhì)上有所回報(bào)，所以感覺毫不費(fèi)力。 團(tuán)隊(duì)成員之間相處得怎么樣？氣氛融洽嗎？有為彼此的成功感到高興嗎？ 團(tuán)隊(duì)成員之間會(huì)以高標(biāo)準(zhǔn)要求對(duì)方嗎？會(huì)互相挑戰(zhàn)來促進(jìn)成長(zhǎng)嗎？ 有沒有一些事情團(tuán)隊(duì)會(huì)覺得不舒服而避免討論的？（詳見：Crucial Conversations: Tools for Talking When Stakes are High）或者引入專家來緩解不安的談話情緒。 有沒有試過以不同方式或者在不同地點(diǎn)舉行Sprint回顧會(huì)議？詳見：Agile Retrospectives: Making Good Teams Great (Esther Derby/Diana Larsen) 團(tuán)隊(duì)在開發(fā)過程中有沒有集中在驗(yàn)收標(biāo)準(zhǔn)上？也許你應(yīng)該在Sprint當(dāng)中舉行一次會(huì)議來評(píng)審當(dāng)前Sprint所承諾的產(chǎn)品待辦事列表項(xiàng)目的驗(yàn)收標(biāo)準(zhǔn)。 Sprint待辦事列表能夠真正反映出團(tuán)隊(duì)正在做的事情嗎？所有對(duì)Sprint的目標(biāo)的打斷和干擾都應(yīng)該被視為障礙。 團(tuán)隊(duì)有保持更新任務(wù)版嗎？ 團(tuán)隊(duì)的任務(wù)版和燃盡圖都能夠很容易地被團(tuán)隊(duì)看見和使用嗎？ 團(tuán)隊(duì)成員都能夠自己領(lǐng)取任務(wù)嗎？ 團(tuán)隊(duì)能夠被保護(hù)得足夠好而避免微管理嗎？ 用于解決技術(shù)債務(wù)的事項(xiàng)都能夠在待辦事列表里面反映出來嗎？還是需要和Product Owner另外溝通呢？ 團(tuán)隊(duì)成員會(huì)在團(tuán)隊(duì)的房間外忽略自己的職稱嗎？ 是不是整個(gè)團(tuán)隊(duì)都將團(tuán)隊(duì)看作一個(gè)整體，對(duì)測(cè)試和編寫文檔共同擔(dān)當(dāng)責(zé)任呢？工程實(shí)踐進(jìn)行得怎么樣？ 你們正在開發(fā)的系統(tǒng)有“開始測(cè)試”按鈕能讓每個(gè)都很容易地察覺到自己是否破壞了某些功能呢？通常這個(gè)是靠xUnit框架來實(shí)現(xiàn)的（JUnit，NUnit等等）。 你們能夠在自動(dòng)化端對(duì)端系統(tǒng)測(cè)試和自動(dòng)化單元測(cè)試之間保持平衡嗎？ 團(tuán)隊(duì)在開發(fā)系統(tǒng)功能測(cè)試和單元測(cè)試的時(shí)候使用的是同一種語言嗎（而不是使用團(tuán)隊(duì)里只有部分成員懂的腳本語言）？這個(gè)是可能的。 你的團(tuán)隊(duì)能夠發(fā)現(xiàn)系統(tǒng)測(cè)試和單元測(cè)試之間的灰色地帶嗎？ 你們的持續(xù)集成服務(wù)器能夠在回歸測(cè)試出現(xiàn)錯(cuò)誤的一個(gè)小時(shí)（或者一分鐘）內(nèi)自動(dòng)發(fā)出警報(bào)嗎？ 所有的測(cè)試都能夠在CI服務(wù)器的測(cè)試結(jié)果報(bào)告中反映出來嗎？ 團(tuán)隊(duì)能夠發(fā)現(xiàn)持續(xù)設(shè)計(jì)和無情的重構(gòu)，而不是一開始就進(jìn)行詳細(xì)的設(shè)計(jì)帶來的樂趣嗎？重構(gòu)擁有一個(gè)嚴(yán)格的定義：改變系統(tǒng)的內(nèi)部結(jié)構(gòu)而不改變其外部行為。重構(gòu)需要在每個(gè)小時(shí)內(nèi)進(jìn)行多次，每當(dāng)有重復(fù)代碼，復(fù)雜的條件邏輯（通常表現(xiàn)為過量的縮進(jìn)和冗長(zhǎng)的方法），糟糕的命名，對(duì)象間的過度耦合，一個(gè)對(duì)象的職責(zé)過多等等問題出現(xiàn)的時(shí)候就需要進(jìn)行重構(gòu)。要在重構(gòu)的時(shí)候有充足的信心，就要有足夠的自動(dòng)化測(cè)試覆蓋率。測(cè)試覆蓋率的漏洞和推遲的重構(gòu)被稱作技術(shù)債務(wù)。 在你的每個(gè)產(chǎn)品待辦事列表項(xiàng)目的驗(yàn)收標(biāo)準(zhǔn)中都包含了完全自動(dòng)化測(cè)試和代碼重構(gòu)這兩項(xiàng)嗎？如果不學(xué)習(xí)使用極限編程的工程實(shí)踐，你就不可能在每個(gè)Sprint都能完成潛在可交付的產(chǎn)品（正如Kent Beck, Ron Jeffries等人所說的）。 團(tuán)隊(duì)成員多數(shù)時(shí)間都在結(jié)對(duì)編程嗎？結(jié)對(duì)編程可以大幅度提高代碼的可維護(hù)性，也可以大大降低bug出現(xiàn)的機(jī)率。但是有時(shí)候結(jié)對(duì)編程實(shí)在挑戰(zhàn)大家的極限，有時(shí)候甚至?xí)雇瓿扇蝿?wù)的時(shí)間變長(zhǎng)（如果我們更重視數(shù)量而不是質(zhì)量的話）。所以，比較推薦的做法是和團(tuán)隊(duì)成員先討論以選擇在一周內(nèi)大家愿意嘗試使用結(jié)對(duì)編程的時(shí)間，而不是從一開始就強(qiáng)迫團(tuán)隊(duì)使用結(jié)對(duì)編程。然后慢慢地，部份人會(huì)開始喜歡結(jié)對(duì)編程的。整個(gè)公司的做得怎么樣？ 團(tuán)隊(duì)之間有沒有適當(dāng)?shù)亟涣骱献髂兀縎crum of Scrums是唯一的解決方案。也可以考慮在團(tuán)隊(duì)中選出代表參加別的團(tuán)隊(duì)的每日站會(huì)。 ScrumMaster之間有互相交流嗎？ 來自公司內(nèi)部的困難會(huì)在適當(dāng)?shù)臅r(shí)候被貼到開發(fā)總監(jiān)的辦公室的墻上嗎？成本能夠以金錢、丟失市場(chǎng)的份額、損失的質(zhì)量或者損失的客戶來量化嗎？ 你的公司的職業(yè)發(fā)展道路和你的團(tuán)隊(duì)的集體目標(biāo)相符嗎？如果以測(cè)試、自動(dòng)化測(cè)試或者開發(fā)文檔為代價(jià)來鼓勵(lì)編程或者設(shè)計(jì)架構(gòu)，那么答案就是否定的。 你能夠幫助公司成為一個(gè)學(xué)習(xí)型企業(yè)嗎？ 你的公司已經(jīng)被外界認(rèn)定為最好的工作場(chǎng)所或者業(yè)界的領(lǐng)頭羊了嗎？恐懼是你的朋友, 一旦你開始意識(shí)到你能夠做些事情來改變現(xiàn)狀，你可能會(huì)感到恐懼而退縮。然而，這正是你走上正軌的標(biāo)志。49 / 49