Kuidas alustada DevOpsi transformatsiooni

Kui te ei mõista, mis on DevOps, siis siin on lühike ülevaade. DevOps on praktiseerimise kogum, mis vähendab inseneride hirme ja vähendab tarkvaratootmise katkestusi. Tavaliselt vähendavad nad ka turulejõudmise aega — ajavahemikku ideest kuni lõppprodukti kohaletoimetamiseni klientidele, mis võimaldab kiiresti läbi viia äri eksperimente.

Kuidas alustada DevOpsi transformatsiooni? Lühidalt: valime teenuse, millega protsessi alustada, tuvastame teenusega seotud inimesed, loome väärtusvoo kaardi, kujundame ajutise meeskonna, mis tegeleb transformatsiooniga esialgu ja määrame talle ülesande. Korrame tsüklit vajalik arv kordi.

Üksikasjalik DevOps-i transformatsiooni plaan koos näidiste ja juhistega on allpool — inseneri raport Express42 ettevõttest, mis annab nõu DevOpi kasvatamise kohta, kiirendades seda protsessi, sest on juba koostanud takistuste kaardi. Kui teile tundub, et transformatsioon pole vajalik või teil on spetsiifika, et DevOps praktikad ei sobi, — kasutage aruannet juhisena piirangute leidmiseks ja kõrvaldamiseks. ettekandest Andrei Aleksandrov — insener Express42's, kes konsultatsioonidega DevOpsi kasvatamiseks, kiirendades seda protsessi, sest on juba loonud müraskaarte. Kui teil tundub, et transformatsioon ei ole vajalik, või kui teil on spetsiifilisus, mis ei sobi DevOps-praktikatega, — kasutage ettekannet juhendina piirangute leidmiseks ja eemaldamiseks.

Kui DevOps-i transformatsiooni küsimus teid vaevab, siis tähendab see, et teil on suur ettevõte ja peate seda protsessi järk-järgult skaleerima kogu struktuuri ulatuses. Kuni on vajadus meeskonda transformeerida või mõni piirang kõrvaldada, saab allolevat algoritmi korrata.

Teenuse valik

Plaani oleme loonud, alustame esimesest sammust — teenuse valimisest. Esimene kriteerium — eluea pikkus: on vanu teenuseid — legacy, ja uusi. Alustada saab nii vanadest kui uutest.

Noore teenuse valimine on mõistlik. See on värske, seal ei ole veel väljakujunenud töösüsteemi meeskonnas, mis sellega tegeleb. Selle ümber ei ole tohutut tehnilist võlga, ei pea seda pidevalt parandama. Saame sellega teha kõike, mida soovime.

Vanade teenustega kaasnevad probleemid, mis on seotud sellega, et muutmine on alati keeruline. Seal on juba teatud tõsiste piirangute kogum, kuid võib-olla tegelevad sellega inimesed, kes on valmis kõik üle vaatama — nad on väsinud ja soovivad midagi teisiti teha, sest neil on valus.

Töö vanade teenustega loob tugeva pretsedendi teie ettevõttes — on võimalik midagi muuta. Kui olete lisanud uue teenuse, mis töötab tootmises 100 korda tunnis ja kõik on korras, siis teie ettevõtte inimesed võivad öelda:

— See on ju uus teenus! Seal oli ju kõik lihtne, proovige meie vanakese jaoks midagi ära teha.

Legacy-teenust on mõttekas kaasata transformatsiooni, kui teete seda kellegagi koos, näiteks kui olete kutsunud välist konsultandi. Olgem ausad, transformatsioon hakkab kõik, mis võimalik, raputama.. Te eksperimenteerite ja ei tea, kuhu jõuate, milliseid tehnoloogiaid ja miks kavatsete kasutada, kus ja milliseid takistusi protsessis võib tekkida. Seetõttu on uue vahetamine lihtsam.

Kui teete kõik ise ja ettevõttes pole tõsist kompetentsi — valime uue teenuse. Kui tead väliskonsultanti ja ressursse on — valige vana.

On teenuseid, mis on lihtsalt kasutajaliides, nagu lihtne veebileht või mobiilirakendus. Kuid on ka tõsiseid asju, nagu arveldamine. Kui midagi peaks arveldamisega valesti minema — on keeruline probleeme lahendada. Siin on meil ka valik.

