Porting phase optimization and productivity maximization

2. Porting phase optimization and productivitymaximization Eric Thommerot

3. Introduction: Why is it an important topic? • Critical phase at the end of the project (on which all the rest has the biggest impact) • Commitments to final customers (carriers) taken and launch slots reserved • Credibility of your company is in question • The product quality might be altered by this phase if it is not prepared/done correctly

4. Introduction: What are we going to talk about? • This is the presentation of a mobile product life cycle within a standalone studio (dev & portingdone in the same studio) • Various small tips that will help you prepare and secure your porting phase • How to organize your teams in the best way • How to maximize the exchanges between your porting and QA teams • How to avoid miscommunication between those two teams • How to measure that your project is healthy

5. Introduction: What will not be covered in this session and why? • This presentationis a bit European-centric BUT the sameprinciplesapply to the US. • We will not talk about why is it difficult to port a game over 300+ handsets (you are all supposed to be familiar with this) • We will not talk about handset bugs (you are all supposed to know most of the handsets are buggy) • We will not talk about porting factories, their strengths and weaknesses (I’m not here to impose my vision and you are all supposed to have your own porting tools)

6. “ Project preparation How can I prepare the project to ensure that the porting phase of my product is going to be easy and secured? 50% of the riskcanbecreatedhere…

7. Identify the mainstreams correctly • Select yourmainstreamsdepending on the projectconstraints: • Time • Humanresources • Expectedquality • Project complexity  Defineyourportingstrategy (seeAppendix 1)

8. Create a genericporting plan based on yourownexperience • Whatis a porting plan (seeappendix 2)? • Knowledgebased on pastprojects • Group phones per familiesbased on screen size, heapmemory and speed • Sort the phone familieseasyat the top, hard at the bottom • Logicalway to addressdevices by proximity (avoiddoingtoobigstepsfrom one phone to anothertypicallydon’tjumpfromSonyEricssons to Motorola triplets in a single step)

9. Create a genericporting plan based on yourownexperience • How to use it? • It’s a living document as long as itis not targeting a project (add new phones in betweenporting phases) • Freezeitwhen a porting phase starts and cutomizeitdepending on marketneeds. • Customizeitbased on the specificities of yourproject (itmight change from one project to anotherdepending on the projectcomplexity) • Use it to progresssafely and manage risksduring the porting phase (willbeexplained in the followingslides)

10. Answer all potential questions youcanthink about at the design stage • Answer the basic questions: • What’sgoing to happen if I want to target a phone withlessmemory? • What’sgoing to happen if I want to target a phone acceptingsmallerbinaries? • What’sgoing to happen if I want to target a phone with a smallerscreen size? • Basicallywhat’sgoing to happen if mytargetedplatform changes significantly, whatshallwe do? • Writeit in the game design…

11. Porting technology selection • Select a portingtechnologynow (and think about the future): • Don’t select ittoolatewhen the developmentis more thanhalfdone  Avoid a 1st portingfrom a technology to another • Can beyourownportingtool but think about ittwicebeforeinvesting, don’tre-invent the wheel • Capitalise yourexperiencefrom one project to another  Improveyourefficiencysoreduceyourcosts

12. “ Interlude How shall I organize my team efficiently to reach the maximum productivity? (Serial VS Parallel organisation)

13. Team organization • Serial: Product 1 Product 2 Team A Team A Team A • Parallel: Product 1 Dev Team A Port Team A Product 2 Dev Team A Port Team A Dev Porting Dev Dev Porting Dev Porting

14. Team organization • Serial VS Parallel: • Serial probably more efficient on the short term (the team knowsits code sothey are faster in reducing the product to more restricteddevices) • Serial is more cost effective if you do not produceenoughgame per year. • Serial probablyless efficient on the long runbecause of the lack of specialisation (youcanforgetthis or that bug or workaround in betweenprojectswheresomeonedoingit all the time will not forget) • If the two teams workregularlytogether, then the Serial organizationadvantagedisappearssincethey ‘ll know eachother’s habits  If possible select a parallelorganization.

15. “ Project development What can help me during the development phase to ensure that the porting phase of my product is going to be easy and secured?

