Er du klar til å være agile?

Scrum er blant de raskest voksende utviklingsmetodene.

Men mange it-prosjekter krever nødvendigvis ikke nyutvikling av programvare.

Er agile en god tilnærming for alle prosjekter?

Nødvendigvis ikke. Vi bør stille oss fire spørsmål før vi bestemmer oss for å bruke agile. Hvis ikke disse fire spørsmålene kan besvares enkelt, er prosjektteamet antakelig ikke klare for å adoptere agile.

1. Hva er brukerhistoriene? For eksempel har brukere av bankløsninger en brukerhistorikk som forteller om tidligere transaksjoner på sin konto. Agile-manifestet vektlegger at enkelte bruker systemet bedre enn opprinnelig beskrevet. Kan vi finne disse beretningene er vi bedre rustet til å bygge et funksjonelt og bedre system.

Det er også viktig å vite om vi beskriver interaksjoner med et system, en egenskap eller et komponent. Interaksjonen hos en bedrift som migrerer fra et egenutviklet ordresystem til hyllevare, ligger for eksempel mellom sluttbruker og system.

2. Hvordan skal vi organisere arbeidskøen (backlog)? Skal prioriteringen ligge på historier om arkitektonisk usikkerhet og kompleksitet, eller på brukererfaringer som senere rapporter baseres på? Organiseringen av denne informasjonen har stor innvirkning på prosjektets retning.

I enkelte tilfelle er kroneverdi tatt med i brukerhistorikken - for eksempel for å avdekke nye forretningsområder. I andre sammenhenger er brukerhistorikk rangert etter hvor mange sluttbrukere som har etterspurt en bestemt funksjon eller opplevd et bestemt problem.

Brukerhistorier fra ETL-systemer (Ekstraher, Transformer, Last) er imidlertid veldig annerledes. I ETL beskrives brukernes interaksjon med en applikasjon, registrerer agile rutiner med å hente data fra eksterne kilder. Det er viktig å huske at den sekvensielle oppbyggingen av arbeidskøen her typisk baserer seg på filstrukturer nedarvet fra den eksterne kilden.

3. Hvordan blir oppgavene inndelt? Kan vi ved å gruppere brukerhistorier utlede og definere oppgaver et Scrum-team kan gjennomføre i en enkel Sprint eller kortoppgave, og gjennom denne prosessen utvikle en fornuftig løsning? Når vi utvikler nye applikasjoner, inkluderes aktivitetene design, koding, testing, konstruksjon og integrasjon. I andre tilfeller dreier de seg om reeingineeringsaktiviteter som ekstraksjon, transformasjon og lasting. Eller kanskje oppgaver som kan gjennomføres med 3GL- eller CASE-verktøy.

4. Hva er vår definisjon av "ferdig"? Av de fire spørsmålene krever dette grundigst vurdering, som vurderinger av testrutiner og metoder, og hvorvidt et separat testteam er påkrevd etter Scrum-teamet.

Alle prosjekter er forskjellige og har forskjellige indikatorer for når de er ferdige. I de fleste tilfeller inkluderer ferdigstillelsen av et prosjekt dokumentert historikk der brukere har vært i stand til å gjennomføre en bestemt oppgave. I det innledende bankeksempelet, er prosjektet ferdig når kunden ser sin kontohistorikk.

Vi kan definere to nivåer av "ferdig". Mange mennesker vil være enig i at et prosjekt er ferdig når 80 prosent av salgsdataene problemfritt tilflyter systemet, og vi har et grunnlag for noenlunde troverdige produkt- og markedsmessige beslutninger. Når systemkvaliteten forbedres videre, søker vi mot det neste nivået av "ferdig" - 100 prosent.

Kan disse fire spørsmålene besvares enkelt, er agile antakelig riktig for prosjektet. Elementer som læringskurver, modningstid, organisasjonskultur og ressurstilgjengelighet har imidlertid også betydning for prosjektets vellykkethet.

Jayajyoti Sengupta, nordisk sjef i konsulentselskapet Cognizant