中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

敏捷開發思想談
敏捷的原則

敏捷開發其實并沒有標準型的流程。SCRUM也只是眾多衍生體中的一個。實際上就算是SCRUM的實際使用也情況千差萬別。所以首先，請大家有這么個概念：

敏捷開發絕對不是一套一成不變的標準化流程。而更多的是一種自適應，自我優化的流程優化理念。

并沒有一定的流程，而是需要大家有對任何自己覺得不對的，不正確的，效率低下的事情的警覺性，和將之提出來并進一步改正的行動力。 其次，敏捷之于游戲開發，則更要體現人對游戲本身品質的把握，而非對各種文檔的審核，這就是和傳統軟件開發區別最大的地方。 所以，沒有最好的流程，只要是合適并且能夠持續優化的流程就是好的。

所以：

l不一樣的項目經理會有不一樣的流程

l一樣的項目經理，不一樣的團隊，也會有不一樣的流程

l一樣的項目經理，一樣的團隊，每隔一段時間，都還會有不一樣的流程。

迭代想與得

為什么我們要迭代？

進行游戲開發，首先請大家對此銘記于心：

l我們的設計不一定是我們真正想要的

l文檔內容在我們想象中和實際體驗版本時的感受不相等

l我們沒法100%的思考到所有需要思考的角落

同樣，要理解為什么要使用迭代，我們需要明白迭代開發從何而來。最初，軟件開發行業中，一般都由需求方提需求，開發方拿到需求開始分析設計，一次性開發成型交付。隨著行業的發展，軟件復雜度的增大，需求變化的增加，大家發現一次成型的版本往往無法滿足需求方的需要，于是返工。當這樣的情況多了之后，返工就成了一種標準化的流程，系統化的返工其實就是我們所謂的迭代了。當然這是一種比較民間的解釋，但是在游戲產業中，這也說明了：

l迭代的目的是為了應付需求的變化。

這里的需求變化需要我們的額外注意：

l游戲產業中的需求變化，并非只是指策劃或需求方在中途站出來說自己的想法有變。更多的時候，是自己在進行游戲開發的過程中，出于對開發的游戲的認知的加深產生的需求設計的變化。一般來說游戲的需求來源于設計，但是我們的設計卻往往并不是我們真實的需求?；蛘哒f，我們的設計往往不能滿足我們真實的需求。

例如，我們需要一個激烈爽快的單體攻擊技能，那么我們的設計可能會涉及到，這個技能的功能，傷害，消耗，動畫播放等。這個設計還會涉及到表現：比如技能的動作如何，特效如何，播放速度如何，鏡頭如何。當我們看到這些設計，我們是否就能確定這些設計能夠滿足我們的需求？進一步，就算我們看到設計之后，認為能夠滿足了我們的需求了，但是否在游戲版本中我們實際體驗的時候，實際效果能100%符合我們的預期？

當我們清醒地認識到：

l無論我們在設計上花多少時間，我們都無法完全消除設計的實際效果和預期的差距。甚至在超過某種程度之后，我們花在設計上的時間將會形成浪費（這就是所謂的OVER-DESIGN）。

我們就應該開始考慮，什么時候設計應該停止，什么時候我們就應該開始先做，然后預留足夠的時間，把那些可能出現的，和必然出現的問題，留給我們后續的迭代來發現和解決。而不是把這些問題試圖在一開始全部解決掉，第一，不現實，第二，不科學。

旋轉上升

什么是迭代

那么，迭代究竟是什么？

首先要申明一點是，其實我們現在談論的迭代并不是純粹的迭代，而是迭代加增量開發。純粹的迭代是指沒有新需求的加入，第一個版本實現的內容就已經完整，之后的版本只是之前內容的優化。而增量，則指下一個版本是在上一個版本基礎上增加內容的開發形式。

那么，迭代加增量開發的意思就顯而易見了，而我們需要的開發模式就是這種：

l在不斷以版本為基礎的增量功能開發的基礎上，不斷對已經有的功能進行完善和優化。這就是狹義的迭代

進一步來講，廣義的迭代，則不僅限于我們的功能開發。而且還要對于我們本身的流程，工具，工作方式，方法，習慣等等所有可以改變，可以優化的地方進行優化，進行修改。最終的目的就是通過一個個版本迭代開發，不只功能品質在變好，團隊效率，團隊流程等各個方面都會變得越來越好。最終形成一個真的具有戰斗力的團隊。