Me töötame kas kriitilise teenusega, kuid me juba kannatame selle tõttu, see loob piiranguid, kas töötame liidese. See on valiku teine kriteerium. Samamoodi on võimalus kaasata kogenud konsultant — töötame keerulise variandiga.

Kuid isegi sel juhul ei soovitaks ma nii teha, sest seni, kuni pole selgust, millega töötada ja millises suunas transformeerida, on kriitiline asi haaramine ja selle ümbertegemine — ei ole just hea idee. Seega eelistame sel juhul töötada liidesega, mille rike ei ole kriitiline.

Edasi vaatame teenuste meeskonda. Nendega, kes selle teenusega tegelevad, peame pidevalt töötama ja väga tihedas kontaktis olema.

Meeskonna liikmed jagunevad tinglikult kahte kategooriasse: konservatiivid — elavad vanas maailmas või ei tea lihtsalt DevOps-ist midagi, ja uuendajad, kes toovad kõik moes olevad praktikad. Teised ei pruugi alati teemas orienteeruda, kuid nad on vähemalt valmis sellega tegelema.

Ühelt poolt on konservatiivid kogenud inimesed: nad on ettevõttes juba pikka aega, tunnevad kõike põhjalikult, kuid ei tea, kuidas praktikat ellu viia. Teiselt poolt on innovaatikud, kes on midagi kuulnud, kuid tõenäoliselt ei ole nad ettevõttes kaua töötanud. Kellega neist on parem koostööd teha?

Konservatiividega tuleb igal juhul suhelda, kuna see on nende teenus. Peame nendega suhtlema, et välja selgitada teenuse spetsiifika, mida saab teha ja mida ei saa. Me sõltume nende nõuannetest. Kindlasti tuleb neile midagi usaldada, kuna nad tunnevad oma teenust paremini. Seetõttu on oluline, kellega me lõpuks kontaktis oleme.

Loogiline on valida meeskonda innovaatikud, kuna konservatiivid võivad kaasa tuua probleeme.

Praktikas juhtub sageli, et konservatiivsetel inimestel on märkimisväärne kogemus, kuid nad ei mõista, kuidas edasi liikuda. Nad kardavad lihtsalt, et pärast teenuse ümberkujundamist ja muutmist vabastatakse nad töölt. Mõnikord sabotaaživad nad oma tööd lihtsalt arusaamatuse tõttu selle suhtes, mis toimub.

Mul oli juhtum, kui üks meeskonnaliige parandas kõike, mida iganes, sest see oli väidetavalt kriitilisem kui see, millega me parajasti tegeleme. Me anname ülesande: täita täna see osa — ei, teisel pool maailma on tuli, läheme seda kohe parandama. Selliste inimestega on raske töötada.

Konservatiivide meeskonna liikmed sageli ignoreerivad ülesandeid või lükkavad neid viimasele minutile. Ja kui, jumal hoidku, teete vea ning määrate neile KPI, mis põhineb täidetud ülesannete arvul, kuid mingi osa on mingil põhjusel KPI-st välja jäetud, siis nad ei tee absoluutselt midagi. Tegelikult on nad õiged, kuna kaotavad seeläbi preemia.

Uuendajatega on lihtsam — nad on lahkemad.Nad on juba midagi kuulnud, tahavad kuhugi jõuda, seetõttu aitavad nad hea meelega. Me vajame inimesi, kes on valmis esialgu kannatama: kui teenus muutub, siis koguvad kõik probleemid ja takistused esimesed innovaatorid -- kui esimesed. Innovaatoreid tõmbab kõik uus ja moekas ning nad on valmis kannatama.

Konservatiive on hiljem võimalik meelt muuta. Kui näitate, et olete väikese muudatuse teinud ning kõik töötab, tahavad nad tõenäoliselt ka proovida ning omaks võtta uut DevOps usku.

Kokkuvõtteks. Kui me teeme kogu muudatuse ise oma firmas, valime: uue teenuse, eelistatavalt lihtsa liidese, et mitte liiga palju kannatada selle rikkumise tõttu, ja innovaatilise meeskonna.

Kui on võimalus kutsuda välisekspert, võtame uue asemel vanema teenuse, millega juba kannatame. Inimesed, kes on tegelema transformatsiooniga piisavalt kaua erinevates ettevõtetes, on näinud erinevaid juhtumeid ja saavad aru, kuidas õigesti edasi minna ning milliseks suunaks liikuda.

