Succes med agile. The hardest single part of building a software system is deciding precisely what to build. Fred Brooks, No Silver Bullet

Transkript

1 Succes med agile The hardest single part of building a software system is deciding precisely what to build. Fred Brooks, No Silver Bullet

2 Kort om Ative Kurser Bedre software hurtigere Konsulenter Bedre viden Bedre vaner Bedre resultater Rådgivning Arkitekter Udviklere ScrumMasters Projektledere CI/Test/build automatisering Scrum / lean transformation Indføring af Scrum, lean & CI Scrum certificeringer Kurser med verdens førende eksperter

3 Nysgerrig efter mere? Vi hjælper også gerne dit team godt i gang Inspiration i din virksomhed, eksempelvis indlæg på afdelingsmøder eller gå-hjem-møder Kurser i alt fra agil kravhåndtering til TDD Rådgivning og coaching On-site eksperter, der ved sidemandsoplæring hjælper jer hurtigere fra start Kontakt os og hør mere

4 Kontakt Martin Gildenpfennig Jan Elbæk

5 Agenda Den agile organisation Pause Succes med agile: Det Gode Håndværk Pause Det Gode Håndværk del 2

6 DET AGILE LØFTE

7 Improved productivity Agile projects are 16% more productive at a statistically significant level of confidence. Source: Mike Cohn SwA 2010.

8 Faster time-to-market Agile projects have at average 37% faster time to market at a statistically significant level of confidence. Source: Mike Cohn SwA 2010.

9 Hvad motiverer organisationer til agile? at blive agile

10 Teleselskabs vision: Nedbring Time-to-market fra 360 dage til 70 dage

11 En offentlig styrelses vision: Nedbring tiden fra behov er kendt til udbud gennemført og leverancearbejde kan påbegyndes fra 11 måneder til 2 måneder.

12 Agile? Hvad er Agile

13 Det agile manifest Vi afdækker bedre måder at udvikle software på ved at gøre det, og ved at hjælpe andre med at gøre det. Gennem dette arbejde har vi lært at værdsætte: Individer og samarbejde frem for processer og værktøjer Kørende software frem for omfattende dokumentation Samarbejde med kunden frem for kontraktforhandlinger Reagere på forandringer frem for at fastholde planer Der er værdi i punkterne til højre, men vi værdsætter punkterne til venstre højere

14 Hvad er Agile? Daily Stand-up Sprint Backlog Product Backlog Co-location Kanban Cross-Functional Teams Scrum Customer Collaboration Continuous Integration Short Sprints User Story Pair Programming Test Driven Development Product Owner..

15

