Agil softwareudvikling i praksis. v/ Thomas Schou-Moldt, Lead Architect, Miracle A/S

Transkript

1 Agil softwareudvikling i praksis v/ Thomas Schou-Moldt, Lead Architect, Miracle A/S

2 Thomas Schou-Moldt, Lead Architect Ansat i Miracle A/S (siden 2008) Arbejder som arkitekt / tech lead / teknisk projektleder Siden 2008 på to store enterprise-projekter ( timer) og to mindre projekter ( timer), samt diverse rådgivning, løsningsdesign, undervisning mv partner i softwareudviklingshus, hvor udviklingsmetoden var baseret på XP Deltager desuden i arbejdet med udvikling af Miracles udviklings- og projektmodel Mail: [email protected] Mobil: LinkedIn:

3

4 Miracle Totalleverandør af it-ydelser: Drift, implementering og udvikling. Stiftet i Miracle i tal /2012 Ansatte: 114 fuldtidsstillinger. 150 kontraktansatte. Omsætning: 140 mio. (+100 mio. BuddyShop) Aktive kunder: 300+ Aktiviteter i DK: København, Fyn, Aarhus, Esbjerg & Aalborg Aktiviteter i udlandet: Island, Sverige, England, Finland & Norge Miracle i Danmark Miracle A/S Miracle BuddyShop Miracle Hosting Miracle Breweries Konsulenter, rådgivning og projekter Freelancere (Specialists & Capacity) Remote drift eller hosting i eget center Eget bryggeri

5 Dette er måske den vigtigste bog, der nogensinde er skrevet om agil vs. vandfald. Muligvis fordi det stadig er den eneste

6 Andre gode bøger Mike Cohn: Mary Poppendieck: Kent Beck: Kent Beck: Craig Larman: Agile estimating and planning Leading Lean Software Development Test Driven Development: By Example Extreme Programming Explained: Embrace Change, 2nd Edition (og andre XP bøger) Agile and Iterative Development: A Manager's Guide

7 Hvad er forskellen på teori og praksis? I teorien er der ingen forskel, men i praksis er der!

8 Hvad er en metode? En formuleret fremgangsmåde, struktureret i faser, samt begrundet og dokumenteret i hele forløbet Pre-metode æra (60 erne) - Ad hoc udvikling (cowboy-kodning) Tre metode generationer - Struktureret (Yourdon, DeMarco, o.a.) - OO ( Booch, Jacobson, o.a.) - Agile (Beck, Highsmith, o.a.)

9 Projektstyring

10 Scrum Et simpelt framework til håndtering af komplekse problemer 3 roller - Product Owner, Scrum Team, Scrum Master 3 ceremonier - Sprint Plannning, Daily Scrum, Sprint Review / Retrospective 3 styringsdokumenter - Product Backlog, Sprint Backlog, Burndown Chart

11 Extreme Programming (XP) En metode med det erklærede formål at udvikle software, som kan leveres til tiden, opfylde kundens behov, fungere, vedligeholdes og udvides. 5 værdier Kommunikation, feedback, enkelhed, mod, respekt 14 principper Flow, kvalitet, baby steps, forbedring, refleksion mv. 24 praksisser Test first (TDD), continuous integration, pair programming, incremental design, shared code, stories mv.

12 Lean Et optimeringsparadigme

13 Rather than work forward from technology or a complex strategy, work backwards from the needs of the customers and build the simplest product possible Eric Ries - The Lean Startup

14 Implementing a Lean software delivery system Visualize Work (to identity the value stream) Limit the WIP (work-in-progress) (to establish an effective pull-mechanismen) Make policies explicit Manage and measure flow (to visualize consequences of decisions) Identify improvement opportunities (to establish a culture of continuous improvement)

15 Scrum og Lean Scrum kan implementere lean værdier... Value Product owner Product backlog Value stream Continuous flow Level pull Sprint backlog Three ceremonies Persue perfection Scrum Master Burndown chart Review / retrospective

16 Agile metoder svagheder og styrker XP Styrker Fokus på tekniske principper Kunden laver prioriteringerne, udviklerne laver estimaterne Gode feedback muligheder Svagheder Kræver tilstedeværelse af kunde Fortrinsvis verbal dokumentation Stiller store krav til deltagerne (dygtige generalister) Scrum Selvstyrende teams Gode feedback muligheder Kunden er involveret Prioriteringer baseres på forretningsværdi Har et begrænset scope Ingen fokus på tekniske principper Kan være svært at få kunden til give unikke prioriteringer af alle krav Lean Fokus på projektets ROI Eliminering af spild Ingen fokus på tekniske principper Kræver mange målinger TOC (Theory of Constraints) kan være et kompleks begreb at jonglere med

17 The Miracle Cure.

18

19 Ingen one-fits-all løsninger Ingen religion eller metode-krige Vandfald er en acceptabel mulighed, men sjældent en realistisk mulighed Afbalancering af agile og disciplin, baseret på modenhedsvurdering både af teamet og af kunden! Mennesker er den vigtigste ressource: den rigtige teamsammensætning afgør ofte om et projekt får succes eller fiasko

20 Sund fornuft Nej Ja Ja tak! Procesdisciplin Ja Nej Kvalitet Kreativt kaos Meningsløst bureaukrati Meningsløst kaos

21

22 Udfordringer ved agil softwareudvikling

23

24 De kritiske parametre Projektets størrelse Afklaret forhold til præmisserne ved agil softwareudvikling Kundens modenhed Leverandørens modenhed Udviklingsteamets sammensætning Stærk engagement/involvering fra kunden Kommunikation, kommunikation, kommunikation! Klar projektvision = fælles ejerskab

25 Case #1 Stor organisation, mange interessenter til projektet Forretningskritisk system Stort budget, ca timer/år ( + inhouse omkostninger) 1-1½ år fra start til pilotrelease Flere udviklingsteams, ca. 20 udviklere/teknikere + tilsvarende antal PM, QA og specifikationsfolk Ingen kravspecifikation (1:1 konvertering), begrænset dokumentation, men adgang til væsentlig inhouse viden Stærk projektejer Uklar projektvision

26 Case #2 Mellemstor organisation, få interessenter til projektet Semi-forretningskritisk system Begrænset budget, ca timer (v.1) 6 mdr fra start til endelig release (v.1) Ét udviklingsteam, 5 personer + en PM/Scrum Master Ingen struktureret kravspecifikation, men grundig beskrivelse af krav/ønsker/muligheder Engageret projektejer Klar projektvision

27 Super simpelt taskboard in action

28 Digitalt taskboard (JIRA/GreenHopper)

29 Kanban board Courtesy of Jeff Anderson, Toronto

30 Ekstra slides

31 Estimering

32 Om Unittest TDD? Test as you go! Gode unittest = bedre softwarekvalitet Dårlige unittest? Så lad være!

33