Wet van conway

…in middelgrote tot grote organisaties tekent een beginnende systeemarchitectuur zich af. Diverse ontwikkelteams ontstaan. De eerste sprints leveren werkende systemen op.

✣  ✣  ✣

De nieuwe organisatie en het nieuwe systeem versterken elkaar wederzijds zodat er zowel effectief als efficient gewerkt kan worden.

De wet van conway is een van computerprogrammeur Melvin Conway die het idee in 1986 introduceerde:

Organisaties die systemen ontwerpen zijn beperkt tot het produceren van ontwerpen die kopieën zijn van de communicatiestructuren van die organisaties.

De wet van conway is een valide sociologische observatie. Om bijvoorbeeld twee separate softwaremodules correct op elkaar te laten aansluiten moeten de ontwerpers en bouwers met elkaar communiceren. Daarom zal de structuur van deze aansluitingen in het systeem de sociale structuren van haar ontwerpers en bouwers spiegelen.

Mel Conway observeerde dat er een zeer nauw verband is tussen de structuur van een systeem en de structuur van de organisatie die het ontwierp.

…Elke organisatie die een systeem ontwerpt zal onvermijdelijk een ontwerp produceren waarvan de structuur een kopie is van de communicatiestructuur van de organisatie.

Anders geformuleerd:

…Merk op hoe de bestaande organisationele structuur veranderingen in architecturele structuur verhindert.

De bestaande structuur (= architectuur = ordening) van een organisatie is mogelijk het grootste en moeilijkst te slechten knelpunt voor de hervorming naar een organisatie met personateams die zich om de behoeften van haar klanten heenvouwen.

Daarom:

Verzeker je ervan dat de organisatiestructuur en de systeemarchitectuur elkaar weerspiegelen en uitwisselbaar zijn met elkaar. Ontwerp nieuwe sociale en organisatorische structuren die het bereiken van het doel katalyseren. Koester een gemeenschappelijke woordenschat, met name voor systeemontwerp en -architectuur, die aansluit bij het grootse gevaarlijke gedurfde doel (en anders is dan de bestaande).

✣  ✣  ✣

✣  ✣  ✣

Conway's observatie vertelt hoe team- en organisatiestructuur ontwerp (ver)hindert en moet zeker niet als aanbeveling worden geïnterpreteerd.

Het (software)product spiegelt de structuur van de organisatie die haar bouwt. Als je een grote, slome organisatie hebt, neig je naar het bouwen van grote, slome software.

De mate waarin een organisatie niet volledig flexibel is in haar communicatiestructuur bepaalt in welk mate ze in elk ontwerp een spiegelbeeld van zichzelf stempelt. Omdat het ontwerp dat het eerst verschijnt bijna nooit de best mogelijk is moet het overheersende systeemconcept mogelijk wijzigen. Daarom is de flexibiliteit van een organisatie belangrijk voor effectief ontwerp. Koester en eer daarom die organisatie-ontwerpers die de organisatie lenig, wendbaar en flexibel houden.

Gedachte-experiment met twee opties: Iedereen die aan het product werkt:

1. kan één en slechts één kleine taak extreem goed uitvoeren, maar geen enkele andere.
2. kan alle activiteiten goed uitvoeren en blinkt uit in een enkele.

Welke optie maakt meer doorvoer van producteigenschappen toen? Welke optie heeft meer flessenhalzen? Welke biedt meer aanpasbaarheid en flexibiliteit? Ook al is de eerste optie niet of nauwelijks haalbaar, op een continuüm van wenselijkheid willen we een lerende organisatie aanmoedigen die in die richting beweegt—flessenhalzen verminderend, mensen die één gebied goed kennen, dan twee, …

Observaties:

• Ontwikkelen van mulit-vaardige mensen creëert rijkelijke leerkansen en nauwe samenwerking met verschillende soorten experts.
• Ontwikkelen van programmeurs die bij verschillende componenten kinnen helpen vereist een variëteit van ervaringen en mentoren.
• Gegevens tonen een buitengewone variantie in individuele productiviteit van programmeurs—onderzoeken suggereren een gemiddelde van vier keer sneller in de top versus de bodem kwartiel.

