En enkel övning

Den här övningen går ut på att implementera kraven i den ordning som de anges, utan att ta hänsyn till de krav som kommer senare. Du ska alltså inte implementera som om kände till samtliga krav från början utan bara ett krav i taget och sedan anpassa lösningen för varje nytt krav.

Du kan naturligtvis innan du börjar, sätta ramar för hur du implementerar, tex om ditt data ska vara på normalform eller någon form av blobbar. Övningen görs med fördel flera gånger, där du kan ställa upp olika ramar för den implementation du tänker göra för att sedan jämföra resultaten.

Du kan välja vilket gränssnitt du vill mot dessa krav, men tipset är att lägga minimalt med tid på gränssnittet och i fokusera på kraven i första hand. Unittester räcker väldigt långt.

Krav 1:
Implementera en enkel shoppingkorg. Du ska kunna lägga till en vara, ta bort en vara och lista varorna i korgen.

Krav 2:
Du ska kunna summera priserna på varorna i korgen. Du ska också kunna markera korgen som "klar", alltså markera att korgen har avslutats och inte längre kommer att uppdateras.

Krav 3:
För en given tidsrymd, beräkna den den mest sålda varan, både till antal och pris.

Krav 4:
En kundkorg anses vara övergiven om den inte har uppdaterats på två timmar. För en given tidsrymd, beräkna totalt värde på de övergivna kundkorgarna.

Krav 5:
Beräkna värdet på den vara som till antalet plockats in i varukorgen och sedan tagits bort ur varukorgen, alltså produkter som kunden visat intresse av men sedan aktivt valt bort (som extra krav skilj på avslutade och övergivna korgar)

Krav 6:
Om en kund har lagt 3 stycken av en vara i kundkorgen, ta bara betalt för två i prisberäkningen.

Krav 7:
Ge 50% på den billigaste varan om värdet på korgen överstiger 1000 kr.

Krav 8:
Ge 10% rabatt på dagens mest sålda vara om den sålts för mer än 1000 kr (när varan läggs i korgen).

Krav 9:
Ge 10% rabatt om det totala försäljningsvärdet före rabatter under innevarande timme överstiger 10000. Rabatten skall upphöra om ny timme påbörjats.

Som variant och överkurs kan du för varje krav skapa upp någon/några miljoner med varukorgar och sedan kräva att varje operation ska vara snabbare än 10 ms.

Man kan också göra övningen så att man tar höjd för alla kraven men stannar efter att man gjort några stycken. Är designen onödigt komplicerad och har du blivit sinkad jämför med den lösning de skulle ha gjort för en mindre uppsättning av krav? Kan du göra lösningen bra utifrån färre krav utan att det blir jobbigt sen?

Öva agila lösningmönster

När man får ett krav kan man implementera det eller så spenderar man en stund med att fantisera om vad som kan bli framtid krav. Ta tex en enkel shoppingkorg på en ehandelssida byggd på två tabeller, korg och varor där korgen innehåller information om vem som "äger" korgen. Korgen innehåller varor. Men när säljavdelningen kommer och säger att de vill veta vilka varor som kunden lagt i korgen men tagit bort innan köp kommer valet att implementera varukorgen med två tabeller kanske framstå som naivt och kortsiktigt.

Nu kan man förstås inte frångå kraven som ställts utifrån att man har en livlig fantasi där man kan föreställa sig ett antal framtida krav. Men det kan man göra är att känna till ett antal lösningsmönster och vilka vinster och förluster man gör med respektive lösning. Om man övat på dessa mönster kanske man ibland kan använda de lösningar som ger bäst möjligheter att hantera framtiden, vad den den nu kan tänkas ge oss.

I skrivande stund har jag två axlar som man kan variera sina övningar runt. Strukturerad/flexibel och stömmande/snapshot. Strukturerad/flexibel är mest utforskad inom programmeringsspråken där diskussionerna om dynamiska och statiska språk pågått länge. Diskussionen finns även i databasvärlden, då främst i konflikten mellan Nosql och relationsdatabaser.

Strömmande lösningar, tex genom eventsourcing syftar till att följa en ström av händelser och sedan agera på dessa, beroende på hur man väljer att bygga kan man återspela händelserna och agera på ett annat sätt då eller så är händelserna flyktiga. En snapshot-lösning håller ett tillstånd i systemet och uppdaterar detta tillstånd.

Ett mer traditionellt system lutar ganska tungt åt att vara strukturerat och av snapshot-karaktär. Man definierar typer och lagrar i tabeller i relationsdatabaser. I alla fall för mig är det mönstret jag kan och där jag känner till vägarna runt många många problem numera. Men som vi känner till finns det ibland godis i dynamiskta och strömmande lösningar men för att kunna komma åt det goda måste man öva, precis som vi gjort i många år med den traditionella lösningen.