[翻譯] 遊戲開發該小心的十個 Scrum 陷阱

Top 10 Pitfalls Using Scrum Methodology for Video Game Development
[翻譯] 遊戲開發該小心的十個 Scrum 陷阱



Paul Miller
July 15, 2008


[Industry veteran Miller looks at the leading Agile methodology for game development, suggesting the ten top pitfalls – and ways to overcome them – for those using Scrum to manage a video game project.]
製作過 Tiger Woods PGA Tour 2007,The Godfather,Star Wars Episode 3,及 Spyro Enter the Dragonfly 等遊戲的業界資深開發者 Miller 觀察遊戲開發的敏捷方法論,提出十個警告,以及如何克服的建議。

There has been some hype about using Scrum for game development, including presentations at Game Developers Conference. There are books and many internet resources that describe Scrum, and this article assumes the reader is familiar with Scrum and Agile methodologies for product development.
在遊戲開發過程中使用的 Scrum 已經形成流行,在 GDC 研討會的演講中講很清楚。也有書籍與網路資源描述 Scrum,這篇文章假定讀者對 Scrum 及敏捷開發方法學有一定程度的熟悉。

Scrum can be a beneficial for some kinds of software projects. There are, however some pitfalls that are easy to run into when employing Scrum to manage a video game project.
Scrum 可以為一些軟體專案帶來幫助。然而對於當我們套用 Scrum 管理遊戲專案時卻發現一些陷阱。

Some hazards can occur because the importance of well-established, existing best practices is ignored. There can be consequences when Scrum is used as a replacement for existing best practices. Here are 10 pitfalls that were experienced on a recent project while employing Scrum methodology.
當曾經被實踐,淬鍊過的方法的重要性被忽略,常常會去實驗新的方法。當 Scrum 來取代目前的實作方法時,產生了一些後果。這裡舉出了十個在最近一個專案套用 Scrum 方法曾經經歷過的陷阱。

10. A Game Design Document (GDD) isn’t needed anymore because the backlog spreadsheet replaces it.

While maintaining both a GDD and a backlog, the team is drowning in an overwhelming amount of paperwork every day. The ScrumMaster or Producer responsible for the backlog ends up spending less time writing or maintaining the GDD and as a result there is a lack of product design specification. Team members are left guessing what code to write or what components or assets need to be constructed in order to make the game that is going to ship.
每天同時維護GDD及備忘錄會讓團隊被行政工作填滿。ScrumMaster 或製作人因為需要維護備忘錄,所以就少了寫GDD的時間,因此產品的規格就會有疏漏。團隊成員可能會不知道某段程式的作用,或是哪一部分的素材需要在發售前建立。

Lesson Learned: Backlog spreadsheets are not a replacement for printer-friendly game design documentation. Team collaboration is not a substitute for someone putting the product design specification in writing.

It’s hard to see up front that the lack of printer friendliness of the backlog spreadsheet is actually going to inhibit everyone’s ability to communicate. Before backlog spreadsheets, it was possible to print out the GDD and bring it to the team meeting and scribble notes on it. It was also easier to provide feedback in writing. By printing out the GDD and bringing it to the meeting, you could talk about the design and refer to it without sitting at a computer.

While using a backlog spreadsheet as a replacement for design documentation, one issue team members realized is that after a meeting they walk back to their desks, start to concentrate on tasks and have forgotten seven of the eight points that were discussed during the meeting. The solution proposed was that everyone needs a laptop to bring to the team meeting so team members can type into the spreadsheet simultaneously. Imagine the team meeting is like a LAN party and everyone can see each others’ cursors on their own view of the spreadsheet.

Unfortunately spreadsheets do not have a multiplayer mode, and the company is not going to buy everyone a laptop just for Scrum methodology. The obvious solution is everyone brings a notepad and pen to the meeting and takes their own notes, but why didn’t the designer put the design in writing in the first place? Why is the design done on the fly and everyone has to take notes like an executive dictating a letter to multiple secretaries at a time?
不幸地,試算表沒辦法玩多人模式,公司也沒辦法因為 Scrum 方法支援每個人一台筆電。這時的解法就是每個人帶紙筆,針對自己工作寫筆記,但為何企劃不就先用文件的方式把設計文件寫好?為何設計變成是我們在撰寫中的過程中進行,就像是多個秘書同時寫筆記?