Er is een sterk verband in software-ontwikkeling tussen wat je weet en wat je goed kan doen'—software is het perfecte voorbeeld van een kennis-intensief beroep. Kortom, er zijn grote zakelijke voordelen als we vaardige ontwikkelaars hebben die voortdurend leren.

Dit leren kent een aantal eerste voorwaarden voor verantwoordelijkheden voor de leiding:

• ruimte voor reflectie—praktijk van veel code schrijven, code lezen van anderen en reflecteren op beide; en
• een structuur die voortdurend leren ondersteund.

Je kunt als organisatie willen versnellen, maar als je niet ook van richting kunt veranderen ga je steeds harder op je ondergang af. Nog een wrak op de weg.

De hoeveelheid vertraging, organisatie van de organisatie, overtollig management, overdrachten, slechte code, duplicering, en complexiteit van coördinatie die wordt geïntroduceerd in grote groepen die zich in componentteams organiseren wordt in de eerste plaats gedreven door twee angsten:

1. mensen kunnen of behoren geen nieuwe vaardigheden te leren (andere componenten, testen, …); en
2. code kan niet effectief gedeeld en geïntegreerd worden tussen mensen.

De eerste aanname is gelukkig onwaar en de tweede, meer waar in de zeventiger jaren, is ondertussen opgelost met wendbare bouwparktijken (agile engineering practices) zoals testgedreven ontwikkeling (test-driven development of TDD), doorlopende integratie (continuous integration) en doorlopende ingebruikname (continuous deployment).

In de zeventiger jaren leken componentteams een logische structuur vanwege haar seriële ontwikkelcyclus, breekbare versiebeheer, zwakke testinstrumenten en praktijken omdat schijnbare voordelen waren:

• Mensen ontwikkelen smalle gespecialiseerde vaardigheden die tot schijnbaar sneller werken leiden als je ze lokaal in plaats van op de gehele systeemdoorvoer van gegenereerde klantwaarde en op korte in plaats van lange termijn bekijkt;
• die specialisten breken hun code minder waarschijnlijk; en
• er zijn geen conflicterende veranderingen in de code door andere teams.

Gelukkig zijn er ondertussen nieuwe structuren voor levenscycli en teams ontdekt en zijn er krachtige, nieuwe en robuuste praktijken en instrumenten voor versiebeheer, integratie en testen.

• Producteigenschappen beelden zich gebruikelijk niet één-op-één af op componenten en daarom ook niet op een componentteam. Meestal overspannen producteigenschappen meerdere componenten en modules. Het kost tijd en geld en managers om de onderlinge afhankelijkheden te coördineren en op elkaar af te stemmen.
• Als meerdere componententeams betrokken zijn is het onduidelijk wie er eindverantwoordelijk is voor analyse van eisen. Dit leidt tot een afzonderlijke analist of analistenteam.
• Een aparte requirements architect dient op hoog niveau het systeem met haar componenten en modules te ontwerpen en te ontleden naar componententeams. Vaak leidt dat tot een matrixtabel die componenten en eigenschappen met elkaar in verband brengt. Ook die tabel moet weer onderhouden worden.
• Van begin tot eind testen van een produceigenschap hoort niet bij een specifiek componentteam thuis. De verantwoordelijkheid hiervoor beleggen kost veel moeite en coördinatie. Een apart systeemtestteam die pas starten met testen nadat de ontwikkeling klaar is—vaak veel later omdat ze het werk van álle verschillende componentteams nodig hebben en deze zelden op het zelfde moment klaar zijn. Bovendien hebben ze een aanzienlijke werkvoorraad van alle andere producteigenschappen die ze moeten testen.

Over ontleden gesproken:

• samenstellende delen af te zonderen;
• op te lossen in de originele elementen;
• vrijstellen van eerder bestaande vormen van (chemische) combinatie;
• tot ontbinding te brengen;
• te laten rotten of bederven.

En dat terwijl we er juist een geheel van willen maken.