周期總結會議，以及一系列的問題改正，優化提高事項，以及平時提倡的交流，對于變化的擁抱等等，都是為了這個目標而發生的。所以，

l敏捷開發是一種精神，而不是一種固定的形式。我們需要有一切都是可以改變的心態和準備，并且真的可以著手去改變任何我們覺得有問題的東西，這樣才能真正發揮敏捷迭代開發的優勢。

陀螺的轉動

如何迭代

迭代的漩渦

首先，我們抽象一下，以便大家能簡單的明白迭代的形式。迭代就像是一個漩渦，從漩渦中心開始旋轉，越轉越大。而處于迭代最中心，所有的東西都圍繞它來轉動的那個核心，就是我們的產品訂單（故事清單）。

而那條旋轉的線，就是我們的版本。版本永遠圍繞著我們的故事清單來開發，（故事清單，抽取于我們的游戲的設計），版本總是由故事清單里尋找需要完成的功能，再將根據實際版本得到的反饋，并更新故事清單。于是功能清單的功能越發的有價值，而版本本身也會越來越有價值。

迭代的步驟

那么，我們的版本該如何圍繞我們的功能清單來畫這個漩渦？

首先，漩渦是一個環繞的圈，所以我們先確定圈的長度：

l一個迭代的長度

在這段固定長度中，它其實是一條單向封閉線性的線段，有始有終。有始有終的過程才能被量化和計劃。在線段開始時我們從產品清單中取得信息，在結尾會釋放一個版本并向產品訂單反饋信息。

再進一步深入：

在這線段的開頭，我們要從產品訂單中取得什么？故事。什么樣的故事？價值（優先級）總和最大，且大?。ü适曼c）不超過我們一個周期工作量的故事。僅僅如此么？當然不是，首先，有一個重要的概念：

l系統

也許有幾個故事隸屬于同一個系統下，它們共同組成了這個系統，它們全部完成，或者至少關鍵部分完成。這個系統才是完整的。當系統不完整的時候，這些功能的樂趣根本無法體現。

那么，有可能當我們選擇這個周期開發某個高價值功能時，沒有開發相應的屬于一個系統的其他低價值功能。于是周期末的版本我們發現，由于系統的不完整，這個功能樂趣甚微。如果對這種涉及系統的問題沒有認識，那么我們很可能就會對這個高價值功能有錯誤的認識。 （關于系統理論的知識，請參見WIKI系統學一詞）

如何避免這個問題？這個時候人的作用就體現出來了。當然我們可以在故事列表上增加一列系統屬性，提醒我們。但根本的方法還是一個或者多個對整個故事列表有著足夠把握能力的人來進行掌控。

我們需要有人能夠全面的了解設計意圖，并且對我們的故事列表進行把關，對我們周期開始的需求選取進行主導。有一點大家應該明白，規則和標準都是人制定的，那么我們究竟是依靠標準和規則來更好的控制結果，還是依靠人本身？是完善更好的標準，還是培養出更能把握質量的人？

接下來，線段中的開發過程，本質上其實就是分析需求，制定計劃，開始開發。或許會周期內分為更細小的周期進行迭代。但是這些小迭代其實依然是瀑布式開發，這點毫無疑問。區別只是在于，這樣的小周期內，我們開發的思想和方針是以敏捷開發的思想為指導的，我們更注重版本，更注重交流，更注重結果。而不是預定義式的開發流程（pre-defined)。

在線段的結尾，一個周期結束了，我們需要做兩件事情，第一是將我們體驗版本之后的反饋，反饋回故事清單中?；蛟S我們體驗某個功能之后會覺得加上另一個功能會更好玩，于是我們提升這個功能的優先級?；蛟S我們會覺得這個功能很無聊，于是我們把同類型的功能優先級都降低。再或者我們添加，甚至刪除一些全新的故事（不推薦）。

迭代的節奏

在迭代中，我們還需要注意我們迭代的節奏，什么時候該松，什么時候該緊。什么時候我們允許大家的發散和更多的思考。什么時候我們應該專注于我們的目標并且忽略其他的一切以得到我們最終的版本。這些都是有所講究的。

這節奏包括各個方面。那么究竟這樣的節奏應該如何來走呢？

