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 reduktojnë numrin e dështimeve në prodhimin e softuerit. Në përgjithësi, ato gjithashtu redukojnë kohën për të hyrë në treg — periudha nga ideja deri në dorëzimin e produktit përfundimtar te klientët, e cila lejon që të kryhen shpejt eksperimentet biznesore.
Si të filloni transformimin DevOps? Nëse flasim shkurt, zgjidhni shërbimin me të cilin do të filloni procesin, identifikoni ata që kanë lidhje me shërbimin, ndërtoni Hartën e Vlerës, krijoni një ekip përkohësisht që do të merret me transformimin për të parin kohë dhe vendosni një detyrë për të. Përsëritni ciklin sa herë që nevojitet.
Një plan i detajuar për transformimin DevOps me shembuj dhe udhëzime është në shpjegim Andrej Aleksandrov — inxhinierit në kompaninë Express42, e cila ofron këshilla për zhvillimin e DevOps, duke e përshpejtuar këtë proces, sepse tashmë ka ndërtuar hartën e pengesave. Nëse ju duket se transformimi nuk është për ju, ose keni një specifikë që praktikat DevOps nuk përputhen, - përdorni raportin si një udhëzues për gjetjen dhe eliminimin e pengesave.
Nëse jeni të shqetësuar për transformimin DevOps, atëherë keni një kompani të madhe dhe duhet ta zgjeroni ngadalë këtë proces në tërë strukturën. Deri sa ka nevojë për të transformuar ekipin ose për të eliminuar një pengesë, algoritmi më poshtë mund të përsëritet.
Zgjedhja e shërbimit
Plani është përgatitur, le të fillojmë me hapin e parë - zgjedhjen e shërbimit. Kriti i parë - koha e jetës: ka shërbime të vjetra - legacë, dhe të reja. Mund të filloni nga të dyja.
Të zgjidhni një shërbim të ri ka kuptim. Ai është i ri, nuk ka ende një proces të stabilizuar të punës në ekipin që merret me të. Nuk ka një mal të borxhit teknik përreth, nuk është e nevojshme ta riparoni atë vazhdimisht. Mund të bëjmë me të gjithçka që duam.
Në rastin e një shërbimi të vjetër, ka probleme që lidhen me të ndryshimi gjithmonë është i vështirë. Aty ka një grup kufizimesh serioze, por ndoshta janë njerëz që janë të gatshëm të presin gjithçka - ata janë lodhur dhe duan të bëjnë diçka ndryshe, sepse iu shkakton dhimbje.
Puna me një shërbim të vjetër krijon një precedent të fortë në kompaninë tuaj - mund të bëni diçka. Nëse keni ndryshuar një shërbim të ri, ai del në prodhim 100 herë në orë, dhe gjithçka është mirë, atëherë njerëzit në kompaninë tuaj mund të thonë:
— Ky është një shërbim i ri! Ajo ishte gjithçka e thjeshtë, provoni të bëni diçka me plehrat tona.
Shërbimi Legacy ka kuptim të merret në transformim kur e bëni atë me dikë, për shembull, nëse keni ftuar një konsultant të jashtëm. Të jemi të sinqertë, transformimi do të tronditë gjithçka që mundet.. Ju eksperimentoni dhe nuk dini se ku do të shkoni, cilat teknologji do të përdorni dhe për çfarë, ku dhe cilat pengesa do të shfaqen në procese. Prandaj, është më e lehtë të ndërrosh diçka të re.
Nëse po e bëni gjithçka vetë, dhe në kompaninë tuaj nuk ka kompetencë të rëndësishme — marrim shërbimin e ri. Nëse njihni një konsultant të jashtëm dhe keni mjete — zgjidhni atë të vjetër.
Ka shërbime që përfaqësojnë thjesht një ndërfaqe për përdoruesit, për shembull, një sit të thjeshtë ose një aplikacion mobil. Por ka edhe gjëra serioze si faturimi. 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 një shërbim kritik, por për shkak të tij vuajmë, ai krijon kufizime, ose punojmë me ndërfaqen. Ky është kriteri i dytë i zgjedhjes. Similarisht, ka mundësi të angazhojmë një konsultant të njohur — punojmë me variantin e rëndë.
Por edhe në këtë rast, nuk do të rekomandoja ta bëni këtë, sepse, derisa nuk ka një kuptim se me çfarë po punoni dhe në cilin drejtim do të transformoni, të merrni një gjë kritike dhe ta rimbusni — nuk është një ide e mirë. Prandaj, në këtë rast ne preferojmë të punojmë me ndërfaqen, e cila nuk është kritike në rast dështimi.
Më pas do të shqyrtojmë ekipin e shërbimit. Me ata që merren me këtë shërbim, do të duhet të punojmë vazhdimisht dhe të bashkëpunojmë në një kontakt të ngushtë.
Njerëzit në ekip ndahen në dy kategori: konservatorë — jetojnë në botën e vjetër, ose thjesht nuk dinë gjë rreth DevOps, dhe inovatorë, që sjellin praktikat më moderne. Të dytët nuk e kuptojnë gjithmonë 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ë: janë prej kohësh në kompani, kuptojnë nga fillimi deri në fund, por nuk e dinë saktësisht për praktikat. Nga ana tjetër janë inovatorët, të cilët kanë dëgjuar diçka, por në kompani, me siguri, nuk punojnë për një kohë të gjatë. Me cilët është më mirë të punoni?
Me duhet të bashkëpunojmë me konservatorët në çdo rast, sepse ky është shërbimi i tyre. Do na duhet të flasim me ta, të sqarojmë specifikën e shërbimit, çfarë mund të bëjmë kështu dhe çfarë në të tjetër. Ne variojmë nga konsultimet e tyre. Sigurisht, do të na duhet t'u japim disa detyra, sepse ata e njohin shërbimin e tyre më mirë. Prandaj, është e rëndësishme me cilën ekip do të kemi kontakt në fund.
Është logjike të zgjedhim inovatorët në ekip, sepse konservatorët mund të sabotojnë punën.
Në praktikë shpesh ndodh që njerëzit konservatorë kanë përvojë të konsiderueshme, por nuk e kuptojnë si të jetojnë më tej. Ata thjesht frikësohen se pas transformimit dhe riparimit të shërbimit, do të shkarkohen për shkak të mos nevojshmërisë. Ndonjëherë, thjesht për shkak të moskuptimit të asaj që ndodh, ata sabotojnë punën.
Kam pasur një rast kur një djalë nga ekipi riparonte çdo gjë, sepse për të ishte më kritike se sa ajo që po bëjmë tani. Ne vendosim detyrën: të implementojmë këtë pjesë sot — jo, në anën tjetër të botës ka një zjarr, po shkojmë ta riparojmë atë. Është e vështirë të punosh me këta njerëz.
Njerëzit nga ekipi i konservatorëve shpesh e injorojnë detyrat, ose i vonojnë deri në momentin e fundit. Dhe nëse, zotit John Willis, bëni një gabim dhe u vendosni KPI për numrin e detyrave të përfunduar, ndërsa një pjesë për ndonjë arsye nuk është e përfshirë në KPI, ata nuk do të bëjnë asgjë. Në thelb, do të keni të drejtë, sepse atëherë ata humbin bonusin.
Me inovatorët është më e lehtë — ata janë më lojalë.. Ata kanë dëgjuar tashmë diçka, duan të shkojnë diku, prandaj do të ndihmojnë. Na duhen njerëz që janë të gatshëm të vuajnë për një kohë të parë: nëse shërbimi ndryshon, të gjitha pengesat dhe vështirësitë do t'i përjetojnë inovatorët si pionierë. Inovatorët duan gjithçka më të re dhe moderne, dhe të vuajnë.
Konservatorët mund të kthehen në besimin tuaj më vonë. Kur të tregoni se keni ndryshuar një pjesë dhe gjithçka funksionon mirë, ka shumë mundësi që ata gjithashtu do të duan ta provojnë dhe do të pranojnë besimin e ri DevOps.
Të përmbledhim. Nëse e bëjmë të gjithë transformimin në kompaninë tonë vetë, atëherë zgjedhim: një shërbim të ri, preferably një ndërfaqe të thjeshtë, në mënyrë që të mos vuajmë shumë nga prishet, dhe një ekip inovatorësh.
Nëse ka mundësi të thërrasësh një konsultant të jashtëm, në vend të një të riu — përdorim shërbimin e vjetër, për të cilin tashmë vuajmë. Njerëzit që janë angazhuar në transformim mjaft gjatë në vende të ndryshme, kanë parë raste të ndryshme dhe tashmë e dinë si të bëjnë gjërat siç duhet, dhe në cilin drejtim të shkohet.
Kush është i përfshirë?
Na nevojitet të gjejmë të gjithë ata që kanë ndonjë lidhje me shërbimin: zhvilluesit, testuesit, administratorët, sigurisht, menaxherët 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ë njihen dhe të bisedohet me ta.
Për çfarë na nevojiten ata? Që të dimë me kë të bisedojmë.Gjatë transformimit, kur ndryshon parimi tradicional i punës me shërbimin, do të ketë lëkundje gjithsesi. Për një kohë do të ketë prishje, ndërsa ne testojmë qasje të reja. Njerëzit duhet të jenë të gatshëm për këtë dhe të pranojnë.
Më pas do të duhet të ndërtojmë Hartën e Vlerës dhe pa këta njerëz nuk e ndërton dot, sepse vetëm ata bashkë e dinë plotësisht çfarë po ndodh. Një njeri nuk e di kurrë gjithçka që po ndodh me shërbimin.
Ata do të rekomandojnë njerëz për ekipin. Më vonë do të diskutojmë pse nevojitet një ekip i veçantë. Në të do të duhet të marrim njerëz nga departamentet ekzistuese. Ata që kanë lidhje me shërbimin, do të mund të rekomandojnë kolegë që mendojnë në drejtimin tonë, që mund të na ndihmojnë dhe kanë kompetencën që na nevojitet.
Më pas ne mbledhim të gjithë këta njerëz nga departamentet e ndryshme në një dhomë dhe fillojmë të ndërtojmë Hartën e Vlerës.
Ndërtojmë Hartën e Vlerës
Harta e Vlerës është një skemë ose hartë, e cila tregon rrjedhën e vlerave deri te klienti.Ky është i gjithë procesi nga ideimi i ideve deri te implementimi i tyre, duke përfshirë të gjitha fazat ndërmjetës dhe mënyrën se si vlera përfundimisht arrin te klientët tanë.
Harta e Vlerës është e nevojshme që të vizualizohet të gjithë fazat e zhvillimit,të lokalizohen problemet përmes matjeve që janë në procesin aktual dhe të fillojmë t'i eliminojmë këto probleme, dhe të vendosim objektivin fillestar.Ky është vendi ku do të fillojmë të bëjmë diçka me të vërtetë.
Metrikat
Në literaturën mbi Hartën e Vlerës janë përshkruar shumë metrikë të ndryshme, por për fillim na mjaftojnë vetëm tre.
Lead Time — vonesë/pritje — koha kur ne presim diçka. Për shembull, një testues pret derisa të lirohet ndjekja për testet, dhe gjatë kësaj kohe nuk mund të bëjë asgjë.
Koha e Shtuar e Vlerës — koha e punës së dobishme — ajo që ne kemi shpenzuar në një fazë të tillë për të krijuar vlerën përfundimtare për përdoruesin. Për shembull, testuesi e nisi testin e tij dhe filloi të kontrollojë diçka. Kjo është koha e punës së dobishme, kur ne me të vërtetë po bëjmë diçka për produktin. Kjo është ajo për të cilën klientët paguajnë — për softin e cilësisë.
%C/A — përqindja e punës së pranuar. Ne kemi një fazë — zhvillimi, faza e dytë — testimi. Sa shumë karakteristika kanë pranuar testuesit nga zhvilluesit, dhe ka këtë përqindje.
Dikur dukej kështu harta jonë.
Ajo mund të duket ndryshe në varësi të strukturës së organizatës, numrit të departamenteve dhe asaj që bëni. Por në përgjithësi, në hartë do të jenë dy faza: ideja dhe analitika. Në këtë fazë priten të dhëna, për shembull, Koha e Lead 2 javë dhe Koha e Shtuar e Vlerës 2 ditë.
Metricat përfshijnë të gjitha fazat.
Backlog — sa shumë detyra që mbetën pas kur analistët i menduan ato.
Zhvillimi — sa shumë javë zhvilluesit pritën sqarime për detyrat, ndjekjet apo pajisjet — nuk ka rëndësi, por ata po presin diçka. Për shembull, në 4 ditë ata zbatuan një karakteristikë. Këtu shfaqet metrika %C/A. Zhvilluesit morën nga Backlog vetëm 80% të detyrave. Ata mendojnë se 20% e mbetura nuk kanë një specifikim të mjaftueshëm dhe i dërguan për ripunim.
Testimi. Në diagram LT është caktuar 4 ditë. Për shembull, testuesit prisnin lirimin e ndjekjes testuese, VA 2 ditë ata me të vërtetë ndihmonin në testim, dhe %C/A = 40 %. — vetëm 40 % e kodit ose karakteristikave që zhvilluesit dërguan, testuesit i konsideruan adekuate. E gjithë e tjerra nuk iu pëlqeu për një arsye apo një tjetër.
Nuk do të ndalem në mënyrën se si për të realizuar këto matje, në fund të artikullit do të rekomandoj literaturë për të cilën mund të mësoni rreth tyre.
E vetmja gjë që do të rekomandoj — mos i besoni njerëzve që do të hartojnë një Hartë të Vlerësimit me ju. Ata paraqesin se sa kohë zgjat proceset e ndryshme, por këto vlerësime nuk janë gjithmonë të sakta, prandaj është më mirë të matni vetë.
Kemi pasur një rast kur shkuam në departamentin e Operacioneve dhe pyesnim se sa kohë do të kishte për të dorëzuar një vefeature të re në prodhim. Ata na thanë se 10 minuta, dhe ne menduam, pse erdhëm në këtë kompani? Doli se 10 minuta është koha që kërkohet nga skripti për të marrë kodin dhe për ta dërguar në server. Por para kësaj, rrelease qëndron për tri ditë në server dhe thjesht pluhuroset - në Backlog ka një detyrë që duhet të dërgohet. Kështu, përpara fazës së dorëzimit, ka një fazë pritjeje ku projekti thjesht qëndron. Po sikur ne të mos ishim shkuar me një notebook, të mos ishim kapur me sytë për një detyrë në Jira dhe të mos e kishim ndjekur atë hap pas hapi, do të mendonim se gjithçka është shkëlqyer dhe s'ka asnjë problem.
Prandaj, do të duhet që matjet t'i bëni vetë, preferohet jo vetëm një herë, për të pasur një përmbledhje të saktë të realitetit. Në varësi të Hartës së Vlerës, do të merrni vendimin se nga ku të filloni dhe çfarë të rregulloni si prioritet.
Ekipi përkohshëm
Shumë kompani që vendosin të integrojnë DevOps krijojnë ekipe, por jo ekip të përkohshëm, përkundrazi, një ekip që ekziston për disa vite. Nëse do t'i drejtoheni shërbimit DevOps, ku përshkruhen modele të ndryshme të ndërtimit të 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 midis departamenteve, për shpejtësinë dhe efikasitetin.
Nëse ekipi ekziston midis departamenteve, vetëm për të bërë diçka tjetër të veçantë, dhe ekziston gjatë për një kohë të gjatë, atëherë krijon një barrierë të panevojshme. Tani programuesi, përveçse të shkojë menjëherë tek administratori për të zgjidhur një çështje, duhet së pari të drejtohet te departamenti DevOps, dhe pastaj ai do të shkojë më tej.
Prandaj, për të filluar, është e nevojshme të krijoni një ekip të përkohshëm.. Ajo do të ekzistojë në mënyrë të përkohshme për gjysmë viti, maksimumi një vit, në varësi të detyrës së vendosur, vetëm për të eliminuar një kufizim që kemi zgjedhur. Më pas ajo do të vdesë. Nëse ne zgjedhim pikën tjetër ku na dhemb shumë, dhe kuptojmë se për të na nevojitet gjithashtu një ekip i veçantë, atëherë ne do ta krijojmë sërish. Por në 'konsolidim' ato ekipe nuk duhet të ekzistojnë - përndryshe ato thjesht do të shkatërrojnë komunikimin dhe do të marrin detyra të tjera që nuk kanë të bëjnë me asgjë, veçse për të bërë diçka. Këto detyra mund të mos kenë lidhje me DevOps dhe me transformimin. Pse nuk duhet t'ia dorëzojmë këtë detyrë departamenteve ekzistuese?
Pse nevojitet një ekip përkohësor
Konflikti me proceset aktuale. Transformimi i 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, nuk do të jetë në gjendje të provojë qasje të tjera.
Këta njerëz duhet të jetojnë sipas rregullave të tjera: të injorojnë të gjitha KPI-të e kompanisë, sepse ata përpiqen të punojnë ndryshe. Ekipet përkohësore nuk do të dorëzojnë kërkesa për të marrë server, por do të shkojnë direkt në departamentin që merret me ta, me kërkesën për t'u dhënë asaj të parës atë që iu nevojitet, sepse kjo është një detyrë prioritare dhe sepse përpiqen të jetojnë ndryshe. Ekipi ka një konflikt të plotë me të gjitha proceset aktuale. Që metodat ekzistuese të punës të mos i pengojnë tani, dhe ata të mos pengojnë të tjerët, ne izolojmë këta njerëz, duke formuar një ekip të veçantë.
Shmangia e burokracisë në eksperimente. Në ekipet përkohësore nuk ka burokraci, ata nuk plotësojnë raporte për orët e punës, ata nuk përgjigjen para menaxherëve. Ky është një botë krejtësisht e ndarë, ku njerëzit jetojnë dhe mendojnë ndryshe, dhe merren me gjëra krejtësisht të tjera. Nuk duhet t'i pengojmë ata një herë tjetër.
Puna e pandërprerë mbi shërbimin. Në pikën e parë ne zgjodhëm diçka mbi të cilën do të eksperimentojmë. Eksperimentet dhe kërkimi i mënyrave për të punuar më mirë është i mirë, por ne duam të prodhojmë gjithashtu veçori. Nëse e gjithë ekipi merret me transformimin në vend të veçorive, atëherë ne do të fillojmë të humbasim të ardhurat, gabimet do të qëndrojnë për një kohë të gjatë - kjo nuk është ajo që na nevojitet. Krijimi i një ekipi të përkohshëm lejon të eksperimentosh pa ndalur punën mbi produktin.
Mos ndiheni në punë,. Kjo sërish është për produktin. Duhet shumë kohë që ekipi të provojë mjete të tjera e të tjera. Që njerëzit të mësojnë mjetet, të fillojnë t'i zbatojnë dhe t'i përdorin siç duhet, do të marrë të paktën gjashtë muaj. Nëse ata merrejnë edhe me produktin — gjashtë muaj do të zgjaten shumë. Nëse njerëzit punojnë me produktin, ata përsëri po punojnë me proceset e vjetra — kjo nuk na nevojitet.
Prandaj nga departamentet e ndryshme ne veçojmë njerëz në një ekip të veçantë që do të merret me transformimin e shërbimit. Si rezultat, shërbimi funksionon, vazhdon të zhvillohet, dhe në të njëjtën kohë ne realizojmë disa eksperimente mbi të.
Ekipi temporal merret vetëm me transformimin DevOps — eliminimin e atij kufizimi që kemi gjetur, dhe asgjë më shumë.
Ekipi përbëhet nga njerëz universale,. Kjo do të thotë se ne nuk kemi marrë vetëm zhvillues. Nuk erdhëm në shërbim dhe nuk e morëm half-e ekipit — jo, ne morëm njerëz nga departamente të ndryshme,. Disa pika më parë ne gjetëm departamente dhe punonjës të ndryshëm që kanë lidhje me shërbimin e transformuar. Nga ata ne ndërtojmë ekipin, sepse ai duhet të jetë universal — ne do të ndryshojmë procesin e testimit, procesin e zhvillimit dhe procesin e shërbimit. Duhet kompetenca të ndryshme.
Për zakonisht, ne marrim një zhvillues, një testues dhe një inxhinier — secilin nga një dhe së bashku me ta inventarizojmë një zgjidhje, e cila lejon të jetojmë ndryshe.
Preferohet që këta njerëz të kenë autoritet në organizatë,. Mund të nevojitet të marrësh një konservator, ndonëse nuk dëshirohet. Nëse kemi një kompani të madhe, nuk të gjithë do të besojnë në projektin tonë, dhe ndokush mund të futë pengesa, p.sh., të mos alokojë një stand. Aty do të nevojitet "autoritete" — një njeri i respektuar me përvojë të madhe, i cili ka fituar një marrëdhënie të mirë me kolegët. Autoriteti i punonjësit në ekip do të thjeshtojë detyrën dhe punën e ekipit temporal. Njerëzit do të mendojnë:
— Ah, ky është ai djalë i shkëlqyer, që të gjithë e njohim dhe e duam, që është angazhuar — duket se në DevOps ka diçka që meritohet të shikohet!
Vendosim qëllimin,
Mblodhëm njerëzit, zgjodhëm shërbimin, shikëm kufizimet, përcaktuam cilët njerëz do të ndikojmë. Tani duhet të vendosim një qëllim dhe ai duhet të jetë tërësisht sipër SMART, — ashtu siç na pëlqen.
Specifik — specifike.
Matër — e matshme. Ky është një pikë shumë e rëndësishme e SMART. Nëse nuk mund të matni diçka, atëherë nuk mund ta ndryshoni dhe nuk kuptoni se çfarë dhe si e keni bërë më mirë ose më keq.
Arritshëm — e arritshme. Bëni një përshtatje për specifikën tuaj. Nëse jeni një kompani enterprise me një histori të gjatë dhe një ngarkesë të madhe detyrash, e cila lëshon një version produkti çdo vit, atëherë nuk do të mund të arrini lëshimin e versioneve të reja të produktit çdo orë brenda gjashtë muajve. Kështu nuk funksionon. Prandaj, vendosni një qëllim të arritshëm brenda një kohe të pranueshme.
Relevante — e rëndësishme. Eliminojmë vetëm atë kufizim që në të vërtetë synon qëllimet tona aktuale.
E kufizuar në kohë — e kufizuar nga koha. Nëse nuk ka afat — ekipi do të merret me çfarëdo: provuar 15 teknologji në vend të 3, shkruar raporte të mëdha, kryer kërkime të padobishme, përmirësuar realizimin e tyre deri në shkëlqim, kur qëllimi është arritur tashmë.
Ne e marrim qëllimin pikërisht me anë të Value Stream Map — përsëri mblidhni gjithë njerëzit dhe vizatoni. Por tani, mbi baza të Value Stream Map të mëparshme, vizatojmë atë që duam të arrijmë.
Identifikojmë një kufizim, që do të eliminojmë tani — me atë do të merret ekipi. Për shembull, kam marrë pritjen nga lëshimi i gatshëm deri në implementimin në prodhim — kjo është kufizimi më i zakonshëm për të cilin njerëzit i drejtohen konsulentëve.
Në bazë të kësaj vendosim detyrën: duam që pritja mes lëshimit të gatshëm dhe daljes në treg të jetë maksimum një orë.
Shembuj detyrash.
- Të shkurtojmë Lead Time të testimit nga 4 ditë në 1 orë.
- Të shkurtojmë Value Added Time për testimin nga 2 ditë në 3 orë.
- Të shkurtojmë Lead Time të implementimit nga 5 orë në 10 minuta.
- Të rrisim C/A nga 50% në 95%, pra të rrisim numrin e veçorive që miratojnë testuesit, në fjalë të tjera, të përmirësojmë cilësinë e punës së zhvilluesve.
Shembujt e detyrave nuk janë marrë në ajër — ato bazohen në matjet që kemi bërë kur zhvillonim Value Stream Map.
Ne vendosim një detyrë të ngjashme për ekipin tonë dhe një kufizim në kohë. Në varësi të sa mirë shkojnë gjërat në kompaninë tuaj, vendosni afate të ndryshme. Në përgjithësi, për të eliminuar kufizimin, nëse njerëzit e bëjnë këtë për herë të parë dhe ende nuk e dinë se me cilat teknologji dhe si konkretisht do të zgjidhin problemin, zakonisht nevojiten gjashtë muaj.
Planifikim i shkurtër
Pra ndaj, ekipi ynë është krijuar, ai 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, jo 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ë ekipi mblidhet në fillim të çdo jave, skicon se çfarë do të bëjë secili. Pas një jave shënojmë: çfarë është bërë dhe çfarë jo, nëse jo, pse, dhe mendojmë se çfarë do të bëjmë këtu e tutje.
Sprintet lejojnë të korrigjojmë kursin në kohë.
Një ose dy javë provuam diçka: teknologji, qasje, mënyra pune, pas kësaj matni përsëri dhe shikoni — a është përmirësuar apo përkeqësuar me këtë qasje? Nëse është përkeqësuar, atëherë po shkojmë në drejtimin e gabuar, duhet të korrigjojmë kursin: vendosim një detyrë tjetër, marrim një teknologji tjetër apo bëjmë diçka tjetër. Sprintet e shkurtër në 1-2 javë lejojnë të manovrosh dhe të largohemi nga vendimet e këqija në kohë.
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 fqinjë. Në një botë ideale është e dëshirueshme që kjo të arrijë në fakt tek të gjithë njerëzit në kompani.
Pse? Nëse duam të transformojmë jo një pjesë të kompanisë, të eliminojmë një kufizim, por gjithçka, që kompania të bëhet e shkathët, kodi të fluturojë shpejt te klienti, dhe asgjë të mos prishet, është e nevojshme që të gjithë të jenë lojalë ndaj idesë së DevOps. Nuk do të jeni në gjendje të aplikoni qasjen në shërbimet dhe ekipet që janë kategorikisht kundër.
Për të krijuar lojalitet, duhet të tregojmë të gjithëve se kemi provuar këtë — ne kemi rezultat, provoni edhe ju! Kjo do të rrisë interesin dhe lojalitetin ndaj asaj që bëjmë, njerëzit do të fillojnë të provojnë diçka duke e bërë këtë tani. Siç tregon praktika, kur ne tregojmë se çfarë kemi provuar dhe çfarë kemi arritur, ekipet e tjera fillojnë të pyesin se si dhe çfarë kemi bërë. Ata shikojnë zbatimet, kodin, dokumentacionin, afrohen me pyetje dhe përpiqen të ndryshojnë diçka te vetja e tyre.
Të folurit për atë që keni arritur është e rëndësishme. Kështu do ta bindni të kaloni në kampin tuaj të konservatorëve, që do të donin të bënin gjithçka si më parë, dhe t'i transformoni ata në inovatorë.
Përveç kësaj
Zgjidhim shërbimin, si një pikë referimi — vendi ku do të fillojmë ndryshimet në kompani. Identifikojmë të gjithë ata që kanë ndonjë lidhje me shërbimin dhe së bashku me ta ndërtojmë Hartën e Vlerës, masim dhe shikojmë ku dhe cilat janë kufizimet.
Krijojmë një ekip të ri përkohësisht, i cili do të zgjidhë detyrën e caktuar. Bazuar në masat dhe Hartën e Vlerës vizatojmë një hartë të re, ku identifikojmë kufizimin që do të zgjidhim. Bazuar në këtë kufizim caktrojmë 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 me kohë të kufizuar.
Përse rrisim procesin, deri sa të transformojmë të gjithë shërbimet tona në formën e kërkuar dhe të eliminojmë të gjitha kufizimet.
Bonusi. Materiale të dobishme
Për ata që kanë vendosur të merren me DevOps vetë.
Projekti "Feniks"
Titulli origjinal — "The Phoenix Project: A Novel about It, Devops, and Helping Your Business Win". Ky është një roman mbi DevOps — historia se si një punonjës u bë shefi i një departamenti që gjithmonë ishte në flakë. Shefi i ri mori një detyrë:
— Ke disa vite për të gjithë ta ndreqësh, në mënyrë që ne të mund ta dërgojmë produktin tonë klientëve tanë shpejt dhe me efikasitet.
"Projekti 'Feniks'. Një roman se si DevOps ndryshon jetën për mirë" — një libër për të gjithë drejtorët, sepse këta njerëz marrin vendime për atë që ndodh në kompani. Nëse je inxhinier apo programues dhe dëshiron që kompanisë tënde t'i fillojë një lëvizje dhe transformim — blije librin dhe ia jep drejtorisë. Ky roman shpjegon gjithçka dhe lexohet shpejt dhe lehtë.
Udhëzuesi për DevOps
Libri është pak më i ndërlikuar. Doli para disa vitesh në anglisht me titullin "The DevOps Handbook How to create world‑class agility, reliability, and security in Technology organizations", por tani është në shqip. Ky është një manual praktik: si të kryesh matje, çfarë është Harta e Vlerës dhe përse është e nevojshme, ku duhet të lëvizësh, në cilin rend. Libri është pikërisht për ata që duan ta bëjnë gjithçka vetë. E rëndësishme, ka shembuj të përvojave të kompanive të tjera.
Për shembull, aty flitet për mënyrën se si një kompani ndihmoi në ndërtimin e një Mape të Rrugës së Vlerës dhe kuptoi se kufizimi nuk ishte në produkt, por në faktin që kasieri shkonte nga dyqani në zyrën përballë për të përdorur këtë produkt. Në vend që të zgjidhnin problemin me programin, ata thjesht i blenë punonjësve të tyre tableta, dhe tani askush nuk shkon askund, ndërsa të gjitha veprimet kryhen në vendin e punës. Përfundim: Mapa e Rrugës së Vlerës mund të aplikohet jo vetëm në softuer, por gjithashtu në të gjitha proceset në organizatë.
Accelerate
Titulli 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 momentin vetëm në anglisht dhe është mbi studimet. Autorët — Nicole Forsgren, Jez Humble dhe Gene Kim — kanë aplikuar praktika të ndryshme në kompani të ndryshme për shumë vite dhe kanë hulumtuar se cilat praktika, si dhe për çfarë ndikojnë.
Në kapitullin e dytë, i dedikuar masave, përmenden Mapa e Rrugës së Vlerës, metrika që përmenda, dhe shumë të tjera, si dhe përshkruhet detalshëm procesi i matjeve. Autorët bëjnë matje përmes sondazheve dhe monitorimit të vetëpërmbushjes së detyrave. Flitet në detaje se cilat metrika janë të mira për t'u matur, cilat nuk duhet, gabimet njerëzore në matje. Nëse keni probleme me matjet, drejtohuni në kapitullin e dytë të librit «Accelerate». Nëse në ekipin tuaj ka shumë praktika, por nuk është e qartë se cilat praktika të aplikoni tani, cilat më vonë, cilat janë reale, e cilat jo — lexoni, libra përmban gjithçka.
Transformimi është një çështje në kufirin e DevOps dhe menaxhimit. Diku në të njëjtin tregun e ndërveprimit të zhvillimit, operacioneve dhe testimit ndodhen tema që ne përpiqemi t'i diskutojmë në , integrimi i ngjashëm nevojitet gjithashtu për të krijuar një produkt cilësor - tema kryesore . Menaxhimi në festival paraqiten — do të thotë që ide të ndryshimeve do të shkojnë aty. Bashkohuni më 27 dhe 28 maj, do të integrohemi dhe transformohemi.
Burimi: habr.com
