Agil kravhantering för att maximera verksamhetsnyttan
•Download as PPTX, PDF•
0 likes•874 views
Vill ni leverera produkter till rätt tid, kostnad och kvalitet – men lyckas inte riktigt? Har du också varit med i ett projekt där till synes ogrundade detaljkrav styr utvecklingen? Eller där kravanalysen är en bromskloss som levererar en oändlig lång och inaktuell lista på krav? Precis som mycket av utvecklingsarbetet idag sker agilt, bör även kravarbete ske agilt. Vi beskriver under seminariet de viktigaste agila principerna och hur dessa kan tillämpas både vid utvecklingen av produkter men också i den viktiga behovs- och verksamhetsanalysen som ligger till grund för utvecklingen. En presentation för dig som vill veta mer hur du kan jobba med krav som bidrar till affärsnyttan i din produkt/utveckling. Du jobbar kanske redan agilt med utveckling men skulle vilja integrera och effektivisera kravarbetet.
Recommended
Recommended
More Related Content
Similar to Agil kravhantering för att maximera verksamhetsnyttan
Similar to Agil kravhantering för att maximera verksamhetsnyttan (20)
More from ADDQ
Agil kravhantering för att maximera verksamhetsnyttan
- 2. Beställarna är otydliga och ändrar sig ofta Kraven är inte testbara Utvecklarna vill ha de riktiga kraven Kravinsamlingen ger oss en inaktuell mastodont-lista Produkten löste inte mitt behov
- 3. Agenda • Agila utgångspunkter • Agil kravutveckling i utvecklingsteamet • Agil kravutveckling i verksamhetsanalysen • Diskussioner
- 6. Good Enough ROI Mottagaren bedömer kvalitet Tid Good enough
- 8. Agil kravutveckling i utvecklingsteam Iterati on 1Itera tion 3 Initiala krav och arkitektur- utveckling Kravutveckling Iteration
- 9. Varifrån kommer kraven? Kan det agila arbetssättet fortplantas inom hela organisationen?
- 10. Begreppsmodell Behov Verksamhets- krav Systemkrav Mål IT-lösning Mäts med Tillgodoser Krävs för att uppnå Implementeras i Krävs för att uppnå
- 13. Diskussion I er organisation, hur är ert nuläge med agilt kravarbete och vilka utmaningar har ni?
- 14. I er organisation, vill ni göra något annorlunda efter detta seminarie? Hinder/möjligheter?
Editor's Notes
- EE Inledning Artighetsfras - Välkomna till vårt seminarie, kul att så många kom! Respektavsnitt - Hoppas ni alla fick en god smörgås och är laddade att lära er om vikten av kravarbete!
- IS Intresseväckare Känner ni igen dessa frustrerade citat om krav? Vi pratar förbi varandra, vi pratar om varandra istället för med varandra Vi gör vårt bästa men lyckas inte Syftet med krav är att ta fram rätt lösning för behovet och det är det vi ska prata om idag Och vi ska prata hur vi gör detta agilt – dvs lättrörligt, smidigt, flexibelt för maximal affärsnytta
- IS Agenda Idag skall vi prata kort om agil kravhantering för maximera verksamhetsnyttan. Simon kommer att prata om agila utgångspunkter och hur krav kommer in i utvecklingsteamen. Jag tänkte prata om hur dessa utgångspunkter kan fortplantas inom hela organisationen och prata med samma språk. På slutet tänkte vi ha en diskussioner runt detta med fokus på era arbetsplatser
- IS Måldefiniering – Målet är att ni ska kunna leverera produkter till rätt tid, kostnad, kvalitet. * fått inspiration till hur ni kan tillämpa agila utgångspunkter för kravarbetet *i diskussionerna fått konkreta tips/råd på hur ni ska göra själva Egen presentation IS SR Jag heter Ingela Strandh och min kollega heter Simon Riddertorp och vi jobbar som kravanalytiker på ADDQ. Vi har bägge mycket lång erfarenhet av kravarbete inom flera olika branscher och både vid utveckling och upphandling av system.
- Egen presentation IS SR Jag heter Ingela Strandh och min kollega heter Simon Riddertorp och vi jobbar som kravanalytiker på ADDQ. Vi har bägge mycket lång erfarenhet av kravarbete inom flera olika branscher och både vid utveckling och upphandling av system.
- Grafen visar ROI, tid och värdekurva. Värdekurvan har en maxpunkt pga avtagande marginalnytta vid ökad resursinsats. Till vänster om maxpunkten kan vi öka värdet men till höger om maxpunkten producerar vi bara waste. Vi ser även att vi inte kommer nå 100% värde utan kanske bara 80%. Slutligen att vi når good enough ganska tidigt. Good Enough är situationsbundet. Om du inte vet vad mottagaren behöver så kan du inte skapa ngt som är good enough. Utan kommer säkert motiveras till överarbete och producera waste. Vem har inte pärmar som ingen läser? Du måste försäkra dig om att veta vad mottageren behöver genom bra kommunikation och samarbete med intressenterna. Du kanske anser att Good enough inte är tillräckligt bra. Tvärtom det är bästa möjliga per definition vi kan inte få det bättre pga avtagande marginalnytta. Ligger vi till vänster om den streckade linjen kan vi öka värdet men till höger producerar vi waste. Jag håller med om att kurvan är lite naiv den går stadigt uppåt till max, jag antar att allt vi gör ger värde, men bara om vi gör rätt saker. Mer realistiskt är att den pendlar upp och ner på vägen. Vi missar oftast maxpunkten och producerar lite waste pga svårt att styra detta. Good Enough innebär inte låg kvalitet. Du kanske tror det? Saken är att det är tillräcklig för sitt syfte. Men det är ingen ursäkt för ett dåligt jobb eftersom kvalitet bedöms av mottagaren inte producenten av kravet. Om din intressent behöver ett perfekt detaljerat krav så är det ditt jobb att utveckla det och det är då GE först då . GE ändras över tid. Kravet kan åka i båda riktningarna både upp och ner längs kurvan Om det åker neråt och inte är GE så ska du fråga dig om det behöver uppdateras. Om kravet är mer än GE ska det uppdateras då? Ja om det har en negativ påverkan på något annat område. Dra ett exempel med diagrammet. Ska jag uppdatera??,Agila kravutvecklare updaterar bara om det annars gör ont och bilden är inte så dålig att detgör ont!
- Bilden visar ROI och tid I den plottas en agil och en traditionell värdekurva. Vi ser att Agil ger mer värde tidigare, båda kan ge lika mycket värde om de körs hela vägen. Agil kan avslutas tidigare. Agil hanterar risk tidigare. Vad handlar JIT om jo att göra saker vid rätt tidpunkt. Krav kan utvecklas tidig sent eller JIT. Tidig kravspecificering leder till waste utan good enough tank. Sent kravarbete leder till missade levaranser och sämre kvalitet Så när specificeras kraven? Jo i rätt tid! JIT. Vad kan vi då göra, några best practice: Kravarbetet synkar och matchar mottagarens behov, fråga mottagaren när behöver hon kravet? Det räcker med en mycket mindre insats än man tror i början Kodutveckling påbörjas innan samtliga krav är utvecklade Kravutvecklingen sker kontinuerligt Hur göra? Estimering och planeringsbehov möts genom att initialt identifiera verksamhetskraven. Minimera waste genom att kravutveckla enbart de systemdelar som faktiskt kommer att byggas. I traditionell kravutveckling utvecklas systemdelar som faktiskt inte används ca 70% enligt exempelvis Standish report. Krav ställer intelligentare frågor om kravutveckling sker senare pga ökad domänkunskap. Intressenter ger bättre svar pga ökad systemkunskap pga de har fått kontinuerlig feedback gärna som product demos.
- Iteration 0, bootstrap: -Identifiera Behov, Mål och Verksamhetskrav -Skapa krav todo-lista -Identifera arkitekturell vision -Utvecklingsbara krav för iteration 1, skall vara estimerbara och testbara. I varje iteration: -Utvecklingsbara krav för iteration n+1 -Krav sessioner: stand-up design sessions customer Q&A sessions -TDD -Granskning (valfritt) -Kraven utvecklas kontinuerligt över hela livsyckeln -Kraven utvecklas endast när det krävs för planering eller utveckling -Kraven görs god enough och JIT
- IS Vet att detta är två olika frågor men så fort jag börjar prata om krav, verksamhetsanalys etc så är det många som automatiskt tänker – ånej, nu blir det en jättekoloss, inte alls agilt etc. så därför tänkte jag adressera bägge sakerna samtidigt. Svaret är ja, det går att tillämpa på alla delar av en organisation, inte bara för systemutveckling Ursprungligen kom dessa principer kommer från bilindustrin, Toyota. Jag var med och införde Lean på hela AstraZenecas forskning det är experimentell och lagstyrd verksamhet – långt från bilar eller system! Lean på labbet, i ledningsgruppen, bland administratörerna. Men för att kunna vara agil måste man komma överens om spelregler/vilka spelarna är
- IS Red ut begreppen! Den kan tyckas självklart men små nyanser/förutfattade meningar gör att vi pratar förbi varandra, inte med varandra. Så att alla vi har gemensam bild av begreppen tänkte jag gå igenom de snabbt En organisation har BEHOV – antingen problem eller möjligheter. Ex möjlighet att expandera på en marknad eller problem med minskade antal kunder. Då sätter man MÅL för att uppnå dessa behov - 10 nya länder i Asien under 2017 eller 20% ökning av antal kunder på 5 år. Dessa mål är mätbara, och refererar till ett nuläge som ska bli ett börläge. Vilka egenskaper eller förmågor krävs för att uppnå dessa mål. Dessa är verksamhetskrav. Verksamhetskrav är precis som alla krav kompletta, tydliga och beskriver VAD som krävs helt enkelt. Det är viktigt att inte tänka lösning, utan endast behov och mål. Ett sätt är att fråga varför, varför, varför och sedan varför igen? Ett sätt att möta verksamhetskrav är att utveckla/förändra ett system. Dessa är systemkrav. Dessa kan mera specifikt prata om befintliga system och sätta kraven i dessa sammanhang. ex. en enkel handläggning i system x får högst ta 5 klick och 5 minuter. System x behöver en ny arbetsflödes-funktionalitet för regelbundna ärendetyper. Genom att koppla alla verksamhetskrav till mål så blir kraven också ”automatiskt”– specifika (detaljerade), mätbara, överenskomna, realistiska och tidsatta. Vet man målet, kan man beskriva kraven på ett kvantiferbart sätt. Och genom att koppla till verksamhetens mål fokuserar man aktiviteterna på just det som ger värde för verksamheten.
- IS Ett lagspel – hela organisationen! Alla behövs, kan inte sakna någon del Det gäller att komma ihåg grunden – var är min del i gemensamma värdekedjan, hur tillför jag GE-arbete enligt mottagaren och JIT för mottagaren? Alla vet sin del av helheten - passa JIT vid bra läge- Även tåfjuttar räknas som mål (GE) Jmf med er org Coachen kan inte påverka så mycket spelet på planen utan ge vägledning innan men det är spelarna som spelar matchen, spelarna som vinner matchen genom sitt samspel
- IS Dessa är spelarna, alla kan passa vem som helst. Men saknas någon blir det ett haltande lag! Allt hänger ihop, och påverkar varandra om och om igen. Samma värdekedja Prata med varandra – vad (GE) behöver du som mottagare veta, när (JIT) behöver du veta det? Det går att vara GE och JIT i alla steg och man MÅSTE koppla ihop systemutvecklingen med ursprungsbehovet – annars utvecklar man inte rätt produkt! Det var vår intro, våra idéer. Men funkar det i praktiken?
- SR Det verkar klokt och enkelt, men hur ska vi göra? Har någon lyckats med delar av detta? Nu ska vi diskutera, 2 och 2. Passa på att dela med er av era praktiska råd och erfarenheter till varandra enligt principer ju mer du ger desto mer du får.
- SR Från era bikupor och vår presentation, kommer ni på något ni vill lyfta? Behöver ni hjälp med specifika frågor?
- IS Summering Begrepp att komma överens om BEHOV, MÅL, VERKSAMHETSKRAV, SYSTEMKRAV. Alla behövs och allt hänger ihop i hela organisationen och allt går att jobba med GE och JIT Målbekräftelse Målet är att ni ska kunna leverera produkter till rätt tid, kostnad, kvalitet (maximera verksamhetsnytta). *fått inspiration till hur ni kan tillämpa agila utgångspunkter för kravarbetet *i diskussionerna fått konkreta tips/råd på hur ni ska göra själva
- IS Och vi vinner matchen!