日期：2009.02.16——2009.03.06
這個專案將嘗試採用敏捷開發。
敏捷是什麼，現在回想起來，當時專案組成員對這方面的了解幾乎就是空白，十足的敏捷白痴（現在這樣講，其實也是在五十步笑一百步，慚愧），只知道這是時下比較時髦的名詞，還有幾個相關的名詞：迭代、結對程式設計、極限程式設計、scrum、story、燃盡圖，對所有這些名詞的了解也頂多停留在非常膚淺的認知上。對於我自己來說，也是人云亦云，外加上很久很久以前走馬觀花地瞟了幾眼《硝煙中的scrum和xp》，也多虧這幾眼，我才知道敏捷裡還有scrum、story、燃盡圖這幾個名詞，汗顏。
專案啟動前走的流程還是沿用了cmm的老一套，產品se下規格，然後規格評審，為初步估了**量，最後就開始準備立項開發了，這時到崗的開發人員有三個：pl（cmm中的稱謂）、我和另乙個同事，根據估出來的**量，需要再協調兩個人開發人員，其中乙個在專案啟動前就到位了，另乙個還暫時定在南京異地開發（我們在深圳），這與敏捷開發原則是相違背的——團隊成員最好能做到同地緊密協作，而且能夠做到每日面對面交流。後來我們在這一點確實嘗到了苦頭。
由於專案組成員對敏捷開發都不熟悉，專案啟動前申請了乙個培訓，但由於培訓老師本身並沒有參與過敏捷專案，培訓過程也差不多就是照本宣科外加討論，所以這個培訓其實也沒有起到多大的作用，我並不是在說培訓老師能力差，其實換任何乙個沒有具體參與過敏捷專案的人來給人培訓，都不會有什麼成效。敏捷不是光靠看書、靠參加就能學會的，只有參與過敏捷專案的人，才能在操作過程中遇到實際的問題，才能針對問題去解決問題，在這裡只有理論是不行的。
立項之前，pl（cmm中的稱謂）根據初步估計出來的**量，以及交付時間點，將真個專案劃分為4個迭代，迭代週期為3周，然後和我這對個掛名的版本se兩個人再細分了下需求點，按自己的的感覺（有點類似優先順序）細分結果劃分到各個迭代中去實施，並寫在乙個excel文件中，內容大概就是這樣的：
迭代一：
功能點 **量（行）
*****功能 1200
*****功能 850
迭代二：
功能點 **量（行）
*****功能 1200
*****功能 850
假如硬要往scrum中靠的話，這個應該算是產品的backlog了，每個功能就是乙個story，但這裡寫的內容與真正意義上的story內容少多了（當時還不知道如何寫story呢，哈哈），其實在scrum中，產品blacklog應該是product owner來寫的，這個角色應該就是我上面說的產品se了，這個職責是不能由其它人頂替的。後面就開了個專案開工會了。到這裡為止，一切好象還是和cmm的沒有什麼差別。
接著，第乙個迭代開始了。迭代的第一天，我們開了個會，與會人：5個開發（乙個在南京用**會議接入），2個測試，1個資料以及qa。我拿著之前我和pl整理出來的那個「story」excel，為專案組成員講解了下這個迭代我們要完成的功能，然後就讓各個成員根據自己的意願去挑想要做的功能了，並要求各個開發人員在會後將功能點細分成「story」（呵呵，搞笑吧，在scrum中這應該是任務了才對），並把每個story的描述以及相應的**量寫到貼紙上。下午，把大家的「story」卡片收集起來，統計了總的**量，然後就準備開始畫燃盡圖了。這燃盡圖怎麼畫呢？沒什麼講的，橫軸肯定是日期了，單位是天。縱軸呢？我們討論後，就是將總的**量，然後除以乙個適當的值，將這個值做為縱軸的單位，這樣子才好畫點，否則4000行**量（實際4000後面還有零頭的），以一行為單位，那縱軸就得畫4000個點，畫死人了，最終我們決定以200行為單位。就這樣我們得到了我們的燃盡圖了。
然後迭代正式的開發期了。果然，團隊人員不在一起辦公的缺點在頭幾天就立馬暴露出來了。首先，每天早上的站立會議，南京的兄弟通過**接入，由於沒有會議終端，深圳這邊的討論他那邊聽不清楚，只好深圳輪到誰講了就拿起話筒講，結果如果南京的兄弟有疑問了，還得把話筒再放回去，使深圳的每個人都能聽到他在講什麼；其次，開發過程中討論不方便，深圳這邊有什麼結論，那邊不能實時知道；最後，就是南京那邊的進度不能很好的控制。所以沒過幾天，我們就強烈申請南京的兄弟過來深圳辦公。
由於當時決定的燃盡圖畫法，畫上去之前得先將昨天完成的工作量彙總，然後再除以200，才換算出燃盡圖上的進度，相當麻煩，而且這個除，很多時候除出來的結果並不是整數，或者半數(**.5)，所以畫的時候更痛苦了。
知道我們怎麼統計昨天完成的工作量的嗎？我們只算昨天實際寫的**行數，對於ut的工作量不進行統計。而我們的燃盡圖上體現的迭代要完成的**量呢？則是包括了編碼、測試的工作量的。結果，我們在迭代進行到一半的時候，就發現了我們很可能到迭代完成的時候，即使**完全寫完了，燃盡圖上的曲線「燃」不到底了，就是不能和橫軸相接。果然，到了迭代結束的時候，我們的燃盡圖上的曲線就掛在半空了，但實際上**都已經寫完，測試也完成了。呵呵，好笑。
就這樣，我們的第乙個敏捷的迭代完成了。好笑。
（待續...）
跌跌撞撞地敏捷之路 及時記錄經驗教訓
日期 2009.03.23 今天又是乙個周一，scrum master每週一都需要做專案週報，向上及周邊相關人報告專案在上週的進展。在這個報告中有經驗教訓這一項，這裡需要在上一周中專案開展過程中團隊成員作出的經驗總結 優秀實踐 出現的問題及規避方法。scrum master早上就開始問 大家回想下，...
跌跌撞撞地敏捷之路 為什麼進度那麼慢
日期 2009.03.25 今天的站立會議花了我們不少時間，原因大家覺得如果不花點時間分析下原因，並找出對策，極有可能會影響sprint的交付。目前的狀況是 這個禮拜sprint就要結束，可實現的功能頂多只有一半。1.沒有按照story優先順序來完成story 按照昨天晚上我們的初步分析，乙個原因是...
跌跌撞撞地敏捷之路 懷念那段結對的日子
現在，如果有人問我要不要在專案中實施結對程式設計，我會第乙個站出來大聲地說 堅決要實施結對 這個專案初次嘗試走敏捷，從一開始對敏捷的不了解，團隊成員的點滴摸索，到中間的漸入佳境，到最後的打回類cmm的原點，這種在乙個專案中 大起大落 的經歷使我倍加愛上敏捷，倍加懷念結對走過的日子。專案啟動初期，沒有...