ETSF30 Requirements Engineering L6: Agile Prioritisation Christin Lindholm Validering av krav Syfte Att säkerställa att vi har eliciterat och dokumenterat rätt krav Kommer vi att bygga rätt system med dessa krav? Metoder Granskningar Tester Modellbaserad simulering Härledning med matematiska modeller Validering av kravspecifikationen Anpassa kravarbetet till projektet Alla i projekt måste ha förståelse för: Projektet omfattning Krav och bakomliggande behov Agile utveckling Grundtanke Utkast av system som testas snabbt Syfte Göra kunden nöjd leverera fungerande programvara under hela processen Krav på kundens engagemang Agile Manifesto http://agilemanifesto.org
Underliggande antagande Antagande om Förändring av krav Krav utvecklas över tid beroende av förändringar i teknologi, kundbehov och verksamhet -> krav uppkommer under utvecklingsprocessen, vilket innebär att lite tid läggs på initial kravelicitering Dokumentation Omfattande dokumentation och modeller är kontraproduktivt -> ingen detaljerad kravdokumentation i förväg Underliggande antagande forts Antagande om Interaktion med kund Kunden är frekvent tillgänglig för utvecklarna Agile utveckling vilar på denna tillgänglighet för elicitering och validering av krav Förändringskostnader Kostnaden för att göra förändringar ökar inte med tiden -> krav som utvecklas över tid ökar inte kostanden. Kravhantering utförs iterativt och inkrementellt Scrum Kravhanteraren Daily Användare/Kund -> Kravhanterare -> Scrum team Time Box Användare/Kund -> Kravhanterare i Scrum team Stories Tasks
Spotify Henrik Kniberg
Krav vs User stories Traditionellt krav 1. Systemet ska tillhandahålla ett konfigurerbart gränssnitt för alla användarfunktioner 2. Användargränssnittet ska vara konfigurerbart på följande områden: a) Font b) Bakgrundsfärg User story Som systemanvändare vill jag kunna konfigurera användargränssnittets font, bakgrundsfärg. Så att jag kan använda systemet på effektivaste sätt User-Story 6.2.3: (Avklarad) Prioritet: H Som spelare vill jag, med så få knapptryck som möjligt, kunna bekräfta mina inställningar och börja spela. Acceptanskriterier: a. På alternativskärmen skall det finnas en bekräfta-knapp. b. När spelaren trycker på knappen skall följande ske: 1. Inställningarna som gjorts skall sparas i appens interna databas. 2. Spelplanen skall visas. Förslag på implementation: Alla alternativ skall sparas i den lokala databasen vid ett knapptryck på bekräfta-knappen. Kommentarer: Scrum och Kanban Utvecklarna upplevde kraven i backlog: Kravet för vagt definierat eller För specifikt, lösning presenterades Face-to-face Upplevda fördelar Kunden kan styra i oväntade riktningar Eliminerar behovet av tidskonsumerande dokumentation och processer för godkännande Upplevda utmaningar Risk för felaktiga eller otillräckliga krav om intensiv interaktion med kund inte finns Få kund att vara onsite Att få koncensus vid mer än en kundgrupp Få förståelse eller tillit från kund som är van vid traditionella utvecklingsprocesser
Iterativ kravhantering Upplevda fördelar Upplevda utmaningar Extrem prioritering Upplevda fördelar Upplevda utmaningar Skapar mer tillfredställande relation med kunden Omedelbara tillgången till kunden ger klarare och mer förståeliga krav Svårt att skapa kostnads och tidsestimeringar för hela projektet Om kommunikationen upphör så skapar bristen på dokumentation problem Negligerar kvalitetskrav Kunden kan ge affärsmässiga skäl för krav -> lättare att förstå kundens prioriteringar och hjälper utvecklarna at bättre möta kundens behov Ger många tillfällen till omprioriteringar Att använda affärsvärde (time-tomarket) som enda prioriteringskriterie kan orsaka stora problem på längre sikt Ständiga omprioriteringar kan leda till instabilitet Konstant planering Upplevda fördelar Tidig och konstant validering -> minimerar till stor del behovet av stora förändringar Kostanden vid ändring minska dramatiskt jämfört med traditionell utveckling Upplevda utmaningar Kravförändringar gör att tidig arkitektur blir inadekvat och redesign av arkitektur ökar kostnaderna betydligt Behovet för refactoring är inte alltid uppenbart och förmågan beror på erfarenhet hos utvecklarna. Löser inte alltid problemet med otillräcklig arkitektur. Prototyping Upplevda fördelar Bra för att validera krav Upplevda utmaningar Kan vara svårt att underhålla och utveckla prototyper Problem med skalbarhet, säkerhet och robusthet Kan skapa orealistiska förväntningar från kunder
Test-driven utveckling Upplevda fördelar Tester kan användas för att skapa spårbarhet. Denna spårbarhet gör det lättare att infoga förändringar Upplevda utmaningar Stor utmaning att utvecklare inte är vana vid att skriva tester innan kodning Kräver förståelse av kraven och omfattande samarbete mellan utvecklare och kund eftersom det involverar förfining av låg-nivå specifikationer iterativt Granskningar (Reviews) och Acceptanstester Upplevda fördelar Granskningsmöten möjliggör: Förvissning att projektet är på rätt väg Ökar kundens tillit och förtroende identifierar problem tidigt Granskningsmöten hjälper ofta till att erhålla ledningsstöd (projekt status och progress till projekt sponsorer) Upplevda utmaningar Har ingen formell modellering av detaljerade krav -> formell verifiering Consistency checks (konsistens kontroll) eller formella inspektioner har man sällan Brist på tillgång till kund kan skapa problem vid acceptanstest då kunden ska utveckla testerna. Ofta används QA-personal för att hjälpa kunden utveckla dessa tester. Öppen källkod open source Öppen programvara Tillgänglig att använda, läsa, modifiera och vidareutveckla Inga licensavgifter Ej immaterialrätt Motprestation opensource.com Licenser Användning av öppen källkod styrs med hjälp av olika typer av licenser Copyleft - fritt distribuera (även sälja) och modifiera. Samma licens vid vidare spridning Permissive ( BSD-style ) krav på fortsatt spridning
Används Android TODO Talk Openly, Develop Openly Grupp företag Jenkins Garrit... Samarbete Projekt Program Verktyg Arbetssätt http://todogroup.org Kravprocessen Diskussion Prioritering Planering Elicitering Planering Elicitering Diskutera följande frågor: Informell Distribuerad Transparant Samarbete Realisering Scoping Realisering Specificering Planering Specificering Elicitering Realisering Scoping Specificering Validering Validering Prioritering Prioritering Scoping Validering Prioritering Varför behövs prioritering? När ska man göra prioriteringar? Vem (vilka roller) är lämpliga att göra prioriteringar?
Definition Prioritisation = to list or rate in order of priority Priority = 1 a (1) : the quality or state of being prior (2) : precedence in date or position of publication b (1) : superiority in rank, position, or privilege (2) : legal precedence in exercise of rights over the same subject matter Viktiga frågor kring prioritering Varför prioritera? När ska man prioritera? Hur ska man prioritera? Vem ska prioritera? Vad ska prioriteras? 2 : a preferential rating; especially : one that allocates rights to goods and services usually in limited supply that project has top priority 3 : something given or meriting attention before competing alternatives Varför prioritera? Vi måste höja systemets prestanda! Vi måste uppfylla nya krav! Vi har inte nog med pengar! Tiden rinner iväg! Nyttan med att prioritera Fokusera på det viktigaste Hitta hög- & låg-prioriterade krav Implementation av rätt krav i rätt ordning Spara tid och pengar Vi måste fixa alla felrapporter! Vi är ont om folk!
Hur ofta används olika funktioner egentligen? Exempel på hur det kan vara: Ibland, ofta eller alltid 36% Sällan 19% Aldrig 45% 80-20-regeln Pareto-principen (vital few, trivial many) 20% av kraven står för 80% av värdet 20% av kraven står för 80% av kostnaden 20% av kraven står för 80% av risken Några krav har Högt värde och låg kostnad, andra har Lågt värde och hög kostnad [Butler Group] Exempel från industriprojekt 13 The requirements value for customer 1 2 4 5 6 3 7 8 9 10 14 11 12 The requirements cost of implementation
Utmaningar med prioritering Abstraktionsnivå på prioriteringsobjekt Kombinatorisk explosion Beroenden Inte lätt att prediktera framtiden Vad behöver göras? Välja vad som ska värderas: è prioriteringskriterier Välja vad som ska prioriteras: è prioriteringsobjekt Strukturera och gruppera: på lagom nivå och rimligt antal Gör själva prioriteringen: prioriteter för varje objekt och kriterium Visualisera, diskutera, iterera, Objekt & kriterier Objekten är ofta produktegenskaper eller högnivåkrav som står för sig själv Kriterierna kan vara t.ex. Kundvärde Utvecklingskostnad Utvecklingstid Teknisk risk Passar säljtidpunkten Passar varumärket Maximera / Minimera På vilken nivå ska vi prioritera?
När prioritera? På vilken skala ska vi ange prioriteter? Inför beslutspunkter, t.ex. Projektstart Konstruktionsstart Releaseplanering Inkrementplanering Vid stora förändringar Upprepade gånger med lagom intervall Kategorisering ex: måste-krav, tvetydiga, ändringsbenägna Dela in i grupper utan inbördes ordning Ordinal skala ex: dyrare, större risk, högre värde Rankad lista A>B Ratioskala ex: $, h, % (relativ) Numeriska relationer A=2*B Olika principer för prioritering Kategorisering Exempel: Stabila, Ändringsbenägna, Oumbärliga, Uteslutna Ger olika högar med krav Sortering på ordinal-skala Parvis jämförelse < mer eller mindre Ger rangordnad lista Estimering på ratio-skala Parvis jämförelse på graderad skala Ger estimat för varje krav som ger relationer # Antal timmar $ Pengar % Relativt Olika tekniker för prioritering Analytical Hierarchy Process (AHP) Ratio-skala, parvisa jämförelser, kräver verktygsstöd, ger mått på graden av konsekvens (consistency) Ranking (sortering) Ordinal skala, parvisa jämförelser, enkel Numeriska betyg Ordinal skala; snabb och enkel; risk att allt blir lika viktigt då kraven inte ställs mot varandra; risk att folk tolkar som ratio-skala (även om betyget 4 inte nödvändigtvis är dubbelt så mycket som betyget 2 ) Top-ten Ordinal skala, snabb och enkel, ger grov uppskattning av en begränsad del av kraven
Vanlig industriell praxis Kraven kategoriseras på skala 1-4 [Lau:7.4] Problem: Kraven ställs aldrig mot varandra Vilket ska bort när viktigt krav tillkommer? Allt tenderar bli viktigast; ger beslutskramp Hur sker prioriteringen? Arbetsgrupper eller individuellt? Gruppdynamik kan påverka Viktigt skapa konsensus? Distribuerat i tid och rum? Parvisa jämförelser: värde Which requirement has the higher value for customer? Parvisa jämförelser: kostnad Which requirement has the higher cost of implementation? Normal papers Very much more More Equal More Very much more Image enhancement Normal papers Very much more More Equal More Very much more Image enhancement Image enhancement Memory buffer Image enhancement Memory buffer Voice control Address book Voice control Address book
Hur lång tid tar det? Kategorisering snabbast men ger minst Jämförelserna går snabbare med tiden Parvisa jämförelser: Minst en jämförelse per krav Om fler görs kan man upptäcka inkonsekvenser Maximal redundant: n*(n-1)/2 Visualisering - värde Visualisering - kostnad
Kostnad-värde-diagram Inkrementell prioritering När nya krav tillkommer: Infoga i strukturen Jämför med befintliga krav Visualisera, diskutera, revidera Ändringshantering Analytical Hierarchy Process Utvecklad av Thomas L. Saaty på 80-talet Allmän teknik inom beslutsteori Parvisjämförelse av alla möjliga par på ratioskalan: 1 Of equal value 3 Small difference 5 Essential or strong value 7 Very large difference 9 Extreme difference 2, 4, 6, 8 Intermediate values Matrisberäkningar ger prioriteter och mått på graden av inkonsekventa jämförelser
Consistency Releaseplanering Konsekvent Att välja ut en mängd krav som skall implementeras i nästa utgåva. Inkonsekvent AHP föreslår 0.1 som övre gräns för hanterbar inkonsekvensgrad, men det är för restriktivt i kravsammanhang då osäkerheterna ofta är stora Releaseplanering Att välja ut en mängd krav som skall implementeras i nästa utgåva. Mest risk först? Det som konkurrenterna inte har först? Få arkitekturen på plats? Nödvändigaste funktionerna först? Funktion före tillförlitlighet? Release-tema? Krav som är beroende?
Summering Nytta av prioritering Fokusera på det viktigaste Hitta hög- & låg-prioriterade krav Implementation av rätt krav i rätt ordning Spara tid och pengar Prioritera i era projekt! Inlärningsmål: Kunskap och förståelse För godkänd kurs skall studenten kunna: definiera grundläggande begrepp och principer inom kravhantering redogöra för ett flertal olika typer av krav redogöra för och värdera ett flertal olika metoder och tekniker för kravhantering beskriva och relatera olika delprocesser inom kravhantering beskriva kravhanteringsprocessens relation till övriga processer i produktlivscykeln 64
Inlärningsmål: Färdighet och förmåga För godkänd kurs skall studenten kunna: välja lämplig kravhanteringsteknik för sammanhanget använda flera olika tekniker för att identifiera krav använda flera olika tekniker för att specificera krav använda flera olika tekniker för att validera krav använda flera olika tekniker för att prioritera krav Inlärningsmål: Värderingsförmåga och förhållningssätt För godkänd kurs skall studenten kunna medvetet kunna välja arbetssätt efter hur kravbilden ser ut på ett adekvat sätt kunna involvera användare i kravprocessen visa ett prov på ett systematiskt och långsiktikt arbetssätt medvetet kunna problematisera över kravkvalitetens påverkan på slutproduktens kvalitet 65 66 Vad händer nu? Sista övningen tisdag och onsdag Labb 4 oktober 13-15, 15-17 Glöm inte förberedelse uppgiften!! Tenta måndagen den 23 oktober kl. 14-19 Tips skriv mycket på den sista delen! Handledning Handledning 21 november utkast kravspec Handledning 14 december färdig kravspec Fram till 21 november?