Piistä ohjelmistoksi: matka DevOpsin löytämiseen ja johtajuuteen

By Katie Sanders

Oletko kyllästynyt siiloutuneeseen työskentelyyn ja myöhästyneisiin määräaikoihin? Haastattelumme Copadon David Brooksin kanssa korostaa yhteistyön merkitystä DevOps-menestyksen saavuttamisessa.

Vaikka DevOps tunnetaan laajalti ohjelmistotoimitusten sujuvoittamisesta ja laadun parantamisesta, todella tehokkaan tiimin luominen edellyttää muutakin kuin yhden työkalun käyttöönottoa. Se on oikeiden elementtien strateginen yhdistelmä: kulttuuri, prosessit, yhteistyö ja teknologia. Tässä artikkelissa tarkastellaan suorituskykyisen DevOps-tiimin keskeisiä osia ja annetaan näkemyksiä siitä, miten organisaatiot voivat yhdistää ne optimaalisten tulosten saavuttamiseksi.

Tätä kysymys- ja vastausartikkelia varten keskustelimme David Brooksin, Copadon evangelisoinnista vastaavan varatoimitusjohtajan kanssa. Hänellä on 35 vuoden kokemus Piilaaksosta, ja hän liittyi Copadoon vuonna 2018 luodakseen tuotehallinnan käytännöt. Hän johti tuotetiimiä neljän vuoden ajan. Brooks liittyi Salesforce.comiin vuonna 2005 käynnistääkseen AppExchangen. Tuotejohtajana hän johti Force.com-alustaa kehittäneitä tiimejä yhdeksän vuoden toimikautensa aikana Salesforcella.

Kiitos paljon, että keskustelit kanssamme! Ennen kuin syvennymme aiheeseen, kertoisitko taustastasi? 

Suoritin sähkötekniikan maisterin tutkinnon Auburnin yliopistossa vuonna 1984. Opinnäytetyöni aiheena oli vikasietoinen moniprosessorikäyttöjärjestelmä ballististen ohjusten puolustukseen. 

Muutin Piilaaksoon ja työskentelin kahdeksassa startup-yrityksessä, joista kolme on tähän mennessä onnistuneesti myyty tai listautunut. Liityin myös Salesforceen pian sen jälkeen, kun yhtiö listautui vuonna 2005. Johdin AppExchangen ja myöhemmin Salesforce-alustan käynnistämisestä vastanneita tiimejä. Olen toiminut pääasiassa tekniikan ja tuotehallinnan johtotehtävissä, vaikka olen ollut myös kahden yrityksen perustaja ja toimitusjohtaja. 

Kukaan meistä ei saavuta menestystä ilman apua matkan varrella. Onko olemassa tiettyä henkilöä, joka auttoi sinua pääsemään siihen, missä olet nyt?

Merkittäviä henkilöitä on kaksi. Chuck Comiso oli Link Technologiesin toimitusjohtaja, ja minä johdin siellä tuotekehitystä. Hän oli vanhan koulukunnan HP-johtaja. Chuck opetti minulle paljon ihmisten johtamisesta. Ted Elliott oli JobSciencen toimitusjohtaja ja toimii nykyään Copadon toimitusjohtajana. Ted opetti minulle, kuinka keskittyä tärkeisiin asioihin ja mitä startup-yrityksen kasvattaminen vaatii.

Mitkä kolme vahvuutta, taitoa tai ominaisuutta auttoivat sinua pääsemään tähän vaiheeseen urallasi? Miten muut voivat aktiivisesti kehittää näitä osa-alueita itsessään? 

Uteliaisuus, viestintä ja luovuus. Olen luonnostani utelias ja elinikäinen oppija, mikä on lahja, jota arvostan eniten. Pystyn myös viestimään ihmisten kanssa tavalla, jonka he ymmärtävät. Puhun kiinaa ja olen oppinut olemaan kärsivällinen niiden kanssa, jotka puhuvat englantia toisena kielenä. Tämä auttaa myös teknisten ideoiden selittämisessä muille kuin teknisille ihmisille.

