Kuidas alustada DevOpsi transformatsiooni

Kui te ei mõista, mis on DevOps, siis siin on lühike kokkuvõte. DevOps on praktikate kogum, mis vähendab inseneride hirme ja vähendab tarkvaraarenduse katkestuste arvu. Reeglina lühendab see turule toomise aega — perioodi ideest kuni lõpptoote klientideni viimiseni, mis võimaldab kiiresti läbi viia ärieksperimente.

Kuidas alustada DevOps ümberkujundamist? Lühidalt: valime teenuse, millega alustada, määrame ära need, kes teenusega seotud, koostame väärtuste voogude kaardi, loome ajutise meeskonna, mis tegeleb alguses ümberkujundamisega, ja määrame talle ülesande. Korratakse tsüklit vajalik arv kordi.

Üksikasjalik DevOps ümberkujundamise plaan näidiste ja juhistega on allpool — detailses kirjelduses aruandes Andrei Aleksandrov — insener firmas Express42, mis pakub nõustamist DevOpsi kasvatamisel, kiirendades protsessi, kuna on juba koostanud kivide kaardi. Kui teile tundub, et ümberkujundamine ei ole vajalik, või teil on selline spetsiifika, et DevOps praktikad ei sobi, — kasutage aruannet juhisena piirangute leidmiseks ja kõrvaldamiseks.

Kui teid häirib DevOps ümberkujundamise küsimus, siis teil on suur ettevõte ja peate seda protsessi järk-järgult laiendama kogu struktuurile. Kuni on vajadus meeskonda ümber kujundada või mõni piirang kõrvaldada, saame alltoodud algoritmi kordata.

Teenuse valik

Plaani oleme seadnud, alustatud esimese sammuga — teenuse valimisega. Esmane kriteerium — eluiga: on vanu teenuseid — legacy ning uusi. Alustada võib nii neist kui ka nendest.

Noore teenuse valimine on loogiline. See on värske, sellega tegelevas meeskonnas ei ole veel väljakujunenud tööprotsesse. Selle ümber pole suurt tehnilist võlga ja seda ei pea pidevalt parandama. Saame teha sellega, mida soovime.

Vanade teenustega võivad ilmneda probleemid, mis on seotud sellega, et muutmine on alati keeruline. Seal on juba mingite tõsiste piirangute kogum, kuid võib-olla tegelevad nendega inimesed, kes on valmis kõike ümber tegema — nad on väsinud ja soovivad midagi teha teisiti, kuna see neile muret teeb.

Töötamine vana teenusega loob teie ettevõttes tugeva pretsedendi — midagi saab muuta. Kui olete uue teenuse muutnud, läheb see tootmisse 100 korda tunnis ja kõik on hästi, siis võivad teie ettevõtte inimesed öelda:

— See, this is a new service! It used to be simple; try doing something with our old wreck.

A legacy service makes sense to transform when you're doing it with someone, for example, if you have invited an external consultant. Let's be honest, the transformation will shake everything that can possibly be shaken.. You are experimenting and don't know where you'll end up, which technologies you'll use and for what purpose, and where potential pitfalls will arise in the processes. Hence, it’s easier to change the new one.

If you’re doing everything yourself, and the company lacks serious expertise—go for the new service. If you know an external consultant and have the budget—choose the old one.

There are services that represent just an interface for users, such as a simple website or mobile application. But there are serious things like billing. If something goes wrong with billing—you're going to have a hard time untangling it. Here, we also have a choice.

We either work with a critical service, but we're already suffering because of it; it's creating limitations, or we work with the interface. This is the second criterion for selection. Similarly, there's an option to engage an experienced consultant—working with the heavy variant.

But even in this case, I wouldn’t recommend doing so because, until there's an understanding of what to work with and which direction to transform in, taking a critical item and shaking it up—isn’t a very good idea. Therefore, in this case, we prefer to work with the interface, the breakdown of which isn’t critical.

Next, let's consider the service team. We will have to work closely with those who are dealing with this service.

The team members can be conditionally divided into two categories: conservatives — living in the old world, or simply know nothing about DevOps, and innovators, who bring in all the trendy practices. The latter may not always be well-versed in the subject, but at least they're open to it.

On one hand, conservatives are experienced individuals: they've been with the company for a long time, they know it inside and out, but don’t know about the practices. On the other hand are the innovators, who have heard something, but most likely haven’t been with the company for very long. Who should we work with?