Kes on seotud?

Peame leidma kõik, kes on teenusega mingil moel seotud: arendajad, testijad, administraatorid, turvalisusspetsialistid, juhid ja võimalusel ka tooteomanikud. Kuigi tooteomanikud ei ole tehnilised inimesed, on nad teenusega seotud: nad teevad otsuseid ja määravad ülesandeid.

Kõik, kes teevad mingisuguseid otsuseid ja mõjutavad teenusega toimuvaid asju, tuleb leida, nendega tutvuda ja suhelda.

Miks nad on meile vajalikud? Kuna on oluline teada, kellega läbirääkimisi pidada.. Teenuste kasutamise harjumus muutub ja selle käigus võib esineda tõrkeid. Uute lähenemiste katsetamise ajal on tõenäoline, et võib esineda katkestusi. Inimesed peavad selleks valmis olema ja sellega nõus olema.

Edasi tuleb koostada Value Stream Map ja ilma nende inimesteta ei saa seda koostada, kuna ainult nemad teavad ühiselt täielikku pilti toimuvast. Üks inimene ei tea kunagi kõike, mis teenusega seotud on.

Nad soovitavad inimesi meeskonda. Hiljem arutame, miks on vajalik eraldi meeskond. Sellesse tuleb värvata inimesi olemasolevatest osakondadest. Need, kellel on teenusega seos, saavad soovitada kolleege, kes mõtlevad meie suunas ja kes saavad meid aidata ning kellel on vajalikud oskused.

Seejärel kogume kõik need inimesed erinevatest osakondadest ühte ruumi ja hakkame koostama Value Stream Map'i.

Koostame Value Stream Map'i

Value Stream Map on skeem või kaart, mis näitab väärtuste voogu kliendini.See on kogu protsess alates idee välja mõtlemisest kuni selle elluviimiseni, sealhulgas kõik vaheetapid ja see, kuidas väärtus lõpuks meie klientideni jõuab.

Value Stream Map on vajalik, et visualiseer kõik arenduse etapid, lokaliseerida probleeme olemasoleva protsessi mõõtmiste kaudu ja alustada nende probleemide lahendamist ning seada esialgne eesmärk. See on koht, kus hakkame midagi tõeliselt tegema.

Mõõdikud

Value Stream Map'i kirjanduses on palju erinevaid mõõdikuid, kuid alguseks piisab meile kolmest.

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

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

%C/A — vastuvõetud töö protsent. Meil on üks etapp — arendus, teine etapp — testimine. Kui palju funktsioone testijad arendajatelt vastu võtsid, ja see protsent on olemas.

Umbes nii näeb välja meie kaart.

See võib sõltuda organisatsiooni struktuurist, osakondade arvust ja teie tegevusalast. Ü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.

Mõõdikud katab absoluutselt kõik etapid.

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

Arendus — kui palju nädalaid arendajad ootavad ülesannete, stendide või varustuse selgitusi — ei ole oluline, kuid nad ootavad midagi. Näiteks, nad teevad funktsiooni 4 päeva. Siin tekib mõõdik %C/A. Arendajad võtsid Backlog'ist ainult 80% ülesandeid. Nad arvavad, et 20% jääb ebamugavalt udususeks, ja saatsid need edasi ümbertegemiseks.

Testimine. Kujutisel on LT määratud 4 päeva. Näiteks ootavad testijad teststendi vabastamist, VA 2 päeva nad testivad tegelikult midagi, ja %C/A = 40 %. — vaid 40 % koodist või funktsioonidest, mida arendajad saatsid, pidasid testijad piisavaks. Kõik muu ei meeldinud neile mõnel põhjusel.

Ma ei hakka üksikasjalikult rääkima, kuidas neid mõõtmisi teha, kuid artikli lõpus soovitan kirjandust, kust saate rohkem teada.

Ainult seda soovitan — ärge uskuge inimesi, kes koostavad teiega väärtusvoo kaardi. Nad näitavad, kui palju aega eri protsessid võtavad, kuid need hinnangud ei ole alati tõesed, seega on parem ise mõõta.