Waterval ten voeten uit. Enorme verkwisting in overdrachten, goedkeuringen, overleggen, coördinatie, vertraging en voorraden met een houdbaarheidsdatum. Typisch sequentieel ontwikkelen, levenscyclus en mentaliteit. Vreemd genoeg hebben mensen de illusie dat ze agile of scrum ‘doen’ omdat ze miniwatervallen in een kortere en iteratieve cyclus doen. Maar miniwatervallen zijn niet lean en agile ontwikkelen. We willen liever gelijktijdig ingenieurswerk.

Het afmaken van een enkele, niet-triviale producteigenschap kost nu typisch vijf of zes iteraties in plaats van een—en dat is zelfs een optimistische inschatting. Erger nog, voor zeer grote systemen voegt de organisatie een vet platform toe, inclusief haar architect en test—elk gespecialiseerd en elk een fasevertraging toevoegend voordat we eindelijk toegevoegde waarde aan de klant kunnen leveren.

Structuren van componentteams en de ontwikkelingen van de sequentiële levenscyclus gaan hand in hand.

Er zit een systemisch gebrek in componentteams.

In traditionele productgroepen voor grote producten met componentteams weten de meeste ontwikkelaars slechts een smal fragment van het systeem, en meest in het oog springend is dat ze weinig zaken zien of leren die nieuw zijn. En dat terwijl de meeste mensen toch vooral plezier scheppen in nieuwe dingen doen.

Tegelijkertijd zijn er altijd enkele wonderbaarlijke mensen die heel veel over het systeem weten—die mensen waar je naar toe gaat als er een onverklaarbare fout optreedt. Als je vraagt hoe dat mogelijk is, krijg je vaak het antwoord, “Hij weet alles omdat hij altijd ieders code leest.”. Of, “Hij heeft aan veel verschillende code gewerkt.”. Interessant genoeg kom je meer van dit soort mensen tegen bij grote succesvolle open bron producten.Er is culturele waarde in “Gebruik de bron, Luuk” die het lezen en delen van kennis via code bevordert.

Wat doet dit er toe? Componentteams verhinderen ontwikkelaars het lezen en leren van nieuwe gebieden van de codebasis, en, breder, van het leren van nieuwe dingen.

Contrasteer deze organisationele mentaliteit met die van Peter Senge's Het Vijfde Discipline waarin hij de cultuur, focus en geest van langlevende bedrijven samenvat: lerende organisaties. Lean Process and Product Development benadrukt dit thema ook en vat de inzichten van het succes van Toyota's nieuwe productontwikkeling samen: Het gaat over het creëren van bakken kennis en over voortdurend leren.

Bij Toyota zeggen ze:

“Mono zukuri wa hito zukuri”

“Dingen maken gaat over mensen maken.”

Componententeams verhinderen een lerende organisatie waarin ontwikkelaars uiteindelijk vaardig wordt in een gebied, en dan in nog een, en nog een. Zo bouwt ze een leerschuld op. Leren dat had moeten gebeuren maar niet is gedaan vanwege enge gerichte specialisten, korte termijn oplossingen, brandbestrijding, gebrek aan reflectie en achterblijven met moderne ontwikkelingen. Wie niet met zijn tijd meegaat, gaat mettertijd. In het begin, bij een jong product, merk je nog niet zoveel van die schuld, maar naar mate het product ouder wordt, wordt het zwaarder en zwaarder.

Componentteams maken lui en sporen makkelijker werken aan, niet het leveren van meer waarde. Componentspecialisten creëren, net zoals als andere enkelvoudige specialisten, een organisationele dwang of flessenhals. Dit leidt tot een fascinerende suboptimalisatie: Werk wordt vaak gekozen op basis van specialisme dan klantwaarde. Vaak worden die producteigenschappen gekozen die de specialisten het best en snelst kunnen realiseren. Hierdoor neigt er een maximale hoeveelheid code gegenereerd te worden, ten koste van waardecreatie voor de klant. Code die door slechts enkele begrepen en onderhouden kan worden en toevoegd aan de technische schuld. Componentteams kiezen dus als vanzelf voor de makkelijkste zaken en niet voor de meest waardevolle. Soms kiezen componentteams voor de realisatie van zaken die pas over een half jaar nodig zijn en genereren daarmee potentieel afval (waste).

Vaak is deze suboptimalisatie en creatie van afval onzichtbaar, omdat:

1. er geen prioritering op basis van klantwaarde is, of de prioritering vindt plaats op basis bizarre en grofkorrelige zaken zoals “verplicht” en “absoluut verplicht”;
2. componentteams zijn druk bezig de fouten van hun component te herstellen; en
3. er is ruim voldoende werk voor interne lokale verbeteringen.

Iedereen lijkt uitermate druk—ze moeten wel waardevol werk doen!

Deze sub-optimalisatie wordt duidelijk zodra je een echte product werkvoorraad maakt die geprioriteerd is op basis van waarde voor de klant.

Poel met Hulpbronnen

Een snelle oplossing om het prioriteitsprobleem op te lossen is door projecten de creëren waarop specialisten worden ingezet. Projectmanagers kiezen mensen uit een poel van specialisten en geven ze terug aan de poel zodra het project is afgelopen. Hierdoor ontstaan projectgroepen of producteigenschapprojecten met matrixmanagement. In dergelijke organisaties worden mensen gedegradeerd tot ‘hulpbron’, alsof het machineonderdelen zijn en menselijke en teamdynamiek niet van belang zijn voor productiviteit of motivatie.

Met een poel van hulpbronnen vouwt het management de organisatie rondom enkelvoudige specialisten. Op papier of in een projectmanagementistrument ziet dat er misschien goed uit, maar in werkelijkheid blijkt dat mensen geen machines zijn—ze kunnen leren, geïnspireerd of gedemotiveerd raken, focus krijgen of verliezen, etc. In praktijk heeft een poel met hulpbronnen vele nadelen:

• Lagere productiviteit door losse projectgroepen—kortlevende groepen mensen die samengebracht worden voor een project—een “projectgroep”—hebben een aantoonbaar lagere productiviteit.
• Lagere motivatie en werkplezier—“Wij haten het om in een poel van hulpbronnen te zitten en in meerdere kortlevende projectgroepen gegooid te worden.” is een veelgehoorde klacht.
• Minder lering—Enkelvoudige specialisten werken en leren zelden buiten hun gebied.
• Lagere productiviteit door multi-tasking—Meestal worden de beschikbare specialisten dun uitgesmeerd over verschillende projecten, 20% op project A, 40% op project B, 10% project C, enzovoort. Hierdoor wordt de specialist gedwongen tot multi-tasking en kostbare contextwisselingen hetgeen ten koste gaat van productiviteit en motivatie.
• Lagere productiviteit en doorvoer vanwege toegenomen overdracht en verkwisting door wachten—Mensen in een tijdelijk groep doen vaak meerdere dingen van meerdere projecten tegelijkertijd. Dus werken ze niet tegelijkertijd samen aan hetzelfde ding waardoor overdrachten en wachttijden ontstaan. Zonde.
• Lagere productiviteit door toegenomen overdracht en wachttijden door fysieke spreiding—De projectgroep zit zelden samen in dezelfde ruimte: projectleden zitten op verschillende verdiepingen, in verschillende kantoren, steden of tijdzones en hebben weinig of geen relatie met elkaar. Productiviteit leidt hier zwaar onder.
• Lagere productiviteit en hogere kosten door meer managers—Als elk tijdelijke projectgroep een eigen manager heeft—meestal in een matrixmanagementstructuur—zijn de kosten hoger en de productiviteit lager vanwege het omgekeerde verband tussen het aantal managers en productiviteit.

Door gebrek aan ga kijken mentaliteit, waardoor ze niet fysiek bij de werkplekken zijn die waarde produceren—gelooft management en leiding dat een poel van hulpbronnen van specialisten werkt. Op papier en in het rekenbland lijkt het allemaal te werken. Bijstellen van en meten op wat efficiencycijfers hier en daar werkt goed. KPIs worden er op ingeregeld, en zo schroeft men het hele systeem vast. Zo vast, dat alle flexibiliteit en wendbaarheid verdwenen is. Zo vast dat er mensen de laan uit gestuurd worden als ze ook maar enigzins afwijken van de mechanische manier van werken. Echter, degenen die het dagelijkse werk doen voelen direct de subtiele maar niet triviale problemen die dat met zich meebrengt.

Kunstmatig werk

