DevOpsin väärinkäytetyt luvut

Ohjelmistoinsinööreinä teemme suuren osan konkreettisesta työstämme tietokoneen äärellä. Monet päätökset perustuvat kuitenkin hyväksymiimme tarinoihin tai valkotauluille piirtämiimme kaavioihin. Näytän kolme kaaviota, joita käytetään usein väärin.

Kaavioiden edustamat ajattelun oikotiet ovat arvokkaita, sillä ne estävät meitä keksimästä pyörää yhä uudelleen. Nämä mallit voivat olla yksittäisen kehittäjän päässä, tiimissä, yrityksessä tai koko toimialalla. Ne ovat voimakkaita, mutta niitä voidaan käyttää sekä hyviin että huonoihin tarkoituksiin.

Erityisen hankalaan tilanteeseen päädymme silloin, kun oikotiemme peittävät tietoa tai ovat yksinkertaisesti vääriä.

Piilota burndown-kaaviosi!

Yksi kaavio, jota näen kaikkien itseään Agile-tiimeiksi kutsuvien käyttävän, on burndown-kaavio.

Kaavion tarkoitus on näyttää, onko tiimi etenemässä kohti sitoutumaansa toimitusta. Sen pitäisi antaa tiimille varhainen varoitus, jotta se voi tarvittaessa tiedottaa sidosryhmiä tai muuttaa prioriteetteja.

Kun kaavioon asetetaan tavoite, se sisältää oletuksia siitä, miten ohjelmistokehitys toimii. Se olettaa, että työ etenee ennakoitavasti ja tasaisesti, mikä ei pidä paikkaansa. Tämä ei kuitenkaan välttämättä ole ongelma. Kaavio voi varoittaa tiimiä varhain siitä, ettei jokin etene odotetusti, ja antaa tiimille mahdollisuuden toimia tilanteen vaatimalla tavalla.

Useammin burndown-kaaviota käytetään johdon ruoskana. Projektipäällikkö tai pahantahtoinen Scrum Master saattaa kesken sprintin tulla patistamaan tiimiä, koska burndown näyttää hänen mielestään huonolta. Ei kuitenkaan ole järkevää keskustella siitä, onko burndown-kaavio hyvä vai huono. Kaavio heijastaa vain tämänhetkistä todellisuutta.

On muistettava, että burndown-kaavio on tiimiä varten. Se ei itsessään kerro mitään arvokasta tai konkreettista. Jos burndown yllättää tai pelottaa, meidän kannattaa selvittää, mikä siinä tarkalleen ottaen yllättää, ja miten voimme ratkaista asian tiiminä.

Kun burndown-kaaviota käytetään väärin, se ei ainoastaan jää hyödyttömäksi, vaan myös aktiivisesti turhauttaa kehittäjiä, jotka yrittävät ratkaista monimutkaisia, ennennäkemättömiä ongelmia.

Myöhästyneiden projektien hallinta

Projektien myöhästyminen silloin tällöin on täysin väistämätöntä. Jokainen tiimi sitoutuu jossain vaiheessa liian suuriin tavoitteisiin. Tiimiä saatetaan painostaa siihen, tai se ei yksinkertaisesti saavuta tavoitettaan.

Toivottavasti huomaamme jo varhaisessa vaiheessa, ettei tavoitteemme todennäköisesti toteudu, jolloin meillä on aikaa toimia. Todennäköisen määräajan ylityksen oletustoimintamalli on kuitenkin rikki. Valitettavasti, kun havaitsemme määräajan siirtyvän, intuitiivinen reaktiomme vain pahentaa ongelmaa.

Oletustoimintamalli on tämä: yritykset lisäävät yleensä resursseja ja kehittäjiä ratkaistakseen ongelman. Odotuksena tai toiveena on, että kun ongelman parissa työskentelee enemmän käsiä ja päitä, pääsemme maaliin nopeammin.

Todellisuudessa uusien ihmisten perehdyttäminen projektiin aiheuttaa välittömän notkahduksen tuottavuudessa. Toimialatuntemuksen jakamiseen, työn arviointiin ja tiimin kasvattamiseen liittyvät haasteet alkavat hidastaa jo valmiiksi myöhässä olevaa tiimiä.

Ennen kuin aikaa on kulunut riittävästi ja uudet tiimin jäsenet ovat päässeet vauhtiin, lisäresurssit ovat vain pienentäneet todennäköisyyttä saavuttaa määräaika. Kuten The mythical Man -Month suosittelee, ainoa tapa käsitellä todennäköisesti ylittyvää määräaikaa on karsia projektin laajuutta tai siirtää määräaikaa.

Lisäresurssien lisäämisellä on myös piilokustannus. Kun resursseja tarvitaan aikataulusta jäljessä olevan projektin pelastamiseen, pelastajat löytyvät todennäköisesti organisaation sisältä. Tämä vaikuttaa paitsi projekteihin, joihin nämä ihmiset alun perin oli osoitettu, myös luo epävakaan tiimirakenteen, mikä tekee jatkuvasta parantamisesta vaikeaa tai jopa mahdotonta.

