日期：2009.03.25
今天的站立會議花了我們不少時間，原因大家覺得如果不花點時間分析下原因，並找出對策，極有可能會影響sprint的交付。目前的狀況是：這個禮拜sprint就要結束，可實現的功能頂多只有一半。
1.沒有按照story優先順序來完成story
按照昨天晚上我們的初步分析，乙個原因是由於我們中間有部分人沒有嚴格按照sprint計畫決定的優先順序去完成story，導致到目前sprint即將結束，而在sprint計畫上確定要完成的主要功能卻只實現了一小部分。
解決方法：在product backlog中為story增加乙個importance欄位，用於標識story的優先順序，優先順序越高其數值越大。當然了，sprint backlog做為product backlog的乙個快照，其中的story也必須有importance標識，同時貼在白板上的story卡片中也必須有這個importance標識，且story卡片按照importance值的從大到小、由高到低的順序貼在白板上，團隊成員必須按照這個順序由上往下地完成這些story。當然，scrum master也需要在這個過程中進行監控，確保團隊成員沒有犯錯。
白板上的story卡片可以將product backlog中story條目的完整內容（也可以簡化些，但至少importance和預估算值不能少）寫上去，如附件。我們在兩個sprint中，story卡片上只是寫著story name，結合這兩次sprint的開展情況來看，卡片上的資訊太少了。在開發過程中，很少有團隊成員會再去開啟儲存著sprint backlog的excel文件看裡面的內容，所以有些記性不太好的成員，比如我，沒過幾天就忘了story的估算值了，而在站立會議上等成員匯報完昨天的工作後，scrum master統計完成工作量時偶爾還得跑去開啟excel去檢視story的估算值；同樣的，那個importance值在這個sprint中差點失去了它的作用。白板放在最顯眼的地方，每個只要轉個身就能看見，且每天站立會議上大家都要對著白板，所以把story資訊在卡片上寫完整，大家就不會遺忘些什麼了。
2.方案反反覆覆的討論
在這個sprint的開發過程中，我們發現花在討論方案上的時間太多了。
比如說，在專案啟動前，產品se輸出的規格文件中已經劃分好了各個層的職責，並初步定了各個層的介面定義，然後在sprint開發的第一天，所有的團隊成員先一起將這些介面的定義確認一遍，在這個過程中有人有疑義，就把產品se拉過來討論了一番，最終經過激烈的爭論，好象花了乙個下午，大家搞清楚了產品se的意圖、以及確定了介面的定義。在設施的過程中，負責實現某個介面的成員（暱稱a君），覺得介面定義還是有問題，就和我討論，旁邊的同事聽著我們的討論，覺得我們的理解和他的理解不一致，認為我們理解錯了產品se的意圖，就和我們「爭執」了上來，然後又把產品se拉上了，討論象漩渦，很快把其它的成員給卷了進來，我、a君、b君認為我們是按著一開始確定下來的方案來實施的，而產品se卻堅持我們錯了，這可把我們給急壞了，就這樣大家有風風火火的爭論著，最終又花了幾個小時把方案明確了。後來b君在實施過程中遇到乙個問題和我討論，討論完確定解決方法後，我認為這個有必要向產品se澄清、確認下，就讓他和產品se說聲，結果這個確認除了b君、產品se外，又把c君和我拉了進去，就這樣又半個多鐘頭過去了。 就是這樣，出現過不少次方案反覆討論的過程。
解決方法：1）每次方案討論，必須有個時間限制，初步規定為半個鐘頭，在這半個鐘頭內大家必須聚焦到問題上，不能發散。（如果在規定時間內無法達成統一意見呢？我自己這樣認為：如果在規定的時間內無法得到答案，那麼先結束這個討論，讓大家先冷靜下，自己再綜合之前討論中其它人的觀點考慮下，半個鐘頭後，大家再來討論，這樣可能比一直聚在一起討論效果好些，在激烈討論的氛圍內人更加會固執己見的）。順便提下，scrum中的一切事情都有時間盒，這個應該貫徹到底。2）每次討論，專案se與產品se必須一起在場，兩者少乙個人都不要討論，否則就會出現重複確認、討論的現象。3）每次討論後，都要簡單輸出乙個紀要，內容包括：討論的問題、最終確認的方案、以及達成這個方案是基於什麼前提條件確定的，然後將這個紀要發出來，大家確認無誤後就歸檔，一來可以做為專案的文件輸出的一部分，二來防止後面大家可能會忘記。
疑問：敏捷開發側重於**，而不是文件，那麼大部分專案都應該會出現我們這種在實施過程中經常討論方案的問題吧？除了我們自己確定的解決方法，還有其它更加高效的方式嗎？還是說，類似大的方案、方向性的東西，應該在專案啟動前就都應該是固定下來呢？思考中。
3.測試的問題
在我們這個專案中，測試人員（測試部的）投入1.5個人（其中有乙個人只能投入50％），測試人員負責測試用例的輸出、進行it測試、sdv測試，ut由開發完成。為了測試能夠開展it，我們承諾為服務層介面單獨包裝下，以服務的形式報出去（其實本身也有這樣的實際需求），這樣測試人員可以通過rmi的方式來測試我們的功能。測試人員反饋我們開發的在整個過程中只關注開發，很少將測試人員考慮在內，開發人員寫完**後，從介面上串通功能後就認為ok了，從不測試報出去的服務介面是否可用，而it一跑起來就出現問題，問題的根源是**中沒有處理對外暴露服務的這種分支，這樣導致測試進度阻塞。
我認為這個服務介面本身就是我們系統的乙個功能，就要求團隊成員必須自己先調通服務介面，然後才能讓測試人員進行it，而scrum master則認為it測試本來就是用來測試功能的正確的，所以服務介面是否能夠跑通也應該是it測試中的一項內容，如果由開發來保證這個，可能存在重複勞動。
我同意scrum master的這個觀點，測試本來就是用來發現**問題的，it跑起來發現有錯誤，這證明it是有用的，測試是有成效的，因為發現問題了（不過，開發人員只關心介面是否調通，而不考慮服務介面這個功能也確實不應該）。之所以it進度被阻塞，主要是因為每次改完**後，需要重新搭建it環境，而編譯打包比較慢。編譯打包時，除了我們這個系統本身的**，還需要將我們依賴的平台框架**一起編譯打包（平台也正在開發中），所以比較耗時。那是不是能夠這樣搞呢：提供兩種打包方式，一種是連同平台**一起編譯，適用於平台**有問題的情況，另一種則是只編譯打包我們系統的**，絕大部分情況都只會用這一種，這樣效率可以提高一些。
跌跌撞撞地敏捷之路 及時記錄經驗教訓
日期 2009.03.23 今天又是乙個周一，scrum master每週一都需要做專案週報，向上及周邊相關人報告專案在上週的進展。在這個報告中有經驗教訓這一項，這裡需要在上一周中專案開展過程中團隊成員作出的經驗總結 優秀實踐 出現的問題及規避方法。scrum master早上就開始問 大家回想下，...
跌跌撞撞地敏捷之路 懷念那段結對的日子
現在，如果有人問我要不要在專案中實施結對程式設計，我會第乙個站出來大聲地說 堅決要實施結對 這個專案初次嘗試走敏捷，從一開始對敏捷的不了解，團隊成員的點滴摸索，到中間的漸入佳境，到最後的打回類cmm的原點，這種在乙個專案中 大起大落 的經歷使我倍加愛上敏捷，倍加懷念結對走過的日子。專案啟動初期，沒有...
2014 跌跌撞撞
又是一年，想起上次做總結還是在大學畢業的時候，那時候是感概萬千，給自己定了n多目標，轉眼一年半過去了，回想起當初的目標，有幾個是真真切切實現了的。這一年，過的還算充實，去年的這個時候，剛上完專業課，被boss叫來跟師兄的畢設，那是自己第一次接觸科研這個東西，以前我總覺得搞科研是乙個很神聖的事情，可是...