在看了一些scrum電子書之後，我開始嘗試在團隊內部推廣這種敏捷方法。開始能採納的也是小範圍的動作，畢竟開始不知道如何走，沒法把所有的流程一下子全部改掉。站會，scrum白板是我們主要的執行手段。可是，經過了乙個月，我們發現站會用掉了我們非常多的時間，非常沒有效率。於是，我們停止了敏捷的腳步。
過了半年，情況發生了變化，公司總部開始推廣scrum方法，我這裡很幸運的接受了兩次培訓。通過兩次培訓，從領導到團隊成員，都有了敏捷的概念，有了統一的認識，都認真的按照敏捷的方法去操作。
經過了1年半的scrum執行，我們每2周發布一次，對於bu的角度來看，我們每次release都能出不少東西，效率上面跟其他的研發團隊相比很是不錯。在公司總部，我們是scrum成功執行的標桿，我們是很值得信任的。
敏捷成了！且慢，在實際執行中，我們還是發現有很多不完善的地方。
首先，產品需求可不是定期來的。每個sprint當中都會有緊急task要求在短時間上線的情形。而且由於bu人員變動，需求文件質量一直不高，很多問題需要邊開發邊溝通需求。這樣很多任務做做停停，需要拖延很長時間才能完成。緊急任務，大任務，這些都不是scrum標準的處理情形。我們又不願意花費太多的時間在任務分解上面，該怎麼辦。。。
其次，scrum只規定了管理上面的一些process，但是對於研發流程本身沒有任何的規定。我們準備補充design review, code review，但是該如何落實呢？我們只能開會的時候強調，再強調。。。
第三，scrum關於任務的估算是乙個問題。我們按照故事點，團隊打撲克的方式來定。但是以前團隊成員和任務變化大，始終無法計算準確的開發速率。現在終於每個sprint故事點數保持恆定了，但是由於分解不細緻，經常有任務跨sprint。我們無法拒絕緊急任務，那我們該如何衡量我們的生產效率呢？
第四，scrum在定義dod上面，我們認為是qa tested。但是產品上線經常也要花費不少精力。這些沒法體現。
為了嘗試解決上面的問題，我們開始了更深入的敏捷之旅。
我的敏捷之旅
首先說說我對敏捷的理解 敏捷在於 敏捷本身 以最有效最快捷最簡單的方式解決問題，這是我對敏捷的理解。而且那些sprint，scrum，tdd，stand up什麼的，甚至是no hierarchy的結構，只是個形式，可以說是best practice。對於敏捷，我認為 在我和客戶之間，和我partn...
敏捷之旅 杭州站
今天去參加了 敏捷之旅 杭州站 聽了下來自 代表的演講，感覺學到了點東西 一 對於web應用開發的新認識 developer 需要工程師文化，主要負責資料運營支撐 1 3人，但不要超過3人 tester 持續整合自動化測試 1 2人 前端 js 提公升頁面效能，尤其是需要考慮使用者網速有快有慢的差別...
敏捷全球之旅 廣州
今天廣州天氣陽光明媚，我很高興能參加 敏捷全球之旅 的講座，親臨scrum大師vernon stinebaker 中文名 史文林 的精彩演講。趁著身上尚有敏捷的 餘溫 記錄一下今天的體會。vernon stinebaker 的背景 博克軟體杭州的技術與架構總監。他是目前國內僅有的兩位scrum聯盟的...