In multiple team project review meetings the ScrumMaster has remarked “We need more communication on our team." All the developers then roll their eyes and ask “where is the design specification in writing? Wasn’t the printer-friendly GDD a form of communication?"
在不同的團隊專案會議中,ScrumMaster 強調我們團隊需要針對設計作更多的溝通。開發者卻面面相覷不知道該討論的文件在哪?我們不該面對方便列印的 GDD 做討論嗎?

Best Practice: Before there was Scrum, writing the GDD in Microsoft Word and putting it in source control was a best practice. A wiki as the GDD is perhaps better than a Word document in source control.
最好的做法:在 Scrum 出現之前,使用微軟 Word 然後放到版本控制軟體中最好。把GDD寫到 Wiki 也許比 Word 的做法更好。

9. Interrupt what people are doing to have them come to the daily 15 minute stand up meeting.

Schedule the daily 15 minute stand up meeting on everyone’s Outlook calendar with a 15 minute reminder, and then the ScrumMaster shows up 2 minutes late and politely waits for those team members who show up 10 minutes late to the meeting.
安排每日十五分鐘的站立會議,然後建立十五分鐘前的鬧鐘提醒他們。鬧鐘提醒之後 ScrumMaster 遲到兩分鐘,等遲到十分鐘的同仁出現。

Question: How does a 6 month project get a whole year behind schedule? Even if you haven’t read the book Mythical Man Month, it is common knowledge that the answer is one day at a time. The 15 minute daily huddles are not more important than contiguous hours of concentration and in-the-zone productivity.

Interrupting programmers, a.k.a. “committed pigs" of Scrum, in the middle of something technical, just to make them come to the team room only to ask them “Are you blocked?" is a good way to derail a half day’s worth of work as well as derail the entire project. Every day the conversation might go like this:

ScrumMaster: “Are you blocked?"
Engineer: “No, we were just working on making the widgets slide across the screen smoothly by using the first Hermite basis function to interpolate an ‘S’ shape curve."
ScrumMaster: “Since I’m a non-technical person why don’t you say that in English?"
Engineer: “The UI will look cool with smooth animation."
ScrumMaster: “Do you have an estimate for that?"
Engineer: “Tomorrow."

程式員,就像 Scrum 中所闡述"豬是用全心付出"的寓言一樣,在技術思考的中途跑來問"做完了沒?"的舉動就像是跑來把列車弄出軌是一樣的。每一天這個站立會議就像是下面這個情節:

工程師:我們正在用 Hermite 函式把介面內插,使其能以 S 的形狀平順地滑過螢幕。

Lesson Learned: The 15 minute daily stand up meeting was supposed to ensure that team members do not spend a day getting sidetracked by tasks that are not important to shipping the product. What if, before there was Scrum, developers had already been through a couple development cycles on various projects and had an established track record of working on the correct tasks and shipping products on time? How does the 15 minute daily meeting correct something that wasn’t broken? It doesn’t.
學到的教訓:一天十五分鐘站立會議是用來確認成員是否在工作上分心,跑去執行對時程不重要的旁鶩。在 Scrum 出現之前,開發者會在不同的專案上就已經有不同的開發週期,及一個確認進度及產品是否能準時產出的方法。站立會議試圖在沒有壞掉的東西上進行修正。

Lesson Learned: A 15 minute reminder for a meeting that starts 10 minutes late just wasted 25 minutes of time for everyone on the team. Suppose that after the meeting developers go back to their desks and spend an additional five to 15 minutes to concentrate and focus on what they were doing before the meeting. The time around a 15 minute meeting adds up to about 40 minutes of distractions during an eight hour work day.

This can amount to weeks of man hours in the course of the development cycle. The question here is: was this time well spent? Does this daily meeting accomplish what it is supposed to accomplish, and does the benefit outweigh the cost? Is there a better way to accomplish the same thing, and without consuming the time?

Having the backlog in an Excel spreadsheet separate from the bug database just makes more work for everyone to maintain a to do list in two separate tools. It’s obvious that development tasks and defects both have the same kind of data. In other words, database software does not know the difference between a dev task and a defect.

