剛開始啟動看板的時候，我們做的很簡單：
於是在那個迭代回顧會上，我們第一次對看板的設計做了回顧，識別了以下的問題列表： -看看，沒有一勞永逸的事情，任何事情都要講究「持續改進」於是，我們對看板進行了重新的設計，制定了看板公約：
我們把公約列印出來，貼在看板的右上角，於是，看板開始變得花花綠綠起來，因為公約很簡單，大家一看就知道。現在感覺看板內容豐富一些了，一眼就能看出哪些任務遇到障礙，需要及時協調跟進的，障礙的處理進展等，大家感覺都不錯。
隨著兩周乙個迭代的節奏慢慢順暢，我們固定了需求的更新週期，並加入了簡單的度量。
最直接的，就是生產率。我們生產率計算很簡單，就是計算每個迭代團隊交付的需求數。
漸漸地，我們又發現了新問題。
我們發布的版本越來越多，現場問題也接踵而至，我們必須要分出人力出來去做現場問題定位。
我們**不斷增加和變更，有些原來為了趕上線時間而定的臨時方案等也需要重構，那麼就需要投入人力去做重構。
這樣，我們的生產率就變低了，從原來的10個/迭代，變成了現在大概7個/迭代。
怎麼分解這些多樣化的任務？在看板中怎麼體現？
於是我們進行了頭腦風暴，做了如下改進：
假設我們有7個需求任務在進行中，那麼最多的重構任務（任務量相當）我們只會安排2條；
現場問題按需分配，因為有設定乙個緩衝時間，所以現場問題來的時候，一般會以緊急任務的形式展示。
乙個迭代之後，我們發現之前頭腦風暴的比例有點太理想了，於是我們又調整了分配比例。
慢慢地，我們不知不覺中，把正在努力地實踐著看板，前方等待我們的，會有更多的驚喜和驚奇，拭目以待。
-不知者無畏，越深入，越敬畏，記錄此文，聊表紀念我們的看板之旅。
我的敏捷之旅
首先說說我對敏捷的理解 敏捷在於 敏捷本身 以最有效最快捷最簡單的方式解決問題，這是我對敏捷的理解。而且那些sprint，scrum，tdd，stand up什麼的，甚至是no hierarchy的結構，只是個形式，可以說是best practice。對於敏捷，我認為 在我和客戶之間，和我partn...
我的springMVC之旅 1
總想寫一篇關於springmvc的文章。可是一直不敢下筆。我只是乙個超級初級的spring菜鳥，總共接觸spring不到1個月。spring我真的沒有發言權。但是我確實看到了spring的強大，真的可以帶來軟體工程的春天。其實spring最亮的並不是mvc，而是強大的ioc 中文意思是控制反轉，又叫...
開始我的Linux之旅
確切的說,我是從華清遠見的官網上得知有個叫嵌入式linux就業培訓班的東西才對linux有些認識的,加之自己和微控制器打了2個多月的交道之後,也不知怎麼地,寢室的幾個傢伙發瘋似的開始玩fpga,sopc,matlab之類的東西,我自然不應該閒著,花了一段時間了解dsp,覺得要先學好數字訊號處理,慢慢...