{"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\/et\/blog\/administrirovanie\/kak-nachat-devops-transformatsiyu","title":{"rendered":"Kuidas alustada DevOpsi transformatsiooni","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Kui te ei m\u00f5ista, mis on DevOps, siis siin on l\u00fchike kokkuv\u00f5te. DevOps on praktikate kogum, mis v\u00e4hendab inseneride hirme<\/strong> ja v\u00e4hendab tarkvaraarenduse katkestuste arvu. Reeglina l\u00fchendab see turule toomise aega<\/strong> \u2014 perioodi ideest kuni l\u00f5pptoote klientideni viimiseni, mis v\u00f5imaldab kiiresti l\u00e4bi viia \u00e4rieksperimente<\/strong>.<\/p>\n

Kuidas alustada DevOps \u00fcmberkujundamist? L\u00fchidalt: valime teenuse, millega alustada, m\u00e4\u00e4rame \u00e4ra need, kes teenusega seotud, koostame v\u00e4\u00e4rtuste voogude kaardi, loome ajutise meeskonna, mis tegeleb alguses \u00fcmberkujundamisega, ja m\u00e4\u00e4rame talle \u00fclesande. Korratakse ts\u00fcklit vajalik arv kordi.<\/p>\n

\"Kuidas<\/p>\n

\u00dcksikasjalik DevOps \u00fcmberkujundamise plaan n\u00e4idiste ja juhistega on allpool \u2014 detailses kirjelduses aruandes<\/a><\/noindex> Andrei Aleksandrov<\/b> \u2014 insener firmas Express42, mis pakub n\u00f5ustamist DevOpsi kasvatamisel, kiirendades protsessi, kuna on juba koostanud kivide kaardi. Kui teile tundub, et \u00fcmberkujundamine ei ole vajalik, v\u00f5i teil on selline spetsiifika, et DevOps praktikad ei sobi, \u2014 kasutage aruannet juhisena piirangute leidmiseks ja k\u00f5rvaldamiseks.
\n<\/a><\/noindex>
\nKui teid h\u00e4irib DevOps \u00fcmberkujundamise k\u00fcsimus, siis teil on suur ettev\u00f5te ja peate seda protsessi j\u00e4rk-j\u00e4rgult laiendama kogu struktuurile. Kuni on vajadus meeskonda \u00fcmber kujundada v\u00f5i m\u00f5ni piirang k\u00f5rvaldada, saame alltoodud algoritmi kordata.<\/p>\n

Teenuse valik<\/h2>\n

\nPlaani oleme seadnud, alustatud esimese sammuga \u2014 teenuse valimisega. Esmane kriteerium \u2014 eluiga<\/strong>: on vanu teenuseid \u2014 legacy ning uusi. Alustada v\u00f5ib nii neist kui ka nendest.<\/p>\n

Noore teenuse valimine on loogiline<\/strong>. See on v\u00e4rske, sellega tegelevas meeskonnas ei ole veel v\u00e4ljakujunenud t\u00f6\u00f6protsesse. Selle \u00fcmber pole suurt tehnilist v\u00f5lga ja seda ei pea pidevalt parandama. Saame teha sellega, mida soovime.<\/p>\n

Vanade teenustega v\u00f5ivad ilmneda probleemid, mis on seotud sellega, et muutmine on alati keeruline<\/strong>. Seal on juba mingite t\u00f5siste piirangute kogum, kuid v\u00f5ib-olla tegelevad nendega inimesed, kes on valmis k\u00f5ike \u00fcmber tegema \u2014 nad on v\u00e4sinud ja soovivad midagi teha teisiti, kuna see neile muret teeb.<\/p>\n

T\u00f6\u00f6tamine vana teenusega loob teie ettev\u00f5ttes tugeva pretsedendi<\/strong> \u2014 midagi saab muuta. Kui olete uue teenuse muutnud, l\u00e4heb see tootmisse 100 korda tunnis ja k\u00f5ik on h\u00e4sti, siis v\u00f5ivad teie ettev\u00f5tte inimesed \u00f6elda:<\/p>\n

\u2014 See, this is a new service! It used to be simple; try doing something with our old wreck.<\/em><\/p>\n

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.<\/strong>. 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\u2019s easier to change the new one.<\/p>\n

If you\u2019re doing everything yourself, and the company lacks serious expertise\u2014go for the new service. If you know an external consultant and have the budget\u2014choose the old one.<\/p><\/blockquote>\n

\nThere 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\u2014you're going to have a hard time untangling it. Here, we also have a choice.<\/p>\n

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

But even in this case, I wouldn\u2019t 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\u2014isn\u2019t a very good idea. Therefore, in this case, we prefer to work with the interface, the breakdown of which isn\u2019t critical.<\/p>\n

Next, let's consider the service team<\/b>. We will have to work closely with those who are dealing with this service.<\/p>\n

The team members can be conditionally divided into two categories: conservatives<\/strong> \u2014 living in the old world, or simply know nothing about DevOps, and innovators<\/strong>, 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.<\/p>\n

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\u2019t know about the practices. On the other hand are the innovators, who have heard something, but most likely haven\u2019t been with the company for very long. Who should we work with?<\/p>\n

Konservatiividega tuleb igal juhul suhelda, kuna see on nende teenus. T\u00f5en\u00e4oliselt tuleb nendega vestelda, v\u00e4lja selgitada teenuse erip\u00e4ra, mida on v\u00f5imalik teha nii ja mida teisiti. Me s\u00f5ltume nende konsultatsioonidest. T\u00f5en\u00e4oliselt tuleb neile midagi usaldada, kuna nad tunnevad oma teenust paremini. Seet\u00f5ttu on oluline, millise meeskonnaga me l\u00f5puks kokku puutume.<\/p>\n

On loogiline valida meeskonda uuendajad, kuna konservatiivid v\u00f5ivad panna tagasil\u00f6\u00f6ke.\n<\/p><\/blockquote>\n

\nPraktiliselt juhtub tihti, et konservatiivsetel inimestel on oluline kogemus, kuid nad ei saa aru, kuidas edasi liikuda. Nad kardavad, et p\u00e4rast teenuse transformatsiooni ja \u00fcmberkujundamist v\u00f5idakse nad t\u00f6\u00f6lt vabastada. M\u00f5nikord, lihtsalt arusaamatuse t\u00f5ttu, mis toimub, saboteerivad nad t\u00f6\u00f6d.<\/p>\n

Mul oli puhul, kus meeskonna poiss parandas k\u00f5ike, mis iganes, kuna see oli v\u00e4idetavalt kriitilisem kui see, mida me praegu teeme. Me anname \u00fclesande: rakendada t\u00e4na see osa \u2014 ei, maailma teises otsas on tulekahju, l\u00e4heme seda parandama. Selliste inimestega on raske t\u00f6\u00f6tada.<\/p>\n

Konservatiivide meeskonnast tulevad inimesed tihti ignoreerivad \u00fclesandeid v\u00f5i l\u00fckkavad need viimasel minutil edasi. Ja kui, jumal hoidku, olete teinud vea ja riputanud neile KPI'd \u00fclesannete arvu kohta, kuid mingi osa ei ole mingil p\u00f5hjusel KPI'sse kaasatud, siis nad ei tee absoluutselt midagi. Tegelikult on nad \u00f5iged, kuna nad kaotavad siis oma boonuse.<\/p>\n

Uuendajatega on lihtsam \u2014 nad on lojaalsemad.<\/strong>Nad on juba midagi kuulnud, tahavad kuhugi minna, seet\u00f5ttu on nad abiks. Me vajame inimesi, kes on valmis algul kannatama: kui teenus muutub, siis k\u00f5ik probleemid ja takistused kogevad uuendajad esimestena. Uuendajad tahavad k\u00f5ike uut ja stiilset ning olles valmis kannatama.<\/p>\n

Konservatiive saab hiljem oma usku \u00fcmber p\u00f6\u00f6rata. Kui n\u00e4itate, et olete t\u00fcki muutnud ja k\u00f5ik t\u00f6\u00f6tab h\u00e4sti, siis t\u00f5en\u00e4oliselt soovivad nad ka proovida ja aktsepteerida uut DevOps'i religiooni.<\/p>\n

\"Kuidas
\n<\/p>\n

Kokkuv\u00f5tteks. Kui me teeme kogu transformatsiooni oma ettev\u00f5ttes ise, siis valime: uus teenus, eelistatavalt lihtne liides, et mitte liiga palju kannatada selle rikke p\u00e4rast, ja uuendajate meeskond.<\/p><\/blockquote>\n

\nKui on v\u00f5imalus kutsuda v\u00e4lisekspert, siis v\u00f5tame vana teenuse, mille p\u00e4rast me juba kannatame, asemel et uut. Inimesed, kes on transformatsiooniga teinud t\u00f6\u00f6d erinevates ettev\u00f5tetes, on n\u00e4inud erinevaid juhtumeid ja m\u00f5istavad juba, kuidas \u00f5igesti tegutseda ning kuhu \u00fcldse suunduda.<\/p>\n

Kes on seotud?<\/h2>\n

\nPeame leidma k\u00f5ik, kes on kuidagi seotud teenusega: arendajad, testijad, adminnid, turbeeksperdid, juhid ja v\u00f5imalik, et tootejuhid. Ehkki tootejuhid pole tehnilised spetsialistid, on nad teenusega seotud: nad teevad otsuseid ja seavad \u00fclesandeid.<\/p>\n

\"Kuidas
\n<\/p>\n

Peame leidma ja tutvuma k\u00f5igiga, kes teevad mis tahes otsuseid ja m\u00f5jutavad teenuse toimimist.<\/p><\/blockquote>\n

\nMiks nad meile vajalikud on? Kuna peame teadma, kellega l\u00e4bir\u00e4\u00e4kimisi pidada.<\/strong>. Transformatsiooni ajal, kui teenuse harjumusp\u00e4rane t\u00f6\u00f6meetod muutub, tuleb see kindlasti l\u00e4bi elada. M\u00f5nda aega esinevad t\u00f5rked, kuni katsetame uusi l\u00e4henemisviise. Inimesed peavad selleks olema valmis ja n\u00f5us.<\/p>\n

Edasi tuleb ehitada v\u00e4\u00e4rtuste vooge kaart ja ilma nende inimesteta ei saa seda teha, sest ainult nemad teavad koos t\u00e4ielikku toimuvat pilti. \u00dcks inimene ei tea kunagi k\u00f5ike, mis teenusega toimub.<\/p>\n

Nad soovitavad inimesi meeskonda. Hiljem arutame, miks vajame erilist meeskonda. Sellesse tuleb v\u00f5tta inimesi olemasolevatest osakondadest. Need, kes on teenusega seotud, saavad soovitada kolleege, kes m\u00f5tlevad meie suunas ja kes saavad meid aidata ning omavad vajalikke oskusi.<\/p>\n

Igal juhul kogume k\u00f5ik need inimesed erinevatest osakondadest \u00fchte ruumi ja hakkame ehitama v\u00e4\u00e4rtuste vooge kaarti.<\/p>\n

Ehita v\u00e4\u00e4rtuste vooge kaarti<\/h2>\n

\nV\u00e4\u00e4rtuste vooge kaart on skeem v\u00f5i kaart, mis n\u00e4itab v\u00e4\u00e4rtuste voolu kliendini.<\/strong>. See on kogu protsess ideest rakendamiseni, sealjuures k\u00f5ik vaheetapid ja see, kuidas v\u00e4\u00e4rtus l\u00f5puks meie klientideni j\u00f5uab.<\/p>\n

V\u00e4\u00e4rtuste vooge kaardi jaoks on vajalik, et visualiseerida k\u00f5ik arendusastmed,<\/strong>lokaliseerida probleemid praeguses protsessis m\u00f5\u00f5tmete kaudu ja alustada probleemide lahendamist ning seada esialgne eesm\u00e4rk<\/strong>. See on koht, kus hakkame t\u00f5eliselt midagi tegema.<\/p>\n

M\u00f5\u00f5tmised<\/h3>\n

\nV\u00e4\u00e4rtuste vooge kaartide kirjanduses on kirjeldatud palju erinevaid m\u00f5\u00f5dikuid, kuid alguseks piisab meile kolmest.<\/p>\n

T\u00e4itmise aeg \u2014 viivitus\/ootamine<\/strong> \u2014 aeg, mil me midagi ootame. N\u00e4iteks ootab testija, kuni testimiseks on saadaval seade, ja sel ajal ei saa ta midagi teha.<\/p>\n

Value Added Time \u2014 v\u00e4\u00e4rtuslik t\u00f6\u00f6aeg<\/strong> \u2014 see, mida kulutasime mingil etapil, et luua l\u00f5plik v\u00e4\u00e4rtus kasutajale. N\u00e4iteks k\u00e4ivitas testija oma testi ja hakkas midagi kontrollima. See on v\u00e4\u00e4rtuslik t\u00f6\u00f6aeg, mil me t\u00f5eliselt teeme midagi toote heaks. Just selle eest kliendid maksavad \u2014 kvaliteetse tarkvara eest.<\/p>\n

%C\/A \u2014 vastuv\u00f5etud t\u00f6\u00f6 protsent. <\/strong>Meil on \u00fcks etapp \u2014 arendus, teine etapp \u2014 testimine. Kui palju funktsioone testijad on arendajatelt vastu v\u00f5tnud, ja selle protsendi m\u00e4\u00e4rabki see.<\/p>\n

Umbes nii n\u00e4eb meie kaart v\u00e4lja.<\/p>\n

\"Kuidas
\n
\nSee v\u00f5ib v\u00e4lja n\u00e4ha erinev s\u00f5ltuvalt organisatsiooni struktuurist, osakondade arvust ja sellest, millega tegelete. Kuid \u00fcldiselt on kaardil kaks etappi: idee <\/strong>ja anal\u00fc\u00fcs<\/strong>. Sellel etapil oodatakse andmeid, n\u00e4iteks Lead Time 2 n\u00e4dalat ja Value Added Time 2 p\u00e4eva.<\/p>\n

Kasutame m\u00f5\u00f5dikuid k\u00f5igil etappidel.<\/p><\/blockquote>\n

\nBacklog<\/strong> \u2014 kui palju \u00fclesandeid j\u00e4i p\u00e4rast seda, kui anal\u00fc\u00fctikud need v\u00e4lja m\u00f5tlesid.<\/p>\n

Arendus<\/strong> \u2014 kui palju n\u00e4dalaid arendajad ootasid selgitusi \u00fclesannete, seadmete v\u00f5i varustuse osas \u2014 see ei oma t\u00e4htsust, aga nad ootavad midagi. N\u00e4iteks, nad rakendavad funktsiooni 4 p\u00e4eva. Siin tuleb m\u00e4ngu m\u00f5\u00f5dik %C\/A. Arendajad v\u00f5tsid Backlogist ainult 80% \u00fclesandeid. Nad arvavad, et \u00fclej\u00e4\u00e4nud 20% pole piisavalt selgeid, ja saatsid need t\u00e4iendavale t\u00f6\u00f6tlemisele.<\/p>\n

Testimine<\/strong>. Skeemil on LT m\u00e4\u00e4ratud 4 p\u00e4eva. N\u00e4iteks ootasid testijad testimise seadme vabastamist, VA 2 p\u00e4eva nad tegelikult testivad midagi, ja %C\/A = 40%. \u2014 ainult 40% koodist v\u00f5i funktsioonidest, mille arendajad saatsid, arvasid testijad olevat sobivad. K\u00f5ik \u00fclej\u00e4\u00e4nud ei meeldinud neile mingil p\u00f5hjusel.<\/p>\n

Ma ei hakka \u00fcksikasjalikult r\u00e4\u00e4kima, kuidas neid m\u00f5\u00f5tmisi teostada, artikli l\u00f5pus soovitan kirjandust, millest selle kohta rohkem teada saada.<\/p>\n

Ainus asi, mida soovitan \u2014 \u00e4rge uskuge inimesi, kes koostavad koos teiega Value Stream Kaardi. Nad kujutavad ette, kui kaua erinevad protsessid aega v\u00f5tavad, kuid need hinnangud ei ole alati \u00f5iged, seega on parem neid ise m\u00f5\u00f5ta.<\/p>\n

Meil oli juhtum, kui me l\u00e4ksime Operations osakonda ja k\u00fcsisime, kui kaua kulub uue funktsiooni tootmisse toimetamiseks. Vastus oli 10 minutit, ja me m\u00f5tlesime, miks me \u00fcldse sellesse ettev\u00f5ttesse tulime? Selgus, et 10 minutit on skripti t\u00f6\u00f6aeg, mis v\u00f5tab koodi ja toimetab serverisse. Kuid enne seda oli versioon kolme p\u00e4eva jooksul serveris ja lihtsalt tolmu kogumas \u2014 Backlogis ootas \u00fclesanne, mis tuleb v\u00e4lja viia. Seega on enne juurutamisetappi ooteetapp, kus projekt lihtsalt seisab. Kui me poleks l\u00e4inud oma m\u00e4rkmete ja silmadega \u00fclesandeid Jira-s j\u00e4lgima, siis oleksime arvanud, et k\u00f5ik on suurep\u00e4rane ja mingit probleemi ei ole.<\/p>\n

Seet\u00f5ttu on m\u00f5\u00f5tmised ikkagi kellegi enda poolt tehtud, eelistatult mitte ainult \u00fcks kord, et saada v\u00f5imalikult l\u00e4hedane arusaam reaalsusest. S\u00f5ltuvalt Value Stream Map-ist teete otsuse, kust kohast alustada ja mida k\u00f5igepealt parandada.<\/p>\n

Ajutine meeskond<\/h2>\n

\nPaljud ettev\u00f5tted, kes otsustasid DevOpsi rakendada, loovad meeskonna, mis ei ole ajutine, vaid eksisteerib mitu aastat. Kui k\u00fcsite DevOps apologizelt, kus on kirjeldatud erinevaid organisatsioonistruktuuri mustreid DevOps-is, m\u00f5istate, et see on antipattern.<\/p>\n

Kui DevOps-meeskond eksisteerib pidevalt mitu aastat, on see suur viga, kuna DevOps t\u00e4hendab osakondade vahelist suhtlust, kiirus ja efektiivsus.<\/p><\/blockquote>\n

\nKui meeskond eksisteerib osakondade vahel, et teha midagi muud eraldi ning p\u00fcsib kaua, loob see lisabarj\u00e4\u00e4ri. N\u00fc\u00fcd peab arendaja administreerijaga k\u00fcsimuse lahendamiseks minema esmalt DevOps osakonda, ja alles siis minema edasi.<\/p>\n

Seet\u00f5ttu peab alustamiseks looma ajutise meeskonna.<\/strong>. Ta eksisteerib tinglikult pool aastat, maksimaalselt aasta, s\u00f5ltuvalt seatud \u00fclesandest, ainult selleks, et k\u00f5rvaldada \u00fcks piirang, mille oleme valinud. P\u00e4rast seda sureb ta. Kui me valime j\u00e4rgmise punkti, kus meil on tugev valu, ja m\u00f5istame, et selle jaoks on meil samuti vaja eraldi meeskonda, siis loome selle uuesti. Kuid \u201ep\u00fcsivalt\u201d ei tohiks sellised meeskonnad eksisteerida - siis nad lihtsalt rikuvad kommunikatsiooni ja v\u00f5tavad endale t\u00e4iesti eraldiseisvaid \u00fclesandeid, ainult midagi tehes. Need \u00fclesanded ei pruugi olla seotud DevOps'i ja transformatsiooniga. Miks mitte anda see \u00fclesanne olemasolevatele osakondadele?<\/p>\n

Miks on vajalik ajutine meeskond<\/h3>\n

\nKonflikt praeguste protsessidega<\/strong>. DevOps'i transformatsioon on muutus mitte ainult tehnoloogias ja t\u00f6\u00f6riistades, mida kasutame, vaid ka t\u00f6\u00f6protsessides, m\u00f5tlemises ja v\u00e4\u00e4rtustes. Kui meeskond t\u00f6\u00f6tab endiselt nii, nagu nad on harjunud, ei \u00f5nnestu neil proovida muid l\u00e4henemisviise.<\/p>\n

Need inimesed peavad elama teiste reeglite j\u00e4rgi: ignoreerima ettev\u00f5tte k\u00f5iki KPI-sid, sest nad proovivad t\u00f6\u00f6tada teisiti. Ajutised meeskonnad ei t\u00e4ida ankeete serveri saamiseks, vaid l\u00e4hevad otse osakonda, mis neid haldab, n\u00f5udma k\u00f5igepealt vajadusi, sest see on prioriteetne \u00fclesanne ja nad p\u00fc\u00fcavad elada teisiti. Meeskonnal on t\u00e4ielik konflikt k\u00f5igi olemasolevate protsessidega. Et olemasolevad t\u00f6\u00f6meetodid neid hetkel ei segaks ja nad ei segaks teisi, isoleerime need inimesed, luues eraldi meeskonna.<\/p>\n

B\u00fcrokraatia v\u00e4ltimine katsetustes<\/strong>. Ajutistes meeskondades ei ole b\u00fcrokraatiat, nad ei t\u00e4ida t\u00f6\u00f6tundide aruandeid, nad ei pea aru andma juhtidele. See on t\u00e4iesti eraldi maailm, kus inimesed elavad ja m\u00f5tlevad teisiti ning tegelevad t\u00e4iesti erinevate asjadega. Neid ei tohi liialt segada.<\/p>\n

Katkematu t\u00f6\u00f6 teenuse nimel<\/strong>. Esimeses punktis valisime midagi, millega katsetada. Katsetamine ja paremate t\u00f6\u00f6viiside otsimine on hea, kuid me tahame ka funktsioone teha. Kui kogu meeskond tegeleb funktsioonide asemel transformatsiooniga, hakkame kaotama tulu, vead j\u00e4\u00e4vad kauaks alles - seda me ei vaja. Ajutise meeskonna loomine v\u00f5imaldab katsetada, katkestamata samal ajal toote arendamist.<\/p>\n

\u00c4ra kuluta aega t\u00f6\u00f6\u00fclesannetele<\/strong>. See on j\u00e4lle toote kohta. Meeskonnal kulub palju aega, et katsetada muid t\u00f6\u00f6riistu ja muud. Et inimesed m\u00f5istaksid t\u00f6\u00f6riistu, hakkaksid neid rakendama ja normaalselt kasutama, kulub v\u00e4hemalt pool aastat. Kui nad tegelevad veel ka tootega, siis venib see pool aastat kosmiliselt. Kui inimesed tegelevad tootega, t\u00f6\u00f6tavad nad j\u00e4lle vanade protsessidega \u2014 seda me ei vaja.<\/p>\n

Seet\u00f5ttu eraldame erinevatest osakondadest inimesi eraldi meeskonda, mis tegeleb teenuse transformatsiooniga. Tulemusena t\u00f6\u00f6tab teenus, j\u00e4tkab arendamist ja samal ajal katsetame selle peal mingisuguseid eksperimente.<\/p>\n

Ajutine meeskond tegeleb ainult DevOps-transformatsiooniga \u2014 eemaldades leitud piirangu ja mitte millegagi muuga.<\/p><\/blockquote>\n

\nMeeskond koosneb universaalsetest inimestest<\/strong>. See t\u00e4hendab, et oleme v\u00f5tnud mitte ainult arendajad. Me ei tulnud teenusesse ja ei v\u00f5tnud sealt pool meeskonda \u2014 ei, me v\u00f5tsime inimesi erinevatest osakondadest<\/strong>. M\u00f5ni punkt tagasi leidsime erinevad osakonnad ja erinevad t\u00f6\u00f6tajad, kes on seotud muudetava teenusega. Nendest koostame meeskonna, sest see peab olema universaalne \u2014 me muudame nii testimisprotsessi, arendusprotsessi kui ka teenuse hooldamise protsessi. Vajame erinevaid kompetentse.<\/p>\n

Tavaliselt v\u00f5tame arendaja, testija ja inseneri \u2014 iga\u00fche \u00fche ja koos nendega leiutame lahenduse, mis v\u00f5imaldab elada teisiti.<\/p>\n

Soovitav on, et need inimesed oleksid organisatsioonis autoriteetsed<\/strong>. V\u00f5ib-olla tuleb v\u00f5tta \u00fcks konservatiiv, kuigi pole soov. Kui meie ettev\u00f5te on suur, ei usu kaugeltki k\u00f5ik meie plaani ja m\u00f5ned v\u00f5ivad seada takistusi, n\u00e4iteks mitte eraldada seista. Siin tulebki m\u00e4ngu \"autoriteet\" \u2014 austatud inimene, kellel on suur kogemus ja kes on teeninud kolleegidelt head suhtumist. T\u00f6\u00f6taja autoriteet meeskonnas lihtsustab \u00fclesannet ja ajutise meeskonna t\u00f6\u00f6d. Inimesed m\u00f5tlevad:<\/p>\n

\u2014 Ahjaa, see \u00e4ge t\u00fc\u00fcp, keda me k\u00f5ik tunneme ja armastame, on sinna sisse astunud \u2014 n\u00e4ib, et DevOps-is on midagi, millele tasub t\u00e4helepanu p\u00f6\u00f6rata!<\/em><\/p>\n

Seame eesm\u00e4rgi<\/h2>\n

\nKogusime inimesi, valisime teenuse, vaatlesime piiranguid, m\u00e4\u00e4rasime, kellele me m\u00f5ju avaldame. N\u00fc\u00fcd peab olema eesm\u00e4rk ja see peab olema t\u00e4iesti SMART<\/strong> \u2014 k\u00f5ik, nagu me armastame.<\/p>\n

Spetsiifiline \u2014 konkreetne<\/strong>.<\/p>\n

M\u00f5\u00f5detav \u2014 m\u00f5\u00f5detav<\/strong>. See on v\u00e4ga oluline SMART punkt. Kui te ei saa midagi m\u00f5\u00f5ta, siis ei saa te seda muuta ega m\u00f5ista, mida ja kuidas olete teinud paremini v\u00f5i halvemini.<\/p>\n

Saadav \u2014 saavutatav<\/strong>. Arvesse tuleb v\u00f5tta oma erip\u00e4ra. Kui olete suur ettev\u00f5te, millel on pikk ajalugu ja palju kohustusi, mis v\u00e4ljastab uue toote versiooni kord aastas, siis ei saa te kuue kuu jooksul saavutada uute tooteversioonide v\u00e4ljalaskmist iga tunni tagant. Nii ei \u00f5nnestu. Seega seadke realistlik eesm\u00e4rk, mis on saavutav m\u00f5istlikus ajaraamis.<\/p>\n

Asjakohane \u2014 relevant. <\/strong>K\u00e4itleme ainult seda piirangut, mis t\u00f5eliselt m\u00f5jutab meie praeguseid eesm\u00e4rke.<\/p>\n

Aja piirang \u2014 ajaliselt piiratud<\/strong>. Kui t\u00e4htaega pole, siis meeskond tegeleb millegagi: katsetab 15 tehnoloogiat 3 asemel, kirjutab tohutuid aruandeid, viib l\u00e4bi kasutuid uuringuid, lihvib oma teostust hiilgavaks, kui eesm\u00e4rk on juba saavutatud.<\/p>\n

Eesm\u00e4rgid seame just Value Stream Map'i abil \u2014 taas kogume k\u00f5ik inimesed kokku ja joonistame. Kuid seekord joonistame selle p\u00f5hjal, mida soovime saada, eelneva Value Stream Map'i alusel.<\/p>\n

\"Kuidas
\n
\nKipume v\u00e4lja tooma \u00fche piirangu, mida hakkame kohe k\u00f5rvaldamiseks t\u00f6\u00f6le, millega meeskond tegeleb. N\u00e4iteks v\u00f5tsin ooteaja valmimise ja selle juurutamise vahe enne tootmisse j\u00f5udmist \u2014 see on k\u00f5ige sagedasem piirang, mille t\u00f5ttu inimesed p\u00f6\u00f6rduvad konsultantide poole.<\/p>\n

Selle p\u00f5hjal seame \u00fclesande: soovime, et ooteaeg valmimise ja lahingusse mineku vahel oleks maksimaalselt \u00fcks tund.<\/p>\n

N\u00e4idised \u00fclesannetest.<\/p>\n