Ihmiset ovat usein niin kiireisiä suunnitellessaan, mitä haluavat sanoa seuraavaksi, että heiltä jää keskustelun ydinaihe huomaamatta. Koska kiinnostuksenkohteeni ovat lisäksi hyvin laajat, pystyn yhdistämään ideoita uusilla tavoilla. Luovuuteni onkin ennen kaikkea kykyä yhdistää paljon tietoa uudeksi sovellukseksi.

Mitä taitoja yrität edelleen kehittää?

Sen täytyy olla viestintä. Siirryin hiljattain uuteen teknisen evangelistan tehtävään, joka edellyttää minulta entistä parempaa kykyä viestiä Copadon erottavista keskeisistä ideoista. Johdan myös Kiinaan liittyvää toimintaamme, joten kiinan kielen taitoni joutuu koetukselle.

Puhutaanpa menestyvästä DevOps-tiimistä. Mitä keskeisiä tavoitteita DevOps-tiimi voisi asettaa digitaalisen muutoksen matkalle?

Mielestäni selkeys ja kunnioitus ovat ensiarvoisen tärkeitä. Sen selkeyttäminen, mitä on tehtävä, on priorisointikysymys, ja se määrittelee selkeästi yksittäiset käyttäjätarinat ja ominaisuudet. Hyvän tuotepäällikön pitäisi pystyä viestimään ”mitä” ja ”miksi”.

Kaikki alkaa ”miksi”-kysymyksen syvällisestä ymmärtämisestä ja sen varmistamisesta, että myös kehitys- ja testaustiimit ymmärtävät sen. Tiimin jäsenten välillä on oltava keskinäistä kunnioitusta, jossa jokainen uskoo mielipiteidensä olevan arvostettuja ja huolenaiheidensa tulevan kuulluiksi. Sen jälkeen jokaisen tiimin jäsenen on kuitenkin täytettävä vastuunsa ja ansaittava tämä luottamus jokaisessa sprintissä. 

Onko olemassa haasteita tai yleisiä sudenkuoppia, jotka DevOps-tiimien tulisi ottaa huomioon?

Liian usein tuotteen omistaja ymmärtää käyttäjien tarpeet huonosti – ei sitä, mitä he pyysivät, vaan sitä, mitä he tarvitsevat. Minut opetettiin aina kysymään ”miksi?” viisi kertaa. Sen jälkeen ymmärrät, mitä todella tarvitaan, ja pystyt viestimään sen muulle tiimille.

Toinen haaste syntyy, kun tiimin jäsenet eivät puhu erimielisyyksistä suoraan. Olen nähnyt kehittäjien kertovan PM:lle, että jokin ei ollut teknisesti mahdollista, vaikka todellisuudessa he eivät vain pitäneet sitä oikeana toimintatapana. Jokaisen tiimin jäsenen pitäisi tuntea, että hänen mielipidettään arvostetaan, ja tuoda esiin näkemyksensä, kun hän on eri mieltä. Viime kädessä tiiminvetäjän on tehtävä päätös, ja muun tiimin on tuettava sitä.

Miten tehokas yhteistyö ja viestintä tiimin jäsenten välillä voivat parantaa DevOps-tiimin tuottavuutta ja menestystä, ja millaiset käytännöt voivat edistää tätä?

Suora ja avoin viestintä, jossa jokaisen mielipidettä arvostetaan ja jokaisella on mahdollisuus tulla kuulluksi, on erittäin tärkeää. Myös syyn ymmärtäminen on tärkeää. Jos tiimin jäsen näkee paremman tavan täyttää vaatimukset, tiimin pitäisi suhtautua ideaan avoimesti. Tämä johtaa usein parempaan ratkaisuun, joka toimitetaan lyhyemmässä ajassa.

Mikä rooli CI/CD:llä on DevOpsissa, ja mitkä ovat parhaat käytännöt CI/CD-putkien toteuttamiseen saumattoman ja luotettavan ohjelmistojulkaisuprosessin varmistamiseksi?

CI/CD:ssä on kyse monien pienten muutosten julkaisemisesta. Se alkaa käyttäjätarinoiden määrittelystä tavalla, joka mahdollistaa niiden toteuttamisen tunneissa eikä päivissä sekä julkaisemisen seuraavaan vaiheeseen ilman ongelmia. Myös automaattinen toiminnallinen ja tietoturvatestaus on kriittisen tärkeää.