16. Charge everybodywithresponsability & accountability • The pro-activity of the developers is crucial • Prepare the project and ease the life of the porting guys if they see something obvious (50% of the necessary settings to reduce the basic binary might be identified by the developers) • The development team needs to be educated and rigorous (comment the code, do not allow unexplained magic numbers) • Involve the porting guys a bit before the porting phase • Organize a pre-porting session somewhere around the Beta phase of the project (may allow to identify bottleneck and things that can be done better) • Involve the porting guys to help the original team with the screen size targeting (will be useful to be familiar with the code)

17. Be careful yourself • Do not do stupid supposed savings during the development phase that you might pay for during the porting phase (i.e. avoid creating an editor that takes time, hardcode something)

18. “ Porting phase What can I do now to maximize the performance?

19. The main problem Porting plan Delivery Validations Porting team X resources QA team Y resources

20. The main problem • 2 teams: • Differentresourcenumbers • Differentcapabilities • But: • Must beused to their real capabilitieseveryday • Must synchronise themselves the best possible way  Provide the best performance at the end

21. Mainstream test & preparation • The orginalmainstream test is crucial. Not allowed to find a significant bug whenyou have 100 gold devices. • Request all necessary art assets (screen size & bit depth) fromyour art team in advance (during the validation of the mainstreamis a good scheduleso the porting team can move full speed withoutwaiting for anyelement)  Prepare a document containing all the necessaryscreensizes for your art team

22. What about BREW • Brewis a separatetechnology if you’redoingitmanually. • Get the Brewscreensizesimplementedalongwith the basic mainstreams • Split the projectwhen the mainstreams are gold • Brewcanbeseen as someadditionalhandsets if you do itusingsomeknown conversion tools in that case addthem as extra handsets to yourporting plan.

23. Deliverystrategy • Do not deliver more thanyour QA team needs to keepthembusy for half a day to a day (itisgenerallyconfusingtheydon’t know what to beginwith if yougivetoomanythings) • Use a clearway to communicateyourdeliveries. Sometoolscan help you (seeappendix 3). Poor communication cancreate confusion and lostdays (especially if you’reworkingwithremote locations in different time zones) • Drive the deliveries in such a waythat the « strategic » binaries are tested first. • CARE… CARE… CARE… bepresent and adaptyourselfveryquickly to anywrong feedback (binarycrashing for instance freeing a slot thatyouneed to fillasap).

24. Risk management • With your porting strategy defined earlier, move: • Down (if top-bottom) • Up’n down (if bottom & low-top to middle) • Up (if bottom to top) • Every step is a potential risk to break the system and have the QA team waiting for some deliveries. • Coordination between your porting team and your QA team will result in the success of the porting phase (if the teams are compatible & everybody is used all the time).

25. Risk management • But move wisely… • You can move on more than 1 front at the same time (QVGA & MidRes for instance). It willallowyou to manage the difficultyeveryday. • Do not assigneverybody on hard thingsat the same time. Manage the difficultydepending on the number of deliveriesyouneed. • Use a step by stepprocess, do not do a toobig single jump • Use the compatibilities to fill the gaps between the deliveries • Alwayskeep one resource (at least) to deal withdebugatanytime  Example

26. Communication • Communicateclearly: • Where the project stands (progression, they must see the end of the tunnel to increase the motivation) • Giveappropriate objectives on a weekly basis soeverybodyknowswhat to do • Don’thesitate to saywhenthings are good (avoid a tooEuropeanbehaviour) • Communicatewhen the goal isreached • Takecredible actions if the goal isn’t • Show you are withthem and not againstthem…

27. “ Project health How can I measuremyprojecthealth?

28. Project Health • Measure the projectschedule on an average basis (being late one week isn’t dramatic if you are not late all the time).  Use a projectschedulingtool to check if the situation is good • If the situation is good you’llsee: • The objective of everyweekisreached • Lowlevel of conflicts • Teams are used at the max of their capacity (will allow you to measure the compatibility of the teams, 1 porting guy cannot give enough work for 20 QA guys alone) • The bug database is not growing dramatically without decreasing (organize “debug sessions” in that case to reduce it).

29. THE END Questions?