{"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 \u00fclevaade. DevOps on praktiseerimise kogum, mis v\u00e4hendab inseneride hirme<\/strong> ja v\u00e4hendab tarkvaratootmise katkestusi. Tavaliselt v\u00e4hendavad nad ka turulej\u00f5udmise aega<\/strong> \u2014 ajavahemikku ideest kuni l\u00f5ppprodukti kohaletoimetamiseni klientidele, mis v\u00f5imaldab kiiresti l\u00e4bi viia \u00e4ri eksperimente<\/strong>.<\/p>\n

Kuidas alustada DevOpsi transformatsiooni? L\u00fchidalt: valime teenuse, millega protsessi alustada, tuvastame teenusega seotud inimesed, loome v\u00e4\u00e4rtusvoo kaardi, kujundame ajutise meeskonna, mis tegeleb transformatsiooniga esialgu ja m\u00e4\u00e4rame talle \u00fclesande. Korrame ts\u00fcklit vajalik arv kordi.<\/p>\n

\"Kuidas<\/p>\n

\u00dcksikasjalik DevOps-i transformatsiooni plaan koos n\u00e4idiste ja juhistega on allpool \u2014 inseneri raport Express42 ettev\u00f5ttest, mis annab n\u00f5u DevOpi kasvatamise kohta, kiirendades seda protsessi, sest on juba koostanud takistuste kaardi. Kui teile tundub, et transformatsioon pole vajalik v\u00f5i teil on spetsiifika, et DevOps praktikad ei sobi, \u2014 kasutage aruannet juhisena piirangute leidmiseks ja k\u00f5rvaldamiseks. ettekandest<\/a><\/noindex> Andrei Aleksandrov<\/b> \u2014 insener Express42's, kes konsultatsioonidega DevOpsi kasvatamiseks, kiirendades seda protsessi, sest on juba loonud m\u00fcraskaarte. Kui teil tundub, et transformatsioon ei ole vajalik, v\u00f5i kui teil on spetsiifilisus, mis ei sobi DevOps-praktikatega, \u2014 kasutage ettekannet juhendina piirangute leidmiseks ja eemaldamiseks.
\n<\/a><\/noindex>
\nKui DevOps-i transformatsiooni k\u00fcsimus teid vaevab, siis t\u00e4hendab see, et teil on suur ettev\u00f5te ja peate seda protsessi j\u00e4rk-j\u00e4rgult skaleerima kogu struktuuri ulatuses. Kuni on vajadus meeskonda transformeerida v\u00f5i m\u00f5ni piirang k\u00f5rvaldada, saab allolevat algoritmi korrata.<\/p>\n

Teenuse valik<\/h2>\n

\nPlaani oleme loonud, alustame esimesest sammust \u2014 teenuse valimisest. Esimene kriteerium \u2014 eluea pikkus<\/strong>: on vanu teenuseid \u2014 legacy, ja uusi. Alustada saab nii vanadest kui uutest.<\/p>\n

Noore teenuse valimine on m\u00f5istlik<\/strong>. See on v\u00e4rske, seal ei ole veel v\u00e4ljakujunenud t\u00f6\u00f6s\u00fcsteemi meeskonnas, mis sellega tegeleb. Selle \u00fcmber ei ole tohutut tehnilist v\u00f5lga, ei pea seda pidevalt parandama. Saame sellega teha k\u00f5ike, mida soovime.<\/p>\n

Vanade teenustega kaasnevad probleemid, mis on seotud sellega, et muutmine on alati keeruline<\/strong>. Seal on juba teatud t\u00f5siste piirangute kogum, kuid v\u00f5ib-olla tegelevad sellega inimesed, kes on valmis k\u00f5ik \u00fcle vaatama \u2014 nad on v\u00e4sinud ja soovivad midagi teisiti teha, sest neil on valus.<\/p>\n

T\u00f6\u00f6 vanade teenustega loob tugeva pretsedendi<\/strong> teie ettev\u00f5ttes \u2014 on v\u00f5imalik midagi muuta. Kui olete lisanud uue teenuse, mis t\u00f6\u00f6tab tootmises 100 korda tunnis ja k\u00f5ik on korras, siis teie ettev\u00f5tte inimesed v\u00f5ivad \u00f6elda:<\/p>\n

\u2014 See on ju uus teenus! Seal oli ju k\u00f5ik lihtne, proovige meie vanakese jaoks midagi \u00e4ra teha.<\/em><\/p>\n

Legacy-teenust on m\u00f5ttekas kaasata transformatsiooni, kui teete seda kellegagi koos, n\u00e4iteks kui olete kutsunud v\u00e4list konsultandi. Olgem ausad, transformatsioon hakkab k\u00f5ik, mis v\u00f5imalik, raputama.<\/strong>. Te eksperimenteerite ja ei tea, kuhu j\u00f5uate, milliseid tehnoloogiaid ja miks kavatsete kasutada, kus ja milliseid takistusi protsessis v\u00f5ib tekkida. Seet\u00f5ttu on uue vahetamine lihtsam.<\/p>\n

Kui teete k\u00f5ik ise ja ettev\u00f5ttes pole t\u00f5sist kompetentsi \u2014 valime uue teenuse. Kui tead v\u00e4liskonsultanti ja ressursse on \u2014 valige vana.<\/p><\/blockquote>\n

\nOn teenuseid, mis on lihtsalt kasutajaliides, nagu lihtne veebileht v\u00f5i mobiilirakendus. Kuid on ka t\u00f5siseid asju, nagu arveldamine. Kui midagi peaks arveldamisega valesti minema \u2014 on keeruline probleeme lahendada. Siin on meil ka valik.<\/p>\n

Me t\u00f6\u00f6tame kas kriitilise teenusega<\/strong>, kuid me juba kannatame selle t\u00f5ttu, see loob piiranguid, kas t\u00f6\u00f6tame liidese<\/strong>. See on valiku teine kriteerium. Samamoodi on v\u00f5imalus kaasata kogenud konsultant \u2014 t\u00f6\u00f6tame keerulise variandiga.<\/p>\n

Kuid isegi sel juhul ei soovitaks ma nii teha, sest seni, kuni pole selgust, millega t\u00f6\u00f6tada ja millises suunas transformeerida, on kriitiline asi haaramine ja selle \u00fcmbertegemine \u2014 ei ole just hea idee. Seega eelistame sel juhul t\u00f6\u00f6tada liidesega, mille rike ei ole kriitiline.<\/p>\n

Edasi vaatame teenuste meeskonda<\/b>. Nendega, kes selle teenusega tegelevad, peame pidevalt t\u00f6\u00f6tama ja v\u00e4ga tihedas kontaktis olema.<\/p>\n

Meeskonna liikmed jagunevad tinglikult kahte kategooriasse: konservatiivid<\/strong> \u2014 elavad vanas maailmas v\u00f5i ei tea lihtsalt DevOps-ist midagi, ja uuendajad<\/strong>, kes toovad k\u00f5ik moes olevad praktikad. Teised ei pruugi alati teemas orienteeruda, kuid nad on v\u00e4hemalt valmis sellega tegelema.<\/p>\n

\u00dchelt poolt on konservatiivid kogenud inimesed: nad on ettev\u00f5ttes juba pikka aega, tunnevad k\u00f5ike p\u00f5hjalikult, kuid ei tea, kuidas praktikat ellu viia. Teiselt poolt on innovaatikud, kes on midagi kuulnud, kuid t\u00f5en\u00e4oliselt ei ole nad ettev\u00f5ttes kaua t\u00f6\u00f6tanud. Kellega neist on parem koost\u00f6\u00f6d teha?<\/p>\n

Konservatiividega tuleb igal juhul suhelda, kuna see on nende teenus. Peame nendega suhtlema, et v\u00e4lja selgitada teenuse spetsiifika, mida saab teha ja mida ei saa. Me s\u00f5ltume nende n\u00f5uannetest. Kindlasti tuleb neile midagi usaldada, kuna nad tunnevad oma teenust paremini. Seet\u00f5ttu on oluline, kellega me l\u00f5puks kontaktis oleme.<\/p>\n

Loogiline on valida meeskonda innovaatikud, kuna konservatiivid v\u00f5ivad kaasa tuua probleeme.\n<\/p><\/blockquote>\n

\nPraktikas juhtub sageli, et konservatiivsetel inimestel on m\u00e4rkimisv\u00e4\u00e4rne kogemus, kuid nad ei m\u00f5ista, kuidas edasi liikuda. Nad kardavad lihtsalt, et p\u00e4rast teenuse \u00fcmberkujundamist ja muutmist vabastatakse nad t\u00f6\u00f6lt. M\u00f5nikord sabotaa\u017eivad nad oma t\u00f6\u00f6d lihtsalt arusaamatuse t\u00f5ttu selle suhtes, mis toimub.<\/p>\n

Mul oli juhtum, kui \u00fcks meeskonnaliige parandas k\u00f5ike, mida iganes, sest see oli v\u00e4idetavalt kriitilisem kui see, millega me parajasti tegeleme. Me anname \u00fclesande: t\u00e4ita t\u00e4na see osa \u2014 ei, teisel pool maailma on tuli, l\u00e4heme seda kohe parandama. Selliste inimestega on raske t\u00f6\u00f6tada.<\/p>\n

Konservatiivide meeskonna liikmed sageli ignoreerivad \u00fclesandeid v\u00f5i l\u00fckkavad neid viimasele minutile. Ja kui, jumal hoidku, teete vea ning m\u00e4\u00e4rate neile KPI, mis p\u00f5hineb t\u00e4idetud \u00fclesannete arvul, kuid mingi osa on mingil p\u00f5hjusel KPI-st v\u00e4lja j\u00e4etud, siis nad ei tee absoluutselt midagi. Tegelikult on nad \u00f5iged, kuna kaotavad seel\u00e4bi preemia.<\/p>\n

Uuendajatega on lihtsam \u2014 nad on lahkemad.<\/strong>Nad on juba midagi kuulnud, tahavad kuhugi j\u00f5uda, seet\u00f5ttu aitavad nad hea meelega. Me vajame inimesi, kes on valmis esialgu kannatama: kui teenus muutub, siis koguvad k\u00f5ik probleemid ja takistused esimesed innovaatorid -- kui esimesed. Innovaatoreid t\u00f5mbab k\u00f5ik uus ja moekas ning nad on valmis kannatama.<\/p>\n

Konservatiive on hiljem v\u00f5imalik meelt muuta. Kui n\u00e4itate, et olete v\u00e4ikese muudatuse teinud ning k\u00f5ik t\u00f6\u00f6tab, tahavad nad t\u00f5en\u00e4oliselt ka proovida ning omaks v\u00f5tta uut DevOps usku.<\/p>\n

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

Kokkuv\u00f5tteks. Kui me teeme kogu muudatuse ise oma firmas, valime: uue teenuse, eelistatavalt lihtsa liidese, et mitte liiga palju kannatada selle rikkumise t\u00f5ttu, ja innovaatilise meeskonna.<\/p><\/blockquote>\n

\nKui on v\u00f5imalus kutsuda v\u00e4lisekspert, v\u00f5tame uue asemel vanema teenuse, millega juba kannatame. Inimesed, kes on tegelema transformatsiooniga piisavalt kaua erinevates ettev\u00f5tetes, on n\u00e4inud erinevaid juhtumeid ja saavad aru, kuidas \u00f5igesti edasi minna ning milliseks suunaks liikuda.<\/p>\n

Kes on seotud?<\/h2>\n

\nPeame leidma k\u00f5ik, kes on teenusega mingil moel seotud: arendajad, testijad, administraatorid, turvalisusspetsialistid, juhid ja v\u00f5imalusel ka tooteomanikud. Kuigi tooteomanikud ei ole tehnilised inimesed, on nad teenusega seotud: nad teevad otsuseid ja m\u00e4\u00e4ravad \u00fclesandeid.<\/p>\n

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

K\u00f5ik, kes teevad mingisuguseid otsuseid ja m\u00f5jutavad teenusega toimuvaid asju, tuleb leida, nendega tutvuda ja suhelda.<\/p><\/blockquote>\n

\nMiks nad on meile vajalikud? Kuna on oluline teada, kellega l\u00e4bir\u00e4\u00e4kimisi pidada.<\/strong>. Teenuste kasutamise harjumus muutub ja selle k\u00e4igus v\u00f5ib esineda t\u00f5rkeid. Uute l\u00e4henemiste katsetamise ajal on t\u00f5en\u00e4oline, et v\u00f5ib esineda katkestusi. Inimesed peavad selleks valmis olema ja sellega n\u00f5us olema.<\/p>\n

Edasi tuleb koostada Value Stream Map ja ilma nende inimesteta ei saa seda koostada, kuna ainult nemad teavad \u00fchiselt t\u00e4ielikku pilti toimuvast. \u00dcks inimene ei tea kunagi k\u00f5ike, mis teenusega seotud on.<\/p>\n

Nad soovitavad inimesi meeskonda. Hiljem arutame, miks on vajalik eraldi meeskond. Sellesse tuleb v\u00e4rvata inimesi olemasolevatest osakondadest. Need, kellel on teenusega seos, saavad soovitada kolleege, kes m\u00f5tlevad meie suunas ja kes saavad meid aidata ning kellel on vajalikud oskused.<\/p>\n

Seej\u00e4rel kogume k\u00f5ik need inimesed erinevatest osakondadest \u00fchte ruumi ja hakkame koostama Value Stream Map'i.<\/p>\n

Koostame Value Stream Map'i<\/h2>\n

\nValue Stream Map on skeem v\u00f5i kaart, mis n\u00e4itab v\u00e4\u00e4rtuste voogu kliendini.<\/strong>See on kogu protsess alates idee v\u00e4lja m\u00f5tlemisest kuni selle elluviimiseni, sealhulgas k\u00f5ik vaheetapid ja see, kuidas v\u00e4\u00e4rtus l\u00f5puks meie klientideni j\u00f5uab.<\/p>\n

Value Stream Map on vajalik, et visualiseer k\u00f5ik arenduse etapid<\/strong>, lokaliseerida probleeme olemasoleva protsessi m\u00f5\u00f5tmiste kaudu ja alustada nende probleemide lahendamist ning seada esialgne eesm\u00e4rk<\/strong>. See on koht, kus hakkame midagi t\u00f5eliselt tegema.<\/p>\n

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

\nValue Stream Map'i kirjanduses on palju erinevaid m\u00f5\u00f5dikuid, kuid alguseks piisab meile kolmest.<\/p>\n

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

Value Added Time \u2014 v\u00e4\u00e4rtuslik t\u00f6\u00f6aeg<\/strong> \u2014 see, mille me kulutasime m\u00f5nes etapis, et luua l\u00f5ppkasutajale v\u00e4\u00e4rtus. N\u00e4iteks testija k\u00e4ivitas 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 maksavad kliendid \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 arendajatelt vastu v\u00f5tsid, ja see protsent on olemas.<\/p>\n

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

\"Kuidas
\n
\nSee v\u00f5ib s\u00f5ltuda organisatsiooni struktuurist, osakondade arvust ja teie tegevusalast. \u00dcldiselt 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

M\u00f5\u00f5dikud katab absoluutselt k\u00f5ik etapid.<\/p><\/blockquote>\n

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

Arendus<\/strong> \u2014 kui palju n\u00e4dalaid arendajad ootavad \u00fclesannete, stendide v\u00f5i varustuse selgitusi \u2014 ei ole oluline, kuid nad ootavad midagi. N\u00e4iteks, nad teevad funktsiooni 4 p\u00e4eva. Siin tekib m\u00f5\u00f5dik %C\/A. Arendajad v\u00f5tsid Backlog'ist ainult 80% \u00fclesandeid. Nad arvavad, et 20% j\u00e4\u00e4b ebamugavalt udususeks, ja saatsid need edasi \u00fcmbertegemiseks.<\/p>\n

Testimine<\/strong>. Kujutisel on LT m\u00e4\u00e4ratud 4 p\u00e4eva. N\u00e4iteks ootavad testijad teststendi vabastamist, VA 2 p\u00e4eva nad testivad tegelikult midagi, ja %C\/A = 40 %. \u2014 vaid 40 % koodist v\u00f5i funktsioonidest, mida arendajad saatsid, pidasid testijad piisavaks. K\u00f5ik muu ei meeldinud neile m\u00f5nel p\u00f5hjusel.<\/p>\n

Ma ei hakka \u00fcksikasjalikult r\u00e4\u00e4kima, kuidas neid m\u00f5\u00f5tmisi teha, kuid artikli l\u00f5pus soovitan kirjandust, kust saate rohkem teada.<\/p>\n

Ainult seda soovitan \u2014 \u00e4rge uskuge inimesi, kes koostavad teiega v\u00e4\u00e4rtusvoo kaardi. Nad n\u00e4itavad, kui palju aega eri protsessid v\u00f5tavad, kuid need hinnangud ei ole alati t\u00f5esed, seega on parem ise m\u00f5\u00f5ta.<\/p>\n

Meil oli juhtum, kui l\u00e4ksime operatsioonide osakonda ja k\u00fcsisime, kui kaua kulub uue funktsiooni tarnimiseks tootmisse. Vastus oli, et 10 minutit, ja m\u00f5tlesime, miks me \u00fcldse sellesse ettev\u00f5ttesse tulime? Selgus, et 10 minutit on skripti t\u00f6\u00f6aeg, mis v\u00f5tab koodi ja toob selle serverisse. Kuid enne seda on versioon olnud kolm p\u00e4eva serveris ja lihtsalt tolmub \u2014 Backlogis on \u00fclesanne, mis tuleb juurutada. T\u00e4hendab, et juurutamise eel on ootamisetapp, kus projekt lihtsalt seisab. Kui me poleks l\u00e4inud m\u00e4rkmeraamatuga, ei oleks me n\u00e4inud \u00fclesannet Jira-s ja ei oleks seda etappidena j\u00e4lginud, siis arvaksime, et k\u00f5ik on suurep\u00e4rane ja probleeme pole.<\/p>\n

Seet\u00f5ttu tuleb m\u00f5\u00f5tmisi siiski ise teha, soovitavalt mitte ainult \u00fcks kord, et omada reaalsusele l\u00e4hedast ettekujutust. S\u00f5ltuvalt Value Stream Map'ist teete otsuse, kust alustada ja mida k\u00f5igepealt parandada.<\/p>\n

Ajutine meeskond<\/h2>\n

\nPaljud ettev\u00f5tted, kes otsustavad DevOpsi rakendada, loovad meeskonna, mis ei ole ajutine, vaid eksisteerib mitu aastat. Kui p\u00f6\u00f6rdute DevOps palveli juurde, kus on kirjeldatud erinevaid korraldusstruktuuri mustreid DevOpsis, siis saate aru, et see on antipattern.<\/p>\n

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

\nKui meeskond eksisteerib osakondade vahel ainult selleks, et teha midagi muud eraldi ning eksisteerib kaua, siis loob see tarbetu takistuse. N\u00fc\u00fcd peab arendaja, selle asemel et minna kohe administraatori juurde k\u00fcsimust lahendama, esmalt p\u00f6\u00f6rduma DevOps osakonna poole, kes seej\u00e4rel edasi l\u00e4heb.<\/p>\n

Seet\u00f5ttu tuleb alustamiseks luua ajutine meeskond<\/strong>. Ta eksisteerib tinglikult pool aastat, maksimaalselt aasta, s\u00f5ltuvalt seatud eesm\u00e4rgist, et \u00fcletada \u00fcks valitud piirang, millele keskendume. Edasi see sureb. Kui valime j\u00e4rgmise punkti, kus on tugevalt valus, ja m\u00f5istame, et selleks on meil samuti vaja eraldi meeskonda, siis loome selle taas. Kuid \u201ep\u00fcsivalt\u201d ei tohiks sellised meeskonnad eksisteerida \u2014 muidu nad ainult h\u00e4irivad kommunikatsiooni ja v\u00f5tavad endale t\u00e4iesti eraldi \u00fclesandeid, et lihtsalt midagi teha. Need \u00fclesanded v\u00f5ivad olla \u00fcldse mitte seotud DevOps'iga 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 t\u00e4hendab mitte ainult tehnoloogiate ja t\u00f6\u00f6riistade muutmist, mida me kasutame, vaid ka t\u00f6\u00f6protsessi, m\u00f5tlemise ja v\u00e4\u00e4rtuste muutmist. Kui meeskond t\u00f6\u00f6tab nii, nagu ta on juba harjunud, ei suuda ta proovida teisi l\u00e4henemisviise.<\/p>\n

Need elada vastavalt teistele reeglitele: ignoreerida k\u00f5iki ettev\u00f5tte KPI-sid, kuna nad p\u00fc\u00fcavad t\u00f6\u00f6tada teisiti. Ajutised meeskonnad ei t\u00e4ida taotlusi serveri saamiseks, vaid l\u00e4hevad otse osakonda, mis nendega tegeleb, n\u00f5udma, et neil antaks k\u00f5igepealt see, mis vajalik, kuna see on prioriteetne \u00fclesanne ja kuna nad p\u00fc\u00fcavad elada teisiti. Meeskonnal on t\u00e4ielik konflikt k\u00f5igi olemasolevate protsessidega. Et praegused t\u00f6\u00f6meetodid neid ei segaks ja nad ei segaks teisi, isolatsioonime neid inimesi, moodustades eraldi meeskonna.<\/p>\n

B\u00fcrokraatia v\u00e4ltimine katsetes<\/strong>. Ajutistes meeskondades ei ole b\u00fcrokraatiat, nad ei t\u00e4ida t\u00f6\u00f6aja aruandeid, nad ei vastuta juhtidele. See on t\u00e4iesti eraldi maailm, kus inimesed elavad ja m\u00f5tlevad teisiti ning tegelevad t\u00e4iesti teiste asjadega. \u00c4rge segage neid \u00fcleliia.<\/p>\n

Katkematu t\u00f6\u00f6 teenuse kallal<\/strong>. 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\u00e4\u00e4vad kauaks rippuma \u2014 seda me ei vaja. Ajutise meeskonna loomine v\u00f5imaldab katsetada, peatamata samal ajal t\u00f6\u00f6 tegemist toote kallal.<\/p>\n

\u00c4ra kuluta aega t\u00f6\u00f6\u00fclesannetele<\/strong>. See on j\u00e4lle toote kohta. Selleks, et meeskond saaks proovida teisi t\u00f6\u00f6riistu ja muud, kulub palju aega. Et inimesed omandaksid t\u00f6\u00f6riistad, hakkaksid neid rakendama ja korralikult kasutama, kulub v\u00e4hemalt kuus kuud. Kui nad teevad veel tootega t\u00f6\u00f6d \u2014 venivad kuud l\u00f5putuks. Kui inimesed tegelevad tootega, t\u00f6\u00f6tavad nad taas vanade protsessidega \u2014 seda me ei vaja.<\/p>\n

Seet\u00f5ttu valime erinevatest osakondadest inimesi eraldi meeskonda, mis tegeleb teenuse transformatsiooniga. Tulemuseks on see, et teenus t\u00f6\u00f6tab, j\u00e4tkab arenemist ja samal ajal katsetame selle peal mingeid eksperimente.<\/p>\n

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

\nMeeskond koosneb mitmekesistest inimestest<\/strong>. See t\u00e4hendab, et ees on mitte ainult arendajad. Me ei tulnud teenusesse ja ei v\u00f5tnud sealt poole meeskonda \u2014 ei, me v\u00f5tsime inimesi erinevatest osakondadest<\/strong>. M\u00f5ni punkt tagasi leidisime erinevad osakonnad ja erinevad t\u00f6\u00f6tajad, kes on seotud transformeeritava teenusega. Neist me moodustame meeskonna, kuna see peab olema mitmekesine \u2014 me muudame nii katsetamisprotsessi, arendamisprotsessi kui ka teenuse toetamise protsessi. On vajalikud erinevad oskused.<\/p>\n

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

Soovitatav on, et need inimesed omaks autoriteeti organisatsioonis<\/strong>. V\u00f5ib-olla tuleb v\u00f5tta \u00fcks konservator, kuigi see ei meeldi. Kui meie ettev\u00f5te on suur, ei usu k\u00f5ik meie ideesse, ja keegi v\u00f5ib segada, n\u00e4iteks mitte eraldada stendi. Siin tuleb m\u00e4ngu autoriteet \u2014 respekteeritud inimene, kellel on suur kogemus ja kes on teeninud kolleegide head suhtumist. T\u00f6\u00f6 autoriteet meeskonnas lihtsustab \u00fclesannet ja ajutise meeskonna t\u00f6\u00f6d. Inimesed m\u00f5tlevad:<\/p>\n

\u2014 Aha, see \u00e4ge mees, keda me k\u00f5ik tunneme ja armastame, on seal \u2014 ilmselt on DevOps'is midagi, mida tasub vaadata!<\/em><\/p>\n

Seame eesm\u00e4rgi<\/h2>\n

\nOleme inimesi kokku kogunud, valinud teenuse, vaadanud piiranguid ja m\u00e4\u00e4ratlenud, kellele me m\u00f5ju avaldame. N\u00fc\u00fcd tuleb seada eesm\u00e4rk ja see peab olema just SMART<\/strong> \u2014 k\u00f5ik nii, nagu me armastame.<\/p>\n

Specific \u2014 konkreetsed<\/strong>.<\/p>\n

Measurable \u2014 m\u00f5\u00f5detavad<\/strong>. See on v\u00e4ga oluline punkt SMARTis. Kui te ei saa midagi m\u00f5\u00f5ta, ei saa te seda muuta ja aru saada, mis ja kuidas te tegite paremini v\u00f5i halvemini.<\/p>\n

Achievable \u2014 saavutatavad<\/strong>. Arvestage oma spetsiifikat. Kui olete enterprise-ettev\u00f5te, millel on pikk ajalugu ja suured kohustused, ning toote versioon tuleb v\u00e4lja kord aastas, siis ei suuda te poole aastaga saavutada uute versioonide v\u00e4ljalaskmist iga tunni tagant. Nii ei toimi. Seet\u00f5ttu seadke reaalselt saavutatav eesm\u00e4rk, mille t\u00e4itmine on m\u00f5istlikus ajaraamis v\u00f5imalik.<\/p>\n

Relevant \u2014 asjakohane. <\/strong>Eemaldame ainult selle kitsenduse, mis t\u00f5eliselt j\u00e4rgib meie praeguseid eesm\u00e4rke.<\/p>\n

Time Limited \u2014 ajaliselt piiratud.<\/strong>. Kui t\u00e4htaega pole \u2014 meeskond tegeleb sellega, mida iganes: proovib 15 tehnoloogiat 3 asemel, kirjutab tohutuid aruandeid, viib l\u00e4bi m\u00f5ttetut uurimist\u00f6\u00f6d, lihvib oma teostust l\u00e4ikivaks, kui eesm\u00e4rk on juba saavutatud.<\/p>\n

Eesm\u00e4rgi seatakse just Value Stream Map'i abil \u2014 kogume taas kokku k\u00f5ik inimesed ja joonistame. Kuid seekord joonistame juba p\u00f5hinedes eelmisele Value Stream Map'ile, mida soovime saavutada.<\/p>\n

\"Kuidas
\n
\nValime \u00fche kitsenduse, mida hakkame kohe k\u00f5rvaldama \u2014 sellega tegelebki meeskond. N\u00e4iteks t\u00f5in ootamise valmis versiooni ja selle tootmise vahele \u2014 see on k\u00f5ige levinum kitsendus, millega inimesed p\u00f6\u00f6rduvad n\u00f5ustajate poole.<\/p>\n

Seame \u00fclesanne: tahame, et valmimise ja t\u00f6\u00f6leasumise vaheline ooteaeg oleks maksimaalselt tund.<\/p>\n

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