samenwerking
Twee doelen van een ontwikkelteam
Een softwareontwikkelteam heeft, in abstracto, twee doelen: vernieuwing en veiligheid. Een team bestaat daarom, zou je kunnen stellen, uit twee delen: ontwikkelaars en testers. Deze conceptualisatie van een ontwikkelteam is het gevolg van een vorm van reductionisme. Maar een team valt niet te reduceren tot haar samenstellende delen. Ze bestaat uit haar samenstellende delen plus hun vormen van interactie.
Een tester of praten
Wij hebben geen tester in ons team. Niet omdat ik niet van testers hou (ik hou van testers), maar omdat het verkeerd gebruik van een tester dysfunctionele patronen in een team verbergt en in stand houdt.
De vergeten tester
Testen is cruciaal voor softwarekwaliteit. En toch, toen ik de kans kreeg een nieuw agile softwareteam samen te stellen, “vergat” ik de tester. Hoe verklaren we deze paradox? Hoe kan een tester tegelijkertijd zó belangrijk en toch ongewenst zijn?
Behoefte aan een testlane
Als we met z’n allen met één ding bezig zijn, dan is onmiddellijk, voor iedereen, zichtbaar wat er al getest is en wat niet. Een testlane is een lapmiddel voor het eigenlijke probleem: dat we onvoldoende samenwerken. Daardoor weten we niet wie wat al heeft gedaan. Dáárom heb je behoefte aan een middel om daar inzicht in te verkrijgen.
Uitrollen, vlak voor de demo
“Ik vind dat we niet meer uit moeten rollen vlak voor een demo,” zei een collega, “dat vond ik nogal spannend.” Liever had hij zichzelf nog wat extra tijd gegeven om zekerheid te krijgen dat de wijziging niet onbedoeld dingen stuk had gemaakt. Ik begrijp het sentiment van waaruit deze opmerking ontspringt. Maar het is in mijn beleving de verkeerde diagnose van de situatie.
Qu'est-ce que c'est un team?
Hij reflecteert: “Het nadeel van trunk-based development is dat een probleem in de pipeline jullie nu allemaal ophoudt. Omdat mijn wijziging de build blijkt te breken, kan niets van jullie er nog door.” – “Nee,” proef ik, een intuïtie najagend. “Het voordeel van TBD is dat dit probleem ons allemaal ophoudt. Dat betekent dat we nu met elkaar moeten praten. Het voorkomt dat we op ons eigen eilandje blijven, het focust ons op het allerbelangrijkste: ervoor zorgen dat we nieuwe features en verbeteringen in de code door kunnen zetten naar de productieomgeving.”
Een ontwikkelaar is verantwoordelijk voor drie systemen
Ik weet niet meer waar ik de inval had, onder de douche of op de wc of tijdens het tanden poetsen (duidelijk is in elk geval dat het op de badkamer was): een ontwikkelaar is verantwoordelijk voor (ten minste) drie systemen.
Hoe heb je het volgehouden?
Software ontwikkelen is niet makkelijk, het is van zichzelf al niet makkelijk en het wordt nog moeilijker omdat je met mensen werkt en mensen zijn nooit makkelijk.
Borrelpraat #2
Hij dronk cola, ik een biertje – maar verder zitten we op één lijn. Het duurde niet lang voordat het over de zoekindex ging – altijd die verdomde zoekindex. “Dat is al vanaf het begin een pijnpunt,” bekende ik. “En ik ben zelf onderdeel van het probleem geweest.”
De vergeten tester
Twee dingen kunnen tegelijkertijd waar zijn. (1) Ik vind de tester de belangrijkste rol hebben in het team. (2) Ik wil geen tester in het team. – Ik wil haast zeggen: de rol van de tester is te belangrijk om bij een tester neer te leggen, maar die uitspraak is makkelijk te misinterpreteren en nodeloos provocerend. En toch…