De Kontinuerlige

Jeg elsker å lage programvare! Jeg vil levere forretningsverdi effektivt over tid. Jeg ønsker å dele med deg, mine tanker om hva som skal til. Denne bloggposten dreier seg om kontinuerlig prosesser, hvilke jeg føler er viktigst og hva de gir av verdi. Til slutt settes det hele sammen, hvor jeg ønsker at du som leser får et nytt perspektiv på systemutvikling, eller inspirasjon til å fortsette den kontinuerlige kampen for å levere produkter uten så mye overhead!

De Kontinuerlige

  • Kontinuerlig tilbakemelding
  • Kontinuerlig integrasjon
  • Kontinuerlig prioritering
  • Kontinuerlig læring og forbedring
  • Kontinuerlig prodsetting

Kontinuerlig tilbakemelding

  • Korte tilbakemeldingssykluser. Dette gjelder på mange plan, men tilbakemelding fra kunde og bruker er essensielt.
  • Fail fast. Jobber du mot feil mål, vil du ikke vite dette snarest mulig?
    • I systemutvikling er det slik at regelen, ikke unntaket, er at man ikke vet nøyaktig hva man skal lage, selv ikke på små features.
  • Parprogrammering gir ekstremt raske tilbakemeldinger på et lavere nivå, hvor forståelse bedres og spres i teamet.
  • Tilbakemelding fra bruker! Supportorganisasjoner bremser ned tilbakemeldingene. (Hvordan bidrar ITIL til bedre system?)
    • Minimer tid fra feil innført til feil oppdaget og ansvarlig opplyst. (friskt i minne, bedre læring, forebygger gjentagelse)
    • Maksimer ansvarligheten til vedkommende som innførte feilen. Avhendinger (hand-overs) sprer ansvar og motarbeider læringen.

Kontinuerlig integrasjon

  • CI. Tester koden med andre databaser, systemer og kodebaser. Fail fast på teknisk nivå.
  • Jo større mengde kode som merges eller testes sammen, jo tyngre blir det.  Samme mengde kode, fordelt over mange integrasjoner, integreres raskere totalt sett enn alt i ett. Det bestrider vel ingen lenger? Kontinuerlig integrasjon minimerer dermed denne overheaden.
  • Oppmuntrer TDD og gode tester.
  • Kontinuerlig respons er relatert, men er mer rettet mot lokalt nivå.
    • TDD. Kjør test, få tilbakemelding etter et par sekunder.
    • Visning. Øyeblikkelig respons fra kodeendring til skjermbilde. Snakk om teknologi- og produktvalg.