Meil oli juhtum, kui läksime operatsioonide osakonda ja küsisime, kui kaua kulub uue funktsiooni tarnimiseks tootmisse. Vastus oli, et 10 minutit, ja mõtlesime, miks me üldse sellesse ettevõttesse tulime? Selgus, et 10 minutit on skripti tööaeg, mis võtab koodi ja toob selle serverisse. Kuid enne seda on versioon olnud kolm päeva serveris ja lihtsalt tolmub — Backlogis on ülesanne, mis tuleb juurutada. Tähendab, et juurutamise eel on ootamisetapp, kus projekt lihtsalt seisab. Kui me poleks läinud märkmeraamatuga, ei oleks me näinud ülesannet Jira-s ja ei oleks seda etappidena jälginud, siis arvaksime, et kõik on suurepärane ja probleeme pole.

Seetõttu tuleb mõõtmisi siiski ise teha, soovitavalt mitte ainult üks kord, et omada reaalsusele lähedast ettekujutust. Sõltuvalt Value Stream Map'ist teete otsuse, kust alustada ja mida kõigepealt parandada.

Ajutine meeskond

Paljud ettevõtted, kes otsustavad DevOpsi rakendada, loovad meeskonna, mis ei ole ajutine, vaid eksisteerib mitu aastat. Kui pöördute DevOps palveli juurde, kus on kirjeldatud erinevaid korraldusstruktuuri mustreid DevOpsis, siis saate aru, et see on antipattern.

Kui DevOps meeskond eksisteerib pidevalt mitu aastat – on see suur viga, kuna DevOps tähendab kommunikatsiooni osakondade vahel, kiirus ja efektiivsus.

Kui meeskond eksisteerib osakondade vahel ainult selleks, et teha midagi muud eraldi ning eksisteerib kaua, siis loob see tarbetu takistuse. Nüüd peab arendaja, selle asemel et minna kohe administraatori juurde küsimust lahendama, esmalt pöörduma DevOps osakonna poole, kes seejärel edasi läheb.

Seetõttu tuleb alustamiseks luua ajutine meeskond. Ta eksisteerib tinglikult pool aastat, maksimaalselt aasta, sõltuvalt seatud eesmärgist, et ületada üks valitud piirang, millele keskendume. Edasi see sureb. Kui valime järgmise punkti, kus on tugevalt valus, ja mõistame, et selleks on meil samuti vaja eraldi meeskonda, siis loome selle taas. Kuid „püsivalt” ei tohiks sellised meeskonnad eksisteerida — muidu nad ainult häirivad kommunikatsiooni ja võtavad endale täiesti eraldi ülesandeid, et lihtsalt midagi teha. Need ülesanded võivad olla üldse mitte seotud DevOps'iga ja transformatsiooniga. Miks mitte anda see ülesanne olemasolevatele osakondadele?

Miks on vajalik ajutine meeskond

Konflikt praeguste protsessidega. DevOps'i transformatsioon tähendab mitte ainult tehnoloogiate ja tööriistade muutmist, mida me kasutame, vaid ka tööprotsessi, mõtlemise ja väärtuste muutmist. Kui meeskond töötab nii, nagu ta on juba harjunud, ei suuda ta proovida teisi lähenemisviise.

Need elada vastavalt teistele reeglitele: ignoreerida kõiki ettevõtte KPI-sid, kuna nad püüavad töötada teisiti. Ajutised meeskonnad ei täida taotlusi serveri saamiseks, vaid lähevad otse osakonda, mis nendega tegeleb, nõudma, et neil antaks kõigepealt see, mis vajalik, kuna see on prioriteetne ülesanne ja kuna nad püüavad elada teisiti. Meeskonnal on täielik konflikt kõigi olemasolevate protsessidega. Et praegused töömeetodid neid ei segaks ja nad ei segaks teisi, isolatsioonime neid inimesi, moodustades eraldi meeskonna.

Bürokraatia vältimine katsetes. Ajutistes meeskondades ei ole bürokraatiat, nad ei täida tööaja aruandeid, nad ei vastuta juhtidele. See on täiesti eraldi maailm, kus inimesed elavad ja mõtlevad teisiti ning tegelevad täiesti teiste asjadega. Ärge segage neid üleliia.

