Den Parallelle facon i software

Software arkitektur handler om facon og form hørte jeg den anden dag. Hvor er faconen så henne – ja den ligger i de abstrakte base klasser. Og hvad kan man så bruge det til? – jo det er fra arkitekturen at projektplanen fremtræder. Det er her mellem streger og kasser at de parallelle spor findes. Det er her man får overblik over hvad der kan udvikles parallelt og hvor der er afhængigheder som udgør de kritiske stier som skal betrædes for at få det til at lykkedes.
Rækkefølgen hvor i hvordan software skrives er derfor ikke ligegyldig, det gælder om at starte det rigtige sted for at opnå parallelitet i projekt planen og dermed udnytte de hænder man har til rådighed bedst muligt. Svarende ligger i arkitekturen fordi vores traditionelle lagdelte arkitektur har afhængigheder. Enhver form for relation mellem software, hvad enten det er en webservice, et c modul, en java klasse giver en afhængighed. Så kommer spørgsmålet når man så tager sit første sprint, hvad skal vi lave? Det ved product owneren. Han har en plan med sprintet. Og vi tager den plan, laver vores backlog, bryder ned til tasks – men hvad skete der med paralleliteten?. Kan vores product owner gennemskue arkitekturen og se at her er et godt sted at starte fordi det betyder at vi om en eller to uger kan rampe up og starte en masse i parallel og give projektet fart. Næppe. Jeg har aldrig set en product owner der kunne. Kunden i den anden ende kan slet ikke. Og er sikkert også ligeglad, kunden forventer at vi gør hvad vi kan for at levere hans produkt så hurtigt så muligt. Derfor sander scrum til. Det er simpelthen langsommere at lave software på den måde, fordi vi ikke tager højde for at noget kan udvikles parallelt.