Tiimien tulisi omaksua testivetoinen kehitys, jotta toiminnallisuus voi edetä nopeasti putken läpi. Jokaisessa vaiheessa tulisi olla laatukriteerit, joilla varmistetaan, ettei muutos voi edetä, ellei se ole valmis. Aito CI/CD-tuotantoonvienti ei ole käytännöllistä joillakin voimakkaasti säännellyillä toimialoilla, mutta sen ei pitäisi estää käytäntöjen soveltamista kaikissa tuotantoa edeltävissä vaiheissa.

Miten DevOps-kulttuurin ja -ajattelutavan edistäminen vaikuttaa tiimin yleiseen menestykseen, ja millä strategioilla organisaatiot voivat edistää tätä kulttuuria kehitys- ja operatiivisten tiimiensä keskuudessa?

DevOps-ajattelutapa tarkoittaa, että kaikilla tiimin jäsenillä on yhteinen tavoite toimittaa laadukasta työtä aina tuotantoon asti. Kehittäjät eivät voi ajatella työnsä olevan valmis, kun he siirtävät muutokset repositorioon. Laatu ei ole yhden henkilön tehtävä, vaan jokainen tiimin jäsen on siitä vastuussa. Tämä yhdistettynä luottamukseen ja jatkuvaan parantamiseen avoimesti suhtautumiseen tekee tiimistä menestyvän.

Mitkä ovat menestyvän DevOps-tiimin olennaiset osat? 

1 . Keskinäinen luottamus—Urani alkuvaiheessa työskentelin tiimissä, jonka jäsenet eivät täysin luottaneet toisiinsa. He kyseenalaistivat jatkuvasti toistensa päätöksiä ja tekivät salaa muutoksia ”korjatakseen” ongelmia. Tämä hidasti kehitystä ja teki tiimissä työskentelystä erittäin epämiellyttävää. 

2 . Sitoutuminen tiimin tavoitteisiin - Tehokas tiimityö perustuu yhteisiin tavoitteisiin. Kokemukseni mukaan menestyneimmät tiimit menevät yksilösuorituksia pidemmälle. Olen nähnyt johtavia kehittäjiä, jotka saatuaan omat tehtävänsä nopeasti valmiiksi tarjoavat ohjausta ja tukea nuoremmille ohjelmoijille. Tämä yhteistyöhenki ulottui vielä pidemmälle, kun kehittäjät auttoivat testaajia testiautomaation toteuttamisessa. Tämän ansiosta tiimi täytti jatkuvasti sitoumuksensa ja säilytti myönteisen työympäristön.

3 . Selkeä viestintä - Paljon aikaa ja energiaa voi kulua hukkaan, jos tiimi ei viesti hyvin. Tämä alkaa tavoitteiden asianmukaisesta ymmärtämisestä. Kun aloitin ketterän menetelmän parissa vuonna 2006, koin sprinttien suunnittelukokoukset liian pitkiksi ja päivittäiset tilannepalaverit typeriksi. Asiaa ei auttanut se, että minun piti käyttää kokouksen aikana kukon kuvaa muistuttamassa, että olin tarkkailija enkä voinut puhua.

Jälkikäteen ymmärrän, kuinka tärkeää kyseisten kokousten pitäminen lyhyinä on, mutta silloin menetettiin tilaisuuksia asioiden selventämiseen. Myöhemmin urallani käytimme päivittäisiä tilannepalavereita kysymysten selvittämiseen. Sprintin loppuun ei kannata päästä vain huomatakseen, että rakensit jotain väärin.

4 . Jatkuva parantaminen - Mikään kaksi tiimiä eivät ole samanlaisia, eikä mikään yksittäinen prosessi toimi jokaiselle tiimille. Lean-tuotannon liike antoi kokoonpanolinjojen työntekijöille valtuudet muuttaa prosessia tehokkaammaksi. He tekivät kokeita ja määrittivät, paransivatko muutokset toimintaa vai heikensivätkö sitä. Sama pätee ohjelmistokehitysprosesseihin. Tiimin tulisi mitata tuloksia arvovirtakuvauksen kaltaisilla työkaluilla ymmärtääkseen todelliset ongelmat ja olla sitten valmis muuttamaan prosessia sellaiseksi, joka on järkevä ja sopii edelleen yrityksen vaatimustenmukaisuussääntöihin.

