Agile en Architectuur

Na het lezen van Erik's artikel over 'Architectural Spikes' (http://www.agile-architecting.com/articles.html) kan ik het niet laten om mijn ideeen over Architectuur te delen.

Erik's artikel adresseert een goed punt, ik zie vaak een soort verschraling ontstaan in Agile projecten, waarin sprint voor sprint wordt voortgesneld. En wat meer architectuur en focus op lange termijn kan zeker geen kwaad.

Het bezwaar dat ik heb tegen Erik's opening alinea, is dat dit een defect zou zijn van Scrum.

Het doel van Scrum is niet om zo snel mogelijk features te releasen. Het doel is namelijk om dit te kunnen blijven volhouden met een zo hoog mogelijke velocity.

En wat is dan architectuur? Een fundering? Als in een gebouw? Die metafoor gaat (en ging) nooit op voor Software. En zelfs niet voor gebouwen.

Ik hou wel van Grady Booch definitie: "Architectuur is de verzameling ontwerp beslissingen die de kosten van het gebruik, de ontwikkeling en beheer van een systeem minimaliseren" (Zijn originele blog is verplaatst en niet makkelijk te vinden, zie anders http://www.itarchitect.co.uk/articles/display.asp?id=358). Grady noemt met name change, de interpretatie boven is van mij.

En dat is wat ik denk dat architectuur is: beslissingen. En dat is wat een goed Scrum team doet, beslissingen maken en de regelmatig stilstaan bij consequenties ervan. Daarom kan een architectuur ontstaan (emerging, remember?) en zijn retrospectives belangrijk.

Architectuur is daarom niet veel anders dan een Plan. Het plan is niet belangrijk in Agile, planning daarentegen zeer. Hetzelfde geldt voor Architectuur: niet belangrijk, architecturing (tm) wel degelijk.

En de architectuur zal dus ook anders ontstaan bij verschillende teams. Ervaren teams in een bekend domein zullen meer van hun architectuur al snel bepalen. Minder ervaren teams in een onbekend domein zullen meer architectureren (tm). En in hun retrospectives kijken naar de velocity.

Neemt dus niet weg dat Erik een heel goed punt heeft. Namelijk dat de meeste kosten na de release van een systeem worden gemaakt, en dat het dan te laat is. Kwaliteit (non-functional requirements) moet dus ook niet laag op de product backlog staan.

Allereerst moet kwaliteit ingebakken worden in de 'Definition of Done', dat garandeert een goede engineering basis. Geen discussies over cyclische dependencies, tight coupling en andere vormen van technical waste!

Verder dienen de stakeholders die verantwoordelijk zijn voor het beheer van het systeem vertegenwoordigd te zijn in het project, zodat hun (ISO9126) zaken worden behartigd, soms ten koste van features, ja.

Het is voor een Agile team dan ook erg belangrijk om kennis te nemen van de kosten van een systeem in gebruik. Vroeg releasen kan daar erg bij helpen.