Stel dat de markt in de volgende versie tien producteigenschappen wil hebben die betrekking hebben op componenten A–T. Wat gaan de componentteams voor U–Z dan doen? Misschien aan zaken werken die minder waarde opleveren? Dat is tenminste wat ze goed kunnen. In het ergste geval wordt er, impliciet, kunstmatig werk gecreëerd zodat ze in ieder geval bezig zijn, ook al is er geen marktgedreven werk op dat moment.

De missie van een ‘resource manager‘ is om iedereen 100% bezig te hebben. Creatief zoeken ze naar werk, wat voor werk dan ook, om iedereen maar bezig te houden. De bonusstructuur laat ze direct in hun portemonnee voelen als dat niet lukt. Dus ze gaan er helemaal voor. Er is dus een extreme focus op locale optimalisatie zodat “iedereen zijn best doet”. Er worden waardeloze zaken gegenereerd—nutteloze code—die getest en in productie genomen én onderhouden moet worden. Welke effect heeft dat op het economisch rendement? Welk effect heeft dat op werkplezier? Welk effect heeft dat op productiviteit?

Dubbel werk dus meer ontwikkelaars

“Wij hebben drie XML-parsers, allemaal zelf ontwikkeld.” Goede code is vrij van duplicatie. Alles is er maar één keer. Redundantie in code is kostbaar en drukt het economisch rendement en vermindert je onderscheidend vermogen in de markt.

Met componentteams en overbezette specialisten zie je duplicatie van code en kansen voor hergebruik vaak niet. Het zit meerdere malen verstopt in diverse componenten. Er is niemand die het overzicht heeft omdat alle specialisten in hun eigen spelonk zitten te werken. Enkelvoudige specialisten leiden tot duplicatie van werk en code. De codebasis groeit groter en groter dan nodig waardoor de vraag naar de toch al schaarse specialisten toeneemt…

Explosief groeiend aantal ontwikkelaars

Werk op component A met hoge prioriteit moet sneller worden gerealiseerd. Snelle oplossing: werf meer ontwikkelaars en zet ze aan het werk op component A. Het team voor component C heeft een lagere prioriteit en blijft dus op dezelfde grootte. Hierdoor wordt component A groter en telt meer regels code. Op termijn wordt het aantal teams voor component A groter, waardoor een breed inzicht over alle componenten en code afneemt.

Voor de volgende versie van het product is het precies omgedraaid: team C heeft een hogere prioriteit en er worden mensen voor geworven. Natuurlijk kan je mensen uit team A overhevelen naar C en ze component C leren ontwikkelen, maar dan gebeurt zelden—het andere team heeft al werk omhanden en wil geen mensen kwijtraken. Bovendien leeft de angst dat er onvoldoende tijd is voor dat leren om ook maar enige zin te hebben. En het is natuurlijk verkwisting als je specialisten van A naar C omschoold. Tenslotte wordt het verplaatsen van mensen vanwege politiek en status tegengehouden—veel managers willen geen kleinere groep, een andere kracht voor locale optimalisatie.

Conway vat het goed samen:

De wet van Parkinson speelt een belangrijke rol… Zolang de prestige en macht van een manager gekoppeld zijn aan de grootte van zijn budget is hij gemotiveerd om zijn organisatie uit te breiden.

Dus als het team voor component A groeit, groeit ook het component zelf. Op een gegeven moment kan het component zich zelfs splitsen, en zo ook de teams. De beide teams specialiseren zich nog verder en zo groeien grote productorganisaties verder en verder.

Problemen met planning en coördinatie

scrum en andere agile methoden streven naar een geïntegreerd product aan het eind van elke iteratie die de toegevoegde waarde voor de klant demonstreert. zien is geloven. Voor de meest producteigenschappen betekent dit betrokkenheid van meerdere componentteams en compliceert daarmee de planning en coördinatie tussen de teams.

Stel dat het doel voor de volgende iteratie is om items 1, 2, 3 en 4 te realiseren. Item 1 vereist aanpassingen in component A en B. Item 2 in A, B, en C. Enzovoort. Er ontstaat een kluwen van onderlinge afhankelijkheden. Alle teams moeten voortdurende met elkaar afstemmen, synchroniseren en op elkaar wachten. Deze coördinatie gebeurt vaak door een aparte projectmanager. Zelfs als we die afhankelijkheden goed kunnen plooien veroorzaakt een vertraging in het ene team vaak een rimpeleffect door alle andere teams en over meerdere iteraties.