16 Det halvhjertede agile manifest Vi har hørt om nye måder at udvikle software ved at betaler konsulenter og læser Gartner rapporter. Igennem dette har vi fået at vide at vi skal værdsætte: Individer og samarbejde frem for processer og værktøjer og vi har obligatoriske processer og værktøjer til at kontrollere, hvordan disse individer (vi foretrækker udtrykket 'ressourcer ) samarbejder Kørende software frem for omfattende dokumentation så længe denne software er omfattende dokumenteret Samarbejde med kunden frem for kontraktforhandlinger selvfølgelig inden for rammerne af snærende kontrakter og striks ændringskontrol Reagere på forandringer frem for at fastholde planer forudsat at der foreligger en detaljeret plan for at reagere på ændringen, og at den følges detaljeret Det vil sige, mens emnerne til venstre lyder fint i teorien, er vi et enterprise firma, og der er ingen chance for at vi vil give slip på emnerne til højre. Kerry Buckley Half Arsed Agile Manifesto 2011

17 Succes med agile Det velfungerende team Product Ownership Ledelsesstøtte (Gøre det rigtigt) (Lave det rigtige) (Skab rammerne)

18 Lave det rigtige rigtigt

19 Hvad er et agilt team En gruppe som i fællesskab er ansvarlige for udførsel af arbejde fra en team-backlog Besidder nødvendige kompetencer til at udføre arbejdet Er selvorganiserende om opgaveløsning Bestemmer selv hvem der laver hvad Bestemmer selv hvordan produktet laves Ideelt set co-located

20 Få det simple til at virke først: Fx et scrum rammeværk Illustrationerne i denne præsentation kommer fra bogen Essential Scrum af Kenny Rubin udgivet i Mike Cohn Signature series, og er tilgængelige på

21 Det agile team Et Scrum team består af: Product Owner Udviklingsholdet Scrum Master Scrum Teams er: Selvorganiserende Cross-funktionelle. Team modellen i Scrum er designet til at forbedre og optimere: Fleksibilitet Kreativitet Produktivitet

22 Agile softwareudvikling fungerer på grund af selvorganiserende teams Men hvordan kan vi udvikle et værdiskabende selvorganiserende system?

23 Forstå værdien for virksomheden!

24

25 Faste domænespecifikke teams

26 Eksempel: Transportfirma - domæner Salg Planlæg Disponer Kør

27

28 Svært Doing Agile Praktikker og processer Being Agile Værdier og principper Daily Stand-up Individuals and interactions Co-location User Story Customer Collaboration Continuous Integration Test Driven Development Her vi starter Reflect and improve Empowered teams Openness Her vi skal være

29 hvordan kan vi udvikle et værdiskabende selvorganiserende team LEDELSESSUPPORT

30 Team - ledelsesopgaven My responsibility is to get my twenty-five guys playing for the name on the front of their shirt and not the one on the back - Tommy Lasorda manager LA Dodgers

31 Team - ledelsesopgaven Rammer: Retning: Rolle: Regler: Relationer: De organisatoriske rammer for teamet Målene og visionen, som teamet har for sit arbejde Ansvar i for arbejde sker i teamet Teamets grundregler for samspil og samarbejde De indbyrdes relationer og kommunikation

32 Skab et godt arbejdsrum Teamet bliver bombarderet af forskellige og konfliktende interesser Kunde 1 Interessent 2 TEAM Produktions -problem Regression Kunde 2 Interessent 1

33 Før: Vi har lidt udfordringer med integrationen, men vi har styr på det Alt er fint! Vi er på planen. Vi har brug for mere management til at koordinere integrationen. Vi leverede vores modul til tiden. Integration er langsommelig pga. fejl fra de andre teams. Vi ved at spec en er forkert, men vi implementerede det. Modulet er kodet og klar til test. Vi kan rette fejl senere.

34 Forandringsproces Forbedringsområder Udvid Definition of Done Forbedre kvalitet (automatisering) Forbedre samarbejde med kunde Vi vil automatisere integrationstest. Lederskab Åbenhed, læring mv. Vi forbedrer vores organisation hver dag. Lad os få en on-site kunde/bruger. Vi vil integrere testere i vores team. Integration er langsommelig pga. fejl fra de andre teams. Vi ved at spec en er forkert, men vi implementerede det. Modulet er kodet og klar til test. Vi kan rette fejl senere.

35 Personlig udvikling Folk skal lære: Forskellen på hastende og vigtig Tidsstyring Egen-motivation Normal læring af fagligheder skal stadig følge med

36 Uddelegering Beslutningskompetence distribueres. Hvordan??

37 Syv niveauer af uddelegering 1. Tell: træffe afgørelser som leder 2. Sell: overbevise folk om beslutninger 3. Consult: få input fra teamet før beslutning træffes 4. Agree: tag beslutning sammen med teamet 5. Advise: teamet rådgiver om beslutning 6. Inquire: teamet informerer om truffet beslutning 7. Delegate: ingen inflydelse, teamet beslutter

38 1. Flytte til nyt domicil 2. Skift fra vandfald til Scrum 3. Udvælgelse af nye teammedlemmer 4. Vælg logo til forretningsområdet 5. Beslut systemarkitektur eller komponentvalg 6. Sprint længde og leverancer 7. Kode guidelines og pairing

39 Det agile fundament Refinement Teamet Stand up Samarbejde Brugertest Det Gode Håndværk Fælles ejerskab Pair programming Komplet Team TDD Kodestandarder Versionskontrol Refactoring backlog Planning Poker Værktøjer Product owner Continuous Integration Automatisk test Enkelt design Stabilt tempo Automatisk deployment Sprint Planning meeting ScrumMaster Sprint Review Fælles værdier

40 KAFFEPAUSE

41

42 Agenda Intro til den tekniske rygrad i en agil verden Vi kommer omkring: Continuous Integration Continuous Delivery DevOps

43 Målet med det gode håndværk Understøtte forretningen i en foranderlig verden med høj grad af innovation Vi skal bidrage med kort time-to-market med leverancer i kendt, høj kvalitet med høj release-kadence

44 Målet med det gode håndværk 1. Flow 2. Feedback Teamet Kunderne / Systemerne i produktion

45 En historie der bliver bedre og bedre

46 Assumption is the mother of all screw-ups! CONTINUOUS INTEGRATION

47 Hvad er integration?

48

49 Princippet bag CI Integrer ved hver ændring og gør det derved til en non-event

50 Aktiviteter Continuous Compilation Continuous Testing Continuous Database Integration Continuous Deployment Continuous Inspection

51 Continuous Integration Developer Feedback loop Commit changes Source Control System Build report Continuous Integration Server Get latest sources Compile code, DB etc. Run tests Inspection and reports Deploy Package deliverables Good builds

52 Commit ofte Commit flere gange hver dag og endnu bedre flere gange hver time Med CI giver dette hyppig feedback Hyppig Commit og Update sikrer at teamet er konstant integreret ingen gemte overraskelser

53 Feedback-løkkerne Måneder Uger Dage Timer Minutter Roadmap Sprint Daily Scrum Continuous Integration Sekunder IDE, compiler, etc.

54 Jeg vil i gang! Hvor starter jeg? Opsæt source control Installer Continuous Integration Server Opsæt job som starter når kode checkes ind Start småt måske bare compile og oplev at få feedback fra hvert commit! Udvid herfra små skridt

55 You only need to test the things you want to work. TESTING -- Kent Beck

56 Testbyrden bliver større og større Sprint 1 Sprint 2 Sprint 3 Nye features B Leverede features B

57 Fremdrift forringes over tid Features / indsats Tid

58 Den Traditionelle Testpyramide

59 Den Agile Testpyramide

60 Konstant fremdrift Features / indsats Manuel test Automatisk test Tid

61 Agile Testing Quadrants Business Facing Supporting the Team Functional Test Prototypes Unit Test Component Test Exploratory Test Usability Test Performance Test Security Test Critique Product Technology Facing

62 Unit-testing Test korrekthed af individuelle komponenter En unit er den mindste testbare enhed, typisk en klasse eller metode

63 At implementere løsningen rigtigt OG At implementere den rigtige løsning

64

65 Egenskab: Server kaffe Baggrund: Givet der er kaffe i maskinen Og prisen for en kop kaffe er 10 kr. Scenarie: Indkast tilstrækkeligt beløb Givet jeg har indkastet 10 kr. Når jeg trykker på kaffeknappen Så laves en kop kaffe Scenarie: Indkast utilstrækkeligt beløb Givet jeg har indkastet 9 kr. Når jeg trykker på kaffeknappen Så laves ikke en kop kaffe

66 Behaviour Driven Development (BDD) Konkrete eksempler på systemets features Beskriver softwarens egenskaber og opførsel uden at detaljere implementeringen Læsbare af mennesker Eksekverbare af maskiner

67 Overordnet sammenhæng? Specifikation Binding System

68 Fra eksempel til kode Hver linje i et scenarie er et step Steps implementeres i kode og binder Gherkin beskrivelsen op mod systemet Eksempel i C#

69 User Story kløften? Færdig software

70 Specification by Example Kollaborativ specificering med eksempler Specifikation med eksempler

71 Test driven development (TDD) Ryd op Refactor Red Skriv fejlende unit test Green Lav lille ændring som gør test grøn

72 Behaviour Driven Development (BDD) Ryd op Refactor Red Skriv fejlende accept-test Refactor Red Green Brug TDD mikroprocess til at få accept test grøn

73 Klar til sprint og færdig User Stories specificeret med eksempler? Færdig? Klar? Automatiseret accepttest grøn?

74 Test på forskellige niveauer Klassisk unit-testing Verificerer individuelle komponenter (hvordan) Forlængelse af compileren Aktivt arbejdsredskab - driver udvikling af koden BDD / Specification by Example Fokuserer på hvad systemet gør, ikke hvordan Sikkerhedsnet / regression

75 Feedback-løkkerne Måneder Uger Dage Timer Minutter Sekunder Roadmap Sprint Daily Scrum Continuous Integration TDD, BDD, etc. IDE, compiler, etc.

76 Jeg vil i gang! Hvor starter jeg? Opret testsuite én unittest, så er du i gang Tilføj testsuiten til dit CI-job Nu er du i gang! Tilføj unittests for fremtidige rettelser Opbyg unittest kompetence i teamet Udarbejd en teststrategi for teamet, som gradvist vender testpyramiden på hovedet

77 PAUSE

78 Ship Early, Ship Often! CONTINUOUS DELIVERY

79 En historie der bliver bedre og bedre

80 Continuous Delivery Automatisering af idriftsættelserne Nedbrydning af siloer i forbindelse hermed Som med Continuous Integration: Gør det ofte og gør det dermed til en non-event Fokuserer på evnen til at kunne idriftsætte enhver ændring

81 One-click deploy igennem miljøerne Continuous Integration Auto Deploy til integrationsmiljø Click Deploy til systemtest Click Deploy til staging Click Deploy til produktion

82 Self-service deployment

83 Overblik GET COMPILE TEST INSPECT PACKAGE Continuous Integration Server Push Produktionsmiljø Testmiljø Stagingmiljø Deploy Server

84 Zero downtime deployments Nedbrydning af siloerne Fuld automatisering Ingen menneskehænder = ingen * nedetid ved deployment = deployments i almindelig kontortid * (eller næsten ingen)

85 Faser i deployment Pre-check Er passwords tilgængelige og korrekte? Er nødvendige systemer operationelle? Etc... Guard Deploy 100% automatisk - ingen hænder Post-check Services startet? Database online? Smoke-test Scan log for opstartsfejl Etc... Feedback

86 Jeg vil i gang! Hvor starter jeg? Lav et deploy-script! Start et deploy-script og automatiserer ét trin Anvend scriptet ved næste deploy Flyt lidt mere fra installationsvejledningen til deploy-script for hver deployment

87 You envision it, you build it, you deploy it, you run it! DEVOPS

88 En historie der bliver bedre og bedre

89 DEV OPS

90 Operations Development Programmører Designere Testere Product Owners UX Systemadministratorer DBA ere Netværksadminstratorer

91 DevOps: Feedback INSTRUMENTERING OG OVERVÅGNING

92 Hvem ringer til hvem ved fejl?

93 Indsigt med telemetri Hurtig feedback er en hjørnesten i den agile udvikling Story workshops giver hurtig feedback på krav Daily Scrum og Sprints giver hurtig feedback på fremdrift TDD, pairing og CI giver hurtig feedback på kvalitet Hvad med hurtig feedback fra produktionssystemerne (og testsystemerne)?

94 Indsigt med telemetri Feedback fra produktionssystemer etableres igennem opsamling og analyse af telemetri Telemetri er målinger (antal, hastighed, etc.), som sendes til et andet sted Sammenligneligt med logging, men hvor logging er ustruktureret er telemetri fuldt struktureret

95 Kommer alle vegne fra Infrastruktur: CPU, RAM, IO, etc. Applikationer: Alt på højt og lavt niveau: ordre placeret, login gennemført, web-side leveret, opslag i db, kald til service, etc. Processer: Deployments, incidents, etc.

96 Opsamling af telemetri Telemetri opsamles centralt Data gøres let tilgængeligt for alle

97 Alarmer ved usædvanligt mønster

98 Etabler telemetri i applikationer Gør det nemt at etablere telemetri i applikationer En enkelt linje skal gerne kunne gøre det, eksempel: Telemetry.Increment( MyApp.LoginSuccess );

99 Early failure detection Undgå store nedbrud ved at reagere på svage signaler Det er ikke et problem lige nu. Vi har opdaget en fejl i dette modul men hvis det sker samtidig med ( ) har vi et nedbrud

100 Jeg vil i gang! Hvor starter jeg? Afhænger af ambition Måske ELK Måske TICK

101 Den anden vinkel: Services Hvordan får jeg En ny database? En ny server? En klon af en eksisterende database? Indlæst en backup? Adgang til logs og lignende? Implementer self-service og automatisering for at optimere flow

102

103 Opsamling 1. Flow 2. Feedback

104 Opsamling, har vi ramt målet? Understøtte forretningen i en foranderlig verden med høj grad af innovation Vi skal bidrage med kort time-to-market med leverancer i kendt, høj kvalitet med høj release-kadence

105

106 Ressourcer