Over feature-teams en component-teams

29 januari 2013 15:50 Lennaert van der Linden Agile, Algemeen

Een klant vertelde me eens over een project dat in zijn bedrijf werd gestart om een back-end systeem opnieuw te implementeren. In een latere fase zou het front-end systeem worden aangepakt. De fasering was begrijpelijk, maar ik had zo mijn bedenkingen. In dit artikel geef ik aan waarom.

Validatie

Faseren biedt meer controle, omdat een kort (deel)project beter is te beheren dan een lang project. De keuze om een faseknip tussen componenten te leggen heeft echter nadelen, omdat problemen dan pas tijdens de integratie van de componenten zichtbaar worden.

Door te starten met het back-end systeem, moeten aannames worden gedaan ten opzichte van het nog aan te passen front-end systeem. Aannames die pas gevalideerd kunnen worden nadat het project voorbij is en het front-end project wordt gestart. De fasering per component lijkt controle op te leveren, maar resulteert in onzekerheid.

gebruikers, front-end- en back-end

Ik gaf daarom aan dat het beter is om front-end en back-end tegelijk te ontwikkelen. Als er dan al twee aparte teams moeten zijn voor de front-end en voor de back-end, dan zou het front-end systeem de vraag moeten aansturen voor het back-end team. Zo voorkom je ongebruikte functionaliteiten of functionaliteiten die niet aansluiten op de benodigdheden van het front-end systeem.

Feature-teams en component-teams

Een team dat alleen werkt aan één component van een systeem, bijvoorbeeld de back-end, is een component-team. Dit in tegenstelling tot een feature-team, dat voor elke feature alle benodigde applicatielagen implementeert. Een component-team houdt zich bijvoorbeeld alleen bezig met de database, een feature-team realiseert de front-end, webserver, database aanroepen.

Feature- en component-teams

In Succeeding with Agile noemt Mike Cohn de volgende voordelen van feature-teams boven component-teams:

  • betere evaluatie van de impact van ontwerpbeslissingen
  • reductie van onnodig werk gecreëerd door overhandigingen
  • zorgt ervoor dat de juiste mensen met elkaar praten
  • component-teams vormen een risico voor de planning
  • zorgt voor focus op het leveren van features

Enkel in uitzonderlijke gevallen is een (tijdelijk!) component-team gerechtvaardigd.

Conclusie

Het lijkt soms voor de handliggend om een project op te delen in fases op basis van componenten. Maar de fasering vormt een risico voor het project, omdat beslissingen niet gevalideerd kunnen worden tot de componenten geïntegreerd worden. Kies daarom voor feature-teams die alle lagen implementeren, of zorg ervoor dat het component-team gedreven wordt door de concrete vraag van een of meer feature-teams, zodat integratie van de componenten onderdeel is van elke fase.

Be Sociable, Share!

2 reacties »

  1. Compleet mee eens.
    Enige is dat je link naar het boek (hier) niet werkt. Ik denk dat dit de link moet zijn: http://www.succeedingwithagile.com

    Martin Sturm januari 30, 2013 13:13

  2. Hallo Martin,

    Bedankt voor je reactie. Ik heb de link bijgewerkt.

    Lennaert van der Linden januari 30, 2013 14:05

Reageer


6 + drie =

RSS feed for comments on this post · TrackBack URI