Titeln är en parafras på den preussiske strategen och generalen Carl von Clausewitz, som sade att "ingen plan överlever den första kontakten med fienden". Han införde även begreppet "krigets friktion". Detta, menade han, är alla de till synes små och triviala saker och händelser som till slut ändrar förutsättningarna i grunden och gör att den ursprungliga planen efter ett tag inte har någon koppling till den verkliga situationen. Den som vinner är därmed inte den som gör den bästa planen, utan den som bäst kan anpassa sig till rådande förhållanden.
Även om mjukvaruutveckling inte är ett krig (vilket vi ska vara tacksamma för) så finns det likheter. I båda aktiviteterna kommer oförutsedda svårigheter att få konsekvenser som vi inte kan förutse. Likaså kommer i båda fallen förutsättningarna (resurser mm) att ändras innan målet är nått. Så att kunna anpassa sig efter rådande förutsättningar är A & O. Det är just därför jag tror på den agila metodikens överlägsenhet över traditionella plandrivna projekt. De senare bygger på att man har en detaljerad plan, och vet man inget annat så förutsätter man att den gäller. Problemet är att ofta kan planen utan uppföljning hamna så långt från verkligheten att det inte går att orientera sig med den längre.
Samma tankesätt verkar gälla för design och implementation. Vad är det som gör det möjligt för kunden att köra sitt system och generera vinst med det? Körbar, vältestad kod.
Vad är det som gör det möjligt för oss utvecklare att låta kundens system ändra sina egenskaper efter ändrade krav eller ändrade förutsättningar, må det vara före eller efter driftsättning?
Välstrukturerad, väldesignad kod.
Vi kan ändra hur mycket som helst i våra designmodeller, systemets beteende kommer inte att ändras för det. Det är i koden vi måste ändra för att generera ett mervärde för systemägaren. Om du inte håller med om att koden är värdefullare än dokumentationen eller modellerna, gör följande tankeexperiment:
Du har två servrar, en med all kod, en med all dokumentation och alla modeller, inga backuper. Det brinner och du kan bara bära ut en server. Vilken väljer du?
För att föregå alla som tror att Agile innebär att man vare sig dokumenterar eller modellerar, så ska man naturligtvis dokumentera sitt system så att andra lättare kan underhålla systemet i framtiden. Bra dokumentation pekar ut för mig vilka ingångar som finns till koden, tex vilka klasser som kan vara lämpliga att börja titta på för att förändra ett visst flöde. När jag väl hittat det ska koden tala för sig själv, annars har man missat något i designen.
Dokumentationen skriver man sedan efter att koden är testad och implementerad, eftersom det då blir så mycket mindre underhållsarbete med den.
Att skapa modeller på en högre nivå än koden för att kunna resonera med andra är naturligtvis också bra, det kan ju bli lite jobbigt att trängas fem personer vid en skärm för att titta på kod. Men man måste hela tiden komma ihåg att man gör det i syfte att få fram körbar, väldesignad kod. Resten är biprodukter, och ju mindre modellering vi kan klara oss med, desto bättre.
Prenumerera på:
Kommentarer till inlägget (Atom)

Inga kommentarer:
Skicka en kommentar