Follow Us on Twitter

Samenwerken tussen projecten

Gepubliceerd in

Februari 2014 - Hoewel Scrum steeds vaker gebruikt wordt voor softwareprojecten zijn er nog veel bedrijven die het vertrouwde watervalmodel gebruiken. Beide project-technieken hebben dan ook hun voordelen. Scrum geeft meer flexibiliteit om met veranderende wensen van de klant om te gaan, terwijl waterval voor veel bedrijven vertrouwder is en een voorspelbare uitkomst geeft.

Het komt regelmatig voor dat meerdere projectteams samen moeten werken, soms zelfs teams van verschillende partijen. In die gevallen komt het voor dat er een Scrumteam moet samenwerken met een team dat waterval gebruikt. In die gevallen is er een conflict tussen de Scrum-methodiek die elke paar weken een nieuwe versie van het product oplevert, en de watervalmethodiek die pas tegen het einde van het project een enkele oplevering doet.

Aangezien de meeste projecten maanden lopen, zal het zelden voorkomen dat de waterval- en Scrum-projecten helemaal in de pas met elkaar lopen. Er moet daarom omgegaan worden met de afhankelijkheden tussen de projecten. Dit Whitebook gaat in op deze onderlinge afhankelijkheden, wat de risico's zijn als er niet goed omgegaan wordt met deze afhankelijkheden, en hoe een projectmanager en/of ScrumMaster kan zorgen dat deze risico's beheerst worden.

Het synchronisatieprobleem

Als er naar het watervalmodel gekeken wordt, is er pas tijdens de ontwikkelfase de mogelijkheid voor een werkende interactie met andere software. In de fases daarvoor (meestal analyse en ontwerp) wordt er nog geen software gemaakt, maar alleen bepaald welke software gemaakt moet worden, en hoe deze gemaakt moet worden. In de designfase is het wel goed mogelijk om een interface-definitie te maken die specificeert hoe de twee softwarepakketten met elkaar communiceren.

Bij het Scrummodel wordt er elke paar weken een ontwikkelcyclus doorlopen. In deze cyclus worden praktisch gezien alle fases van het watervalmodel doorlopen voor een klein deel van het project. Elke sprint wordt dan ook een deel van de uiteindelijke oplossing opgeleverd, net zolang tot de klant tevreden is met de som van de opgeleverde delen. Er wordt dus van uitgegaan dat er in een enkele sprint de interfacedefinitie bepaald wordt, en de software klaar is om deze interface te gebruiken of aan te bieden.

Projectverloop
Afbeelding 1: Het verloop van waterval en Scrum projecten

Er moet dus op een bepaald moment worden afgesproken hoe de twee softwarepakketten met elkaar moeten communiceren. Bij voorkeur op een moment dat opportuun is voor beide projecten.

De risico's

Door de verschillende projectaanpakken is er een risico dat er niet op het goede moment onderkend wordt dat er afspraken gemaakt moeten worden tussen de twee projecten. Als deze afspraken niet op het goede moment gemaakt (kunnen) worden zal er later in minimaal een van de projecten een probleem ontstaan omdat gewenste functionaliteit niet geleverd kan worden.

Voor een watervalproject betekent dat in principe dat er vanuit een latere fase weer teruggegaan moet worden naar de ontwerp- of zelfs analysefase. Dit zal op zijn minst extra kosten en vertragingen veroorzaken. Bijvoorbeeld voor het opnieuw inzetten van analisten en ontwerpers die ondertussen al met een volgend project bezig zijn.

Bij Scrumprojecten is dit risico een stuk kleiner omdat er om de paar weken weer een cyclus start. Door de korte cyclus is het verlies in tijd beperkt. Echter zal er nog steeds gekeken moeten worden of de benodigde kennis wel aanwezig is in het projectteam op het moment dat de interface met een ander project afgesproken en gemaakt wordt. Echter kan het wel zijn dat de architectuur niet berekend is op de beoogde interactie. In dat geval zal een eerder uitgevoerd werk aangepast moeten worden.

Al met al lopen beide projecten risico's wat betreft de beschikbaarheid van de goede kennis.

Planning

Om te voorkomen dat er op het verkeerde (meestal te late) moment ontdekt wordt dat er interactie met een ander softwarepakket nodig is, moet er vanaf het begin van het project rekening mee gehouden worden.

Voor watervalprojecten moet er tijdens de analysefase onderkend worden dat de interactie nodig is. Tijdens de ontwerpfase moeten er dan afspraken worden gemaakt over de interactie, en hoe deze tot stand gaat komen. En tijdens de implementatiefase moet de interactie geïmplementeerd worden.