Konservatiividega tuleb igal juhul suhelda, kuna see on nende teenus. Tõenäoliselt tuleb nendega vestelda, välja selgitada teenuse eripära, mida on võimalik teha nii ja mida teisiti. Me sõltume nende konsultatsioonidest. Tõenäoliselt tuleb neile midagi usaldada, kuna nad tunnevad oma teenust paremini. Seetõttu on oluline, millise meeskonnaga me lõpuks kokku puutume.

On loogiline valida meeskonda uuendajad, kuna konservatiivid võivad panna tagasilööke.

Praktiliselt juhtub tihti, et konservatiivsetel inimestel on oluline kogemus, kuid nad ei saa aru, kuidas edasi liikuda. Nad kardavad, et pärast teenuse transformatsiooni ja ümberkujundamist võidakse nad töölt vabastada. Mõnikord, lihtsalt arusaamatuse tõttu, mis toimub, saboteerivad nad tööd.

Mul oli puhul, kus meeskonna poiss parandas kõike, mis iganes, kuna see oli väidetavalt kriitilisem kui see, mida me praegu teeme. Me anname ülesande: rakendada täna see osa — ei, maailma teises otsas on tulekahju, läheme seda parandama. Selliste inimestega on raske töötada.

Konservatiivide meeskonnast tulevad inimesed tihti ignoreerivad ülesandeid või lükkavad need viimasel minutil edasi. Ja kui, jumal hoidku, olete teinud vea ja riputanud neile KPI'd ülesannete arvu kohta, kuid mingi osa ei ole mingil põhjusel KPI'sse kaasatud, siis nad ei tee absoluutselt midagi. Tegelikult on nad õiged, kuna nad kaotavad siis oma boonuse.

Uuendajatega on lihtsam — nad on lojaalsemad.Nad on juba midagi kuulnud, tahavad kuhugi minna, seetõttu on nad abiks. Me vajame inimesi, kes on valmis algul kannatama: kui teenus muutub, siis kõik probleemid ja takistused kogevad uuendajad esimestena. Uuendajad tahavad kõike uut ja stiilset ning olles valmis kannatama.

Konservatiive saab hiljem oma usku ümber pöörata. Kui näitate, et olete tüki muutnud ja kõik töötab hästi, siis tõenäoliselt soovivad nad ka proovida ja aktsepteerida uut DevOps'i religiooni.

Kokkuvõtteks. Kui me teeme kogu transformatsiooni oma ettevõttes ise, siis valime: uus teenus, eelistatavalt lihtne liides, et mitte liiga palju kannatada selle rikke pärast, ja uuendajate meeskond.

Kui on võimalus kutsuda välisekspert, siis võtame vana teenuse, mille pärast me juba kannatame, asemel et uut. Inimesed, kes on transformatsiooniga teinud tööd erinevates ettevõtetes, on näinud erinevaid juhtumeid ja mõistavad juba, kuidas õigesti tegutseda ning kuhu üldse suunduda.

Kes on seotud?

Peame leidma kõik, kes on kuidagi seotud teenusega: arendajad, testijad, adminnid, turbeeksperdid, juhid ja võimalik, et tootejuhid. Ehkki tootejuhid pole tehnilised spetsialistid, on nad teenusega seotud: nad teevad otsuseid ja seavad ülesandeid.

Peame leidma ja tutvuma kõigiga, kes teevad mis tahes otsuseid ja mõjutavad teenuse toimimist.

Miks nad meile vajalikud on? Kuna peame teadma, kellega läbirääkimisi pidada.. Transformatsiooni ajal, kui teenuse harjumuspärane töömeetod muutub, tuleb see kindlasti läbi elada. Mõnda aega esinevad tõrked, kuni katsetame uusi lähenemisviise. Inimesed peavad selleks olema valmis ja nõus.

Edasi tuleb ehitada väärtuste vooge kaart ja ilma nende inimesteta ei saa seda teha, sest ainult nemad teavad koos täielikku toimuvat pilti. Üks inimene ei tea kunagi kõike, mis teenusega toimub.

Nad soovitavad inimesi meeskonda. Hiljem arutame, miks vajame erilist meeskonda. Sellesse tuleb võtta inimesi olemasolevatest osakondadest. Need, kes on teenusega seotud, saavad soovitada kolleege, kes mõtlevad meie suunas ja kes saavad meid aidata ning omavad vajalikke oskusi.

