Integrerat ingenjörsprojekt

Transkript

1 Integrerat ingenjörsprojekt TNIU21

2 Kursmål Studenten skall efter genomgången kurs kunna arbeta efter en projektmodell i en autentisk situation medverka aktivt och väl fungerande i en projektgrupp utveckla initiativförmåga och visa på kreativa lösningar införskaffa tillräckliga kunskaper inför utförande av projektarbete anpassa projektmodellen och teknik till projektkontext redovisa delresultat muntligt och skriftligt inom givna tids- och projektramar reflektera över utfört projektarbete och föreslå förbättringar runt metod och resultat 2

3 Examination Exjobbsrapport Behandlar metod/process, fokuserar ej på produkt Struktur: Sammanfattning / Abstract Introduktion Teori Metod Resultat Diskussion Slutsats 3

4 Reliabilitet & Validitet Validitet ser till att det som mäts är relevant i sammanhanget Reliabilitet ser till att det mäts på ett tillförlitligt sätt Validitet handlar om att använda rätt sak vid rätt tillfälle. Att kunna ange i vilken situation och för vilken population resultaten är giltiga Reliabilitet handlar om pålitlighet. Vilka beslut kan fattas om de baseras på mätningar som man inte kan lita på? Exempel Om vi vill räkna ut BMI (Body Mass Index) för en person så behöver vi längd och vikt. Om vi då har mätt skostorlek mycket noggrant så har vi uppnått hög reliabilitet, men låg validitet, för vi kan ju inte avgöra BMI med bara skostorleken. Om vi istället tittar på personen och skattar längd och vikt så har vi låg reliabilitet, men validiteten är högre. 4

5 Kvantitativ validitet Innehållsvaliditet: Avgöra om metoden mäter vad den ska Samtidig validitet: Säkerställer att resultat stämmer överens med resultat från andra undersökningar gjorda av andra (med en annan metod) Konstruktionsvaliditet: Stämmer relaterade begrepp överens med våra mätningar? Kommunikativ validitet: Att kommunicera sin vandring genom forskningsprocessen, så att försöket kan generaliseras/upprepas Pragmatisk validitet: Är den kunskap man kommer fram till användbar? 5

6 Kvalitativ validitet Kommunikativ validitet (inre validitet) Beskrivning av förförståelse/fördomar som författaren har Beskrivning av metod Beskrivning av urval av deltagare Beskrivning av analysprocessen Triangulering (inre validitet) Intervjua deltagare med olika relation till problemet Analysera materialet enligt olika paradigm Överförbarhet (yttre validitet) Författaren presenterar vägen och undersöker om resultaten är tillämpbara (ej generaliserbarhet) 6

7 Reliabilitet Kvantitativ reliabilitet Är mätningen fri från bias (fördom/vinkling) av personen som mäter? Påverkas mätningen av tiden? Finns det en samstännighet i utfallet mellan olika delar i en enkät som tar upp samma fenomen? Kvalitativ reliabilitet Är mätinstrumenten pålitliga? Är forskarens kvalitet tillräcklig? Är forskaren objektiv (inre validitet)? 7

8 Frågor på examination? 8

9 Iterativ utveckling Genomföra Planera Utvärdera Förstå/Besluta 9

10 Inkrementell utveckling 10

11 Agil utvecklingsmetodik Inkrementell och iterativ utvecklingsmetod Agile Manifest Individer och samspel framför metoder, processer och verktyg Körbar programvara framför omfattande dokumentation Kundsamarbete framför kontraktsförhandlingar Anpassning till förändring framför att följa en statisk plan 11

12 Extreme Programming För de dagliga aktiviteterna i projektet Utvecklarna sätts i första rummet Bill of rights Sustainable pace Fyra värden (öh, nej, fem...) Kommunikation, enkelhet, feedback, mod, respekt Practices Kodstandard, Kontinuerlig integration, Parprogrammering, TDD, Refactoring, m.m. 12

