敏捷的原則敏捷開發其實並沒有標準型的流程。scrum也只是眾多衍生體中的乙個。實際上就算是scrum的實際使用也情況千差萬別。所以首先，請大家有這麼個概念：
敏捷開發絕對不是一套一成不變的標準化流程。而更多的是一種自適應，自我優化的流程優化理念。
並沒有一定的流程，而是需要大家有對任何自己覺得不對的，不正確的，效率低下的事情的警覺性，和將之提出來並進一步改正的行動力。其次，敏捷之於遊戲開發，則更要體現人對遊戲本身品質的把握，而非對各種文件的審核，這就是和傳統軟體開發區別最大的地方。所以，沒有最好的流程，只要是合適並且能夠持續優化的流程就是好的。
所以：l不一樣的專案經理會有不一樣的流程
l一樣的專案經理，不一樣的團隊，也會有不一樣的流程
l一樣的專案經理，一樣的團隊，每隔一段時間，都還會有不一樣的流程。
迭代想與得
為什麼我們要迭代？
l我們的設計不一定是我們真正想要的
l文件內容在我們想象中和實際體驗版本時的感受不相等
l我們沒法100%的思考到所有需要思考的角落
同樣，要理解為什麼要使用迭代，我們需要明白迭代開發從何而來。最初，軟體開發行業中，一般都由需求方提需求，開發方拿到需求開始分析設計，一次性開發成型交付。隨著行業的發展，軟體複雜度的增大，需求變化的增加，大家發現一次成型的版本往往無法滿足需求方的需要，於是返工。當這樣的情況多了之後，返工就成了一種標準化的流程，系統化的返工其實就是我們所謂的迭代了。當然這是一種比較民間的解釋，但是在遊戲產業中，這也說明了：
l迭代的目的是為了應付需求的變化。
這裡的需求變化需要我們的額外注意：
l遊戲產業中的需求變化，並非只是指策劃或需求方在中途站出來說自己的想法有變。更多的時候，是自己在進行遊戲開發的過程中，出於對開發的遊戲的認知的加深產生的需求設計的變化。一般來說遊戲的需求**於設計，但是我們的設計卻往往並不是我們真實的需求。或者說，我們的設計往往不能滿足我們真實的需求。
當我們清醒地認識到：
l無論我們在設計上花多少時間，我們都無法完全消除設計的實際效果和預期的差距。甚至在超過某種程度之後，我們花在設計上的時間將會形成浪費（這就是所謂的over-design）。
我們就應該開始考慮，什麼時候設計應該停止，什麼時候我們就應該開始先做，然後預留足夠的時間，把那些可能出現的，和必然出現的問題，留給我們後續的迭代來發現和解決。而不是把這些問題試圖在一開始全部解決掉，第一，不現實，第二，不科學。
旋轉上公升
什麼是迭代
那麼，迭代究竟是什麼？
首先要申明一點是，其實我們現在談論的迭代並不是純粹的迭代，而是迭代加增量開發。純粹的迭代是指沒有新需求的加入，第乙個版本實現的內容就已經完整，之後的版本只是之前內容的優化。而增量，則指下乙個版本是在上乙個版本基礎上增加內容的開發形式。
那麼，迭代加增量開發的意思就顯而易見了，而我們需要的開發模式就是這種：
l在不斷以版本為基礎的增量功能開發的基礎上，不斷對已經有的功能進行完善和優化。這就是狹義的迭代
進一步來講，廣義的迭代，則不僅限於我們的功能開發。而且還要對於我們本身的流程，工具，工作方式，方法，習慣等等所有可以改變，可以優化的地方進行優化，進行修改。最終的目的就是通過乙個個版本迭代開發，不只功能品質在變好，團隊效率，團隊流程等各個方面都會變得越來越好。最終形成乙個真的具有戰鬥力的團隊。
週期總結會議，以及一系列的問題改正，優化提高事項，以及平時提倡的交流，對於變化的擁抱等等，都是為了這個目標而發生的。所以，
l敏捷開發是一種精神，而不是一種固定的形式。我們需要有一切都是可以改變的心態和準備，並且真的可以著手去改變任何我們覺得有問題的東西，這樣才能真正發揮敏捷迭代開發的優勢。
陀螺的轉動
如何迭代
迭代的漩渦
首先，我們抽象一下，以便大家能簡單的明白迭代的形式。迭代就像是乙個漩渦，從漩渦中心開始旋轉，越轉越大。而處於迭代最中心，所有的東西都圍繞它來轉動的那個核心，就是我們的產品訂單（故事清單）。
而那條旋轉的線，就是我們的版本。版本永遠圍繞著我們的故事清單來開發，（故事清單，抽取於我們的遊戲的設計），版本總是由故事清單裡尋找需要完成的功能，再將根據實際版本得到的反饋，並更新故事清單。於是功能清單的功能越發的有價值，而版本本身也會越來越有價值。
迭代的步驟
那麼，我們的版本該如何圍繞我們的功能清單來畫這個漩渦？
首先，漩渦是乙個環繞的圈，所以我們先確定圈的長度：
l 乙個迭代的長度
再進一步深入：
在這線段的開頭，我們要從產品訂單中取得什麼？故事。什麼樣的故事？價值（優先順序）總和最大，且大小（故事點）不超過我們乙個週期工作量的故事。僅僅如此麼？當然不是，首先，有乙個重要的概念：
l系統
也許有幾個故事隸屬於同乙個系統下，它們共同組成了這個系統，它們全部完成，或者至少關鍵部分完成。這個系統才是完整的。當系統不完整的時候，這些功能的樂趣根本無法體現。
那麼，有可能當我們選擇這個週期開發某個**值功能時，沒有開發相應的屬於乙個系統的其他低價值功能。於是週期末的版本我們發現，由於系統的不完整，這個功能樂趣甚微。如果對這種涉及系統的問題沒有認識，那麼我們很可能就會對這個**值功能有錯誤的認識。（關於系統理論的知識，請參見wiki系統學一詞）
如何避免這個問題？這個時候人的作用就體現出來了。當然我們可以在故事列表上增加一列系統屬性，提醒我們。但根本的方法還是乙個或者多個對整個故事列表有著足夠把握能力的人來進行掌控。
我們需要有人能夠全面的了解設計意圖，並且對我們的故事列表進行把關，對我們週期開始的需求選取進行主導。有一點大家應該明白，規則和標準都是人制定的，那麼我們究竟是依靠標準和規則來更好的控制結果，還是依靠人本身？是完善更好的標準，還是培養出更能把握質量的人？
接下來，線段中的開發過程，本質上其實就是分析需求，制定計畫，開始開發。或許會週期內分為更細小的週期進行迭代。但是這些小迭代其實依然是瀑布式開發，這點毫無疑問。區別只是在於，這樣的小週期內，我們開發的思想和方針是以敏捷開發的思想為指導的，我們更注重版本，更注重交流，更注重結果。而不是預定義式的開發流程（pre-defined)。
迭代的節奏
在迭代中，我們還需要注意我們迭代的節奏，什麼時候該鬆，什麼時候該緊。什麼時候我們允許大家的發散和更多的思考。什麼時候我們應該專注於我們的目標並且忽略其他的一切以得到我們最終的版本。這些都是有所講究的。
這節奏包括各個方面。那麼究竟這樣的節奏應該如何來走呢？
在乙個迭代之內，我們的節奏應該是先鬆後緊。當然不是說迭代開始時我們的效率可以放緩。這裡的先鬆，是指在一開始時我們可以有更多的想法和思路，更多的**和研究。本來我們的迭代工作就是從粗到細，從模糊到精確的進行。在迭代中，我們也如此一步步明確我們的工作。
一旦目標明確，那麼迭代週期sprint的名稱的含義就出來了：我們向著我們的目標衝刺而去。到了這個階段，我們需要收縮我們的討論和想象，一切以最後的版本和質量為前提。以盡可能快的速度來開發我們的功能，提高我們遊戲的質量，得到我們需要的結果。
敏捷開發基本思想
敏捷開發是由一些業界專家針對一些企業現狀提出了一些讓軟體開發團隊具有快速工作 響應變化能力的價值觀和原則，並於2001初成立了敏捷聯盟。他們正在通過親身實踐以及幫助他人實踐，揭示更好的軟體開發方法。通過這項工作，他們認為 個體和互動 勝過 過程和工具 可以工作的軟體 勝過 面面俱到的文件 客戶合作 ...
敏捷開發思想與實踐
我想敏捷的思想大家都能說出一大堆來，我也不囉嗦了。在此只是談談自己的一些想法和觀點，希望大家拍磚，謝謝。1 整理需求，分析，總體設計，先把握住總體，忌拘泥於細節。2 先找到乙個可以快速突破的點，根據專案的實際確定第乙個迭代。3 敏捷的關鍵是快速的交付客戶，哪怕只是最簡單的demo，這樣便於與客戶交流...
敏捷開發基本思想
本文主要總結一下敏捷開發模式的基本思想 1 測試驅動開發 tdd 敏捷開發中，測試是在功能實現之前。就是要實現乙個功能，首先根據業務需求，寫出相應的測試，然後再寫功能 使得每個測試都可以通過。可以將每個功能做成乙個story，然後針對每個story編寫測試。2 小版本發布 frequent rele...