Igal juhul kogume kõik need inimesed erinevatest osakondadest ühte ruumi ja hakkame ehitama väärtuste vooge kaarti.

Ehita väärtuste vooge kaarti

Väärtuste vooge kaart on skeem või kaart, mis näitab väärtuste voolu kliendini.. See on kogu protsess ideest rakendamiseni, sealjuures kõik vaheetapid ja see, kuidas väärtus lõpuks meie klientideni jõuab.

Väärtuste vooge kaardi jaoks on vajalik, et visualiseerida kõik arendusastmed,lokaliseerida probleemid praeguses protsessis mõõtmete kaudu ja alustada probleemide lahendamist ning seada esialgne eesmärk. See on koht, kus hakkame tõeliselt midagi tegema.

Mõõtmised

Väärtuste vooge kaartide kirjanduses on kirjeldatud palju erinevaid mõõdikuid, kuid alguseks piisab meile kolmest.

Täitmise aeg — viivitus/ootamine — aeg, mil me midagi ootame. Näiteks ootab testija, kuni testimiseks on saadaval seade, ja sel ajal ei saa ta midagi teha.

Value Added Time — väärtuslik tööaeg — see, mida kulutasime mingil etapil, et luua lõplik väärtus kasutajale. Näiteks käivitas testija oma testi ja hakkas midagi kontrollima. See on väärtuslik tööaeg, mil me tõeliselt teeme midagi toote heaks. Just selle eest kliendid maksavad — kvaliteetse tarkvara eest.

%C/A — vastuvõetud töö protsent. Meil on üks etapp — arendus, teine etapp — testimine. Kui palju funktsioone testijad on arendajatelt vastu võtnud, ja selle protsendi määrabki see.

Umbes nii näeb meie kaart välja.

See võib välja näha erinev sõltuvalt organisatsiooni struktuurist, osakondade arvust ja sellest, millega tegelete. Kuid üldiselt on kaardil kaks etappi: idee ja analüüs. Sellel etapil oodatakse andmeid, näiteks Lead Time 2 nädalat ja Value Added Time 2 päeva.

Kasutame mõõdikuid kõigil etappidel.

Backlog — kui palju ülesandeid jäi pärast seda, kui analüütikud need välja mõtlesid.

Arendus — kui palju nädalaid arendajad ootasid selgitusi ülesannete, seadmete või varustuse osas — see ei oma tähtsust, aga nad ootavad midagi. Näiteks, nad rakendavad funktsiooni 4 päeva. Siin tuleb mängu mõõdik %C/A. Arendajad võtsid Backlogist ainult 80% ülesandeid. Nad arvavad, et ülejäänud 20% pole piisavalt selgeid, ja saatsid need täiendavale töötlemisele.

Testimine. Skeemil on LT määratud 4 päeva. Näiteks ootasid testijad testimise seadme vabastamist, VA 2 päeva nad tegelikult testivad midagi, ja %C/A = 40%. — ainult 40% koodist või funktsioonidest, mille arendajad saatsid, arvasid testijad olevat sobivad. Kõik ülejäänud ei meeldinud neile mingil põhjusel.

Ma ei hakka üksikasjalikult rääkima, kuidas neid mõõtmisi teostada, artikli lõpus soovitan kirjandust, millest selle kohta rohkem teada saada.

Ainus asi, mida soovitan — ärge uskuge inimesi, kes koostavad koos teiega Value Stream Kaardi. Nad kujutavad ette, kui kaua erinevad protsessid aega võtavad, kuid need hinnangud ei ole alati õiged, seega on parem neid ise mõõta.

Meil oli juhtum, kui me läksime Operations osakonda ja küsisime, kui kaua kulub uue funktsiooni tootmisse toimetamiseks. Vastus oli 10 minutit, ja me mõtlesime, miks me üldse sellesse ettevõttesse tulime? Selgus, et 10 minutit on skripti tööaeg, mis võtab koodi ja toimetab serverisse. Kuid enne seda oli versioon kolme päeva jooksul serveris ja lihtsalt tolmu kogumas — Backlogis ootas ülesanne, mis tuleb välja viia. Seega on enne juurutamisetappi ooteetapp, kus projekt lihtsalt seisab. Kui me poleks läinud oma märkmete ja silmadega ülesandeid Jira-s jälgima, siis oleksime arvanud, et kõik on suurepärane ja mingit probleemi ei ole.

