Een extra mannetje lost niet alles op!

Het maken van een projectplanning is geen rocket science. Je schat in hoeveel uren je nodig hebt voor de klus en deelt die door de beschikbare uren van de ontwikkelaars. Et voilà, we hebben een doorlooptijd!

Een extra mannetje lost niet alles op!

Het maken van een projectplanning is geen rocket science. Je schat in hoeveel uren je nodig hebt voor de klus en deelt die door de beschikbare uren van de ontwikkelaars. Et voilà, we hebben een doorlooptijd!

Toch is het niet zo dat het uitbreiden van het development team automatisch leidt tot een snellere oplevering. Dat heeft een aantal redenen.

Het kritieke pad

In elk project moet je een aantal vaste stappen in een bepaalde volgorde doorlopen. Die activiteiten vormen het kritieke pad en dat bepaalt de minimale doorlooptijd van je project.

Enkele voorbeelden:

  • Voordat je schermen en workflows gaat bouwen, moet de basisfunctionaliteit op orde zijn (autorisatie, template ed).
  • Om rapporten te kunnen bouwen, heb je schermen/data nodig
  • De gebruikers kunnen pas functionele ketentesten doen als de interfaces zijn ontwikkeld

Over samenwerken en voortschrijdend inzicht

Sommige dingen kunnen ontwikkelaars samen oppakken, maar vaak is dat niet handig. Natuurlijk kun je met twee mensen aan één stylesheet werken, maar dat kost uiteindelijk extra tijd omdat je elke change moet mergen/testen etc. In de praktijk neemt de doorlooptijd van je project dus toe.
 

Verder moet je ook altijd wat slack inbouwen omdat er verschillende partijen bij het project betrokken zijn die een inbreng leveren. De klant zal bijvoorbeeld tijd willen om de geleverde functionaliteit te beoordelen en er moet ruimte zijn om eventuele feedback in de software te verwerken. Om deze redenen hanteren we bij CNOC een minimale doorlooptijd van 6 weken voor een project: 2 sprints van 3 weken.

Springen op een lopende trein: geen goed idee!

Nou kun je bij aanvang van een project vaak nog wel wat schuiven. Loopt het eenmaal, dan kun je het projectteam maar beter zoveel mogelijk intact houden. Het levert vrijwel nooit tijdwinst op om nieuwe developers aan een lopend project toe te voegen die de omgeving en de bestaande codebase niet kennen. Voor ze aan de slag kunnen met het fixen van bugs, refactoring, of het uitbouwen van andersmans code, ben je weken (of maanden) verder.

Alleen voor nieuwe code

Hoe meer code er al ligt, hoe meer tijd het bestaande team vrij moet maken om hun nieuwe collega’s wegwijs te maken in code. Doe je dat niet, dan is de kans groot dat ze er een puinhoop van maken zodat je nog verder van huis bent. Op korte termijn kost het inhuren van meer ontwikkelaars altijd extra tijd en zorgt het voor meer risico. De enige situatie waarin het nut heeft om extra mensen in te zetten, is als ze compleet nieuwe functionaliteit kunnen oppakken en de tijd hebben om zich goed in te werken.

Interesse?

Bij CNOC vinden we het altijd interessant om te sparren over alles wat met softwareontwikkeling te maken heeft. Neem contact met ons op, dan maken we een afspraak om kennis te maken.