Tre moment. TDP023 Projekt: Agil systemutveckling. Tidsplan - översikt. Roller. Projekt med extern kund. Scrum master

Transkript

1 Tre moment TDP023 Projekt: Agil systemutveckling Johan Åberg 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+11: Sprint 3 V12+13: Sprint 4 V16+17: Sprint 5 + överlämning V18-20: Marknadsföring av produkt V18-20: Individuell rapport Roller Lärare Johan Åberg Studierektor Jalal Maleki 8 utvecklingsteam 3-4 studenter per team Extern kund (1 per team) Intern scrum master för varje team Externa coacher Ansvar Scrum master burn-down chart; att den blir till, 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 Dropbox-liknande klient för att synkronisera filer mellan molnplattform & vanlig dator Teknik: OpenSSH, C++ Demonstrator för nytt spelkoncept (betting) Teknik: väljas i samråd med kund (t.ex. Android, iphone el. webb) Digitalt arbetsbord med mobil slavdisplay för intensivvården Teknik: C#, Android (Java/Ajax/HTML?), MS Win7 (Multitouch Lib) OpenAss Assistering över IP (fråge-svarslösning) Teknik: Webb, Android System för rangordning av webbsidor m.a.p. lättlästhet Teknik: webb System för central loggning och övervakning av serverpark Teknik: webb, lite DB Verktyg för ritning av orienteringskartor Teknik: webb (javascript, etc) Matplaneringsverktyget PlanEatSmile vidareutvecklas med stöd för varuplanering etc Teknik: php + javascript 1

2 Projekt med extern kund (forts.) Planering & förberedelse Sprint 0 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 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 Tillgänglig tid Sprint start Första måndagen kl tid för estimering av stories i backlog + ev nya stories prioritering av stories av kund fördelning av stories bland utvecklare Sprint end Demonstration andra fredagen kl Retrospective direkt efter sprint end, dvs ca kl Dagliga (nästan) scrummöten på fixa(!) tider 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 Velocity: 70% Tillgänglig tid: 35h/pers/sprint Antal pers: 3 Parprogrammering Velocity: 70% Tillgänglig tid för stories? ((35*4) / 2) * 0.7 = 49 Tillgänglig tid för stories? (35* 2) * 0.7 = 49 2

3 Exempel (forts) Retrospective x x x x x Varje x markerar totaltiden för stories som ännu ej slutförts under sprinten. x x x x x 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 , 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 , Examination Aktivt deltagande i projektarbetet (8hp) Språklig kommunikation (2hp) Individuell reflektionsrapport (2hp) Deadline 21/5, Ska klargöra studentens individuella bidrag till det levererade systemet, inklusive lyckade och mindre lyckade kodexempel 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 3

4 Etik Frågor? Sekretess Gruppindelning XP Enkät Värden Principer Praktiker Värden Värde - Kommunikation Kommunikation Enkelhet Feedback Mod Respekt Någon annan kan veta lösningen Någon annan kan hjälpa mig hitta lösningen Kommunikation skapar lagkänsla och samarbete 4

5 Koda för idag Värde - Enkelhet 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 Principer Safety Säkerhet Pålitlighet Etc Teamets beteende ska reflektera värdena! Mänsklighet Ekonomi Delad nytta Självlikhet Förbättring Mångfald Reflektion Möjlighet Flöde Redundans Misslyckande Babysteg Accepterat ansvar 5

6 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! 6

7 Princip - Reflektion Princip - Flöde 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 Kontinuerligt flöde av aktiviteter snarare än diskreta faser Retrospection vid sprint end! 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 7

8 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 - Primary 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 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 8

9 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 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 9

10 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 XP-planering 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 10

11 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 Iterationsplanering 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 11

12 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 12

13 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. 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 13

14 Produktägare Roller 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 Scrum master Roller 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 Product backlog Dokument 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 Sprint backlog Dokument 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? 14

15 Agila metoder En ansats från NN/g 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? 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 Skapa spikes 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 15

16 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 16