The only difference between a dev task and a defect is that a dev task comes before implementation and a defect is after implementation and includes steps to reproduce it. There should be no reason why dev tasks and defects can not be tracked with the same database, project management tool.

Best Practice: Some development tasks take a couple minutes to complete and some development tasks can take multiple days to complete. Instead of having the same conversation everyday with a Scrum Master, it would be better to put all tasks in a task management database.

The task database needs to have some kind of folder or query mechanism to view which tasks are being worked on today. Each person on the team can have their own folders and the folders can be called “WorkComplete", “WorkInProgress" and “WorkToDoNext". Each team member updates their own folders as they are switching tasks, and when they claim complete on a development task or claim fixed on a bug.

Everyone on the team, from their own machine, can see everyone else’s folders, so they can see what other team members are working on. The time estimates or time remaining can also be entered into each task item. If anyone wants to know what team members are doing today, that person can just look at the “WorkInProgress" folders. TestTrack, DevTrack and FogBugz are three commercial off-the-shelf defect-tracking and project-management database tools that have features that can support this.

If you find value in visualizing the Scrum task board or if you still use a Gant chart, consider making a little graphics program that takes everyone’s folders and tasks from the database and renders the tasks as nodes (like task cards on the Scrum board) in a directed acyclic graph of task dependencies on a horizontal axis time-line (like a Gant chart).
假如你認為 Scrum 的工作表的視覺化很重要,或是你仍在使用甘特圖,試著用繪圖軟體來把資料庫的資料以節點及非循環結構呈現出來(就像甘特圖一樣)。

Then you can use a projector to display the rending on a wall. Imagine you can add little progress-status bars on each task for the hours estimated and hours remaining (like health bars above avatars). You can even have animated effects for when team members are at their desks claiming complete on tasks (like the animation of files going into the recycle bin in Windows Explorer).
然後再用投影機顯示在牆壁上,想像一下每個工作的進度調都標明預估及剩餘時間(就像血條一樣)然後當團隊成員完成工資握的時候,就播放一個動畫(就像是 Windows 回收桶的動畫一樣)。

Imagine these animated effects will look like a fireworks particle system when you reach 100 developers on a team. Developers whose actual hours closely match estimated hours will receive +3 experience points and completing a cycle will allow them to level up. W00t! Executives will be so entertained to have the real-time visualization of teamwork and productivity that they will forget to play-test the latest build of the game.

Best of all, this electronic Scrum board will scale from small teams of 5 game developers to large teams of 250 game developers. Don’t forget to implement smooth-zooming to hyperbolic fish-eye view for large graph visualization (see Google images for those words).
最好的是,這個電子化的 Scrum 面板可以從五個開發者的小團隊到兩百五十人的大團隊都適用。別忘記要做平順的放大及專看全貌的魚眼鏡頭功能。

8. Moving all team members into a dedicated team room or team area does not cross-pollinate with cubicle assignments in the per-discipline-organized cubicle farm.

It’s good to have engineers sit next to each other so they can work through solutions to problems. It’s also good to have engineers sit next to content creators so the engineers can offer customer support for the custom authoring tools. It’s somewhat of an inhibitor if a developer has to walk across the building multiple times per day to collaborate with another developer. Part of the problem here is that desks and cubicle walls are not moveable.

Lesson Learned: If you want collaboration to happen, don’t mandate it first and then inhibit it at the same time. Instead first enable collaboration by removing the inhibitions, and then let collaboration happen by coincidence or out of necessity.

Best Practice: A way to make collaboration uninhibited is to first put desks on casters. Second, give everyone un-interruptible power supplies and wireless network connections. Next, consider getting rid of some of the cubicle walls. Team members are now enabled to unplug, and move their desks around the open bull-pen work area without shutting down and rebooting machines.

Thus a half day of face-to-face collaborative productivity is not inhibited by the hour it takes to move equipment, re-connect cables and reboot. Sure, un-interruptible power supplies for everyone are expensive. The hours of lost productivity, inhibited productivity, lost data, and damages from dropped equipment are also expensive.

Finally, tell developers it’s urgent to get development tasks done on time and they can push their desks and computers anywhere they need to in order to get work done. The result is that developers will find it compelling to push their desks next to each other out of necessity to be productive, and not because of the mandate to fulfill the prophecy of buzzword project management.