在一個迭代之內，我們的節奏應該是先松后緊。當然不是說迭代開始時我們的效率可以放緩。這里的先松，是指在一開始時我們可以有更多的想法和思路，更多的探討和研究。本來我們的迭代工作就是從粗到細，從模糊到精確的進行。在迭代中，我們也如此一步步明確我們的工作。

一旦目標明確，那么迭代周期SPRINT的名稱的含義就出來了：我們向著我們的目標沖刺而去。到了這個階段，我們需要收縮我們的討論和想象，一切以最后的版本和質量為前提。以盡可能快的速度來開發我們的功能，提高我們游戲的質量，得到我們需要的結果。至于具體的迭代方式，各有不同，我的方式大家可以參加之前發出的那個VISIO圖表。某些細節接下來還會講到。

版本持續統一的意志

為什么需要版本

驗證樂趣

我們的設計在我們的腦海里，很可能和在別人腦海里得到的認識是不一樣的。

或許大家都能有幸得到統一的認識，但是做出來實際體驗的時候又不一定能夠符合我們的預期。

就算符合了我們的預期，也許我們玩的時候會發現一些新的點子可以很容易的加入到游戲，并且大幅度的提高游戲性。

所以，多個迭代版本的目的，首先就是為了：驗證我們的功能是否符合我們的設計預期。因為:

l沒有實際玩到之前，永遠不要相信自己的設計是OK的。

我想強調的是，這里的設計預期不僅僅涉及到我們的功能，事實上作為游戲開發，功能開發永遠只占其中的一小部分，還有大部分的時間我們需要用來調整，優化，修改，以達到我們的真實預期。

換一種說法，這里的預期除了功能以外，還有我們對它的感受，也就是這個功能到底好不好玩。而我們關注的重點，也是在好不好玩上。如果只是關注于功能是否完善，那么我們的版本就還離成品有一大段路要走。

所以迭代版本應該是計劃功能均可玩，并且沒有會阻止我們體驗所有需要體驗內容的BUG的游戲版本。它是我們評判一切的依據，因為一切功能，一切資源，一切玩法，在進入版本可以被我們體驗之前，都存在不確定性，只有最后經過版本的體驗，這一切的不確定性才能消除。

持續集成

其次，敏捷開發的要求是快速迭代。但是這里的快速迭代其實遠比大家想象的還要快速?；蛟S大家覺得正確的快速迭代就是每一個周期，或2周，或一個月就需要一個版本出來。迭代速度比起傳統開發確實快了許多，版本也多了許多。但是事實上的快速迭代遠比一個周期要短的多。理想的快速迭代，應該是：

l每個功能，每個改動完成之后都有一個版本能夠立即對功能進行驗證，進行體驗。

讓我們對游戲的改變把握得更直接和高效。讓大部分對游戲方向的修正都發生在開發當中而不僅僅發生在周期的開頭或者末尾。原因就如我所說，每一個功能從完成，到有樂趣，都需要有一個打磨的過程。在打磨之前，很有可能這個功能根本沒有樂趣。所以實際上，我們一周要開發一個功能，很可能我們前4天就需要把功能開發完畢，周四出一個版本進行體驗。然后周五針對周四的反饋進行一些BUG修正和反饋修改。之后樂趣才出的來。

是的，如果是理想情況的話，每一個功能無論大小都應該是這樣的一個流程。哪怕是一個只有半天開發周期的功能，我們在3個小時開發后也需要出一個版本對功能進行驗證，并提出反饋改進（如果有的話）。之后優化到大家覺得這個功能合格或者有存在的價值之后，我們才會繼續下一個功能。

這樣的過程當然過于理想化，每一個功能我們都可以幾乎無限的優化下去。所以我們也需要對優化的程度進行取舍。這樣取舍的標準還是最終會基于我們開發者自己的個人能力和標準上。更重要的是，我們需要建立每一個功能和變動都需要一個版本進行驗證的意識。進而才能追求我們的版本質量和效率。

沖刺的藝術

效率

敏捷開發絕對不是犧牲效率追求品質的開發模式。

相反，在每一個迭代當中：

l效率才是需要追求的第一位。

唯有在盡可能快地發布版本之后，我們才能根據版本的反饋，進行修正。進而得到更好的版本質量。大部分時候，我們需要的僅僅是以最快的速度得到我們需要的原型。驗證我們的設計。 為此我們需要盡可能的追求效率。