Kontinuerlig prioritering

  • Jobb etter prioritet
    • Personene i prosjektet ditt er utrolig verdifulle ressurser. Bør vi ikke spille dem best mulig?
    • Er det i det helt tatt rasjonelt å forsvare noe annet enn at de skal jobbe med høyest prioriterte oppgaver?
  • Kontinuerlig prioritering dreier seg om å ta beslutninger basert på best mulig informasjonsgrunnlag.
    • Når er vi best skikket til å vurdere hva som er viktigst? Akkurat nå eller i planleggingsfasen for et år siden, for en måned siden eller en uke siden? Svarer gir seg selv.
  • Prioriteringene kan endre seg daglig.
    • Det gjenspeiler at du vet mer.
    • Lite endringer er symptom på dårlig informasjonsinnhenting, lite tilbakemeldinger, ønsketenkning eller dårlig styring.
  • KANBAN er mest tilrettelagt for kontinuerlig prioritering, da det er et køsystem. SCRUM er et plansystem, men med enukersiterasjoner er det kanskje responsivt nok? Se min tidligere bloggpost om KANBAN and SCRUM combined, for tanker rundt dette.
  • Kontinuerlig prioritering er en jobb der man vurderer forretningsverdi mot kostnad. Både forretningsverdi og kostnad er variabelt med tid og tilstanden i prosjektet, for samme feature eller defekt. En feature kan ha svært lav prioritet en dag, for så å få topprioritet et par uker senere.
  • Detaljnivå i prioritering avhenger av aktualiteten. Du verken bryter ned eller setter prioritering på oppgaver eller user stories langt frem i tid. De nærmest dagene (ukene) er viktigst, innenfor en større plan eller visjon. (plan som i idé, ikke som i dokument med utdaterte og ofteste feilaktige antagelser)
  • Kontinuerlig prioritering er aktiv styring av prosjektet!
    • hvilke insentiver er lagt til rette for å levere mest mulig forretningsverdi, dekke mest mulig forretningsbehov, raskest, oftest, for kunden? Fastpris representerer det motsatte, det ligger i dens natur. De eneste som har reell mulighet til kontinuerlig prioritering er der kunden selv har styringen. Om ikke kunden har slik kompetanse, har man et genialt, men svært lite brukt alternativ i Norge, profesjonelle Produkt Owners e.l. En uavhengig person som styrer prosjektet fra kundens side, med innleide ressurser. Kunden må ha makta! Alle dagens kontrakter motarbeider kundens interesser. Det får bli en diskusjon til en annen gang.
  • Kontinuerlig behovsanalyse er så tett knyttet til kontinuerlig prioritering at jeg grupperer det innunder dette. Det er også tett knyttet til kontinuerlige tilbakemeldinger.
    • Bedrer beslutningsgrunnlaget for kontinuerlig prioritering.
    • Aktivt søken etter potensielt omveltende informasjon. Er du på feil kurs, vil du ikke da oppdage dette tidligst mulig?  10 ressurser på feil kurs i 10 uker koster ekstreme summer. I tillegg vil de ha endret kodebasen og potensielt fordyre videreutviklingen. Hver linje kode koster penger etter at den er skrevet.
    • Bør prosjektet avbrytes? Splittes opp? Ekte styring som dette, ser vi lite av.
  • Hvor mange prosjekter søker aktivt informasjon og endrer prioriteringene sine etter disse?

Kontinuerlig læring og forbedring

  • Prøv og feil, ofte og billig!
  • Forkast teknologier, rammeverk, produkter etc. som ikke dekker behovet, før de koster for mye. Stolthet til side, jeg har stadig tatt feil valg selv. Det er uintelligent å fortsette når du vet bedre.
  • Kontinuerlig tilbakemelding er svært relevant til dette. Vi har muligheten til å lære om og av våre valg. Læring og forbedring er rettet mot individene,  ikke kun om prosjektet og dets kurs. Vi må reflektere og strebe etter å bli bedre!
  • Regelmessige retrospekter for lære om de større trekkene og filosofere over valg som ble tatt eller ikke tatt.
  • Refactoring, omskrivning og annen innsats for forbedring av kodekvalitet, sparer masse tid totalt sett. Jeg vet denne er noe counter-intuitive, men det er for meg en selvfølge. Dette er noe de dyktigste utviklere vet, de som leverer fart over tid.
  • Kontinuerlig læring og forbedring er grunnstenen i det å bli en software craftsman. IT-bransjen beveger seg utrolig raskt, les litt hver dag!
  • Standarder
    • er bra!
    • er er idéer som skal forandres ettersom man vet bedre
    • skal utfordres!
  • Ofte følt at du lærte mye av en fagbok? Hvor mye tid tar det å lese en? Hvor mye tid tar det om du løser en ting suboptimalt eller dårlig, når det finnes bedre måter? Hvordan vet du at du ikke har tatt feil valg som kunne spart deg og andre for masse arbeid nå og i fremtiden?
  • Bruk 40% av tiden til å lese, studere og forbedre deg selv. Bruk resten av tiden på effektiv utvikling og levér bedre (mer, raskere) enn en “100% ressurs”. OMA’s postulat nr 1.
  • Ville du løst sist prosjekt på samme måte om igjen?
  • Ville du løst sist feature på samme måte om igjen?
  • Nei vil alltid være svaret på de to over, du vet tross alt mer nå. Men svaret på “hvordan annerledes?” vil avhenge av hvor dyktig du er blitt.
  • Vil du heller ha en utvikler med 10 års erfaring som ikke er interessert i å lære av andre eller forbedre seg selv, eller en med 3 års erfaring som kontinuerlig forbedrer seg selv og aktivt søker lærdom som ofte invaliderer det han/hun kan fra før.
  • “Det er alltid noe å klage på”, går utrykket. Ja, tenker jeg, men er det negativt?
    • Det stor forskjell på hva Petter Northug og en mosjonist klager på.
    • En toppidrettsutøver, selv om han/hun er verdensener, fokuserer på ting å forbedre.
    • En mosjonist vil klage på helt elementære ting.
    • Ettersom man forbedrer seg, finner man neste ting å forbedre, eller “klage på”.
    • Som selvstending konsulent må jeg hoppe frem og tilbake mellom disse nivåene og ser mye forskjellig. Jeg har lagt merke til at der nivået eller lavest, er der det er minst åpenhet og lærevilje.
  • Du kan bli ufattelig god som småbarnsfar/-mor med 8-16 jobb ! Det handler mye om holdninger hos deg selv og også din arbeidsgiver. Men noe lesning må du gjøre på egen tid. Om ikke du er villig til å investere i deg, hvorfor skal arbeidsgiver være det?