For added comfort, each development team or development group can have a designated team area and moveable privacy screens and/or a team room. Make sure to provide big whiteboards on wheels too.

7. A team member says “I’m not doing something right now because I was told there needs to be a task entered into the backlog and the task needs to be assigned to me by the project manager."

Lesson Reinforced: The proactive person looks for the next task that needs doing, asks customers if everything is working, and thinks about what can be done now to make next month’s to-do list lighter weight. The reactive person finished the work for the current two week sprint and believes they are not responsible for anything more until the next two week sprint when they are assigned more tasks.

Lesson Learned: Telling people that the whole team is focusing on only two weeks’ worth of work at a time, and they can’t work on tasks unless assigned, can make people reactive instead of proactive. It’s important that all team members can see the big picture, and are encouraged to take responsibility for the components and details of the big picture without micromanagement.

Best Practice: Adding tasks to the Scrum spreadsheet feels like having to ask permission for things that have trivial granularity. Developers assume ownership and responsibility for the project. Developers have foresight about what work needs to be done next month. Developers are able to proactively work on tasks ahead of schedule as well as provide customer service to each other without needing a task assigned.
最好的做法:把工作加到 Scrum 的試算表好像就必須請求權限一樣。開發者本來就應該擁有專案,同時肩負責任。開發者會預先評估下個月要進行的項目。開發者開始工作,就應該像客服提供顧客服務一樣不需要指派。

6. Start managing stories and sprints before all the people are on the team. Decide that your Scrum stories and sprints are 100% completed months before the project even has a QA tester.

Lesson Reinforced: Without QA in the first month of the project, you might as well admit that you are planning to have a death march and crunch time. It is common knowledge that adding QA to the project up front is not just important, it’s mission critical.

Best Practice: Throughout the development cycle, have engineers and content creators fix bugs as they go, so that the total open bug count stays at a minimum. Have QA on the project at the beginning of the development cycle to report bugs and to verify and close bugs. This is important for reducing crunch time due to overwhelming number of bugs at the end of a development cycle.

Every day, each developer can look at the open defect count and their own current dev task to do list. If there are more open defects than dev tasks, consider the bug count too high and spend part of the day fixing the lowest hanging fruit before switching to the next dev task.

Even better: each person on the team is customer-friendly and asks their customers and teammates if there are any issues that are preventing them from fixing their own bugs. Recognize that some bugs don’t get fixed because they have dependencies on other people fixing other bugs.

5. Scrum Pitfall: The 15-minute daily stand-up meeting degenerates into a daily go-around-the-table-and-each-person-give-a-status-report.
五,Scrum 的陷阱:十五分鐘的站立會議墮落為每天走到桌子旁邊報告進度的形式。

There are no action items from the daily meeting and the daily meeting doesn’t actually help increase productivity. At the daily meeting, the Scrum Master makes some remark that team members or the team’s actions are “not Agile".
每日會議並沒有實際產出任何東西。在每日會議的時候,Scrum Master 的存在其實就是一個團隊並不敏捷的證明。

Lesson Learned: There is no value or purpose in practicing Scrum just for Scrum’s sake.
學到的教訓:為了 Scrum 而實行 Scrum 沒有太大意義。

Lesson Reinforced: “Round table status report without action item" meetings are a waste of time. Certainly the cost of everyone else’s time combined does not outweigh the benefit of saving the meeting inviter’s time.

Best Practice: Maximizing everyone’s 40 hour a week bandwidth pipe is more important than a daily 15 minute meeting. If one person on the team has the lion’s share of work to do and others are waiting for the next daily build or the next two week sprint there is something wrong with the project or the project management. The workload needs to be evenly distributed.

Best Practice: Make sure all meetings have an agenda, and the agenda is part of the meeting invite. An action item includes the task that will be performed, the name of the person who will do the task and should also have a deadline or at least a time frame. For example: “Joe will have placeholders for the character model checked into source control by the end of the day tomorrow, so designers and engineers can work with it this week."
最好的做法:確保所有的會議都有大綱,大綱必須在會議通知中就說明清楚。任務中的一個項目是會在會議中討論,執行的成員應該要知道這件工作的時程。舉例來說:Joe 會負責把角色模型在明天結束時放到版本控制軟體中,這樣企劃及工程師就能在這周使用它們。

