前言

本讀書筆記分兩部分。
第一部分探討傳統(tǒng)軟件開發(fā)方式和敏捷開發(fā)的區(qū)別。
第二部分探討敏捷開發(fā)方法論之一的Scrum方法。根據(jù)《Scrum要素》中的周記，結(jié)合《Scrum權(quán)威指南》，討論Scrum的主要內(nèi)容。

敏捷力介紹

瀑布模型

瀑布模型將開發(fā)和交付企業(yè)軟件項目的流程分割為相互獨立的階段：

1. 需求收集
2. 設(shè)計
3. 編碼
4. 測試

在瀑布流程中，每一步驟都必須等待前一步驟結(jié)束后才能繼續(xù)，也只有等待所有步驟都結(jié)束后才有可能向客戶交付價值。人們往往會認為“完美化”設(shè)計能夠作為該模型的理論支持：能夠早點捕獲錯誤和缺陷，從而降低項目全過程成本。然而美中不足之處就在于“完美化”太不現(xiàn)實了，軟件產(chǎn)品是復(fù)雜系統(tǒng)，而不是靜態(tài)物件，毫無經(jīng)驗數(shù)據(jù)只能設(shè)計出致命的爛系統(tǒng)，在出問題前把事情搞得一團糟。

迭代式方法

敏捷團隊做的開發(fā)工作和瀑布團隊一模一樣，但他們的做事方式很不一樣。敏捷開發(fā)周期使用的職能和瀑布方法一樣：需求收集、設(shè)計、編碼和測試，差別在于：敏捷團隊會做一點點需求收集，一點點設(shè)計、編碼和測試，最后交付一點點價值給客戶。接著團隊再重復(fù)此過程，周而復(fù)始，工作推進過程中不斷改善、調(diào)整流程，一直到項目完成為止。

Scrum

初讀《Scrum權(quán)威指南》，該書精練準確地定義了Scrum框架，包括Scrum理論、價值觀、團隊、事件、工件等內(nèi)容，而在《Scrum要素》的開篇，作者以講故事的手法敘述了一篇《Scrum團隊周記》，形象生動地將Scrum框架主要內(nèi)容介紹給讀者。

角色

在《Scrum團隊周記》中，這支高績效的scrum團隊由九個人組成，Brad是產(chǎn)品負責人，F(xiàn)rank是團隊的scrum master，剩下七名均為團隊成員，他們來自傳統(tǒng)領(lǐng)域，頭銜可能各不相同，例如架構(gòu)師、業(yè)務(wù)分析師、設(shè)計師、軟件開發(fā)者、測試人員、產(chǎn)品經(jīng)理等，但scrum只承認三個互不相同的角色，即產(chǎn)品負責人、scrum master和團隊成員，團隊規(guī)模在5-9人。

Brad —— 產(chǎn)品負責人

Brad有一張工作項的候選列表，新特性和錯誤修復(fù)的工作都有，他認為這些都是項目上最重要的待辦事項。這些待辦事項源自于一個按優(yōu)先級排序地清單，將它們挑選出來是Brad作為產(chǎn)品負責人職責地一部分。
選定范圍后，Brad會用文摘卡記錄下這些特性。
這些故事都是Brad、業(yè)務(wù)和客戶想要的東西：故事是有商業(yè)價值的。
團隊成員們和Brad逐一討論這些用戶故事，明確其驗收標準，或者更確切地說，就是Brad心目中已經(jīng)完成故事地模樣。
有個故事大家理解得還不夠，沒有想象中地好，他們要求Brad再去向某個關(guān)鍵客戶多要些信息回來。

我們可以看出產(chǎn)品負責人的工作職責有哪些：

1. 清晰地表述產(chǎn)品待辦列表項，并對產(chǎn)品列表項進行排序，使其最好地實現(xiàn)目標和使命
2. 確保產(chǎn)品待辦列表對所有人是可見、透明和清晰地，同時顯示Scrum團隊下一步要做地工作，以及確保開發(fā)團隊對產(chǎn)品待辦列表項有足夠深地了解。
3. 優(yōu)化開發(fā)團隊所執(zhí)行工作地價值

Frank —— Scrum Master