那么，如何得到我們需要的效率？

范圍

首先，永遠不要做多余的事情。一旦目標明確，那么我們的目標就是所有我們要做的，在目標范圍內的質量優化，必要的代碼改善，必要的體驗優化，都是可以做的。但是離開了我們目標范圍的事情，一件都不要做。

這里的范圍，則是一個度量。而這個度量的劃分，則又一次，需要依據我們這些人來判斷。它需要我們深刻的理解到，我們制定這些目標的意義，我們要實現的究竟是什么，我們應該優化到什么程度？

我們有多少時間，那么我們就只能設計到什么程度，做到什么程度。而更多的次要的需求，我們有時間再考慮，更多的兼容性想法我們可以想，前提是我們這個版本還有時間。我們需要畫一條基準線，在有限的時間里，我們能做多少內容，該做哪些內容？一切行動都需要以我們的目標為準則。當然，我們還需要考慮量產和下個階段的準備工作等等（然則，這些其實如果規劃的好，應該可以算作這個周期內的目標之一）。但這些都需要服從于當前版本的開發。全力開發我們需要的內容。

因此我們需要避免過度設計，過度開發，以及過度優化。我們需要將效率作為我們開發的準則。

人員

永遠只涉及必要的人。為什么我們要進行小組化開發？因為人員牽扯一旦擴大，唯一的結果就是效率降低。各種意見難以統一，管理變得困難，計劃難以統籌，任務分配變得困難等等。所以最佳的小組規模應該在7人前后。

僅僅如此么？當然不是，我們不但要確定小組規模并且將小組開發與外界的干擾屏蔽開。我們還要確定我們項目開發的流程中，每一個步驟所要參與的人員，哪些是真正必須的，哪些是不必參加的。確定人員的職責范圍，首先他們需要專心于負責的部分，之后才涉及力所能及的部分。

在這里，需要解釋的一點就是，敏捷開發并不是所有的決定和步驟都要大家來參與，以增進組員責任心和歸屬感的。為了最大化效率，我們永遠只讓必要的人來做必要的事情。比如故事分解為任務，只需要小組成員，和相應的主程主美主策。比如故事本身的優先級劃分，只需要核心組成員（更加通常的情況是只有PO）參與即可，小組成員沒有必要參與。再來，版本體驗會，我們需要的是真正的指導性的意見和重要的人的聲音，如果需要專門組織一個會來聽小組成員對版本的反饋，我覺得那小組成員平時就不知道是干什么去了。我們需要在組織每一場會議的時候都考慮到，是不是每一個到會議的人都是必須到的，因為我們找他來開會的時間，都本來應該是他開發和工作的時間，而那才是我們的重點。

高效會議

最后，我們需要有一個清醒的認識，過多的會議永遠都是高效率的開發的大敵。一個會議10個人，一小時，意味著我們會損失10個人時的工作時間。而實際上一周的工作中，我們一個人時都是損失不起的。當然，這并不是意味著我們不要開會。而是我們需要意識到我們的會議究竟是否有必要，如果有，那么會議效率是否足夠？我們是否有足夠的會議準備和計劃，能夠保證我們會議的效率？還有我們是否有相應的會議章程，會議時限？這些都是我們需要考慮的，用以高效化會議，減少時間浪費的重要方法。

所以，當我們思考效率的時候，不妨真的來看看我們現在的開發，分析一下一周的工作中，究竟開發的時間有多少？其他的時間又有多少?？纯吹降资鞘裁丛谟绊懼覀兊拈_發，是否有方法，或者措施，能減弱這些影響。最終進一步加快我們的開發？

開發的脈絡

交流

非正式溝通

交流，在敏捷開發中，是永遠都談不夠的東西。也是永遠會存在問題的地方。在敏捷開發中，我們會重視交流而輕文檔。原因？只是因為交流永遠比文檔更高效。

并非我們就此放棄文檔，文檔最終會變成記錄我們討論交流結果的工具，便于未來查閱。高效的原因是，在交流的過程中，我們就可以共同修正分歧，修正個人的錯誤，并且將信息傳達給對方。當然，一切都還僅僅是基礎的東西。

