Agile udviklingsmetoder
De senere år er der kommet mere fokus på Agile udviklingsmetoder, men hvad er Agile udviklingsmetoder og hvad kan vi bruge det til.
Når vi pragmatisk taler om Agile udviklingsmetoder, taler vi om:
• Konceptet og principper for udvikling af software
• Projektstyringsmodellen
• Arkitekturen bag software løsningen
• Det tekniske design bag den implementerede løsning.
Historien bag Agile Udviklingsmetoder starter i USA.
I 2001 samledes 17 fremtrædende software designere og konkurrenter indenfor software udvikling i Snowbird ski-internatet i Utah, for at diskutere fællesnævnere for deres metoder.
Til mødet i Snowbird blev ideerne bag disse metoder forenet under et fælles set af værdier, som er udtrykt i det Agile Manifest. Udover manifestet fremsatte man også 12 agile principper, som uddyber værdierne. Agil softwareudvikling består altså ikke kun af udviklingsmetoder og praktikker, men også af værdier og principper.
Agile udviklingsmetoder er ikke specifikt rettet mod SAP, men det skal ikke hindre os i SAP verdenen at anvende konceptet.
Du kan læse mere om dette møde og organisationen bag på denne web adresse http://agilemanifesto.org.
Figuren viser, at agil softwareudvikling som koncept kan opdeles i 4 dele: værdier, principper, metoder og praktikker. Værdier er de vigtigste men også mest abstrakte og dermed placeret øverst i pyramiden. Jo længere man bevæger sig ned, jo mere konkret bliver det.
Der findes adskillige projekt styrings metoder, som understøtter agil softwareudvikling og som tager udgangspunkt i manifestet fra den internationale organisation Agile Alliance.
Med agile metoder ønskes en minimering af risikoen og maksimering af produktiviteten ved at udvikle software gennem en kort iterativ proces. Scrum og Extreme Programming (XP) er to af de mest brugte agile metoder, men der findes også mange andre – og agilitet, som koncept, kan også benyttes til udvikling af de mere traditionelle metoder. Business Process Management (BPM) er et ledelses syn som understøtter agil software udvikling gennem det, at identificere de forretningsmæssige processer softwaren skal løse. BPMN er den notation som anvendes i forbindelse med design af forretnings processerne og BPMS er den tekniske platform i hvilken man afvikler forretnings processerne. I SAP kan man med fordel anvende ABAP Objects til udvikling af såvel BPMS som selve de forretningsmæssige processer.
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
We follow these principles:
1. Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
2. Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.
3. Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
4. Business people and developers must work
together daily throughout the project.
5. Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
6. The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence
and good design enhances agility.
10. Simplicity--the art of maximizing the amount
of work not done--is essential.
11. The best architectures, requirements, and designs
emerge from self-organizing teams.
12. At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.
Agile principper
Der er i alt 12 Agile principper, og de understøtter de 4 agile værdier i Manifestet. For eksempel understøtter princip nr. 3 den agile værdi nr. 2, idet princippet bl.a. udtrykker, at software, og altså ikke dokumentation, skal afleveres tidligt og hyppigt. Det vil sige, at følges princip nr. 3, så støttes den agile værdi nr. 2. Men principperne er dog stadig for abstrakte til at kunne omsættes direkte til praktisk brug. Det er her metoder og praktikker kommer ind i billedet.
Agile metoder
Agile metoder kan betragtes som en konkretisering af de agile værdier og principper. Dvs. at værdier og principper operationaliseres til praktisk brug, idet de gøres specifikke. Metoder fortæller altså brugeren, hvilke skridt der skal tages for at gennemføre et eller flere principper. Agile metoder kan ofte dekomponeres til en række praktikker, der mere uniformt beskriver de enkelte skridt.
Agile praktikker
Agile praktikker er en detaljeret beskrivelse af, hvordan et eller flere principper realiseres. For eksempel i XP gennemføres princip nr. 3 gennem praktikken "Weekly Cycle". Kort sagt siger praktikken, at en iteration (identificering af krav, design, konstruktion, test og kunde-feedback) strækker sig over en uge. Ved at følge praktikken er man altså i stand til at aflevere små funktionelle dele af software til kunden tidligt og kontinuerligt (hver uge). Derved gennemføres princip nr. 3, og værdien i manifestets 2. sætning overholdes.
Hvad kan man så bruge det til?
Hvis metoder og praktikker konkret beskriver, hvordan vi skal udvikle software, hvad skal vi så med de agile principper og værdier? Ja, netop fordi metoder og prak-tikker er konkrete, vil det ofte være nødvendigt at tilpasse dem til det miljø og den situation, de skal virke i. Som eksempel vil praktikken "Weekly Cycle" ikke være så fornuftig at følge stringent, hvis udviklerne i forsøget på at nå deadlines på en uge bliver overanstrengte og dermed svækker kvaliteten af softwaren. I det tilfælde vil princip nr. 8 og 9 blive brudt. Her vil det måske være fornuftigt at øge størrelsen på en iteration fra en uge til 14 eller 30 dage. Praktikken vil stadig realisere princip 3, men udviklerne kan nu bedre følge med, hvorved princip 8 og 9 også overholdes. For at forstå agil softwareudvikling, er man derfor nødt til at forstå principperne, hvordan de understøtter de 4 agile værdier samt sammenhængen imellem dem. Hermed kan man tilpasse praktikker og metoder til den pågældende situation og stadig udføre agil softwareudvikling.
Forskellen mellem traditionel og Agil udviklingsmetoder
Den helt store forskel mellem traditionelle udviklings koncepter og Agil udviklingskonceptet er den meget korte udviklingstid. Hvor traditionelle projekter har en projektcyclus på 1-3 år, arbejder man i Agil projekter med en projektcyclus på ganske få måneder. I det traditionelle projekt er der i princeippet kun ét gennemløb, men ofte vil der være en opfølgning på projektet, hvor der samles op på udeståender og løses problemer. I det Agil projekt har man mange iterative projekt gennemløb. Fordelen er, at projektets scope hele tiden kan forandes idet vi for hvert gennemløb kan lægge en ny plan, foretage nye prioriteringer undvige problemer identificeret under det sidste gennemløb.
At gennemføre Agil softwareudvikling er ikke bare en dans på roser, det stiller meget store krav til både kunde og leverandør. Projektledelsen og herunder process ejeren samt arkitekten, skal være estremt gode til at prioritere hvilke processer, der udvikles hvornår. Tilsvarende stilles der store krav til projektdeltagerne som har stor frihed og dermed også et stort ansvar.
I Agile softwareudvikling vil man også stå over for den udfordring, at mens projektdeltagerne har fokus på én iteration af projekt gennemløbet, vil forretningsressourcer og arkitekter have fokus på næste gennemløb. Forretningsressourcerne indgår endda samtidigt som testere på den igangværende itereation. Men kan man håndtere disse dobbeltløb øges angagementet og acceptet både i forretningen og i projektet.
BGS Consulting har været med i et success projekt, hvor der blev anvendt Agile Udviklingsmetoder, BPM og ABAP Objects. Projektet bestod i reimplementering af eksisterende processer samt udvikling af nye processer. I forbindelse med reimplementeringen, blev det besluttet at modernisere arkitekturen og baseret udviklingen på Business Process Management og egen udviklet BPMS system. Projektet blev samlet set leveret til aftalte tidspunkt og til den aftalte pris. Ved review kunne vi konstatere omfattende reduktion i antallet af kodelinier, samt en øget og ensartet kvalitet af den leverede løsning.
