Jos et ymmärrä mitä DevOps on, tässä on nopea huijauslehti. DevOps on joukko käytäntöjä, jotka vähentää insinöörien pelkoa ja vähentää ohjelmistotuotannon virheiden määrää. Yleensä ne ovat samat vähentää markkinoille tuloaikaa — ajanjakso ideasta lopputuotteen toimittamiseen asiakkaille, mikä mahdollistaa nopean toteuttamisen yrityskokeiluja.
Kuinka aloittaa DevOps-muunnos? Lyhyesti: valitsemme palvelun, jolla prosessi käynnistetään, tunnistamme palveluun liittyvät, rakennamme Value Stream Map -kartan, luomme väliaikaisen tiimin, joka käsittelee muutosta ensimmäistä kertaa ja asetamme sille tehtävän. Toistamme syklin tarvittavan määrän kertoja.
Yksityiskohtainen DevOps-muunnossuunnitelma esimerkkeineen ja ohjeineen leikkauksen alla - transkriptiossa Andrei Aleksandrov - Express42:n insinööri, joka neuvoo DevOpsin itämisessä ja nopeuttaa tätä prosessia, koska hän on jo rakentanut rake-kartan. Jos sinusta tuntuu, että et tarvitse muutosta tai erityispiirtesi ovat sellaiset, että DevOps-käytännöt eivät sovellu, käytä raporttia ohjeena rajoitusten löytämiseen ja poistamiseen.
Jos olet huolissasi DevOps-muunnosongelmasta, sinulla on suuri yritys, ja sinun on asteittain skaalattava tämä prosessi koko rakenteen läpi. Niin kauan kuin komentoa on muutettava tai jokin rajoitus poistettava, alla olevaa algoritmia voidaan toistaa.
Palvelun valinta
Olemme laatineet suunnitelman, aloitetaan ensimmäisestä vaiheesta - palvelun valinnasta. Ensimmäinen kriteeri on elinikä: on vanhoja palveluita - vanhoja ja uusia. Voit aloittaa molemmilla.
On loogista valita nuori palvelu. Se on tuore, eikä sitä käsittelevässä tiimissä ole vielä vakiintunutta prosessia. Sen ympärillä ei ole teknistä velkaa, sinun ei tarvitse korjata sitä koko ajan. Voimme tehdä sillä mitä haluamme.
Vanhan palvelun tapauksessa siihen liittyy ongelmia muutos on aina vaikeaa. On jo olemassa joukko vakavia rajoituksia, mutta ehkä niitä käsittelevät ihmiset, jotka ovat valmiita lapioimaan kaiken - he ovat väsyneitä ja haluavat tehdä jotain toisin, koska heillä on kipua.
Työskentely vanhan palvelun kanssa on vahva ennakkotapaus yrityksessäsi - voit muuttaa jotain. Jos muutat uutta palvelua, se rullaa alas 100 kertaa tunnissa ja kaikki on hyvin, yrityksesi ihmiset saattavat sanoa:
- Tämä on uusi palvelu! Siellä kaikki oli yksinkertaista, yritä tehdä jotain hylkyllemme.
Legacy-palvelua on järkevää käyttää muuntamiseen, kun teet sen jonkun kanssa, esimerkiksi jos olet kutsunut ulkopuolisen konsultin. Olkaamme rehellisiä, muutos ravistaa kaikkea mahdollista. Kokeilet etkä tiedä mihin päädyt, mitä tekniikoita käytät ja miksi, missä ja mitä sudenkuoppia prosesseissa syntyy. Siksi on helpompi vaihtaa uusi.
Jos teet kaiken itse, eikä yrityksellä ole vakavaa osaamista, otamme uuden palvelun. Jos tunnet ulkopuolisen konsultin ja sinulla on varaa, valitse vanha.
On palveluita, jotka ovat vain käyttöliittymä käyttäjille, esimerkiksi yksinkertainen verkkosivusto tai mobiilisovellus. Mutta laskutuksen hengessä on vakavia asioita. Jos laskutuksessa menee pieleen, sitä on vaikea selvittää. Tässä meillä on myös valinnanvaraa.
Työskentelemme joko kriittisen palvelun kanssa, mutta kärsimme sen takia, se luo rajoituksia tai teemme työtä käyttöliittymän kanssa. Tämä on toinen valintakriteeri. Samoin on mahdollista houkutella kokenut konsultti - työskentelemme vaikean vaihtoehdon kanssa.
Mutta tässäkään tapauksessa en suosittele tätä, koska ennen kuin ei ole ymmärrystä siitä, mitä tehdä ja mihin suuntaan muuttaa, kriittisen asian ottaminen ja ravistaminen ei ole kovin hyvä idea. Siksi tässä tapauksessa käytämme mieluummin käyttöliittymää, jonka vika ei ole kriittinen.
Katsotaanpa pidemmälle palveluryhmä. Meidän on työskenneltävä jatkuvasti ja oltava erittäin tiiviissä vuorovaikutuksessa tämän palvelun tarjoajien kanssa.
Ryhmän ihmiset jaetaan kahteen luokkaan: konservatiivit - elä vanhassa maailmassa tai et yksinkertaisesti tiedä mitään DevOpsista ja uudistajia, jotka vetävät kaikki muodikkaita käytäntöjä. Jälkimmäiset eivät aina ymmärrä aihetta, mutta ovat ainakin valmiita siihen.
Toisaalta konservatiivit ovat kokeneita ihmisiä: he ovat olleet yrityksessä pitkään, ymmärtävät sen sisältä ja ulkoa, mutta eivät tiedä tarkalleen käytännöistä. Toisaalta on keksijöitä, jotka ovat kuulleet jotain, mutta eivät todennäköisesti ole työskennelleet yrityksessä kovin pitkään. Kumman kanssa on parempi työskennellä?
Joudut joka tapauksessa olemaan vuorovaikutuksessa konservatiivien kanssa, koska tämä on heidän palvelustaan. Sinun täytyy kommunikoida heidän kanssaan, selvittää palvelun erityispiirteet, mitä voidaan tehdä tällä tavalla ja mitä muuta. Olemme riippuvaisia heidän neuvoistaan. Sinun on luultavasti uskottava heille jotain, koska he tietävät palvelunsa paremmin. Siksi on tärkeää, mihin tiimiin olemme yhteydessä.
On loogista valita tiimiin uudistajia, sillä konservatiivit voivat laittaa porsaan.
Käytännössä usein käy niin, että konservatiivisilla ihmisillä on merkittävää kokemusta, mutta heillä ei ole ymmärrystä siitä, kuinka elää eteenpäin. He vain pelkäävät, että palvelun muutoksen ja uudelleensuunnittelun jälkeen heidät irtisanotaan tarpeettomina. Joskus he sabotoivat työtä, koska he eivät ymmärrä mitä tapahtuu.
Minulla oli tapaus, jossa kaveri tiimistä korjasi kaiken, koska se oli oletettavasti kriittisempi kuin se, mitä nyt teemme. Asetamme tehtävän: toteuttaa tämä kappale tänään - ei, toisella puolella maailmaa on tulipalo, aiomme korjata sen. Tällaisten ihmisten kanssa on vaikea työskennellä.
Konservatiivisen tiimin ihmiset unohtavat usein tehtävät tai lykkäävät niitä viime hetkellä. Ja jos, John Willis kieltää, teit virheen ja määritit heille KPI:n suoritettujen tehtävien määrälle, ja jostain syystä jotain osaa ei sisällytetty KPI: hen, he eivät tee mitään. Yleensä he ovat oikeassa, koska silloin he menettävät bonuksen.
Innovaattoreiden kanssa se on helpompaa – he ovat uskollisempia. He ovat jo kuulleet jotain, he haluavat mennä jonnekin, joten he auttavat. Tarvitsemme ihmisiä, jotka ovat valmiita kärsimään ensimmäistä kertaa: jos palvelu muuttuu, innovaattorit tarttuvat edelläkävijöinä kaikkiin kohuihin ja haravoihin. Innovaattorit haluavat kaikkea uutta ja muodikasta ja kärsivät.
Konservatiivit voivat myöhemmin kääntyä. Kun näytät, että vaihdoit kappaletta ja kaikki toimii hyvin, he todennäköisesti haluavat myös kokeilla sitä ja omaksuvat uuden DevOps-uskonnon.
Tehdään yhteenveto. Jos teemme koko muutoksen yrityksessämme itse, valitsemme: uuden palvelun, mieluiten yksinkertaisen käyttöliittymän, jotta se ei kärsi liikaa sen rikkoutumisesta, ja innovaattoritiimin.
Jos on mahdollista kutsua ulkopuolinen konsultti, otamme uuden palvelun sijaan vanhan palvelun, jonka takia jo nyt kärsimme. Muutostyössä pitkään eri yrityksissä mukana olleet ihmiset ovat nähneet erilaisia tapauksia ja ymmärtävät jo, miten se tehdään oikein ja mihin suuntaan ylipäätään mennään.
Kuka on mukana?
Meidän on löydettävä kaikki, joilla on ainakin jonkinlainen suhde palveluun: kehittäjät, testaajat, ylläpitäjät, tietoturvaasiantuntijat, johtajat ja mahdollisesti tuotteen omistajat. Huolimatta siitä, että Tuoteomistajat eivät ole teknisiä asiantuntijoita, he ovat yhteydessä palveluun: he tekevät päätöksiä, asettavat tehtäviä.
Jokainen, joka tekee ainakin jonkin verran päätöksiä ja vaikuttaa siihen, mitä palvelussa tapahtuu, on löydettävä, tavattava ja viestittävä.
Mihin me niitä tarvitsemme? Tietääkseen kenen kanssa neuvotella. Muutoksen aikana, kun tavallinen palvelun kanssa työskentelyperiaate muuttuu, se edelleen tärisee. Vikoja tulee jonkin aikaa, kun testaamme uusia lähestymistapoja. Ihmisten on oltava valmiita tähän ja hyväksyä se.
Seuraavaksi sinun on rakennettava Arvovirtakartta, ja ilman näitä ihmisiä et voi rakentaa sitä, koska vain he kaikki yhdessä tietävät täydellisen kuvan siitä, mitä tapahtuu. Yksi ihminen ei koskaan tiedä kaikkea, mitä palvelussa tapahtuu.
He suosittelevat ihmisiä tiimiin, myöhemmin keskustellaan, miksi erillistä tiimiä tarvitaan. Sen on otettava ihmisiä olemassa olevilta osastoilta. Palveluun osallistuvat voivat suositella meidän suuntaan ajattelevia, meitä auttavia ja osaavia työtovereita.
Seuraavaksi kokoamme kaikki nämä ihmiset eri osastoilta yhteen huoneeseen ja alamme rakentaa arvovirran karttaa.
Arvovirtakartan rakentaminen
Arvovirtakartta on kaavio tai kartta, joka näyttää arvojen kulun asiakkaalle. Tämä on koko prosessi idean keksimisestä sen toteutukseen, sisältäen kaikki välivaiheet ja kuinka arvo lopulta päätyy asiakkaillemme.
Arvovirtakartta tarvitaan visualisoida kaikki kehitysvaiheet, paikallistaa ongelmat nykyisessä prosessissa olevien mittausten avulla ja alkaa poistaa näitä ongelmia, ja aseta alkuperäinen tavoite. Tästä alamme oikeasti tehdä jotain.
Mittarit
Value Stream Map -kirjallisuudessa on kuvattu monia erilaisia mittareita, mutta vain kolme riittää aloittamaan.
Toimitusaika - viive/odota - aika, jolloin odotamme jotain. Esimerkiksi testaaja odottaa, kunnes testiteline on vapaa, eikä voi tänä aikana tehdä mitään.
Lisäarvoa - hyödyllistä työaikaa - mitä käytimme tässä ja sellaisessa vaiheessa luodaksemme loppuarvon käyttäjälle. Esimerkiksi testaaja käynnisti testinsä ja alkoi tarkistaa jotain. Tämä on hyödyllisen työn aikaa, jolloin todellakin tehdään jotain tuotteen hyväksi. Tästä asiakkaat maksavat – laadukkaasta ohjelmistosta.
%C/A on hyväksytyn työn prosenttiosuus. Meillä on yksi vaihe - kehitys, toinen vaihe - testaus. Kuinka monta ominaisuuksia testaajat ovat hyväksyneet kehittäjiltä, on tämä prosenttiosuus.
Karttamme näyttää suunnilleen tältä.
Se voi näyttää erilaiselta riippuen organisaation rakenteesta, osastojen lukumäärästä ja tehtävistäsi. Mutta yleensä kartalla on kaksi vaihetta: ajatus и analytics. Tässä vaiheessa tietoja odotetaan, esimerkiksi toimitusaika 2 viikkoa ja lisäarvoaika 2 päivää.
Katamme täysin kaikki vaiheet mittareilla.
kasauma — kuinka paljon ongelmia oli sen jälkeen, kun analyytikot keksivät ne.
suunnittelu - kuinka monta viikkoa kehittäjät ovat odottaneet selvitystä tehtävistä, telineistä tai laitteista - sillä ei ole väliä, mutta he odottavat jotain. Esimerkiksi ominaisuuden käyttöönotto kestää 4 päivää. Tässä tulee esiin %C/A-mittari. Kehittäjät ottivat vain 80% tehtävistä Backlogista. He uskovat, että lopuilla 20 prosentilla ei ole tarpeeksi selkeää teknistä eritelmää, ja lähettivät ne tarkistettavaksi.
Testaus. LT-kaavio on asetettu 4 päiväksi. Esimerkiksi testaajat odottivat testipenkin vapautumista, VA testasivat jotain 2 päivää ja %C/A = 40%. — Testaajat pitivät vain 40 % kehittäjien lähettämästä koodista tai ominaisuuksista riittävinä. He eivät jostain syystä pitäneet kaikesta muusta.
En käsittele yksityiskohtaisesti näiden mittausten suorittamista; artikkelin lopussa suosittelen kirjallisuutta, josta voit oppia niistä.
Ainoa asia, jonka voin suositella, on, että et luota ihmisiin, jotka laativat kanssasi arvovirtakartan. Ne antavat käsityksen siitä, kuinka kauan eri prosessit kestävät, mutta nämä arviot eivät aina pidä paikkaansa, joten on parasta mitata itse.
Meillä oli tapaus, kun tulimme käyttöosastolle ja kysyimme, kuinka kauan uuden ominaisuuden toimittaminen tuotantoon kesti. He sanoivat meille, että se kestää 10 minuuttia, ja ajattelimme, miksi edes tulimme tähän yritykseen? Kävi ilmi, että 10 minuuttia on skriptin ajoaika, joka ottaa koodin ja toimittaa sen palvelimelle. Mutta ennen tätä julkaisu istuu palvelimella kolme päivää ja kerää vain pölyä - Backlogissa on tehtävä, joka on otettava käyttöön. Osoittautuu, että ennen käyttöönottovaihetta on odotusvaihe, jolloin projekti vain istuu siinä. Jos emme olisi menneet muistilehtiöllä, emme olisi kiinnittäneet huomiota Jiran tehtävään ja alkaneet seurata sitä askel askeleelta, olisimme luulleet, että kaikki oli hienoa eikä ongelmaa ollut.
Siksi sinun on silti tehtävä mittaukset itse, mieluiten useammin kuin kerran, jotta sinulla on idea lähellä todellisuutta. Arvovirran kartasta riippuen päätät, mistä aloittaa ja mitä korjata ensin.
Väliaikainen joukkue
Monet yritykset, jotka päättävät ottaa DevOpsin käyttöön, luovat tiimin, mutta eivät väliaikaisen, vaan useiden vuosien ajan. Jos siirryt DevOps apologize -palveluun, joka kuvaa erilaisia malleja organisaatiorakenteen rakentamiseen DevOpsissa, ymmärrät, että tämä on anti-malli.
Kun DevOps-tiimi on jatkuvasti olemassa useita vuosia, tämä on suuri virhe, koska DevOpsissa on kyse osastojen välisestä viestinnästä, nopeudesta ja tehokkuudesta.
Jos tiimi on olemassa osastojen välillä vain tehdäkseen jotain muuta erikseen ja on olemassa pitkään, se luo tarpeettoman esteen. Sen sijaan, että ohjelmoija menisi välittömästi järjestelmänvalvojan puoleen ratkaisemaan ongelma, hänen on ensin otettava yhteyttä DevOps-osastoon, niin hän jatkaa.
Siksi sinun on luotava väliaikainen tiimi aloittaaksesi. Se on voimassa ehdollisesti kuusi kuukautta, korkeintaan vuoden, riippuen käsiteltävästä tehtävästä, vain yhden valitsemamme rajoituksen poistamiseksi. Sitten hän kuolee. Jos valitsemme seuraavan kohdan, jossa meillä on paljon kipua ja ymmärrämme, että tarvitsemme siihen myös erillisen joukkueen, luomme sen uudelleen. Mutta tällaisten ryhmien ei pitäisi olla "pysyvästi" - silloin ne vain häiritsevät viestintää ja yleensä ottavat erillisiä tehtäviä saadakseen jotain aikaan. Nämä tehtävät eivät välttämättä liity DevOpsiin tai muuntamiseen ollenkaan. Miksi emme anna tätä tehtävää olemassa oleville osastoille?
Miksi väliaikainen tiimi tarvitaan?
Ristiriita nykyisten prosessien kanssa. DevOps-muutos ei ole vain muutos käyttämiimme teknologioihin ja työkaluihin, vaan muutos itse työprosessiin, ajatteluun ja arvoihin. Jos tiimi toimii niin kuin on jo tottunut, se ei voi kokeilla muita lähestymistapoja.
Näiden ihmisten on elettävä eri sääntöjen mukaan: jättää huomiotta kaikki yrityksen KPI:t, koska he yrittävät työskennellä eri tavalla. Väliaikaiset tiimit eivät täytä hakemuksia saadakseen palvelimen, vaan menevät suoraan niitä hoitavalle osastolle vaatien, että heille annetaan ensin mitä he tarvitsevat, koska se on prioriteetti ja koska he yrittävät elää toisin. Tiimi on täysin ristiriidassa kaikkien nykyisten prosessien kanssa. Jotta nykyiset työkäytännöt eivät häiritse heitä nyt, eivätkä ne häiritse muita, eristämme nämä ihmiset erilliseen tiimiin.
Byrokratian välttäminen kokeiluissa. Väliaikaisilla tiimeillä ei ole byrokratiaa, ne eivät tee aikaraportteja, he eivät raportoi esimiehille. Tämä on täysin erillinen maailma, jossa ihmiset elävät ja ajattelevat eri tavalla ja tekevät täysin eri asioita. Ei niitä tarvitse enää häiritä.
Palvelun parissa jatkuvaa työtä. Ensimmäisessä kohdassa valitsimme jotain, jota aiomme kokeilla. Kokeilu ja toimintatapojen löytäminen on hyvä asia, mutta haluamme myös tehdä ominaisuuksia. Jos koko tiimi keskittyy transformaatioon ominaisuuksien sijaan, alamme menettää tuloja, bugeja roikkuu pitkään - emme tarvitse tätä. Väliaikaisen tiimin luominen mahdollistaa kokeilun keskeyttämättä tuotteen parissa työskentelemistä.
Älä tuhlaa aikaa työtehtäviin. Kyse on taas tuotteesta. Muiden työkalujen ja juttujen kokeileminen vie paljon aikaa. Kestää vähintään kuusi kuukautta ennen kuin ihmiset hallitsevat työkalut, alkavat ottaa niitä käyttöön ja käyttää niitä normaalisti. Jos he keskittyvät myös tuotteeseen, kuusi kuukautta venyy kosmisesti. Jos ihmiset työskentelevät tuotteen parissa, he työskentelevät jälleen vanhoilla prosesseilla - emme tarvitse sitä.
Siksi osoitamme ihmisiä eri osastoilta erilliseen tiimiin, joka muuttaa palvelua. Tämän seurauksena palvelu toimii, kehittyy edelleen ja samalla teemme siihen joitain kokeiluja.
Väliaikainen tiimi on omistettu vain DevOps-muunnokselle - poistamalla löytämämme rajoituksen, eikä mitään muuta.
Ryhmä koostuu monipuolisista ihmisistä. Tämä tarkoittaa, että emme palkanneet vain kehittäjiä. Emme tulleet palvelukeskukseen ja ottaneet puolta tiimistä sieltä - ei, otimme ihmisiä eri osastoilta. Muutama piste sitten löysimme eri osastoja ja erilaisia työntekijöitä, jotka liittyvät muuttuneeseen palveluun. Rekrytoimme heistä tiimin, koska sen on oltava universaalia - muutamme testausprosessia, kehitysprosessia ja palvelun ylläpitoprosessia. Erilaista osaamista tarvitaan.
Yleensä otamme kehittäjän, testaajan ja insinöörin yksi kerrallaan, ja yhdessä heidän kanssaan keksitään ratkaisu, jonka avulla voimme elää eri tavalla.
On toivottavaa, että näillä ihmisillä on auktoriteettia organisaatiossa. Saatat joutua ottamaan yhden konservatiivin, vaikka et halua. Jos meillä on iso yritys, kaikki eivät usko ideaamme, ja jotkut saattavat laittaa puolan renkaihimme esimerkiksi jättämällä telineen. Täällä tarvitset "auktoriteettia" - arvostettua henkilöä, jolla on laaja kokemus ja joka on ansainnut kollegoidensa hyvän asenteen. Työntekijän auktoriteetti tiimissä yksinkertaistaa väliaikaisen tiimin tehtävää ja työtä. Ihmiset ajattelevat:
- Joo, tämä hieno jätkä, jonka me kaikki tunnemme ja rakastamme, sopii sinne - ilmeisesti DevOpsissa on jotain katsomisen arvoista!
Tavoitteen asettaminen
Keräsimme ihmisiä, valitsimme palvelun, tarkastelimme rajoituksia ja päätimme, mihin ihmisiin vaikutamme. Nyt sinun on asetettava tavoite ja sen pitäisi olla suora tekijältä SMART - kaikki mitä rakastamme.
Erityinen - spesifinen.
Mitattavissa - mitattavissa. Tämä on erittäin tärkeä SMART-kohta. Jos et voi mitata jotain, et voi muuttaa sitä ja ymmärtää, mitä ja miten teit paremmin tai huonommin.
Saavutettavissa - saavutettavissa. Tee säädöt tarpeidesi mukaan. Jos olet yritysyritys, jolla on pitkä historia ja suuri vastuukuorma ja joka julkaisee tuotteen version kerran vuodessa, et voi saavuttaa uusien versioiden julkaisua tuotteesta joka tunti kuuden kuukauden aikana. Se ei toimi niin. Aseta siksi realistinen tavoite, joka on saavutettavissa hyväksyttävässä ajassa.
Relevantti - relevantti. Poistamme vain ne rajoitukset, jotka todella palvelevat nykyisiä tavoitteitamme.
Aika rajoitettu - ajallisesti rajoitettu. Jos määräaikaa ei ole, tiimi tekee mitä haluaa: kokeilee 15 teknologiaa kolmen sijasta, kirjoittaa valtavia raportteja, tekee hyödytöntä tutkimusta, hioa niiden toteutusta, kunnes se loistaa, kun tavoite on jo saavutettu.
Otamme tavoitteen Value Stream -kartan avulla - keräämme kaikki ihmiset uudelleen ja piirrämme heidät. Mutta vasta nyt, edellisen arvovirtakartan perusteella, piirrämme sen, mitä haluamme saada.
Korostamme yhden rajoituksen, jonka poistamme juuri nyt - näin joukkue tekee. Esimerkkinä otin odotuksen valmiista julkaisusta sen käyttöönottoon tuotannossa - tämä on yleisin rajoitus, jolla ihmiset kääntyvät konsulttien puoleen.
Tämän perusteella asetimme tehtävän: haluamme, että valmiin julkaisun ja taisteluun menemisen välinen odotus kestää enintään tunnin.
Esimerkkejä tehtävistä.
- Lyhennä testauksen läpimenoaikaa 4 päivästä 1 tuntiin.
- Vähennä testaukseen kuluvaa lisäarvoa 2 päivästä 3 tuntiin.
- Lyhennä käyttöönottoaikaa 5 tunnista 10 minuuttiin.
- Kasvata C/A 50 %:sta 95 %:iin eli lisää testaajien hyväksymien ominaisuuksien määrää, eli paranna kehittäjien työn laatua.
Esimerkit tehtävistä eivät ole otettu meidän päästämme, vaan ne perustuvat mittauksiin, joita teimme kehitettäessä arvovirtakarttaa.
Asetamme tiimillemme samanlaisen tehtävän ja aikarajan. Sen mukaan, kuinka hyvin yrityksesi menee, asetat erilaisia määräaikoja. Keskimäärin rajoituksen poistaminen kestää yleensä kuusi kuukautta, jos ihmiset tekevät tämän ensimmäistä kertaa eivätkä vielä tiedä, millä tekniikoilla ja kuinka tarkasti he ratkaisevat ongelman.
Lyhyt suunnittelu
Joten tiimimme on luotu, sillä on tavoite, ihmiset alkavat työskennellä. Tärkeä kohta on lyhyt työn suunnittelu: sprinttejä yhdestä kahteen viikkoaeikä enempää, mitattavissa olevia parannuksia joka viikko ja kurssin korjaus.
Käytämme esimerkiksi usein lähestymistapaa liikkuva-liikkuvaKun koko tiimi kokoontuu jokaisen viikon alussa, he kirjaavat tiedostoon, mitä jokainen tekee. Viikon kuluttua kirjataan, mitä on tehty ja mitä ei, jos ei, niin miksi, ja mietitään mitä tehdä seuraavaksi.
Sprinttien avulla voit tehdä oikea-aikaisia kurssikorjauksia.
Viikon tai parin kokeilit jotain: tekniikoita, lähestymistapoja, toimintatapoja, sen jälkeen mittaat uudestaan ja katsot - onko parempaa vai huonompaa tällä lähestymistavalla? Jos se on huonompi, se tarkoittaa, että olemme menossa väärään suuntaan, meidän on korjattava kurssi: asetettava toinen tehtävä, otettava erilainen tekniikka tai tehtävä jotain muuta. Lyhyet 1-2 viikon sprintit antavat sinun liikkua ja välttää huonot päätökset ajoissa.
Menestyksen jakaminen
Joukkue saavuttaa jonkin verran menestystä, pientä tai suurta - sillä ei ole väliä, aina on jokin tulos. Kaikkien pitäisi tietää tästä tuloksesta: sekä DevOpsiin osallistuneiden että naapuriosastojen. Ihanteellisessa maailmassa olisi toivottavaa, että tämä ylipäänsä saapuisi kaikille yrityksen ihmisille.
Minkä vuoksi? Jos haluamme muuttaa ei vain osaa yrityksestä, poistaa ei vain yhtä rajoitusta, vaan kaikkea yleisesti, jotta yritys muuttuu joustavaksi, koodi saavuttaa nopeasti asiakkaan, eikä mikään hajoa, meidän on kaikkien oltava uskollisia idealle DevOpsista. Et voi soveltaa lähestymistapaa palveluihin ja tiimeihin, jotka vastustavat sitä jyrkästi.
Jotta uskollisuus ilmaantuisi, meidän on kerrottava kaikille, että olemme kokeilleet tätä - meillä on tuloksia, kokeile sinäkin! Tämä lisää kiinnostusta ja uskollisuutta toimintaamme kohtaan, ihmiset alkavat yrittää tehdä jotain juuri nyt. Kuten käytäntö osoittaa, kun kerromme, mitä yritimme ja mitä saavutimme, muut tiimit alkavat kysyä, miten ja mitä teimme. He katsovat toteutuksia, koodia, dokumentaatiota, esittävät kysymyksiä ja yrittävät muuttaa jotain itsestään.
On tärkeää puhua siitä, mitä teit. Näin vakuutat konservatiivit, jotka halusivat tehdä kaiken vanhalla tavalla, liittymään leiriisi ja muuttamaan heistä uudistajia.
Yhteensä
Palvelun valinta, lähtökohtana - paikka, josta aloitamme muutokset yrityksessä. Tunnistamme kaikki, joilla on jotain tekemistä palvelun kanssa ja heidän kanssaan arvovirran kartan rakentaminen, mittaamme ja katsomme missä ja mitkä rajoitukset ovat.
Uuden väliaikaisen tiimin luominen, joka ratkaisee ongelman. Perustuu mittauksiin ja arvovirtakarttaan piirrämme uuden kartan, jossa korostamme rajoitusta, jonka ratkaisemme. Tämän rajoituksen perusteella aseta tehtävä, joita joukkue käsittelee. Tehtävänä pitäisi olla välttämättä SMART - erityisiä, mitattavissa olevia, nykyisiin tehtäviin liittyviä ja ajallisesti rajoitettuja.
Toista prosessi, kunnes muutamme ehdottoman kaikki palvelumme vaadittuun muotoon ja poistamme kaikki rajoitukset.
Bonus. Hyödyllisiä materiaaleja
Niille, jotka päättivät tehdä DevOpsin itse.
Phoenix-projekti
Alkuperäinen nimi on "The Phoenix Project: A Novel about It, Devops, and Helping Your Business Win". Tämä on romaani DevOpsista - tarina siitä, kuinka työntekijästä tehtiin osaston päällikkö, joka oli aina tulessa. Uusi pomo sai tehtävän:
"Teillä on muutama vuosi aikaa saada kaikki kuntoon, jotta voimme vihdoin toimittaa tuotteemme asiakkaillemme nopeasti ja tehokkaasti."
"Projekti Phoenix" Romaani siitä, kuinka DevOps muuttaa elämää parempaan suuntaan” on kirja kaikille johtajille, koska he tekevät päätöksiä siitä, mitä yrityksessä tapahtuu. Jos olet insinööri tai ohjelmoija ja haluat liikkeen ja muutoksen alkavan yrityksessäsi, osta kirja ja anna se johdolle. Tämä romaani selittää kaiken ja on nopeaa ja helppoa luettavaa.
DevOps-opas
Kirja on monimutkaisempi. Se julkaistiin useita vuosia sitten englanniksi otsikolla "The DevOps Handbook How to Create agility, reliability and security in Technology Organisations", mutta nyt se on jo saatavilla venäjäksi. Tämä on todellista käsikirja - käytännön opas: miten mittaukset suoritetaan, mikä arvovirtakartta on ja miksi sitä tarvitaan, minne mennä, missä järjestyksessä. Kirja on tarkoitettu vain niille, jotka haluavat tehdä kaiken itse. Mikä tärkeintä, se sisältää esimerkkejä muiden yritysten kokemuksista.
Se kertoo esimerkiksi, kuinka yksi yritys rakensi Value Stream Map -kartan ja tajusi, että sen rajoitus ei ollut tuotteessa, vaan siinä, että kassa käveli kaupasta seuraavaan toimistoon käyttämään tätä tuotetta. Sen sijaan, että he olisivat ratkaisseet ongelman ohjelman avulla, he ostivat myyjilleen tabletteja, ja nyt kukaan ei mene minnekään, ja kaikki toimet suoritetaan heidän työpaikallaan. Johtopäätös: Value Stream Map voidaan laajentaa ohjelmistojen lisäksi kaikkiin organisaation prosesseihin.
Kiihdyttää
Koko nimi: "Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organisations." Tämä on seuraava taso - hardcore. Kirja julkaistiin viime vuonna, toistaiseksi vain englanniksi ja se käsittelee tutkimusta. Kirjoittajat – Nicole Forsgren, Jez Humble ja Gene Kim – ovat käyttäneet erilaisia käytäntöjä eri yrityksissä useiden vuosien ajan ja tutkineet, mitkä käytännöt vaikuttavat mihin ja miten.
Toisessa mittausta käsittelevässä luvussa mainitaan Value Stream Map, mainitsemani mittarit ja monet muut sekä kuvataan mittausprosessi yksityiskohtaisesti. Kirjoittajat mittaavat kyselylomakkeilla ja itseseurantatehtävillä. Siinä kuvataan yksityiskohtaisesti mitkä mittarit ovat oikein mitattuja, mitä ei pidä mitata, sekä inhimilliset virheet mittauksissa. Jos sinulla on vaikeuksia mittausten kanssa, katso kirjan "Kiihdytys" toista lukua. Jos tiimilläsi on vain paljon käytäntöjä, mutta ei ole selvää, mitä käytäntöjä soveltaa nyt, mitä myöhemmin, mitkä todella toimivat ja mitkä eivät - lue, kirja selittää kaiken.
Muutos on ongelma DevOpsin ja hallinnan risteyksessä. Jossain samalla kehittämisen, toiminnan ja testauksen risteysalueella ovat aiheet, joista yritämme keskustella , samaa integraatiota tarvitaan laadukkaan tuotteen luomiseen - pääaihe . Festivaalin hallinta esitetty - Tämä tarkoittaa, että kaikki ovat valmiita ideoimaan muutosta. Liity joukkoomme 27. ja 28. toukokuuta, integroitumme ja muutumme.
Lähde: will.com