進一步的是，究竟如何能讓我們的交流高效？首先，必須明確一點，會議并非是高效率交流的良好方式。更好的交流，應該更多來自于更頻繁的，更多的非正式的溝通。把所有人拉到一起，強迫他們發言，或者收聽，并非能很好的傳遞信息或者進行討論。而鼓勵他們進行自發的討論、交流、在每天，在所有的閑暇，都可以進行一些思想，一些想法的發散、討論。這才是最好的情況。

我們當然也可以就此進行推動。更多的不是人為的設置一些剛性討論需求，而是制造一種推崇各自討論的氛圍。

郵件

其次，是我們交流的方法。我們有沒有真正考慮過，哪些內容我們應該放到正規會議上進行宣講？哪些內容我們只需要發一封郵件，并收集回信的反饋？哪些內容，我們只需要找到相關的人，非正式地談論一下就可以得到解決？這些分類一旦清晰，能夠為我們的團隊節約多少時間？

從另一方面來說，有多少內容我們甚至連郵件都沒有發出，完全變成了個人的地下行為？在這里，我想強調一下關于郵件的作用，在原來的公司，我們被要求盡量少使用郵件，因為某個時期，員工們甚至把所有需要面談的內容都用郵件來代替了。距離5米的兩個人甚至一周幾百封郵件卻沒有一次談話。

而在現在的環境中，郵件卻變得相對冷落，很多應該有郵件作為記錄，或者應該由郵件發出的內容都借由其他的方式或者沒有以任何方式發出。比如現在很多的策劃文檔，每一次更新，只有一定幾率會有郵件通知到大家。比如會議紀要，當然這都還是表現的比較好了。再比如不太重要的設計文檔，這些都可以借由郵件發送來讓需要知道的人了解，并且相比專門的宣講會，節約很多的時間。大家只需要看完之后，把反饋意見用郵件發回就可以了。所以，我們可以考慮是否完善我們對于郵件的使用？更重要的是，是否我們可以進一步提高我們對于郵件使用的意識？我相信，這會是一個很漫長的過程，但是必然能夠極大提高我們辦公的效率。

其實終究，還是我們考慮問題的方式，我們是否能夠意識到我們現在的交流方面的不足，是否能夠開始改進？這將是我們是否能夠繼續成長的關鍵。

項目的基石

人

談到人，其實就是談到整個流程和過程中最關鍵的地方，最關鍵的元素，也是決定一切事情成敗的根本。無論多好的制度，流程，如果沒有相應的，合格的人來執行，也只會是失敗的結局。那么，在敏捷開發中，或者說在游戲業的敏捷開發中，我們需要什么樣的人，我們需要什么樣的素質和要求，才能更好的運作這個模式，更好的做，并且做出更好的游戲呢？

迭代的意識

首先，是改進的意識。永遠記住，沒有完美的東西。我們需要保持清醒的認識，認識到我們的項目；我們的流程；我們的文檔；我們的游戲等等，都還有可以改進的地方，都還有很多可以改進的地方。改進是沒有終點的，我們需要能夠找到這些可以改進的地方，我們還需要可以找到改進的方法，并且切實的推行下去。這樣，我們才能在一次次迭代中，得到更好的項目，更好的版本，更好的團隊，等等。意識到我們有問題，我們才能夠改正這些問題。從某種意義上來說，其實這也是迭代的意識。

效率的意識

其次，我們需要效率的意識，我們要明白，最終，我們是在開發商品。我們是在進行商業運作，所以效率是我們需要真正關心的。而效率的重點并不是每天在公司里花了超過8小時，而是我們的時間是否都真正被有效利用起來了。我們是不是真的在需要的時間內，給出了需要的成品。是否這些成品能夠合格。每天做的事情是否有意義，是否能夠給予我們的工作和項目幫助？我們是否能夠抓住我們工作的重點？而不是浪費在無關痛癢的地方。我們需要考慮我們的工作是否是向著目標前進的，是否足夠，是否有效率。要做到效率，我們就需要首先明確我們的目標，其次清醒的意識到我們在做的事情，最后再反省是否有無效或者被浪費的地方。是否我們能做的都做了，是否我們把不需要做的也做了？

理解游戲

