Če ne razumete, kaj je DevOps, tukaj je kratek povzetek. DevOps je niz praks, ki zmanjšujejo strahove inženirjev in zmanjšujejo število motenj v produkciji programske opreme. Na splošno tudi skrajšajo čas do trga — obdobje od ideje do dostave končnega izdelka strankam, kar omogoča hitro izvajanje poslovnih eksperimentov..
Kako začeti DevOps transformacijo? Na kratko: izberemo storitev, s katero bomo začeli postopek, identificiramo tiste, ki so povezani s storitvijo, zgradimo Value Stream Map, ustvarimo začasno ekipo, ki se bo sprva ukvarjala s transformacijo, in ji postavimo nalogo. Cikel ponavljamo tolikokrat, kolikor je potrebno.
Podroben načrt DevOps transformacije z zgledi in navodili je v razširjenju Andrejem Aleksandrovom — inženirja v podjetju Express42, ki svetuje pri uvajanju DevOps-a, pospešuje ta postopek, ker je že zgradil karto težav. Če menite, da transformacija ni potrebna, ali imate takšno specifiko, da DevOps prakse niso primerne, uporabite poročilo kot navodilo za odkrivanje in odpravo omejitev.
Če vas skrbi vprašanje DevOps transformacije, imate veliko podjetje in je treba postopek postopoma razširiti na celotno strukturo. Dokler obstaja potreba po transformaciji ekipe ali odpravi kakšne omejitve, lahko spodnji algoritem ponavljate.
Izbira storitve
Načrtujemo, začnemo s prvim korakom — izbiro storitve. Prvi kriterij je življenjska doba: obstajajo stare storitve — legacy in nove. Začeti je mogoče z obema.
Izbira mlade storitve je smiselna.Sveža je, še ni ustaljenih delovnih procesov v ekipi, ki se z njo ukvarja. Okoli nje ni gora tehničnih dolgov, ni treba nenehno popravljati. Z njo lahko delamo, kar želimo.
Pri stari storitvi pa obstajajo težave, povezane s tem, da je sprememba vedno težka.Že obstaja niz nekaterih resnih omejitev, morda pa se jih lotevajo ljudje, ki so že pripravljeni, da jih prekinejo — utrujeni so in želijo narediti nekaj drugače, ker jih boli.
Delo s staro storitvijo ustvarja močan precedent v vašem podjetju — lahko se nekaj spremeni. Če ste spremenili novo storitev, se ta na produkciji odvija 100-krat na uro in je vse v redu, lahko ljudje v vašem podjetju rečejo:
— To je nov servis! Tam je bilo vse preprosto, poskusite z našo staro zadevo karkoli narediti.
Legacy-servis ima smisel prevzeti v transformacijo, ko to počnete s kom drugim, na primer, če ste povabili zunanjega svetovalca. Bodimo iskreni, transformacija bo pretresla vse, kar se da.. Eksperimentirate in ne veste, kam boste prišli, katere tehnologije in zakaj boste uporabili, kje in kakšne težave se bodo pojavile v procesih. Zato je lažje zamenjati nov servis.
Če vse delate sami, podjetje pa nima resne strokovnosti — vzamemo nov servis. Če poznate zunanjega svetovalca in imate sredstva — izberite starega.
Obstajajo servisi, ki predstavljajo samo vmesnik za uporabnike, na primer, preprost spletni strani ali mobilna aplikacija. Toda obstajajo tudi resne stvari, kot je billing. Če se pri billingu kaj ne bo izšlo - bo težko razumeti. Tudi tukaj imamo izbiro.
Delamo bodisi s kritičnim servisom, vendar zaradi njega že trpimo, ustvarja omejitve, bodisi delamo z vmesnikom. To je drugi kriterij izbire. Podobno, obstaja možnost privabiti izkušenega svetovalca — delamo s težko možnostjo.
Vendar tudi v tem primeru ne bi svetoval tako ravnati, ker, dokler ni razumevanja, s čim delamo in v katero smer transformirati, jemati kritično stvar in jo preurejati — ni najboljša ideja. Zato v tem primeru raje delamo z vmesnikom, katerega okvara ni kritična.
Nato bomo obravnavali ekipo servisa. Tistimi, ki se ukvarjajo s tem servisom, se bomo morali neprestano ukvarjati in tesno sodelovati.
Ljudi v ekipi lahko nekako razdelimo v dve kategoriji: konservativci — živijo v starem svetu, ali preprosto ne vedo nič o DevOps, in inovatorji, ki prenašajo vse modne prakse. Drugi ne vedno razumejo teme, vendar so vsaj pripravljeni na to.
Na eni strani so konservativci — izkušeni ljudje: dolgo so v podjetju, razumejo vse od začetka do konca, vendar ne vedo, kako ravnati s praksami. Na drugi strani — inovatorji, ki so kaj slišali, vendar verjetno ne delajo v podjetju zelo dolgo. S kom od njih bi bilo bolje delati?
S konservatívci se bude muset jednat, protože je to jejich služba. Budeme s nimi muset komunikovat, zjistit specifika služby, co se dá udělat a co ne. Jsme závislí na jejich radách. Určitě jim budeme muset něco svěřit, protože znají svou službu lépe. Proto je důležité, s jakým týmem nakonec budeme mít kontakt.
Je logické vybrat do týmu inovátory, protože konzervativci by mohli nastražit past.
V praxi je často špatně, že konzervativní lidé mají značné zkušenosti, ale nemají představu, jak žít dál. Bojí se, že po transformaci a úpravě služby budou propuštěni, protože nebudou potřební. Někdy kvůli nepochopení toho, co se děje, sabotují práci.
Měl jsem případ, kdy kluk z týmu opravoval cokoliv, protože to bylo prý kritičtější než to, co právě děláme. Dáme úkol: realizovat dnes tenhle úsek — ne, na druhém konci světa je požár, jdeme ho opravovat. S takovými lidmi je těžké pracovat.
Lidé z konzervativního týmu často zanedbávají úkoly nebo je odkládají na poslední chvíli. A pokud, nedejbože, uděláte chybu a dáte jim KPI za počet splněných úkolů, a nějaká část není zahrnuta do KPI, tak neudělají vůbec nic. V tomto ohledu budou mít pravdu, protože by tím přišli o prémie.
S inovátory je to jednodušší — jsou loajálnější.Už něco slyšeli, chtějí někam směřovat, takže budou pomáhat. Potřebujeme lidi, kteří jsou ochotni první dobu trpět: pokud se mění služba, tak všechny nerovnosti a problémy vyřeší inovátory jakožto průkopníci. Inovátory chtějí to nejnovější a trendy, a nebojí se utrpět.
Konzervativce později lze přeměnit na svou víru. Když ukážete, že jste změnili část a všechno funguje dobře, pravděpodobně i oni budou chtít vyzkoušet a přijmou novou DevOps víru.
Shrňme to. Pokud provedeme celou transformaci ve společnosti sami, vybíráme: novou službu, nejlépe s jednoduchým rozhraním, aby se nám příliš netížilo, když se pokazí, a tým inovátorů.
Če obstaja možnost povabiti zunanjega svetovalca, namesto novega — izberemo starega ponudnika, zaradi katerega že trpimo. Ljudje, ki so se s transformacijo ukvarjali dovolj dolgo v različnih podjetjih, so videli različne primere in zdaj razumejo, kako pravilno ravnati ter v katero smer iti.
Kdo je vključen?
Moramo najti prav vse, ki imajo kakršnokoli povezavo s storitvijo: razvijalce, testere, skrbnike, varnostnike, managerje in morda tudi Product Owners. Kljub temu, da Product Owners niso tehnični strokovnjaki, so povezani s storitvijo: sprejemajo odločitve in postavljajo naloge.
Vse, ki sprejemajo kakršnekoli odločitve in vplivajo na to, kar se dogaja s storitvijo, je treba najti, srečati in se pogovoriti z njimi.
Zakaj jih potrebujemo? Da vemo, s kom se dogovoriti.. Med transformacijo, ko se spreminja običajen način delovanja storitve, bo vseeno prihajalo do motenj. Nekaj časa bodo napake, medtem ko testiramo nove pristope. Ljudje se morajo tega zavedati in se s tem strinjati.
Nato bomo morali zgraditi Value Stream Map in brez teh ljudi tega ne moremo storiti, saj samo oni skupaj poznajo celotno sliko dogajanja. Ena oseba nikoli ne ve vsega, kar se dogaja s storitvijo.
Priporočili bodo ljudi v ekipo. Kasneje se bomo pogovorili, zakaj potrebujemo posebno ekipo. Vanjo bo treba vključiti ljudi iz obstoječih oddelkov. Tisti, ki so povezani s storitvijo, bodo lahko priporočili sodelavce, ki razmišljajo v našem smislu, in nam lahko pomagajo ter imajo kompetence, ki jih potrebujemo.
Nato zberemo vse te ljudi iz različnih oddelkov v eno sobo in začnemo graditi Value Stream Map.
Gradimo Value Stream Map.
Value Stream Map je shema ali karta, ki prikazuje tok vrednot do stranke.To je celoten proces od ideje do izvedbe, vključno z vsemi vmesnimi koraki in tem, kako vrednost na koncu pride do naših strank.
Value Stream Map je potrebna, da vizualiziramo vse faze razvoja,lokaliziramo težave skozi meritve, ki so v trenutnem procesu, in začnemo te težave odpravljati, ter določimo začetni cilj.To je mesto, kjer bomo začeli resnično delati.
Metrike
V literaturi o Value Stream Map je opisano veliko različnih metrik, toda za začetek so nam dovolj le tri.
Lead Time — zamuda/čakanje — čas, ko pričakujemo nekaj. Na primer, tester čaka, da se sprosti testni prostor, in v tem času ne more nič delati.
Value Added Time — čas koristnega dela — to je tisto, kar smo porabili v določenem koraku, da bi ustvarili končno vrednost za uporabnika. Na primer, tester je zagnal svoj test in začel preverjati. To je čas koristnega dela, ko dejansko delamo nekaj za izdelek. To je tisto, za kar stranke plačujejo — za kakovostno programsko opremo.
%C/A — odstotek sprejetega dela. Imamo eno fazo — razvoj, drugo fazo — testiranje. Koliko funkcij so testerji sprejeli od razvijalcev, in to je ta odstotek.
Približno tako izgleda naša karta.
Lahko pa izgleda drugače, odvisno od strukture organizacije, števila oddelkov in tistega, s čimer se ukvarjate. A na splošno bo na karti dve fazi: ideja in analitika. V tej fazi se pričakujejo podatki, na primer, Lead Time 2 tedna in Value Added Time 2 dni.
Z metriko pokrivamo prav vse faze.
Backlog — koliko nalog je ostalo potem, ko so jih analitiki izmislili.
Razvoj — koliko tednov so razvijalci čakali na pojasnila o nalogah, testnih prostorih ali opremi — ni pomembno, a nekaj čakajo. Na primer, 4 dni bodo uresničili funkcijo. Tukaj se pojavi metrika %C/A. Razvijalci so vzeli iz Backloga le 80 % nalog. Menijo, da za preostalih 20 % ni dovolj jasnega TŽ, in so jih poslali na izboljšave.
Testiranje. Na shemi je LT določen na 4 dni. Na primer, testerji so čakali, da se sprosti testni prostor, VA 2 dni dejansko testirajo, in %C/A = 40 %. — le 40 % kode ali funkcij, ki so jih poslali razvijalci, so testerji ocenili kot ustrezne. Vse ostalo jim iz kakršnegakoli razloga ni bilo všeč.
Ne bom podrobno opisoval, kako izvesti te meritve, na koncu članka bom priporočil literaturo, iz katere se lahko o njih poučite.
Edina stvar, ki jo priporočam — ne verjemite ljudem, ki bodo z vami izdelali Value Stream Map. Predstavljajo, koliko časa zasedajo različni procesi, a te ocene niso vedno točne, zato je najbolje meriti sam.
Imeli smo primer, ko smo šli v oddelek Operations in vprašali, koliko časa traja, da nova funkcionalnost pride v produkcijo. Odgovorili so nam, da 10 minut, in pomislili smo, zakaj smo sploh prišli v to podjetje? Izvedeli smo, da je 10 minut čas delovanja skripte, ki vzame kodo in jo dostavi na strežnik. Ampak pred tem je bil release tri dni namesto, da bi bil na strežniku in preprosto čakal - v Backlogu je naloga, ki jo je treba deployati. Izkazalo se je, da je pred fazo deploya faza čakanja, ko projekt preprosto leži. Če ne bi šli s zvezkom, ne bi opazili naloge v Jira in ne bi začeli slediti po korakih, bi menili, da je vse v redu in da ni nobenih težav.
Zato bo treba meritve vseeno opraviti sami, najbolje ne samo enkrat, da bi imeli realno predstavo. Glede na Value Stream Map boste sprejeli odločitev, od kod začeti in kaj popraviti najprej.
Začasna ekipa
Mnoge podjetja, ki so se odločila uvesti DevOps, oblikujejo ekipo, ki pa ni začasna, temveč obstaja že nekaj let. Če se obrnete na DevOps servis apologize, kjer so opisani različni vzorci organizacijske strukture v DevOps, boste razumeli, da je to antipattern.
Ko DevOps ekipa obstaja nepretrgoma več let, je to velika napaka, ker DevOps pomeni komunikacijo med oddelki, hitrost in učinkovitost.
Če ekipa obstaja med oddelki, samo da bi počela nekaj drugega ločenega in obstaja dolgo, ustvarja dodaten zid. Zdaj mora programer namesto, da bi takoj šel do administratorja rešiti vprašanje, najprej stopiti v oddelek DevOps, ki se potem pomika naprej.
Zato je za začetek potrebno oblikovati začasno ekipo. Trajala bo pogojno šest mesecev, najdlje eno leto, odvisno od postavljene naloge, le da bi odpravila eno omejitev, ki smo jo izbrali. Potem bo umrla. Če izberemo naslednjo točko, kjer nas močno boli, in spoznamo, da potrebujemo za to tudi posebno ekipo, jo bomo spet ustvarili. Vendar takšne ekipe na "stalni osnovi" ne bi smele obstajati — v nasprotnem primeru le ovirajo komunikacijo in prevzemajo povsem ločene naloge, samo da nekaj delajo. Te naloge sploh niso nujno povezane z DevOps in transformacijo. Zakaj te naloge ne bi zaupali obstoječim oddelkom?
Zakaj potrebujemo začasno ekipo
Konflikt s trenutnimi procesi. DevOps transformacija je sprememba ne le tehnologij in orodij, ki jih uporabljamo, ampak tudi sprememba samega delovnega procesa, razmišljanja in vrednot. Če bo ekipa delala tako, kot je že navajena, ne bo mogla preizkusiti drugih pristopov.
Ti ljudje morajo živeti po drugih pravilih: ignorirati vse KPI v podjetju, ker poskušajo delati drugače. Začasne ekipe ne bodo oddajale zahtevkov za strežnik, ampak bodo neposredno zahtevale od oddelka, ki z njimi upravlja, da jim kot prvim dajo tisto, kar potrebujejo, ker je to prednostna naloga in ker poskušajo živeti drugače. Ekipa ima popoln konflikt z vsemi trenutnimi procesi. Da trenutne metode dela ne bi ovira njih now, in da ne bi ovirali drugih, te ljudi izoliramo, tako da jih postavimo v posebno ekipo.
Izogibanje birokraciji v eksperimentih. V začasnih ekipah ni birokracije, ne izpolnjujejo poročil o delovnih urah, ne poročajo menedžerjem. To je popolnoma ločen svet, v katerem ljudje živijo in razmišljajo drugače ter se ukvarjajo z povsem drugimi stvarmi. Ne smemo jim dodatno motiti.
Neprekinjeno delo na storitvi. V prvem koraku smo izbrali nekaj, s čimer bomo eksperimentirali. Eksperimenti in iskanje boljših načinov dela je dobro, vendar želimo tudi razvijati funkcionalnosti. Če se celotna ekipa namesto funkcionalnosti ukvarja s transformacijo, bomo začeli izgubljati prihodke, napake bodo dolgotrajno viseli — tega ne potrebujemo. Ustanovitev začasne ekipe omogoča eksperimentiranje, ne da bi pri tem ustavili delo na izdelku.
Ne izgubljajte čas na delovne naloge. Spet gre za izdelek. Da bi ekipa preizkusila druge pripomočke in podobno, potrebujemo veliko časa. Da ljudje osvojijo orodja, jih začnejo vnašati in jih normalno uporabljati, bo potrebnih vsaj šest mesecev. Če se bodo ukvarjali še s produktom, se bo šest mesecev neskončno raztegnilo. Če se ljudje ukvarjajo s produktom, ponovno delajo s starimi procesi — tega ne potrebujemo.
Zato iz različnih oddelkov določamo ljudi v posebno ekipo, ki se bo ukvarjala s transformacijo storitve. Tako storitev deluje, se še naprej razvija, hkrati pa izvajamo nekatera eksperimentiranja.
Zadostna ekipa se ukvarja le s DevOps transformacijo — odpravljanje omejitev, ki smo jih odkrili, in nič drugega.
Ekipa sestavlja univerzalne ljudi. To pomeni, da nismo vzeli samo razvijalcev. Nismo prišli v storitev in jo prepolovili — ne, vzeli smo ljudi iz različnih oddelkov. Pred nekaj točkami smo našli različne oddelke in različne zaposlene, ki so povezani s transformirano storitvijo. Iz njih sestavljamo ekipo, ker mora biti univerzalna — spreminjali bomo tako postopek testiranja kot postopek razvoja in postopek vzdrževanja storitve. Potrebne so različne kompetence.
Običajno vzamemo razvijalca, testera in inženirja — vsakega po enega, in skupaj z njimi izmislimo rešitev, ki omogoča drugačno življenje.
Želeno je, da imajo ti ljudje avtoriteto v organizaciji. Morda bo potrebno vzeti enega konservativca, čeprav se ne mara. Če imamo veliko podjetje, ne bodo vsi verjeli v naš načrt, nekateri pa morda postavljajo ovire, na primer, ne dodelijo stojala. Tukaj bo potrebna 'avtoriteta' — spoštovana oseba z velikimi izkušnjami, ki si je pridobila dobro mnenje kolegov. Avtoriteta zaposlenega v ekipi poenostavi nalogo in delo začasne ekipe. Ljudje bodo razmišljali:
— Aha, ta kul tip, ki ga vsi poznamo in imamo radi, se je vključil — očitno je v DevOps nekaj, na kar se splača pogledati!
Postavimo cilj
Zbrali smo ljudi, izbrali storitev, gledali omejitve, določili, na katere ljudi bomo vplivali. Zdaj je potrebno postaviti cilj in ta cilj mora biti jasen po SMART — tako, kot imamo radi.
Specifično — konkretna.
Merljivo — merljiva. To je veoma važna tačka SMART. Ako ne možete nešto meriti, ne možete to promeniti i razumeti šta i kako ste uradili bolje ili lošije.
Dostižno — dostižna. Prilagodite svojoj specifičnosti. Ako ste preduzeće sa dugom istorijom i velikim teretom obaveza, koje objavljuje verziju proizvoda jednom godišnje, nećete moći da postignete izdavanje novih verzija proizvoda svaka dva meseca. Takvo nešto nije moguće. Zato postavite realan cilj koji je dostižan u razumnom roku.
Relevantno — relevantna. Uklanjamo samo onu prepreku koja zaista progonimo naše trenutne ciljeve.
Vremenski ograničena — ograničena vremenom. Ako nema rokova — tim će se baviti čim god to želi: iskušavati 15 tehnologija umesto 3, pisati ogromne izveštaje, sprovesti beskorisna istraživanja, doraditi svoju implementaciju do savršenstva, kada je cilj već postignut.
Cilj postavljamo uz pomoć Value Stream Map — ponovo okupljamo sve ljude i crtamo. Ali sada, na osnovu prethodne Value Stream Map, crtamo ono što želimo da postignemo.
Ističemo jednu prepreku koju ćemo ukloniti odmah — tim će se time baviti. Na primer, uzeo sam čekanje od gotovog izdanja do njegovog postavljanja u produkciju — to je najčešća prepreka sa kojom se ljudi obraćaju konsultantima.
Na osnovu toga postavljamo zadatak: želimo da čekanje između gotovog izdanja i izlaska na tržište bude maksimalno sat.
Primeri zadataka.
- Smanjiti Lead Time testiranja sa 4 dana na 1 sat.
- Smanjiti Value Added Time za testiranje sa 2 dana na 3 sata.
- Smanjiti Lead Time postavljanja sa 5 sati na 10 minuta.
- Povećati C/A sa 50% na 95%, to jest povećati broj funkcionalnosti koje prihvataju testeri, drugim rečima, poboljšati kvalitet rada programera.
Primeri zadataka nisu izmišljeni — oni su zasnovani na merenjima koja smo radili kada smo razvijali Value Stream Map.
Postavljamo sličan zadatak našem timu i vremensko ograničenje. U zavisnosti od toga koliko u vašoj kompaniji dobro ide, postavljate različite rokove. U proseku, za uklanjanje prepreke, ako se tim bavi ovim po prvi put i još ne zna koje tehnologije i kako tačno će rešiti problem, obično je potrebno šest meseci.
Kratko planiranje
Torej, naša ekipa je ustanovljena, ima svoj cilj in ljudje se začnejo uvajati v delo. Pomembno je kratko načrtovanje dela: sprinti en do dva tednain ne več, merljiva izboljšanja vsak teden in prilagoditev smeri.
Na primer, pogosto uporabljamo pristop moving-moving, ko se vsa ekipa zbere na začetku vsakega tedna, zapiše v datoteko, kaj bo kdo delal. Po enem tednu pregledamo: kaj je bilo narejeno, kaj ne, če ni, zakaj in razmišljamo, kako naprej.
Sprinti omogočajo pravočasno prilagoditev smeri.
Teden ali dva smo poskusili nekaj: tehnologije, pristope, načine dela, nato pa ponovno izmerite in poglejte — ali je bilo s tem pristopom bolje ali slabše? Če slabše, potem gremo v napačno smer, potrebno je prilagoditi smer: postaviti drugo nalogo, uporabiti drugo tehnologijo ali kaj drugega narediti. Kratki sprinti na 1-2 tedna omogočajo manevriranje in pravočasno izogibanje slabim odločitvam.
Delimo uspehe
Ekipa dosega nekakšne uspehe, naj bodo majhni ali veliki — ni pomembno, vedno je nek rezultat. O tem rezultatu morajo vedeti vsi: tako tisti, ki so vključeni v DevOps, kot tudi sosednji oddelki. V idealnem svetu bi bilo dobro, če bi to doseglo sploh do vseh ljudi v podjetju.
Zakaj? Če želimo transformirati ne le del podjetja, odpraviti ne eno omejitev, temveč prav vse, da postane podjetje fleksibilno, da koda hitro pride do stranke in da nič ne odpove, je potrebno, da so vsi naklonjeni ideji DevOps. Ne boste mogli uporabiti pristopa do storitev in ekip, ki so strogo proti.
Da bi pridobili zvestobo, moramo vsem pripovedovati, da smo poskusili to — imamo rezultat, poskusite tudi vi! To bo povečalo zanimanje in zvestobo temu, kar počnemo, ljudje bodo začeli poskušati nekaj narediti takoj. Kot kaže praksa, ko povemo, kaj smo poskusili in kaj dosegli, druge ekipe začnejo spraševati, kako in kaj smo naredili. Gledajo na implementacije, kodo, dokumentacijo, prihajajo z vprašanji in poskušajo spremeniti kaj pri sebi.
Povedati, kaj vam je uspelo - je pomembno. Tako boste prepričali konservativce, ki so želeli vse delati po starem, da preidejo v vašo skupino in jih spremenili v inovatore.
Ukupno
Izbiramo storitev, kot izhodišče — tisti kraj, kjer bomo začeli spremembe v podjetju. Identificiramo sve koji imaju bilo kakvu povezanost sa uslugom i zajedno s njima gradimo Value Stream Map, merimo i gledamo gde i koja ograničenja postoje.
Formiramo novi privremeni tim, koji će se baviti postavljenim zadatkom. Na osnovu merenja i Value Stream Map crtamo novu mapu, gde ističemo to ograničenje koje ćemo rešavati. Na osnovu ovog ograničenja postavljamo zadatak, kojim će se tim baviti. Zadatak mora biti obavezno SMART — specifičan, merljiv, relevantan za trenutne zadatke i vremenski ograničen.
Ponavljamo proces, dok ne transformišemo apsolutno sve naše usluge u traženi oblik i ne eliminišemo sva ograničenja.
Bonus. Korisni materijali
Za one koji su odlučili da se sami bave DevOps-om.
Projekt 'Feniks'
Originalni naziv — „The Phoenix Project: A Novel about It, Devops, and Helping Your Business Win“. To je roman o DevOps-u — priča o tome kako je zaposlenik postao šef odeljenja koje je bilo u neprekidnom haosu. Novom šefu je postavljen zadatak:
— Imaš nekoliko godina da sve ispraviš kako bismo konačno mogli brzo i efikasno da isporučujemo naš proizvod našim klijentima.
„Projekat 'Feniks'. Roman o tome kako DevOps menja živote nabolje“ — knjiga za sve rukovodioce, jer upravo ti ljudi donose odluke o tome šta se dešava u kompaniji. Ako ste inženjer ili programer i želite da se u vašoj kompaniji započne akcija i transformacija — kupite knjigu i poklonite je rukovodstvu. Ovaj roman sve objašnjava, a brzo i lako se čita.
Vodnik po DevOps
Knjiga je malo složenija. Objavljena je pre nekoliko godina na engleskom pod nazivom „The DevOps Handbook How to create world‑class agility, reliability, and security in Technology organizations“, ali sada već ima i na srpskom. To je pravi priručnik — praktični vodič: kako sprovoditi merenja, šta je Value Stream Map i zašto je potrebna, kojim putem treba ići, kojim redosledom. Knjiga je upravo za one koji žele sve da urade sami. Najvažnije, u njoj se nalaze primeri iskustava drugih kompanija.
Na primjer, ovdje se opisuje kako je jedna kompanija izradila Value Stream Map i shvatila da njezino ograničenje nije u proizvodu, već u tome što blagajnik odlazi od prodavnice do susjednog ureda da bi iskoristio taj proizvod. Umjesto da rješavaju problem s programom, jednostavno su kupili tablet računare svojim prodavačima, i sada nitko ne odlazi nigde, već se sve radnje obavljaju na radnom mjestu. Zaključak: Value Stream Map može se primjenjivati ne samo na softver, već i na sve procese u organizaciji.
Accelerate
Puno ime: „Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations“. Ovo je sljedeća razina — hardcore. Knjiga je objavljena prošle godine, za sada samo na engleskom i govori o istraživanjima. Autori — Nicole Forsgren, Jez Humble i Gene Kim — dugi niz godina primjenjuju različite prakse u različitim kompanijama i istražuju koje prakse, kako i na što utječu.
U drugom poglavlju, posvećenom mjerenju, spominju se Value Stream Map, one metrike koje sam spominjao, i mnoge druge, a detaljno je opisan proces mjerenja. Autori provode mjerenja putem upitnika i samostalnog praćenja zadatka. Detaljno se opisuje koje metrike treba pravilno mjeriti, koje ne bi trebalo, ljudske greške u mjerenju. Ako imate poteškoća s mjerenjima, obratite se drugom poglavlju knjige „Accelerate“. Ako vaša ekipa ima mnogo praksi, ali nije jasno koje prakse primijeniti sada, koje kasnije, koje stvarno djeluju, a koje ne — čitajte, u knjizi je sve objašnjeno.
Transformacija je pitanje na raskrižju DevOps-a i upravljanja. Negdje u toj istoj oblasti presjeka razvoja, operacija i testiranja nalaze se teme koje nastojimo raspraviti na , ta ista integracija je potrebna i za kreiranje kvalitetnog proizvoda – glavne teme . Upravljanje na festivalu of — znači za ideje o transformaciji sve dolazi tu. Pridružite se 27. i 28. maja, integrisaćemo se i transformisati.
Izvor: habr.com