13 Extreme Programming Bill of rights Kundens rättigheter Ledningen har rätt att bestämma kostnader Ledningen har rätt att bestämma prioriteter Ledningen har rätt att se hur långt arbetet har fortskridit Teamets rättigheter Teamet har rätt att uppskatta hur lång tid en viss uppgift kommer ta Teamet har rätt att få sin uppskattning respekterad Teamet har rätt att ärligt rapportera fortgång Teamet har rätt att få veta vad som är viktigast att göra härnäst Teamet har rätt att få stöd närhelst teamet behöver det 13

14 Parprogrammering Två programmerare jobbar sida vid sida En programmerare, föraren, har kontrollen över tangentbordet och implementerar aktivt. Den andre programmeraren, observatören, observerar kontinuerligt det som föraren kodar för att identifiera taktiska defekter Vid behov kan de två programmerarna brainstorma runt hinder de möter på vägen och eftersom de ibland byter roller, arbetar de jämlikt tillsammans. 14

15 Parprogrammering Parprogrammerare spenderar ungefär 15% mer tid än individuella programmerare på samma uppgift. Dock är denna extra tid inte statistiskt signifikant. Parprogrammerare får 15% färre fel i koden än individuella programmerare. Denna högre kvalitet är statistiskt signifikant. 95% av parprogrammerare säger att de trivs bättre med arbetet, är mer självsäkra och litar på att den kod de har producerat fungerar. I det långa loppet tjänar man alltså både moral och pengar, eftersom det tar mycket lång tid att rätta buggar 15

16 Parprogrammering 16

17 Refactoring Omfaktorisering (refactoring) Effektivisera, optimera och öka läsbarhet utan att ändra funktionalitet Förbereder för och förenklar återanvändbarhet Ökar flexibiliteten i arkitekturen, vilket bidrar till okomplicerad design och en enkelhet att lägga till eller ändra krav Ökar underhållbarheten Unken kod är skäl för omfaktorisering Duplicerad kod Långa metoder Stora klasser Utspridda ändringar Switch/Case-satser Onödig generalitet Primitiva tvångstankar Kommentarer 17

18 Testdriven utveckling (TDD) Ger direkt feedback på felaktigheter i kod Ju längre en defekt finns i systemet desto svårare och kostsamt är det att ta bort den Därmed kan man hitta defekter och dess orsaker med lätthet Använder sig av en testfall som samlas i en testbänk (scaffolding) Genom att kontinuerligt köra dessa automatiska testfall kan man lätt se om en förändring påverkar systemet negativt Den automatiska testbänken gör därmed att ny funktionalitet lätt integreras i koden TNM021 Programvaruutveckling 18

19 Testdriven utveckling Hur då? 1. Skriv en testmetod för din metod 2. Kompilera testet. Det ska fallera, eftersom du inte har skrivit koden som testet ska anropa och testa 3. Implementera precis tillräckligt i metoden för att kompileringen ska gå igenom 4. Kör testet och kolla om det fallerar 5. Implementera precis tillräckligt i metoden för att testet ska gå igenom 6. Kör testet och kolla så att det inte fallerar 7. Omfaktorisera för förtydligande och borttagning av duplicit kod i metoden TNM021 Programvaruutveckling (TDD) 19

20 Scrum Scrum sköter den omkringliggande verksamheten, specifikt planering Scrum ger teamet chans att organisera sig själva 20

21 Scrum Roller Produktägare Har tätast kontakt med kund eller är kund Tar hand om kravarbetet (backlog i Scrum) Måste vara en gris Scrummaster Är processägare och ansvarig för att teamet ska lyckas med Scrum Är teamledare, inte projektledare Skyddar teamet mot omvärldens höns Är utvecklare i teamet och således gris Team/Utvecklare Storlek - 7 +/- 2 Självorganiserande, är sina egna projektledare Grisar 21