Voor Scrumprojecten komt er op de product backlog een item voor de integratie met het watervalpakket. Bij het onderzoeken van dit backlog item moet dan ook de noodzaak tot integratie worden onderkend, zodat tijdens de relevante sprints de goede capaciteit aanwezig is. Als er voor meerdere backlog items communicatie nodig is dan moet dat van te voren onderkend worden, en moeten de interface afspraken als geheel gedaan worden.

Er moet wel rekening mee gehouden worden dat een enkele fase in een watervalproject over het algemeen een periode van meerdere sprints in een Scrum project beslaat.

In een ideale wereld lopen de waterval- en Scrum projecten globaal gelijk op. In dat geval kan in de analysefase van het watervalproject contact worden gelegd tussen de projectteams. Tijdens de ontwerpfase van het watervalproject wordt dan de interface tussen de twee pakketten afgesproken. Normaliter zal het Scrumteam deze interface dan direct implementeren. Let er wel op dat er bij het Scrumproject gekeken moet worden naar alle backlog items die een afhankelijkheid hebben met de interface. Over het algemeen is het achteraf aanpassen van de interface tijdrovend.

Als het Scrumteam gebruik maakt van een interface aangeboden door het watervalpakket dan zal er een zogenaamde stub gemaakt worden die de interface simuleert tot het watervalteam ver genoeg gevorderd is om de interface vrij te geven. Op dat moment zal ook pas blijken of de afspraken goed genoeg zijn geweest, en de interface werkbaar is.

Als het Scrumteam een interface aanbiedt die het watervalpakket zal gebruiken dan zal deze ongebruikt blijven tot het watervalteam in de ontwikkelfase komt en gaat integreren met de interface van het Scrumpakket. Het gevaar is dat pas veel later ontdekt wordt dat de interface niet voldoet. In dat geval moet er teruggegaan worden naar een oud stuk code, en hoe langer geleden er aan een stuk code gewerkt is, hoe meer tijd nodig is om aanpassingen te doen.

Hoewel het niet helemaal in de Scrummethode past is het in het geval van een dergelijke situatie wel wenselijk om een tijdslijn aan te nemen die past bij het waterval project. Spreek de interface af tijdens de ontwerp fase van het waterval project, en implementeer deze tijdens de ontwikkelingsfase van het watervalproject. Dit betekent ook dat er van meet af aan gekeken moet worden naar alle functionaliteit (binnen beide projecten) die van de interface gebruik gaat maken, en wat de eisen/wensen hierbij zijn.

Het is natuurlijk niet altijd zo dat twee projecten geheel in de pas lopen. Globaal zijn er twee mogelijkheden. Als het watervalproject al voorbij de ontwerpfase is op het moment dat het Scrumteam contact legt om een interface af te spreken, zal er voor het watervalteam een stuk analyse en ontwerp opnieuw moeten worden gedaan. Met bijbehorende kosten.

Als het Scrumteam al een tijd bezig is op het moment dat het watervalteam contact legt om een interface af te spreken, kan er een sprint gereserveerd worden om dit te realiseren. Dat zou andere delen van het pakket op kunnen schuiven, en tijd kunnen kosten om de architectuur aan te passen aan de nieuwe wensen.

In beide gevallen kan het te laat contact leggen met een projectteam problemen opleveren. Zeker als daardoor later de interface niet blijkt te voldoen aan de eisen van de opdrachtgever.

Conclusie

Als je binnen een project ontdekt dat er met andere software interactie nodig is, prioriteer dit. Als er te vroeg contact gelegd wordt, dan is er nog niets aan de hand, maar kunnen er wel afspraken gemaakt worden. Als er te laat contact gelegd wordt, dan kunnen er behoorlijke kosten bijkomen aan mankracht en tijd om de communicatie tussen de twee softwarepakketten tot stand te brengen.

Let hierbij ook goed op dat er naar de complete interactie tussen de twee projecten wordt gekeken. Een interface in delen bepalen is over het algemeen een perfect recept voor te late oplevering. Voor het Scrumproject betekent dit dat backlog items over meerdere sprints verdeeld worden.

Waardering:
 

Reacties

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.

Meer informatie over formaatmogelijkheden

CAPTCHA
Deze vraag is om te testen of u een persoon bent en om spam te voorkomen
Image CAPTCHA
Enter the characters shown in the image.