5 . Turvallinen tila uusille ideoille - Ainoa tapa saada kaikki tiimin jäsenet jakamaan ideansa on luoda heille turvallinen olo. Tyhmiä kysymyksiä tai ideoita ei ole olemassa. Usein idea vaikuttaa mahdottomalta toteuttaa, mutta jos kyseenalaistat pitkään käytössä olleet käytännöt, huomaat, ettei kukaan tiedä, miksi ne alun perin otettiin käyttöön. Huonoin koskaan kuulemani vastaus oli: ”Koska olemme aina tehneet näin.” Jatkuvan parantamisen tarve tarkoittaa, että sinun on oltava avoin uusille ajattelutavoille. Saatat hylätä 90 % uusista ideoista, mutta jäljelle jäävillä 10 prosentilla voi olla merkittävä vaikutus.

Mitä uusia suuntauksia ennakoit DevOps-ympäristöön, jotka voisivat vaikuttaa merkittävästi digitaalisen transformaation strategioihin tulevaisuudessa?

Generatiivinen tekoäly, epäilemättä. Copilot-tuotteiden käyttäminen koodin ja testiskriptien tuottamiseen parantaa tuottavuutta merkittävästi. Hyvistä vaatimuksista on kuitenkin aloitettava, joten suunnittelua tukevissa työkaluissa nähdään huomattavia parannuksia.

Suurin osa tulevista ponnisteluistamme keskittyy siihen, että teemme oikeita asioita ja ymmärrämme vaikutukset ja riippuvuudet. GenAI helpottaa julkaisun dokumentointia ja parantaa kykyämme tukea loppukäyttäjiä tuottamalla reaaliaikaisia ja sovellusten nykytilan mukaisia ohjepalveluita.

Jos voisit innostaa liikkeen, joka tekisi eniten hyvää mahdollisimman monille ihmisille, mikä se olisi? 

Vau! Luulen, että kaikki palautuu melko perustavanlaatuisiin periaatteisiin. Kohtele muita niin kuin haluat itseäsi kohdeltavan eli kunnioita toisianne. Ota vastuu sitoumuksistasi ja toimita se, minkä lupaat eli toimi rehellisesti. Keskity sidosryhmiesi menestykseen; auta heitä menestymään ja ansaitse heidän luottamuksensa.

Keskeiset opit

Tehokkaasti toimivan DevOps-tiimin rakentaminen vaatii harkittua ja jatkuvaa työtä. Asettamalla keskeiset osa-alueet—kulttuurin, prosessit, yhteistyön ja teknologian—etusijalle organisaatiot voivat hyödyntää DevOpsin koko potentiaalin.

  • Arvioi nykytila ja tunnista kehityskohteet.
  • Panosta koulutuksiin ja työpajoihin yhteistyöhön perustuvan DevOps-kulttuurin edistämiseksi.
  • Ota käyttöön työkaluja ja automatisoi prosesseja työnkulkujen sujuvoittamiseksi.
  • Mittaa edistymistä jatkuvasti ja mukauta lähestymistapaasi tulosten perusteella.

Jos haluat lukea lisää haastatteluja ja saada DevOps-näkemyksiä, tilaa The CTO Clubin uutiskirje.

Katie Sanders
As a data-driven content strategist, editor, writer, and community steward, Katie helps technical leaders win at work. Her 15 years of experience in the tech space makes her well-rounded to provide technical audiences with first-hand operating wisdom so senior tech leaders can get clarity. Tech leaders want to learn from peers who’ve been there. Katie surfaces hard-won lessons that help leaders scale systems, teams, and strategy in the face of disruption. Katie is an Executive Editor at Black & White Zebra. She nurtures a large and diverse community of technical experts and writers, and she knows that a thriving community doesn't grow without thoughtfulness, advocacy, and intention. Interested in being reviewed? Find out more here.
Follow the author:

You may also like