Seetõttu on mõõtmised ikkagi kellegi enda poolt tehtud, eelistatult mitte ainult üks kord, et saada võimalikult lähedane arusaam reaalsusest. Sõltuvalt Value Stream Map-ist teete otsuse, kust kohast alustada ja mida kõigepealt parandada.

Ajutine meeskond

Paljud ettevõtted, kes otsustasid DevOpsi rakendada, loovad meeskonna, mis ei ole ajutine, vaid eksisteerib mitu aastat. Kui küsite DevOps apologizelt, kus on kirjeldatud erinevaid organisatsioonistruktuuri mustreid DevOps-is, mõistate, et see on antipattern.

Kui DevOps-meeskond eksisteerib pidevalt mitu aastat, on see suur viga, kuna DevOps tähendab osakondade vahelist suhtlust, kiirus ja efektiivsus.

Kui meeskond eksisteerib osakondade vahel, et teha midagi muud eraldi ning püsib kaua, loob see lisabarjääri. Nüüd peab arendaja administreerijaga küsimuse lahendamiseks minema esmalt DevOps osakonda, ja alles siis minema edasi.

Seetõttu peab alustamiseks looma ajutise meeskonna.. Ta eksisteerib tinglikult pool aastat, maksimaalselt aasta, sõltuvalt seatud ülesandest, ainult selleks, et kõrvaldada üks piirang, mille oleme valinud. Pärast seda sureb ta. Kui me valime järgmise punkti, kus meil on tugev valu, ja mõistame, et selle jaoks on meil samuti vaja eraldi meeskonda, siis loome selle uuesti. Kuid „püsivalt” ei tohiks sellised meeskonnad eksisteerida - siis nad lihtsalt rikuvad kommunikatsiooni ja võtavad endale täiesti eraldiseisvaid ülesandeid, ainult midagi tehes. Need ülesanded ei pruugi olla seotud DevOps'i ja transformatsiooniga. Miks mitte anda see ülesanne olemasolevatele osakondadele?

Miks on vajalik ajutine meeskond

Konflikt praeguste protsessidega. DevOps'i transformatsioon on muutus mitte ainult tehnoloogias ja tööriistades, mida kasutame, vaid ka tööprotsessides, mõtlemises ja väärtustes. Kui meeskond töötab endiselt nii, nagu nad on harjunud, ei õnnestu neil proovida muid lähenemisviise.

Need inimesed peavad elama teiste reeglite järgi: ignoreerima ettevõtte kõiki KPI-sid, sest nad proovivad töötada teisiti. Ajutised meeskonnad ei täida ankeete serveri saamiseks, vaid lähevad otse osakonda, mis neid haldab, nõudma kõigepealt vajadusi, sest see on prioriteetne ülesanne ja nad püüavad elada teisiti. Meeskonnal on täielik konflikt kõigi olemasolevate protsessidega. Et olemasolevad töömeetodid neid hetkel ei segaks ja nad ei segaks teisi, isoleerime need inimesed, luues eraldi meeskonna.

Bürokraatia vältimine katsetustes. Ajutistes meeskondades ei ole bürokraatiat, nad ei täida töötundide aruandeid, nad ei pea aru andma juhtidele. See on täiesti eraldi maailm, kus inimesed elavad ja mõtlevad teisiti ning tegelevad täiesti erinevate asjadega. Neid ei tohi liialt segada.

Katkematu töö teenuse nimel. Esimeses punktis valisime midagi, millega katsetada. Katsetamine ja paremate tööviiside otsimine on hea, kuid me tahame ka funktsioone teha. Kui kogu meeskond tegeleb funktsioonide asemel transformatsiooniga, hakkame kaotama tulu, vead jäävad kauaks alles - seda me ei vaja. Ajutise meeskonna loomine võimaldab katsetada, katkestamata samal ajal toote arendamist.

Ära kuluta aega tööülesannetele. See on jälle toote kohta. Meeskonnal kulub palju aega, et katsetada muid tööriistu ja muud. Et inimesed mõistaksid tööriistu, hakkaksid neid rakendama ja normaalselt kasutama, kulub vähemalt pool aastat. Kui nad tegelevad veel ka tootega, siis venib see pool aastat kosmiliselt. Kui inimesed tegelevad tootega, töötavad nad jälle vanade protsessidega — seda me ei vaja.

