{"id":34157,"date":"2019-10-31T21:56:43","date_gmt":"2019-10-31T18:56:43","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-nachat-devops-transformatsiyu\/"},"modified":"2019-10-31T21:56:43","modified_gmt":"2019-10-31T18:56:43","slug":"kak-nachat-devops-transformatsiyu","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/kak-nachat-devops-transformatsiyu","title":{"rendered":"Kako za\u010deti DevOps transformacijo","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\u010ce ne razumete, kaj je DevOps, tukaj je kratek povzetek. DevOps je niz praks, ki zmanj\u0161ujejo strahove in\u017eenirjev<\/strong> in zmanj\u0161ujejo \u0161tevilo motenj v produkciji programske opreme. Na splo\u0161no tudi skraj\u0161ajo \u010das do trga<\/strong> \u2014 obdobje od ideje do dostave kon\u010dnega izdelka strankam, kar omogo\u010da hitro izvajanje poslovnih eksperimentov.<\/strong>.<\/p>\n

Kako za\u010deti DevOps transformacijo? Na kratko: izberemo storitev, s katero bomo za\u010deli postopek, identificiramo tiste, ki so povezani s storitvijo, zgradimo Value Stream Map, ustvarimo za\u010dasno ekipo, ki se bo sprva ukvarjala s transformacijo, in ji postavimo nalogo. Cikel ponavljamo tolikokrat, kolikor je potrebno.<\/p>\n

\"Kako<\/p>\n

Podroben na\u010drt DevOps transformacije z zgledi in navodili je v raz\u0161irjenju predavanjem<\/a><\/noindex> Andrejem Aleksandrovom<\/b> \u2014 in\u017eenirja v podjetju Express42, ki svetuje pri uvajanju DevOps-a, pospe\u0161uje ta postopek, ker je \u017ee zgradil karto te\u017eav. \u010ce menite, da transformacija ni potrebna, ali imate tak\u0161no specifiko, da DevOps prakse niso primerne, uporabite poro\u010dilo kot navodilo za odkrivanje in odpravo omejitev.
\n<\/a><\/noindex>
\n\u010ce vas skrbi vpra\u0161anje DevOps transformacije, imate veliko podjetje in je treba postopek postopoma raz\u0161iriti na celotno strukturo. Dokler obstaja potreba po transformaciji ekipe ali odpravi kak\u0161ne omejitve, lahko spodnji algoritem ponavljate.<\/p>\n

Izbira storitve<\/h2>\n

\nNa\u010drtujemo, za\u010dnemo s prvim korakom \u2014 izbiro storitve. Prvi kriterij je \u017eivljenjska doba<\/strong>: obstajajo stare storitve \u2014 legacy in nove. Za\u010deti je mogo\u010de z obema.<\/p>\n

Izbira mlade storitve je smiselna.<\/strong>Sve\u017ea je, \u0161e ni ustaljenih delovnih procesov v ekipi, ki se z njo ukvarja. Okoli nje ni gora tehni\u010dnih dolgov, ni treba nenehno popravljati. Z njo lahko delamo, kar \u017eelimo.<\/p>\n

Pri stari storitvi pa obstajajo te\u017eave, povezane s tem, da je sprememba vedno te\u017eka.<\/strong>\u017de obstaja niz nekaterih resnih omejitev, morda pa se jih lotevajo ljudje, ki so \u017ee pripravljeni, da jih prekinejo \u2014 utrujeni so in \u017eelijo narediti nekaj druga\u010de, ker jih boli.<\/p>\n

Delo s staro storitvijo ustvarja mo\u010dan precedent<\/strong> v va\u0161em podjetju \u2014 lahko se nekaj spremeni. \u010ce ste spremenili novo storitev, se ta na produkciji odvija 100-krat na uro in je vse v redu, lahko ljudje v va\u0161em podjetju re\u010dejo:<\/p>\n

\u2014 To je nov servis! Tam je bilo vse preprosto, poskusite z na\u0161o staro zadevo karkoli narediti.<\/em><\/p>\n

Legacy-servis ima smisel prevzeti v transformacijo, ko to po\u010dnete s kom drugim, na primer, \u010de ste povabili zunanjega svetovalca. Bodimo iskreni, transformacija bo pretresla vse, kar se da.<\/strong>. Eksperimentirate in ne veste, kam boste pri\u0161li, katere tehnologije in zakaj boste uporabili, kje in kak\u0161ne te\u017eave se bodo pojavile v procesih. Zato je la\u017eje zamenjati nov servis.<\/p>\n

\u010ce vse delate sami, podjetje pa nima resne strokovnosti \u2014 vzamemo nov servis. \u010ce poznate zunanjega svetovalca in imate sredstva \u2014 izberite starega.<\/p><\/blockquote>\n

\nObstajajo servisi, ki predstavljajo samo vmesnik za uporabnike, na primer, preprost spletni strani ali mobilna aplikacija. Toda obstajajo tudi resne stvari, kot je billing. \u010ce se pri billingu kaj ne bo iz\u0161lo - bo te\u017eko razumeti. Tudi tukaj imamo izbiro.<\/p>\n

Delamo bodisi s kriti\u010dnim servisom<\/strong>, vendar zaradi njega \u017ee trpimo, ustvarja omejitve, bodisi delamo z vmesnikom<\/strong>. To je drugi kriterij izbire. Podobno, obstaja mo\u017enost privabiti izku\u0161enega svetovalca \u2014 delamo s te\u017eko mo\u017enostjo.<\/p>\n

Vendar tudi v tem primeru ne bi svetoval tako ravnati, ker, dokler ni razumevanja, s \u010dim delamo in v katero smer transformirati, jemati kriti\u010dno stvar in jo preurejati \u2014 ni najbolj\u0161a ideja. Zato v tem primeru raje delamo z vmesnikom, katerega okvara ni kriti\u010dna.<\/p>\n

Nato bomo obravnavali ekipo servisa<\/b>. Tistimi, ki se ukvarjajo s tem servisom, se bomo morali neprestano ukvarjati in tesno sodelovati.<\/p>\n

Ljudi v ekipi lahko nekako razdelimo v dve kategoriji: konservativci<\/strong> \u2014 \u017eivijo v starem svetu, ali preprosto ne vedo ni\u010d o DevOps, in inovatorji<\/strong>, ki prena\u0161ajo vse modne prakse. Drugi ne vedno razumejo teme, vendar so vsaj pripravljeni na to.<\/p>\n

Na eni strani so konservativci \u2014 izku\u0161eni ljudje: dolgo so v podjetju, razumejo vse od za\u010detka do konca, vendar ne vedo, kako ravnati s praksami. Na drugi strani \u2014 inovatorji, ki so kaj sli\u0161ali, vendar verjetno ne delajo v podjetju zelo dolgo. S kom od njih bi bilo bolje delati?<\/p>\n

S konservat\u00edvci se bude muset jednat, proto\u017ee je to jejich slu\u017eba. Budeme s nimi muset komunikovat, zjistit specifika slu\u017eby, co se d\u00e1 ud\u011blat a co ne. Jsme z\u00e1visl\u00ed na jejich rad\u00e1ch. Ur\u010dit\u011b jim budeme muset n\u011bco sv\u011b\u0159it, proto\u017ee znaj\u00ed svou slu\u017ebu l\u00e9pe. Proto je d\u016fle\u017eit\u00e9, s jak\u00fdm t\u00fdmem nakonec budeme m\u00edt kontakt.<\/p>\n

Je logick\u00e9 vybrat do t\u00fdmu inov\u00e1tory, proto\u017ee konzervativci by mohli nastra\u017eit past.\n<\/p><\/blockquote>\n

\nV praxi je \u010dasto \u0161patn\u011b, \u017ee konzervativn\u00ed lid\u00e9 maj\u00ed zna\u010dn\u00e9 zku\u0161enosti, ale nemaj\u00ed p\u0159edstavu, jak \u017e\u00edt d\u00e1l. Boj\u00ed se, \u017ee po transformaci a \u00faprav\u011b slu\u017eby budou propu\u0161t\u011bni, proto\u017ee nebudou pot\u0159ebn\u00ed. N\u011bkdy kv\u016fli nepochopen\u00ed toho, co se d\u011bje, sabotuj\u00ed pr\u00e1ci.<\/p>\n

M\u011bl jsem p\u0159\u00edpad, kdy kluk z t\u00fdmu opravoval cokoliv, proto\u017ee to bylo pr\u00fd kriti\u010dt\u011bj\u0161\u00ed ne\u017e to, co pr\u00e1v\u011b d\u011bl\u00e1me. D\u00e1me \u00fakol: realizovat dnes tenhle \u00fasek \u2014 ne, na druh\u00e9m konci sv\u011bta je po\u017e\u00e1r, jdeme ho opravovat. S takov\u00fdmi lidmi je t\u011b\u017ek\u00e9 pracovat.<\/p>\n

Lid\u00e9 z konzervativn\u00edho t\u00fdmu \u010dasto zanedb\u00e1vaj\u00ed \u00fakoly nebo je odkl\u00e1daj\u00ed na posledn\u00ed chv\u00edli. A pokud, nedejbo\u017ee, ud\u011bl\u00e1te chybu a d\u00e1te jim KPI za po\u010det spln\u011bn\u00fdch \u00fakol\u016f, a n\u011bjak\u00e1 \u010d\u00e1st nen\u00ed zahrnuta do KPI, tak neud\u011blaj\u00ed v\u016fbec nic. V tomto ohledu budou m\u00edt pravdu, proto\u017ee by t\u00edm p\u0159i\u0161li o pr\u00e9mie.<\/p>\n

S inov\u00e1tory je to jednodu\u0161\u0161\u00ed \u2014 jsou loaj\u00e1ln\u011bj\u0161\u00ed.<\/strong>U\u017e n\u011bco sly\u0161eli, cht\u011bj\u00ed n\u011bkam sm\u011b\u0159ovat, tak\u017ee budou pom\u00e1hat. Pot\u0159ebujeme lidi, kte\u0159\u00ed jsou ochotni prvn\u00ed dobu trp\u011bt: pokud se m\u011bn\u00ed slu\u017eba, tak v\u0161echny nerovnosti a probl\u00e9my vy\u0159e\u0161\u00ed inov\u00e1tory jako\u017eto pr\u016fkopn\u00edci. Inov\u00e1tory cht\u011bj\u00ed to nejnov\u011bj\u0161\u00ed a trendy, a neboj\u00ed se utrp\u011bt.<\/p>\n

Konzervativce pozd\u011bji lze p\u0159em\u011bnit na svou v\u00edru. Kdy\u017e uk\u00e1\u017eete, \u017ee jste zm\u011bnili \u010d\u00e1st a v\u0161echno funguje dob\u0159e, pravd\u011bpodobn\u011b i oni budou cht\u00edt vyzkou\u0161et a p\u0159ijmou novou DevOps v\u00edru.<\/p>\n

\"Kako
\n<\/p>\n

Shr\u0148me to. Pokud provedeme celou transformaci ve spole\u010dnosti sami, vyb\u00edr\u00e1me: novou slu\u017ebu, nejl\u00e9pe s jednoduch\u00fdm rozhran\u00edm, aby se n\u00e1m p\u0159\u00edli\u0161 net\u00ed\u017eilo, kdy\u017e se pokaz\u00ed, a t\u00fdm inov\u00e1tor\u016f.<\/p><\/blockquote>\n

\n\u010ce obstaja mo\u017enost povabiti zunanjega svetovalca, namesto novega \u2014 izberemo starega ponudnika, zaradi katerega \u017ee trpimo. Ljudje, ki so se s transformacijo ukvarjali dovolj dolgo v razli\u010dnih podjetjih, so videli razli\u010dne primere in zdaj razumejo, kako pravilno ravnati ter v katero smer iti.<\/p>\n

Kdo je vklju\u010den?<\/h2>\n

\nMoramo najti prav vse, ki imajo kakr\u0161nokoli povezavo s storitvijo: razvijalce, testere, skrbnike, varnostnike, managerje in morda tudi Product Owners. Kljub temu, da Product Owners niso tehni\u010dni strokovnjaki, so povezani s storitvijo: sprejemajo odlo\u010ditve in postavljajo naloge.<\/p>\n

\"Kako
\n<\/p>\n

Vse, ki sprejemajo kakr\u0161nekoli odlo\u010ditve in vplivajo na to, kar se dogaja s storitvijo, je treba najti, sre\u010dati in se pogovoriti z njimi.<\/p><\/blockquote>\n

\nZakaj jih potrebujemo? Da vemo, s kom se dogovoriti.<\/strong>. Med transformacijo, ko se spreminja obi\u010dajen na\u010din delovanja storitve, bo vseeno prihajalo do motenj. Nekaj \u010dasa bodo napake, medtem ko testiramo nove pristope. Ljudje se morajo tega zavedati in se s tem strinjati.<\/p>\n

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.<\/p>\n

Priporo\u010dili bodo ljudi v ekipo. Kasneje se bomo pogovorili, zakaj potrebujemo posebno ekipo. Vanjo bo treba vklju\u010diti ljudi iz obstoje\u010dih oddelkov. Tisti, ki so povezani s storitvijo, bodo lahko priporo\u010dili sodelavce, ki razmi\u0161ljajo v na\u0161em smislu, in nam lahko pomagajo ter imajo kompetence, ki jih potrebujemo.<\/p>\n

Nato zberemo vse te ljudi iz razli\u010dnih oddelkov v eno sobo in za\u010dnemo graditi Value Stream Map.<\/p>\n

Gradimo Value Stream Map.<\/h2>\n

\nValue Stream Map je shema ali karta, ki prikazuje tok vrednot do stranke.<\/strong>To je celoten proces od ideje do izvedbe, vklju\u010dno z vsemi vmesnimi koraki in tem, kako vrednost na koncu pride do na\u0161ih strank.<\/p>\n

Value Stream Map je potrebna, da vizualiziramo vse faze razvoja,<\/strong>lokaliziramo te\u017eave skozi meritve, ki so v trenutnem procesu, in za\u010dnemo te te\u017eave odpravljati, ter dolo\u010dimo za\u010detni cilj.<\/strong>To je mesto, kjer bomo za\u010deli resni\u010dno delati.<\/p>\n

Metrike<\/h3>\n

\nV literaturi o Value Stream Map je opisano veliko razli\u010dnih metrik, toda za za\u010detek so nam dovolj le tri.<\/p>\n

Lead Time \u2014 zamuda\/\u010dakanje<\/strong> \u2014 \u010das, ko pri\u010dakujemo nekaj. Na primer, tester \u010daka, da se sprosti testni prostor, in v tem \u010dasu ne more ni\u010d delati.<\/p>\n

Value Added Time \u2014 \u010das koristnega dela<\/strong> \u2014 to je tisto, kar smo porabili v dolo\u010denem koraku, da bi ustvarili kon\u010dno vrednost za uporabnika. Na primer, tester je zagnal svoj test in za\u010del preverjati. To je \u010das koristnega dela, ko dejansko delamo nekaj za izdelek. To je tisto, za kar stranke pla\u010dujejo \u2014 za kakovostno programsko opremo.<\/p>\n

%C\/A \u2014 odstotek sprejetega dela. <\/strong>Imamo eno fazo \u2014 razvoj, drugo fazo \u2014 testiranje. Koliko funkcij so testerji sprejeli od razvijalcev, in to je ta odstotek.<\/p>\n

Pribli\u017eno tako izgleda na\u0161a karta.<\/p>\n

\"Kako
\n
\nLahko pa izgleda druga\u010de, odvisno od strukture organizacije, \u0161tevila oddelkov in tistega, s \u010dimer se ukvarjate. A na splo\u0161no bo na karti dve fazi: ideja <\/strong>in analitika<\/strong>. V tej fazi se pri\u010dakujejo podatki, na primer, Lead Time 2 tedna in Value Added Time 2 dni.<\/p>\n

Z metriko pokrivamo prav vse faze.<\/p><\/blockquote>\n

\nBacklog<\/strong> \u2014 koliko nalog je ostalo potem, ko so jih analitiki izmislili.<\/p>\n

Razvoj<\/strong> \u2014 koliko tednov so razvijalci \u010dakali na pojasnila o nalogah, testnih prostorih ali opremi \u2014 ni pomembno, a nekaj \u010dakajo. Na primer, 4 dni bodo uresni\u010dili funkcijo. Tukaj se pojavi metrika %C\/A. Razvijalci so vzeli iz Backloga le 80 % nalog. Menijo, da za preostalih 20 % ni dovolj jasnega T\u017d, in so jih poslali na izbolj\u0161ave.<\/p>\n

Testiranje<\/strong>. Na shemi je LT dolo\u010den na 4 dni. Na primer, testerji so \u010dakali, da se sprosti testni prostor, VA 2 dni dejansko testirajo, in %C\/A = 40 %. \u2014 le 40 % kode ali funkcij, ki so jih poslali razvijalci, so testerji ocenili kot ustrezne. Vse ostalo jim iz kakr\u0161negakoli razloga ni bilo v\u0161e\u010d.<\/p>\n

Ne bom podrobno opisoval, kako izvesti te meritve, na koncu \u010dlanka bom priporo\u010dil literaturo, iz katere se lahko o njih pou\u010dite.<\/p>\n

Edina stvar, ki jo priporo\u010dam \u2014 ne verjemite ljudem, ki bodo z vami izdelali Value Stream Map. Predstavljajo, koliko \u010dasa zasedajo razli\u010dni procesi, a te ocene niso vedno to\u010dne, zato je najbolje meriti sam.<\/p>\n

Imeli smo primer, ko smo \u0161li v oddelek Operations in vpra\u0161ali, koliko \u010dasa traja, da nova funkcionalnost pride v produkcijo. Odgovorili so nam, da 10 minut, in pomislili smo, zakaj smo sploh pri\u0161li v to podjetje? Izvedeli smo, da je 10 minut \u010das delovanja skripte, ki vzame kodo in jo dostavi na stre\u017enik. Ampak pred tem je bil release tri dni namesto, da bi bil na stre\u017eniku in preprosto \u010dakal - v Backlogu je naloga, ki jo je treba deployati. Izkazalo se je, da je pred fazo deploya faza \u010dakanja, ko projekt preprosto le\u017ei. \u010ce ne bi \u0161li s zvezkom, ne bi opazili naloge v Jira in ne bi za\u010deli slediti po korakih, bi menili, da je vse v redu in da ni nobenih te\u017eav.<\/p>\n

Zato bo treba meritve vseeno opraviti sami, najbolje ne samo enkrat, da bi imeli realno predstavo. Glede na Value Stream Map boste sprejeli odlo\u010ditev, od kod za\u010deti in kaj popraviti najprej.<\/p>\n

Za\u010dasna ekipa<\/h2>\n

\nMnoge podjetja, ki so se odlo\u010dila uvesti DevOps, oblikujejo ekipo, ki pa ni za\u010dasna, temve\u010d obstaja \u017ee nekaj let. \u010ce se obrnete na DevOps servis apologize, kjer so opisani razli\u010dni vzorci organizacijske strukture v DevOps, boste razumeli, da je to antipattern.<\/p>\n

Ko DevOps ekipa obstaja nepretrgoma ve\u010d let, je to velika napaka, ker DevOps pomeni komunikacijo med oddelki, hitrost in u\u010dinkovitost.<\/p><\/blockquote>\n

\n\u010ce ekipa obstaja med oddelki, samo da bi po\u010dela nekaj drugega lo\u010denega in obstaja dolgo, ustvarja dodaten zid. Zdaj mora programer namesto, da bi takoj \u0161el do administratorja re\u0161iti vpra\u0161anje, najprej stopiti v oddelek DevOps, ki se potem pomika naprej.<\/p>\n

Zato je za za\u010detek potrebno oblikovati za\u010dasno ekipo<\/strong>. Trajala bo pogojno \u0161est mesecev, najdlje eno leto, odvisno od postavljene naloge, le da bi odpravila eno omejitev, ki smo jo izbrali. Potem bo umrla. \u010ce izberemo naslednjo to\u010dko, kjer nas mo\u010dno boli, in spoznamo, da potrebujemo za to tudi posebno ekipo, jo bomo spet ustvarili. Vendar tak\u0161ne ekipe na \"stalni osnovi\" ne bi smele obstajati \u2014 v nasprotnem primeru le ovirajo komunikacijo in prevzemajo povsem lo\u010dene naloge, samo da nekaj delajo. Te naloge sploh niso nujno povezane z DevOps in transformacijo. Zakaj te naloge ne bi zaupali obstoje\u010dim oddelkom?<\/p>\n

Zakaj potrebujemo za\u010dasno ekipo<\/h3>\n

\nKonflikt s trenutnimi procesi<\/strong>. DevOps transformacija je sprememba ne le tehnologij in orodij, ki jih uporabljamo, ampak tudi sprememba samega delovnega procesa, razmi\u0161ljanja in vrednot. \u010ce bo ekipa delala tako, kot je \u017ee navajena, ne bo mogla preizkusiti drugih pristopov.<\/p>\n

Ti ljudje morajo \u017eiveti po drugih pravilih: ignorirati vse KPI v podjetju, ker posku\u0161ajo delati druga\u010de. Za\u010dasne ekipe ne bodo oddajale zahtevkov za stre\u017enik, 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\u0161ajo \u017eiveti druga\u010de. 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.<\/p>\n

Izogibanje birokraciji v eksperimentih<\/strong>. V za\u010dasnih ekipah ni birokracije, ne izpolnjujejo poro\u010dil o delovnih urah, ne poro\u010dajo mened\u017eerjem. To je popolnoma lo\u010den svet, v katerem ljudje \u017eivijo in razmi\u0161ljajo druga\u010de ter se ukvarjajo z povsem drugimi stvarmi. Ne smemo jim dodatno motiti.<\/p>\n

Neprekinjeno delo na storitvi<\/strong>. V prvem koraku smo izbrali nekaj, s \u010dimer bomo eksperimentirali. Eksperimenti in iskanje bolj\u0161ih na\u010dinov dela je dobro, vendar \u017eelimo tudi razvijati funkcionalnosti. \u010ce se celotna ekipa namesto funkcionalnosti ukvarja s transformacijo, bomo za\u010deli izgubljati prihodke, napake bodo dolgotrajno viseli \u2014 tega ne potrebujemo. Ustanovitev za\u010dasne ekipe omogo\u010da eksperimentiranje, ne da bi pri tem ustavili delo na izdelku.<\/p>\n

Ne izgubljajte \u010das na delovne naloge<\/strong>. Spet gre za izdelek. Da bi ekipa preizkusila druge pripomo\u010dke in podobno, potrebujemo veliko \u010dasa. Da ljudje osvojijo orodja, jih za\u010dnejo vna\u0161ati in jih normalno uporabljati, bo potrebnih vsaj \u0161est mesecev. \u010ce se bodo ukvarjali \u0161e s produktom, se bo \u0161est mesecev neskon\u010dno raztegnilo. \u010ce se ljudje ukvarjajo s produktom, ponovno delajo s starimi procesi \u2014 tega ne potrebujemo.<\/p>\n

Zato iz razli\u010dnih oddelkov dolo\u010damo ljudi v posebno ekipo, ki se bo ukvarjala s transformacijo storitve. Tako storitev deluje, se \u0161e naprej razvija, hkrati pa izvajamo nekatera eksperimentiranja.<\/p>\n

Zadostna ekipa se ukvarja le s DevOps transformacijo \u2014 odpravljanje omejitev, ki smo jih odkrili, in ni\u010d drugega.<\/p><\/blockquote>\n

\nEkipa sestavlja univerzalne ljudi<\/strong>. To pomeni, da nismo vzeli samo razvijalcev. Nismo pri\u0161li v storitev in jo prepolovili \u2014 ne, vzeli smo ljudi iz razli\u010dnih oddelkov<\/strong>. Pred nekaj to\u010dkami smo na\u0161li razli\u010dne oddelke in razli\u010dne zaposlene, ki so povezani s transformirano storitvijo. Iz njih sestavljamo ekipo, ker mora biti univerzalna \u2014 spreminjali bomo tako postopek testiranja kot postopek razvoja in postopek vzdr\u017eevanja storitve. Potrebne so razli\u010dne kompetence.<\/p>\n

Obi\u010dajno vzamemo razvijalca, testera in in\u017eenirja \u2014 vsakega po enega, in skupaj z njimi izmislimo re\u0161itev, ki omogo\u010da druga\u010dno \u017eivljenje.<\/p>\n

\u017deleno je, da imajo ti ljudje avtoriteto v organizaciji<\/strong>. Morda bo potrebno vzeti enega konservativca, \u010deprav se ne mara. \u010ce imamo veliko podjetje, ne bodo vsi verjeli v na\u0161 na\u010drt, nekateri pa morda postavljajo ovire, na primer, ne dodelijo stojala. Tukaj bo potrebna 'avtoriteta' \u2014 spo\u0161tovana oseba z velikimi izku\u0161njami, ki si je pridobila dobro mnenje kolegov. Avtoriteta zaposlenega v ekipi poenostavi nalogo in delo za\u010dasne ekipe. Ljudje bodo razmi\u0161ljali:<\/p>\n

\u2014 Aha, ta kul tip, ki ga vsi poznamo in imamo radi, se je vklju\u010dil \u2014 o\u010ditno je v DevOps nekaj, na kar se spla\u010da pogledati!<\/em><\/p>\n

Postavimo cilj<\/h2>\n

\nZbrali smo ljudi, izbrali storitev, gledali omejitve, dolo\u010dili, na katere ljudi bomo vplivali. Zdaj je potrebno postaviti cilj in ta cilj mora biti jasen po SMART<\/strong> \u2014 tako, kot imamo radi.<\/p>\n

Specifi\u010dno \u2014 konkretna<\/strong>.<\/p>\n

Merljivo \u2014 merljiva<\/strong>. To je veoma va\u017ena ta\u010dka SMART. Ako ne mo\u017eete ne\u0161to meriti, ne mo\u017eete to promeniti i razumeti \u0161ta i kako ste uradili bolje ili lo\u0161ije.<\/p>\n

Dosti\u017eno \u2014 dosti\u017ena<\/strong>. Prilagodite svojoj specifi\u010dnosti. Ako ste preduze\u0107e sa dugom istorijom i velikim teretom obaveza, koje objavljuje verziju proizvoda jednom godi\u0161nje, ne\u0107ete mo\u0107i da postignete izdavanje novih verzija proizvoda svaka dva meseca. Takvo ne\u0161to nije mogu\u0107e. Zato postavite realan cilj koji je dosti\u017ean u razumnom roku.<\/p>\n

Relevantno \u2014 relevantna. <\/strong>Uklanjamo samo onu prepreku koja zaista progonimo na\u0161e trenutne ciljeve.<\/p>\n

Vremenski ograni\u010dena \u2014 ograni\u010dena vremenom<\/strong>. Ako nema rokova \u2014 tim \u0107e se baviti \u010dim god to \u017eeli: isku\u0161avati 15 tehnologija umesto 3, pisati ogromne izve\u0161taje, sprovesti beskorisna istra\u017eivanja, doraditi svoju implementaciju do savr\u0161enstva, kada je cilj ve\u0107 postignut.<\/p>\n

Cilj postavljamo uz pomo\u0107 Value Stream Map \u2014 ponovo okupljamo sve ljude i crtamo. Ali sada, na osnovu prethodne Value Stream Map, crtamo ono \u0161to \u017eelimo da postignemo.<\/p>\n

\"Kako
\n
\nIsti\u010demo jednu prepreku koju \u0107emo ukloniti odmah \u2014 tim \u0107e se time baviti. Na primer, uzeo sam \u010dekanje od gotovog izdanja do njegovog postavljanja u produkciju \u2014 to je naj\u010de\u0161\u0107a prepreka sa kojom se ljudi obra\u0107aju konsultantima.<\/p>\n

Na osnovu toga postavljamo zadatak: \u017eelimo da \u010dekanje izme\u0111u gotovog izdanja i izlaska na tr\u017ei\u0161te bude maksimalno sat.<\/p>\n

Primeri zadataka.<\/p>\n