Vertraagde waarde

Waarde kan alleen geleverd worden als het werk van alle componenten geïntegreerd, getest en geaccepteerd is. Componententeam bevorderen een sequentiële levenscyclus. Met een sequentiële manier van werken hopen zich op allerlei plekken halffabrikaten op—werk in uitvoering dat een aantal iteraties blijft hangen voordat het geïntegreerd kan worden tot een waardevolle en verscheepbare producteigenschap en rendement kan genereren. Als die voorraden hebben bovendien een verloopdatum—‘tenminste houdbaar tot’—en verliezen dus voortdurend waarde. De potentiële waarde verdampt, verrot soms. Bovendien verbergen zich daar defecten, bevriezen investeringen, reduceren flexibiliteit en vertragen het leveren van waarde.

Dus, componentteams:

• werken vaak niet aan die zaken die het meeste waarde genereren;
• veroorzaken vertragingen die een negatief effect hebben op het systeem als geheel.

Meer erbarmelijk ontwerp en code

Misschien is de grootste ironie van componentteams wel het onjuiste geloof dat hun creatie resulteert in componenten van goed ontwerp en code. Het tegenovergesteld blijkt waar te zijn—de code van een enkelvoudig componentteam blijkt vaak nogal brak te zijn. “Misschien is de code wat rommelig, maar wij begrijpen het wel.” Wat gebeurt hier?

• Beperkte lering—Ontwikkelaars worden niet blootgesteld aan uitgestrekte hoeveelheden verschillende code. Dit beperkt hun lering van goed ontwerp.
• Vertrouwdheid broedt vertroebeling—Als je lang genoeg naar dezelfde 10.000 regels code kijkt, maand na maand, dan begint het vertrouwd en ‘helder’ te lijken. Je ziet niet langer hoe gecompliceerd het is en het maakt je ook niet zoveel meer uit. Dus ben je ook niet echt meer gemotiveerd om het grondig te verbeteren.
• Vertroebeling en zwaar gedupliceerde grote codebases verzekeren werk—Sommigen denken en doen inderdaad op deze wijze. Helemaal in groepen waarin lijnmanagement geen meesterprogrammeurs zijn, niet naar de code kijken en geen exellente herstructuring aanmoedigen.
• Geen druk van buiten om de code te verhelderen, herstructureren en te voorzien van vele unit tests—Aleen het team van vijf componentontwikkelaars werkt aan de code en zijn ermee bekend, niemand anders dus. Er is dus nul druk van buitenaf om de code voortdurend te herstructureren, koppelingen te verminderen en het te omgeven met grote hoeveelheden unit tests zodat het helder en robuust en testbaar is voor anderen die ermee moeten werken.

Het bestendigen van het geloof dat componentteams grootse code afleveren is een indicator van gebrek aan ga kijken gedrag door eerstelijnsmanagers. Als zij meesterontwikkelaars waren—Leanbeginsel: mijn manager kan mijn werk beter doen dan ik—en regelmatig breed en diep in de code duiken, dan zien ze meer, niet minder, frisse blikken maken de code beter.

Bronnen

• Scaling Lean and Agile Development, Craig Larman en Bas Vodde.
• The Fifth Discipline, Peter Senge

Platformgroepen en grootschalige componentgroepen

In grote productorganisaties bestaan vaak een of meer platformgroepen die zich ontfermen over de onderste lagen van het product—vet platform en zich alszodanig onderscheiden. Soms organiseren zij zich zelfs als aparte afdelingen. In een grote bank kan je bijvoorbeeld een afdeling ontdekken voor de gegevens- of persistentielaag. Ze zijn verantwoordelijk voor de onderste lagen van het besturingsysteem voor de bank. Bovenop het vet platform voor persistentie bouwt vervolgens de componentteams voor bedrijfs- en klantprocessen haar eigen, separate, abstractielaag.

