公司所有開發組目前都在提倡敏捷開發，我所在的開發組也沒有out，剛剛發版的產品我們就引入了敏捷開發的一些概念--雖然還比較粗糙，但整體感覺還是蠻好的。發版後，有一段空閒期，閒來無事，看到同事桌上有本《輕鬆Scrum之旅--敏捷開發故事》，就借過來讀了一下，通篇就是一個產品的敏捷開發過程，從概念和使用方法上看，能有不小收穫。這次就寫一下自己初次體驗敏捷的一些感受和這本書的一點讀後感。

先說一下自己在實際開發中的一些感受吧。

敏捷開發整體來說是一種思想，但凡是思想的東西就不會侷限於某種或某幾種應用之上。敏捷也不例外，軟體開發作為一種智力工程，只是敏捷的一個應用而已。具體到實際的應用，思想就會被具化為一些行之有效的手段和指導原則。敏捷在實際軟體開發有XP,RUP,Scrum等多種應用框架，這些框架基本都是一些指導原則的集合，我們實際開發中採用了Scrum,但中間也採用了其他框架的一些非常優秀的指導原則！這其實也體現了敏捷的部分思想：不拘泥於形式！

使用Scrum，首先要有功能看板，現在有很多軟體形式的看板，我們第一次使用敏捷，果斷沒有使用這種看板，而是採用了更具視覺衝擊力的實物看板，我們開發經理用週末打造瞭如下看板：

上面就是我們組大而帥的功能看板，那他的作用是啥呢？上面在不同格子上貼的便籤又是啥呢？我先簡介概括一下我們使用敏捷的步驟，這些問題你就會有了答案的。

我們第一次是這樣使用Scrum的（其中的一些步驟和涉及到的用詞和標準Scrum有所區別，這個我後面會分析）：

1》 部門經理，開發經理，需求人員將產品進行分解，分解為一些較大的點，然後根據重要性和難易度將這些點分為3個迭代週期，即3個迭代週期後，產品整體及出爐了。

2》 開始每一次迭代前，部門經理，開發經理會將這個迭代的大點進行細分成一些小點，大小通常控制在1~3天。

3》 開始具體一次迭代，我們首先會開一個任務分配會議，時長大約1個多小時，開發經理給出所有的上述分解出的小點，挨個“招標”。如果有人感興趣，舉手示意即可，對於沒人認領的點，開發經理最後會根據時間，強制分配給某人。

4》 開始迭代，首先所有人將自己的開發點寫在便籤上，並且貼在上述看板自己對應行的【準備】列中。這個看板“行”是和開發人員對應的，一人一行。“列”是和任務過程對應的，通常包括：準備；進行中；自測；完成。

5》 每天早晨9:00，開發經理會組織所有開發人員在看板前集合，舉行每日例會，時長通常在20-30分鐘。每個開發人員必須發言，發言內容為：昨天我做了什麼事情，我遇到了什麼困難，今天我要做什麼事情。說的過程，同時移動任務便籤到看板相應的列上。每個任務便籤上都寫有該任務的完成時間，如果開發時間和進度不匹配，開發經理會立即發現並進行溝通。

6》 一次迭代完成後，部門經理，開發經理，需求人員，所有開發人員，測試人員會開一次評審會議，時長大約2個小時，這期間主要是開發人員向所有與會者展示這次迭代的開發成果。測試人員也瞭解一下產品的使用方法，便於馬上開展的測試工作。

這就是我們的敏捷過程，借用部門經理的話，這就是“山寨版”敏捷......但我們還是在這幾條步驟下，經過3次迭代，產品成功發版了。其中也遇到了一些問題，比較典型的如下：

1》 任務分解粒度太粗！2~3天的任務，通常會產生拖延，因為這個時間本身就是估算的，任務時間長，說明其包含的功能點多，每個功能點有一點延遲，整個任務就有延遲，一個任務有延遲，最後往往會波及到整個迭代的時長！我們這3個迭代最後多出現了延時情況。

2》 任務粒度太粗還有另一個問題時，功能點的遺漏！這個問題甚至會拖延到測試時才被發現，只能臨時將其新增到下次迭代中，影響了下次迭代的開發。

3》 開發人員受外界影響太大！我們開發人員不僅要參與這個產品的發版，同時還要參與維護以前的產品。這種時間沒法計算到迭代週期中，但同樣會影響迭代週期的計劃時長。

4》 分解任務分配時間時，程式碼評審和自測的時間估量的太少，導致每次迭代後交付給測試的產品小問題太多。雖然整體流程可以走通，但仍熱讓測試團隊怨氣頗大！

這就是我們第一次自我敏捷的過程和期間產生的一些問題。如果僅僅從“敏捷的實施”這個角度看，我們的敏捷是失敗的。因為我們沒有按時優質的交付每一次迭代成果，最後的產品也產生了拖延。

然後再說一下我讀完《輕鬆Scrum之旅--敏捷開發故事》一書後，對Scrum的一些收穫吧，其中還有和我自己的敏捷開發進行的對比。先說一下Scrum中涉及到的一些名詞：

1》 Product Owner：產品所有者，這個人發起一個產品的開發，並且負責將產品通過User Story的形式進行描述，並對所有User Story按優先順序排序，給出一個大概的開發時間。我上述描述中“部門經理”就是我們那個產品的Produce Owner。