If there were no action items for anyone after the meeting, there was no purpose to having developers stop working and gather into a conference room. Status reports and other communication can be done over email, instant message or a phone call.

4. Make Scrum mandatory.
四,把 Scrum 變為形式化。

Stakeholders and executives make Scrum mandatory for the development team and expect quantitative project completion predictions. Managers don’t ever provide feedback to the team members, or reveal what value was actually gained from all those Scrum sizing exercises where developers choose numbers from a deck of cards.
專案負責人及行政主管把 Scrum 當作是一種託管的方式,希望專案的產出能夠量化。管理者沒有給予團隊意見及回饋,或是透露從 Scrum 的撲克牌計算中希望得到甚麼。

Even worse: executives don’t gain any value at all from the quantitative predictions that they didn’t already have with the project manager’s gut feeling. Or maybe the executives don’t understand that the team members are spending time doing ridiculous number guessing exercises to size a Scrum story in order to obtain the quantitative prediction that no one looks at.
更糟糕的是:行政主管並沒有從這些量化的預測上得到些甚麼,因為成員對專案的了解沒有專案經理來得詳細。也許行政主管並沒有真正了解成員花了很多時間在試著製作 Scrum 的使用者故事,算出那些沒有人會關心的預測數字。

Lesson Learned: Communication needs to go both directions, not just one direction. That means up the chain of command and also down. Feedback from, and visibility of stakeholders and executives is equally important as providing those stakeholders with a summary of the project status.

Best Practice: If a milestone is completed on time or if a game ships on time, stakeholders, senior management, and even executives walk around the cubicles and say to individual team members at the bottom of the org chart some things like “Hey, I heard your team completed its milestone on time and your project is on schedule, great job! That’s exactly what we like at this company! That’s excellent work!"

The positive reinforcement from the top of the org chart is worth more than any gold that anyone can earn in any MMO. Note to management and executives: if you want productivity increased, make sure your positive words are more valuable and more gratifying to employees than their time spent shooting giant zombie spiders and leveling up.

Imagine if there is just one milestone that is on time and that on-time delivery gets personalized recognition and reward by both the VP of product development and also by that VP of marketing who never seems to come out of his/her 700 square foot corner office for anything. Compare that to the same on-time milestone when no one seems to notice or care about the hard work that went into it. Success breeds more success! Low morale breeds high-cost employee turnover.

3. Implement only two weeks’ worth of work and write only the code based on what you currently know about the game design.

If you were not assigned to work on a task, then you can’t work on it. Ignore any concern that the game design may change later on in the development cycle.

Lesson Reinforced: Bottom-up code design is not better than top-down code design. Scrum, Agile, and Extreme Programming cultivate and promote bottom-up code design. When there is lack of big picture design documentation, the tendency is to implement one thing at a time, and then modify and tweak according to customer’s feedback.

Since there isn’t any foresight about what code will get shipped and what code will be thrown away due to design changes there isn’t a lot of care taken to make code maintainable. Adding features that were not planned for can be costly. Down the road band-aids and patches require time spent refactoring.

Best Practice: Make a game from low fidelity to high fidelity. The low fidelity version has prototypes of all the features. Code can be organized from top down and with understanding of all the features that are going into the product that is going to ship. Note that there is a difference between code and content. Perhaps the game content is what you want to be able to sprint and iterate on.

2. “Sprint Zero" is pre-production time.

Start the pre-production by putting all stories into the Scrum backlog spreadsheet. Pre-production only lasts two weeks. Ignore any concern that there still isn’t concept art before Sprint 1.
實做之前,設計的時候,不管這時候其實設計都還只有概念,只花兩周把所有的使用者故事放到 Scrum 的備忘錄試算表。

Lesson Learned: “Sprint Zero" is not pre-production. Creativity and innovation cannot be managed. Team brainstorming might be visible while sitting in a conference room buzzed on energy drinks but sometimes the best ideas come to mind while stuck in traffic during the car ride home from work. You cannot demand that someone comes up with the best creative game idea instantaneously. It doesn’t help to manage and track game ideas in a backlog spreadsheet, either.