Frank是團隊地scrum master，他早已把房間布置得妥妥當當，就等會議開始
Frank開始帶著大家做“估算游戲”，跟撲克牌游戲很像，能夠幫助團隊快速達成共識

我們可以看到，scrum master擔當教練角色，引領(lǐng)團隊達到更高級地凝聚力、自組織和表現(xiàn)。他們密切注意流程和進度地情況，獻言獻策幫助團隊解決小問題，有需要時還會扮演回音板角色。

1. 服務(wù)于產(chǎn)品負責人，確保團隊中每個人都盡可能地理解目標、范圍和產(chǎn)品域等
2. 服務(wù)于開發(fā)團隊，移除開發(fā)團隊工作進展中地障礙，幫助開發(fā)團隊創(chuàng)造高價值地產(chǎn)品，引導scrum事件
3. 服務(wù)于組織，在組織范圍內(nèi)規(guī)劃Scrum的實施，幫助員工和利益攸關(guān)者理解并實施Scrum和經(jīng)驗導向的產(chǎn)品開發(fā)

團隊成員
剩下的所有開發(fā)人員，負責在每個Sprint結(jié)束時交付潛在可發(fā)布并且完成的產(chǎn)品增量。

1. 他們是自組織的，沒有人有權(quán)告訴開發(fā)團隊應(yīng)該如何把產(chǎn)品代辦列表變成潛在可發(fā)布的功能增量
2. 開發(fā)團隊是跨職能的團隊，團隊作為一個整體，擁有創(chuàng)建產(chǎn)品增量所需的全部技能
3. 開發(fā)團隊中的每個成員也許有特長和專注地領(lǐng)域，但是責任屬于整個開發(fā)團隊

事件

Sprint周期是scrum過程地基本節(jié)奏，這是敏捷方法論的一個共同點，以迭代方式完成工作，在《周記》中，Sprint周期長度為一周，一周內(nèi)出現(xiàn)Sprint事件如圖所示

Sprint.png

Sprint計劃會議

Brad開始講話：“大家平均每個Sprint能夠完成相當于40個故事點的工作量。我已經(jīng)從產(chǎn)品里選出了最前面8個故事，加起來正好40個點的大小，我想知道團隊會不會承諾這些故事”
團隊成員們和Brad逐一討論這些用戶故事，明確其驗收標準，或者更確切地說，就是Brad心目中已經(jīng)完成故事地模樣。團隊成員會繼續(xù)討論實現(xiàn)這些故事要做地工作，有哪些類型，有多少工作量。
團隊開始把用戶故事分解成任務(wù)，團隊一起上，要找到辦法對這些故事進行設(shè)計、編碼以及測試，在此過程中，他們會用便利貼把所有的任務(wù)記錄下來。

Sprint計劃會議要回答以下問題：

• 接下來地Sprint交付的增量中要包含什么內(nèi)容？
• 要如何完成交付增量所需的工作？

開發(fā)團隊預(yù)測在這次Sprint中要開發(fā)的功能，產(chǎn)品負責人講解Sprint的目標以及達成該目標所需完成的待辦列表項，整個Scrum團隊協(xié)同工作來理解Sprint的工作。

在設(shè)定了Sprint目標后并選出這個Sprint要完成的產(chǎn)品待辦列表項后，開發(fā)團隊將決定如何在Sprint中把這些功能構(gòu)建成完成的產(chǎn)品增量。開發(fā)團隊通常從設(shè)計整個系統(tǒng)開始，到如何將產(chǎn)品待辦列表列表轉(zhuǎn)化成可工作的產(chǎn)品增量所需要的工作。

每日站會

scrum日會是一種短會，用于團結(jié)和協(xié)調(diào)團隊。為了鼓勵大家都簡潔點，這個會是站著開的，它也因此而得名“每日站會”。
團隊成員輪流分享信息：前一天完成了什么任務(wù)，明天的scrum日會前打算做哪個任務(wù)；有沒有碰到什么障礙或者是受到了什么拖累