2》 Product Backlog：產品的功能點的總綱，即所有的User Story。最後Scrum是否完成，就看這個Backlog中是否還有剩餘User Story。敏捷中允許Product Backlog發生變化，這分為兩點：一是前面迭代中完成的部分發生了需求變化，則將這部分放到未完成的Backlog中，另一個是沒有開發的部分發生變化。並且如果Scrum的整體週期很難變化，可以視開發進度從Product Backlog中將部分User Story移出。

3》 User Story：產品的一個開發點，通常是一個較大的點，從使用者角度進行描述。一個大的User Story通常會包括多個較小的User Story。較小的User Story會包含多個Task。

4》 Task：產品的一個小的開發點，我們進行開發忘功能看板上貼便籤上，寫得就應該是Task。每個Task的時長通常為0.5~1天。從這個角度看，我上述描述的自己的敏捷對Task的大小沒有控制好，這點確實對開發影響很大！

5》 Scrum Master：Scrum團隊的負責人。負責一個Scrum團隊和Product Owner交流的一個人。Scrum強調團隊的自我管理性，即開始Scrum後，這個團隊就相對封閉了，不應受外界影響。這個團隊的一個開放口就是Scrum Master 。這個人負責團隊與外界溝通，並且阻止外界對團隊的影響。我上述描述自己的敏捷中，開發經理就相當這個角色。

6》 Sprint：中文翻譯就是“衝刺”， 我上面描述自己的敏捷提到的“迭代”就等同於Sprint。實際實施Scrum中，就是要完成幾個Sprint。一個Sprint時間通常為2周~2個月，這個視產品大小而定。

7》 Sprint Backlog：一個迭代過程中需要完成的功能點列表。這個列表就是從Product Backlog中挑選出來的。

8》 Sprint Planning Meeting：Sprint計劃會議。這個會議是開始一個Sprint的標誌會議。通常分為兩部分，第一是Product Owner，Scrum Master，所有開發人員，使用者（如果有的話最好）同時參加，共同決定這次Sprint中要完成Product Backlog中哪些功能，如果此刻又不明白的地方，Scrum Master和開發人員必須和Product Owner進行充分溝通，直到明白為止。第二是Scrum Master 和所有開發人員參加，將這次Sprint中的User Story分解為Story，每個Story完成時間控制在0.5~1天，並且由開發人員按興趣領取相應的Task。注意程式碼評審和自測也要分別作為一個Task存在。

9》 Daily Scrum Meeting：每日例會。由Scrum Master和所有開發人員參與的例會。這個是Scrum的精髓，Scrum Master控制一個Spint的進度就是根據這個會議。

10》 Sprint Review Meeting： Sprint評審會議。每次Sprint後對整個Sprint的成果向Product Owner，測試進行演示的一個會議，是一個Sprint完成的標誌。

11》 Sprint Retrospective Meeting：Sprint回顧會議。這個會議由Scrum Master 和全體開發人員參加，大家討論一下在剛剛結束的一個Sprint中的所得和所失。是一個Scrum團隊自我成長和進步的最好的方式，大家互相提出自己的建議並發現問題，進行團隊經驗累積。我上述自己的敏捷沒有這個會議，這個是一大損失！

這些都是這本書提到的一些Scrum概念，在實際應用中，我們的一些東西和這個肯定會略有不同，這個無關緊要，但其中一些重要的步驟，比如最後8~11 這個4個，是不可或缺的！

Scrum是軟體開發中對敏捷的一組具體的應用指導原則，他強調面對面的溝通（一個Scrum團隊最好保持在6~8人，並且大家辦公位置能在一起），歡迎變化，弱化文件（他強調程式碼和註釋是最好的文件），並且不提倡加班（對於視加班為常態的廣大IT“民工”真是一大福音啊）。

實施Scrum中，有幾點是要提前有所防備的。Scrum歡迎變化，所以我們就不可避免會有一些需求的變動或開發人員請假的一些情況，所以我們在安排時間時儘可能留一些預留時間，這個長度視經驗而定。如果在實施過程中，預感到進度出現滯後的現象，Scrum Master要及時和Product Owner進行溝通，暴露問題所在，提前做出調整，如延長一定時間或者去掉一些User Story。

Scrum中涉及一個功能看板，這個看板很重要，可以用實物看板（我上述描述的敏捷過程所用），目前也有很多Scrum實施軟體，如ScrumWorks（這本書中使用的軟體），這個軟體好像是收費的，所以我也沒用過，但貌似功能很強大！不僅能有實物看板一切功能，而且還支援自動繪製“燃盡圖”，這是一個整個專案進度的視覺化顯示，從網上找到的燃盡圖，大家可以看一下：

紅線表示計劃進度路線，藍線表示實際進度路線。藍線在上面，表示進度有所滯後，藍線在下面表示進度有所加快。如果不用ScrumWorks這類軟體，我們如果需要這種視覺化圖片，需要自己手動進行。

這就是自己先糊里糊塗經歷過敏捷而後又細細品味後敏捷的一點入門小得，總結一下，敏捷就是一種思想，是一種以人為出發點的一種管理哲學，可以應用在各種領域。在軟體工程領域，Scrum是一組具體的敏捷實施指導原則，概念清晰，比較適合初次採用敏捷的開發團隊使用。