Best Practice: Pre-production for any great product involves lots and lots of prototyping. Think on the magnitude of hundreds of prototypes. You would like to be able to mass produce these prototypes. Some ideas may never be more than a scribble on a little yellow piece of paper. Some prototypes might be full-featured software demos with hundreds of tuning knobs and ways to adjust content on the fly while the game is playing.

You need powerful prototyping tools that allow non-technical people to do lots of iterations every day. Pre-production does take time. The more prototypes that the team can create and demonstrate quickly will result in a better product.

1. Start managing the project by prioritizing tasks and asking for time estimates even before any GDD is written.

In every two-week sprint planning meeting, repeat the same behavior of prioritizing tasks before there is any design. This is about as dysfunctional as signing a production contract with a licensor before there is any design document or concept document. The worst case is then giving the licensor the freedom to make any change to the design at any time during full production with no regard for the cost of the team implementing the change.

Lesson Learned: The project management cart does not go before the game design horse.

Best Practice: Write a draft of the game design document and get feedback from engineers, content creators as well as the publisher and licensor. Do this before making a commitment to full production. Make sure that engineers and content creators understand the product design before you start prioritizing tasks and asking for time estimates.

Best Practice: You may have a mental checklist for sanity sake, and doing things in the correct order during a development cycle is important. Many developers have a gut feeling about death march projects. If your gut feeling says this is going to be bad unless the proper actions are taken, then it probably will be. Trust your gut feeling about game development over the Scrum consultant’s advice. Scrum consultants don’t make games; they get paid to give an all day Scrum Master certification training class.
最好的做法:你心中應該有一個合理的檢核清單。在開發週期用正確的順序進行。很多開發者對衝刺中的專案會有直覺。假如你的直覺告訴你應該要先做甚麼避免錯誤,那就應該去做。相信直覺優先於 Scrum 顧問的建議。Scrum 顧問沒做過遊戲,它們是靠 Scrum Master 認證課程營生。


Scrum and Agile methods are just tools in the project management toolbox. Suppose you had a crescent wrench, a vice grips, a channel wrench, and a pliers in your toolbox. If you just use the crescent wrench for everything without thinking about what it actually takes to get the project done, you are going to end up stripping a lot of your nuts.
Scrum 及敏捷方法只是專案管理的工具之一。假定工具箱有各種工具如鐵鎚,板手,尖嘴鉗。你卻只用鐵鎚處理每個狀況。你只是把各種情況看成釘子而已。

During many game development projects, some lessons are learned the hard way. The hard lesson learned is that Scrum is not a silver bullet that makes video game product development more successful. There are many technical details, know-how and best practices that have been gained by years of experience developing games, one development cycle after another, analyzing what went right and what went wrong.
在不同的遊戲開發專案中,有時候必須透過困難才能獲得成長。Scrum 帶給我們的教訓就是遊戲開發沒有萬用藥。它仰賴很多技術的細節,專業知識,以及從多年而來,一個接著一個的開發周期分析對錯的經驗法則。

Employing Scrum as a complete replacement for already well-established process and methods that existed before there was Scrum is a sure way to make a project miserable punishment. When Scrum is added to the project to solve problems and ensure success, it can easily become the cause of more problems than it solves if the pitfalls are not remedied with appropriate timing.
導入 Scrum 取代原本就已經建立的流程會等於讓專案接受悲慘的懲罰。當本篇提到的陷阱沒有適當的被處理,原本希望使用 Scrum 來解決專案的問題,確保成功,但卻很容易變成更多問題的成因,比起原本要解決的問題更多。

This article has provided some contrasting insights about Scrum. Certainly before making the executive decision to mandate Scrum, it should help to hear from both camps: those who advocate Scrum religiously and those who approach cautiously and play devil’s advocate.
本篇文章提供了一些關於 Scrum 的反向看法。在實際導入的決定之前可以藉此協助聆聽雙方的意見:宗教般支持 Scrum 的人以及認為 Scrum 是來搗亂的那些人。


在下方填入你的資料或按右方圖示以社群網站登入: 標誌

您的留言將使用 帳號。 登出 /  變更 )

Google photo

您的留言將使用 Google 帳號。 登出 /  變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 /  變更 )


您的留言將使用 Facebook 帳號。 登出 /  變更 )

連結到 %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.