scrum
並不是什麼高深的管理方法，
scrum
的科學原理中，沒有什麼是值得被拿出來，放在學術界討論的東西，就連其估算方法，也是使用了看似遊戲一般的撲克牌估算法，實在是難登大雅之堂。
scrum
的指導原則很簡單，沒有把軟體開發中的所有的事情都詳細的規定，或許可以說，
scrum
只明確闡述了極少數的幾個問題，
scrum
容忍混亂，甚至是一種對於混亂的妥協。但是
scrum
成功了，在很多領域中都獲得了巨大的成功，究其原因，在於
scrum
抓住了軟體開發中最終要的因素：人的管理。不同於傳統的開發方法集中於對過程的探索與執著，
scrum
完全拋開了繁瑣的過程，把軟體開發重新放在了人的身上，
scrum
妥協，容忍混亂，不使用複雜高深的管理方法，就是在於他要將人凝聚成乙個團隊，讓團隊來完成軟體，而不是讓規則、標準、過程和文件來完成軟體。 我的
scrum
和遊戲開發管理經驗來自於我的工作，我所在的公司是一家軟體研發管理工具**商，幫助全世界的遊戲公司管理其開發過程，也包括了中國的遊戲公司。我所深入接觸過的十餘家大型遊戲公司，全部對敏捷開發表示了強烈的興趣，我也親自幫助其中的部分遊戲公司的多個遊戲專案組實踐了敏捷開發，並取得了良好的成績。
我在今年早些時候或了的
scrum
聯盟授予的
scrum master
認證，在參加認證課程的過程中，引發了我對於
scrum
和遊戲開發的深入的反思。
看了scrum
的科學原理和遊戲專案開發遇到的問題，我們不難發現他們之間存在著很多相
似的價值觀。
scrum
希望能夠在最短的時間裡完成最**值的功能，遊戲也是如此，策劃們會提出海量的需求，永遠不可能做完，又要在規定的時間上線，這就使得遊戲開發團隊不得不在規定的時加內，完成最**值的需求
scrum
擁抱變化，不做完美的需求文件，而是在每個
sprint
結束後，對產品
backlog
重新進行一番審視，主動地去接受變更，改變產品
backlog
，以確保能在下乙個
sprint
內開發出最重要的內容。遊戲團隊開發也是如此，策劃人員需要不停的根據玩家反饋、市場變化等因素來調整遊戲的策劃案，開發團隊需要以一種積極應對的方式來處理策劃變更。
scrum
不做完美的開發計畫，多變更的環境中，沒有任何乙個計畫能被良好的執行，如果我們不能執行乙個既定的計畫，那麼我們不如不制定這種計畫，而是用另外的方式，基於承諾的方式來完成開發工作。有過遊戲開發經驗的人都知道，遊戲開發根本不能按照既定的計畫進行，但是不計畫又沒法管，而
scrum
正式提出這種非計畫驅動型的研發管理方式。
遊戲中很多文件的價值很低，如功能分析與設計文件，當產品被製作好以後，這些文件便沒有了任何價值，乙個功能和其他功能的關聯，也都在策劃文件中有詳細的記錄，因此在開發過程中，根本不會尊尋傳統軟體開發中的先文件再開發的方法。同屬於敏捷開發的
scrum
方法也堅持交付有價值的功能，從而盡可能減少不必要的文件，這也正和遊戲開發的做法完全吻合。
遊戲對於產品質量有極高的要求，普遍高於一般的軟體，傳統的開發方法，不論是瀑布、
rup，總是會在開發後期時間內出現
bug大爆發，團隊疲於奔命的應付
bug的局面，對於功能高耦合度的遊戲而言，這簡直是致命的。
scrum
倡導風險前移，對於「完成」的概念有明確的定義，每個
sprint
都以產品演示和評審作為結束標誌，這對於提高產品質量，起到了關鍵的作用。
從以上這幾點來看，
scrum
的價值觀和遊戲開發管理價值觀完全的吻合，
scrum
完全可以運用到遊戲開發過程當中。
然而，當遊戲團隊的專案經理們閱讀了敏捷開發、
scrum
的一大堆經典著作之後，大都提
scrum
倡導弱分工，小團隊應用。在強分工和大團隊的遊戲開發專案中，
scrum
是否已經失去了它的立足的根基？
出了乙個相同的疑問：
實施敏捷，尤其是要實施
scrum
，就意味著我們要徹底改變傳統的，計畫驅動型的開發方法，這個改變不但包括了專案管理思路上的轉變，對於團隊的劃分、專案流程，乃至工作方式，都要發生改變。同時改變也是雙向的，開發者在改變的同時，
scrum
也要根據遊戲公司的實際環境發生相應的改變。
scrum
實施成功的關鍵，就是做好從傳統向敏捷的轉變，
scrum
實施的最大的風險，就是
scrum but
，意思是說，雖然我們實施了
scrum
，但是我們卻沒有遵守
scrum
的核心要求做事情，也就是說沒有做好徹底的轉變。
scrum but
導致了大量嘗試
scrum
的團隊失敗，並嚴重的誤解了敏捷與
scrum。
在接下來的文章中，會詳細說明團隊在使用
scrum
中所作出的改變，以及這些改變的出發點及其重要性。
很抱歉，因為商業保密問題，在這篇文章中，我不能說明任何一家我所接觸過的遊戲公司的實際管理方法，連公司及其中的任何人員的名字等資訊也不能使用，所以在下面的文章中，我會使用
t公司來代表我所接觸過的全部遊戲公司，在下文中所使用的公司、專案、人員名稱以及時間點均為虛構，請勿對號。 t
公司是國內一家網路遊戲開發、運營公司，有自己的開發、運營團隊，
t公司在遊戲開發領域經營多年，有豐富的遊戲開發經驗。從去年開始，
t公司開始正式在其中乙個專案組中嘗試使用敏捷開發方法，在這之前，
t公司也一直嘗試著在其開發方法中融入敏捷因素，但是一直沒有正式的使用純粹的敏捷方法。
該專案是乙個新的網路遊戲研發專案，專案經理是老紀，老紀雖說叫老紀，其實年齡並不算大，資歷確實很深，曾經當過很長一段時間程式設計師，後來領導過兩個個遊戲專案，都取得了不錯的成果，老紀並不是敏捷開發的忠實擁護者，對於敏捷開發的了解也是在實踐敏捷的過程中逐漸積累起來的。但是他很樂意接受敏捷和
scrum
能夠帶來的好處，因此在我們的幫助下，他很快的在他的專案組中實踐了
scrum
，並獲得了良好的結果。
下面我們以
t公司中老紀的專案組實踐敏捷開發的故事來說說
scrum
是如何被運用的。在下面的實踐中，你可能會發現我們對傳統的
scrum
作了大量的改變，但是我們依然把握了
scrum
的最核心本質，
scrum
的團隊構架，還有
scrum
的最重要的實踐活動。
Scrum中的團隊速率
一輪迭代完成的故事點就是專案的速率。為這個專案做計畫時，我們可以用已知的速率，我們也可以自己假想乙個速率。速率是乙個有用的管理工具，所以在每輪迭代結束和迭代中監控團隊的速率是很重要的。測量速率 多數故事很容易清點 團隊在迭代中完成了這些故事，所以他們的點數全部計算在內。假如乙個團隊某個迭代中的速率是...
omnipeeker在wifi分析中的應用
記得大學學習tcp ip協議時，tcpdump給了很多幫助，最近需要好好了解一下802.11x mac層，在業內高手的推薦下發現了omnipeeker這一利器。下面和初學者分享一下這個軟體的使用。從無線特性看，電磁波的發射方是沒法限制接收方的，只要在覆蓋範圍內，任何人都可以用相關裝置收到訊號，也可以...
zookeeper在storm集群中的應用
1.心跳檢測,儲存supervisor和worker的心跳 包括它們的狀態 使得nimbus可以監控整個集群的狀態，從而重啟一些掛掉的worker 2.提交任務 3.儲存整個集群的所有狀態資訊,供ui顯示 4.storm在zk上的儲存結構 storm在zookeeper上的根目錄 預設為 storm...