Katkematu töö teenuse kallal. Esimese punktina valisime midagi, mille kallal katsetada. Katsetamine ja otsimise viis paremaks toimimiseks on head, kuid me tahame ka funktsioone luua. Kui kogu meeskond tegeleb transformatsiooniga funktsioonide asemel, hakkame tulu kaotama ning vead jäävad kauaks rippuma — seda me ei vaja. Ajutise meeskonna loomine võimaldab katsetada, peatamata samal ajal töö tegemist toote kallal.

Ära kuluta aega tööülesannetele. See on jälle toote kohta. Selleks, et meeskond saaks proovida teisi tööriistu ja muud, kulub palju aega. Et inimesed omandaksid tööriistad, hakkaksid neid rakendama ja korralikult kasutama, kulub vähemalt kuus kuud. Kui nad teevad veel tootega tööd — venivad kuud lõputuks. Kui inimesed tegelevad tootega, töötavad nad taas vanade protsessidega — seda me ei vaja.

Seetõttu valime erinevatest osakondadest inimesi eraldi meeskonda, mis tegeleb teenuse transformatsiooniga. Tulemuseks on see, et teenus töötab, jätkab arenemist ja samal ajal katsetame selle peal mingeid eksperimente.

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

Meeskond koosneb mitmekesistest inimestest. See tähendab, et ees on mitte ainult arendajad. Me ei tulnud teenusesse ja ei võtnud sealt poole meeskonda — ei, me võtsime inimesi erinevatest osakondadest. Mõni punkt tagasi leidisime erinevad osakonnad ja erinevad töötajad, kes on seotud transformeeritava teenusega. Neist me moodustame meeskonna, kuna see peab olema mitmekesine — me muudame nii katsetamisprotsessi, arendamisprotsessi kui ka teenuse toetamise protsessi. On vajalikud erinevad oskused.

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

Soovitatav on, et need inimesed omaks autoriteeti organisatsioonis. Võib-olla tuleb võtta üks konservator, kuigi see ei meeldi. Kui meie ettevõte on suur, ei usu kõik meie ideesse, ja keegi võib segada, näiteks mitte eraldada stendi. Siin tuleb mängu autoriteet — respekteeritud inimene, kellel on suur kogemus ja kes on teeninud kolleegide head suhtumist. Töö autoriteet meeskonnas lihtsustab ülesannet ja ajutise meeskonna tööd. Inimesed mõtlevad:

— Aha, see äge mees, keda me kõik tunneme ja armastame, on seal — ilmselt on DevOps'is midagi, mida tasub vaadata!

Seame eesmärgi

Oleme inimesi kokku kogunud, valinud teenuse, vaadanud piiranguid ja määratlenud, kellele me mõju avaldame. Nüüd tuleb seada eesmärk ja see peab olema just SMART — kõik nii, nagu me armastame.

Specific — konkreetsed.

Measurable — mõõdetavad. See on väga oluline punkt SMARTis. Kui te ei saa midagi mõõta, ei saa te seda muuta ja aru saada, mis ja kuidas te tegite paremini või halvemini.

Achievable — saavutatavad. Arvestage oma spetsiifikat. Kui olete enterprise-ettevõte, millel on pikk ajalugu ja suured kohustused, ning toote versioon tuleb välja kord aastas, siis ei suuda te poole aastaga saavutada uute versioonide väljalaskmist iga tunni tagant. Nii ei toimi. Seetõttu seadke reaalselt saavutatav eesmärk, mille täitmine on mõistlikus ajaraamis võimalik.

Relevant — asjakohane. Eemaldame ainult selle kitsenduse, mis tõeliselt järgib meie praeguseid eesmärke.

Time Limited — ajaliselt piiratud.. Kui tähtaega pole — meeskond tegeleb sellega, mida iganes: proovib 15 tehnoloogiat 3 asemel, kirjutab tohutuid aruandeid, viib läbi mõttetut uurimistööd, lihvib oma teostust läikivaks, kui eesmärk on juba saavutatud.

Eesmärgi seatakse just Value Stream Map'i abil — kogume taas kokku kõik inimesed ja joonistame. Kuid seekord joonistame juba põhinedes eelmisele Value Stream Map'ile, mida soovime saavutada.

Valime ühe kitsenduse, mida hakkame kohe kõrvaldama — sellega tegelebki meeskond. Näiteks tõin ootamise valmis versiooni ja selle tootmise vahele — see on kõige levinum kitsendus, millega inimesed pöörduvad nõustajate poole.

