本文作者:sodme
本文出處:http://blog.csdn.net/sodme
宣告: 本文可以不經作者同意, 任意複製, 轉載, 但任何對本文的引用都請保留文章開始前三行的作者, 出處以及宣告資訊. 謝謝.

引言：
博聞而後智慧，勤學更要多實踐。相比於以前，現在對於知識和資訊的獲取便捷程度，已有太大進步。但是，人的智慧卻似乎正因為科技的日新月異而變得愈加退化。相比於春秋戰國、先秦諸子時期的古人而言，現代的我們，無論在思想深度還是廣度方面，都只能甘願望其項背。很多東西，是一通百通的，我把這種一通百通能力叫作“開悟”。開悟，不僅僅在於你可以有很深的思想，還在於你可以把這些思想靈活運用於自己的工作和生活。對敏捷和SCRUM的理解也是一樣，剛開始，我只把它當作一種純技術層面的開發方式，後來我發現它的很多東西其實是一種方法論，再後來，我發現它的很多東西其實是一種生活和工作的態度。乃至於現在，我甚至將要把敏捷與佛教掛上勾了，這不是說我形而上學，而是，我發現了把思想用於實踐、從實踐進化思想的最大樂趣。

正文：

我們的團隊和產品，在發展過程中，經歷了很多個困難時刻，這些困難裡，既有技術方面的，也有人員方面的，既有我們自己能克服的，也有靠我們自己的力量解決不了的。但是，從始至終，我們都抱著一個很強烈的信念：作產品，而不僅僅是作技術; 作團隊，而不僅僅是作產品; 作好自己，而後再去影響和幫助別人。在我眼裡，產品是我們生存下去的唯一希望，而團隊則是作出產品的最核心因素。

囉嗦了這麼多，其實，我是想說，不管你採用什麼樣的開發方式，其出發點和落腳點，都首先應該是：把產品作好。在想著把產品作好的前提下，再客觀的分析團隊、產品、公司的現狀，而後決定你及你的團隊所走的路。即使一個被別人吹得再神的開發方式，拿給你用時，你也需要從自己的實際出發，看看哪些東西是有利的、哪些東西是無用的甚至是有害的，你要時刻清楚你想要的是什麼，而後再決定如何引進和採納。

我知道，很多人都很明白我以上所講的道理，只是，所有的問題最終可能都歸於：大家尚沒有足夠的能力去判斷哪些有益哪些有害，因而也就決定不了哪些應該引進，哪些應該捨棄。我想說，無論哪個團隊，也無論哪個個人，在其成長的過程中，都必然經歷過這樣一個階段，不同點在於，你站在一個什麼樣的角度去分析和處理這些問題。還是上面說的那句話：在這個時候，你需要從產品全域性的角度再反覆審視一下，哪樣作對產品最有利，就採取哪樣的作法。

請永遠記住：產品第一！只有這一點，才是我們最根本的、也最實際的目標。有了這一點，其它所謂各種各樣的開發方式，才有意義，否則，就是在浪費大家的時間，就是在教條化。

鋪墊了這麼多，現在讓我們進入正題，看看我們是如何以SCRUM的方式來驅動一個網遊專案的研發。

2006年8月，在我們的產品反覆折騰了很多個回合----無任何大進展的回合後，公司高層想在我們產品組推動一種新的開發方式：SCRUM。

在整個SCRUM開發方式方面，我們把一個專案首先分成：若干個“重大版本”，把每個“重大版本”又分成若干個Sprint階段。

每一個“重大版本”相當於以前我們經常所說的開發里程碑，而每個Sprint則是在“重大版本”這個相對較長的里程碑時間內對工作目標再細化，生成每兩週一個的更加可控的開發內容和可釋出的小版本。通常，一個“重大版本”的開發週期是兩到三個月，而一個Sprint的開發週期則是一至兩週。在“重大版本”和每個Sprint的工作目標裡，都明確列出了每一階段準備完成的內容。

此外，採用了SCRUM開發方式的團隊，在每天早晨，都會一個很簡短的晨會，我們團隊也不例外，團隊的每個成員在會上只說三句話：昨天完成了什麼內容，今天準備完成什麼內容，以及今天的工作需要找誰協調（如果有協調需求的話）。注意，在這個晨會上，我們特別強調每個團隊成員到底在昨天“具體完成”了哪些內容，不能太籠統，不能太含糊其詞，要明確，要具體，要能一說就讓別人知道你在作什麼以及已經作了什麼。