Kontinuerlig prodsetting

Continuous deployment. Denne binder alle de kontinuerlige sammen. Denne gir ekstrem verdiøkning! Streber du etter kontinuerlig prodsetting vil du automatisk få fokus på alle de kontinuerlige over. De følger naturlig! Det er verdt mye i seg selv. Andre bieffekter vil være

  • Release blir en ikke-hendelse. Du blir rett og slett god på det og automatiserer prosessen.
  • Lite kode ut i prod ofte, gir:
    • færre feil
    • færre feilkilder
    • kjappere feilfiks
    • mindre kode å søke gjennom for å finne feilen
    • sjeldnere kritiske feil!
  • Det er lettere å fikse feil i kode du akkurat har laget og shippet, enn noe du lagde for uker siden.
  • Kjapt få ut AB-tester, som virkelig lærer deg mye dine brukere og hjelper deg med å ta riktigere valg
  • Stegvis deploy. Rulle ut til 10% med automatisk utrulling til alle om det passer noen gitte kriterier (for å avdekke minnelekkasje, større feil etc).
  • Har du en feil, vet hvordan den kan fikses, hvorfor ikke levere fiksen med en gang?
  • nåla i høystakken blir lettere å finne jo mindre høy du har. Sagt på en annen måte. 100 nåler i 100 høystakker går kjappere å finne enn 100 nåler i én høystakk med alt høyet.
  • Hand-overs kommer frem i lyset som det åpenbare tapssluket det er. Skal du lage og levere en bug på timen eller dagen, nytter det ikke å levere fra deg koden til QA, tester, forvalter eller drifter. Man følger koden helt ut, står ansvarlig og må møte alle konsekvenser selv. Ingen andre man har levert ansvaret til.
  • FLYT! Utviklerne havner lettere i flytsonen (karakterisert som ekstremt effektiv og fokusert) når de får lage ting som gir verdi med en gang.
  • MOMENTUM. Hvor imponert blir brukerne der de opplever en bug og får den fikset samme dag? At applikasjonen stadig blir bedre og dekker flere relaterte behov?
  • TRYGT og SIKKERT. Kanskje det vanskeligste å erindre. De fleste i dag ser på utrulling som en risikofylt hendelse. Hvordan blir det da mindre risiko når man gjør det oftere? Jeg lar den henge.

