Denne side er en gennemgang af en række af de proces fokus områder der arbejdes med i Agilis Software. Informationerne her er meget operationelt orienteret, dvs. hvordan får man tingene til at fungere i praksis. Dette er fordi det erfaringsmæssigt er den største udfordring i forbindelse med procesforbedringer: det er forholdvis let, at forstå principper i en udviklingsmetode som f.eks. SCRUM, Unified Process eller XP, men det er straks sværere at få implementeret disse metoder effektivt i dagligdagen. Vi vil også meget gerne hjælpe med generel sparring og coaching i forhold til agile processer men har den holding, at den bedste måde at arbejde med dette er i forbindelse med konkrete problemstillinger i dagligdagen.

Fælles projekt

Klassisk projekt	Simpel agilt projekt	Integreret agilt projekt

Klassisk projekt

Et kritisk element i et effektivt udviklingsprojekt er, at man i projektet har en fælles forståelse for hvad projektet består af. Dette lyder måske umiddelbart som en triviel iagttagelse, men i praksis ser man tit, i hvert fald i mere klassisk opbyggede projekter, at projektmedlemmer er meget fokuseret på deres egne arbejdsområder, og ikke har den store indsigt eller interesse for det samlede projekt. Dette skyldes primært, at der ikke er effektive mekanismer på plads til at dele det samlede projektbillede mellem projektmedlemmerne. Resultatet er, at folk i vid udstrækning arbejder i deres egen små siloer med sporadiske møder til indsamling af status og uddelegering af opgaver.

Simpelt agilt projekt

En af de store fordele ved at arbejde i et agilt projekt er fokuset på at opnå et samlet billede af hvad meningen med projektet er, hvordan man når derhen og hvordan det står til. Til at løfte denne udfordring findes agile methologier som Scrum, XP med proces elementer som standups, pairing, teams, sprints, backlogs osv. der alle er forsøg på at udvikle et simpelt fælles billede af 'vores' projekt. Dette er i høj grad en forbedring i forhold til tidligere tider, da man nu grundlæggende har en fælles forståelse af hvad man laver.

Problemet i denne sammenhæng er, at det mere detaljerede og komplette billede af projekt informationerne stadigvæk ikke er fælles. Det være sig ting som kode, dokumentation, planer, opgaver, QA, bygning, test osv. Disse elementer er de områder vi arbejder med i dagligdagen, og indeholder det mest præcise og opdaterede billede af projektet. Man kan sige, at de projektmodeller man arbejder med i sine standups/sprintmøder/backlogs er et forsøg på at give et forsimpelt overordnet billede af projektet, som man kan arbejde effektivt med i det samlede team. Udfordringen her er, at disse forsimplede modeller ikke bliver bedre end forståelsen af den detaljerede model den bygger på. Eksempler er:

• Backlog: Backloggen er afhængig af, at der er en god forståelse mellem team og kunde af hvad det egentligt er man skal lave, og teamet skal have lavet en god operationel nedbrydning af de ting der skal laves, dvs. opgaverne skal kunne afsluttes, indehold velspecificerede resultater, indeholdes i interationer/sprints, kunne afvikles effektivt osv. Dvs. for at kunne vedligeholde en god backlog, er det yderst nyttigt at have adgang til et fælles, detaljeret og lettilgængeligt billede af de forstående og igangværende opgaver/features/krav (issuemodel).
• Standups: Et af de klassiske problemer man oplever med standupmøderne er, at opgaver tilsyneladende bliver løst som de skal, men den samlede, velfungerende løsning materialiserer sig ikke. Dette er dels et symptom på, at detailnedbrydning af de features der skal laves ikke er præcis nok, og dels afspejler at kriterierne for hvad det betyder, at en opgaver er 'færdig' (done) ikke er fyldestgørende. Her er det igen en meget stor hjælp hvis man har adgang til et fælles detaljeret billede af de forliggende opgaver. Dette opgave billede skal så kobles med præcise og fyldestgørende informationer om hvad status er på de enkelte opgaver.
• Erfaringopsamling/retrospektives: Man bør løbende under et projekt samles for at reflektere over hvordan det går og hvad der kan forbedres. For at kunne overveje dette på et effektivt grundlag, har man igen brug for et samlet billede af de forskellige projekt aspekter på et højt detaljeringsniveau. Her skal informationerne igen være tætkoblet, da det typisk er i områderne mellem de forskellige softwaredomæner, at problemerne opstår, f.eks. at krav, test, opgaver, kode etc. ikke afspejler det samme projekt.

Integreret agilt projekt

I det fuldt integrerede projekt arbejder alle direkte i den samme informationsmodel for projektet, blot med forskellige fokuserede views, der afspejler lige nøjagtig det område man arbejde med for nuværende. Dette fokuserede view skal selvfølgelig afspejle alle de projektmæssige aspekter, der er relevant for lige den ting/feature/bugs man sidder med, dvs. bl.a. opgaver, bygs, interessenter, dokumentation, tests, krav, planer, infrastruktur osv. På den anden side skal alle andre projekt informationer kunne filtreres væk for at kunne arbejde med så simpelt en arbejdskontekst som muligt. Samtidig skal det være let at skifte fokus, dels til andre elementer af projektet, men også at 'zoom'e ind eller ud i projektmodellen, så man kan forøge detaljeringsgraden eller overblikket.

Fordelen ved sådan en view centrisk samlet informationmodel er:

