Større systemer og applikasjoner er som regel delt opp i horisontale lag. De øverste lagene er nærmest sluttbrukerne og de nederste lagene er nærmest databasen og de eksterne systemene. Lagene i midten håndterer forretningslogikk. 

Hvordan skal man gå frem for å utvikle et stort system? Vi tar for gitt at fossefallsmetoden er foreldet og at vi ser oss om etter en mer smidig (agile) prosess. I tillegg til Scrum og Extreme Programming (XP) finnes det en metodikk kalt “Feature Driven Development” (FDD) som er utviklet av Jeff de Luca og Peter Coad. 

Read more »

Dynamisk er fint. Dynamisk betyr bevegelig, effektivt og hensiktsmessig. Dynamisk er et plussord, og udynamisk er et tilsvarende minusord. Dersom man kaller en person udynamisk er det ikke for å rose, skryte og framheve positive egenskaper. Udynamisk er det når ting er helt fast definert, og man (nærmest vrangvillig) ikke ønsker å bevege på dem. Udynamisk gjør det vanskelig å gjøre annet enn det som er faktisk planlagt og avtalt - og gode idéer skal man helst ikke presentere underveis. For å sikre gode vilkår for innovasjon og kreativitet er det derfor viktig å være dynamisk.

I Tarantell leverer vi prosjekter. Prosjekter er (av andre enn oss) definert som å være “ikke-repeterende” arbeidsoppgaver. En form for dugnad, der man setter ned en arbeidsgruppe eller prosjektgruppe på tvers av linjeorganisasjonen; på tvers av ordinære ansvar og oppgaver. En prosjektgruppe har mandat til å løse én bestemt oppgave, innenfor gitte tidsrammer og budsjettrammer.

Et prosjekt kan i sin natur ikke gjentas. Om det kunne, ville det vært en prosess, en produksjonsprosess - som gjerne kunne inngå i en industribedrift. Måten man lager hamburgere på hos McDonalds er en slik prosess: man følger de samme stegene og kommer til det samme resultatet. Gang på gang, i et repeterende mønster.
I et prosjekt kan man gjenbruke erfaringen og kunnskapen som ligger igjen hos prosjektdeltakerne, men prosjektet i seg selv er for unikt til å gjentas steg for steg.

Gjennom denne ganske raske argumentasjonsrekken kan man trekke den slutningen prosjekter (som er unike) har behov for dynamikk (for å sikre nødvendig innovasjon og kreativitet). Dynamiske prosjekter burde derfor være et plussord som var mye brukt. Men det er det ikke. Istedet hører man mye om agile prosjektmetoder, smidighet, fleksibilitet og effektivitet. Dette er verktøy for å nå prosjektets målsetning - ikke for å påvirke prosjektets målsetninger. Den kreativiteten og innovasjonen man gir rom for er for å levere det beste resultatet - ikke for å omdefinere behovet.

Det er viktig å se denne forskjellen, slik at man legger til rette for den rette bruken av alle kreative krefter (og de er mange!). Prosjekt som arbeidsform er i de fleste tilfeller lagt opp som en relativt rigid og udynamisk gjennomføring. Man har fastsatte budsjettmidler, en fast tidsramme og et fast team av mennesker til å løse oppgaven. At teamet eller arbeidsgruppen har behov for en smidighet i sin gjennomføring er lett å se: Når alt annet er fastlagt, er det kun den mennesklige tilpasningsevne som kan dekke opp for uforutsette forhold (og de er det OGSÅ mange av!).

Finnes det da ikke dynamiske prosjekter der ute? Prosjekter der målsetningene defineres basert på en kontinuerlig læringsprosess?
De finnes. Men jeg er ikke sikker på om det gjør prosjektgruppens arbeid noe enklere. I dynamiske prosjekter vil man arbeide på et høyt abstraksjonsnivå; og man er nært koblet til forretningsstrategi og bevilgning av midler. Dette gir helt andre leveransetyper enn de man er vant til i mer rendyrkede utviklingsprosjekter. Man vil f.eks. levere en idé, et mandat, en beslutningsunderlag - kort sagt et premiss for å gjøre den endelige leveransen. Og det er noe ganske annet enn en å komme til en sluttført løsningsleveranse.

For å reparere myten om at alle IT-prosjekter leverer a) For Sent, b) Over Budsjett og c) Med Irrelevant Funksjonalitet er den gjengse oppfatning at svaret har ankommet. Enter Scrum.

Med hurtige iterasjoner, fokus på burn down og team som ikke konstant forstyrres av endrede krav er framtiden allerede ankommet. Veien blir målet, vi reiser sammen og alle ender på samme sted, på samme side i boken, funksjonaliteten er som avtalt, kvaliteten er i henhold til planlagt nivå - og tid og kostnader er under kontroll.

