硝煙中敏捷的咱們

記得公司大張旗鼓轟轟烈烈的開展敏捷是在前年的十二月份。當時公司剛來了一個項目經理A君，處於各類需求敏捷就在那時開展了起來。當時公司買了一本關於敏捷的書《用戶故事與敏捷方法》。可是感受當時搞的太形式化了，就像解放伊始的大生產運動。對頭一年過去了基本上如今項目又恢復了一片混戰的狀態。如今回憶起來簡直就像一場鬧劇，堪比喜劇。歸結一句話不敏捷的人你用什麼方法都沒辦法是整個團隊敏捷起來。

一個技術團隊中頭兒決定了這個團隊的方向，成員決定了這個團隊的戰鬥力。其實每一個程序員都應該是全棧工程師，尤爲是對於創業公司來講。主動進入而且可以進入創業公司的開發者都有這些潛質，並且創業公司正好提供了培養全棧工程師的沃土。上到需求下到運維，而後開發用到的各類技術，數據庫，編程語言樣樣精通。我崇尚兩種文化，一種是狼文化，一種是海盜文化。前者是我我的對這種神聖的動物比較熱衷；後者深受《Steve Jobs》這本書中的感觸。每種團隊都有本身的文化和觀念，可是重要的是堅持貫徹下去。

《硝煙中的Scrum和Xp》這本書很早就從InfoQ下載下來了。這本精簡版書自己很是的薄就一百多頁，一天時間就能夠看完了。下邊是一些筆錄。

團隊和項目負責人如何左右一個Sprint中要完成哪些故事：

    1. 假如項目負責人感受某個故事是須要加入進來的，那麼它能夠這樣：調整估時的優先級；或者縮小現有估時的範圍。

    2. 團隊成員能夠憑藉經驗直覺來左右一個故事是否加入這個Sprint；借鑑以往的生產率。

生產率的計算公式：

生產效率估算方式：直覺反應、基於昨日天氣的生產率計算、基於可用人-天和估算投入程度的生產率計算

對每一個故事的估時：能夠每一個人通過完整的思考，而後輸出本身心中的數字，若是差距不大則沒問題，可是若是兩我的的偏差很是大的話則要從新討論了。這個也能夠綜合考慮技術的實現方案，難易程度，多由程序員完成較好。

確保每一個成員對故事是有必定的理解的，也就理解的需求是對的，不然會形成估時的偏差，若是Sprint已經開始也會形成一些沒必要要的工做。如何解決這個問題：能夠經過豐富每一個估時，好比如何demo。

技術故事：技術故事是開發人員提出的一些需求，好比重構，部署服務器。這些估時產品負責人是不會關係這些東西的，由於這些東西不能帶來直接的利益。可是一個技術性的項目這些東西是基礎，因此也要擺在一個重要的位置，說服產品負責人。   

測試驅動開發：測試驅動開發意味着你要先寫一個自動測試，而後編寫剛好夠用的代碼，讓它經過這個測試，接着對代碼進行重構，主要是提升它的可讀性和消除重複。整理一下，而後繼續。

整本書讀下來沒什麼特別東西：就是一個公司試試敏捷今年後的一些經驗教訓總結。其中的一些章節我沒有看「多個團隊的敏捷管理」、「跨地域團隊的敏捷管理」這些章節也不是我想看的。不過是敏捷也好仍是團隊內部總結出來的一套管理方案也好，都須要不斷地調整調試總結提升。和技術同樣這方面也沒有銀彈，適合本身的纔是最好的。

在這個浮躁的社會如何讓團隊內部的人踏實下來纔是最重要的，對於一個創業公司從上到下更是要踏踏實實的纔是。這是一個創業者的年代，可是沒有幾個成功的，一百個都沒有一個。任何管理方式最終都落實到執行力上，團隊管理制度要有絕對的執行力，團隊成員要有執行力。咱們團隊的一個例子：基本每次晨會中總會有幾我的彙報着幹了幾天的工做。這是團隊管理者最好可以瞭解一下他們的工做，若是任務安排合理，恐怕這些人是出現了什麼問題。若是這些人拒絕把本身的工做交代清楚，或者支支吾吾，就得采起一些措施了。這些人繼續在團隊都會影響整個團隊的紀律。

對了上邊還提到了多總結，這個恐怕是團隊最不想作的事情了。至少咱們團隊是這樣的，第一個Sprint試試的最好，各項工做安排進行的都比較正常。而後慢慢慢的就沒有而後了。到中途晨會A君都不想再去組織。若是沒有對每一個Sprint的總結的話就會形成咱們這樣的後果，至少咱們要計算一下每個迭代的生產率，完成程度，觀察燃盡圖等等，以便於下個迭代可以更高效。有始無終絕對不是好事。

還有一個就是對於Bug的管理，這個東西一會是讓我比較頭疼的東西。永遠不要縱容一個Bug，由於這個東西會產生雪球效應，越攢越多，到最後不想有人碰。每一個迭代作好可以抽出一天來衡量一下這個迭代的bug，儘可能斬盡殺絕。再者說若是bug增加正向的話，該看看代碼質量了。哎，說多了都是淚水。