Seetõttu eraldame erinevatest osakondadest inimesi eraldi meeskonda, mis tegeleb teenuse transformatsiooniga. Tulemusena töötab teenus, jätkab arendamist ja samal ajal katsetame selle peal mingisuguseid eksperimente.

Ajutine meeskond tegeleb ainult DevOps-transformatsiooniga — eemaldades leitud piirangu ja mitte millegagi muuga.

Meeskond koosneb universaalsetest inimestest. See tähendab, et oleme võtnud mitte ainult arendajad. Me ei tulnud teenusesse ja ei võtnud sealt pool meeskonda — ei, me võtsime inimesi erinevatest osakondadest. Mõni punkt tagasi leidsime erinevad osakonnad ja erinevad töötajad, kes on seotud muudetava teenusega. Nendest koostame meeskonna, sest see peab olema universaalne — me muudame nii testimisprotsessi, arendusprotsessi kui ka teenuse hooldamise protsessi. Vajame erinevaid kompetentse.

Tavaliselt võtame arendaja, testija ja inseneri — igaühe ühe ja koos nendega leiutame lahenduse, mis võimaldab elada teisiti.

Soovitav on, et need inimesed oleksid organisatsioonis autoriteetsed. Võib-olla tuleb võtta üks konservatiiv, kuigi pole soov. Kui meie ettevõte on suur, ei usu kaugeltki kõik meie plaani ja mõned võivad seada takistusi, näiteks mitte eraldada seista. Siin tulebki mängu "autoriteet" — austatud inimene, kellel on suur kogemus ja kes on teeninud kolleegidelt head suhtumist. Töötaja autoriteet meeskonnas lihtsustab ülesannet ja ajutise meeskonna tööd. Inimesed mõtlevad:

— Ahjaa, see äge tüüp, keda me kõik tunneme ja armastame, on sinna sisse astunud — näib, et DevOps-is on midagi, millele tasub tähelepanu pöörata!

Seame eesmärgi

Kogusime inimesi, valisime teenuse, vaatlesime piiranguid, määrasime, kellele me mõju avaldame. Nüüd peab olema eesmärk ja see peab olema täiesti SMART — kõik, nagu me armastame.

Spetsiifiline — konkreetne.

Mõõdetav — mõõdetav. See on väga oluline SMART punkt. Kui te ei saa midagi mõõta, siis ei saa te seda muuta ega mõista, mida ja kuidas olete teinud paremini või halvemini.

Saadav — saavutatav. Arvesse tuleb võtta oma eripära. Kui olete suur ettevõte, millel on pikk ajalugu ja palju kohustusi, mis väljastab uue toote versiooni kord aastas, siis ei saa te kuue kuu jooksul saavutada uute tooteversioonide väljalaskmist iga tunni tagant. Nii ei õnnestu. Seega seadke realistlik eesmärk, mis on saavutav mõistlikus ajaraamis.

Asjakohane — relevant. Käitleme ainult seda piirangut, mis tõeliselt mõjutab meie praeguseid eesmärke.

Aja piirang — ajaliselt piiratud. Kui tähtaega pole, siis meeskond tegeleb millegagi: katsetab 15 tehnoloogiat 3 asemel, kirjutab tohutuid aruandeid, viib läbi kasutuid uuringuid, lihvib oma teostust hiilgavaks, kui eesmärk on juba saavutatud.

Eesmärgid seame just Value Stream Map'i abil — taas kogume kõik inimesed kokku ja joonistame. Kuid seekord joonistame selle põhjal, mida soovime saada, eelneva Value Stream Map'i alusel.

Kipume välja tooma ühe piirangu, mida hakkame kohe kõrvaldamiseks tööle, millega meeskond tegeleb. Näiteks võtsin ooteaja valmimise ja selle juurutamise vahe enne tootmisse jõudmist — see on kõige sagedasem piirang, mille tõttu inimesed pöörduvad konsultantide poole.

Selle põhjal seame ülesande: soovime, et ooteaeg valmimise ja lahingusse mineku vahel oleks maksimaalselt üks tund.

Näidised ülesannetest.

• Kärpida testimise läbiviimise aega 4 päevast 1 tunnini.
• Kärpida väärtusliku aja kuluda testimise jaoks 2 päevast 3 tunnini.
• Kärpida juurutamise läbiviimise aega 5 tunnist 10 minutini.
• Suurendada C/A 50%-lt 95%-le, see tähendab suurendada funktsioonide arvu, mille testijad aktsepteerivad, teisisõnu, parandada arendajate töö kvaliteeti.

