公司作爲設備提供商，不斷開發新的產品，升級舊的產品，解決產品使用過程中發現的問題；我們作爲網管研發團隊，不斷把新產品納入網管系統，增加新的網管功能，協助解決工程應用問題。本質上說，這是一種以增量開發爲主的模式。但一直以來，公司都是以項目製爲基礎在管理研發工作，以經典的瀑布模型作爲標準的研發流程，公司通過CMMI3級認證的研發流程，也是以瀑布模型爲基礎。公司建立任職資格體系，也是以參與的各種規模項目的數量等作爲評估的成果依據。
私底下一直感覺這種模型並不太適合於我們這種以增量開發爲主的研發流程，CMMI運行的效果也不佳（實際上很少有項目完整執行CMMI流程）。這個問題困擾了我們很久，始終沒有太好的思路來解決。一直到我看到了Scrum，學習瞭解並少量應用了Scrum形式之後，感覺這纔是比目前瀑布模型更適合我們的開發模式。
作爲一種敏捷開發模式，Scrum強調團隊自管理，強調快速迭代，有清晰的組織形式，其自由開放的新理念也易爲團隊成員所接受。但是會對現有的研發管理框架造成大的挑戰，特別是在滿足公司市場戰略，員工績效評估等方面(我們已經習慣了項目由上面派下來，經理計劃安排工作，團隊成員執行的“常規”做法）。如果實施，這是一場從上到下的理念變革，如何保證公司、員工在這場變革中雙贏甚至多贏呢？公司的市場目標、產品目標能否達成，員工是否能更有活力、更加投入，保證項目質量、進度，從而爲公司、也爲自己創造更大價值？
俗話說，一切重在“執行”，國外傳來的這部“好經”，會不會被中國和尚念歪了（就像CMM ^_^)？我們怎樣才能把Scrum學好、用好？竊以爲可以從以下幾個方面入手：
一，確定你的企業高層能否全力支持，這是企業中任何重大變革成功的關鍵。否則一個命令壓下來，團隊自管理就會成爲泡影。
二，確定你的企業文化是自由、開放型的，能承受新理念的衝擊。經理們能否放棄控制一切的慾望，員工們能否做好自我管理工作任務的準備？
三，確定你從哪兒開始Scrum，找一個合適的試點團隊、試點項目。
四，培訓宣講，讓團隊成員們統一思想，使得大家都瞭解具體的方法、過程、和角色分工。他們大多數將會是貢獻出一切的開餐館的“豬”的角色，沒有他們的理解支持，什麼都將成空。
五，找好你的Scrum Master，找一個好的Scrum Master，確定你的Product owner。（好象沒有項目經理，那他幹什麼？哦，我也不知道。）
六，開始吧
雖然有了這些構思，但還沒有成爲現實。Scrum，我們應該擁抱你麼？