開發(fā)團隊或者開發(fā)團隊成員通常會在每日Scrum站會后立即聚到一起進行更詳細的討論，或者為Sprint中剩余的工作進行調(diào)整或重新計劃。
Scrum master確保開發(fā)團隊每日站會如期舉行，但開發(fā)團隊自己負責召開會議。Scrum master教導開發(fā)團隊將每日Scrum會議時間控制在15分鐘內(nèi)。每日Scrum站會增進交流溝通、減少其他會議、發(fā)現(xiàn)開發(fā)過程中需要移除的障礙、突顯并促進快速地做決策、提高開發(fā)團隊的認知程度。這是一個進行檢視和適應(yīng)的關(guān)鍵會議

評審會議

午飯后進行當前Sprint的公開收尾，團隊成員們都來了，這一事件就是Sprint評審會議。整個團隊都在場，還向所有干系人發(fā)出了參會邀請。
團隊先是宣布他們完成了這個Sprint承諾過的所有故事。接著就直接開始演示他們?yōu)楣适滤_發(fā)的這個軟件功能。
演示結(jié)束后，團隊邀請參會者親身體驗新功能，問他們有沒有疑問或者建議，Brad小心記錄下不同干系人對于當前產(chǎn)品的看法，以及他們希望在下一次發(fā)布時看到的變化。

我們可以看到，一次Sprint評審會議包含以下內(nèi)容：

• 參會者包括Scrum團隊和產(chǎn)品負責人邀請的主要利益攸關(guān)者
• 產(chǎn)品負責人說明哪些產(chǎn)品待辦列表項已經(jīng)完成和哪些沒有完成
• 開發(fā)團隊討論在Sprint期間哪些工作做的好，遭遇到說明問題以及問題是如何解決的
• 開發(fā)團隊演示完成的工作并解答關(guān)于所交付增量的問題
• 參會的所有人就下一步的工作進行探討，這樣，Sprint評審會議就能夠為接下來的Sprint計劃會議提供有價值的輸入信息
• 評審市場或潛在的產(chǎn)品使用方式所帶來的家下來要做的最有價值的東西轉(zhuǎn)變，同時為下個預(yù)期產(chǎn)品功能或產(chǎn)品能力版本的發(fā)布評審時間表、預(yù)算、潛力和市場

回顧會議
回顧會議是Scrum團隊檢視自身并創(chuàng)建下一個Sprint改進計劃的機會。
目的在于：檢視前一個Sprint中關(guān)于人、關(guān)系、過程和工具的情況如何；找出并加以排序做得好的和潛在需要改進的主要方面，同時制定改進Scrum團隊工作方式的計劃。
回顧會議幫助我們把握時機，在消極模式尚未根深蒂固時，趁著記憶還很清晰，多捕獲一些認識和見解，找到一些可改進的事實，制定行動計劃，實現(xiàn)這些改變。

三大支柱

Scrum基于經(jīng)驗過程控制理論，或稱之為經(jīng)驗主義。經(jīng)驗主義主張知識源自實際經(jīng)驗以及當前已知情況下做出的決定所獲得。Scrum采納一種迭代和增量式的方法來優(yōu)化對未來的預(yù)測和控制風險。透明、檢視和適應(yīng)是經(jīng)驗過程控制的三大支柱，支撐起每一個經(jīng)驗過程的實施。

透明
過程中的關(guān)鍵環(huán)節(jié)對于那些對產(chǎn)出負責的人必須是顯而易見的。要擁有透明，就要為這些關(guān)鍵環(huán)節(jié)制定統(tǒng)一的標準，這樣所有留意這些環(huán)節(jié)的人都會對視察到的事物有統(tǒng)一的理解

檢視
Scrum的使用者必須經(jīng)常檢視Scrum的工件和完成Sprint目標的進展，以便發(fā)現(xiàn)不必要的差異。檢視不應(yīng)該過于頻繁而阻礙工作本身。當檢視是由技能嫻熟的檢視者在工作中勤勉地執(zhí)行時，效果最好

適應(yīng)
如果檢視者發(fā)現(xiàn)過程中的一個或多個方面偏離可接受范圍以外，并且將會導致產(chǎn)品不可接受時，就必須對過程或者過程化的內(nèi)容加以調(diào)整，調(diào)整工作必須盡快執(zhí)行如此才能最小化進一步的偏離