去年有個機會和游戲業內的某位研發管理李經理聊到游戲研發項目的現狀，他感嘆道：“游戲越來越復雜，團隊的規模越來越大，而人員的流失卻相當嚴重， 僅以調整工資來留住人才顯然不是應對之策。”

2006年，公司剛剛成立時，李經理就加入了，他們有幾千萬的天使資金，人數在三年內擴充到二百多人。但在團隊不斷壯大的過 程中，人員流失也非常嚴重，甚至連主策劃都被挖走了。這就給公司管理帶來了一系列問題，例如在事務中需求不斷地變更，對需求理解的錯誤及溝通的不通暢等， 使得埋怨之聲不絕于耳。他的團隊對新人的培訓和內部協調花掉相當多的時間，但成效不佳。聊天時我們從各個不同的角度，諸如公司管理制度及文化、研發方法和 研發工具等，彼此交換了意見。

冰凍三尺非一日之寒，這復雜的問題也不可能輕易就有個完美的解答。單就從軟件工程的角度來看，合適的研發方法和工具結合可以相當大程度的增加生產力，并降 低人員流失所造成的損失。討論之后我們覺得這些要點具有共性，可供大家參考，就把要點整理并補充了一下。雖然這不像學術研究那般地嚴謹，但仍提供了大家在 實際操作時一些思考的方向。讓我們從一個典型的游戲研發團隊所具有下列特點說起。大致上它有下列幾點：

一、 需求變化多且快 –需求的變化是不可避免的。更甚者是游戲好玩與否很大程度是由玩家決定的。所以，需求的重要性很難確定。需求的變更可以直接沖擊產品交付時間，因而很容易 便引起大家相互的指責。
二、協作不容易 - 典型的游戲的開發團隊里有策劃、美工（2D、3D）、程序、測試等角色。由于人員較多，溝通協調都不容易。舉例來說，某個流程改變了，相關的人又需要一段 時間才能適應這新流程。當某個需求變更時，可能策劃、美工（2D、3D）、程序、測試等人員又要溝通并返工。
三、資源調度難度大 - 團隊里常會有某些人（如程序員）在等待其他人（如策劃）的情況。通常管理人員對這些情況并不能掌握得很好，這使得資源在無形中浪費了。

為了要應付游戲研發過程中需求變化快的特性，越來越多的團隊已使用或正在考慮使用敏捷方法。（有些人可能不知道其團隊已在使用較簡單的敏捷操作，如每日站 立會議等。）實踐已證明敏捷方法有下列優點：縮短產品開發時間、提高軟件品質、項目較為可控、成員自主能力提高并顯著地提高其生產力。在諸多敏捷方法論 中，Scrum似乎特別受到青睞。而敏捷方法也并非是互不相容的。比如，有些團隊會以Scrum的方式管理，以XP的方式操作。

由于傳統文化等因素，有些人認為Scrum未必能很容易地被中國研發團隊接受。Scrum團隊鼓勵每個成員都參與并發表意見。但由于中國的傳統教育方式并 不刻意鼓勵學生發言，大多數的中國研發人員未必能習慣敏捷的思維及操作。舉例來說，Scrum Master組織每日立會并負責清除在這些會議上反映出來的那些障礙。它的角色更像是團隊協調人。但由于Scrum Master這個角色一般由團隊技術主管或項目經理擔任，團隊成員會揣摩并附和他的意見。還有，在團隊中進行討論時是對事不對人的。在會中有些意見被采 納，有些被否決，這本是很正常的事。但這操作也有它的困難。我曾經參與一個較技術性的討論會，在會中有個很優秀的女孩提出了她的建議，但沒被接納。她覺得這是個恥辱，居然就站起來走出了會議室。

并非所有的團隊和項目都適合采用敏捷方法的。大致上來說，適合使用敏捷方法的團隊和項目具有下列特性：

一、團隊有能力引進自下而上的管理模式。傳統的管理模式是自上而下的，在經理把項目理解后拆分成幾個任務，再將這些任務分配給個人。敏捷方法對團隊成員的 要求較高，不但成員的性格需要較為獨立開放，技術能力和對整體項目的理解也都要到達一定水平。
二、團隊人員不宜太多。團隊協調和資源調度在七到十人的團隊里還是游刃有余的。但一旦人數再增加，團隊協調和資源調度的難度都呈等比級數增加。當團隊變大 時，需要有工具支持以保證項目的可控性。
三、需求變化多且快。敏捷方法就是為擁抱需求變化而設計的。如果能保證項目的可預見性（Visibility）和可控性，那需求的變化就不是太大的問題。
四、團隊成員最好能在同一處工作。由于溝通的頻繁，分布式團隊是較不適宜使用敏捷方法的。但當然，若成員必須在異地工作，那工具多少可以幫上些忙。

當團隊人數增加到十人以上，團隊協調和資源調度的難度都呈等比級數增加。在這情況下，引入適當的工具是必要的。在選取敏捷研發管理工具時，我們應考慮下列 特點：

一、整合的平臺（Integrated Platform）

這平臺要能做項目計劃并管理需求、代碼、測試、發布。它是策劃、美工（2D、3D）、程序、測試等人員的協同及溝通平臺?；蛟S在開始選工具時我們要的只是 這其中的一部分，如需求管理，但依然我們需要預先考慮將來會擴展到對整個軟件生命周期的管理。這些工具模塊之間的數據要能相通。

二、量化程度高（Quantification）

它必須能在以下幾方面做量化：需求、人力資源及費用等。這些數據將為未來的改進提供依據。需求的量化對整個項目的管理有著重大的意義。它意謂著需求可以被 分割成足夠小的單位（大約是一到幾個工作人天），這些小單位可以恰當地被分配給程序員或測試員，每個成員的工作量可以被合理地分配，每個迭代的長短被控制 得恰當，當需求變更時一切仍然可控。

三、可追溯性高（Traceability）

理想上，項目成員應可將相關的文檔（包括需求及參考資料等）、測試用例、及代碼等鏈接，并從其一追溯到其他的。如果生命周期管理系統的各個子系統不是整合 的，那這種追溯事實上是不可能完善的。在實務中最常發生的例子可能是，研發人員要修復某個缺陷，他常常會需要找出原本的設計文檔及歷史上相關缺陷修復的狀 況。知道了來龍去脈后，他便可以很準確地完成他的工作。

四、 可擴展性(Scalability )高

可擴展性至少表現在二方面：（1）人員的可擴展和（2）地域的可擴展（分布式團隊）。當團隊擴展到十人以上時產生的第一個問題是溝通變得不通暢，每日例會 不易舉行。由于知識量太大，成員已難以掌握全貌。一個可能的做法是將團隊分成幾個小組，每個小組各自開會。工具的作用在于將所有的知識及數據間的鏈接保存 妥當。團隊成員可以在任何時刻拿到自個兒小組的、別個小組的及整個團隊的知識。如此，就算團隊增長到百人，項目全貌仍舊可以掌控。
大約半年過去了。最近我和李經理再次聯系時，他告訴我：“埋怨之聲少多了，但傍晚自動留下用公司晚餐的人卻多了。”我說：“哦！我明白了。敏捷方法所造成的另一個問題就是公司付出的晚餐費用會大大的增加。”我們都笑了。