Översikt Fö: Projekt: Interaktivt system Kursinformation och introduktion Kursupplägg Systemutveckling Agila metoder Användarorientering Mål Projekt Utveckla en grafisk interaktiv tillämpning ihop med beställare (kunder) Utveckla programvara tillsammans med programmerare och beställare (kunder) Utveckla programvara baserat på agila metodikens grundvärderingar Praktiker att använda Coachning Deltagande design (participatory design) User stories Planning games Acceptanstester Parprogrammering Testdriven utveckling Scrum-möten (dagligen, eller nästan dagligen) Informativ arbetsplats Sitt tillsammans Helt team Andra tekniker som ni finner intressanta eller som föreslås av era coacher 1
Föreläsningar Övningar Intro XP Deltagande design Sketching XP Sketching Avstämningar Seminarier Olika teman Koppling till era coacher Tidsuppskattning XP 160h 43h = 117h per person Värden Principer Praktiker 2
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 Värde - Enkelhet Värde - Feedback Koda för idag Vad är det enklaste som kan fungera? 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 Värde - Respekt Mod att tala sanning fostrar kommunikation Mod att släppa misslyckade lösningar uppmuntrar enkelhet Mod att söka riktiga konkreta svar, skapar feedback Bidragen från varje person i teamet måste respekteras 3
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 Princip - Mänsklighet Princip - Ekonomi 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 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 Princip - Självlikhet 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 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 4
Princip - Förbättring Princip - Mångfald Starta en aktivitet, gör ditt bästa idag, förbättra lösningen över tid Teams 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 kommunkation! 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 Princip - Möjlighet Princip - Redundans Problem är möjligheter till förändring 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. 5
Princip - Misslyckande Princip - Kvalitet Att försöka och misslyckas ger kunskap Om du inte vet bästa sättet, prova alla (eller många) 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 Princip Accepterat ansvar 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? 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 6
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 Praktik - Veckocykel 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 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! 7
Praktik - kvartalscykel Praktik - Slack 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 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 8
Praktik Inkrementell design Planering Designa om varje dag vid behov Försök få designen av systemet att fylla de behov som finns idag 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 Ca 3 meningar i kundterminologi Tillräcklig detalj för att kunna tidsuppskatta utvecklingstiden Storys bör tilldelas affärsvärde: nödvändig, värdefull, eller bra idé Utvecklare kan föreslå storys men kunden har sista ordet Stories kan läggas till, ändras eller tas bort under projektets gång Skriva user stories Releaseplanering 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 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 9
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 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å 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 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 Summera tidsuppskattningarna Summan får ej överskrida totala tillgängliga tiden Om tidsuppskattningar visas vara fel under iterationen, be kunden justera omfånget 10
Testning Acceptanstest 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 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 11
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 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 12
Dokument Scrum-möte Burn-down chart 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 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 13
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 Minst 2 användare Minst 1 utvecklare Design workshop 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ändbarhetsgenomgå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 14