TDP023 Projekt: Agil systemutveckling Johan Åberg johan.aberg@liu.se
Tre moment Projekt 8hp Marknadsföring av produkt 2hp Kopplat till projektarbetet Individuell rapport 2hp Kopplad till projektarbetet Learning by doing (and reflecting)!
Tidsplan - översikt V3+4: Planering + förberedelse (sprint 0) V5+6: Sprint 1 V7+8: Sprint 2 V9+10: Sprint 3 V15+16: Sprint 4 V17+18: Sprint 5 + överlämning V19-21: Marknadsföring av produkt V19-21: Individuell rapport
Roller Lärare Johan Åberg Studierektor Jalal Maleki 5 utvecklingsteam 4-5 studenter per team Extern kund (1 per team) Intern scrum master för varje team Externa coacher i VT1
Scrum master Ansvar burn-down chart; att den blir till (delat ansvar med coacherna), samt att den uppdateras håller i tidsestimeringsarbetet (planning poker) fördelning av stories scrum-möten; att de blir till, uppföljning kommunikation med kund håller i sprint start håller i sprint end (inklusive retrospective, och att den följs upp)
Projekt med extern kund 5 projekt att välja mellan Intresseanmälan görs på enkät efter denna föreläsning Projekt kan kräva underskrift av sekretessvillkor Liknande villkor som för uppsatsarbeten med företagskunder och kursen Företagsprojekt Kunden äger det utvecklade systemet
Planering & förberedelse Sprint 0 Teknik Få igång teknik, versionshantering, etc Genomför tekniköversikt Databashanterare Programspråk Genomgång av ev. nuvarande system Organisation Ta kontakt med kunden Boka ett första möte, helst redan första veckan Lär känna varandra Lär känna coacherna Kick-off? Litteratur Läs kurslitteraturen
Sprints - organisation Sprint start Första onsdagen kl 13-17 13-15 tid för estimering av stories i backlog + ev nya stories 15-16 prioritering av stories av kund 16-17 fördelning av stories bland utvecklare Sprint end Demonstration andra fredagen kl 15-16 Retrospective direkt efter sprint end, dvs ca kl 16-17 OBS: Dagliga (nästan) scrum-möten på fixa(!) tider
Tillgänglig tid Projektarbete (8hp) Sprint 0: 4h schemalagd tid + 26h förberedelse & inläsning Sprint 1-5: 20h schemalagd tid + 15h övrig tid (35h per sprint) Språklig kommunikation (2hp) 52h per person Individuell reflektionsrapport (2hp) 52h per person
Exempel burn down chart Tillgänglig tid: 35h/pers/sprint Antal pers: 4 Parprogrammering 2 par Velocity: 70% Tillgänglig tid: 35h/pers/sprint Antal pers: 5 Parprogrammering 3 par Velocity: 70% Tillgänglig tid för stories? (35*2) * 0.7 = 49h Tillgänglig tid för stories? (35* 3) * 0.7 = 73.5h
Exempel (forts) 49 x x x x Varje x markerar totaltiden för stories som ännu ej slutförts under sprinten. 25 x x x x x 0 x
Retrospective Sista moment i varje sprint end Vad har gått bra? Vad har gått dåligt? Alla i teamet skriver på post-its Plus: vad har gått bra, och ska bibehållas? Delta: vad ska förbättras? De vanligaste plus:en och delta:n sammanställs och följs upp under nästa sprint
Planning poker Alla i teamet estimerar en story/task Väljer ett kort/skriver en siffra Alla visar upp sitt val samtidigt Den som valt minst tid och den som valt mest tid diskuterar och enas om en estimering Finns varianter
Litteratur Kursbok Kent Beck, Extreme Programming Explained Artiklar Williams, L., Kessler, R.R., Cunningham, W., Jeffries, R. Strengthening the case for pair programming, IEEE Software, 17(4), pp. 19-25, 2000. Kjetil Molokken-Ostvold, Nils Christian Haugen, Hans Christian Benestad. Using planning poker for combining expert estimates in software projects, The Journal of Systems and Software 81, pp. 2106-2117, 2008.
Examination Aktivt deltagande i projektarbetet (8hp) Språklig kommunikation (2hp) Individuell reflektionsrapport (2hp) Deadline 21/5, 08.00 Ska klargöra studentens individuella bidrag till det levererade systemet, inklusive lyckade och mindre lyckade kodexempel Inkludera sammanställning av commitlogg Ska klargöra vad studenten lärt sig i projektet OBS: För dagbok under projektets gång för att ha bra underlag för skrivandet
Sekretess Etik
Frågor?
Uppdrag - Omnicloud Utveckla ett Linux CLI till Omnicloud som låter användare interagera med tjänsten via Linux command-line. CLI:et ska vara trådat och ta emot push-notifikationer från servern över TLS. Det ska stödja de funktioner som vårt nuvarande API klarar av såsom att lägga till och ta bort projekt och domäner. CLI:et ska vara skrivet i ett kompilerat språk och det ska inte finnas några licensproblem för att distribuera binären.
XP Extreme Programming Värden Principer Praktiker
Värden Kommunikation Enkelhet Feedback Mod Respekt
Värde - Kommunikation Någon annan kan veta lösningen Någon annan kan hjälpa mig hitta lösningen Kommunikation skapar lagkänsla och samarbete
Värde - Enkelhet Koda för idag Vad är det enklaste som kan fungera?
Värde - Feedback Förändring skapar behov av feedback Kritisk del av kommunikation Typer Åsikter om idéer, dina eller andras Hur kod ser ut när man implementerar en idé Hur en idé fungerar när den sjösätts
Värde - Mod Mod att tala sanning fostrar kommunikation Mod att släppa misslyckade lösningar uppmuntrar enkelhet Mod att söka riktiga konkreta svar, skapar feedback
Värde - Respekt Bidragen från varje person i teamet måste respekteras
Fler värden Safety Säkerhet Pålitlighet Etc Teamets beteende ska reflektera värdena!
Principer Mänsklighet Ekonomi Delad nytta Självlikhet Förbättring Mångfald Reflektion Möjlighet Flöde Redundans Misslyckande Babysteg Accepterat ansvar
Princip - Mänsklighet Utvecklare är människor, med fundamentala mänskliga behov: Grundläggande säkerhet Prestation Tillhörighet Växa Intimitet Balansera individuella behov med teamets behov
Princip - Ekonomi Utveckling måste ha affärsvärde, möta affärsmål, och stödja affärsbehov En krona idag är värd mer än en krona imorgon, tjäna pengar tidigt och spendera pengar sent Att först lösa affärsbehovet med högst prioritet, maximerar nyttan av projektet
Princip Delad nytta Varje aktivitet bör komma till nytta för alla inblandade Viktigaste och svåraste principen Nytta för mig nu, för mig senare, och för kunden Win-win-praktiker: Testdriven programmering Omfaktorering Generell kodstil
Princip - Självlikhet Kopiera en struktur (lösning) som fungerar till en annan kontext, även i olika (tids)skalor Kvartal: lista teman som ska behandlas och hantera med stories Vecka: lista stories som ska hanteras, skriv tester, få dem att fungera Timmar: Lista tester som ska skrivas, skriv ett test, få det att fungera, skriv ett till, få dem båda att fungera, osv, till listan är tom
Princip - Förbättring Starta en aktivitet, gör ditt bästa idag, förbättra lösningen över tid
Princip - Mångfald Team behöver varierande kunskaper, attityder och perspektiv Mångfald leder ofta till konflikter, t.ex. genom flera sätt att se på och lösa ett problem Kom ihåg respekt och kommunikation!
Princip - Reflektion Gör jobbet, tänk på hur du gör det, och varför det fungerar (eller inte fungerar) Lyft fram misstag och lär från dem Reflektion både i teamet och individuellt Retrospection vid sprint end!
Princip - Flöde Kontinuerligt flöde av aktiviteter snarare än diskreta faser
Princip - Möjlighet Problem är möjligheter till förändring
Princip - Redundans Kritiskt viktiga problem ska hanteras på flera olika sätt (med flera praktiker) Exempel Kodningsdefekter undviks genom parprogrammering, kontinuerlig integration, riktig kundinvolvering, testdriven programmering, etc.
Princip - Misslyckande Att försöka och misslyckas ger kunskap Om du inte vet bästa sättet, prova alla (eller många)
Princip - Kvalitet Om du inte vet bästa sättet att göra något gör ditt bästa Om du vet bästa sättet att göra något men att det skulle ta för lång tid gör det bästa du kan på den tid som finns
Princip - Babysteg Gör inte stora ändringar i stora steg Vad är det minsta du kan göra som märkbart går i rätt riktning?
Princip Accepterat ansvar Ansvar kan inte tilldelas du avgör om du tar ansvar eller ej Med ansvar kommer auktoritet
Praktiker Praktiker ges mening av värdena Praktiker är situationsberoende Praktiker kan delas in i Primary & Corollary Praktiker fungerar bra tillsammans Interaktionen mellan praktiker förstärker deras effekter
Praktiker - Primary Arbetsvillkor Helt team Sitt tillsammans Informativt arbetsutrymme Energiskt arbete Planering Stories Veckocykel Kvartalscykel Slack Implementation & testning Parprogrammering 10 minuters build Kontinuerlig integration Testdriven programmering Inkrementell design
Praktik Helt team Inkludera alla nödvändiga kunskaper och perspektiv Försök hitta team spirit Vi hör tillsammans Vi gör det här tillsammans Vi stödjer varandras arbete, utveckling och lärande Ideal storlek? Brytpunkter vid 12 och 150 Undvik att sätta personer i olika team
Praktik Sitt tillsammans Öppet utrymme för teamet Litet privat utrymme i närheten eller begränsade arbetstimmar Om det inte går hela tiden försök lösa det delar av tiden
Praktik Informativt arbetsutrymme Ge översikt av projektstatus och framsteg Stories på en vägg, sorterade spatiellt, enligt t.ex följande rubriker: Klart Denna vecka Denna release Att tidsuppskatta Framtid Stora synliga diagram
Praktik Energiskt arbete Arbeta bara så många timmar som du kan vara produktiv och hålla ut Hantera arbetstiden mer effektivt, t.ex. programmera en tid med e-mail och telefon avstängd Om sjuk, stanna hemma och bli frisk
Praktik - Stories Kundsynlig funktionalitet Uppskatta utvecklingsarbetet för genomförande Skriv på kort Namn Kort skriftlig eller grafisk förklaring Tidsuppskattning (timmar) Sätt kortet på väggen
Praktik - Veckocykel Planera arbete en vecka i taget Vid veckomöte: Granska utveckling hittills, förhållande till förväntad utveckling Kunden väljer stories för veckan Bryt ner stories i tasks om nödvändigt Team medlemmar tar på sig tasks och tidsuppskattar dem Skriv tester för stories Jobba ej på helger! OBS: i denna kurs kör vi cykler om två veckor
Praktik - kvartalscykel Planera arbetet ett kvartal i taget Vid kvartalsmöte: Identifiera flaskhalsar Initiera åtgärder Planera teman Välj ut stories för kvartalet för att adressera valda teman Fokusera på helheten, hur projektet passar in i organisationen
Praktik - Slack Inkludera små tasks som kan släppas om det behövs Man kan alltid lägga till mer stories och leverera mer än utlovat För att få en atmosfär av tillit är det viktigt att inte bryta löften Inkludera slacktid, 1 vecka av 8, eller % av tid
Praktik - Parprogrammering Sida vid sida vid en dator Om du behöver tänka själv/pröva en idé/prototypa, gör det och ta upp resultatet i gruppen, och implementera om i par Rotera par ofta Respektera personligt utrymme, tänk på individuella och kulturella skillnader Om du känner dig obekväm i ett par, ta upp det
Praktik 10-minutersbuild Bygg automatiskt hela systemet och kör alla tester automatiskt på 10 minuter Lagom tidsgräns för att köpa en kaffe
Praktik Kontinuerlig integration Integrera och testa ändringar ofta (efter max 2-3 timmar) Ju längre du väntar med integration desto högre och mer oförutsägbar blir kostnaden Integrera och testa efter varje parprogrammeringsepisod
Praktik Testdriven programmering Skriv först test innan addering eller ändring av kod (för en story eller task) Testa, koda, omfaktorera, testa, koda, omfaktorera, Dessa små test används vid den automatiska builden och testen av hela systemet
Praktik Inkrementell design Designa om varje dag vid behov Försök få designen av systemet att fylla de behov som finns idag
Planering XP-planering Förutsäga vad som kommer att åstadkommas till leveransdatum Bestämma vad som ska göras näst Betoning på styrning Två steg Releaseplanering Iterationsplanering
Releaseplanering
Releaseplanering Kunder skriver user stories Varje story representerar en önskad feature. Alla stories ihop specificerar systemet Tillräcklig detalj för att kunna tidsuppskatta utvecklingstiden Utvecklare kan föreslå storys men kunden har sista ordet Stories kan läggas till, ändras eller tas bort under projektets gång Formulering: Som en X vill jag kunna göra Y för att Z
Skriva user stories Kunden tar en hög med kort och skriver stories Utvecklare ställer frågor för förtydliganden (ej för implementationsaspekter) Riv sönder kort och skriv nya vid behov För bakomliggande kod/teknik, försök relatera till kundbehov och bryt ner det i stories
Releaseplanering Utvecklare uppskattar hur lång tid stories kan ta att implementera Varje story får en 1, 2, eller 3-dagarsuppskattning i ideal utvecklingstid Längre än 3 dagar -> kunden bryter ner storyn i mindre delar Kortare än 1 dag -> för detaljerad, slå ihop stories Varje story får en teknisk risknivå: låg, medel, hög
Tidsuppskatta user stories Intuitiv tidsuppskattning Hur lång tid skulle det ta om du programmerade hela dagarna utan avbrott Spike-lösning Experimentera för att få en idé om hur problemet kan lösas Uppskatta med jämförelse Jämför storyn med tidigare implementerade stories
Iterationsplanering
Iterationsplanering Projekthastighet baseras på föregående iteration Hur många stories/tasks har slutförts? Summera tidsuppskattningarna av antalet genomförda stories/tasks under föregående iteration Summan = projekthastighet Kunden väljer stories från releaseplanen Misslyckade acceptanstest att fixa väljs också
Iterationsplanering Valda user stories och misslyckade tester bryts ner till tasks Tasks skrivs ner på kort (som för stories) Stories skrivs i kundens språk, tasks skrivs i utvecklarnas språk Eventuella dubletter tas bort
Iterationsplanering Utvecklare väljer tasks och tidsuppskattar dessa Varje task uppskattas som 1, 2, eller 3 ideala programmeringstimmar Tasks kortare än 1h -> slås ihop med andra tasks Tasks längre än 3h -> bryts ner i delar
Iterationsplanering Summera tidsuppskattningarna Summan får ej överskrida totala tillgängliga tiden Om tidsuppskattningar visas vara fel under iterationen, be kunden justera omfånget
Testning Fel är kostsamma, och att eliminera fel är också kostsamt Ju tidigare ett fel hittas, desto billigare att fixa Acceptanstester testar funktionaliteten av hela systemet (kund) Enhetstester testar komponenter (utvecklare) Så snart ett test lyckas, så fortsätter teamet se till att testet förblir lyckat
Acceptanstest Acceptanstester skapas från user stories Under en iteration kommer valda user stories att översättas till acceptanstester av kunden En story kan ha en eller flera acceptanstester, där varje test representerar något förväntat resultat Kunden ansvarar för att verifiera om ett acceptanstest går igenom, och avgöra vilka misslyckade tester som har högst prioritet att fixa i nästa iteration
Automatisera acceptanstester - tips Definiera input och förväntad output Skriv funktionella tester som program Använd scriptspråk för att simulera GUIkommandon Använd en inputinspelare och be kunden använda denna för att definiera tester Automatisera tester inkrementellt Kan vara lurigt för väldigt interaktiva system
Enhetstester Skapa eller ladda ner ett testramverk T.ex. www.xprogramming.com/software.htm Stöd i Visual Studio Testa alla klasser i systemet Ej triviala get- och set-metoder Skapa testerna först, innan koden skrivs Enhetstesterna checkas in i repositoryt tillsammans med koden de testar
Buggtester När en bugg upptäcks skapas tester som synliggör buggen En bugg i produktion kräver ett acceptanstest som vakar över buggen Givet ett misslyckat acceptanstest, kan utvecklare skapa enhetstester som visar felet mer kodspecifikt När enhetstesterna går igenom till 100% kan man köra om acceptanstestet
Scrum Projektledningsmetod för agil programutveckling Egenskaper Levande backlog av features Korta iterationer eller sprints Kort dagligt möte, sk Scrum-möte
Sprint
Roller Scrum team Litet självorganiserande team som utför utvecklingsarbetet Fullständig auktoritet att ta nödvändiga åtgärder för att uppnå åtagandena Helst ca 7 personer inklusive analytiker, designer, kvalitetsansvariga, programmerare
Roller Produktägare Representerar kunden och styr mot affärsperspektivet Administrerar product backlog Är ofta en kund, men kan vara en del av den interna organisationen Rollen kräver kunskap om engineering, marknadsföring, och affärsprocesser
Roller Scrum master En kombination av coach & fixare Träffar teamet dagligen i Scrum möten Försöker få scrum teamet att kunna jobba i lugn & ro Fokuserar alltid på att ge teamet bästa möjliga förutsättningar för att uppnå målen med sprinten Efter varje sprint håller scrum master ett utvärderingsmöte med teamet sprint retrospective
Dokument Product backlog Högnivådokument för hela projektet Innehåller övergripande beskrivningar av alla nödvändiga features, önskelistefeatures etc Är öppen och editerbar av alla Innehåller grova tidsuppskattningar, i dagar
Dokument Sprint backlog Detaljerat dokument om hur teamet ska implementera kraven för kommande sprint Tasks bryts ner i timmar, med en maxgräns på 16h Ingen tilldelas tasks i sprint backlog, teammedlemmarna väljer själva
Burn-down chart Dokument
Scrum-möte Daglig lägesdiskussion med teamet ett måste Mötesriktlinjer Startar exakt i tid, med överenskomna straff för försening Max 15 minuter oavsett teamstorlek All deltagare står upp Alla utvecklare besvarar följande frågor Vad har du gjort sedan förra mötet? Vad tänker du göra inför kommande möte? Är det något som hindrar dig från att uträtta ditt planerade arbete?
Agila metoder Möjligheter Fokus på förändring Kundinvolvering Löser problem med vattenfallsmodellen: Kravspecar alltid fel Designarbete tidigt och sedan ej förändringsbart Slutanvändaren bortglömd Risker Programmerarcentrerad metod ID och användbarhet en sidoeffekt av kodandet -> går emot 30 års erfarenhet av UCD Helheten tappas bort -> lapptäcke Kund = användare?
En ansats från NN/g
Sprint 0 Start vid första kundträffen Möjlighet till designarbete innan första iterationen börjar med planning game den 21/4 Datainsamling -> Skapa personas Övergripande design -> Storyboards Utvärdering av konkurrerande system -> Mål/krav
Användbarhetstestning - Revolving door Boka testanvändare vid en fix tid varje vecka Användbarhetstesta det som finns Bättre att testa något än inget alls
Spikes Skapa spikes För design & datainsamling & användbarhetstestning Tidsuppskatta på samma sätt som för user stories Dra bort tiden från tillgänglig tid vid planning game
Deltagare Design workshop Minst 2 användare Minst 1 utvecklare Minst 1 facilitator/moderator Förberedelse för utvecklare Införskaffa kunskap om problemdomänen Undersök minst en potentiell lösning Förbered scenarier Förbered agenda Boka deltagare, mötesrum, fixa material
Design workshop - agenda Introduktioner Användbarhets-genomgång Syfte & förväntningar Identifiera problem Designmål Scenarier Pappersprototypning Kombinera designer Mer designarbete Genomgång av syfte & förväntningar & resultat Dokumentera resultaten