再次，我們需要有對游戲的把握。畢竟，我們做的是游戲，如果做的人都不知道什么是游戲，那么如何能保證我們做出來的游戲能被人喜愛？甚至，我們如何能保證我們做出來的游戲，是游戲， 而不僅僅是一個選擇播放的技能地圖預覽器？所以，首先，我們大家都需要了解游戲，了解什么是游戲，游戲包含了什么；游戲性是什么；核心玩法是什么；主要模式是什么；畫面表現是什么；音效是什么；故事是什么，它們是如何結合的，是如何組合成一個游戲的。不同的游戲類型里，這些要素又以什么比例組合，哪一個更加重要。這些都是游戲開發者所需要了解的基本。進而，開發者才能明白，我們現在的游戲已經有了哪些元素，還差哪些元素，已經有的元素是否足夠，是否還有所欠缺。這時，合格的游戲開發者們，才有能力說出，我們的開發方向在哪里，應該補充什么元素，有什么欠缺的地方。這樣，我們才有能力，做出一個至少完整的游戲。

開發者的野心

進一步，我們如果還有野心，并非只是做一個完整的，良好的游戲，我們還想要有創新，想要做一款讓人眼前一亮的游戲。那么我們就不只要了解什么是游戲，我們還需要對游戲有自己的理解和想法，我們需要有自己對這個游戲的未來的想象，并且時常將之拿出來討論，碰撞，最后留下那些可行的，優秀的方案來實現。我們每個人都需要對我們的游戲有所希望，并且這些希望都是需要時常在我們的大腦里醞釀的。這才是游戲開發最有趣的地方，我們總是可以實現我們腦海中大膽的想法，我們總是可以把我們有趣的意見，點子說出來，如果能夠得到大家的贊同，就可以實現到游戲里去。做游戲應該是有趣的，而不是每天重復枯燥無聊的勞動。所以，我們需要思考，并且說出我們的想法。

快樂地制造快樂

用心制造快樂，是不夠的，還需快樂地制造快樂。讓我們并不僅僅是麻木的工作著，而是真的有趣的去做有趣的事。這才是做游戲的本意，這才是大部分人最早加入游戲公司制作游戲的本意。如果我們做的東西連我們自己都無法說服自己，“那是有趣的?！蹦亲龀鰜淼恼娴哪苡腥っ?？我們在做游戲，之后才是工作。如果整個游戲，都沒有一點自己的心思在里面，那我們就真的只是在勤勞的上下班了。

而且也只有相互間的思想，想法在碰撞，才會做出有意思的游戲。游戲的設計并不僅僅是策劃的事情，游戲的需求也不僅僅是由策劃提出。只有大家每個人都可以針對游戲的缺陷，樂趣，玩法能有自己的見解，每天爭的面紅耳赤，那才是真正做好游戲的取勝之道。在游戲性的討論上，根本沒有策劃美術程序之分。

對游戲工業化開發的把握

最后，我們還需要有對游戲開發的把握，對整體的把握。我們是否知道我們現在處于游戲開發的哪個階段？這個階段應該重視那些東西？應該注意那些東西？這個階段我們應該完成那些東西？對于這些我們是否有清醒的認識，清醒的計劃？

我們是否有對我們項目的整體規劃？知道我們現在要做什么，知道我們下一步還要做什么，這才能讓我們明白我們現在做的是否有意義，是否有效率，是否正確。我們的目的，絕對不是過GR1，2,3,4,5.這一點大家應該明白，我們始終都是在做游戲，如果我們的方法正確，計劃正確，那么這些評審對我們產生不了任何影響，那么既然我們每次都需要針對這些評審改變我們的流程計劃，那么是不是也意味著我們本身的計劃也存在一些問題？這個問題大家也許可以思考一下。不要讓問題找到我們，而是我們去尋找問題。

故事WHY ME? WHY STORY?

為什么要使用故事？

我們為什么要使用故事？要理解這個問題，首先要理解故事的作用。那么故事的作用是什么？

消除理解誤差。

早期軟件開發的需求方往往不懂任何技術，開發者的功能清單卻往往難以讓需求方有直觀的對最后成品的認識。比如，或許一個功能描述是，“戰斗場景分為5層可以根據攝像機的移動而相對運動”，但對于非專業人士來說，他們可能無法理解這樣的描述意味著什么。于是故事開始發揮了它的作用：以一種大家都認可的方式讓所有人對我們要做的功能目標有清楚的認識。

所以：

l只要能夠讓全體人充分意識到我們功能開發的目標以及內容，那么它就是一個很好的故事。