Seame ülesanne: tahame, et valmimise ja tööleasumise vaheline ooteaeg oleks maksimaalselt tund.

Näidist ülesannetest.

• Lühenda testimise juhtimisaega 4 päevast 1 tunnini.
• Lühenda lisandväärtuse aega testimise jaoks 2 päevast 3 tunnini.
• Lühenda deploy'i juhtimisaega 5 tunnist 10 minutini.
• Suurenda C/A 50%-lt 95%-le, st suurenda funktsioonide arvu, mida testijad aktsepteerivad, lühidalt, paranda arendajate töö kvaliteeti.

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

Seame sarnase ülesande meie meeskonnale ja tähtaegade piiri. Olenevalt sellest, kui hästi on teie ettevõttes kõik, seate erinevad tähtaegad. Keskmiselt kulub piirangute kõrvaldamiseks, kui inimesed tegelevad sellega esmakordselt ja ei tea veel, milliseid tehnoloogiaid ja kuidas konkreetseid probleeme lahendada, tavaliselt kuus kuud.

Lühike planeerimine

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

Näiteks kasutame sageli lähenemist moving-moving, kus kogu meeskond koguneb iga nädala alguses, et kirja panna, mida igaüks teeb. Nädala pärast vaatame, mis on tehtud ja mis mitte, ning kui ei ole, siis miks, ja mõtleme, mida edasi teha.

Sprintid võimaldavad kurssi õigeaegselt kohandada.

Nädala või kahe jooksul proovime midagi: tehnoloogiaid, lähenemisi, tööviise, seejärel mõõdame uuesti ja vaatame – kas sellise lähenemisega on parem või halvem? Kui halb, siis ei liigu me õigesse suunda, on vaja kurssi kohandada: seada uus ülesanne, võtta teine tehnoloogia või teha midagi muud. Lühikesed sprintid kestusega 1-2 nädalat võimaldavad manööverdada ja õigeaegselt halbadest lahendustest kõrvale hoida.

Jagame edusamme

Meeskond saavutab mingit edusamme, olgu need väikesed või suured – oluline on, et oleks mingi tulemus. Sellest tulemusest peaksid teadma kõik: nii need, kes on seotud DevOpsiga, kui ka naaberosakonnad. Idee maailmas oleks soovitav, et see jõuaks kõigi kogu ettevõtte inimesteni..

Miks? Kui tahame muuta mitte osa ettevõttest, eemaldada mitte ühe piirangu, vaid kõik, et ettevõte oleks paindlik, kood jõuaks kiiresti kliendini ja midagi ei rikuks, peavad kõik olema DevOpsi ideele truud. Te ei saa lähenemist rakendada teenustele ja meeskondadele, kes on kategooriliselt vastu.

Looduse tekkimiseks peame rääkima kõigile, et oleme proovinud seda — meil on tulemused, proovige teie ka! See suurendab huvi ja truudust selle vastu, millega me tegeleme, inimesed hakkavad kohe midagi tegema. Praktika näitab, et kui räägime, mida oleme proovinud ja mida saavutatud, siis teised meeskonnad hakkavad küsima, kuidas ja mida tegime. Nad vaatavad rakendusi, koodi, dokumentatsiooni, tulevad küsimustega ja püüavad midagi enda juures muuta.

Rääkida sellest, mis teil on õnnestunud — on oluline. Nii veenate konservatiive, kes soovisid teha kõike vanaviisi, liikuma teie leeri ja muundama nad uuendajateks.

Kokku

Valime teenuse, kui lähtepunkt — koht, kus alustada muudatusi ettevõttes. Tu vastame kõiki, kellel on mingit seotust teenusega ja koos nendega loome väärtuste voogukaardi, mõõdame ja vaatame, kus ja millised piirangud esinevad.

Loome uue ajutise meeskonna, mis lahendab antud ülesande. Mõõtmiste ja väärtuste voogukaardi põhjal joonistame uue kaardi, kus toome esile eelsoodumuse, mida kavatseme lahendada. Selle piirangu alusel seame ülesande, millega tegeleb meeskond. Ülesanne peab olema kindlasti SMART — konkreetne, mõõdetav, asjakohane praeguste ülesannete jaoks ja ajaliselt piiratud.

