Verslag online seminarie distributed development

Niels Lion
Verslag online seminarie distributed development
Inhoud:
Op 8 Mei kregen we de kans om een online seminarie over distributed
development bij te wonen. Deze semenarie focuste zich op het gebruik van
distributed development voor gameontwikkeling. De format van het seminarie
was simpel, doch zeer interessant: een aantal mensen die actief zijn in game
development en gebruik maakten van distributed development kwamen om de
beurt spreken over hoe ze hier mee omgingen.
Eerst misschien eventjes uitleggen wat distributed development nu eigenlijk is;
distributed development is simpelweg een stuk software ontwikkelen terwijl de
verschillende ontwikkelaars niet fysiek bij elkaar zitten. Neem bijvoorbeeld een
spelletje dat ontwikkelt word door een Amerikaan en een Belg. Gezien de afstand
tussen deze twee landen te groot is om elke dag te overbruggen hebben deze
ontwikkelaars twee opties: ofwel verhuist een van hen, ofwel doen ze aan
distributed development (DD). Gezien deze webinar dan ook over het tweede
ging en niet over hoe gemakkelijk naar een ander continent te verhuizen zal ik
het dan ook maar over DD hebben.
De mensen die hun ervaringen met DD kwamen delen hadden diverse
achtergronden, ook al werkten ze allemaal binnen de games industrie. Zo was
een van de panelists een manager van Ubisoft, een van de grootste game
developers en publishers ter wereld met grote teams verspreid over de hele
wereld. Aan het andere einde van de schaal was er ook een indie developer
aanwezig die met een team kleiner dan tien man werkte. Ergens tussen de twee
in zat virtuos, een bedrijf van Franse origine maar met een HQ in Shangai dat
specialiseerd in art en animation voor games. Het spreekt voor zichzelf dat een
enorm bedrijf als Ubisoft met teams die honderden leden kunnen tellen op een
heel andere manier aan DD doet dan een klein indie team.
Multi-site collaboration
De manier waarop Ubisoft en Virtuos aan DD doet heet multi-site collaboration.
Wat dit betekent is dat bij ubisoft je wel nog teams hebt die fysiek naast elkaar
zitten, maar ze hebben diverse teams verspreid over de wereld. Dit brengt een
aantal voordelen met zich mee, zo behoud je bijvoorbeeld enkele van de troeven
van klassiek development: het feit dat je toch nog fysiek omringt bent door
collega’s terwijl je werkt betekent dat het gemakkelijk is om gewoon eventjes je
stoel te draaien en over bijvoorbeeld een stuk code waar je mee vast zit te
beginnen praten. Nog een voordeel is dat elke site zijn eigen groepsidentiteit kan
behouden. Aan de andere kant brengt dit ook een aantal nadelen en risico’s met
zich mee. Ten eerste is dit zeer duur, want je moet meerdere gebouwen elk met
hun eigen hardware en software-licenties kopen of huren, dit betekent dat enkel
grotere bedrijven multi-site development kunnen bekostigen. Verder loop je ook
het risico dat de verschillende teams op zichzelf teruggeplooid raken, het is
Niels Lion
immers van nature makkelijker om te communiceren met iemand die bij wijze
van spreken naast je zit dan iemand die vijf tijdzones van je af zit. Zoiets kan
zeer duur uitvallen voor een project, want uiteindelijk moet de code die elk team
schrijft perfect samen passen en een cohees product vormen, als dit niet het
geval is en er tijd gespendeerd moet worden om dit te fixen zullen er
gegarandeerd deadlines overschreden worden. Nog een gevaar is dat een team
onrealistische verwachtingen van andere teams kan hebben. Verder komt het
vaak voor dat de verschillende teams in verschillende tijdzones zitten, wat
betekent dat directe communicatie tussen twee teams nog moeilijker word.
Virtuos echter ziet deze verschillende tijdzones als een pluspunt. Als de teams
immers geografisch genoeg verspreid zijn betekent dit dat ze op een 24-uur
cyclus kunnen werken: Als een team stopt met werken begint een ander, zo is er
altijd iemand bezig met te werken en kan er altijd op feedback of vragen van de
klant gereageerd worden.
Ubisoft gebruikt een paar technieken om alles in goede baan te trachten doen
lopen. Ten eerste duiden ze een site aan als lead site. Deze site draagt dan de
ultime verantwoordelijkheid voor het project, en de andere sites fungeren dan
een beetje alsof de lead site hun cliënt is waar ze voor werken. Ten tweede
hebben ze regels voor de communicatie tussen de verschillende sites. Over
technische onderwerpen mag iedereen met iedereen praten, maar als het over
belangrijkere beslissingen en planning gaat mogen enkel de verantwoordelijk
managers met elkaar praten, waarvan er een per site zijn. Ze hebben ook een
Collaboration Producer in dienst wiens taak eruit bestaat ervoor te zorgen dat de
samenwerking tussen de verschillende sites vlot verloopt.
Tools
Om dit hele DD verhaal tot een goed einde te brengen bestaan er natuurlijk een
hele resem tools. Natuurlijk worden de klassiekers als github en team foundation
server ook binnen DD gebruikt, maar vooral Virtuos sprak over enkele tools waar
ik hiervoor nog niet gehoord had, met name Hansoft en Shotgun. Hansoft is een
Zweedse tool voor team collaboration en management in agile software
development. Shotgun is alsook een project management tool, maar dan
gespecialiseerd in art, met een uitgebreidere UI om bijvoorbeeld simpel feedback
te krijgen of te vragen op een 3D-model of op een texture, etc…
Indies
De laatste panelist was de leider van een klein indie team: het team telde slechts
vier vaste leden. Deze vier leden wonen elk in een ander land, dus doen ze ook
aan DD. Hun werkplaatsen waren een kamer in hun huis met een desktop PC.
Met zo een klein team spreekt het vanzelf dat het er wat minder professioneel
aan toe gaat: ze houden er geen managers op na, geen vaste werkuren noch
timetables. Een laxe houding betekende echter de dood van hun eerste project:
ze hadden besloten agile met sprints te werken, maar uiteindelijk hielden ze
nooit scrum-meetings en ze bleven maar features bijplannen terwijl hen huidige
features nog niet deftig geimplementeerd waren. Deadline na deadline werd
overschreden en hun budget raakte op. Echter besloten ze opnieuw te beginnen
Niels Lion
met een kleiner project. Dit keer ging het wel goed: ze hielden dagelijkse scrum
meetings en hielden zich aan de features waar ze van het begin voor gingen. Zo
slaagden ze er in binnen hun budget te blijven en een compleet spel af te
leveren. Ze gingen wel een maand over de oorspronkelijke deadline, het is en
blijft een IT-project natuurlijk.
Analyse competentieprofiel TI:
De meest relevante competenties zien volgens mij de volgende:
Competentie 2: Vlot functioneren in een internationale omgeving en de interne
en externe communicatie rond IT-projecten, dienstverlening en investeringen
voeren in drie talen en dit zowel mondeling als schriftelijk.
Het drie talen gedeelte is misschien wat minder belangrijk, ik geloof dat vooral
Engels essentieel zal zijn als je echt met vele nationaliteiten samenwerkt. Maar
vlot kunnen functioneren in een internationale omgeving is ongetwijfeld
essentieel bij DD.
Competentie 5
Gegevens verzamelen, opslaan en ter beschikking stellen zodat deze op een
correcte en gebruiksvriendelijke manier kunnen worden opgevraagd.
Bij DD is het van levensbelang voor het project dat al je medewerkers
gemakkelijk aan het werk dat je gedaan hebt kunnen en gemakkelijk feedback
kunnen geven en vragen.
Competentie 8
Een IT-opdracht projectmatig en teamgericht aanpakken met respect voor de
planning.
Zoals uit de presentatie van de indie-developer blijkt is het bij DD een noodzaak
dat je de discipline kan opbrengen om je consequent aan de planning en gekozen
werkwijze te houden.
Persoonlijke reflectie:
Ik kan zonder twijfel zeggen dat ik dit een van de sterkste seminaries vond die ik
tot nu toe heb meegemaakt, ik ben dan ook zeer blij dat we de kans kregen om
deze te bekijken ondanks het feit dat ze samen viel met een paar lessen. Ik
geloof dat ik veel bijgeleerd heb dankzij dit seminarie. DD is iets waar ik hiervoor
eigenlijk nog niets over wist. Nu ik er echter over na denk heb ik er eigenlijk wel
al een klein beetje ervaring mee: voor enkele vakken waar er groepswerken voor
zijn heb ik het de facto al op kleine schaal gebruikt om met bepaalde teamleden
samen te werken. Dit is natuurlijk heel wat anders dan echt DD te gaan
gebruiken in een bedrijf, maar toch. Het was dus ook een privilege om te mogen
horen hoe zulke diverse bedrijven er elk mee werken.
Het eerste dat me opviel tijdens het seminarie is dat terwijl het zich
concentreerde op game development bijna alles dat gezegd over DD kan
toegepast worden op allerhande software projecten, niet enkel games.
Niels Lion
Een tweede ding dat me opviel is dat iedere spreker zei dat er in hun bedrijf agile
word gewerkt. Het was leuk om te zien dat deze methode van werken die ook
binnen de HUB onderwezen word binnen zo veel internationale bedrijven
aanwezig was.
Na dit seminarie ben ik echt overtuigd van de krachten van DD, ik vind het
gewoon prachtig dat een groep mensen vanuit diverse landen vlot kan
samenwerken zonder te hoeven verhuizen. Ik vind het idee dat ik later potentieel
met iemand uit pakweg Shangai aan een project zou kunnen werken zonder naar
China te moeten gaan zeer spannend, en ik ben blij dat ik IT studeer.