Näidiste ülesanded ei ole väljamõeldud — need põhinevad mõõtmistel, mida me tegime, kui töötasime välja Value Stream Map'i.

Seame sarnase ülesande oma meeskonnale ja ajapiirangut. Sõltuvalt sellest, kui hästi läheb teie ettevõttes, seadke erinevad tähtajad. Keskmiselt kulub piirangu kõrvaldamiseks, kui inimesed tegelevad sellega esmakordselt ja ei tea veel, milliste tehnoloogiate abil ja kuidas probleemi lahendada, tavaliselt kuus kuud.

Lühike planeerimine

Nii et, meie meeskond on loodud, tal on eesmärk ja inimesed hakkavad töötama. Oluline punkt on töö lühike planeerimine: sprindid üks kuni kaks nädalatja mitte rohkem, mõõdetavad parandused iga nädal ja kursi korrigeerimine.

Näiteks kasutame me sageli lähenemist moving-moving, kus kogu meeskond koguneb iganädalaselt, viskab kirja, mida igaüks teeb. Nädala pärast märkame: mis on tehtud ja mis mitte, kui mitte, siis miks, ja mõtleme, mida edasi teha.

Sprindid võimaldavad kursust õigel ajal korrigeerida.

Nädala või kaks proovime midagi: tehnoloogiaid, lähenemisi, tööviise, pärast seda mõõdame uuesti ja vaatame — kas selle lähenemisega on parem või halvem? Kui halvem, siis ei liigu me õiges suunas, tuleb kursust korrigeerida: seada uus ülesanne, võtta kasutusele muu tehnoloogia või teha midagi muud. Lühikesed sprindid 1-2 nädala vältel võimaldavad manööverdada ja õigeaegselt halbadest lahendustest kõrvale hoiduda.

Jagame edusamme

Meeskond saavutab teatud edusamme, olgu need väikesed või suured — pole vahet, alati on mingit tulemust. Sellest tulemusest peaksid olema teadlikud kõik: nii need, kes on seotud DevOpsiga, kui ka naabruses asuvad osakonnad. Ideaalsetes tingimustes võiks see jõuda üldse kõikide ettevõtte inimesteni.

Miks? Kui me soovime transformeerida mitte osa ettevõttest, välja juurida mitte ühte piirangut, vaid kõik, et ettevõte muutuks paindlikuks, kood liiguks kiiresti kliendini ja miski ei katke, siis on oluline, et kõik oleksid DevOpsi ideele lojaalsed. Te ei saa rakendada lähenemist teenustele ja meeskondadele, kes on absoluutsete vastaste seas.

Loodud lojaalsuseks peame rääkima kõigile, mida oleme proovinud — meil on tulemus, proovige ka! See tõstab huvi ja lojaalsust selle vastu, millega me tegeleme, inimesed hakkavad proovima kohe midagi teha. Praktika on näidanud, et kui me räägime, mida oleme proovinud ja milles oleme edu saavutanud, hakkavad teised meeskonnad küsima, kuidas ja mida me tegime. Nad vaatavad teostusi, koodi, dokumentatsiooni, lähenemise küsimustega ja püüavad midagi enda juures muuta.

Rääkida sellest, mis teil on saavutatud — on oluline. Nii veenate te konservatiive, kes soovisid kõike teha vanaviisi, liikuma teie poole ning muundate nad innovaatikuteks.

Kokkuvõttes

Valime teenuse, kui lähtepunkti — koht, kus alustame ettevõttes muutusi. Tuvastame kõik, kellel on seos teenusega ja koos nendega ehitame Value Stream Mapi, mõõdame ja vaatame, kus ja millised on piirangud.

Loome uue ajutise meeskonna, mis lahendab pandud ülesande. Mõõtmiste ja Value Stream Mapi põhjal juhime uue kaardi, kus eristame piirangut, mille lahendamisega tegeleme. Selle piirangu põhjal seame ülesande, millega meeskond tegelema hakkab. Ülesanne peab olema kindlasti SMART — spetsiifiline, mõõdetav, praeguste ülesannetega asjakohane ja ajaliselt piiratud.

Korrame protsessi, kuni oleme transformeerinud kõik meie teenused soovitud kujule ja kõrvaldanud kõik piirangud.

