{"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\/ro\/blog\/administrirovanie\/kak-nachat-devops-transformatsiyu","title":{"rendered":"Cum s\u0103 \u00eencepi transformarea DevOps","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Dac\u0103 nu \u00een\u021belegi ce este DevOps, iat\u0103 un scurt ghid. DevOps este un set de practici care reduc temerile inginerilor<\/strong> \u0219i scad num\u0103rul de erori \u00een produc\u021bia de software. De regul\u0103, acestea scad timpul de lansare pe pia\u021b\u0103<\/strong> \u2014 perioada de la idee p\u00e2n\u0103 la livrarea produsului final c\u0103tre clien\u021bi, ceea ce permite desf\u0103\u0219urarea rapid\u0103 a experimentelor de afaceri<\/strong>.<\/p>\n

Cum s\u0103 \u00eencepi transformarea DevOps? Pe scurt: alegem serviciul cu care \u00eencepem procesul, identific\u0103m persoanele implicate \u00een serviciu, construim o hart\u0103 a fluxului de valoare, form\u0103m o echip\u0103 temporar\u0103 care se va ocupa de transformare \u00een primele etape \u0219i \u00eei stabilim o sarcin\u0103. Repet\u0103m ciclul de c\u00e2te ori este necesar.<\/p>\n

\"Cum<\/p>\n

Un plan detaliat de transformare DevOps cu exemple \u0219i instruc\u021biuni este disponibil \u00een continuare raportului<\/a><\/noindex> Andrei Alexandrov<\/b> \u2014 inginer la compania Express42, care consult\u0103 \u00een dezvoltarea DevOps, acceler\u00e2nd acest proces, deoarece a construit deja harta provoc\u0103rilor. Dac\u0103 \u021bi se pare c\u0103 transformarea nu este necesar\u0103 sau specificul t\u0103u face ca practicile DevOps s\u0103 nu fie aplicabile, folose\u0219te raportul ca un ghid pentru identificarea \u0219i eliminarea constr\u00e2ngerilor.
\n<\/a><\/noindex>
\nDac\u0103 te \u00eengrijoreaz\u0103 problema transform\u0103rii DevOps, \u00eenseamn\u0103 c\u0103 ai o companie mare \u0219i trebuie s\u0103 scalezi treptat acest proces \u00een \u00eentreaga structur\u0103. At\u00e2ta timp c\u00e2t exist\u0103 necesitatea de a transforma echipa sau de a elimina o constr\u00e2ngere, algoritmul de mai jos poate fi repetat.<\/p>\n

Alegerea serviciului<\/h2>\n

\nPlanificat, s\u0103 \u00eenceap\u0103 cu primul pas \u2014 alegerea serviciului. Primul criteriu \u2014 durata de via\u021b\u0103<\/strong>: exist\u0103 servicii vechi \u2014 legacy \u0219i servicii noi. Se poate \u00eencepe cu ambele.<\/p>\n

Este logic s\u0103 alegi un serviciu t\u00e2n\u0103r<\/strong>. Este proasp\u0103t, nu exist\u0103 \u00eenc\u0103 un proces de lucru stabilit \u00een echipa care se ocup\u0103 de el. Nu are o acumulare mare de datorii tehnice, nu trebuie s\u0103-l repari tot timpul. Putem face cu el tot ce vrem.<\/p>\n

\u00cen cazul unui serviciu vechi, exist\u0103 probleme legate de faptul c\u0103 schimbarea este \u00eentotdeauna dificil\u0103<\/strong>. Acolo exist\u0103 deja un set de constr\u00e2ngeri serioase, dar, posibil, exist\u0103 persoane care sunt gata s\u0103 se implice \u2014 ele s-au s\u0103turat \u0219i doresc s\u0103 fac\u0103 lucrurile diferit, pentru c\u0103 resimt durerea.<\/p>\n

Lucrul cu un serviciu vechi creeaz\u0103 un precedent puternic<\/strong> \u00een compania dumneavoastr\u0103 \u2014 se pot face modific\u0103ri. Dac\u0103 a\u021bi implementat un nou serviciu, care merge \u00een produc\u021bie de 100 de ori pe or\u0103, \u0219i totul este \u00een regul\u0103, atunci oamenii din compania dumneavoastr\u0103 ar putea spune:<\/p>\n

\u2014 Dar acesta e un nou serviciu! Acolo totul era simplu, \u00eencerca\u021bi s\u0103 face\u021bi ceva cu r\u0103m\u0103\u0219i\u021bele noastre.<\/em><\/p>\n

Este sens s\u0103 adop\u021bi un serviciu legacy atunci c\u00e2nd \u00eel transformi \u00eempreun\u0103 cu cineva, de exemplu, dac\u0103 ai invitat un consultant extern. S\u0103 fim sinceri, transformarea va zgudui tot ce se poate.<\/strong>. Experimenta\u021bi \u0219i nu \u0219ti\u021bi unde ve\u021bi ajunge, ce tehnologii \u0219i de ce ve\u021bi folosi, unde \u0219i ce capcane pot ap\u0103rea \u00een procese. De aceea, este mai u\u0219or s\u0103 schimbi noul.<\/p>\n

Dac\u0103 totul face\u021bi singur \u0219i \u00een companie nu exist\u0103 competen\u021be serioase \u2014 alege\u021bi un nou serviciu. Dac\u0103 cunoa\u0219te\u021bi un consultant extern \u0219i ave\u021bi fonduri \u2014 opta\u021bi pentru cel vechi.<\/p><\/blockquote>\n

\nExist\u0103 servicii care sunt pur \u0219i simplu o interfa\u021b\u0103 pentru utilizatori, de exemplu, un site simplu sau o aplica\u021bie mobil\u0103. Dar exist\u0103 \u0219i lucruri serioase \u00een domeniul factur\u0103rii. Dac\u0103 ceva nu merge bine cu facturarea \u2014 va fi greu s\u0103 se rezolve. Aici, de asemenea, avem de ales.<\/p>\n

Noi lucr\u0103m fie cu un serviciu critic<\/strong>, dar deja suferim din cauza lui, deoarece creeaz\u0103 restric\u021bii, fie lucr\u0103m cu o interfa\u021b\u0103<\/strong>. Acesta este al doilea criteriu de selec\u021bie. \u00cen mod similar, exist\u0103 posibilitatea de a atrage un consultant experimentat \u2014 lucr\u0103m cu varianta grea.<\/p>\n

\u00cens\u0103, chiar \u0219i \u00een acest caz, nu a\u0219 recomanda s\u0103 facem a\u0219a, deoarece, p\u00e2n\u0103 nu exist\u0103 o \u00een\u021belegere clar\u0103 cu ce lucr\u0103m \u0219i \u00een ce direc\u021bie transform\u0103m, s\u0103 lu\u0103m un lucru critic \u0219i s\u0103-l rearanj\u0103m \u2014 nu este o idee foarte bun\u0103. A\u0219adar, \u00een acest caz, prefer\u0103m s\u0103 lucr\u0103m cu o interfa\u021b\u0103, al c\u0103rei defect nu este critic.<\/p>\n

Mai departe, vom analiza echipa de serviciu<\/b>. Cu cei care se ocup\u0103 de acest serviciu, va trebui s\u0103 lucr\u0103m constant \u0219i s\u0103 interac\u021bion\u0103m \u00een foarte str\u00e2ns contact.<\/p>\n

Oamenii din echip\u0103 se \u00eempart \u00een mod condi\u021bionat \u00een dou\u0103 categorii: conservatori<\/strong> \u2014 tr\u0103iesc \u00een vechea lume sau pur \u0219i simplu nu \u0219tiu nimic despre DevOps, \u0219i inovatori<\/strong>, care promoveaz\u0103 toate practicile la mod\u0103. Cei din urm\u0103 nu \u00een\u021beleg \u00eentotdeauna subiectul, dar m\u0103car sunt dispu\u0219i s\u0103 se implice.<\/p>\n

Pe de o parte, conservatorii sunt oameni experimenta\u021bi: au fost mult timp \u00een companie, se \u00een\u021beleg pe deplin, dar nu cunosc practicile. Pe de alt\u0103 parte, inova\u021bii care au auzit ceva, dar cel mai probabil nu lucreaz\u0103 de foarte mult timp \u00een companie. Cu cine ar fi mai bine s\u0103 colabor\u0103m?<\/p>\n

Va trebui s\u0103 colabor\u0103m cu conservatorii \u00een orice caz, deoarece acesta este serviciul lor. Va trebui s\u0103 comunic\u0103m cu ei, s\u0103 clarific\u0103m specificul serviciului, ce se poate face \u00eentr-un mod, \u0219i ce nu. Depindem de consultan\u021bele lor. Cu siguran\u021b\u0103 va trebui s\u0103 le \u00eencredin\u021b\u0103m ceva, pentru c\u0103 ei cunosc serviciul lor mai bine. De aceea, este important cu ce echip\u0103 vom avea contact \u00een cele din urm\u0103.<\/p>\n

Este logic s\u0103 alegi inova\u021bii \u00een echip\u0103, pentru c\u0103 conservatorii pot pune be\u021be \u00een roate.\n<\/p><\/blockquote>\n

\n\u00cen practic\u0103, se \u00eent\u00e2mpl\u0103 adesea ca oamenii conservatori s\u0103 aib\u0103 experien\u021b\u0103 semnificativ\u0103, dar s\u0103 nu \u00een\u021beleag\u0103 cum s\u0103 mearg\u0103 mai departe. Le este fric\u0103 c\u0103 dup\u0103 transformarea \u0219i restructurarea serviciului, vor fi da\u021bi afar\u0103 pentru c\u0103 nu mai sunt necesari. Uneori, din cauza ne\u00een\u021belegerii a ceea ce se \u00eent\u00e2mpl\u0103, saboteaz\u0103 munca.<\/p>\n

Am avut un caz \u00een care un tip din echip\u0103 repara tot ce-i ie\u0219ea \u00een fa\u021b\u0103, pentru c\u0103 acesta era, chipurile, mai critic dec\u00e2t ceea ce facem acum. Stabilim o sarcin\u0103: s\u0103 realiz\u0103m ast\u0103zi acest segment - nu, la cap\u0103tul lumii e un incendiu, mergem s\u0103-l repar\u0103m. E greu s\u0103 lucrezi cu astfel de oameni.<\/p>\n

Oamenii din echipa conservatorilor adesea ignor\u0103 sarcinile sau le am\u00e2n\u0103 p\u00e2n\u0103 \u00een ultimul moment. \u0218i dac\u0103, Doamne fere\u0219te, ai gre\u0219it \u0219i le-ai pus KPI pentru num\u0103rul de sarcini finalizate, iar o parte din ele nu sunt incluse \u00een KPI, nu vor face nimic. \u00centr-adev\u0103r, vor avea dreptate, pentru c\u0103 atunci \u00ee\u0219i pierd bonusul.<\/p>\n

Cu inova\u021bii este mai simplu - sunt mai loiali.<\/strong>Ei au auzit deja ceva, vor s\u0103 se \u00eendrepte c\u0103tre ceva, a\u0219a c\u0103 vor ajuta. Ne trebuie oameni care sunt dispu\u0219i s\u0103 sufere la \u00eenceput: dac\u0103 serviciul se schimb\u0103, toate erorile \u0219i obstacolele vor fi \u00eent\u00e2mpinate de inova\u021bi ca pionieri. Inova\u021bii vor toate cele mai noi \u0219i la mod\u0103, \u0219i vor suferi.<\/p>\n

Conservatorii pot fi converti\u021bi mai t\u00e2rziu \u00een credin\u021ba voastr\u0103. C\u00e2nd le vei ar\u0103ta c\u0103 ai schimbat o parte \u0219i totul func\u021bioneaz\u0103 bine, cel mai probabil, vor dori s\u0103 \u00eencerce \u0219i vor accepta noua religie DevOps.<\/p>\n

\"Cum
\n<\/p>\n

S\u0103 rezum\u0103m. Dac\u0103 facem \u00eentreaga transformare \u00een compania noastr\u0103, alegem: un serviciu nou, preferabil cu o interfa\u021b\u0103 simpl\u0103, pentru a nu suferi prea mult din cauza defect\u0103rilor, \u0219i o echip\u0103 de inovatori.<\/p><\/blockquote>\n

\nDac\u0103 exist\u0103 posibilitatea de a chema un consultant extern, \u00een loc de un nou serviciu \u2013 opt\u0103m pentru vechiul serviciu, din cauza c\u0103ruia deja suferim. Oamenii care s-au ocupat de transformare suficient de mult timp \u00een diverse companii au v\u0103zut diferite cazuri \u0219i \u00eencep s\u0103 \u00een\u021beleag\u0103 cum s\u0103 fac\u0103 lucrurile corect \u0219i \u00een ce direc\u021bie s\u0103 mearg\u0103.<\/p>\n

Cine este implicat?<\/h2>\n

\nTrebuie s\u0103 \u00eei g\u0103sim pe to\u021bi cei care au vreo leg\u0103tur\u0103 cu serviciul: dezvoltatori, testeri, administratori, speciali\u0219ti \u00een securitate, manageri \u0219i, posibil, Product Owners. De\u0219i Product Owners nu sunt tehnici, au leg\u0103tur\u0103 cu serviciul: iau decizii, stabilesc sarcini.<\/p>\n

\"Cum
\n<\/p>\n

Pe to\u021bi cei care iau vreo decizie \u0219i influen\u021beaz\u0103 ceea ce se \u00eent\u00e2mpl\u0103 cu serviciul trebuie s\u0103-i g\u0103sim, s\u0103 ne \u00eent\u00e2lnim \u0219i s\u0103 discut\u0103m.<\/p><\/blockquote>\n

\nDe ce ne sunt ei necesari? Pentru a \u0219ti cu cine s\u0103 ne \u00een\u021belegem.<\/strong>. \u00cen timpul transform\u0103rii, c\u00e2nd principiile obi\u0219nuite de func\u021bionare ale serviciului se schimb\u0103, acesta va fi afectat. O vreme vor exista erori, p\u00e2n\u0103 test\u0103m noile abord\u0103ri. Oamenii trebuie s\u0103 fie preg\u0103ti\u021bi pentru asta \u0219i s\u0103 fie de acord.<\/p>\n

Apoi va trebui s\u0103 construim Value Stream Map \u0219i f\u0103r\u0103 aceste persoane nu \u00eel putem construi, pentru c\u0103 doar ei \u00eempreun\u0103 cunosc \u00eentreaga imagine a ceea ce se \u00eent\u00e2mpl\u0103. O singur\u0103 persoan\u0103 niciodat\u0103 nu \u0219tie tot ce se \u00eent\u00e2mpl\u0103 cu serviciul.<\/p>\n

Ei ne pot sf\u0103tui cu privire la oamenii din echip\u0103. Mai t\u00e2rziu vom discuta despre de ce avem nevoie de o echip\u0103 separat\u0103. Va trebui s\u0103 lu\u0103m oameni din departamentele existente. Cei care au leg\u0103tur\u0103 cu serviciul pot recomanda colegi care g\u00e2ndesc \u00een direc\u021bia noastr\u0103, care ne pot ajuta \u0219i au competen\u021bele necesare.<\/p>\n

Apoi, adun\u0103m to\u021bi ace\u0219ti oameni din diverse departamente \u00eentr-o camer\u0103 \u0219i \u00eencepem s\u0103 construim Value Stream Map.<\/p>\n

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

\nValue Stream Map este un diagram\u0103 sau o hart\u0103 care arat\u0103 fluxul de valori c\u0103tre client.<\/strong>. Este \u00eentregul proces de la conceperea ideii p\u00e2n\u0103 la implementarea acesteia, inclusiv toate etapele intermediare \u0219i modul \u00een care valoarea ajunge \u00een cele din urm\u0103 la clien\u021bii no\u0219tri.<\/p>\n

Value Stream Map este necesar pentru a vizualiza toate etapele dezvolt\u0103rii<\/strong>, a localiza problemele prin m\u0103sur\u0103torile existente \u00een procesul actual \u0219i a \u00eencepe s\u0103 le elimin\u0103m, \u0219i a stabili obiectivul ini\u021bial.<\/strong>Acesta este locul unde vom \u00eencepe s\u0103 facem cu adev\u0103rat ceva.<\/p>\n

Metrici<\/h3>\n

\n\u00cen literatura despre Value Stream Map sunt descrise multe metrici diferite, dar pentru \u00eenceput ne ajung doar trei.<\/p>\n

Lead Time \u2014 \u00eent\u00e2rziere\/a\u0219teptare<\/strong> \u2014 timpul \u00een care a\u0219tept\u0103m ceva. De exemplu, un tester a\u0219teapt\u0103 ca un stand de testare s\u0103 devin\u0103 disponibil \u0219i, \u00een acest timp, nu poate face nimic.<\/p>\n

Value Added Time \u2014 timpul de lucru util<\/strong> \u2014 cel pe care l-am petrecut \u00eentr-o anumit\u0103 etap\u0103 pentru a crea valoarea final\u0103 pentru utilizator. De exemplu, testerul a \u00eenceput testul \u0219i a \u00eenceput s\u0103 verifice ceva. Acesta este timpul de lucru util, c\u00e2nd facem cu adev\u0103rat ceva pentru produs. Acesta este ceea ce clien\u021bii pl\u0103tesc \u2014 pentru software de calitate.<\/p>\n

%C\/A \u2014 procentul de lucru acceptat. <\/strong>Avem o etap\u0103 \u2014 dezvoltare, a doua etap\u0103 \u2014 testare. C\u00e2te caracteristici au fost acceptate de testeri de la dezvoltatori \u0219i exist\u0103 acest procent.<\/p>\n

Cam a\u0219a arat\u0103 harta noastr\u0103.<\/p>\n

\"Cum
\n
\nEa poate ar\u0103ta diferit \u00een func\u021bie de structura organiza\u021biei, num\u0103rul de departamente \u0219i ceea ce face\u021bi. Dar, \u00een general, harta va avea dou\u0103 etape: ideea <\/strong>\u0219i analiza<\/strong>. \u00cen aceast\u0103 etap\u0103 se a\u0219teapt\u0103 date, de exemplu, Lead Time 2 s\u0103pt\u0103m\u00e2ni \u0219i Value Added Time 2 zile.<\/p>\n

Metricile acoper\u0103 absolut toate etapele.<\/p><\/blockquote>\n

\nBacklog<\/strong> \u2014 c\u00e2te sarcini au r\u0103mas dup\u0103 ce anali\u0219tii le-au g\u00e2ndit.<\/p>\n

Dezvoltare<\/strong> \u2014 c\u00e2te s\u0103pt\u0103m\u00e2ni au a\u0219teptat dezvoltatorii clarific\u0103ri pentru sarcini, standuri sau echipamente \u2014 nu conteaz\u0103, dar ei a\u0219teapt\u0103 ceva. De exemplu, 4 zile ei implementeaz\u0103 o caracteristic\u0103. Aici apare metrica %C\/A. Dezvoltatorii au preluat din backlog doar 80% din sarcini. Ei consider\u0103 c\u0103 pentru restul de 20% nu exist\u0103 un caiet de sarcini suficient de clar, a\u0219a c\u0103 le-au trimis pentru revizuire.<\/p>\n

Testare<\/strong>. \u00cen diagram\u0103, LT este setat la 4 zile. De exemplu, testerii au a\u0219teptat eliberarea standului de testare, VA 2 zile ei au testat cu adev\u0103rat ceva, iar %C\/A = 40%. \u2014 doar 40% din codul sau caracteristicile pe care le-au trimis dezvoltatorii au fost considerate adecvate de c\u0103tre testeri. Tot restul nu le-a pl\u0103cut din anumite motive.<\/p>\n

Nu voi intra \u00een detalii despre cum s\u0103 efectuezi aceste m\u0103sur\u0103tori, la sf\u00e2r\u0219itul articolului voi recomanda literatur\u0103 din care po\u021bi afla despre ele.<\/p>\n

Singurul lucru pe care \u00eel sf\u0103tuiesc este s\u0103 nu crede\u021bi oamenilor care vor face cu voi Value Stream Map. Ei estimeaz\u0103 c\u00e2t timp dureaz\u0103 diferite procese, dar aceste estim\u0103ri nu sunt \u00eentotdeauna corecte, a\u0219a c\u0103 este mai bine s\u0103 m\u0103sura\u021bi singuri.<\/p>\n

A avut un caz \u00een care am mers \u00een departamentul Operations \u0219i am \u00eentrebat c\u00e2t timp dureaz\u0103 livrarea unei noi func\u021bionalit\u0103\u021bi \u00een produc\u021bie. Ni s-a r\u0103spuns c\u0103 10 minute, \u0219i ne-am g\u00e2ndit de ce am venit \u00een aceast\u0103 companie. S-a dovedit c\u0103 cele 10 minute sunt timpul de rulare a scriptului care ia codul \u0219i \u00eel livreaz\u0103 pe server. Dar \u00eenainte de asta, release-ul st\u0103 timp de trei zile pe server \u0219i pur \u0219i simplu se adun\u0103 praf \u2014 \u00een Backlog exist\u0103 o sarcin\u0103 care trebuie desf\u0103\u0219urat\u0103. A\u0219adar, \u00eenainte de etapa de desf\u0103\u0219urare, exist\u0103 o etap\u0103 de a\u0219teptare, \u00een care proiectul pur \u0219i simplu stagn\u0103. Dac\u0103 nu am fi mers cu un notebook, nu am fi observat sarcina din Jira \u0219i nu am fi \u00eenceput s\u0103 o urm\u0103rim pas cu pas, am fi considerat c\u0103 totul este minunat \u0219i c\u0103 nu exist\u0103 nicio problem\u0103.<\/p>\n

De aceea, va trebui s\u0103 face\u021bi m\u0103sur\u0103tori singuri, ideal de mai multe ori, pentru a avea o imagine c\u00e2t mai apropiat\u0103 de realitate. \u00cen func\u021bie de Value Stream Map, ve\u021bi lua decizii despre de unde s\u0103 \u00eencepe\u021bi \u0219i ce s\u0103 corecta\u021bi mai \u00eent\u00e2i.<\/p>\n

Echip\u0103 temporar\u0103<\/h2>\n

\nMulte companii care au decis s\u0103 implementeze DevOps \u00ee\u0219i creeaz\u0103 o echip\u0103, doar c\u0103 nu este temporar\u0103, ci existent\u0103 de c\u00e2\u021biva ani. Dac\u0103 v\u0103 adresa\u021bi unui serviciu DevOps care descrie diferite modele de organizare a structurii \u00een DevOps, ve\u021bi \u00een\u021belege c\u0103 aceasta este un antipatern.<\/p>\n

Atunci c\u00e2nd echipa DevOps exist\u0103 constant timp de c\u00e2\u021biva ani \u2014 aceasta este o mare gre\u0219eal\u0103, deoarece DevOps este despre comunicarea \u00eentre departamente, despre vitez\u0103 \u0219i eficien\u021b\u0103.<\/p><\/blockquote>\n

\nDac\u0103 echipa exist\u0103 \u00eentre departamente, doar pentru a face ceva separat, \u0219i exist\u0103 mult timp, atunci creeaz\u0103 o barier\u0103 suplimentar\u0103. Acum, programatorul, \u00een loc s\u0103 mearg\u0103 direct la administrator pentru a rezolva o problem\u0103, trebuie mai \u00eent\u00e2i s\u0103 se adreseze departamentului DevOps, care apoi va continua mai departe.<\/p>\n

A\u0219adar, pentru a \u00eencepe, trebuie s\u0103 crea\u021bi o echip\u0103 temporar\u0103.<\/strong>. Va exista condi\u021bionat timp de \u0219ase luni, maximum un an, \u00een func\u021bie de obiectivul stabilit, doar pentru a elimina o singur\u0103 restric\u021bie pe care am ales-o. Dup\u0103 aceea, va disp\u0103rea. Dac\u0103 alegem urm\u0103toarea problem\u0103 care ne doare puternic \u0219i realiz\u0103m c\u0103 pentru aceasta avem nevoie de o echip\u0103 separat\u0103, atunci o vom crea din nou. Dar echipele de \u201epermanent\u201d nu ar trebui s\u0103 existe \u2014 altfel ele doar perturb\u0103 comunicarea \u0219i preiau sarcini complet separate, doar ca s\u0103 fac\u0103 ceva. Aceste sarcini pot s\u0103 nu fie legate de DevOps \u0219i de transformare. De ce s\u0103 nu l\u0103s\u0103m aceast\u0103 sarcin\u0103 departamentelor existente?<\/p>\n

De ce este necesar\u0103 o echip\u0103 temporar\u0103<\/h3>\n

\nConflict cu procesele actuale<\/strong>. Transformarea DevOps este o schimbare nu doar a tehnologiilor \u0219i instrumentelor pe care le folosim, ci \u0219i a procesului de lucru, a g\u00e2ndirii \u0219i a valorilor \u00een sine. Dac\u0103 echipa va lucra a\u0219a cum este obi\u0219nuit\u0103, nu va reu\u0219i s\u0103 \u00eencerce alte abord\u0103ri.<\/p>\n

Ace\u0219ti oameni trebuie s\u0103 tr\u0103iasc\u0103 dup\u0103 alte reguli: s\u0103 ignore toate KPI-urile din companie, deoarece \u00eencearc\u0103 s\u0103 lucreze diferit. Echipele temporare nu vor completa cereri pentru a ob\u021bine un server, ci se vor duce direct la departamentul care se ocup\u0103 cu acestea, cer\u00e2ndu-le celor care le gestioneaz\u0103 s\u0103 le ofere, \u00eent\u00e2i de toate, ceea ce au nevoie, deoarece aceasta este o sarcin\u0103 prioritar\u0103 \u0219i pentru c\u0103 \u00eencearc\u0103 s\u0103 tr\u0103iasc\u0103 diferit. Echipa are un conflict total cu toate procesele actuale. Pentru ca metodele de lucru existente s\u0103 nu le interfereze acum, iar ei s\u0103 nu interfereze cu ceilal\u021bi, izol\u0103m ace\u0219ti oameni, cre\u00e2ndu-le o echip\u0103 separat\u0103.<\/p>\n

Evitarea birocra\u021biei \u00een experimente<\/strong>. \u00cen echipele temporare nu exist\u0103 birocra\u021bie, nu completeaz\u0103 rapoarte despre orele lucrate, nu r\u0103spund \u00een fa\u021ba managerilor. Este o lume complet separat\u0103, \u00een care oamenii tr\u0103iesc \u0219i g\u00e2ndesc diferit \u0219i se ocup\u0103 cu lucruri complet diferite. Nu trebuie s\u0103 le perturb\u0103m din nou.<\/p>\n

Lucru continuu asupra serviciului<\/strong>. \u00cen primul punct, am ales ceva cu care vom experimenta. Experimentele \u0219i c\u0103utarea de modalit\u0103\u021bi de a lucra mai bine sunt importante, dar dorim s\u0103 realiz\u0103m \u0219i caracteristici. Dac\u0103 \u00eentreaga echip\u0103 se va ocupa de transformare \u00een loc de func\u021bii, atunci vom \u00eencepe s\u0103 pierdem venituri, iar bug-urile vor r\u0103m\u00e2ne mult timp \u2014 acest lucru nu ne este necesar. Crearea unei echipe temporare permite experimentarea, f\u0103r\u0103 a opri \u00eens\u0103 lucrul asupra produsului.<\/p>\n

Nu pierde\u021bi timpul cu sarcinile de lucru<\/strong>. Este din nou despre produs. E nevoie de mult timp ca echipa s\u0103 \u00eencerce alte instrumente \u0219i altele asemenea. Ca oamenii s\u0103 \u00eenve\u021be instrumentele, s\u0103 \u00eenceap\u0103 s\u0103 le implementeze \u0219i s\u0103 le foloseasc\u0103 corespunz\u0103tor, va dura, cel pu\u021bin, jum\u0103tate de an. Dac\u0103 se vor ocupa \u0219i de produs \u2014 acea jum\u0103tate de an se va extinde enorm. Dac\u0103 oamenii se ocup\u0103 de produs, ei lucreaz\u0103 din nou cu vechile procese \u2014 nu avem nevoie de asta.<\/p>\n

Prin urmare, din diferite departamente, select\u0103m oameni \u00eentr-o echip\u0103 separat\u0103 care se va ocupa de transformarea serviciului. Drept urmare, serviciul func\u021bioneaz\u0103, continu\u0103 s\u0103 se dezvolte \u0219i, \u00een acela\u0219i timp, facem unele experimente pe el.<\/p>\n

Echipa temporar\u0103 se ocup\u0103 exclusiv de transformarea DevOps \u2014 eliminarea acelei restric\u021bii pe care am g\u0103sit-o \u0219i nimic mai mult.<\/p><\/blockquote>\n

\nEchipa este format\u0103 din oameni versatili<\/strong>. Asta \u00eenseamn\u0103 c\u0103 am luat nu doar dezvoltatori. Nu ne-am dus \u00een serviciu \u0219i nu am luat jum\u0103tate din echip\u0103 \u2014 nu, am luat oameni din diferite departamente<\/strong>. Cu c\u00e2teva puncte \u00een urm\u0103, am g\u0103sit diferite departamente \u0219i diferi\u021bi angaja\u021bi care au leg\u0103tur\u0103 cu serviciul \u00een curs de transformare. Din ei form\u0103m echipa, pentru c\u0103 trebuie s\u0103 fie versatil\u0103 \u2014 vom schimba at\u00e2t procesul de testare, c\u00e2t \u0219i procesul de dezvoltare, \u0219i procesul de \u00eentre\u021binere a serviciului. Este nevoie de competen\u021be diverse.<\/p>\n

De obicei, lu\u0103m un dezvoltator, un tester \u0219i un inginer \u2014 pe fiecare c\u00e2te unul, \u0219i \u00eempreun\u0103 cu ei g\u0103sim o solu\u021bie care ne permite s\u0103 func\u021bion\u0103m diferit.<\/p>\n

Este de dorit ca ace\u0219ti oameni s\u0103 aib\u0103 autoritate \u00een organiza\u021bie<\/strong>. Poate va trebui s\u0103 lu\u0103m un conservator, de\u0219i nu vrem. Dac\u0103 avem o companie mare, nu to\u021bi vor crede \u00een planul nostru, iar cineva ar putea pune be\u021be \u00een roate, de exemplu, s\u0103 nu aloce un stand. Aici va fi nevoie de \u201eautoritate\u201d \u2014 o persoan\u0103 respectat\u0103, cu mult\u0103 experien\u021b\u0103, care a c\u00e2\u0219tigat respectul colegilor. Autoritatea angajatului \u00een echip\u0103 va simplifica sarcina \u0219i munca echipei temporare. Oamenii vor g\u00e2ndi:<\/p>\n

\u2014 Aha, tipul acela grozav pe care \u00eel \u0219tim \u0219i \u00eel iubim s-a \u00eenscris \u2014 se pare c\u0103 \u00een DevOps este ceva demn de v\u0103zut!<\/em><\/p>\n

Stabilim un obiectiv<\/h2>\n

\nAm str\u00e2ns oamenii, am ales serviciul, am analizat limit\u0103rile, am stabilit asupra c\u0103ror oameni vom avea influen\u021b\u0103. Acum trebuie s\u0103 stabilim un obiectiv \u0219i acesta trebuie s\u0103 fie chiar dup\u0103 SMART<\/strong> \u2014 tot a\u0219a cum ne place.<\/p>\n

Specific \u2014 specific\u0103<\/strong>.<\/p>\n

Measurable \u2014 m\u0103surabil\u0103<\/strong>. Acesta este un punct foarte important din SMART. Dac\u0103 nu po\u021bi m\u0103sura ceva, nu po\u021bi schimba \u0219i nu po\u021bi \u00een\u021belege ce \u0219i cum ai f\u0103cut mai bine sau mai r\u0103u.<\/p>\n

Achievable \u2014 realizabil\u0103<\/strong>. F\u0103 ajust\u0103ri \u00een func\u021bie de specificul t\u0103u. Dac\u0103 e\u0219ti o companie de tip enterprise cu o lung\u0103 istorie \u0219i o mare povar\u0103 de responsabilit\u0103\u021bi, care lanseaz\u0103 o versiune de produs o dat\u0103 pe an, nu vei putea \u00een jum\u0103tate de an s\u0103 atingi lansarea de noi versiuni de produs la fiecare or\u0103. Asta nu se va \u00eent\u00e2mpla. A\u0219adar, stabile\u0219te un obiectiv realist, care poate fi realizat \u00eentr-un interval de timp acceptabil.<\/p>\n

Relevant \u2014 relevant\u0103. <\/strong>Elimin\u0103m doar acea constr\u00e2ngere care urm\u0103re\u0219te cu adev\u0103rat obiectivele noastre actuale.<\/p>\n

Time Limited \u2014 limitat\u0103 \u00een timp<\/strong>. Dac\u0103 nu exist\u0103 un termen limit\u0103 \u2014 echipa se va ocupa de orice altceva: va \u00eencerca 15 tehnologii \u00een loc de 3, va scrie rapoarte enorme, va desf\u0103\u0219ura cercet\u0103ri inutile, va lucra la implementarea sa p\u00e2n\u0103 la str\u0103lucire, c\u00e2nd obiectivul a fost deja atins.<\/p>\n

Obiectivul este stabilit cu ajutorul Value Stream Map \u2014 reunim din nou to\u021bi oamenii \u0219i desen\u0103m. Dar doar acum, pe baza Value Stream Map anterioare, desen\u0103m ceea ce vrem s\u0103 ob\u021binem.<\/p>\n

\"Cum
\n
\nSubliniem o constr\u00e2ngere pe care o vom elimina chiar acum - asta va face echipa. De exemplu, am luat a\u0219teptarea de la lansarea finalizat\u0103 p\u00e2n\u0103 la desf\u0103\u0219urarea \u00een produc\u021bie - aceasta este cea mai frecvent\u0103 constr\u00e2ngere cu care oamenii contacteaz\u0103 consultantii.<\/p>\n

Pe baza acestui lucru stabilim sarcina: vrem ca a\u0219teptarea \u00eentre lansarea finalizat\u0103 \u0219i ie\u0219irea \u00een lupt\u0103 s\u0103 fie de maximum o or\u0103.<\/p>\n

Exemple de sarcini.<\/p>\n