對我們來說，這樣的共識需要在策劃，美術，程序等人員之間達成，所以我們的故事也需要以一種大家都能理解的方式來表達。而更重要的，不是故事的方式，而是確實所有人都能夠完全理解。具體怎么寫，其實真的怎么寫方便都可以。

整體統籌估計和管理。

由于故事是從系統和結構的層面，以一定的高度來描述我們整個項目的框架功能，所以我們可以以較快的速度全面了解我們的功能點，而對于這些功能點，我們還可以進一步快速的給出粗略的估算。進而得出整個項目的大概工期或者每個迭代我們可以完成的故事數量。這里的估算往往是由不準確慢慢到準確的。

l每一個周期，每一個項目的歷史數據都可以讓我們之后的估計更加精確。

而且這樣劃分的工作，可以更好的交付給不同的小組完成。小組內部進一步自行組織計劃，使得我們的管理工作可以分散到小組，降低管理難度。

創意管理

本質上，游戲就是已有的同類游戲的完整功能點，加上我們獨特的創意。完備的前者能讓我們的游戲成為一款合格的游戲，而后者的加入則讓我們的游戲變得獨特。引入故事后，我們可以總是在一個層面，對功能開發和創意嘗試的投入進行平衡，相互以取舍。我們可以總是以功能和創意的價值來判斷真正對我們有價值的開發順序。

故事在講什么？

什么是故事?

首先，故事本質上依然是功能點，依然是從需求中抽取出的一個個系統功能。只是以一種所有人都能理解的形式進行描述。所以，為了能夠讓所有人能夠理解，故事僅僅只從實現功能的目的來描述這個功能：

l故事是對功能的目的的描述

同時，故事是在講述這個功能究竟是發揮什么樣的作用。所以它本身價值只是簡單描述和給予一定參考。

l它不是，不能也不需要詳細的描述這個功能的所有細節和玩家對此的感受。

因為前者有相應的策劃文檔，后者難以文檔化以標準衡量。

所以，當我們要驗收某個故事的時候，并不是我們比照著一個個故事，來體驗游戲?？匆粋€個故事是否在游戲中完整的實現了。

正確的故事驗收，應該是在這個故事在組內達成統一之，所有人就應該知道要做成什么樣子之后。將單個功能的驗收在周期內

就實時完成。而在最后版本發布之時，對功能進行檢驗，檢測這個功能的最終效果是好還是壞。

我們的目的不只是要看是不是功能A,B,C,D已經完成了，我們應該再深入一步：

l關注于功能是否得到了很好的效果，符合了我們的預期

l在游戲開發中，則是，是否有了樂趣

l是否有其他想法，能夠讓這個游戲更有趣

因為僅僅是功能的集合，并不能成為合格的游戲。

因此，我們也需要改變我們對于設計目的的定義：

l我們的目的并非僅僅是完成某個功能，而是功能能否達到我們需要的樂趣。

帶著這樣的思路，我們才能真正的在版本回顧的時候，給予能夠指導我們開發方向的反饋，而非僅僅是針對我們功能開發的完整與否，發表意見。

作為核心組成員，或者，作為整個游戲項目的一員：

l我們不應該僅僅關心于完成情況，各種細小的錯誤。我們應該看得更遠，思考的更遠，給予我們的開發真正能提升最終質量的幫助。

最后，故事包含對它大小的估計，我們可以使用這個估計來對將來的工作和計劃進行評估；對它本身價值的估計，讓我們在選擇他們時可以參考。簡單的來說，就是另一些附加的功能。

用好你的武器

如何使用故事

故事的來源

第一，從已有的游戲設計文檔或者框架中抽取的，比如，我們已經知道我們要做的是一個回合制戰斗的游戲，那么我們就可以抽取出，基礎戰斗指令，回合制戰斗流程之類的故事。

第二，新出現的創意性質的內容，比如，今天我突然想到在回合制戰斗中加入行動順序條或許是個很有趣的點子，我告訴大家，大家也覺得這個東西很好，于是我把它加入到清單中。

第三，當我玩到某個游戲的版本的時候，發現，某個功能給我的反饋不是很好，或者我覺得可以如何改進，能夠讓這功能變得更好，那么也可以放進到故事清單中。

故事的使用

首先，我們有一個用來維護故事的列表，術語叫做產品訂單，里面羅列了所有我們已經完成或者沒有完成，重要的或者不重要的故事。我們可以在里面清楚的看到：

l故事的描述

l故事點（大?。?/strong>