Andre, gammeldagse metodeverk konsentrerer seg om å planlegge før man går til aksjon - også kalt fossefall. Noen helt klare ulemper med dette er at fossefallsprosjekter har en tendens til å vare lenge, og de kravene man hugde i steintavlene ved prosjektets start er kanskje ikke like viktige lenger. Kostnadsrammene er fastsatt, og rigid endringshåndtering sørger for at det er vanskelig å omprioritere kravene underveis. Dersom man allikevel velger å endre kravene blir tidsrammene forskøvet og man må tilføre mer budsjettmidler. Fordelen, vil mange hevde, er at det er langt lettere å knytte dette til standard kontrakter og juridiske avtaleverk.

I hverdagen oppleves det slik at fossefallsprosjekter betinger en god del støtteleveranser. Dokumentasjon. I utgangspunktet vil det være en god idé å dokumentere sine planer og veivalg, slik at partene er enige om hvilke prioriteringer prosjektet har gjort. Men ofte er det slik at: a) leverandøren må sette av produksjonskapasitet (les: programmerere) for å dokumentere, og b) oppdragsgiver ikke har kompetanse eller tilgjengelig tid til å vurdere planene.

Dersom man i korte iterasjoner KODER i stedet for å dokumentere vil man være produktiv tidligere, og det blir enklere og mer oversiktlig for oppdragsgiver å ta stilling til resultatet, og å prioritere den viktigste funksjonaliteten. At standard kontraktsverk ikke ennå støtter denne partnerorienterte arbeidsformen skal jeg ikke komme nærmere inn på her.

Men: I prosjekter av strategisk natur vil ikke løsningsområdet være tydelig. Målsetningen kan være å øke inntekter; å redusere kostnader; å søke nye forretningsmuligheter. Å starte å kode noe på dag 1 vil i slike tilfeller være en relativt sikker måte å ødsle med tid og penger på. Man vil ikke kunne vite om man er på riktig plattform, med riktig personell, og man kan bare gjette på hva kravene til løsningen kan være.

Ingen fare, sier scrummerne. Scrum kan brukes til alt mulig, også strategiarbeid. Dette er selvsagt 100% korrekt, gitt at HELE prosjektet dreier seg om strategi. Men dersom første iterasjon dreier seg om strategisk fundament, andre iterasjon vil dreie seg om plattform- og leverandørvalg, tredje iterasjon om etablering av infrastruktur etc. har jeg følgende påstand: Dette er fossefall. Og det er fossefall med en uhensiktsmessig metode. Teamet vil måtte endres fra iterasjon til iterasjon, backlog kan ikke videreføres, koding må avvente anskaffelse og leverandørvalg etc. I slike tilfeller vil man være langt bedre tjent med å splitte opp i flere og mindre prosjekter. Eller å benytte en velprøvd fossefallsmodell med faseinndelinger, formaldokumenter og beslutningspunkter.

At Scrum inneholder samspillsregler og oppmuntrer til god internkommunikasjon i prosjektgjennomføring kan bare applauderes. At man har fokus på produktivitet og klare ansvarsforhold likeså. Men som verktøy må det være tilpasset oppgaven.

Når skapets posisjon skal diskuteres er det noen man skal lytte til mer enn andre. Når skapet heter webapplikasjoner og webteknologi så hører jeg etter når Martin Fowler og David Heinemeier Hansson snakker. Når ovenfornevnte størrelser snakker sammen og moderator heter Scott Hanselman, da setter jeg iTunes på repeat.
Read more »

I artikkelen Classic Mistakes Enumerated beskriver Steven C. McConnell en rekke klassiske feilgrep som stadig blir gjort i utviklingsprosjekter. Boken som artikkelen er hentet fra ble skrevet for over 10 år siden, men er skremmende relevant fortsatt. En av grunnene til at det stadig blir gjort slike klassiske feil er at de har en besnærende appell. For eksempel: Er prosjektet forsinket? Sett flere personer på prosjektet! Ønsker du å redusere tidsforbruket i prosjektet? Gjør prosjektplanen mer aggressiv!

Selv om man oppdager og unngår slike feil, vil man ikke nødvendigvis få et raskt og effektivt utviklingsløp, sier han. Men ved å gjøre disse feilene vil man få et lenger prosjektløp enn nødvendig.

Read more »

Scott W. Ambler presenterer sin strategi for å integrere brukerorientert design(UCD) i agile metodikk. Det redegjøres kort for de grunnleggende sidene ved agile utvikling og UCD. Han avliver en del myter rundt begge disiplinene før han gjør rede for henholdsvis modellering av brukeropplevelse og brukertesting i prosjekter som kjører agile. 

Sett med mine Focus Dailies® så er dette morsom og viktig lesning. Agile metodikk har gjerne et utviklerperspektiv hvor den enkelte utvikler igjennom f.eks. personas eller kundekontakt ivaretar brukervennligheten i løsningen. Dette er vel og bra men erstatter ikke kvaliteten de tyngre UCD metoder og utøvere produserer. Ambler foreslår gjensidig tilnærming og kompromisser men tar han fortsatt for lett på UCD? - Kjør debatt.

http://www.agilemodeling.com/essays/agileUsability.htm