22 Scrum 24 timmar (daily scrum) Product backlog Sprint backlog Sprint planning 1-4 veckor sprint SPRINT Sprint retrospective 22 Leveransobjekt

23 Scrum Product backlog En lista av prioriterade arbetsuppgifter i projektet Listan baseras på kundens vision/krav Sprint backlog En prioriterad och tidsestimerad lista över arbetsuppgifter från projektet att utföra i aktuell sprint Tar de viktigaste sakerna ur Product backlog först Sprint planning Prioritering och tidsestimering av en lagom mängd uppgifter från product backlog som räcker för att ge ett leveransobjekt Man väljer ut så mycket som man lämpligen kan hinna med under en sprint (säg 1 vecka för detta projektet) Tidsestimering görs så bra man kan, estimerar man fel så har man lärt sig det till nästa sprint planning 23

24 Scrum Product backlog innehåller stories ID - unik identifering (det räcker med ett löpnummer) Namn - kort och beskrivande, verb och substantiv, 2-10 ord Viktighetsgrad - Produktägarens viktning, kanske, prioritet är ett dåligt ord. OBS! Olika viktning på alla delar! Ett första estimat - En enklare tidsuppskattning ifrån teamet Enheten är points och matchar något bra, i vårt fall ideala-ingenjörstimmar. Ta ett lagom stort antal personer (2-4), lås in er i ett rum där det finns mat och inga telefoner, hur många timmar skulle det ta att slutföra arbetet? Om svaret är 3 personer och 4 timmar, då är estimatet 12 points Det viktigaste är att estimatet används för att jämföra mot andra estimat... 2 points är dubbelt så mycket som 1, och matchar inte nödvändigtvis 2 timmar. Hur det ska testas/demas - gör det här, och sen det här, då borde det här inträffa. Ett användningsfall. (För TDD) Tillägg - annan info, referenser, m.m. 24

25 Scrum Product backlog ID Name Imp Est Demo Notes 1 Deposit See your own transaction story 10 8 Log in, open deposit page, deposit 10, go to my balance and check that it has increased by 10. Log in, click on transactions. Do a deposit. Go back to transactions, check that the new deposit shows up Need an UML sequence diagram. No need to worry about encryption for now Use paging to avoid large DB queries. Design similar to view users page. 25

26 Scrum Leveransobjekt En tillräckligt stor delmängd av systemet för att ge direkt nytta En helhet som fungerar och bara innehåller det viktigaste just nu Ger chans till utvärdering innan hela produkten är färdig Daily Scrum Vad har du gjort sedan igår? Vad planerar du att göra idag? Vad hindrar dig från att nå ditt mål? Sprint retrospective Ett möte där alla gruppmedlemmar reflekterar över genomförd sprint. Diskussion om vad som gick bra och vad man kan göra bättre nästa sprint. 26

27 Product Owner Product Backlog Scrum Master Team TDD Whole team Collective Ownership Tracker Continuous Integration Metaphor SCRUM Coding Standard Daily Scrum Pair programming XP Sustainable Pace Small Releases Refactoring Simple Design Planning Game Sprint Backlog Burndown Chart Sprint Planning Sprint Review 27

28 Feedback cycles Sprint demo Daily Scrum Kontinuerlig integration TDD/Enhetstest Parprogrammering 28

29 Agile & Usability 29

30 Frågor så långt? 30

31 Backlogbygge Timeboxed, som allt i Scrum (30 min) Resultat, en lista i viktighetsordning ID Name Imp Est Demo Notes 1 Deposit See your own transaction story 10 8 Log in, open deposit page, deposit 10, go to my balance and check that it has increased by 10. Log in, click on transactions. Do a deposit. Go back to transactions, check that the new deposit shows up Need an UML sequence diagram. No need to worry about encryption for now Use paging to avoid large DB queries. Design similar to view users page. 31