由此來看，對於一個專案目標，我們大致採用了以下的分解方式：

                              
                                     一個完整的產品(12~18個月)
                                                   |
                      -------------------------------------------
                      |                            |                            |
                  重大版本1(2~3個月)    重大版本2                 重大版本3
                      |
         --------------------
         |            |            |
      Sprint(2周) Sprint     Sprint
         |
    --------
    |         |
 Scrum  Scrum(每天)


在大家的日常開發中，我們通常都會遇到這樣一種情況：當專案剛剛開始時，我們都能很詳細的列出到哪個時間點作出哪些東西，而實際上，很多的專案，都不能按照預定的時間完成。那麼，這是為什麼呢？

這是因為，我們只在開始和結束兩個端點對產品進行了控制，而沒有對產品研發的漫長中間過程進行控制，或者說控制了但沒有很好的效果。事實上，在結束時再進行控制已經晚了，我們真正應該發力的點恰恰是這個“中間過程”。那SCRUM有什麼比較好的方式對中間過程進行控制嗎？當然有，那就是：“逐層分解”，而且，是切實可行、易被貫徹、可見成效的“逐層分解”。

如果僅從對一個專案的進度控制粒度上來說，我認為SCRUM方式更好的在形式上保證了對專案進度在更細的粒度上進行更有效的控制，從而更好的保證產品可以成功：把一個開發週期在12到18個月的完整產品，先分解成2~3個月的研發短週期，進而又把這2~3個月的時間再細化，劃分成2周粒度的Sprint目標，而具體到了每一天每一個人的開發任務上，又讓每個人明確了自己今天和明天要作的事，同時大家也能明確知道未來兩週自己的開發目標。

很多公司和很多團隊，整天在喊我們沒有執行力，我們一定要提高執行力。什麼叫執行力？怎樣才能提高執行力？我認為，如果保證了這樣的控制力，就一定可以產生執行力。

如果從對整個專案的分解層次來看，SCRUM方式，很強調對於專案的控制力，同時，也很強調儘快推出版本的能力。作網際網路產品，特別是作網遊產品，絕大多數的團隊由於水平、經驗等諸多方面的原因，都無法保證自己作的東西就一定是符合使用者需求和玩家喜好的，所以，我們需要在正式版本之前不斷投放一些先期測試的版本，先行開放一部分功能給使用者嘗試體驗，開發團隊在這種反饋的基礎上再對設計進行調整和完善。

我以前曾經說過，比起傳統軟體開發，採用了敏捷開發的團隊，在研發理念和深層次思想上，已經有了太大的不同：傳統軟體開發方式，把一切都設想得太好，假定世界美好、使用者需求相對穩定，所有事情按步就搬，缺乏活力和創新；而敏捷開發，很務實，它首先承認我們不可能弄出一個完美無缺的版本出來，然後提出了一系列如何把產品從不完美變得逐漸完美的方法，在這些方法裡，“儘快釋出最新可用版本”成為一種最為有效、務實的手段。

SCRUM作為敏捷方法論的一種實踐方式，它自然也是朝著這個目標走的：儘快開發，儘快測試，儘快釋出可用版本，儘快讓使用者體驗，儘快讓開發團隊知道自己的不足，這樣又反過來激勵開發團隊把產品作得更好。

而產品作好了，公司可以贏利，團隊就能生存下去，這些都是很實際的問題。

我們為什麼這麼強調“儘快釋出版本”？從更深層次的思想上，是因為我們承認並堅信：使用者，只有使用者，才是對產品是否好用、是否有用的最有效裁判者，而不是設計者本身！作傳統軟體時，可能你的使用者只是一兩家企業，你可以整天泡在你的使用者那裡，把各方面的需求瞭解得清清楚楚、明明白白、真真切切，但是，網際網路的使用者動輒千、萬計，甚至百萬、千萬、億計，你無法靠一個設計者的腦袋去考慮清楚這麼多人的需求和喜好，你只能儘快提煉出他們需求中最重合的、“你自以為有用”的需求，而後儘快把想法實現出來，把可測版本推到使用者面前，去驗證你的設計，然後再儘快推出新的版本來滿足你從使用者那裡得到的新有效需求。

從某種意義上來說，這種開發模式下的軟體形態，是一種周而復始、不斷進化的過程，它甚至已經超越了我們以前所瞭解的傳統軟體生命週期模型。驀地，這讓我想起了佛學裡所說的輪迴，是的，只要這種開發方式下出來的產品走上良性迴圈，它的存在形式本身就是一種輪迴。

下一篇文章，我將繼續與大家分享我的敏捷和SCRUM體會，主題將是：如何具體規劃每一天。