Korrame protsessi, kuni oleme ümber kujundanud kõik meie teenused soovitud kujul ja kõrvaldanud kõik piirangud.

Boonus. Kasulikud materjalid

Neile, kes otsustasid DevOpsiga iseseisvalt tegeleda.

Projekt „Fööniks”

Originaal pealkiri — „The Phoenix Project: A Novel about It, Devops, and Helping Your Business Win“. See on romaan DevOpsist — lugu sellest, kuidas töötaja nimetati osakonna juhiks, kes pidevalt oli tulekahjus. Uuele juhile anti ülesanne:

— Sul on paar aastat aega kõik korda seada, et saaksime lõpuks kiiresti ja tõhusalt toimetada meie toodet meie klientidele.

«Projekt „Phoenix“. Romaan sellest, kuidas DevOps muudab elu paremaks» — raamat kõigile juhtidele, sest just nemad teevad otsuseid selle kohta, mis ettevõttes toimub. Kui olete insener või programmeerija ja soovite, et teie ettevõttes algaks tegevus ja muutus — ostke raamat ja kingige juhtkonnale. See romaan seletab kõike, samas on seda lihtne ja kiiresti lugeda.

DevOpsi juhend

Natukene keerulisem raamat. Ilmus paar aastat tagasi inglise keeles pealkirjaga „The DevOps Handbook How to create world-class agility, reliability, and security in Technology organizations“, kuid nüüd on see juba venekeelsena saadaval. See on tõeline käekiri — praktiline juhend: kuidas teostada mõõtmisi, mis on Value Stream Map ja miks see vajalik on, kuhu liikuda, õiges järjekorras. Raamat on just neile, kes soovivad kõike ise teha. Kõige olulisem on, et selles on näiteid teiste ettevõtete kogemustest.

Näiteks räägitakse seal, kuidas üks ettevõte koostas Value Stream Map'i ja mõistis, et neil ei ole tootmispiirangut, vaid see, et kassapidaja peab käima poest naaberkontorisse, et toodet kasutada. Probleemi lahendamise asemel, mis oli seotud tarkvaraga, ostsid nad oma müüjatele tahvelarvutid, ja nüüd ei pea keegi kuhugi minema, kõik tegevused toimuvad töökohtadel. Järeldus: Value Stream Map'i võib rakendada mitte ainult tarkvarale, vaid ka kõigile organisatsiooni protsessidele.

Kiirendada

Täisnimetus: «Accelerate: Lean tarkvara ja DevOpsi teadus: Kõrge jõudlusega tehnoloogiaorganisatsioonide ehitamine ja skaleerimine». See on järgmine tase — hardcore. Raamat ilmus eelmisel aastal, hetkel ainult inglise keeles ja see räägib uuringutest. Autorid — Nicole Forsgren, Jez Humble ja Gene Kim — on aastaid rakendanud erinevaid praktikaid erinevates ettevõtetes ja uurinud, millised praktikud, kuidas ja millele mõjutasid.

Teises peatükis, mis käsitleb mõõtmisi, mainitakse Value Stream Map'i, neid mõõdikuid, mida ma nimetasime, ja paljusid teisi, samuti on üksikasjalikult kirjeldatud mõõtmise protsessi. Autorid teevad mõõtmisi küsitluste ja ülesannete iseseisva jälgimise abil. Räägitakse põhjalikult, milliseid mõõdikuid on õige mõõta, milliseid mitte, inimehitustest mõõtmistes. Kui teil on mõõtmistega raskusi, pöörduge teise peatüki poole raamatust „Accelerate“. Kui teie meeskonnas on lihtsalt palju praktikaid, kuid ei ole selge, milliseid praktikaid praegu rakendada, milliseid hiljem, millised toimivad tõeliselt ja millised mitte — lugege, raamatus on kõik selgelt välja toodud.

Transformatsioon on küsimus DevOpsi ja juhtimise ristmikul. Kusagil seal arendamise, operaatorite ja testimise vahel asuvad teemad, mida me püüame arutada DevOpsConf, sama integratsioon on vajalik ka kvaliteetse toote loomiseks – peamise teema QaulityConf. Juhtimine festivalil RIT++ esindatud Whale Rider — tähendab, et ideed transformatsiooniks on kõik seal. Liituge 27. ja 28. maiks, integreerume ja transformeerume.

Allikas: habr.com