Tämä ei olisi ongelma, jos sitä tapahtuisi harvoin, mutta valitettavasti monissa suurissa yrityksissä se on normaalia: työntekijöitä siirrellään projektista toiseen hämmentävässä, muuttuvien prioriteettien tanssissa.

Kaikki ei kuitenkaan ole toivotonta, vaikka maalasin synkän kuvan määräaikojen ylittymisestä. Voimme tehdä asialle jotain.

Reväise laastari irti ja karsi laajuutta

Tärkeintä on arvioida jo alussa, myöhästyykö projekti. Usein paras ratkaisu on karsia laajuutta ja miettiä etukäteen, miten laajuutta voi karsia niin, että jäljelle jää mielekäs kokonaisuus.

Laajuuden karsiminen voi heikentää motivaatiota tai olla joissain tapauksissa jopa mahdotonta hyväksyä. Silloin meidän on panostettava siihen, että resursseja on helpompi lisätä projekteihin tarpeen mukaan.

Kun määräaika lähestyy ja huomaat, ettet saavuta tavoitettasi, tilannetta on vaikea korjata. Voit kuitenkin tehdä joitakin asioita, jotka helpottavat resurssien lisäämistä projektiin tarpeen mukaan.

Parhaat vinkit perehdyttämisen helpottamiseen

Suosittelen kohtelemaan kaikkia ohjelmistoprojekteja avoimen lähdekoodin projekteina. Tämä tarkoittaa, että niihin osallistumisen helppouteen on panostettava.

Projektin käyttöä, testaamista ja kehittämistä varten on oltava dokumentaatio. Testauksen on oltava automatisoitua, eikä laatua saa varmistaa kokenut kehittäjä, vaan pilkuntarkka robotti. Lähdekoodimme tallentamiseen käytetyt työkalut on kehitetty tukemaan open source -työnkulkuja tai ne ovat saaneet niistä vahvoja vaikutteita, joten hyödynnä näiden alustojen natiiveja ominaisuuksia.

Varmista vähintään, että seuraavat asiat ovat kunnossa:

• README, jossa on selkeät ja helposti saatavilla olevat ohjeet tuotteen buildaamiseen, käyttöön ja testaamiseen

• Linkit pipelineihin, koodaustyyleihin ja ulkoiseen dokumentaatioon

• Selkeästi kuvattu työnkulku

• Maininta keskeisistä henkilöistä ja siitä, miten heihin saa yhteyden

Näissä toimenpiteissä haastavaa on se, että ne toimivat vakuutuksena. Niiden tärkeys voi olla vaikea muistaa, kun niille ei tunnu olevan tarvetta. Mutta sinä päivänä, kun niitä tarvitset, et voi enää ottaa riskiä siitä, ettet olisi tehnyt näitä valmisteluja.

Yllättävä totuus automaatiosta

DevOps-ihmisenä suhtaudun automaatioon ehkä hieman liiankin innostuneesti. Tiedämme, että automaatio on edellytys sille, että tiimin koon kasvattaminen mahdollistaa superlineaarisen skaalautumisen. Se tuo myös monenlaisia hyötyjä laadun, auditoinnin, toimitusnopeuden ja varmuuden kannalta.

Intuitiomme mukaan manuaalisen työn määrä vähenee, kun investoimme automaatioon. Accelerate DevOps Research kuitenkin kumoaa tämän oletuksen. Tutkimuksen mukaan käyttöönottoprosessin automaatio lisää manuaalista työtä. Tämä johtuu siitä, että testattavia ja katselmoitavia muutoksia on nyt valtavasti.

On kuitenkin hyvä tiedostaa, että olemme poistaneet vain yhdenlaista manuaalista työtä. Olennaista on varmistaa, että mittaat oikeaa asiaa. Muuten automaatiohanke voidaan tulkita epäonnistuneeksi, vaikka olisit onnistunut automatisoimaan osan työnkulustasi.

Tämän manuaalisen työn lisääntymisen vuoksi monet automaatiohankkeet keskeytetään tai todetaan epäonnistuneiksi. Manuaalista työtä ei ole ainoastaan enemmän, vaan automaatiota on myös ylläpidettävä.

Organisaatioissa, jotka ovat prosessiensa automatisoinnin alkuvaiheessa tai joilla on vain vähän kokemusta automaatiosta, automaatioon suhtaudutaan usein epäluuloisesti. Tämä johtaa päällekkäiseen työhön, jota tekevät sekä robotit että ihmiset.

Jotta voimme hyötyä automaatiosta, tarvitsemme myös muutosta ajattelutapaan. Kun manuaalisen työn lisääntymiseen varaudutaan jo ennen automaatioprosessin aloittamista, ikävä yllätys voidaan toivottavasti välttää. Tässä blogikirjoituksessa esittelin muutamia yleisesti hyväksyttyjä lukuja. Enterprise-tason väärinkäsityksestä voit lukea Agile alignment trap -artikkelista.

Minulla oli ilo osallistua DevOpsDays Zurich 2019 -tapahtumaan ja jakaa ajatuksiani lavalta puheenvuorossa: Misused Figures of DevOps.