Posts Tagged ‘user_story’

h1

Lägg krut på rätt ställe med ”Focus Scales”

måndag, 22 mars, 2010

Hur vet man att man lägger krutet på rätt saker? Hur kan man förenkla utmaningen med att kommunicera kundens vision in i Scrum-teamet? Räcker Produktbackloggens prioritering för att nå maximal verksamhetsnytta? ”Focus Scales” kan vara ett kraftfullt verktyg för att fylla gapet mellan kundens behov och teamets ansträngningar.

.

Agiles projektledningstriangel

Scrums verktyg för att ena kunden och Scrum-teamen under samma ledstjärna är ett Vision Statement. Denna beskriver visionen för IT-lösningen, dvs. vad dess syfte är, mål och önskat resultat. Agiles projektledningstriangel säger vidare att vi aldrig får kompromissar med kvaliteten utan att vi anpassar scoopet för att nå tid och budget.

Även fast vi aldrig tummar på kvalitét gör vi fortfarande kontinuerligt andra typer av val; dels avgör vi löpande i vilken ordning vi utvecklar funktionerna (dvs. vad som ska levereras efter nästa sprint). Men vi avgör också löpande hur mycket krut vi ska lägga ner på varje funktion, dvs. hur avancerad eller minimalistisk implementering av varje User Story ska göras.

.

Focus Scales

Själva prioriteringen av Produktbackloggen gör Produktägaren givetvis löpande i dialog med kunden. Det är dock en mycket god idé att samtidigt som man tar fram ”Vision Statement” även målar upp några enkla tumregler för vad man ska lägga extra tid och energi på och vad man ska hålla enkelt.

Som ett diskussionsunderlag för Produktägaren (och teamet) i sin dialog med kunden kan man använda sig av något jag kallar Fokus Scales. Dessa kan även teamet använda internt när de designar funktionerna och funderar över hur pass avancerad eller enkel lösning de ska sikta på.

Att dessutom ta fram dessa vågskålar under en workshop där både kund och teamet är med (eller åtminstone representanter för teamet) öppnar upp för en fantastisk möjlighet att diskutera idéer, koncept och nå konsensus över vad man vill åstadkomma och vad som är viktigt.

Ett exempel på ett projekts fokus vågskålar…


Varje vågskål beskriver hur balansen ska läggas när man väljer mellan två olika kriterier. Observera att kriterierna absolut inte behöver vara motsatser eller utesluta varandra, de ska endast vara vägledande och fungera som diskussionsunderlag. Kriterier som är vettiga i ett projekt kanske helt saknar relevans och betydelse i ett annat. Det är en god idé att begränsa antalet vågskålar till ett fåtal (kanske 3-5 stycken). Med för många vågskålar riskerar summan av dem bli svårbegripliga och motsägelsefulla.

.

Tydligare ledstjärna!

Genom att börja med att ta fram Vision Statement och Focus Scales etableras och kommuniceras en tydlig målsättning och gemensam ledstjärna för både kund och team från början. En framgångsfaktor för alla agila projekt.

(Ursprungligen publicerad på sogeti.blogg.se)

Annonser
h1

Bygg inga pussel. Utveckla vertikalt!

tisdag, 9 mars, 2010

Vad innebär det att jobba inkrementellt? Hur levererar man en komplex lösning med en komplex arkitektur i små steg enligt en iterativ process såsom Scrum?

Iterativt = Upprepbar, lärande process. Små steg. Förvänta dig inte att få det rätt första gången. (Sprint = Iteration)

Inkrementellt = Bygg i vertikala tårtbitar (Stories) hellre än i lager, dvs. bygg inte en modul i taget för att i slutskedet försöka foga ihop dem. Bygg och leverera en liten del av helheten i varje iteration.

Så, vad är det man ska undvika?

  • Dela inte upp team efter applikationens lager.
  • Bygg inte en komponent i taget bara för att i projektets slutskede (under exempelvis integrationstestningen, eller än värre – efter leverans) upptäcka att bitarna inte passar ihop och måste skrivas om.
  • Bygg inte något under sprinten som inte resulterar i någonting som inte är av värde för slutanvändaren och som inte kan demonstreras på Sprint Demo.
  • Brodera inte ut komponenter med extra funktioner som kan ”vara bra att ha” eller som inte är nödvändiga just nu för den Story som ska levereras. (Med största sannolikhet är det antagligen ogjort jobb. ”Bra att ha”-funktioner visar sig ofta överflödig eller nödvändiga att skriva om när de väl ska anropas/användas.)

Hur ska vi göra istället?

  • Gruppera Stories i områden och bygg tvärfunktionella team runt varje område (som har kunskap som krävs för att utveckla och testa alla lager, exempelvis UI, server och databas).
  • Bygg en Story i taget och bygg alla funktioner som behövs (dvs. bygg det som behövs i UI, det som behövs på servern och det som behövs i databasen), och inget annat än det som behövs för Storyn.
  • Se till att Storyn som utvecklas under Sprint är tillräckligt avgränsad för att bli KLAR (dvs. kodad, testad, integrationstestad, dokumenterad, levererbar och installerbar)

Meh!?

…kanske någon tänker, ”Är det inte svårt att bygga något varje sprint som slutanvändaren kan använda och som har faktiskt värde för verksamheten?”

Svar ja.

De första Sprintarna kommer mycket energi och tid gå till att bygga skelettet och ramverket i arkitekturen. Och det måste det få göra annars riskerar man att få en slarvig struktur som inte går att bygga vidare från. Men ledordet även här måste vara – ”Bygg enbart och endast det du behöver, men gör det bra”. Försök inte förutse framtida behov utan bygg en arkitektur som är tillräckligt flexibel och stabil för att kunna anpassas, byggas ut och justeras i framtiden.

Balansgången är svår men däri ligger också nyckeln till förmågan att kunna leverera värdefull mjukvara efter varje Sprint och en av hemligheterna till hur man uppnår snabbhet och flexibilitet.

(Ursprungligen publicerad på blogg.sogeti.se)