Nëse nuk e kuptoni se çfarë është DevOps, ja një përmbledhje e shkurtër. DevOps është një grup praktikash që redukojnë frikërat e inxhinierëve dhe zvogëlojnë numrin e dështimeve në prodhimin e softuerit. Në përgjithësi, ato shkurtojnë kohën e daljes në treg — periudha nga ideja deri te dorëzimi i produktit përfundimtar te klientët, e cila lejon realizimin e shpejtë të eksperimentimeve biznesore.
Si të filloni transformimin DevOps? Nëse flasim shkurt: zgjedhim shërbimin me të cilin do të fillojmë procesin, identifikojmë ata që kanë lidhje me shërbimin, ndërtuam Hartën e Vlerës, krijojmë një ekip përkohëshem që do të merret me transformimin për një kohë dhe i japim atij një detyrë. E përsërisim ciklin sa herë që nevojitet.
Një plan të detajuar të transformimit DevOps me shembuj dhe udhëzime poshtë — në transkript Andrei Aleksandrov — inxhinier në kompaninë Express42, e cila ofron konsultime për zhvillimin e DevOps, duke e përshpejtuar këtë proces, pasi ka ndërtuar tashmë hartën e gurëve të sikletit. Nëse ju duket se transformimi nuk është i nevojshëm për ju, ose nëse keni një specifikë të tillë që praktikat DevOps nuk përshtaten, — përdorni raportin si një udhëzues për gjetjen dhe eliminimin e pengesave.
Nëse ju shqetëson çështja e transformimit DevOps, atëherë ju keni një kompani të madhe, dhe duhet të filloni ngadalë të shkallëzoni këtë proces në të gjithë strukturën. Deri sa të ketë nevojë për të transformuar ekipin ose për të eliminuar ndonjë kufizim, algoritmi më poshtë mund të përsëritet.
Zgjedhja e shërbimit
Plani është hartuar, le të fillojmë me hapin e parë — zgjedhjen e shërbimit. Kriteri i parë — jetëgjatësia: ka shërbime të vjetra — legacy, dhe të reja. Mund të filloni me të dyja.
Të zgjedhësh një shërbim të ri është logjikë. Ai është i ri, nuk ka ende një proces të vendosur të punës në ekipin që merret me të. Përreth tij nuk ka një mal borxhesh teknike, nuk është e nevojshme ta riparoni gjithmonë. Mund të bëjmë me të gjithçka që duam.
Në rastin e një shërbimi të vjetër ka probleme që lidhen me faktin se ndryshimi gjithmonë është i vështirë. Atje ka një grup të caktuar kufizimesh serioze, por ndoshta janë njerëz që janë gati ta riformulojnë gjithçka — ata janë lodhur dhe duan të bëjnë diçka ndryshe sepse ndihen të dhimbshëm.
Puna me një shërbim të vjetër krijon një precedens të fuqishëm në kompaninë tuaj – ka diçka për t'u ndryshuar. Nëse keni ndërruar shërbimin e ri, ai funksionon me 100 herë në orë, dhe gjithçka është mirë, atëherë njerëzit në kompaninë tuaj mund të thonë:
— Ky është shërbimi i ri! Atje gjithçka ishte e thjeshtë, provoni të bëni diçka me mjetin tonë të vjetër.
Ka sens të merrni shërbimin legacy në transformim, kur e bëni atë me dikë, për shembull, nëse keni ftuar një këshilltar të jashtëm. Të jemi të sinqertë, transformimi do të tundë gjithçka që është e mundur.. Po eksperimentoni dhe nuk e dini se ku do të shkoni, cilat teknologji dhe për çfarë do t'i përdorni, ku dhe cilat është problemet në procese që do të shfaqen. Prandaj, më e lehtë është të ndërroni të rejat.
Nëse gjithçka e bëni vetë dhe në kompani nuk ka ekspertizë të rëndësishme – merrni shërbimin e ri. Nëse njihni një këshilltar të jashtëm dhe keni mjete – zgjidhni atë të vjetër.
Ka shërbime që janë thjesht një ndërfaqe për përdoruesit, për shembull, një faqe e thjeshtë ose një aplikacion mobil. Por ka edhe gjëra serioze si sistemi i faturimit. Nëse diçka shkon keq me faturimin – do të jetë e vështirë të merresh me të. Këtu gjithashtu kemi një zgjedhje.
Ne punojmë ose me shërbime kritike, por të cilin jemi duke vuajtur, ai krijon kufizime, ose punojmë me ndërfaqen. Ky është kriteri i dytë për zgjedhjen. Po ashtu, ka mundësi të angazhojmë një konsulent të kualifikuar — punojmë me variantin e rëndë.
Por edhe në këtë rast, unë nuk do ta rekomandoja këtë, sepse, derisa nuk ka një kuptim se me çfarë po punojmë dhe në cilën drejtim duhet të transformohemi, të marrim një gjë kritike dhe ta rregullojmë — nuk është një ide shumë e mirë. Prandaj, në këtë rast preferojmë të punojmë me ndërfaqen, dëmtimi i së cilës nuk është kritik.
Më pas do të shqyrtojmë ekipin e shërbimit. Me ata që merren me këtë shërbim, do të na duhet të punojmë dhe ndërveprojmë vazhdimisht në kontakt të ngushtë.
Njerëzit në ekip përfshihen në dy kategori: konservatorë — jetojnë në botën e vjetër, ose thjesht nuk dinë asgjë rreth DevOps, dhe inovatorë, që sjellin të gjitha praktikat moderne. Të dytët nuk janë gjithmonë të informuar për temën, por të paktën janë të gatshëm për të.
Nga njëra anë, konservatorët janë njerëz me përvojë: kanë qenë në kompani për një kohë të gjatë, e dinë gjithçka për të, por nuk kanë informacion për praktikat. Nga ana tjetër janë inovatorët, të cilët kanë dëgjuar diçka, por sigurisht që kanë punuar në kompani për një kohë të shkurtër. Me kë është më mirë të punosh?
Me konservatorët do të duhet të bashkëpunojmë në çdo rast, sepse është shërbimi i tyre. Do të kemi nevojë të komunikojmë me ta, të kuptojmë specifikat e shërbimit, çfarë mund të bëhet kështu dhe çfarë ndryshe. Jemi të varur nga këshillat e tyre. Me siguri do të duhet t'u ngarkojmë atyre diçka, sepse ata e njohin shërbimin më mirë. Prandaj është e rëndësishme, me cilin ekip do të kemi kontakt në fund.
Është logjike të zgjidhni innovatorët për ekipin, sepse konservatorët mund të sabotojnë punën.
Në praktikë, shpesh ndodh që njerëzit konservatorë kanë përvojë të konsiderueshme, por nuk kuptojnë si të avancojnë më tej. Ata thjesht kanë frikë se pas transformimit dhe ristrukturimit të shërbimit, do të humbasin vendin e punës. N sometimes thjesht për shkak të moskuptimit të asaj që ndodh, ata sabotojnë punën.
Kam kam pas një rast, kur një djalë nga ekipi riparoi gjithçka, sepse kjo supozohej të ishte më e rëndësishme sesa ajo që po bëjmë tani. Ne vendosim një detyrë: realizojmë këtë pjesë sot — jo, në anën tjetër të botës ka një zjarr, dhe shkojmë ta riparojmë. Me njerëz të tillë është e vështirë të punosh.
Njerëzit nga ekipi i konservatorëve shpesh i injorojnë detyrat, ose i shtyjnë deri në minutën e fundit. Dhe nëse, Perëndia e ruajttë, bëni një gabim dhe u jepni KPI për numrin e detyrave të përfunduar, dhe ndonjë pjesë për arsye të panjohura nuk përfshihet në KPI, ata nuk do të bëjnë asgjë. Në thelb, do të kenë të drejtë, sepse ata do të humbasin bonusin e tyre.
Me inovatorët është më e lehtë — ata janë më lojalë.Ata tashmë kanë dëgjuar diçka, duan të shkojnë diku, prandaj do të ndihmojnë. Na duhen njerëz që janë të gatshëm të vuajnë në fillim: nëse shërbimi ndryshon, inovatorët do të përballen me të gjithë pengesat dhe problemet si pionierë. Inovatorët duan gjithçka të re dhe në modë, dhe të vuajnë.
Konservatorët mund të bëhen besimtarë më vonë. Kur të tregoni se keni ndryshuar një pjesë dhe gjithçka punon mirë, është e sigurt që ata gjithashtu do të duan ta provojnë dhe do të pranojnë fenë e re DevOps.
Le të përmbledhim. Nëse e bëjmë të gjithë transformimin brenda kompanisë sonë, atëherë zgjedhim: një shërbim të ri, me sa më shumë përparësi një ndërfaqe të thjeshtë, në mënyrë që të mos vuajmë shumë nga dështimi i tij, dhe një ekip inovatorësh.
Nëse kemi mundësi të ftojmë një këshilltar të jashtëm, në vend të një shërbimi të ri, marrim shërbimin e vjetër, për shkak të të cilit vuajmë tashmë. Njerëzit që janë angazhuar në transformim për një kohë të gjatë në kompani të ndryshme, kanë parë raste të ndryshme dhe tashmë e kuptojnë se si të bëjnë gjërat si duhet dhe në cilin drejtim duhet të shkojnë.
Kush është i përfshirë?
Na duhet të gjejmë të gjithë ata që kanë ndonjë lidhje me shërbimin: zhvillues, testues, administrues, siguri, menaxherë dhe, ndoshta, Product Owners. Megjithëse Product Owners nuk janë teknikë, ata kanë lidhje me shërbimin: marrin vendime, vendosin detyra.
Të gjithë ata që marrin ndonjë vendim dhe ndikojnë në atë që ndodh me shërbimin, duhet të gjenden, të njihemi dhe të bisedojmë.
Për çfarë na nevojiten? Për të ditur me kë të negociojmë.. Gjatë transformimit, kur ndryshon principi i zakonshëm i punës me shërbimin, do të ketë ende tronditje. Për një kohë, do të ketë devijime derisa të testojmë qasje të reja. Njerëzit duhet të jenë të gatshëm për këtë dhe ta pranojnë atë.
Pastaj do të duhet të ndërtojmë një Hartë Vlerash dhe pa këta njerëz nuk do ta ndërtosh, sepse vetëm ata së bashku e dinë plotësisht imazhin e asaj që po ndodh. Një person kurrë nuk e di gjithçka që ndodh me shërbimin.
Ata do të rekomandojnë njerëz në ekip. Më vonë do të diskutojmë pse nevojitet një ekip i veçantë. Do të duhet të marrim njerëz nga departamentet ekzistuese. Ata që kanë lidhje me shërbimin, mund të rekomandojnë kolegë që mendojnë si ne dhe që mund të na ndihmojnë dhe kanë kompetencë në atë që na nevojitet.
Pastaj mbledhim të gjithë këta njerëz nga departamente të ndryshme në një dhomë dhe fillojmë të ndërtojmë Hartën e Vlerave.
Ndërtojmë Hartën e Vlerave
Harta e Vlerave është një skemë ose hartë që tregon rrjedhën e vlerave deri te klienti. Ky është procesi i plotë nga ideimi deri në zbatimin e saj, duke përfshirë të gjitha etapet ndërmjet dhe si vlera përfundimisht arrin te klientët tanë.
Harta e Vlerave është e nevojshme për visualizoni të gjitha fazat e zhvillimit, lokalizoni problemet përmes matjeve që janë në procesin aktual dhe filloni t'i zgjidhni këto probleme, dhe vendosni një qëllim fillestar. Ky është vendi ku do të fillojmë të bëjmë diçka reale.
Metricat
Në literaturën mbi Hartën e Vlerës janë përshkruar shumë metrika të ndryshme, por për fillim na mjafton vetëm të tri.
Koha e Prerjes — vonesa/pritur — koha kur presim diçka. Për shembull, testi i pritjes së një vendi për teste, dhe në këtë kohë nuk mund të bëjë asgjë.
Koha e Vlerës së Shtuar — koha e punës së dobishme — ajo që kemi shpenzuar në një fazë të tillë për të krijuar vlerën përfundimtare për përdoruesin. Për shembull, testi e ka ndjekur testin e tij dhe ka filluar të kontrollojë diçka. Kjo është koha e punës së dobishme, kur ne faktikisht bëjmë diçka për produktin. Kjo është ajo për të cilën klientët paguajnë — për software cilësor.
%C/A — përqindja e punës së pranuar. Kemi një fazë — zhvillimi, faza e dytë — testi. Sa shumë veçori kanë pranuar testuesit nga zhvilluesit, dhe ekziston ky përqindje.
Dikur duket kështu harta jonë.
Ajo është e mundur që të duket ndryshe në varësi të strukturës organizative, numrit të departamenteve dhe asaj që bëni. Por në përgjithësi, harta do të ketë dy faza: ideja dhe analiza. Në këtë fazë priten të dhëna, për shembull, Koha e Çmimeve 2 javë dhe Koha e Vlerës të Shtuar 2 ditë.
Metrit e mbulojmë të gjitha fazat.
Backlog — sa detyra ishin duke pritur pas se sa analistët i menduan ato.
Разработка — sa javë zhvilluesit pritën për sqarime mbi detyrat, stendat apo pajisjet — nuk ka rëndësi, por ata po presin diçka. Për shembull, 4 ditë ata realizojnë një veçori. Këtu shfaqet metri %C/A. Zhvilluesit morën vetëm 80% të detyrave nga Backlog. Ata mendojnë se 20% e tjera nuk kanë një specifikim të qartë dhe i dërguan për rishikim.
Testimi. Në skemë LT është caktuar 4 ditë. Për shembull, testuesit pritën të lirojnë stendën e testimit, VA 2 ditë ata vërtet testojnë diçka, dhe %C/A = 40%. — vetëm 40% e kodit ose veçorave që zhvilluesit dërguan, testuesit i konsideruan adekuate. Të gjitha të tjerat nuk u pëlqyen për një arsye.
Nuk do të ndalem shumë në këtë proces matjeje, në fund të artikullit do të rekomandoj literaturën nga e cila mund të mësoni për to.
E vetmja që do të rekomandoja është të mos i besoni njerëzve që do të krijojnë me ju një Hartë të Vlerës. Ata paraqesin se sa kohë zgjatën proceset e ndryshme, por këto vlerësime nuk janë gjithmonë të sakta, ndaj është më mirë ta matni vetë.
Kemi pasur një rast kur shkuam në departamentin e Operacioneve dhe pyetëm se sa kohë merrte dorëzimi i një funksionaliteti të ri në prodhim. Na u përgjigjën se 10 minuta, dhe ne menduam, përse erdhëm direkt në këtë kompani? Doli se 10 minuta ishin koha e skriptit që merrte kodin dhe e dërgonte në server. Por para kësaj, lëshimi qëndronte për tre ditë në server e duke pritur — në Backlog kishte një detyrë që duhej vendosur. Pra, rezulton se para fazës së lëshimit ka një fazë pritje, ku projekti thjesht qëndron. Nëse nuk do të kishim shkuar me një bllok shënimesh, nuk do të ishim fokusuar në detyrën në Jira dhe nuk do të kishim filluar ta ndiqnim hap pas hapi, do të kishim menduar se gjithçka ishte mirë dhe nuk kishte asnjë problem.
Prandaj, do t'ju duhet të kryeni vetë matjet, preferohet jo një herë, për të pasur një paraqitje që është afër realitetit. Në varësi të Hartës së Fluksit të Vlerës, do të merrni vendimin se nga ku të filloni dhe çfarë të korrigjoni si prioritet.
Ekipi temporary
Shumë kompani që vendosën të implementojnë DevOps krijojnë një ekip, jo temporary, por që ekziston për disa vite. Nëse referoheni në shërbimin DevOps, ku janë përshkruar mënyra të ndryshme për ndërtimin e strukturës organizative në DevOps, do të kuptoni se kjo është një anti-model.
Kur ekipi DevOps ekziston vazhdimisht për disa vite — kjo është një gabim i madh, sepse DevOps është për komunikimin ndërmjet departamenteve, për shpejtësinë dhe efikasitetin.
Nëse ekipi ekziston mes departamenteve, vetëm për të bërë diçka tjetër të veçantë, dhe ekziston për një kohë të gjatë, atëherë ai krijon një barrierë shtesë. Tashmë, programuesi, në vend që të shkojë menjëherë te administratori për të zgjidhur një problem, duhet fillimisht të kontaktojë departamentin DevOps, dhe ai do të shkojë më tej.
Prandaj, për të filluar, është e nevojshme të krijoni një ekip temporary. Ajo do të ekzistojë në mënyrë kushtore për gjysmë viti, maksimumi për një vit, në varësi të qëllimit të vendosur, vetëm për të zgjidhur një kufizim të vetëm që ne zgjodhëm. Më pas ajo do të vdesë. Nëse ne do të zgjedhim pikën tjetër ku ndiejmë dhimbje të madhe dhe do të kuptojmë se për të na nevojitet gjithashtu një ekip i veçantë, atëherë ne do ta krijojmë përsëri. Por në 'pjesën e vërtetë' ekipi si ky nuk duhet të ekzistojë — përndryshe ata vetëm do të prishin komunikimin dhe do të marrin përsipër detyra të veçanta, vetëm për të bërë diçka. Këto detyra mund të mos kenë lidhje fare me DevOps dhe me transformimin. Pse të mos ia japim këtë detyrë departamenteve ekzistuese?
Pse është një ekip përkohës
Konflikti me proceset aktuale. Transformimi DevOps është një ndryshim jo vetëm në teknologjitë dhe mjetet që përdorim, por edhe në procesin e punës, mendimin dhe vlerat. Nëse ekipi do të punojë ashtu siç është mësuar, ai nuk do të mund të provojë qasje të tjera.
Këta njerëz duhet të jetojnë sipas rregullave të tjera: të injorojnë të gjitha KPI-të në kompani, sepse po përpiqen të punojnë ndryshe. Ekipet përkohshme nuk do të plotësojnë aplikacione për të marrë një server, por do të shkojnë drejtpërdrejt në departamentin që zajis, me kërkesën për t'u dhënë atyre në radhë të parë atë që nevojitet, sepse kjo është një detyrë prioritare dhe sepse po përpiqen të jetojnë ndryshe. Ekipi ka një konflikt të plotë me të gjitha proceset aktuale. Që metodat e tanishme të punës të mos u pengojnë atyre tani, dhe ata të mos pengojnë të tjerët, ne do t'i izolojmë këta njerëz duke i vendosur në një ekip të veçantë.
Shmangia e byrokracisë në eksperimente. Në ekipet përkohshme nuk ka byrokraci, ata nuk plotësojnë raporte për orët e punës, ata nuk raportojnë përpara menaxherëve. Ky është një botë krejtësisht e ndarë, në të cilën njerëzit jetojnë dhe mendojnë ndryshe dhe angazhohen në gjera krejt të tjera. Mos i pengoni ata pa nevojë.
Puna e pandërprerë mbi shërbimin. Në pikën e parë ne kemi zgjedhur diçka mbi të cilën do të eksperimentojmë. Eksperimentet dhe kërkimi i mënyrave për të punuar më mirë janë të mira, por ne duam të zhvillojmë edhe karakteristika. Nëse e gjithë ekipi merret me transformimin në vend të karakteristikave, ne do të fillojmë të humbasim të ardhurat dhe defektet do të kalojnë shumë kohë pa u zgjidhur — kjo nuk na nevojitet. Krijimi i një ekipi përkohës dhe lejon eksperimentimin, pa ndaluar punën mbi produktin.
Mospërjekje për detyrat e punës. Kjo përsëri ka të bëjë me produktin. Për sa kohë që ekipi të provojë mjete të tjera e kështu me radhë, kërkohet shumë kohë. Për njerëzit të mësojnë mjete, të fillojnë t’i zbatojnë dhe t’i përdorin në mënyrë të duhur, duhen të paktën gjashtë muaj. Nëse ata do të merren edhe me produktin — gjashtë muaj do të zgjasin në masë të madhe. Nëse njerëzit merren me produktin, ata do të punojnë përsëri me proceset e vjetra — kjo nuk na nevojitet.
Prandaj nga departamente të ndryshme ne caktojmë njerëz në një ekip të veçantë, i cili do të merret me transformimin e shërbimit. Si rezultat, shërbimi funksionon, vazhdon të zhvillohet, dhe në të njëjtën kohë ne vendosim disa eksperimente mbi të.
Ekipi përkohësisht merret vetëm me transformimin e DevOps — eliminimin e atij kufizimi që gjetëm, dhe asgjë më shumë.
Ekipa përbëhet nga njerëz polyvalentë. Kjo do të thotë se ne morëm jo vetëm zhvilluesit. Ne nuk erdhëm në shërbim dhe nuk e morëm gjithë ekipin nga aty — jo, ne morëm njerëz nga departamente të ndryshme. Disa pika më parë, gjetëm departamente të ndryshme dhe punonjës të ndryshëm që kanë lidhje me shërbimin që po transformojmë. Nga ata formojmë ekipin, sepse ai duhet të jetë polyvalent — do të ndryshojmë procesin e testimit, procesin e zhvillimit dhe procesin e shërbimit të shërbimit. Ne kemi nevojë për kompetenca të ndryshme.
Zakoni do të merrnim një zhvillues, një testues dhe një inxhinier — secilin nga një, dhe së bashku me ta do të krijojmë një zgjidhje që na lejon të jetojmë ndryshe.
Preferohet që këta njerëz të kenë autoritet në organizatë. Ndoshta do të duhet të angazhojmë një konservator, edhe pse nuk dëshirojmë. Nëse kemi një kompani të madhe, jo të gjithë do të besojnë në planin tonë, dhe ndonjë mund të përpiqet të na pengojë, për shembull, duke mos siguruar një stendë. Këtu ne do të na nevojitet një «autoritet» — një person i respektuar me shumë përvojë, i cili ka fituar respektin e kolegëve. Autoriteti i një punonjësi në ekip do ta lehtësojë detyrën dhe punën e ekipit përkohësisht. Njerëzit do të mendojnë:
— Ah, ky është ai tipi i madh që të gjithë e njohim dhe e duam, duket se në DevOps ka diçka, që ia vlen ta shohim!
Vendosim një qëllim
Kemi mbledhur njerëzit, kemi zgjedhur shërbimin, kemi parë kufizimet, kemi përcaktuar se në kë të ndajmë ndikimin tonë. Tani duhet të vendosim një qëllim dhe ai duhet të jetë konkret sipër SMART — çdo gjë, siç na pëlqen.
Specific — specifike.
Measurable — e matshme. Ky është një pikë shumë e rëndësishme e SMART. Nëse nuk mund ta matni diçka, atëherë nuk mund ta ndryshoni dhe nuk do të kuptoni se çfarë bëni më mirë ose më keq.
Achievable — e arritshme. Bëni një kompromis për specifikën tuaj. Nëse jeni një kompani enterprise me histori të gjatë dhe një ngarkesë të madhe përgjegjësish, e cila lëshon një version produkti çdo vit, nuk do të mund të arrini të lëshoni versione të reja produkti çdo orë brenda gjashtë muajve. Kjo nuk është e mundur. Prandaj, vendosni një qëllim real, të arritshëm brenda një periudhe të pranueshme.
Relevant — e rëndësishme. Ne eliminojmë vetëm atë kufizim që vërtet ndjek qëllimet tona aktuale.
Time Limited — e kufizuar në kohë. Nëse nuk ka afat — ekipa do të merret me çfarëdo: të provojë 15 teknologji në vend të 3, të shkruajë raporte të mëdha, të bëjë hulumtime të kota, të rafinojë implementimin e saj deri në shkëlqim, kur qëllimi tashmë është arritur.
Ne e marrim qëllimin duke përdorur Mapped Value Stream — sërish mbledhim të gjithë njerëzit dhe vizatojmë. Por tani, mbi bazën e Mapped Value Stream të mëparshme, vizatojmë atë që duam të arrijmë.
Dallo një kufizim që do të eliminojmë tani, — me këtë do të merret ekipa. Për shembull, kam marrë pritjen nga lëshimi përfundimtar deri te vendosja në prodhim — kjo është kufizimi më i shpeshtë me të cilin njerëzit i drejtohen konsulentëve.
Bazuar në këtë, vendosim një detyrë: duam që koha midis lëshimit të përfunduar dhe daljes në treg të jetë maksimum një orë.
Shembuj të detyrave.
- Të shkurtojë kohën e testimit nga 4 ditë në 1 orë.
- Të shkurtojë kohën e vlerësuar për testim nga 2 ditë në 3 orë.
- Të shkurtojë kohën e lëshimit nga 5 orë në 10 minuta.
- Të rritet C/A nga 50% në 95%, do të thotë të rritet numri i karakteristikave që pranojnë testuesit, në fjalë të tjera, të përmirësohet cilësia e punës së zhvilluesve.
Shembujt e detyrave nuk janë marrë nga ajri — ato bazohen në matjet që kemi bërë kur zhvilluam Hartën e Vlerës.
Vendosim një detyrë të ngjashme për ekipin tonë dhe një kufizim në afat. Varësisht nga sa mirë shkoi në kompaninë tuaj, vendosni afate të ndryshme. Në mesatare, për të eliminuar kufizimin, nëse njerëzit e bëjnë këtë për herë të parë dhe nuk e dinë akoma se me cilat teknologji dhe si konkretisht do të zgjidhin problemin, zakonisht kalon gjysmë viti.
Planifikim të shkurtër
Pra, ekipi ynë është krijuar, ka një qëllim, njerëzit fillojnë të punojnë. Një pikë e rëndësishme — është planifikimi i shkurtër i punës: sprintet një deri në dy javëdhe, më shumë, përmirësime të matshme çdo javë dhe korrigjimi i kursit.
Për shembull, ne shpesh përdorim qasjen moving-moving, kur e gjithë ekipa mblidhet në fillim të çdo jave, shkruan në një dosje se çfarë do të bëjë secili. Pas një jave vlerësojmë: çfarë është bërë dhe çfarë jo, dhe nëse nuk është bërë, pse, dhe mendojmë se çfarë të bëjmë më tej.
Sprintet lejojnë rregullimin e kursit në kohë.
Pas një ose dy javësh provoni diçka: teknologji, qasje, metoda pune, pastaj matni përsëri dhe shikoni — a është bërë më mirë apo më keq me këtë qasje? Nëse është bërë më keq, domethënë po shkojmë në drejtimin e gabuar, duhet të rregullojmë kursin: të vendosim një detyrë tjetër, të marrim një teknologji tjetër ose të bëjmë diçka tjetër. Sprintet e shkurtra të 1-2 javëve lejojnë manovrimin dhe largimin në kohë nga vendimet e këqija.
Ndajmë suksesin
Ekipa arrin disa suksese, të vogla ose të mëdha — nuk ka rëndësi, gjithmonë ka një rezultat. Të gjithë duhet të dinë për këtë rezultat: si ata që janë të përfshirë në DevOps, ashtu edhe departamentet fqinje. Në një botë ideale, do të ishte e dëshirueshme që kjo të arrinte në të gjithë të gjithë njerëzit në kompani.
Pse? Nëse duam të transformojmë jo një pjesë të kompanisë, të heqim jo një kufizim, por të heqim të gjitha për të bërë kompaninë më fleksibile, për të dërguar kodin shpejt te klienti pa asnjë problem, duhet që të gjithë të jenë të angazhuar për idenë e DevOps. Nuk do të mund të aplikoni këtë qasje në shërbime dhe ekipe që janë kategorikisht kundër.
Për të krijuar angazhim, duhet të tregojmë të gjithëve se ne provuam këtë — kemi arritur rezultate, provoni edhe ju! Kjo do të rrisë interesin dhe angazhimin për atë që bëjmë, njerëzit do të fillojnë të provojnë diçka menjëherë. Siç tregon praktika, kur ne tregojmë se çfarë provuam dhe çfarë arritëm, ekipet e tjera fillojnë të pyesin se si dhe çfarë kemi bërë. Ata shikojnë implementimet, kodin, dokumentacionin, afrohen me pyetje dhe përpiqen të ndryshojnë diçka te vetja.
Të tregosh për atë që arrite — është e rëndësishme. Kështu do të bindësh konservatorët që duan të vazhdojnë si më parë të kalojnë në kampin tuaj dhe t'i transformosh ata në inovatorë.
Në përfundim
Zgjedhim shërbimin, si pikë reference — vendi ku do të fillojmë ndryshimet në kompani. Identifikojmë të gjithë ata që kanë ndonjë lidhje me shërbimin dhe së bashku me ta krijojmë Hartën e Vlerës, matim dhe shikojmë ku dhe çfarë kufizimesh ka.
Krijojmë një ekip të ri të përkohshëm, i cili do të zgjidhë detyrën e caktuar. Bazuar në matjet dhe Hartën e Vlerës vizatojmë një hartë të re, ku theksojmë kufizimin që do të trajtojmë. Bazuar në këtë kufizim caktojmë një detyrë, me të cilën do të merret ekipi. Detyra duhet të jetë patjetër SMART — specifike, e matshme, relevante për detyrat aktuale dhe e kufizuar në kohë.
Përsërisim procesin, derisa të transformojmë të gjitha shërbimet tona në formën e kërkuar dhe të eliminojmë të gjitha kufizimet.
Bonus. Materiale të dobishme
Për ata që vendosen të merren me DevOps në mënyrë të pavarur.
Projekti 'Feniks'
Titulli origjinal — «Projekti Phoenix: Një roman për IT, DevOps dhe ndihmën për të fituar biznesin tuaj». Ky është një roman mbi DevOps — një histori se si një punonjës u bë shefi i një departamenti që gjithmonë ishte në zjarr. Shefi i ri mori një detyrë:
— Ke disa vjet për të gjitha ta korrigjuar, që të mundim më në fund të dorëzojmë produktin tonë shpejt dhe efektivisht për klientët tanë.
«Projekti “Feniks”. Një roman mbi mënyrën se si DevOps ndihmon për ta ndryshuar jetën për mirë» — një libër për të gjithë menaxherët, sepse këta njerëz marrin vendime për atë që ndodh në kompani. Nëse jeni inxhinier ose programues dhe dëshironi që në kompaninë tuaj të fillojë një levizje dhe transformim — blini librin dhe dhuroni për menaxhimin. Ky roman shpjegon gjithçka, duke u lexuar shpejt dhe lehtë.
Udhëzuesi i DevOps
Një libër më i avancuar. Doli para disa vjetësh në anglisht me titullin «The DevOps Handbook How to create world‑class agility, reliability, and security in Technology organizations», por tani është tashmë në shqip. Ky është një udhëzues — një manual praktik: si të kryhen matjet, çfarë është harta e vlerës (Value Stream Map) dhe përse është e nevojshme, ku duhet të shkojmë, në cilin rend. Libri është pikërisht për ata që duan të bëjnë gjithçka vetë. E rëndësishme është se ai përmban shembuj të përvojës së kompanive të tjera.
Për shembull, ajo tregon se si një kompani ndihmoi në ndërtimin e një Karte të Vlerës dhe kuptoi se kufizimi i saj nuk ishte në produkt, por në atë se si kasieri shkonte nga dyqani në zyrën më të afërt për ta përdorur këtë produkt. Në vend që të zgjidhnin problemin me programin, ata thjesht blenë tableta për shitësit e tyre, dhe tani askush nuk shkon diku, por çdo veprim kryhet në vendin e punës. Përfundim: Karte e Vlerës mund të aplikohet jo vetëm në softuer, por edhe në të gjithë proceset në organizatë.
Accelerate
Emri i plotë: «Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations». Ky është niveli tjetër — hardcore. Libri doli vitin e kaluar, për tani vetëm në anglisht dhe është rreth hulumtimeve. Autorët — Nicole Forsgren, Jez Humble dhe Gene Kim — në një periudhë të gjatë kanë aplikuar praktika të ndryshme në kompani të ndryshme dhe kanë hulumtuar se cilat praktika, si dhe për çfarë ndikojnë.
Në kapitullin e dytë, i cili i kushtohet matjeve, përmenden Mappa e Rrjedhës së Vlerës, metrikat që përmenda, dhe shumë të tjera, si dhe përshkruhet në detaje procesi i matjeve. Autorët kryejnë matje duke përdorur anketat dhe ndjekjen e detyrave nga vetë. Flitet në detaje se cilat metrika duhen matur siç duhet, cilat nuk duhen, dhe gabimet njerëzore në matje. Nëse hasni vështirësi me matjet, referojuni kapitullit të dytë të librit "Accelerate". Nëse në ekipin tuaj ka shumë praktika, por nuk është e qartë cili praktikë të aplikoni tani, cili më vonë, cili funksionon me të vërtetë dhe cili jo — lexoni, në libër është gjithçka e shpjeguar.
Transformimi është një çështje në ndërfaqen e DevOps dhe menaxhimit. Në të njëjtën zonë të ndërfaqes së zhvillimit, operacioneve dhe testimit ndodhin temat që ne përpiqemi të diskutojmë në , integrimi i të njëjtave nevojitet gjithashtu për krijimin e një produkti cilësor – tema kryesore . Menaxhimi në festival paraqitet — do të thotë për idetë për transformim, e gjithë ajo është atje. Bashkohuni më 27 dhe 28 maj, do të integrohemi dhe do të transformohemi.
Burimi: habr.com