32 Sprint planning Vad krävs för sprint planning En product backlog! Att varje teammedlem vet hur mycket de kan lägga in i sprinten Vad kommer ur en sprint planning Ett sprint goal En lista på teammedlemmar och deras commitment Ett givet demodatum/tid En definierad plats och tid för daily scrum En sprint backlog En schysst plan som gör att teamet kan arbeta ostört en sprint Vilka deltar Kund / produktägare Alla andra grisar 32

33 Sprint planning Varför måste kund/produktägare delta? Fyra variabler Omfattning, estimat (tid), viktighetsgrad (kostnad), kvalitet Vem bestämmer vad? Extern kvalitet bestäms av användarna (en del av omfattning) Intern kvalitet är bestämd. Den tummar ingen på! Agenda Timeboxed! Produktägare bestämmer sprint goal (en helhet!) Teamet estimerar samt bryter ned stories tillsammans med kund/ produktägare Produktägare uppdaterar ev. viktighetsgrad Alla tillsammans bestämmer vilka stories som ska vara med Teamet sätter tid och plats för daily scrum 33

34 Sprint planning Vilka stories ska vara med? Om D ska få plats? Product backlog Product backlog Product backlog Product backlog A B C }Velocity D A B }Velocity A B C D }Velocity A1 B C D }Velocity D C E E E E A2 Alt. 1 Omprioritera Alt. 2 Ändra omfattning Alt. 3 Dela stories 34

35 Sprint planning Velocity Hur många story points är utförda? Focus factor Teamets effektivitet Available time Räknas i ideala-ingenjörstimmar/dagar Last sprint This Sprint 35 Focus factor = Actual Velocity Available time Estimated Velocity = Focus factor * Available time

36 Sprint planning Bryt ner stories i aktiviteter Det blir mycket diskussion och mycket ändringar i denna fas Smidigast att göra med post-it-lappar Produktägaren/kunden behöver inte delta Exempel: Storyn Query Users får aktiviteterna Clarify requirements, Write test code, Design GUI, Test GUI, Find reporting tool and do spike, Implement user list, Integration test, debug, refactor, Implement query form En story är färdig när den Är accepterad av produktägaren Håller tillräckligt hög kvalitet (dvs. är parprogrammerad, testad och omfaktoriserad enligt XP) Därmed bör test-first och omfaktorisering vara aktiviteter till en story (se ovan) 36

37 Sprint running Arbeta tillsammans och synliggör arbetet Sprint taskboard direkt efter sprint planning 37

38 Sprint running Ta från den översta storyn (viktighetsgrad 150) Sprint taskboard under dag 2 38

39 Sprint running Tydliggör oplanerade aktiviteter Sprint taskboard under dag 10 39

40 Sprint running Nya krav och förändrade krav som dyker upp mitt i sprinten? Placeras i product backlog av produktägaren, prioriteras/viktighetsgraderas av kund och estimeras (i mån av tid) av teamet Sätts upp som story under nästa sprint planning och utförs under den sprinten Om kravet är en rejäl förändring, stoppas sprinten och en ny sprint planning görs 40

41 Sprint tracking Burndown chart Om grafen glider över normalstrecket så är det läge att ta bort några planerade stories Om grafen glider under normalstrecket så lägger man till några ifrån backlog:en 41

42 Sprint retrospective Låt alla komma till tals Försök förklara estimated vs. actual velocity Dela upp i enkla kategorier, som good, could have been better, och improvements 42

43 Ert projekt Roller Flera produktägare Flera processägare (Scrum masters) Teamleaders Tisdagar demo / sprint planning Sista dagen Demo för examinator & kund Release Inlämning av rapport Kickout (lunch - boka bord! :) 43

44 Referenser Extreme programming explained, Kent Beck Agile Software Development with Scrum, Ken Schwaber/Mike Beedle Agile Project Management with Scrum, Ken Schwaber Scrum and XP from the Trenches, Henrik Kniberg 44