Dacă nu înțelegi ce este DevOps, iată un scurt ghid. DevOps este un set de practici care reduc temerile inginerilor și scad numărul de erori în producția de software. De regulă, acestea scad timpul de lansare pe piață — perioada de la idee până la livrarea produsului final către clienți, ceea ce permite desfășurarea rapidă a experimentelor de afaceri.
Cum să începi transformarea DevOps? Pe scurt: alegem serviciul cu care începem procesul, identificăm persoanele implicate în serviciu, construim o hartă a fluxului de valoare, formăm o echipă temporară care se va ocupa de transformare în primele etape și îi stabilim o sarcină. Repetăm ciclul de câte ori este necesar.
Un plan detaliat de transformare DevOps cu exemple și instrucțiuni este disponibil în continuare Andrei Alexandrov — inginer la compania Express42, care consultă în dezvoltarea DevOps, accelerând acest proces, deoarece a construit deja harta provocărilor. Dacă ți se pare că transformarea nu este necesară sau specificul tău face ca practicile DevOps să nu fie aplicabile, folosește raportul ca un ghid pentru identificarea și eliminarea constrângerilor.
Dacă te îngrijorează problema transformării DevOps, înseamnă că ai o companie mare și trebuie să scalezi treptat acest proces în întreaga structură. Atâta timp cât există necesitatea de a transforma echipa sau de a elimina o constrângere, algoritmul de mai jos poate fi repetat.
Alegerea serviciului
Planificat, să înceapă cu primul pas — alegerea serviciului. Primul criteriu — durata de viață: există servicii vechi — legacy și servicii noi. Se poate începe cu ambele.
Este logic să alegi un serviciu tânăr. Este proaspăt, nu există încă un proces de lucru stabilit în echipa care se ocupă de el. Nu are o acumulare mare de datorii tehnice, nu trebuie să-l repari tot timpul. Putem face cu el tot ce vrem.
În cazul unui serviciu vechi, există probleme legate de faptul că schimbarea este întotdeauna dificilă. Acolo există deja un set de constrângeri serioase, dar, posibil, există persoane care sunt gata să se implice — ele s-au săturat și doresc să facă lucrurile diferit, pentru că resimt durerea.
Lucrul cu un serviciu vechi creează un precedent puternic în compania dumneavoastră — se pot face modificări. Dacă ați implementat un nou serviciu, care merge în producție de 100 de ori pe oră, și totul este în regulă, atunci oamenii din compania dumneavoastră ar putea spune:
— Dar acesta e un nou serviciu! Acolo totul era simplu, încercați să faceți ceva cu rămășițele noastre.
Este sens să adopți un serviciu legacy atunci când îl transformi împreună cu cineva, de exemplu, dacă ai invitat un consultant extern. Să fim sinceri, transformarea va zgudui tot ce se poate.. Experimentați și nu știți unde veți ajunge, ce tehnologii și de ce veți folosi, unde și ce capcane pot apărea în procese. De aceea, este mai ușor să schimbi noul.
Dacă totul faceți singur și în companie nu există competențe serioase — alegeți un nou serviciu. Dacă cunoașteți un consultant extern și aveți fonduri — optați pentru cel vechi.
Există servicii care sunt pur și simplu o interfață pentru utilizatori, de exemplu, un site simplu sau o aplicație mobilă. Dar există și lucruri serioase în domeniul facturării. Dacă ceva nu merge bine cu facturarea — va fi greu să se rezolve. Aici, de asemenea, avem de ales.
Noi lucrăm fie cu un serviciu critic, dar deja suferim din cauza lui, deoarece creează restricții, fie lucrăm cu o interfață. Acesta este al doilea criteriu de selecție. În mod similar, există posibilitatea de a atrage un consultant experimentat — lucrăm cu varianta grea.
Însă, chiar și în acest caz, nu aș recomanda să facem așa, deoarece, până nu există o înțelegere clară cu ce lucrăm și în ce direcție transformăm, să luăm un lucru critic și să-l rearanjăm — nu este o idee foarte bună. Așadar, în acest caz, preferăm să lucrăm cu o interfață, al cărei defect nu este critic.
Mai departe, vom analiza echipa de serviciu. Cu cei care se ocupă de acest serviciu, va trebui să lucrăm constant și să interacționăm în foarte strâns contact.
Oamenii din echipă se împart în mod condiționat în două categorii: conservatori — trăiesc în vechea lume sau pur și simplu nu știu nimic despre DevOps, și inovatori, care promovează toate practicile la modă. Cei din urmă nu înțeleg întotdeauna subiectul, dar măcar sunt dispuși să se implice.
Pe de o parte, conservatorii sunt oameni experimentați: au fost mult timp în companie, se înțeleg pe deplin, dar nu cunosc practicile. Pe de altă parte, inovații care au auzit ceva, dar cel mai probabil nu lucrează de foarte mult timp în companie. Cu cine ar fi mai bine să colaborăm?
Va trebui să colaborăm cu conservatorii în orice caz, deoarece acesta este serviciul lor. Va trebui să comunicăm cu ei, să clarificăm specificul serviciului, ce se poate face într-un mod, și ce nu. Depindem de consultanțele lor. Cu siguranță va trebui să le încredințăm ceva, pentru că ei cunosc serviciul lor mai bine. De aceea, este important cu ce echipă vom avea contact în cele din urmă.
Este logic să alegi inovații în echipă, pentru că conservatorii pot pune bețe în roate.
În practică, se întâmplă adesea ca oamenii conservatori să aibă experiență semnificativă, dar să nu înțeleagă cum să meargă mai departe. Le este frică că după transformarea și restructurarea serviciului, vor fi dați afară pentru că nu mai sunt necesari. Uneori, din cauza neînțelegerii a ceea ce se întâmplă, sabotează munca.
Am avut un caz în care un tip din echipă repara tot ce-i ieșea în față, pentru că acesta era, chipurile, mai critic decât ceea ce facem acum. Stabilim o sarcină: să realizăm astăzi acest segment - nu, la capătul lumii e un incendiu, mergem să-l reparăm. E greu să lucrezi cu astfel de oameni.
Oamenii din echipa conservatorilor adesea ignoră sarcinile sau le amână până în ultimul moment. Și dacă, Doamne ferește, ai greșit și le-ai pus KPI pentru numărul de sarcini finalizate, iar o parte din ele nu sunt incluse în KPI, nu vor face nimic. Într-adevăr, vor avea dreptate, pentru că atunci își pierd bonusul.
Cu inovații este mai simplu - sunt mai loiali.Ei au auzit deja ceva, vor să se îndrepte către ceva, așa că vor ajuta. Ne trebuie oameni care sunt dispuși să sufere la început: dacă serviciul se schimbă, toate erorile și obstacolele vor fi întâmpinate de inovați ca pionieri. Inovații vor toate cele mai noi și la modă, și vor suferi.
Conservatorii pot fi convertiți mai târziu în credința voastră. Când le vei arăta că ai schimbat o parte și totul funcționează bine, cel mai probabil, vor dori să încerce și vor accepta noua religie DevOps.
Să rezumăm. Dacă facem întreaga transformare în compania noastră, alegem: un serviciu nou, preferabil cu o interfață simplă, pentru a nu suferi prea mult din cauza defectărilor, și o echipă de inovatori.
Dacă există posibilitatea de a chema un consultant extern, în loc de un nou serviciu – optăm pentru vechiul serviciu, din cauza căruia deja suferim. Oamenii care s-au ocupat de transformare suficient de mult timp în diverse companii au văzut diferite cazuri și încep să înțeleagă cum să facă lucrurile corect și în ce direcție să meargă.
Cine este implicat?
Trebuie să îi găsim pe toți cei care au vreo legătură cu serviciul: dezvoltatori, testeri, administratori, specialiști în securitate, manageri și, posibil, Product Owners. Deși Product Owners nu sunt tehnici, au legătură cu serviciul: iau decizii, stabilesc sarcini.
Pe toți cei care iau vreo decizie și influențează ceea ce se întâmplă cu serviciul trebuie să-i găsim, să ne întâlnim și să discutăm.
De ce ne sunt ei necesari? Pentru a ști cu cine să ne înțelegem.. În timpul transformării, când principiile obișnuite de funcționare ale serviciului se schimbă, acesta va fi afectat. O vreme vor exista erori, până testăm noile abordări. Oamenii trebuie să fie pregătiți pentru asta și să fie de acord.
Apoi va trebui să construim Value Stream Map și fără aceste persoane nu îl putem construi, pentru că doar ei împreună cunosc întreaga imagine a ceea ce se întâmplă. O singură persoană niciodată nu știe tot ce se întâmplă cu serviciul.
Ei ne pot sfătui cu privire la oamenii din echipă. Mai târziu vom discuta despre de ce avem nevoie de o echipă separată. Va trebui să luăm oameni din departamentele existente. Cei care au legătură cu serviciul pot recomanda colegi care gândesc în direcția noastră, care ne pot ajuta și au competențele necesare.
Apoi, adunăm toți acești oameni din diverse departamente într-o cameră și începem să construim Value Stream Map.
Construim Value Stream Map.
Value Stream Map este un diagramă sau o hartă care arată fluxul de valori către client.. Este întregul proces de la conceperea ideii până la implementarea acesteia, inclusiv toate etapele intermediare și modul în care valoarea ajunge în cele din urmă la clienții noștri.
Value Stream Map este necesar pentru a vizualiza toate etapele dezvoltării, a localiza problemele prin măsurătorile existente în procesul actual și a începe să le eliminăm, și a stabili obiectivul inițial.Acesta este locul unde vom începe să facem cu adevărat ceva.
Metrici
În literatura despre Value Stream Map sunt descrise multe metrici diferite, dar pentru început ne ajung doar trei.
Lead Time — întârziere/așteptare — timpul în care așteptăm ceva. De exemplu, un tester așteaptă ca un stand de testare să devină disponibil și, în acest timp, nu poate face nimic.
Value Added Time — timpul de lucru util — cel pe care l-am petrecut într-o anumită etapă pentru a crea valoarea finală pentru utilizator. De exemplu, testerul a început testul și a început să verifice ceva. Acesta este timpul de lucru util, când facem cu adevărat ceva pentru produs. Acesta este ceea ce clienții plătesc — pentru software de calitate.
%C/A — procentul de lucru acceptat. Avem o etapă — dezvoltare, a doua etapă — testare. Câte caracteristici au fost acceptate de testeri de la dezvoltatori și există acest procent.
Cam așa arată harta noastră.
Ea poate arăta diferit în funcție de structura organizației, numărul de departamente și ceea ce faceți. Dar, în general, harta va avea două etape: ideea și analiza. În această etapă se așteaptă date, de exemplu, Lead Time 2 săptămâni și Value Added Time 2 zile.
Metricile acoperă absolut toate etapele.
Backlog — câte sarcini au rămas după ce analiștii le-au gândit.
Dezvoltare — câte săptămâni au așteptat dezvoltatorii clarificări pentru sarcini, standuri sau echipamente — nu contează, dar ei așteaptă ceva. De exemplu, 4 zile ei implementează o caracteristică. Aici apare metrica %C/A. Dezvoltatorii au preluat din backlog doar 80% din sarcini. Ei consideră că pentru restul de 20% nu există un caiet de sarcini suficient de clar, așa că le-au trimis pentru revizuire.
Testare. În diagramă, LT este setat la 4 zile. De exemplu, testerii au așteptat eliberarea standului de testare, VA 2 zile ei au testat cu adevărat ceva, iar %C/A = 40%. — doar 40% din codul sau caracteristicile pe care le-au trimis dezvoltatorii au fost considerate adecvate de către testeri. Tot restul nu le-a plăcut din anumite motive.
Nu voi intra în detalii despre cum să efectuezi aceste măsurători, la sfârșitul articolului voi recomanda literatură din care poți afla despre ele.
Singurul lucru pe care îl sfătuiesc este să nu credeți oamenilor care vor face cu voi Value Stream Map. Ei estimează cât timp durează diferite procese, dar aceste estimări nu sunt întotdeauna corecte, așa că este mai bine să măsurați singuri.
A avut un caz în care am mers în departamentul Operations și am întrebat cât timp durează livrarea unei noi funcționalități în producție. Ni s-a răspuns că 10 minute, și ne-am gândit de ce am venit în această companie. S-a dovedit că cele 10 minute sunt timpul de rulare a scriptului care ia codul și îl livrează pe server. Dar înainte de asta, release-ul stă timp de trei zile pe server și pur și simplu se adună praf — în Backlog există o sarcină care trebuie desfășurată. Așadar, înainte de etapa de desfășurare, există o etapă de așteptare, în care proiectul pur și simplu stagnă. Dacă nu am fi mers cu un notebook, nu am fi observat sarcina din Jira și nu am fi început să o urmărim pas cu pas, am fi considerat că totul este minunat și că nu există nicio problemă.
De aceea, va trebui să faceți măsurători singuri, ideal de mai multe ori, pentru a avea o imagine cât mai apropiată de realitate. În funcție de Value Stream Map, veți lua decizii despre de unde să începeți și ce să corectați mai întâi.
Echipă temporară
Multe companii care au decis să implementeze DevOps își creează o echipă, doar că nu este temporară, ci existentă de câțiva ani. Dacă vă adresați unui serviciu DevOps care descrie diferite modele de organizare a structurii în DevOps, veți înțelege că aceasta este un antipatern.
Atunci când echipa DevOps există constant timp de câțiva ani — aceasta este o mare greșeală, deoarece DevOps este despre comunicarea între departamente, despre viteză și eficiență.
Dacă echipa există între departamente, doar pentru a face ceva separat, și există mult timp, atunci creează o barieră suplimentară. Acum, programatorul, în loc să meargă direct la administrator pentru a rezolva o problemă, trebuie mai întâi să se adreseze departamentului DevOps, care apoi va continua mai departe.
Așadar, pentru a începe, trebuie să creați o echipă temporară.. Va exista condiționat timp de șase luni, maximum un an, în funcție de obiectivul stabilit, doar pentru a elimina o singură restricție pe care am ales-o. După aceea, va dispărea. Dacă alegem următoarea problemă care ne doare puternic și realizăm că pentru aceasta avem nevoie de o echipă separată, atunci o vom crea din nou. Dar echipele de „permanent” nu ar trebui să existe — altfel ele doar perturbă comunicarea și preiau sarcini complet separate, doar ca să facă ceva. Aceste sarcini pot să nu fie legate de DevOps și de transformare. De ce să nu lăsăm această sarcină departamentelor existente?
De ce este necesară o echipă temporară
Conflict cu procesele actuale. Transformarea DevOps este o schimbare nu doar a tehnologiilor și instrumentelor pe care le folosim, ci și a procesului de lucru, a gândirii și a valorilor în sine. Dacă echipa va lucra așa cum este obișnuită, nu va reuși să încerce alte abordări.
Acești oameni trebuie să trăiască după alte reguli: să ignore toate KPI-urile din companie, deoarece încearcă să lucreze diferit. Echipele temporare nu vor completa cereri pentru a obține un server, ci se vor duce direct la departamentul care se ocupă cu acestea, cerându-le celor care le gestionează să le ofere, întâi de toate, ceea ce au nevoie, deoarece aceasta este o sarcină prioritară și pentru că încearcă să trăiască diferit. Echipa are un conflict total cu toate procesele actuale. Pentru ca metodele de lucru existente să nu le interfereze acum, iar ei să nu interfereze cu ceilalți, izolăm acești oameni, creându-le o echipă separată.
Evitarea birocrației în experimente. În echipele temporare nu există birocrație, nu completează rapoarte despre orele lucrate, nu răspund în fața managerilor. Este o lume complet separată, în care oamenii trăiesc și gândesc diferit și se ocupă cu lucruri complet diferite. Nu trebuie să le perturbăm din nou.
Lucru continuu asupra serviciului. În primul punct, am ales ceva cu care vom experimenta. Experimentele și căutarea de modalități de a lucra mai bine sunt importante, dar dorim să realizăm și caracteristici. Dacă întreaga echipă se va ocupa de transformare în loc de funcții, atunci vom începe să pierdem venituri, iar bug-urile vor rămâne mult timp — acest lucru nu ne este necesar. Crearea unei echipe temporare permite experimentarea, fără a opri însă lucrul asupra produsului.
Nu pierdeți timpul cu sarcinile de lucru. Este din nou despre produs. E nevoie de mult timp ca echipa să încerce alte instrumente și altele asemenea. Ca oamenii să învețe instrumentele, să înceapă să le implementeze și să le folosească corespunzător, va dura, cel puțin, jumătate de an. Dacă se vor ocupa și de produs — acea jumătate de an se va extinde enorm. Dacă oamenii se ocupă de produs, ei lucrează din nou cu vechile procese — nu avem nevoie de asta.
Prin urmare, din diferite departamente, selectăm oameni într-o echipă separată care se va ocupa de transformarea serviciului. Drept urmare, serviciul funcționează, continuă să se dezvolte și, în același timp, facem unele experimente pe el.
Echipa temporară se ocupă exclusiv de transformarea DevOps — eliminarea acelei restricții pe care am găsit-o și nimic mai mult.
Echipa este formată din oameni versatili. Asta înseamnă că am luat nu doar dezvoltatori. Nu ne-am dus în serviciu și nu am luat jumătate din echipă — nu, am luat oameni din diferite departamente. Cu câteva puncte în urmă, am găsit diferite departamente și diferiți angajați care au legătură cu serviciul în curs de transformare. Din ei formăm echipa, pentru că trebuie să fie versatilă — vom schimba atât procesul de testare, cât și procesul de dezvoltare, și procesul de întreținere a serviciului. Este nevoie de competențe diverse.
De obicei, luăm un dezvoltator, un tester și un inginer — pe fiecare câte unul, și împreună cu ei găsim o soluție care ne permite să funcționăm diferit.
Este de dorit ca acești oameni să aibă autoritate în organizație. Poate va trebui să luăm un conservator, deși nu vrem. Dacă avem o companie mare, nu toți vor crede în planul nostru, iar cineva ar putea pune bețe în roate, de exemplu, să nu aloce un stand. Aici va fi nevoie de „autoritate” — o persoană respectată, cu multă experiență, care a câștigat respectul colegilor. Autoritatea angajatului în echipă va simplifica sarcina și munca echipei temporare. Oamenii vor gândi:
— Aha, tipul acela grozav pe care îl știm și îl iubim s-a înscris — se pare că în DevOps este ceva demn de văzut!
Stabilim un obiectiv
Am strâns oamenii, am ales serviciul, am analizat limitările, am stabilit asupra căror oameni vom avea influență. Acum trebuie să stabilim un obiectiv și acesta trebuie să fie chiar după SMART — tot așa cum ne place.
Specific — specifică.
Measurable — măsurabilă. Acesta este un punct foarte important din SMART. Dacă nu poți măsura ceva, nu poți schimba și nu poți înțelege ce și cum ai făcut mai bine sau mai rău.
Achievable — realizabilă. Fă ajustări în funcție de specificul tău. Dacă ești o companie de tip enterprise cu o lungă istorie și o mare povară de responsabilități, care lansează o versiune de produs o dată pe an, nu vei putea în jumătate de an să atingi lansarea de noi versiuni de produs la fiecare oră. Asta nu se va întâmpla. Așadar, stabilește un obiectiv realist, care poate fi realizat într-un interval de timp acceptabil.
Relevant — relevantă. Eliminăm doar acea constrângere care urmărește cu adevărat obiectivele noastre actuale.
Time Limited — limitată în timp. Dacă nu există un termen limită — echipa se va ocupa de orice altceva: va încerca 15 tehnologii în loc de 3, va scrie rapoarte enorme, va desfășura cercetări inutile, va lucra la implementarea sa până la strălucire, când obiectivul a fost deja atins.
Obiectivul este stabilit cu ajutorul Value Stream Map — reunim din nou toți oamenii și desenăm. Dar doar acum, pe baza Value Stream Map anterioare, desenăm ceea ce vrem să obținem.
Subliniem o constrângere pe care o vom elimina chiar acum - asta va face echipa. De exemplu, am luat așteptarea de la lansarea finalizată până la desfășurarea în producție - aceasta este cea mai frecventă constrângere cu care oamenii contactează consultantii.
Pe baza acestui lucru stabilim sarcina: vrem ca așteptarea între lansarea finalizată și ieșirea în luptă să fie de maximum o oră.
Exemple de sarcini.
- Reducerea timpului de testare de la 4 zile la 1 oră.
- Reducerea timpului adăugat pentru testare de la 2 zile la 3 ore.
- Reducerea timpului de desfășurare de la 5 ore la 10 minute.
- Creșterea C/A de la 50% la 95%, adică creșterea numărului de funcționalități acceptate de testeri, cu alte cuvinte, îmbunătățirea calității muncii dezvoltatorilor.
Exemplele de sarcini nu sunt inventate - ele sunt bazate pe măsurători pe care le-am făcut când am dezvoltat Value Stream Map.
Stabilim o sarcină similară echipei noastre și o constrângere de timp. În funcție de cât de bine sunt lucrurile în compania ta, stabilești termene diferite. În medie, pentru eliminarea constrângerii, când oamenii se ocupă de asta pentru prima dată și nu știu încă prin ce tehnologii și cum vor rezolva problema, de obicei durează șase luni.
Planificare scurtă
Așadar, echipa noastră este formată, are un scop, iar oamenii încep să lucreze. Un aspect important este planificarea pe termen scurt a activităților: sprinturi de una-două săptămâniși, nu mai mult, îmbunătățiri măsurabile în fiecare săptămână și ajustarea direcției.
De exemplu, folosim adesea abordarea moving-moving, când întreaga echipă se adună la începutul fiecărei săptămâni, notează într-un document ce va face fiecare. După o săptămână, analizăm: ce a fost realizat și ce nu, iar dacă nu, de ce, și ne gândim ce să facem în continuare.
Sprinturile permit ajustarea direcției la timp.
O săptămână sau două am încercat ceva: tehnologii, abordări, metode de lucru, după care măsurăm din nou și vedem - a fost mai bine sau mai rău cu această abordare? Dacă a fost mai rău, înseamnă că ne îndreptăm greșit, trebuie să ajustăm direcția: să stabilim o altă sarcină, să adoptăm o tehnologie diferită sau să facem altceva. Sprinturile scurte de 1-2 săptămâni ne permit să ne adaptăm și să renunțăm la soluțiile slabe la timp.
Împărtășim succesul
Echipa atinge unele succese, fie ele mici sau mari — nu contează, întotdeauna există un anumit rezultat. Despre acest rezultat trebuie să știe toată lumea: atât cei implicați în DevOps, cât și departamentele învecinate. Într-o lume ideală, ar fi de dorit să ajungă la toți oamenii din companie.
De ce? Dacă dorim să transformăm nu o parte a companiei, să eliminăm o singură restricție, ci toate, pentru ca firma să devină flexibilă, codul să ajungă rapid la client, iar nimic să nu se defecteze, trebuie ca toată lumea să fie loială ideii de DevOps. Nu veți putea aplica abordarea la servicii și echipe care sunt categoric împotrivă.
Pentru a crea loialitate, trebuie să le povestim tuturor că am încercat asta — avem un rezultat, încercați și voi! Acest lucru va crește interesul și loialitatea față de ceea ce facem, iar oamenii își vor începe imediat propriile încercări. Așa cum arată practica, atunci când povestim ce am încercat și ce am realizat, alte echipe încep să întrebe cum și ce am făcut. Ele analizează implementările, codul, documentația, vin cu întrebări și încearcă să schimbe ceva la ele însele.
A povesti despre ceea ce ați realizat este important. Astfel, veți convinge conservatorii să vină în tabăra voastră, care doreau să facă totul pe calea veche și îi transformați în inovatori.
În concluzie
Alegerem serviciul, ca punct de plecare — locul de unde vom începe schimbările în companie. Identificăm pe toți cei care au vreo legătură cu serviciul și împreună cu ei construim o Hartă a Fluxului de Valoare, măsurăm și observăm unde și ce limitări există.
Creăm o nouă echipă temporară, care se va ocupa de sarcina stabilită. Pe baza măsurărilor și a Hărții Fluxului de Valoare conturăm o nouă hartă, unde evidențiem limitarea pe care ne propunem să o abordăm. Pe baza acestei limitări stabilim sarcina, cu care se va ocupa echipa. Sarcina trebuie să fie neapărat SMART — specifică, măsurabilă, relevantă pentru sarcinile curente și limitată în timp.
Repetăm procesul, până când transformăm toate serviciile noastre la forma dorită și eliminăm toate limitările.
Bonus. Materiale utile
Pentru cei care au decis să se ocupe de DevOps pe cont propriu.
Proiectul „Fenix”
Titlul original - „The Phoenix Project: A Novel about It, Devops, and Helping Your Business Win”. Este un roman despre DevOps - o poveste despre cum un angajat a fost numit șef de departament, care era mereu în foc. Noul șef a primit sarcina:
— Ai la dispoziție câțiva ani pentru a rezolva totul, astfel încât să putem finalmente livra produsul nostru rapid și eficient clienților noștri.
„Proiectul „Fenix”. Roman despre cum DevOps schimbă viața în bine” - o carte pentru toți managerii, pentru că tocmai aceste persoane iau decizii despre ceea ce se întâmplă în companie. Dacă ești inginer sau programator și vrei ca în compania ta să înceapă o mișcare și o transformare - cumpără cartea și oferă-o conducerii. Acest roman explică totul și se citește rapid și ușor.
Ghid pentru DevOps
O carte mai complexă. A fost lansată acum câțiva ani în limba engleză sub titlul „The DevOps Handbook How to create world‑class agility, reliability, and security in Technology organizations”, dar acum există deja și în română. Este un adevărat manual - un ghid practic: despre cum să realizăm măsurători, ce este Harta Fluxului de Valoare și de ce este necesară, în ce direcție ar trebui să ne îndreptăm, în ce ordine. Cartea este pentru cei care doresc să facă totul pe cont propriu. Cel mai important, conține exemple din experiența altor companii.
De exemplu, se discută cum o companie a construit o hartă a fluxului de valoare și a realizat că limitarea nu era în produs, ci în faptul că casierul mergea de la magazin la biroul vecin pentru a folosi acest produs. În loc să rezolve problema cu software-ul, pur și simplu au cumpărat tablete pentru vânzători, iar acum nimeni nu mai pleacă nicăieri, ci toate acțiunile se desfășoară la locul de muncă. Concluzie: Harta fluxului de valoare poate fi aplicată nu doar software-ului, ci și tuturor proceselor din organizație.
Accelerare
Titlul complet: „Accelerate: Știința Lean Software și DevOps: Construirea și Scalarea Organizațiilor Tehnologice cu Performanțe Ridicate”. Acesta este un nou nivel — hardcore. Cartea a fost publicată anul trecut, deocamdată doar în engleză și vorbește despre cercetări. Autorii — Nicole Forsgren, Jez Humble și Gene Kim — au aplicat timp de mulți ani diverse practici în diferite companii și au analizat care practici, cum și asupra a ce influențează.
În al doilea capitol, dedicat măsurărilor, se menționează harta fluxului de valoare, metricile pe care le-am menționat și multe altele, iar procesul de măsurare este detaliat. Autorii efectuează măsurători prin chestionare și auto-urmărirea sarcinilor. Este descris în detaliu ce metrici trebuie măsurate corect, ce nu ar trebui, erorile umane în măsurători. Dacă aveți dificultăți cu măsurătorile, consultați al doilea capitol al cărții „Accelerate”. Dacă echipa dumneavoastră are multe practici, dar nu este clar care practici să fie aplicate acum, care mai târziu, care sunt cu adevărat eficiente și care nu — citiți, cartea oferă toate răspunsurile.
Transformarea este o întrebare la intersecția DevOps și management. În aceeași zonă de intersecție a dezvoltării, operării și testării se află subiectele pe care ne străduim să le discutăm la , aceeași integrare este necesară și pentru crearea unui produs de calitate – tema principală de la . Managementul la festivalul este prezentat — înseamnă că toate ideile pentru transformare se îndreaptă acolo. Alăturați-vă între 27 și 28 mai, ne vom integra și transforma.
Sursa: habr.com
