Blixttal Agila Sverige 2012 - Krav är bara en flyktig version av målet (Jimmy Janlén, Crisp)
•Descargar como PPTX, PDF•
1 recomendación•622 vistas
Jimmy Janléns blixttal till Agila Sverige 2012 - Krav är bara en flyktg version av målet. Krav ska betraktas som en ögonblicksbild av vad man tror man vill ha. Inget annat. Så snart kravet har påbörjat sin förvandling till fungerande värdefull mjukvara och kunskap (såsom användarmanual, teknisk systembeskrivning, testfall, osv) börjar det förlora sin relevans. Av nostalgiska skäl kanske man väljer att spara kravet till eftervärlden, men egentligen har det efteråt spelat ut sin roll. (Kommentar: Detta är blixttalsförslag 4 av 4. Om så önskas jag kan jag hinna förbereda och hålla max två av dem. Förutsatt att något av dem blir accepterade såklart.)
Recomendados
Recomendados
Más contenido relacionado
Destacado
Destacado (20)
Blixttal Agila Sverige 2012 - Krav är bara en flyktig version av målet (Jimmy Janlén, Crisp)
- 2. Jimmy Janlen
- 3. Jimmy Janlen
- 4. Jimmy Janlen
- 5. Jimmy Janlen
- 6. Jimmy Janlen
- 7. Jimmy Janlen
- 8. Jimmy Janlen
- 9. Jimmy Janlen
- 10. Jimmy Janlen
- 11. Jimmy Janlen
- 12. Jimmy Janlen
- 13. Jimmy Janlen
- 14. Jimmy Janlen
- 15. Jimmy Janlen
- 16. Jimmy Janlen
- 17. Jimmy Janlen
- 18. Jimmy Janlen
- 19. Jimmy Janlen
- 20. Jimmy Janlen
- 21. Jimmy Janlen
- 22. Jimmy Janlen
- 23. Jimmy Janlen
Notas del editor
- Hej! Jag heter Jimmy Janlén och jobbar som konsult och teamchef på Sogeti. De senaste fyra-fem åren har jag uteslutande haft uppdrag som Scrum Master, Agil projektledare och Scrum Coach.Jag tänkte ägna de följande tio minuterna till att diskutera hur jag tycker man bör förhålla sig till krav när man jobbar agilt. Utmaningarna och konflikterna kring just krav har gäckat mig i vågor. Stundtals har frustrationerna varit större, ibland smärre.Synsättet och attityden kring krav har jag många gånger upplevt vara en bromskloss mot högre agilitet. Krav ska bara betraktas som en flyktig version av målet. Inget annat.
- Ibland försöker jag förklara för vänner, familj och chef vad jag jobbar med. Har inte rönt några större framgångar där.Hur som helst…De senaste fyra-fem åren har jag uteslutande haft uppdrag som Scrum Master, Agil projektledare och Scrum Coach. Jag har hållit oräkneliga seminarier och en stor drös kurser.Jag har haft förmånen att jobba i många olika projekt hos många olika kunder. Jag har fått uppleva många olika kulturer.Detta hoppas jag få fortsätta med länge till.
- Så krav…Hur kommer det sig att vi historiskt ägnat mycket tid och energi åt att skriva detaljerade kravspecifikationer?För det första: Avstånd mellan beställare och leverantör. Ibland kan vi till och med mäta avstånden i mil.För det andra: Avstånd i tiden. Ibland kan det gå månader innan beställningen kan förvandlas till en fungerande produkt eller ett installerbart system. Under dessa omständigheter behöver kunskapen om vad beställaren behöver och önskar sparas på något sätt.För det tredje: För att leverantören (eller IT-avdelningen) ska kunna göra ”träffsäkra” beräkningar av tidsåtgång och kostnader inför avtals- och kontraktsförhandlingar behövs tydliga och ”kompletta” krav.
- Vissa av er här inne kanske har nått väldigt långt i ert agila arbete, och så långt att ni rider på en våg av continuousdeployment.Ideér fångas upp i farten.Teamet jobbar intensivt tillsammans och balanserar på en surfingbräda av samarbete, tillit, mod och hög technicalexcellence och minimal waste.Har man väl kommit upp på planing går det undan.Grattis!
- Många har dock precis påbörjat resan eller befinner sig tidigt i förvandlingsprocessen, eller har kanske fastnat någonstans på vägen.Man har tagit flera viktiga steg men har fortfarande kvar ett arv av gamla rutiner, gamla attityder och gamla revir som inte riktigt går ihop med en agil kultur.Exempelvis: milstolpar, funktionell organisation, fokus på timmar framför resultat, morötter och milstolpar. Och krav. Idag tänker jag zooma in på de detaljerade kravspecifikationerna vilka jag hävdar är en förlegad artefakt som inte är kompatibel med agile. Övriga exempel är precis lika viktiga men dessa lämnar jag därhän just nu.
- Om vi har påbörjat vår agila resa och försöker höja produktivitet, effektivitet och kvalitet genom att jobba Scrum eller Kanban och samtidigt fortsätter lägga stort värde i kraven - som om ett krav är värdefullt i sig - ställer vi till det för oss.Varför påstår jag det?(cont)
- (cont)Jo, jobbar vi agilt betyder det att vi fokuserar på vår förmåga att leverera värdefull testad mjukvara, få feedback på det vi gör - samt att bygga på vår kunskap.Hur många checkboxar vi bockat av i kravspecen säger inget om vilket värde vi levererat.Om målet är att få bocka av 100% av checkboxarna, som om kravspecen vore facit, kommer vi undvika att ifrågasätta konstigheter eller ifrågasätta nyttan i varje enskild checkbox. I värsta fall finns det dessutom ekonomiska incitament för att träffa just 100%.
- Vidare, det är lätt att glömma bort att en detaljerad, utbroderad, vackert designad kravspecfaktist är författad av en person. En människa som du och jag. Med mänskliga brister och svagheter. Ett tjusigt detaljerat krav ger illusionen att någon annan tänkt till ordentligt. Någon som förstår helheten bättre än ”vi på IT”. Ibland är det såklart så. Och ibland inte.Men om vi inte varit delaktiga i framtagandet av kravet, hur ska vi kunna veta?
- (cont)Jag menar, vad går snabbast och vad skulle ge bäst resultat? Att du skriver en detaljerad instruktion i hur jag viker ett plan, vilken du sedan lämnar över till mig, eller…att du och jag sitter tillsammans så att jag kan se hur du gör och du kan förklara vad jag gör för felvikningar? Ju mer detaljerad instruktion du skrev, desto svårare skulle jag antagligen ha att följa den.
- När man jobbar agilt betyder det att systemet gradvis växer fram, justeras och byggs på. Betraktar vi kravet som något beständigt och värdefull kommer vi konstant behöva uppdatera dessa och hålla koll på versionshantering, spårbarhet och kravets status.Är det ett nytt krav, är det redo för review, är det testat, är det gammalt och inaktuellt? Osv.Ganska snabbt blir det till och med svårt att svara på frågan – ”Vad utgör just-nu versionen, den som ligger i produktion?”Kan vi lita på att kraven stämmer med verkligheten? Är de uppdaterade?
- Överlämning av kravspecar möjliggör också distansiering.Ibland kanske man till och med kommer undan med attityden – jag har gjort mitt nu, kravet är skrivet. Din tur!
- Och som alltid när man försöker överlämna kunskap via skriftlig text – vi öppnar upp möjligheten för missförstånd och tolkningar.Detta är det i princip omöjligt att skydda sig helt ifrån.
- Detaljerade krav bjuder också till att de används i ett blamegame när kunden inte är nöjd med resultatet.Felet kanske inte ligger i författaren av kraven, eller hos personen som tolkade det. Problemet är just att vi kommunicerar genom krav.
- Krav kan också i efterhand användas som en ursäkt av leverantören för att man inte gjort ett bättre jobb.Som sagt, om målet är att uppfylla 100% av kraven finns det ju direkt ingen morot att ifrågasätta kraven och designen som sådan.
- Så, hur förhindrar vi problem och situationer som dessa? Som kund kanske man nu drar slutsatsen att man i fortsättningen, nästa gång, måste jag skriva ÄNNU detaljrikare kravspecar - så att det blir rätt.
- NEJ!Stopp.Jobbar vi agilt behöver vi byta attityd och mindset kring krav.
- Men visst, vi måste erkänna att det finns skillnad på krav och krav…Dels har vi krav som beskriver effektmål eller övergripande egenskaper. Dels kan tredje part ställa krav på gränssnitt och API:er.Sedan har vi de detaljerade kravspecarna, som i detalj beskriver vad vi ska bygga.
- Vill vi skapa utrymme för att jobba agilt måste vi sluta skriva och värdera detaljerade kravspecar.Jobba istället med agila krav (såsom UserStories) och arbeta kontinerligt med att forma en allt bättre process som på bästa sätt förvandlar idé till fungerande värdefull testad mjukvara.
- # Dialog. Tillsammans. ## Anteckningar och skisser är ögonblicksbilder och input till vidare utveckling. ## Lägg dock värde i att dokumentera kunskap och hur det blev. Dokumentera beslut och detaljer i testfall, användarmanualer, ###...
- Våga bryta isär krav. Våga prioritera.Våga lita på att vi tillsammans, kund och team, kan identifiera och utveckla de bästa idéerna och funktionerna.Våga göra små steg i taget. Och våga välj bort.
- Och bara för att man inte jobbar med detaljeradekravspecar betyder det inte att resultatet blir helt slumpartat.Lita på processen. Lita på människorna. Lita på viljan och förmågan.Krav en bara en flyktig version av målet. Ett underlag i diskussionen. Inget mera. Spara det av nostalgiska skäl om du vill men lägg inget värde eller prestige i det. Fokus ska alltid vara värdefull mjukvara och kunskap.Krav en bara en flyktig version av målet.
- Tack!