Če ne razumete, kaj je DevOps, je tukaj kratek goljuf. DevOps je nabor praks, ki zmanjšuje strahove inženirjev in zmanjšati število napak v proizvodnji programske opreme. Praviloma so enaki skrajšati čas do trga — obdobje od ideje do dostave končnega izdelka kupcem, kar omogoča hitro izvedbo poslovni poskusi.
Kako začeti transformacijo DevOps? Na kratko: izberemo storitev, s katero začnemo proces, identificiramo tiste, ki so povezani s storitvijo, zgradimo Value Stream Map, ustvarimo začasno ekipo, ki se bo prvič ukvarjala s transformacijo in ji postavimo nalogo. Cikel ponovimo zahtevano število krat.
Podroben načrt transformacije DevOps s primeri in navodili pod rezom - v prepisu Andrej Aleksandrov - inženirka pri Express42, ki svetuje o kalitvi DevOps in pospeši ta proces, ker je že zgradila zemljevid rake. Če se vam zdi, da transformacije ne potrebujete ali pa so vaše specifike takšne, da DevOps prakse niso primerne, uporabite poročilo kot navodila za iskanje in odpravo omejitev.
Če vas skrbi vprašanje transformacije DevOps, potem imate veliko podjetje in morate postopoma razširiti ta proces po celotni strukturi. Dokler je treba preoblikovati ukaz ali odpraviti kakšno omejitev, se lahko ponavlja spodnji algoritem.
Izbira storitve
Načrt smo začrtali, začnimo s prvim korakom – izbiro storitve. Prvi kriterij je življenjska doba: obstajajo stare storitve - podedovane in nove. Lahko začnete z obema.
Logično je izbrati mlado službo. Svež je, ni še ustaljenega procesa dela v ekipi, ki se s tem ukvarja. Okoli njega ni gora tehničnega dolga, ni vam ga treba ves čas popravljati. Z njim lahko počnemo, kar hočemo.
Pri stari službi so težave povezane s tem, da sprememba je vedno težka. Nekaj resnih omejitev je že nabor, ampak morda se z njimi ukvarjajo ljudje, ki so pripravljeni vse z lopato potresti - utrujeni so in hočejo narediti nekaj drugače, ker jih boli.
Delo s staro storitvijo predstavlja močan precedens v vašem podjetju - lahko nekaj spremenite. Če zamenjate novo storitev, se ta ustavi 100-krat na uro in je vse v redu, potem bi lahko ljudje v vašem podjetju rekli:
- To je nova storitev! Tam je bilo vse preprosto, poskusite nekaj narediti z našo razbitino.
Storitev Legacy je smiselno uporabiti za transformacijo, ko to počnete z nekom, na primer, če ste povabili zunanjega svetovalca. Bodimo iskreni, preobrazba bo zamajala vse mogoče. Eksperimentirate in ne veste, kje boste prišli, katere tehnologije boste uporabili in zakaj, kje in kakšne pasti se bodo pojavile v procesih. Zato je lažje zamenjati novega.
Če vse naredite sami in podjetje nima resnih kompetenc, vzamemo novo storitev. Če poznate zunanjega svetovalca in imate sredstva, izberite starega.
Obstajajo storitve, ki so preprosto vmesnik za uporabnike, na primer preprosto spletno mesto ali mobilna aplikacija. So pa v duhu obračunavanja resne stvari. Če gre kaj narobe pri obračunavanju, bo to težko ugotoviti. Tukaj imamo tudi izbiro.
Delamo bodisi s kritično storitvijo, vendar zaradi tega trpimo, ustvarja omejitve ali delamo z vmesnikom. To je drugo merilo izbire. Podobno je mogoče privabiti izkušenega svetovalca - delamo s težko možnostjo.
Toda tudi v tem primeru tega ne bi priporočal, ker dokler ni razumevanja, s čim delati in v katero smer preoblikovati, vzeti kritično stvar in jo pretresti, ni dobra ideja. Zato v tem primeru raje delamo z vmesnikom, katerega okvara ni kritična.
Poglejmo naprej servisna ekipa. Nenehno bomo morali sodelovati in zelo tesno sodelovati s tistimi, ki zagotavljajo to storitev.
Ljudje v ekipi so razdeljeni v dve kategoriji: konservativci — živijo v starem svetu ali preprosto ne vedo ničesar o DevOps, in inovatorji, ki vlečejo vse modne prakse. Slednji ne razumejo vedno teme, so pa vsaj pripravljeni nanjo.
Po eni strani so konzervativci izkušeni ljudje: v podjetju so že dolgo, razumejo ga znotraj in zunaj, vendar ne poznajo natančno praks. Na drugi strani pa so inovatorji, ki so nekaj slišali, a najverjetneje v podjetju ne delajo prav dolgo. S katerim je bolje delati?
V vsakem primeru boste morali komunicirati s konzervativci, saj je to njihova služba. Z njimi boste morali komunicirati, ugotoviti posebnosti storitve, kaj je mogoče storiti na ta način in kaj še. Odvisni smo od njihovih nasvetov. Verjetno jim boste morali kaj zaupati, saj bolje poznajo svojo storitev. Zato je pomembno, s katero ekipo na koncu pridemo v stik.
Logično je, da za ekipo izberemo inovatorje, saj lahko konservativci vanj vtaknejo prašiča.
V praksi se pogosto zgodi, da imajo konzervativni ljudje veliko izkušenj, vendar ne razumejo, kako živeti naprej. Preprosto se bojijo, da jih bodo po preoblikovanju in preoblikovanju službe odpustili kot nepotrebne. Včasih preprosto zato, ker ne razumejo, kaj se dogaja, sabotirajo delo.
Imel sem primer, ko je fant iz ekipe vse popravil, ker je bilo menda bolj kritično kot to, kar delamo zdaj. Postavili smo si nalogo: izvesti ta del danes - ne, na drugem koncu sveta je požar, popravili ga bomo. S takimi ljudmi je težko delati.
Ljudje iz konservativne ekipe pogosto pozabljajo na naloge ali jih odlagajo na zadnji trenutek. In če ste, ne daj John Willis, naredili napako in jim dodelili KPI za število opravljenih nalog in iz nekega razloga kakšen del ni bil vključen v KPI, potem ne bodo storili ničesar. Na splošno bodo imeli prav, ker potem izgubijo bonus.
Z inovatorji je lažje - bolj so zvesti. Nekaj so že slišali, želijo nekam iti, zato bodo pomagali. Potrebujemo ljudi, ki so pripravljeni prvič trpeti: če se storitev spremeni, bodo inovatorji kot pionirji ujeli vse udarce in rake. Inovatorji želijo vse novo in modno in trpijo.
Konservativci se lahko pozneje spreobrnejo. Ko pokažete, da ste del spremenili in vse deluje dobro, ga bodo najverjetneje želeli preizkusiti tudi oni in bodo sprejeli novo vero DevOps.
Naj povzamemo. Če celotno preobrazbo v našem podjetju naredimo sami, potem izberemo: novo storitev, po možnosti preprost vmesnik, da ne bi preveč trpeli zaradi njenega razpada, in ekipo inovatorjev.
Če je mogoče poklicati zunanjega svetovalca, namesto novega vzamemo staro storitev, zaradi katere že tako trpimo. Ljudje, ki se že dolgo ukvarjajo s transformacijo v različnih podjetjih, so videli različne primere in že razumejo, kako to storiti pravilno in v katero smer na splošno iti.
Kdo je vpleten?
Najti moramo vse, ki imajo vsaj malo zveze s storitvijo: razvijalce, preizkuševalce, skrbnike, strokovnjake za varnost, menedžerje in po možnosti lastnike izdelkov. Kljub temu, da Product Owners niso tehnični strokovnjaki, so povezani s storitvijo: sprejemajo odločitve, postavljajo naloge.
Vse, ki sprejemajo vsaj nekatere odločitve in vplivajo na dogajanje s storitvijo, je treba poiskati, spoznati in komunicirati.
Za kaj jih potrebujemo? Vedeti, s kom se pogajati. Med transformacijo, ko se običajno načelo dela s storitvijo spremeni, se bo še vedno treslo. Dokler preizkušamo nove pristope, bodo nekaj časa prihajale do napak. Ljudje morajo biti na to pripravljeni in se s tem strinjati.
Nato boste morali zgraditi zemljevid toka vrednosti in brez teh ljudi ga ne boste mogli zgraditi, saj le vsi skupaj poznajo celotno sliko dogajanja. Ena oseba nikoli ne ve vsega, kar se dogaja s storitvijo.
Priporočili bodo ljudi za ekipo, kasneje se bomo pogovorili, zakaj je potrebna posebna ekipa. Vzeti bo moral ljudi iz obstoječih oddelkov. Tisti, ki se ukvarjamo s storitvijo, bomo lahko priporočili sodelavce, ki razmišljajo v naši smeri, ki nam lahko pomagajo in so kompetentni, kar potrebujemo.
Nato zberemo vse te ljudi iz različnih oddelkov v eno sobo in začnemo graditi zemljevid toka vrednosti.
Izdelava zemljevida toka vrednosti
Zemljevid toka vrednosti je diagram ali zemljevid, ki prikazuje pretok vrednosti do stranke. To je celoten proces od nastanka ideje do njene izvedbe, vključno z vsemi vmesnimi fazami in načinom, kako vrednost na koncu pride do naših strank.
Zemljevid toka vrednosti je potreben za vizualizirati vse stopnje razvoja, lokalizirati težave z meritvami, ki obstajajo v trenutnem procesu, in začeti odpravljati te težave ter postaviti začetni cilj. Tukaj začnemo dejansko nekaj narediti.
Metrike
V literaturi o zemljevidu toka vrednosti je opisanih veliko različnih meritev, a za začetek so dovolj samo tri.
Dobavni rok - zamuda/čakanje - čas, ko nekaj čakamo. Na primer, preizkuševalec čaka, da se testno stojalo sprosti, in v tem času ne more narediti ničesar.
Čas z dodano vrednostjo - koristen delovni čas - koliko smo porabili v tej in tej fazi, da smo ustvarili končno vrednost za uporabnika. Na primer, tester je zagnal svoj test in začel nekaj preverjati. To je čas koristnega dela, ko dejansko naredimo nekaj za izdelek. To je tisto, za kar stranke plačajo - kakovostno programsko opremo.
%C/A je odstotek sprejetega dela. Imamo eno fazo - razvoj, drugo fazo - testiranje. Ta odstotek je število preizkuševalcev funkcij, ki so jih sprejeli od razvijalcev.
Takole je približno videti naš zemljevid.
Morda je videti drugače, odvisno od strukture organizacije, števila oddelkov in tega, kaj počnete. Toda na splošno bosta na zemljevidu dve stopnji: ideja и analitika. Na tej stopnji se pričakujejo podatki, na primer dobavni rok 2 tedna in čas dodane vrednosti 2 dni.
Z metriko pokrivamo popolnoma vse stopnje.
Zaostanek — koliko težav je bilo potem, ko so jih analitiki odkrili.
Razvoj - koliko tednov so razvijalci čakali na pojasnila o nalogah, stojalih ali opremi - ni pomembno, vendar nekaj čakajo. Za implementacijo funkcije potrebujejo na primer 4 dni. Tu nastopi metrika %C/A. Razvijalci so vzeli le 80% nalog iz Backlog-a. Menijo, da preostalih 20% nima dovolj jasne tehnične specifikacije, in so jih poslali v revizijo.
Testiranje. LT diagram je nastavljen na 4 dni. Na primer, preizkuševalci so čakali, da se sprosti testna miza, VA dejansko so nekaj testirali 2 dni in %C/A = 40 %. — samo 40 % kode ali funkcij, ki so jih poslali razvijalci, so preizkuševalci ocenili kot ustrezne. Vse drugo jim iz nekega razloga ni bilo všeč.
Ne bom se podrobneje ukvarjal s tem, kako izvesti te meritve, na koncu članka bom priporočil literaturo, iz katere se lahko naučite o njih.
Edino, kar lahko priporočam, je, da ne zaupate ljudem, ki bodo skupaj z vami sestavili zemljevid toka vrednosti. Zagotavljajo predstavo o tem, kako dolgo trajajo različni procesi, vendar te ocene niso vedno pravilne, zato je najbolje, da izmerite sami.
Imeli smo primer, ko smo prišli v operativni oddelek in vprašali, koliko časa je trajalo, da smo novo funkcijo dobavili v proizvodnjo. Povedali so nam, da bo trajalo 10 minut, in pomislili smo, zakaj smo sploh prišli v to podjetje? Izkazalo se je, da je 10 minut čas delovanja skripte, ki vzame kodo in jo dostavi na strežnik. Pred tem pa izdaja tri dni stoji na strežniku in preprosto nabira prah - v zaostanku je naloga, ki jo je treba namestiti. Izkazalo se je, da pred fazo uvajanja obstaja čakalna faza, ko projekt kar stoji. Če ne bi šli z beležko, ne bi opazili naloge v Jiri in ji začeli slediti korak za korakom, bi mislili, da je vse super in da ni težav.
Zato boste še vedno morali meritve opraviti sami, po možnosti večkrat, da boste imeli idejo blizu realnosti. Glede na zemljevid toka vrednosti se boste odločili, kje začeti in kaj najprej popraviti.
Začasna ekipa
Mnoga podjetja, ki se odločijo za implementacijo DevOps, ustvarijo ekipo, vendar ne začasno, ampak takšno, ki obstaja že nekaj let. Če obiščete storitev opravičila DevOps, ki opisuje različne vzorce za izgradnjo organizacijske strukture v DevOps, boste razumeli, da je to anti-vzorec.
Ko DevOps ekipa obstaja neprekinjeno več let, je to velika napaka, saj gre pri DevOps za komunikacijo med oddelki, za hitrost in učinkovitost.
Če ekipa obstaja med oddelki samo zato, da počne nekaj drugega ločeno, in obstaja dolgo časa, potem ustvarja nepotrebno oviro. Zdaj mora programer, namesto da bi takoj šel k administratorju, da reši težavo, najprej stopiti v stik z oddelkom DevOps in bo šel naprej.
Zato morate za začetek ustvariti začasno ekipo. Pogojno bo obstajal šest mesecev, največ eno leto, odvisno od naloge, ki jo opravljamo, le da odpravimo eno omejitev, ki smo jo izbrali. Potem bo umrla. Če izberemo naslednjo točko, kjer imamo veliko bolečine in se zavedamo, da tudi za to potrebujemo ločeno ekipo, potem jo bomo znova ustvarili. Toda takšne ekipe ne bi smele obstajati "stalno" - potem le motijo komunikacijo in na splošno prevzemajo ločene naloge samo zato, da nekaj naredijo. Te naloge morda sploh niso povezane z DevOps ali transformacijo. Zakaj te naloge ne damo obstoječim oddelkom?
Zakaj je potrebna začasna ekipa?
Konflikt s trenutnimi procesi. DevOps transformacija ni le sprememba tehnologij in orodij, ki jih uporabljamo, temveč sprememba samega procesa dela, razmišljanja in vrednot. Če bo ekipa delovala tako, kot je vajena, ne bo mogla preizkušati drugih pristopov.
Ti ljudje morajo živeti po drugačnih pravilih: ignorirati vse KPI-je v podjetju, ker poskušajo delati drugače. Začasne ekipe ne bodo izpolnjevale vlog za pridobitev strežnika, ampak bodo šle direktno na službo, ki jih vodi, in zahtevale, da jim najprej dajo tisto, kar potrebujejo, ker je to prioriteta in ker poskušajo živeti drugače. Ekipa je v popolnem konfliktu z vsemi trenutnimi procesi. Da bi zagotovili, da obstoječe delovne prakse zdaj ne motijo njih in ne motijo drugih, te ljudi izoliramo v ločeno ekipo.
Izogibanje birokraciji pri poskusih. Začasne ekipe nimajo birokracije, ne pišejo poročil o delovnem času, ne poročajo vodjem. To je popolnoma ločen svet, v katerem ljudje živijo in razmišljajo drugače in počnejo popolnoma različne stvari. Ni jih treba znova motiti.
Neprekinjeno delo na servisu. V prvi točki smo izbrali nekaj, kar bomo eksperimentirali. Eksperimentiranje in iskanje načinov za boljše delo je dobro, vendar želimo izdelati tudi funkcije. Če se celotna ekipa osredotoči na transformacijo namesto na funkcije, potem bomo začeli izgubljati dohodek, hrošči bodo dolgo časa naokoli - tega ne potrebujemo. Ustvarjanje začasne ekipe vam omogoča eksperimentiranje, ne da bi prenehali delati na izdelku.
Ne izgubljajte časa z delovnimi nalogami. Spet gre za izdelek. Ekipa potrebuje veliko časa, da preizkusi druga orodja in stvari. Trajalo bo vsaj šest mesecev, da ljudje obvladajo orodja, jih začnejo implementirati in normalno uporabljati. Če se osredotočijo tudi na izdelek, se bo šest mesecev vesoljsko raztegnilo. Če ljudje delajo na izdelku, spet delajo s starimi procesi - tega ne potrebujemo.
Zato ljudi iz različnih oddelkov dodelimo ločeni ekipi, ki bo preoblikovala storitev. Kot rezultat, storitev deluje, se še naprej razvija, hkrati pa na njej izvajamo nekaj poskusov.
Začasna ekipa je namenjena le preobrazbi DevOps – odpravi omejitve, ki smo jo našli, in nič več.
Ekipo sestavljajo vsestranski ljudje. To pomeni, da nismo najeli samo razvijalcev. Nismo prišli v servisni center in od tam vzeli polovice ekipe - ne, vzeli smo ljudje iz različnih oddelkov. Pred nekaj točkami smo našli različne oddelke in različne zaposlene, ki so povezani s preoblikovano storitvijo. Iz njih rekrutiramo ekipo, ker mora biti univerzalna – spremenili bomo proces testiranja, proces razvoja in proces vzdrževanja storitev. Potrebne so različne kompetence.
Običajno enega po enega vzamemo razvijalca, preizkuševalca in inženirja ter skupaj z njimi pridemo do rešitve, ki nam omogoča, da živimo drugače.
Zaželeno je, da imajo ti ljudje avtoriteto v organizaciji. Morda boste morali vzeti enega konzervativnega, čeprav tega ne želite. Če imamo veliko podjetje, ne bodo vsi verjeli v našo idejo, nekateri pa nam lahko pristavijo palico v kolesih, na primer, če ne zagotovijo stojala. Tukaj boste potrebovali "avtoriteto" - spoštovano osebo z bogatimi izkušnjami, ki si je prislužila dober odnos svojih kolegov. Avtoriteta zaposlenega v timu bo poenostavila nalogo in delo začasne ekipe. Ljudje bodo mislili:
- Ja, ta kul tip, ki ga vsi poznamo in imamo radi, se prilega zraven - očitno je v DevOps nekaj, kar je vredno ogleda!
Postavljanje cilja
Zbrali smo ljudi, izbrali storitev, pogledali omejitve in določili, na katere ljudi bomo vplivali. Zdaj si morate postaviti cilj, ki mora biti jasen od SMART - vse, kar imamo radi.
Specifično - specifično.
Merljivo - merljivo. To je zelo pomembna SMART točka. Če nečesa ne morete izmeriti, potem tega ne morete spremeniti in razumeti, kaj in kako ste naredili bolje ali slabše.
Dosegljivo - dosegljivo. Naredite prilagoditve, da bodo ustrezale vašim posebnim potrebam. Če ste podjetniško podjetje z dolgo zgodovino in velikim bremenom odgovornosti, ki izda verzijo produkta enkrat letno, potem ne boste mogli doseči izdaje novih verzij produkta vsako uro v šestih mesecih. Tako ne bo šlo. Zato si postavite realen cilj, ki je dosegljiv v sprejemljivem časovnem okviru.
Relevantno - relevantno. Odstranjujemo le tiste omejitve, ki dejansko služijo našim trenutnim ciljem.
Časovno omejeno - časovno omejeno. Če roka ni, bo ekipa naredila, kar hoče: preizkusila 15 tehnologij namesto 3, napisala ogromna poročila, opravila neuporabne raziskave, pilila njihovo implementacijo, dokler ne zasije, ko je cilj že dosežen.
Cilj zavzamemo s pomočjo Zemljevida toka vrednosti - ponovno zberemo vse ljudi in jih narišemo. Toda šele zdaj na podlagi prejšnjega Zemljevida toka vrednosti narišemo, kaj želimo dobiti.
Izpostavljamo eno omejitev, ki jo bomo zdaj odpravili – to bo naredila ekipa. Kot primer sem vzel čakanje od končane izdaje do uvedbe v produkcijo - to je najpogostejša omejitev, s katero se ljudje obrnejo na svetovalce.
Na podlagi tega smo postavili nalogo: želimo, da je čakanje med končano sprostitvijo in odhodom v boj največ eno uro.
Primeri nalog.
- Skrajšajte čas testiranja s 4 dni na 1 uro.
- Zmanjšajte čas z dodano vrednostjo za testiranje z 2 dni na 3 ure.
- Skrajšajte čas za uvajanje s 5 ur na 10 minut.
- Povečajte C/A s 50% na 95%, torej povečajte število funkcij, ki jih preizkuševalci sprejmejo, z drugimi besedami, izboljšajte kakovost dela razvijalcev.
Primeri nalog niso vzeti iz naših glav - temeljijo na meritvah, ki smo jih opravili pri razvoju Zemljevida toka vrednosti.
Podobno nalogo smo postavili tudi naši ekipi in časovno omejitev. Glede na to, kako dobro posluje vaše podjetje, postavljate različne roke. V povprečju odprava omejitve običajno traja šest mesecev, če ljudje to počnejo prvič in še ne vedo, s katerimi tehnologijami in kako konkretno bodo rešili težavo.
Kratko načrtovanje
Torej, naša ekipa je ustvarjena, ima cilj, ljudje začnejo delati. Pomembna točka je kratek načrt dela: šprinta en do dva tednain nič več, merljive izboljšave vsak teden in popravek tečaja.
Na primer, pogosto uporabljamo pristop gibljiv-gibljivKo se na začetku vsakega tedna zbere celotna ekipa, si v datoteko zapišejo, kaj bo kdo naredil. Po enem tednu ugotavljamo, kaj je bilo narejeno in kaj ne, če ne, zakaj, in razmišljamo, kaj naprej.
Sprinti vam omogočajo pravočasno popravljanje proge.
Teden ali dva ste nekaj preizkušali: tehnologije, pristope, načine dela, nato znova merite in vidite - je s tem pristopom postalo bolje ali slabše? Če je slabše, pomeni, da gremo v napačno smer, moramo popraviti pot: postaviti drugo nalogo, uporabiti drugo tehnologijo ali narediti kaj drugega. Kratki sprinti, ki trajajo 1-2 tedna, vam omogočajo manevriranje in pravočasno izogibanje slabim odločitvam.
Deljenje uspeha
Ekipa doseže nek uspeh, majhen ali velik - ni pomembno, vedno je nek rezultat. Za ta rezultat bi morali vedeti vsi: tako tisti, ki sodelujejo pri DevOps, kot sosednji oddelki. V idealnem svetu bi bilo zaželeno, da bi to sploh prišlo vsem ljudem v podjetju.
Za kaj? Če želimo preoblikovati ne samo del podjetja, odpraviti ne samo eno omejitev, ampak vse nasploh, da bo podjetje postalo fleksibilno, da koda hitro pride do naročnika in da se nič ne pokvari, moramo biti vsi zvesti ideji. od DevOps. Pristopa ne boste mogli uporabiti pri storitvah in ekipah, ki mu odločno nasprotujejo.
Da se pojavi zvestoba, moramo vsem povedati, da smo to poskusili - imamo rezultate, poskusite tudi vi! To bo povečalo zanimanje in zvestobo temu, kar počnemo, ljudje bodo začeli poskušati nekaj narediti takoj zdaj. Kot kaže praksa, ko vam povemo, kaj smo poskušali in kaj smo dosegli, druge ekipe začnejo spraševati, kako in kaj smo naredili. Gledajo implementacije, kodo, dokumentacijo, postavljajo vprašanja in poskušajo nekaj spremeniti pri sebi.
Pomembno je govoriti o tem, kar ste naredili. Tako boste konservativce, ki so želeli vse narediti po starem, prepričali v vaš tabor in jih spremenili v inovatorje.
Skupno
Izbira storitve, kot izhodišče - kraj, kjer bomo začeli s spremembami v podjetju. Identificiramo vse, ki imajo karkoli opraviti s storitvijo in z njimi izdelava zemljevida toka vrednosti, izmerimo in vidimo kje in kakšne so omejitve.
Ustvarjanje nove začasne ekipe, ki bo rešil težavo. Na podlagi meritev in zemljevida toka vrednosti narišemo nov zemljevid, kjer označimo omejitev, ki jo bomo rešili. Na podlagi te omejitve zastavite nalogo, s katerim se bo ekipa ukvarjala. Naloga naj bo nujno SMART - specifični, merljivi, relevantni za tekoče naloge in časovno omejeni.
Ponovite postopek, dokler absolutno vseh naših storitev ne preoblikujemo v zahtevano obliko in odpravimo vse omejitve.
Bonus. Uporabni materiali
Za tiste, ki so se odločili za DevOps sami.
Projekt Phoenix
Prvotni naslov je "The Phoenix Project: A Novel about It, Devops, and Helping Your Business Win." To je roman o DevOps – zgodba o tem, kako je bil zaposleni postavljen za vodjo oddelka, ki je vedno gorel. Novi šef je dobil nalogo:
"Imate nekaj let, da vse uredite v redu, tako da lahko končno hitro in učinkovito dostavimo naš izdelek našim strankam."
"Projekt Feniks" Roman o tem, kako DevOps spreminja življenje na bolje« je knjiga za vse managerje, saj so to ljudje, ki odločajo o dogajanju v podjetju. Če ste inženir ali programer in želite, da se gibanje in preobrazba začneta v vašem podjetju, kupite knjigo in jo dajte vodstvu. Ta roman razloži vse in se hitro in enostavno bere.
DevOps vodnik
Knjiga je bolj zapletena. Pred nekaj leti je bil objavljen v angleščini pod naslovom »The DevOps Handbook How to create world-class agility, reliability, and security in Technology organization«, zdaj pa je že na voljo v ruščini. To je resnično priročnik - praktični vodnik: kako izvajati meritve, kaj je mapa toka vrednosti in zakaj je potrebna, kam iti, v kakšnem vrstnem redu. Knjiga je samo za tiste, ki želijo vse narediti sami. Najpomembneje pa je, da vsebuje primere izkušenj drugih podjetij.
Na primer, pove, kako je neko podjetje zgradilo zemljevid toka vrednosti in ugotovilo, da njegova omejitev ni v izdelku, ampak v dejstvu, da je blagajničarka hodila od trgovine do naslednje pisarne, da bi uporabila ta izdelek. Namesto da bi problem rešili s programom, so preprosto kupili tablice za svoje prodajalce in zdaj nihče ne gre nikamor, vsa dejanja pa izvajajo na delovnem mestu. Zaključek: Mapo toka vrednosti je mogoče razširiti ne le na programsko opremo, ampak tudi na vse procese v organizaciji.
Pospešite
Polni naslov: »Accelerate: Znanost o vitki programski opremi in DevOps: Gradnja in skaliranje visoko zmogljivih tehnoloških organizacij.« To je naslednja raven - hardcore. Knjiga je izšla lani, zaenkrat samo v angleščini in je raziskovalna. Avtorji – Nicole Forsgren, Jez Humble in Gene Kim – že vrsto let uporabljajo različne prakse v različnih podjetjih in raziskujejo, katere prakse vplivajo na kaj in kako.
Drugo poglavje o merjenju omenja zemljevid toka vrednosti, metrike, ki sem jih omenil, in številne druge, podrobno pa opisuje tudi postopek merjenja. Avtorji merijo z uporabo vprašalnikov in nalog za samokontrolo. Podrobno opisuje, katere metrike je pravilno meriti, katerih ne bi smeli meriti, in človeške napake pri meritvah. Če imate težave z meritvami, si oglejte drugo poglavje knjige "Pospeši". Če ima vaša ekipa preprosto veliko praks, vendar ni jasno, katere prakse uporabiti zdaj, katere kasneje, katere resnično delujejo in katere ne - preberite, knjiga pojasnjuje vse.
Transformacija je vprašanje na presečišču DevOps in upravljanja. Nekje na istem področju presečišča razvoja, delovanja in testiranja so teme, o katerih poskušamo razpravljati na , enaka integracija je potrebna za ustvarjanje kakovostnega izdelka - glavna tema . Vodstvo festivala predloženo - to pomeni, da so vsi tam za ideje za preobrazbo. Pridruži se nam 27. in 28. maja, integrirali se bomo in transformirali.
Vir: www.habr.com