Boonus. Kasulikud materjalid

Neile, kes otsustasid tegeleda DevOpsiga iseseisvalt.

Projekt "Feniix"

Originaalne pealkiri — "The Phoenix Project: A Novel about It, Devops, and Helping Your Business Win". See on romaan DevOpsist — lugu sellest, kuidas töötajatest sai osakonna juhataja, kes pidevalt lahingus oli. Uuele juhile pandi ülesanne:

— Sul on mitu aastat aega, et kõik ära parandada, et me lõpuks saaksime kiiresti ja tõhusalt tarnida meie toodet meie klientidele.

„Feniixi projekt. Romaan sellest, kuidas DevOps muudab elu paremaks” — raamat kõigile juhtidele, sest just need inimesed teevad otsuseid selle kohta, mis ettevõttes toimub. Kui oled insener või programmeerija ja tahad, et sinu ettevõttes algaks muutus ja transformatsioon — osta raamat ja kingi juhtkonnale. See romaan selgitab kõike ning seda on kiire ja lihtne lugeda.

DevOps'i juhend

Rohkem keeruline raamat. Ilmus paar aastat tagasi ingliskeelsena pealkirjaga "The DevOps Handbook: How to create world-class agility, reliability, and security in Technology organizations", kuid nüüd on juba saadaval eesti keeles. See on tõeline käesolev juhend — praktiline juhend: kuidas läbi viia mõõtmisi, mis on Value Stream Map ja miks see vajalik on, kuhu liikuda ja millises järjekorras. Raamat on mõeldud just neile, kes soovivad ise kõike teha. Kõige tähtsam, et selles on teiste ettevõtete kogemuse näiteid.

Näiteks räägitakse seal, kuidas üks ettevõte koostas Value Stream Map'i ja mõistis, et nende piirang ei ole tootes, vaid selles, et kassapidaja käib poest naaberbüroosse, et toodet kasutada. Probleemi programmi lahendamise asemel ostsid nad oma müüjatele tahvelarvutid ning nüüd ei pea keegi kuhugi minema, kõik tegevused toimuvad töö kohal. Järeldus: Value Stream Map'i saab rakendada mitte ainult tarkvarale, vaid ka kõikidele organisatsiooni protsessidele.

Kiirendama

Täpne pealkiri: «Kiirendamine: Lean tarkvara ja DevOpsi teadus: Kõrge saavutusvõimega tehnoloogiaorganisatsioonide loomine ja skaleerimine». See on järgmine tase — kõva. Raamat ilmus eelmisel aastal, hetkel ainult inglise keeles ja see käsitleb teadusuuringuid. Autorid — Nicole Forsgren, Jez Humble ja Gene Kim — on aastaid rakendanud erinevaid praktikaid erinevates ettevõtetes ning uurinud, kuidas praktikaid, kuidas ja millele need mõju avaldavad.

Teises peatükis, mis on pühendatud mõõtmistele, mainitakse Value Stream Map'i, neid mõõdikuid, mida ma nimetasime, ja paljusid teisi, samuti on põhjalikult kirjeldatud mõõtmise protsessi. Autorid viivad mõõtmised läbi küsimustike ja iseseisva ülesannete jälgimisega. Räägitakse täpselt, milliseid mõõdikuid tuleks õigesti mõõta, milliseid mitte, inimlikud vead mõõtmistes. Kui teil on mõõtmisega raskusi, pöörduge raamatu „Kiirendamine” teise peatüki poole. Kui teie meeskonnas on lihtsalt palju praktikaid, kuid pole selge, milliseid praktikaid praegu rakendada, milliseid hiljem, millised tõeliselt toimivad ja millised mitte — loe, raamatus on kõik selgelt selgitatud.

Transformatsioon on küsimus DevOpsi ja juhtimise piiril. Kusagil seal arendamise, haldamise ja testimise ristumiskohas on teemad, mida proovime arutada DevOpsConf, sama integratsioon on vajalik ka kvaliteetsete toodete loomiseks – peamine teema KvaliteediKonf. Juhtimine festivalil RIT++ umbes 800 rakendust. Uute rakenduste arendamise lihtsustamiseks on ette valmistatud tüüpiliste Whale Rider — tähendab, et kõik ideed transformatsiooniks on sinna. Liituge 27. ja 28. mail, me integreerime ja transformeerime.

Allikas: habr.com