Management

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


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

縮網址:http://wp.me/pBAPd-vP

原文網址:http://www.gamasutra.com/view/feature/132121/top_10_pitfalls_using_scrum_.php

Paul Miller
July 15, 2008

[譯按]本篇文章是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.
十,遊戲設計文件(GDD)再也不需要了,因為我們用備忘錄試算表來取代。

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.
缺少方便列印的備忘錄試算表其實並沒有抑制每個人溝通的能力。在我們使用備忘錄試算表之前,GDD也可以被印出來,在團隊會議時寫下註解。以文字的方式回饋也很容易。把GDD印出來帶到會議室,你可以在沒有電腦的情形下與成員討論。

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

ScrumMaster:你今天進度如何?
工程師:我們正在用 Hermite 函式把介面內插,使其能以 S 的形狀平順地滑過螢幕。
ScrumMaster:我懂技術,你能簡單說明嗎?
工程師:介面動畫會看起來很酷又平順。
ScrumMaster:你預計甚麼時候會做完?
工程師:明天。

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.
最好的做法:一些開發工作會花一兩分鐘完成,一些開發工作則是花費好幾天。不要每天都跟ScrumMaster講相同的話,反而應該要把工作放在一個管理工具上。

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.
團隊中的每個人,都可以看到其他人的資料夾,所以他們知道其他人在做甚麼事。每個工作項目都有預估時間及剩下時間。假如有人想知道某個人在做甚麼。可以直接看工作進度的資料夾。TestTrack,DevTrack,及FogBugz都是支援這個功能的商業追蹤臭蟲及專案管理的工具。

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.
強化的教訓:從小處開始寫並不一定從架構寫來得好。Scrum,敏捷,極限編程都是偏好從底層開始設計。當缺乏巨觀的設計文件,就會一次只做一個部分,然後再依照客戶的回饋修改。

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.
一,在遊戲設計文件(GDD)完成之前就藉由安排工作及評估來管理專案。

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 認證課程營生。

Conclusion
結論

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 是來搗亂的那些人。

廣告

發表迴響

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

WordPress.com Logo

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

Twitter picture

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

Facebook照片

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

Google+ photo

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

連結到 %s