Har du optimalisert driftsorganisasjonen? Har du optimalisert forvaltning? Nyutvikling? Da har du suboptimalisert over helheten. Vennligst ikke forsøk deg på kontinuerlig prodsetting om prosjektet og utviklerne ikke har kontroll over hele linjen! Ikke tillat hindring eller forsinkelse av tilbakemeldinger til de ansvarlige (les: utviklerne) for feilene eller uklarhetene. Altså, support som ITIL etc. som er laget for å hindre slik tilbakemelding(de sier det penere, “skjerme utviklerne”). Alt henger sammen! Forstå hva som skal til, ellers feiler du, brutalt! Slik som med smidig om man ikke har forstått tankene. Jeg gruer meg til alle dem som liksom bruker smidig eller SCRUM, vanner ut KANBAN og/eller kontinuerlig tenkning med sin ignoranse. Det er skadelig å tre slike prosesser inn i rigide rammer av ting som rett og slett ikke funker. Det vil fremdeles ikke bli fungere! Kontinuerlig prodsetting krever tilpasning av organisasjon, ikke omvendt! Still deg spørsmålet hvorfor, med alt du foretar deg. Forstå idéen og tankearbeidet bak buzz-wordene. Dette ble mitt frustrasjonsavsnitt ser jeg, dette brenner jeg for!

Kontinuerlig prodsetting, Continuous Deployment, er fremtiden. Dette levner jeg liten tvil. Flyteknologi, kirurgiske instrumenter og andre livskritiske systemer kan være unntak. Du lar ikke hjertemaskinen få online oppdateringer! Allikevel må man innse at big-bang (store leveranser)  er mer risikable enn mange små og også reflektere over arbeidsprosessen med slike “livskritiske” systemer også. Ditt system er nok blant de 99% av systemer som ikke er blant unntakene, du har nok med 90% sannsynlighet betydelige organisatoriske utfordringer. Det er dessverre mange hindringer, som nevnt i min vesle rant i avsnittet over, for det meste politiske sådan. Jeg planlegger å skrive mer om hva jeg tenker om det, i en senere bloggpost, men det er skummelt å klage for høyt, noen kan risikere å blir fornærmet og gi meg masse fine titler. Continuous Deployment for the win!

Oppsummering

Det er utrolig mange gode teknikker fra XP, smidig og lean. De kontinuerlige prosessene forsterker disse, noe som i seg selv er verdt mye. Vi vet godt at dårlig kode forsinker prosesser enormt. Kontinuitetsprosessene gjør det tydelig at hand-overs forsinker prosessen, så utvikler følger dermed koden helt ut i prod og må selv ta konsekvensen av sine valg. Dermed lærer man ting man ikke visste man ikke visste og skriver bedre kode med mindre feil.

Sett i gang med Kontinuerlig Prodsetting og meld fra til meg. Jeg vil investere!

Relevante linker

About Ole Morten Amundsen

Developer, programmer, entrepreneur. Java, .Net, ruby, rails, agile, lean. Opinionated enthusiast!
This entry was posted in agile, integration, Java, lean, methodology, rails, ruby, smidig, Testing and tagged , , , , , , , , , , , , . Bookmark the permalink.

7 Responses to De Kontinuerlige

  1. Hyggelig å se at det hjelper å mase da ;) Har ikke lest denne ennå, men ser bra ut!

    • Ole Morten Amundsen says:

      alle trenger et spark i ræva i ny og ne :) Ble kanskje litt mye rants innimellom her. Vanskelig å skrive om slike temaer når det kan være så lett å misforstå og feiltolke.

  2. Kristian Frøhlich Hansen says:

    Her var det mye bra Ole Morten! Jeg er spesielt fasinert av de som får til cont. deployment. Dette tror jeg setter
    ekstreme krav til organisasjonen og kan bli en fin utfordring :) Tweet’et nylig om en startup som har fått til dette,
    sjekk en av mine siste tweets for link til slides.

    • Ole Morten Amundsen says:

      Det er den linken jeg har her på slutten, Kristian! Det er meget imponerende det de gjør hos KaChing og lean start up, og så riktig! Takk for tipset på twitter @kristfh

  3. Pingback: The Continuouses « Ole Morten Amundsen

  4. Pingback: Kontinuerlige leveranser – noen enkle spørsmål | Ole Morten Amundsen

  5. Pingback: Kontinuerlige leveranser – noen enkle spørsmål | Ole Morten Amundsen

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s