Kun ajattelet suorituskykyistä organisaatiota, oletko koskaan pohtinut, mitä parhaita käytäntöjä se noudattaa saavuttaakseen tällaisen aseman? Suosivatko ne ketteriä lähestymistapoja vai DevOps-lähestymistapoja?
Tavoitteidensa saavuttamiseksi nämä organisaatiot turvautuvat usein ketterien kehitystyökalujen yhdistelmään iteratiivisen kehityksen ja mukautuvan suunnittelun hallinnassa sekä DevOps-työkaluihin, jotka tehostavat automaatiota, jatkuvaa integraatiota ja käyttöönottoa.
Kehitys- ja operointiprosessin tavoitteena on auttaa yritystä täyttämään vaatimuksensa, auttaa tiimin jäseniä tekemään yhteistyötä ja purkamaan siiloja ongelmien ratkaisemiseksi sekä lopulta saattamaan heidän työskentelemänsä projektit ja ominaisuudet päätökseen, jotta he voivat kasvattaa päivittäisten tai kuukausittaisten aktiivisten käyttäjien määrää – tai yrityssovellusten tapauksessa lisätä sovellustensa toiminnallisuuksia.
Kun tiimit työskentelevät siiloissa, viestintään syntyy aukkoja, mikä puolestaan johtaa kaaokseen. Kun tiimit taas työskentelevät yhdessä, ne ovat tehokkaampia.
Tässä artikkelissa käsittelen ketteriä ja DevOps-lähestymistapoja, esimerkkejä tilanteista, joissa tiettyjä menetelmiä kannattaa ottaa käyttöön, sekä sitä, miten testaaminen vaikuttaa kussakin näistä tilanteista.
Ketterän ohjelmistokehityksen käytännöt
Vesiputousmalliin verrattuna ketterässä kehityksessä keskitytään yhteen keskeiseen periaatteeseen, johon kuuluu asiakkaiden tarpeiden täyttäminen jo prosessin alkuvaiheessa ja jatkuvan toimituksen avulla. Jatkuva toimitus on mahdollista vain, kun laadunvarmistustiimi otetaan mukaan prosessiin varhaisessa vaiheessa ja sen kanssa tehdään usein yhteistyötä.
Tällä hetkellä jotkin pienet ja keskisuuret yritykset ovat tilanteessa, jossa ne eivät noudata täysin ketterää lähestymistapaa eivätkä vesiputousmallia, vaan näiden yhdistelmää. Nämä niin kutsutut ketterät tiimin jäsenet keskittävät suuren osan energiastaan yksityiskohtaisiin prosesseihin, kuten 30 minuutin päivittäisiin tilannepalavereihin ja 60 minuutin retrospektiivikokouksiin, unohtaen sijoitetun pääoman tuoton, mikä johtaa lopulta tilanteeseen, jossa tuotannossa havaitaan paljon virheitä.
Have an account? Log In
Onko ala todella siirtynyt pois vesiputousmallista?
Oletko koskaan ollut mukana organisaatiossa, jonka luulit noudattavan ketterän ohjelmistokehityksen prosesseja, mutta tajusitkin, että laadunvarmistustiimi osallistuu testaukseen vasta kehityksen valmistuttua?
Tässä esimerkissä sitä kutsuttiin edelleen ketteräksi, koska kehitystiimin jäsenet työskentelivät samanaikaisesti useiden haarojen (tai ominaisuuksien) parissa iteratiivisesti. Kun heidän ominaisuutensa piti testata, he kuitenkin odottivat kaiken kehityksen valmistumista — mikä on vesiputousmenetelmän ydin. Koska yritykset haluavat edetä nopeammin voidakseen kasvattaa asiakaskuntaansa, tiimeille kertyy useimmiten teknistä velkaa.
Paras tapa ratkaista tämä ongelma on muuttaa organisaatio täysin ketteräksi ja työskennellä iteratiivisesti tiiviissä yhteistyössä laadunvarmistustiimin kanssa. Tämä edellyttää työskentelyä kaikkien sidosryhmien kanssa, jotta he ymmärtävät muutoksen tekemättä jättämisen seuraukset ja sen, miten se voi vaikuttaa loppukäyttäjäkokemukseen.
Ketterät viitekehykset ja niiden muunnelmat
Tässä artikkelissa käsittelen kahta suosituinta ketterää viitekehystä:
- Scrum
- Kanban
Scrum on iteratiivisiin ja inkrementaalisiin prosesseihin perustuva ohjelmistokehityksessä käytettävä ketterä menetelmä. Siinä noudatetaan ajallisesti rajattua kehitystyötä, jota kutsutaan sprinteiksi. Sprinttien kesto vaihtelee organisaation mukaan viikosta kuukauteen tai neljännekseen.
Ensin järjestetään sprintin suunnittelutilaisuus, jota seuraa sprintti, jonka aikana toteutus ja testaus tapahtuvat päivittäisine tilannepalavereineen, ja lopuksi järjestetään retrospektiivikokous.
Scrumia käytetään yleensä tuotekehitystiimeissä, joissa tiimin jäsenten on rajattava työskentelyaikansa asiakkaiden määräaikojen saavuttamiseksi. Sitä sovelletaan enimmäkseen B2C-sovelluksiin, koska liian pitkään odottaessa ominaisuus ei ole enää uusi, sillä joku muu on saattanut toteuttaa sen jo!
B2B-sovelluksissa, joita käyttävät enimmäkseen yritysasiakkaat, käytetään yleisesti muokattua ketterän menetelmän versiota nimeltä SaFe – skaalattu ketterä viitekehys.
Useimmat yritysten projektit kuuluvat johonkin seuraavista luokista:
- Tiimitaso
- Ohjelmataso
- Portfoliotaso
Tiimitason projektit ovat ominaisuuspohjaista kehitystyötä, jossa jokainen tiimin jäsen vastaa omasta projektistaan ja prosesseistaan. Nämä tiimit käyttävät yleensä Scrumia tai Kanbania työnsä luonteesta riippuen.
Jos tiimit kuuluvat tutkimus- ja kehitysorganisaatioihin tai testiautomaatioon, niiden on ehdottomasti noudatettava Kanbania, joka on vähemmän jäykkä, ja tavoitteena on keskittyä enemmän nykyisen tehtävän suorittamiseen kuin siirtyä seuraavaan kiinnostavalta vaikuttavaan tehtävään! Jos tiimit ovat osa tuotekehitysorganisaatiota, ne käyttävät yleensä Scrum-prosesseja.
Ohjelmatason projekteihin osallistuu useita tiimejä, jotka työskentelevät tietyn tavoitteen, kuten AWS-siirron, saavuttamiseksi. Vaikka tämä projekti voitaisiin luokitella portfoliotason projektiksi, väittäisin, ettei se välttämättä vaikuttaisi henkilöstö- tai taloushallinnon tiimeihin.
Tässä tapauksessa AWS-siirtoprojekti voisi kestää kuukausia odottamattomien ongelmien vuoksi, joten painopiste on AWS-siirron onnistuneessa loppuunsaattamisessa jakamalla se samalla perusteltuihin sprintteihin.
Portfoliotason projekteihin osallistuu yrityksen eri organisaatioita; esimerkkinä voidaan mainita JIRA:n käyttöönotto. Jokainen organisaatio edellyttäisi JIRA-työnkulkujen toteuttamista eri tavalla tarpeidensa perusteella. Henkilöstöhallinnon tiimit eivät tarvitse testausta, vaan painopiste on pääasiassa työntekijöiden tiettyihin pyyntöihin vastaamisessa, ja kun heitä on autettu, tehtävä merkitään ”valmiiksi”.
Ketterät menetelmät tulisi ottaa käyttöön organisaatioissa, joissa tapahtuu jatkuvasti muutoksia. Näiden muutosten on kuitenkin edelleen käytävä läpi testaamis- ja virheenkorjauskierros, eikä testausta välttämättä ole automatisoitu, mikä pidentää prosessien kestoa.
Lopuksi, kun ominaisuudet ovat valmiita käyttöönotettaviksi, ne luovutetaan koonti-/ylläpitotiimille. Testausta tehdään siis vesiputousmalliin verrattuna iteratiivisesti, mutta painopiste ei ole jatkuvassa testauksessa ja toimituksessa, joten testausta ei siirretä merkittävästi aiempaan vaiheeseen. Tästä syntyy tarve DevOps-lähestymistavalle!
DevOps-lähestymistapa
DevOps-lähestymistapa keskittyy kehityksen ja testauksen ulkopuolisiin osa-alueisiin ja edistää täysin automatisoitua CI/CD-putkea sekä valvontaominaisuuksia. Ketterä kehitys suhtautuu muutoksiin myönteisesti, kun taas DevOps-lähestymistapa keskittyy jatkuvaan testaukseen ja toimitukseen varmistaakseen, että usein toistuvat julkaisut onnistuvat loppukäyttäjien kannalta.
IT-toimintojen tiimin tavoitteena on skaalata ohjelmistokehityksen prosessia koodin kirjoittamisen ja päivittämisen nopeuttamiseksi, mikä on välttämätöntä uusien sovellusten ja palveluiden luomisessa sekä IT-tiimin ominaisuuksien päivittämisessä.
Nykyään jopa tiimien rakenteen osalta laatu- ja IT-toimintojen tiimit kuuluvat samaan organisaatioon, jotta ne voivat työskennellä tiiviisti yhdessä. Itse asiassa käyttöön on otettu uusi rooli nimeltä TestOps, joka keskittyy erityisesti CI/CD-putkien määrittämiseen, joissa automatisoidut testit suoritetaan pull-pyyntöjä vastaan ja jotka antavat kehitystiimeille välitöntä palautetta.
Automatisoitu testaus on välttämätöntä testaustoimien skaalaamiseksi, ja sen arvo menetetään, jos se ei ole osa jatkuvaa testausta ja jatkuvaa käyttöönotto- ja julkaisusykliä. Siksi TestOps-henkilöstö pitää aina kiireisenä automatisoidun testausinfrastruktuurin ylläpito.
Näin varmistetaan, että toimintotiimin jäsenet voivat keskittyä maailmanluokan infrastruktuurin toimittamiseen ohjelmistokehitystä varten ilman, että testausinfrastruktuuri häiritsee heidän työtään.
Nykyään käytössä on paljon työkaluja ja DevOps-käytäntöjä, jotka tehostavat koko prosessia.
- Terraformin tilatiedosto viittaa joukkoon infrastruktuureja, jotka määritellään ja joita hallitaan yhtenä yksikkönä – näin määritellään ja hallitaan erilaisia testi- ja kehitysympäristöjä. Terraform auttaa palvelinten määrittämisessä, mutta tarvitsemme infrastruktuurin näiden palvelinten suorittamiseen.
- AWS tarjoaa infrastruktuurin EC2-instanssien kautta, jotka ovat tällä hetkellä kustannustehokkain tapa määrittää ja suorittaa nämä palvelimet. Jos teknologiapinossasi on paljon mikropalveluita, voit docker composella määrittää ja suorittaa useita Docker-säilöympäristöjä.
- Ansible automatisoi koneiden määrittämisen suorittamaan prosesseja tai palvelimia.
- Kubernetes auttaa hallitsemaan näiden EC2-instanssien klusteria podina ja ajoittaa säilöjen suorittamisen tässä klusterissa käytettävissä olevien laskentaresurssien perusteella.
Pitäisikö sinun käyttää ketterää kehitystä vai DevOpsia?
Vaikka ketterän ohjelmistokehityksen ja DevOps-lähestymistavan välinen vertailu on organisaatioissa jatkuvan keskustelun aihe, paras tapa tarkastella asiaa on esittää itsellemme seuraavat kysymykset:
- Kuinka sopeutumiskykyinen organisaatiomme on uusien teknologioiden suhteen?
- Pystymmekö kilpailemaan kilpailijoidemme kanssa tuotteidemme laadun osalta?
- Käyttävätkö asiakkaat todennäköisesti tuotteitamme, koska ne täyttävät heidän odotuksensa?
Jos vastaukset edellä esitettyihin kysymyksiin ovat jossain määrin kielteisiä, on aika keskittyä enemmän molempien lähestymistapojen yhdistämiseen ja mukauttaa se vastaamaan tarpeitamme.
Ihanteellinen ohjelmistokehitysmenetelmä
Ketteriin ja DevOps-pohjaisiin ohjelmistokehitysprosesseihin liittyvä keskeinen ero on se, että ensin mainittu keskittyy enemmän jatkuvien muutosten huomioimiseen, kun taas jälkimmäinen keskittyy jatkuvaan testaukseen, toimitukseen ja käyttöönottoon. Kehitys- ja operointitiimien välinen yhteistyö on ratkaisevan tärkeää, jotta kehitystiimin työ ei esty.
Oman näkemykseni mukaan ihanteellisen ohjelmistokehitysprosessin tulisi sisältää seuraavat asiat:
- Asiakas- ja käyttäjäpersoonien käsittely sekä asiakaspalautteen hyödyntäminen
- Parhaisiin käytäntöihin keskittyminen teknisen velan kertymisen estämiseksi
- Jatkuva parantaminen, jatkuva testaus, jatkuva integraatio, jatkuva toimitus, jatkuva käyttöönotto ja valvonta
Tältä prosessi näyttäisi:
Eri asiakaspersoonien huomioiminen ei rajoitu tuotehallintatiimeihin. Loppujen lopuksi, miksi kehitämme näitä tuotteita? Mikä näiden tuotteiden tarkoitus on, jos asiakkaat eivät käytä niitä?
Otetaan Nokian klassinen esimerkki—heille kertyi jatkuvasti teknistä velkaa, koska he eivät pysyneet markkinatrendien, erityisesti kilpailijansa Applen innovaatioiden, tahdissa. He keskittyivät tiukkojen sprinttijaksojen noudattamiseen, kunnes heidät lopulta unohdettiin!
Kaikkien yritysten tulisi ymmärtää, miksi niiden ominaisuuksia kehitetään ja millaisia asiakkaita ne palvelevat. Näin varmistetaan, että kehitämme käyttäjäkeskeisiä ominaisuuksia.
Kun uusi tuote julkaistaan, olipa kyseessä mobiilisovellus tai verkkosovellus, varmista aina, että asiakkailla on mahdollisuus antaa palautetta. Kaikki yritykset eivät noudata tiukkaa prosessia, jossa työskennellään tiiviisti asiakastuen kanssa.
More Articles
CI/CD
Edistä lopuksi tekoälyyn ja koneoppimiseen perustuvaa jatkuvaa integraatiota ja jatkuvaa toimitusta. Kun projekti epäonnistuu, se ei välttämättä tarkoita tiimin jäsenten osaamisen puutetta, vaan pikemminkin riittämätöntä testausta ja sitä, ettei ongelmia ole löydetty aiemmin kehityksen aikana.
Joskus asiat menevät kuitenkin pieleen riittävästä testauksesta ja käytössä olevasta automaatiosta huolimatta—jos käytössä olisi suositusjärjestelmä, joka tunnistaisi, milloin julkaista ja milloin ei, tällaiset katastrofaaliset epäonnistumiset voitaisiin ehkä välttää.
Tiheät iteraatiot auttavat kehitystiimiä ymmärtämään, mikä toimii ja mikä ei, sekä pohtimaan skaalautuvuutta. Haittapuolena on, että se vie aikaa! Jos jokin toinen suositus- tai ennustejärjestelmä voisi kerätä tietoa asiakkaista ja ennustaa, auttaisiko tietty ominaisuus saavuttamaan suosiota vai epäonnistuisiko se jo ennen kehityksen aloittamista, se auttaisi tehostamaan laadukkaan tuotteen rakentamista heti ensimmäisestä päivästä lähtien!
Kaiken kaikkiaan tavoitteena on varmistaa, että liiketoimintavaikutukset kasvavat nopeammin, kun nämä parhaat käytännöt otetaan osaksi kehitysprosessia.
Lopuksi
Loppujen lopuksi sekä ketterällä kehityksellä että DevOpsilla on ratkaiseva rooli nykyaikaisessa ohjelmistokehityksessä, mutta oikea valinta riippuu organisaatiosi tavoitteista, tiimirakenteesta, hinnoitteluvaihtoehdoista ja projektin tarpeista.
Ketterä kehitys keskittyy iteratiiviseen kehitykseen ja joustavuuteen, kun taas DevOps korostaa jatkuvaa toimitusta, automaatiota sekä kehityksen ja operaatioiden välistä yhteistyötä. Monet organisaatiot saavuttavat hyviä tuloksia yhdistämällä molemmat lähestymistavat tehokkuuden ja laadun maksimoimiseksi. Valitsemastasi polusta riippumatta on tärkeää sovittaa työkalut ja prosessit yhteen innovaatioiden edistämiseksi ja arvon tuottamiseksi nopeammin.
Jos haluat lisää näkemyksiä kehitystyönkulkujen optimoinnista ja toimialan kehityksen tahdissa pysymisestä, tilaa The CTO Clubin uutiskirje.
