Vi hadde estimert konverteringen av kredittkortfunksjonaliteten i nettbanken over på ny plattform, til et halvt årsverk.
Da vi var ferdige hadde vi brukt ett og et halvt årsverk, altså tre ganger så lang tid. På tross av dette hadde ledelsen tillit til oss.
Hvorfor hadde de det? Hva hadde det ekstra årsverket gått med til?
Det hadde stort sett gått med til verktøy.
Standardisere, automatisere
Vi var i en situasjon hvor vi skulle konvertere både privatnettbanken og bedriftsnettbanken vår over på ny plattform. Vi så tidlig at vi kunne få god nytte av en del script og verktøy vi hadde laget. Ledelsen så også at dette hadde potensiale til å bli god investering, så dermed ble vi verktøymakere i tillegg til utviklere.
Men hva var det egentlig vi så? Hvorfor følte vi det var verdt å bruke dobbelt så mye tid på verktøy i starten som på faktisk konvertering av funksjonalitet?
Vi kan se på verktøyene våre som en variant av standardiserte, automatiserte prosesser.
Hvis Taiichi Ohno og gjengen bak smidigmanifestet er foreldrene til Lean og Smidig, kan vi si at William Deming er bestefaren. I 1950 inspirerte Deming Ohno og Toyota med det som skulle bli kjernen i Toyota Production System, eller Lean, som er det amerikanske betegnelsen på det.
Kjernen i Lean består av to ting:
- Kontinuerlig forbedring — hvordan skape en organisasjon som har kontinuerlig forbedring som basis i kulturen sin
- Respekt for folk — trua på at folk som får mulighetene og rammebetingelsene, alltid vil gjøre sitt beste
Deming mente at basis for kontinuerlig forbedring, er standardiserte prosesser. Hvis vi ikke har standardisert, så er det der vi bør begynne: Finn beste måte å utføre en operasjon på, la alle gjøre operasjonen på denne måten, og sørge for at det er så lett å gjøre det at det føles dumt å la være.
Vi som jobber med IT kan gjøre det enda bedre enn å standardisere — vi kan ofte automatisere operasjonene i tillegg.
«Vi som jobber med IT kan gjøre det enda bedre enn å standardisere — vi kan ofte automatisere operasjonene i tillegg.»
Rammeverket bob
En operasjon alle 150 utviklerne våre gjør flere ganger om dagen eller i uka, er å opprette brancher med tilhørende byggejobber. Vi har laget oss et scriptrammeverk som heter bob, så hos oss gjør vi dette med onelineren
bob feature begin <featurenavn>
Med denne oneliner-en får vi:
- opprettet branchen med rett navnestandard
- opprettet byggejobben for branchen
- sikret at vi får med oss en commithook slik at den automatisk bygger ved push
Vil vi gå til jobben i Jenkins UIet, skriver vi
bob ci job open
så går vi rett dit i nærmeste nettleser.
Lettere å hjelpe
Men vil ikke slike verktøy stå i veien for forbedring, snarere enn å hjelpe?
Vi tror det viktigste vi kan gjøre for ikke å gå den fellen, er å sørge for at verktøyene våre er så åpne som mulig, slik at alle kan være med å bidra. Har du forslag til en forbedring, legg opp en pull request, og så tar vi det derfra. På den måten får du også eierskap til verktøyene, du merker at du kan forbedre dem selv.
SpareBank 1 deler sitt eget mock-verktøy, Troxy
Siden alle teamene våre stort sett bruker de samme verktøyene, så gjør det at det blir lettere å hjelpe hverandre på tvers av team, og også bytte team. Vi kjenner oss igjen i infrastrukturen, og kan fokusere på funksjonaliteten.
På denne måten er verktøyene våre med på å skape fellesskap mellom teamene våre, noe vi ofte føler kan være vanskelig, og som vi jobber mye med på fellesarenaene våre som faggruppene og fagdagen hver torsdag.
Verktøyene våre hjelper ikke bare med forbedring, de gjør ting enklere for oss også. Operasjoner vi gjør ofte, eller burde gjøre ofte, bør være lette å gjøre — det må være lett å gjøre rett.
Tenk hvor enkelt det er å starte og kjøre avgårde med bilen over, på tross av hvor kompliserte de mekaniske og elektriske prosessene som faktisk sørger for at bilen kjører, er?
«Verktøyene våre hjelper ikke bare med forbedring, de gjør ting enklere for oss også.»
Sover godt om natten
Vi bruker OpenShift som containerplattform, så et tilsvarende eksempel hos oss kan være det å dra opp et containermiljø for applikasjonen en jobber med lokalt. Hos oss gjør vi det med onelineren
bob openshift up
Vi trenger altså bare disse 16 tegnene og den lokale docker-compose.yaml filen som tilhører applikasjonen, for å spinne opp et fullt testmiljø i openshift for den aktuelle applikasjonen.
Når ting er automatisert og standardisert, så gjør vi ting likt.
Et av verktøyene våre som hjelper oss med dette, er applikasjonsgeneratorene våre. Når vi skal lage et nytt api, eller en ny frontendapplikasjon, så genererer vi opp applikasjonene. Dette garanterer blant annet at
- applikasjonene har rett konfigurerert sikkerhet
- at vi har kontroll på hvilke deler av den totale sikkerhet som håndteres av plattformen, og hva som håndteres av applikasjonene selv
På denne måten kan vi lage mange nye applikasjoner og deploye mange nye endringer, og fortsatt sove godt om natten.
I del to av denne artikkelserien skal vi fortelle om hvordan verktøyene våre er laget. Vi delte også mer om disse temaene på JavaZone VR tidligere i høst.
- Hva skal vi testere gjøre, nå som utviklere automatiserer alt selv?
- Skal vi i legge ned? spør Marianne Falkenås i SpareBank 1.