日期：2009.03.23
今天又是乙個周一，scrum master每週一都需要做專案週報，向上及周邊相關人報告專案在上週的進展。在這個報告中有經驗教訓這一項，這裡需要在上一周中專案開展過程中團隊成員作出的經驗總結、優秀實踐、出現的問題及規避方法。scrum master早上就開始問：「大家回想下，上週我們有什麼經驗教訓沒有？」大家你看看我，我看看你，或者聳聳肩，他沒有得到任何的答覆，嘆了口氣：「哎呀，上週怎麼沒有記錄下來呢？」然後大家就各自幹自己的事了。到了下午，scrum master又問了一遍同樣的問題：「大家再想想，上週我們有什麼經驗教訓沒有？」結果還是一樣。
雖然是小事一樁，但從效率提公升的角度來講，我想只要稍加改善，還是多多少少有提公升的餘地的。首先不說記錄經驗教訓是scrum master的週報內容，單從其實際的作用來說本身就是件非常具有意義的事情，將這些東西記錄下來即可以在sprint回顧會議中進行總結，而且還可以傳承下來，做為本專案組以後的新進成員或者其它專案組的學習資料。所以這項工作應該做到scrum master的日常工作中（或者指派某個團隊成員來承擔），一旦有好的經驗總結、好的實踐或者教訓就立馬記錄到乙個文件中並歸檔。這樣scrum master在做週報的時候就可以信手拈來，而不用花時間去回顧，一舉兩得。
效率提公升應該就是這樣一點一滴的積累起來的。
跌跌撞撞地敏捷之路 為什麼進度那麼慢
日期 2009.03.25 今天的站立會議花了我們不少時間，原因大家覺得如果不花點時間分析下原因，並找出對策，極有可能會影響sprint的交付。目前的狀況是 這個禮拜sprint就要結束，可實現的功能頂多只有一半。1.沒有按照story優先順序來完成story 按照昨天晚上我們的初步分析，乙個原因是...
跌跌撞撞地敏捷之路 懷念那段結對的日子
現在，如果有人問我要不要在專案中實施結對程式設計，我會第乙個站出來大聲地說 堅決要實施結對 這個專案初次嘗試走敏捷，從一開始對敏捷的不了解，團隊成員的點滴摸索，到中間的漸入佳境，到最後的打回類cmm的原點，這種在乙個專案中 大起大落 的經歷使我倍加愛上敏捷，倍加懷念結對走過的日子。專案啟動初期，沒有...
跌跌撞撞地敏捷之路 第一次敏捷開發
日期 2009.02.16 2009.03.06 這個專案將嘗試採用敏捷開發。敏捷是什麼，現在回想起來，當時專案組成員對這方面的了解幾乎就是空白，十足的敏捷白痴 現在這樣講，其實也是在五十步笑一百步，慚愧 只知道這是時下比較時髦的名詞，還有幾個相關的名詞 迭代 結對程式設計 極限程式設計 scrum...