• Konsistens: Da alle arbejder på den samme model, opstår der ikke så let inkonsistenser mellem informationer i forskelle projektaspekter
• Større synlighed: Som illustreret på figuren øverst bliver det muligt direkte at eksponere projektets aspekter til personer udenfor udviklingsteamet som f.eks. programleder, kunder, brugere osv.
• Undgår redundans: Når først information om et projektaspekt (feature, opgave, personinfo, osv.) er tilføjet en gang til projektmodellen kan efterfølgende brugere af denne information bare tilføje (eller linke) det til de relevante views, i stedet for at skulle skrive sin egen version af hvad det drejer sig om.

I praksis er den eneste effektive måde at kunne arbejde med sådan en fælles model, at benytte sig af et brugervenligt og meget integreret værktøjssetup, som f.eks. den vifte af værktøjer vi arbejder med i Agilis. Nedenfor er vist eksempler på hvordan de forskellige værktøjselementer fungerer som fokus punkter for forskellige projekt aspekter. Bemærk, at i praksis vil det ikke være umiddelbart klart, at det er forskellige værktøjer man benytter, da de tilgåes samlet gennem enten en webbrowser ellers ens IDE'er.

Dokumentation Confluence	Opgaver JIRA	Automatisk systemtest GreenPepper	Continuous Integration Bamboo

Fokus på mennesker - ikke værktøjer

Selvom det måske kunne lyde som om, at fokus i det fuldt integrerede projektsetup er flyttet fra teamet til de værktøjer man benytter sig af, er dette ikke hensigten. Resultatet af at bevæge sig i retning af et mere integreret projekt skulle gerne være, at fokus for størstedelen af teamet flytter sig fra, at skulle bruge mange ressourcer på at lede efter informationer i forskellige dokumenter samt kæmpe for at holde disse informationer opdateret til, at man let finder de informationer man har brug for, og ikke er mere end et klik fra at give ens eget bidrag med. Det er klart, at der skal bruges en masse ressourcer på opsætning, vedligehold og coaching i forhold til de mere avanceredet kollaborative værktøjer vi arbejder med i Agilis, men dette arbejde kan begrænses til en meget lille skare af organisatoriske nøglepersoner og Agilis konsulenter.

Resultatet er, at man med de værktøjer vi benytter i Agilis, har væsentligt større overskud til at fokusere på det vi som mennesker er bedst til, nemlig at drive den kreative proces til håndtering af kundernes forretningsmæssige udfordringer.

Ikke integreret projekt Masser af manuelt arbejde med informations opsøgning og vedligehold Isoleret i siloer. Undgår dokumentation	Integreret projekt Effektiv informationssøgning og vedlighold Overblik. Overskud til at fokusere på at skabe forretningsværdi

Fokus på nuet

Selvom det er vigtigt at kunne planlægge et projekt fremadrettet og gå tilbage i tiden for at se hvordan projektet så ud tidligere, er det projektets tilstand her og nu, der er langt det vigtigste. Hvis der ikke er styr på hvordan projektet har det på et givet tidspunkt så man kan prioritere de umiddelbare opgaver, og det umuligt at forudsige hvordan projektet vil opføre sig på længere sigt. Derfor skal man altid starte med at kigge efter årsager til problemer og forbedringer af disse, fremfor at bruge for meget energi på fremtidige aktiviteter og eller periodevise forbedringstiltag. Eksempler på dette er:

• Teste løbende og kontinuert i stedet for ved sprint/iterationsafslutningen.
• Lad være med at forsøge at planlægge fremtidige versioner for detaljeret, men koncentrerer dig om at overskue den nuværende version.
• Planer er foreløbige, vær klar til at opdatere disse så snart du kan se at projektets tilstand afviger fra det planlagte.

Kontinuerlig udvikling

• I stedet for at lave en topdown nedbrydning af projektet i 'projekt -> versioner -> iterationer -> sprints -> dagsstatus' hvor man placerer sine test-, design-, dokumentations- og styringsaktiviteter i forhold til disse 'hak' i projektforløbet, bør man forsøge at trække så mange af disse mere overordnede projektaktiveteter ned til at være en del af den løbende udvikling. De mere langsigtede nedbrydninger af projektet kan så opbygges på denne baggrund. F.eks. bør sprints/iterationer ikke være andet end en logisk samling af funktionaliteter. Aktiviteter som test, deployment release, statusopdatering aktiviteter skulle gerne kunne holdes på et minimum her, da disse hensyn så vidt muligt bør være dækket i den løbende udvikling.

Mere konkret betyder dette bl.a. at:

• Tests skrives, mens funtionalitet udvikles.
• Opgave status vedligholdes, mens der udvikles.
• Opgave beskrivelse vedligeholdes så snart man bliver klogere på hvad der foregår.
• General kvalitetssikring fortages undervejs i udviklingen.
  En god metode til at få koblet disse aktiviteter så tæt på den løbende udvikling som muligt er at spørge sig hver gang man har en aktivitet eller hensyn, der skal håndteres:
  • Fremadrettet: Har dette værdi på nuværende tidspunkt eller kan jeg vente med det ?Det drejer sig for om design, analyse, dokumentation, krav, kode osv.
  • Bagudrettet: Kunne jeg med fordel have gjort dette, da jeg lavede selve funktionaliteten ? Det kan være systemtest, dokumentation, review, redesign osv.

Det er absolut ikke en triviel opgave at få trukket QA, dokumentations, test og opgavestyringsaktiviter ind i den daglige udvikling. Udfordringerne er bl.a.

• Kan kræve en hel del arbejde for at kunne understøtte dette til bl.a. automatisering, rapportering og værktøjsimplementering.
• Kræver at udviklerne har fokus på en bredere del af projektet end bare programmering.
• Kræver at ikke-tekniker som tester, QA'er, projektleder kunde skal arbejde med informationer som i højere grad er præget af at være tæt på selve applikations udviklingen.
• Tendens til mere komplekse(detaljerede) status og QA informationer.