很久沒有寫技術(shù)文章了，公司一直以來都在不斷嘗試Scrum模式的敏捷開發(fā)，為了了解如何能夠更好的處理在項目實施過程中的團隊碰到的問題和加深自己對Scrum的理解，于是在網(wǎng)上找了些書籍和資料，的確原本的英文資料和InfoQ上的資料也非常多。然而無意中發(fā)現(xiàn)有人推薦 《輕松Scrum之旅》這本，因此就買來看看，果然發(fā)現(xiàn)本書寫的模式非常有意思，以一個傳統(tǒng)開發(fā)團隊如果過度到實施Scrum的團隊，其中有很多小故事都是非常精彩和實在。其中不缺乏對Scrum理念的詮釋。以關(guān)毅和David的郵件對話模式就是一個很好的例子，其中說明到很多團隊在實施Scrum過程中都可能會碰到問題，比如團隊人員變動和臨時需求，開發(fā)和測試團隊的合作等方面的問題。當(dāng)然還包括Scrum團隊的管理和各種能夠幫助團隊提高的各種經(jīng)驗，甚至將Scrum的理念引伸到現(xiàn)實生活中，如對餐館服務(wù)生，裝修房子工人工作的管理等，這無一都反映了Scrum的敏捷精神。其實敏捷不僅僅反映在軟件開發(fā)過程中，而是可以應(yīng)用于生活很多場合。這本書我斷斷續(xù)續(xù)的看了一個月，差不多翻了兩遍還是有了不少收獲。的確還是挺佩服這本IBM團隊出的書，能夠以這種方式來說明很多東西，而不是長篇大幅的理論。總體來說是本不錯的書籍，不過如果非要指出這本書需要改進的地方，我個人倒覺得很有必要在以下幾個方面做些增強：
跨團隊交流(cross team communication)，現(xiàn)實中很多公司的開發(fā)團隊可能不像書中的那么少人，書中北京這邊只是關(guān)毅一個人是Scrum Marster。比如我們公司一個項目內(nèi)就有3個開發(fā)團和一個測試團隊，也就是可能會有4個Scrum Marster，因此每個sprint都會有比較多的任務(wù)。通常來說主要是GUI和Beckend，Report三部分，很多情況開發(fā)團隊之間就想選擇自己團隊比較熟悉的那塊，所以在產(chǎn)品負(fù)責(zé)人(Product Owne)在做planning game過程之后，分豬肉(product backlog)的時候，大家都想拿自己熟悉的東西。而其實這個是多少有背于Scrum的每個成員都盡可能了解到產(chǎn)品更多東西的理念。因此在我們團隊大佬們都比較靈活，一般會輪詢來做，比如這個迭代(sprint)這個團隊重點做了GUI方面的東西，可能下個Sprint就側(cè)重做Beckend方面的東西。這樣有利于整個團隊對整個項目的理解，同時可以發(fā)現(xiàn)更多的問題。因此如果本書能在加入Scrum marster 之間的一些交流場景進去，估計更豐滿點:).因為在我們實施過程中發(fā)現(xiàn)不同團隊Scrum marster之間的協(xié)調(diào)也是非常重要的，也就是老大之間PK一下如何"分贓"以及"分贓”是否均勻等。
另一個方面的就是產(chǎn)品負(fù)責(zé)人(Product owner)這一角色的“戲”表現(xiàn)得不夠詳盡，其實在現(xiàn)實中這個角色會非常的重要和敏感，因為客戶的任何新的需求變動都會從他那反映出來，而在做Playing game(了解需求概略會議)的時候會對backlog做出相應(yīng)的講解，使得團隊人員首先能夠有個感性的認(rèn)識，基本上了解用戶的需求即需要做的東西有哪些。其中哪些優(yōu)先級高優(yōu)先級低的功能都有一個大致的理解。這方面在我們團隊實踐過程中我感受是最深的就是，有時候一個sprit都開始了幾天又發(fā)現(xiàn)用戶的需求做了變動，使得前幾天的工作幾乎是白費了，這個非常打擊士氣，而且時間又花了。當(dāng)然這個時候Product owner也會對這個迭代的任務(wù)(backlog)做相應(yīng)的調(diào)整等方面的處理，不過這恰恰反映了Scrum敏捷模式的優(yōu)點，任何新的變動能夠及時的知道。
團隊分享(team sharing)方面，這個包括技術(shù)方面的分享和一些經(jīng)驗方面的分享，當(dāng)然書中也有說到請求其他部門的開發(fā)人員做PDF導(dǎo)出等方面的技術(shù)問題。也就是說也做了些團隊分享方面的事情，而我覺得這些不是很夠，就我們的實踐經(jīng)驗來說，基本上每給sprint我們都會有些sharing，如開發(fā)工具，框架，各種技術(shù)熱點和經(jīng)驗等等。內(nèi)容基本都不局限，另外還有個很有意思的是，其他團隊做Sharing的時候，我們有時候也會派一個“間諜”(Spy)去旁聽，碰到好點子就拿來和本團隊成員分享，這個的確是很有意思的過程。同時本書中沒有看到關(guān)毅他們團隊做一些類似團隊創(chuàng)新(innovation)活動，其實有些公司還是有這種小活動。類似的我們團隊每周五 5點到6點都有一個小時的自由討論創(chuàng)新活動，大家可以分享些創(chuàng)新方面的想法，最終整理可能會形成一些對產(chǎn)品或有用的東西，我個人認(rèn)為這個是很值得推廣。很多公司就是因為把大家每天都搞得太忙了都沒有時間去思考改進或創(chuàng)新方面的問題。一天在那里抱怨員工設(shè)計出來的東西沒有創(chuàng)意，壓根就沒有給員工思考的時間，上來就寫就編碼。說到這還真羨慕google，據(jù)說每周五都可以放下工作，做些想做的東西，所以google才有了那么多創(chuàng)新的東西。
以上都是個人的愚見，歡迎大家拍磚，分享經(jīng)驗，尤其希望本書作者看到了拍磚:)，個人聯(lián)系方式在首頁。