Er is geen absolute voorwaarde dat er aparte platformgroepen moeten zijn. De ontwikkelinstrumenten en productieomgevingen zijn bijvoorbeeld hetzelfde voor alle lagen (hoe kun je anders integreren?). In principe kan een ontwikkelaar in een hogere laag ook code in lagere ‘platformlagen’ aanpassen. De grens is willekeurig.

De lange termijn visie voor organisationele verandering in de richting van personateams, grootscalige scrum en minder verkwisting door overdracht impliceren dat een kunstmatig geconstrueerde platformgroep kan opgaan in klantgerichte personateams die zich over alle code ontfermen. Dit is een meerjarige lerende reis.

De meeste nadelen van componentteams kunnen door personateams verzacht of weggenomen worden. personateams verenigen alle disciplines—analyse van eisen, interactieontwerp, planning, globaal ontwerp, programmering, systeem- en integratietesten in één gesmeed team. Van begin tot eind, van klant tot in de ‘bittenbak’.

Planning, coördinatie en de uitvoering van het werk worden uitermate vereenvoudigd, hetgeen leidt tot verkorte cycli. Het leren neemt toe en de organisatie kan zich volledig richten op die zaken die zoveel mogelijk waarde voor haar klanten hebben.

Omdat meerdere personateams vaak aan gedeelde componenten werken, soms zelfs op hetzelfde moment, is het essentieel dat de code schoon, helder en robuust is, constant geherstructureerd en geïntegreerd word, omgeven door een grondige testsuite—anders is het gewoon onmogelijk om ermee te werken.

personateams verschuiven de aandacht voor de uitdaging van coördinatie tussen de teams weg van vooraf vaststellen van eisen en ontwerp en projectmanagement tussen teams en naar coördinatie op het niveau van code. Coördineren op het niveau van code is relatief eenvoudig met de hedendaagse ‘agile’ en ‘open source’ praktijken en instrumenten zoals testgedreven ontwikkeling, voortdurende integratie en voortdurende inproductiename. Natuurlijk weten ontwikkelaars en managers die onbekend zijn met deze praktijken dit niet en blijven vasthouden aan alles vooraf bepalen en vastleggen als antwoord op de uitdaging van coördinatie.

Natuurlijk veroorzaakt de vershuiving naar personateams nieuwe uitdagingen en wensen, maar deze zijn makkelijk het hoofd te bieden en te vervullen met moderne middelen. minst gekwalificeerde bouwer gecombineerd met promiscue paring is zo'n praktijk.

Gemeenschappelijke verantwoordelijkheid voor ontwerp

{p|voortdurende integratie}} en voortdurende inproductiename impliceren het groeien van een systeem, in kleine stappen—elk verbetert het systeem een klein beetje. In aanvulling op het meermalen per dag voortdurend integreren van alle code op de stam en non-stop volledige geautomatiseerde duizenden fijnmazige tests wordt {p|voortdurende integratie}} met continu verbeterend ontwerp ondersteund door andere praktijken:

• Cultuur van evolutionair ontwerp—Zoals de wet van conway al aangeeft is de eerste ontwerpvisie zelden de beste. Bovendien verandert de software voortdurend. Daarom, beschouw ontwerp en architectuur als een levend ding dat oneindige incrementele verfijning nodig heeft en moedig deze cultuur aan. Een sequentiële levenscyclus met een enkele architectuur die vooraf bedacht wordt of met ontwerpfasen geeft het onjuiste bericht dat het ontwerp iets is wat we eenmalig definiëren en dan eenmalig bouwen.
• testgedreven ontwikkeling—Drijf de ontwikkeling van code door duizenden volledig geautomatiseerde microtesten en testen op hogere niveaus waarbij elke test een klein functioneel increment drijft. Dit leidt tot een testsuite met honderduizenden geautomatiseerde tests.
• voortdurende herstructuring—Een niet te missen stap. Voer een kleine herstructuring uit na elke microverandering van de broncode of test om de kwaliteit van het ontwerp, de code of de test te verbeteren (verwijder duplicatie, verhoog inkapseling, …). Herstructurering impliceert dat we de code altijd een beetje beter achterlaten dan we hem aantroffen. Merk op dat ontwerpkwaliteit codekwaliteit betekent. Er is geen echt ander ontwerp dan de broncode.

---