{"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\/sq\/blog\/administrirovanie\/kak-nachat-devops-transformatsiyu","title":{"rendered":"Si e filluar transformimin DevOps","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

N\u00ebse nuk e kuptoni se \u00e7far\u00eb \u00ebsht\u00eb DevOps, ja nj\u00eb p\u00ebrmbledhje e shkurt\u00ebr. DevOps \u00ebsht\u00eb nj\u00eb grup praktikash q\u00eb redukojn\u00eb frik\u00ebrat e inxhinier\u00ebve<\/strong> dhe zvog\u00eblojn\u00eb numrin e d\u00ebshtimeve n\u00eb prodhimin e softuerit. N\u00eb p\u00ebrgjith\u00ebsi, ato shkurtojn\u00eb koh\u00ebn e daljes n\u00eb treg<\/strong> \u2014 periudha nga ideja deri te dor\u00ebzimi i produktit p\u00ebrfundimtar te klient\u00ebt, e cila lejon realizimin e shpejt\u00eb t\u00eb eksperimentimeve biznesore<\/strong>.<\/p>\n

Si t\u00eb filloni transformimin DevOps? N\u00ebse flasim shkurt: zgjedhim sh\u00ebrbimin me t\u00eb cilin do t\u00eb fillojm\u00eb procesin, identifikojm\u00eb ata q\u00eb kan\u00eb lidhje me sh\u00ebrbimin, nd\u00ebrtuam Hart\u00ebn e Vler\u00ebs, krijojm\u00eb nj\u00eb ekip p\u00ebrkoh\u00ebshem q\u00eb do t\u00eb merret me transformimin p\u00ebr nj\u00eb koh\u00eb dhe i japim atij nj\u00eb detyr\u00eb. E p\u00ebrs\u00ebrisim ciklin sa her\u00eb q\u00eb nevojitet.<\/p>\n

\"Si<\/p>\n

Nj\u00eb plan t\u00eb detajuar t\u00eb transformimit DevOps me shembuj dhe udh\u00ebzime posht\u00eb \u2014 n\u00eb transkript raportit<\/a><\/noindex> Andrei Aleksandrov<\/b> \u2014 inxhinier n\u00eb kompanin\u00eb Express42, e cila ofron konsultime p\u00ebr zhvillimin e DevOps, duke e p\u00ebrshpejtuar k\u00ebt\u00eb proces, pasi ka nd\u00ebrtuar tashm\u00eb hart\u00ebn e gur\u00ebve t\u00eb sikletit. N\u00ebse ju duket se transformimi nuk \u00ebsht\u00eb i nevojsh\u00ebm p\u00ebr ju, ose n\u00ebse keni nj\u00eb specifik\u00eb t\u00eb till\u00eb q\u00eb praktikat DevOps nuk p\u00ebrshtaten, \u2014 p\u00ebrdorni raportin si nj\u00eb udh\u00ebzues p\u00ebr gjetjen dhe eliminimin e pengesave.
\n<\/a><\/noindex>
\nN\u00ebse ju shqet\u00ebson \u00e7\u00ebshtja e transformimit DevOps, at\u00ebher\u00eb ju keni nj\u00eb kompani t\u00eb madhe, dhe duhet t\u00eb filloni ngadal\u00eb t\u00eb shkall\u00ebzoni k\u00ebt\u00eb proces n\u00eb t\u00eb gjith\u00eb struktur\u00ebn. Deri sa t\u00eb ket\u00eb nevoj\u00eb p\u00ebr t\u00eb transformuar ekipin ose p\u00ebr t\u00eb eliminuar ndonj\u00eb kufizim, algoritmi m\u00eb posht\u00eb mund t\u00eb p\u00ebrs\u00ebritet.<\/p>\n

Zgjedhja e sh\u00ebrbimit<\/h2>\n

\nPlani \u00ebsht\u00eb hartuar, le t\u00eb fillojm\u00eb me hapin e par\u00eb \u2014 zgjedhjen e sh\u00ebrbimit. Kriteri i par\u00eb \u2014 jet\u00ebgjat\u00ebsia<\/strong>: ka sh\u00ebrbime t\u00eb vjetra \u2014 legacy, dhe t\u00eb reja. Mund t\u00eb filloni me t\u00eb dyja.<\/p>\n

T\u00eb zgjedh\u00ebsh nj\u00eb sh\u00ebrbim t\u00eb ri \u00ebsht\u00eb logjik\u00eb<\/strong>. Ai \u00ebsht\u00eb i ri, nuk ka ende nj\u00eb proces t\u00eb vendosur t\u00eb pun\u00ebs n\u00eb ekipin q\u00eb merret me t\u00eb. P\u00ebrreth tij nuk ka nj\u00eb mal borxhesh teknike, nuk \u00ebsht\u00eb e nevojshme ta riparoni gjithmon\u00eb. Mund t\u00eb b\u00ebjm\u00eb me t\u00eb gjith\u00e7ka q\u00eb duam.<\/p>\n

N\u00eb rastin e nj\u00eb sh\u00ebrbimi t\u00eb vjet\u00ebr ka probleme q\u00eb lidhen me faktin se ndryshimi gjithmon\u00eb \u00ebsht\u00eb i v\u00ebshtir\u00eb<\/strong>. Atje ka nj\u00eb grup t\u00eb caktuar kufizimesh serioze, por ndoshta jan\u00eb njer\u00ebz q\u00eb jan\u00eb gati ta riformulojn\u00eb gjith\u00e7ka \u2014 ata jan\u00eb lodhur dhe duan t\u00eb b\u00ebjn\u00eb di\u00e7ka ndryshe sepse ndihen t\u00eb dhimbsh\u00ebm.<\/p>\n

Puna me nj\u00eb sh\u00ebrbim t\u00eb vjet\u00ebr krijon nj\u00eb precedens t\u00eb fuqish\u00ebm<\/strong> n\u00eb kompanin\u00eb tuaj \u2013 ka di\u00e7ka p\u00ebr t'u ndryshuar. N\u00ebse keni nd\u00ebrruar sh\u00ebrbimin e ri, ai funksionon me 100 her\u00eb n\u00eb or\u00eb, dhe gjith\u00e7ka \u00ebsht\u00eb mir\u00eb, at\u00ebher\u00eb njer\u00ebzit n\u00eb kompanin\u00eb tuaj mund t\u00eb thon\u00eb:<\/p>\n

\u2014 Ky \u00ebsht\u00eb sh\u00ebrbimi i ri! Atje gjith\u00e7ka ishte e thjesht\u00eb, provoni t\u00eb b\u00ebni di\u00e7ka me mjetin ton\u00eb t\u00eb vjet\u00ebr.<\/em><\/p>\n

Ka sens t\u00eb merrni sh\u00ebrbimin legacy n\u00eb transformim, kur e b\u00ebni at\u00eb me dik\u00eb, p\u00ebr shembull, n\u00ebse keni ftuar nj\u00eb k\u00ebshilltar t\u00eb jasht\u00ebm. T\u00eb jemi t\u00eb sinqert\u00eb, transformimi do t\u00eb tund\u00eb gjith\u00e7ka q\u00eb \u00ebsht\u00eb e mundur.<\/strong>. Po eksperimentoni dhe nuk e dini se ku do t\u00eb shkoni, cilat teknologji dhe p\u00ebr \u00e7far\u00eb do t'i p\u00ebrdorni, ku dhe cilat \u00ebsht\u00eb problemet n\u00eb procese q\u00eb do t\u00eb shfaqen. Prandaj, m\u00eb e leht\u00eb \u00ebsht\u00eb t\u00eb nd\u00ebrroni t\u00eb rejat.<\/p>\n

N\u00ebse gjith\u00e7ka e b\u00ebni vet\u00eb dhe n\u00eb kompani nuk ka ekspertiz\u00eb t\u00eb r\u00ebnd\u00ebsishme \u2013 merrni sh\u00ebrbimin e ri. N\u00ebse njihni nj\u00eb k\u00ebshilltar t\u00eb jasht\u00ebm dhe keni mjete \u2013 zgjidhni at\u00eb t\u00eb vjet\u00ebr.<\/p><\/blockquote>\n

\nKa sh\u00ebrbime q\u00eb jan\u00eb thjesht nj\u00eb nd\u00ebrfaqe p\u00ebr p\u00ebrdoruesit, p\u00ebr shembull, nj\u00eb faqe e thjesht\u00eb ose nj\u00eb aplikacion mobil. Por ka edhe gj\u00ebra serioze si sistemi i faturimit. N\u00ebse di\u00e7ka shkon keq me faturimin \u2013 do t\u00eb jet\u00eb e v\u00ebshtir\u00eb t\u00eb merresh me t\u00eb. K\u00ebtu gjithashtu kemi nj\u00eb zgjedhje.<\/p>\n

Ne punojm\u00eb ose me sh\u00ebrbime kritike<\/strong>, por t\u00eb cilin jemi duke vuajtur, ai krijon kufizime, ose punojm\u00eb me nd\u00ebrfaqen<\/strong>. Ky \u00ebsht\u00eb kriteri i dyt\u00eb p\u00ebr zgjedhjen. Po ashtu, ka mund\u00ebsi t\u00eb angazhojm\u00eb nj\u00eb konsulent t\u00eb kualifikuar \u2014 punojm\u00eb me variantin e r\u00ebnd\u00eb.<\/p>\n

Por edhe n\u00eb k\u00ebt\u00eb rast, un\u00eb nuk do ta rekomandoja k\u00ebt\u00eb, sepse, derisa nuk ka nj\u00eb kuptim se me \u00e7far\u00eb po punojm\u00eb dhe n\u00eb cil\u00ebn drejtim duhet t\u00eb transformohemi, t\u00eb marrim nj\u00eb gj\u00eb kritike dhe ta rregullojm\u00eb \u2014 nuk \u00ebsht\u00eb nj\u00eb ide shum\u00eb e mir\u00eb. Prandaj, n\u00eb k\u00ebt\u00eb rast preferojm\u00eb t\u00eb punojm\u00eb me nd\u00ebrfaqen, d\u00ebmtimi i s\u00eb cil\u00ebs nuk \u00ebsht\u00eb kritik.<\/p>\n

M\u00eb pas do t\u00eb shqyrtojm\u00eb ekipin e sh\u00ebrbimit<\/b>. Me ata q\u00eb merren me k\u00ebt\u00eb sh\u00ebrbim, do t\u00eb na duhet t\u00eb punojm\u00eb dhe nd\u00ebrveprojm\u00eb vazhdimisht n\u00eb kontakt t\u00eb ngusht\u00eb.<\/p>\n

Njer\u00ebzit n\u00eb ekip p\u00ebrfshihen n\u00eb dy kategori: konservator\u00eb<\/strong> \u2014 jetojn\u00eb n\u00eb bot\u00ebn e vjet\u00ebr, ose thjesht nuk din\u00eb asgj\u00eb rreth DevOps, dhe inovator\u00eb<\/strong>, q\u00eb sjellin t\u00eb gjitha praktikat moderne. T\u00eb dyt\u00ebt nuk jan\u00eb gjithmon\u00eb t\u00eb informuar p\u00ebr tem\u00ebn, por t\u00eb pakt\u00ebn jan\u00eb t\u00eb gatsh\u00ebm p\u00ebr t\u00eb.<\/p>\n

Nga nj\u00ebra an\u00eb, konservator\u00ebt jan\u00eb njer\u00ebz me p\u00ebrvoj\u00eb: kan\u00eb qen\u00eb n\u00eb kompani p\u00ebr nj\u00eb koh\u00eb t\u00eb gjat\u00eb, e din\u00eb gjith\u00e7ka p\u00ebr t\u00eb, por nuk kan\u00eb informacion p\u00ebr praktikat. Nga ana tjet\u00ebr jan\u00eb inovator\u00ebt, t\u00eb cil\u00ebt kan\u00eb d\u00ebgjuar di\u00e7ka, por sigurisht q\u00eb kan\u00eb punuar n\u00eb kompani p\u00ebr nj\u00eb koh\u00eb t\u00eb shkurt\u00ebr. Me k\u00eb \u00ebsht\u00eb m\u00eb mir\u00eb t\u00eb punosh?<\/p>\n

Me konservator\u00ebt do t\u00eb duhet t\u00eb bashk\u00ebpunojm\u00eb n\u00eb \u00e7do rast, sepse \u00ebsht\u00eb sh\u00ebrbimi i tyre. Do t\u00eb kemi nevoj\u00eb t\u00eb komunikojm\u00eb me ta, t\u00eb kuptojm\u00eb specifikat e sh\u00ebrbimit, \u00e7far\u00eb mund t\u00eb b\u00ebhet k\u00ebshtu dhe \u00e7far\u00eb ndryshe. Jemi t\u00eb varur nga k\u00ebshillat e tyre. Me siguri do t\u00eb duhet t'u ngarkojm\u00eb atyre di\u00e7ka, sepse ata e njohin sh\u00ebrbimin m\u00eb mir\u00eb. Prandaj \u00ebsht\u00eb e r\u00ebnd\u00ebsishme, me cilin ekip do t\u00eb kemi kontakt n\u00eb fund.<\/p>\n

\u00cbsht\u00eb logjike t\u00eb zgjidhni innovator\u00ebt p\u00ebr ekipin, sepse konservator\u00ebt mund t\u00eb sabotojn\u00eb pun\u00ebn.\n<\/p><\/blockquote>\n

\nN\u00eb praktik\u00eb, shpesh ndodh q\u00eb njer\u00ebzit konservator\u00eb kan\u00eb p\u00ebrvoj\u00eb t\u00eb konsiderueshme, por nuk kuptojn\u00eb si t\u00eb avancojn\u00eb m\u00eb tej. Ata thjesht kan\u00eb frik\u00eb se pas transformimit dhe ristrukturimit t\u00eb sh\u00ebrbimit, do t\u00eb humbasin vendin e pun\u00ebs. N sometimes thjesht p\u00ebr shkak t\u00eb moskuptimit t\u00eb asaj q\u00eb ndodh, ata sabotojn\u00eb pun\u00ebn.<\/p>\n

Kam kam pas nj\u00eb rast, kur nj\u00eb djal\u00eb nga ekipi riparoi gjith\u00e7ka, sepse kjo supozohej t\u00eb ishte m\u00eb e r\u00ebnd\u00ebsishme sesa ajo q\u00eb po b\u00ebjm\u00eb tani. Ne vendosim nj\u00eb detyr\u00eb: realizojm\u00eb k\u00ebt\u00eb pjes\u00eb sot \u2014 jo, n\u00eb an\u00ebn tjet\u00ebr t\u00eb bot\u00ebs ka nj\u00eb zjarr, dhe shkojm\u00eb ta riparojm\u00eb. Me njer\u00ebz t\u00eb till\u00eb \u00ebsht\u00eb e v\u00ebshtir\u00eb t\u00eb punosh.<\/p>\n

Njer\u00ebzit nga ekipi i konservator\u00ebve shpesh i injorojn\u00eb detyrat, ose i shtyjn\u00eb deri n\u00eb minut\u00ebn e fundit. Dhe n\u00ebse, Per\u00ebndia e ruajtt\u00eb, b\u00ebni nj\u00eb gabim dhe u jepni KPI p\u00ebr numrin e detyrave t\u00eb p\u00ebrfunduar, dhe ndonj\u00eb pjes\u00eb p\u00ebr arsye t\u00eb panjohura nuk p\u00ebrfshihet n\u00eb KPI, ata nuk do t\u00eb b\u00ebjn\u00eb asgj\u00eb. N\u00eb thelb, do t\u00eb ken\u00eb t\u00eb drejt\u00eb, sepse ata do t\u00eb humbasin bonusin e tyre.<\/p>\n

Me inovator\u00ebt \u00ebsht\u00eb m\u00eb e leht\u00eb \u2014 ata jan\u00eb m\u00eb lojal\u00eb.<\/strong>Ata tashm\u00eb kan\u00eb d\u00ebgjuar di\u00e7ka, duan t\u00eb shkojn\u00eb diku, prandaj do t\u00eb ndihmojn\u00eb. Na duhen njer\u00ebz q\u00eb jan\u00eb t\u00eb gatsh\u00ebm t\u00eb vuajn\u00eb n\u00eb fillim: n\u00ebse sh\u00ebrbimi ndryshon, inovator\u00ebt do t\u00eb p\u00ebrballen me t\u00eb gjith\u00eb pengesat dhe problemet si pionier\u00eb. Inovator\u00ebt duan gjith\u00e7ka t\u00eb re dhe n\u00eb mod\u00eb, dhe t\u00eb vuajn\u00eb.<\/p>\n

Konservator\u00ebt mund t\u00eb b\u00ebhen besimtar\u00eb m\u00eb von\u00eb. Kur t\u00eb tregoni se keni ndryshuar nj\u00eb pjes\u00eb dhe gjith\u00e7ka punon mir\u00eb, \u00ebsht\u00eb e sigurt q\u00eb ata gjithashtu do t\u00eb duan ta provojn\u00eb dhe do t\u00eb pranojn\u00eb fen\u00eb e re DevOps.<\/p>\n

\"Si
\n<\/p>\n

Le t\u00eb p\u00ebrmbledhim. N\u00ebse e b\u00ebjm\u00eb t\u00eb gjith\u00eb transformimin brenda kompanis\u00eb son\u00eb, at\u00ebher\u00eb zgjedhim: nj\u00eb sh\u00ebrbim t\u00eb ri, me sa m\u00eb shum\u00eb p\u00ebrpar\u00ebsi nj\u00eb nd\u00ebrfaqe t\u00eb thjesht\u00eb, n\u00eb m\u00ebnyr\u00eb q\u00eb t\u00eb mos vuajm\u00eb shum\u00eb nga d\u00ebshtimi i tij, dhe nj\u00eb ekip inovator\u00ebsh.<\/p><\/blockquote>\n

\nN\u00ebse kemi mund\u00ebsi t\u00eb ftojm\u00eb nj\u00eb k\u00ebshilltar t\u00eb jasht\u00ebm, n\u00eb vend t\u00eb nj\u00eb sh\u00ebrbimi t\u00eb ri, marrim sh\u00ebrbimin e vjet\u00ebr, p\u00ebr shkak t\u00eb t\u00eb cilit vuajm\u00eb tashm\u00eb. Njer\u00ebzit q\u00eb jan\u00eb angazhuar n\u00eb transformim p\u00ebr nj\u00eb koh\u00eb t\u00eb gjat\u00eb n\u00eb kompani t\u00eb ndryshme, kan\u00eb par\u00eb raste t\u00eb ndryshme dhe tashm\u00eb e kuptojn\u00eb se si t\u00eb b\u00ebjn\u00eb gj\u00ebrat si duhet dhe n\u00eb cilin drejtim duhet t\u00eb shkojn\u00eb.<\/p>\n

Kush \u00ebsht\u00eb i p\u00ebrfshir\u00eb?<\/h2>\n

\nNa duhet t\u00eb gjejm\u00eb t\u00eb gjith\u00eb ata q\u00eb kan\u00eb ndonj\u00eb lidhje me sh\u00ebrbimin: zhvillues, testues, administrues, siguri, menaxher\u00eb dhe, ndoshta, Product Owners. Megjith\u00ebse Product Owners nuk jan\u00eb teknik\u00eb, ata kan\u00eb lidhje me sh\u00ebrbimin: marrin vendime, vendosin detyra.<\/p>\n

\"Si
\n<\/p>\n

T\u00eb gjith\u00eb ata q\u00eb marrin ndonj\u00eb vendim dhe ndikojn\u00eb n\u00eb at\u00eb q\u00eb ndodh me sh\u00ebrbimin, duhet t\u00eb gjenden, t\u00eb njihemi dhe t\u00eb bisedojm\u00eb.<\/p><\/blockquote>\n

\nP\u00ebr \u00e7far\u00eb na nevojiten? P\u00ebr t\u00eb ditur me k\u00eb t\u00eb negociojm\u00eb.<\/strong>. Gjat\u00eb transformimit, kur ndryshon principi i zakonsh\u00ebm i pun\u00ebs me sh\u00ebrbimin, do t\u00eb ket\u00eb ende tronditje. P\u00ebr nj\u00eb koh\u00eb, do t\u00eb ket\u00eb devijime derisa t\u00eb testojm\u00eb qasje t\u00eb reja. Njer\u00ebzit duhet t\u00eb jen\u00eb t\u00eb gatsh\u00ebm p\u00ebr k\u00ebt\u00eb dhe ta pranojn\u00eb at\u00eb.<\/p>\n

Pastaj do t\u00eb duhet t\u00eb nd\u00ebrtojm\u00eb nj\u00eb Hart\u00eb Vlerash dhe pa k\u00ebta njer\u00ebz nuk do ta nd\u00ebrtosh, sepse vet\u00ebm ata s\u00eb bashku e din\u00eb plot\u00ebsisht imazhin e asaj q\u00eb po ndodh. Nj\u00eb person kurr\u00eb nuk e di gjith\u00e7ka q\u00eb ndodh me sh\u00ebrbimin.<\/p>\n

Ata do t\u00eb rekomandojn\u00eb njer\u00ebz n\u00eb ekip. M\u00eb von\u00eb do t\u00eb diskutojm\u00eb pse nevojitet nj\u00eb ekip i ve\u00e7ant\u00eb. Do t\u00eb duhet t\u00eb marrim njer\u00ebz nga departamentet ekzistuese. Ata q\u00eb kan\u00eb lidhje me sh\u00ebrbimin, mund t\u00eb rekomandojn\u00eb koleg\u00eb q\u00eb mendojn\u00eb si ne dhe q\u00eb mund t\u00eb na ndihmojn\u00eb dhe kan\u00eb kompetenc\u00eb n\u00eb at\u00eb q\u00eb na nevojitet.<\/p>\n

Pastaj mbledhim t\u00eb gjith\u00eb k\u00ebta njer\u00ebz nga departamente t\u00eb ndryshme n\u00eb nj\u00eb dhom\u00eb dhe fillojm\u00eb t\u00eb nd\u00ebrtojm\u00eb Hart\u00ebn e Vlerave.<\/p>\n

Nd\u00ebrtojm\u00eb Hart\u00ebn e Vlerave<\/h2>\n

\nHarta e Vlerave \u00ebsht\u00eb nj\u00eb skem\u00eb ose hart\u00eb q\u00eb tregon rrjedh\u00ebn e vlerave deri te klienti<\/strong>. Ky \u00ebsht\u00eb procesi i plot\u00eb nga ideimi deri n\u00eb zbatimin e saj, duke p\u00ebrfshir\u00eb t\u00eb gjitha etapet nd\u00ebrmjet dhe si vlera p\u00ebrfundimisht arrin te klient\u00ebt tan\u00eb.<\/p>\n

Harta e Vlerave \u00ebsht\u00eb e nevojshme p\u00ebr visualizoni t\u00eb gjitha fazat e zhvillimit<\/strong>, lokalizoni problemet p\u00ebrmes matjeve q\u00eb jan\u00eb n\u00eb procesin aktual dhe filloni t'i zgjidhni k\u00ebto probleme, dhe vendosni nj\u00eb q\u00ebllim fillestar<\/strong>. Ky \u00ebsht\u00eb vendi ku do t\u00eb fillojm\u00eb t\u00eb b\u00ebjm\u00eb di\u00e7ka reale.<\/p>\n

Metricat<\/h3>\n

\nN\u00eb literatur\u00ebn mbi Hart\u00ebn e Vler\u00ebs jan\u00eb p\u00ebrshkruar shum\u00eb metrika t\u00eb ndryshme, por p\u00ebr fillim na mjafton vet\u00ebm t\u00eb tri.<\/p>\n

Koha e Prerjes \u2014 vonesa\/pritur<\/strong> \u2014 koha kur presim di\u00e7ka. P\u00ebr shembull, testi i pritjes s\u00eb nj\u00eb vendi p\u00ebr teste, dhe n\u00eb k\u00ebt\u00eb koh\u00eb nuk mund t\u00eb b\u00ebj\u00eb asgj\u00eb.<\/p>\n

Koha e Vler\u00ebs s\u00eb Shtuar \u2014 koha e pun\u00ebs s\u00eb dobishme<\/strong> \u2014 ajo q\u00eb kemi shpenzuar n\u00eb nj\u00eb faz\u00eb t\u00eb till\u00eb p\u00ebr t\u00eb krijuar vler\u00ebn p\u00ebrfundimtare p\u00ebr p\u00ebrdoruesin. P\u00ebr shembull, testi e ka ndjekur testin e tij dhe ka filluar t\u00eb kontrolloj\u00eb di\u00e7ka. Kjo \u00ebsht\u00eb koha e pun\u00ebs s\u00eb dobishme, kur ne faktikisht b\u00ebjm\u00eb di\u00e7ka p\u00ebr produktin. Kjo \u00ebsht\u00eb ajo p\u00ebr t\u00eb cil\u00ebn klient\u00ebt paguajn\u00eb \u2014 p\u00ebr software cil\u00ebsor.<\/p>\n

%C\/A \u2014 p\u00ebrqindja e pun\u00ebs s\u00eb pranuar. <\/strong>Kemi nj\u00eb faz\u00eb \u2014 zhvillimi, faza e dyt\u00eb \u2014 testi. Sa shum\u00eb ve\u00e7ori kan\u00eb pranuar testuesit nga zhvilluesit, dhe ekziston ky p\u00ebrqindje.<\/p>\n

Dikur duket k\u00ebshtu harta jon\u00eb.<\/p>\n

\"Si
\n
\nAjo \u00ebsht\u00eb e mundur q\u00eb t\u00eb duket ndryshe n\u00eb var\u00ebsi t\u00eb struktur\u00ebs organizative, numrit t\u00eb departamenteve dhe asaj q\u00eb b\u00ebni. Por n\u00eb p\u00ebrgjith\u00ebsi, harta do t\u00eb ket\u00eb dy faza: ideja <\/strong>dhe analiza<\/strong>. N\u00eb k\u00ebt\u00eb faz\u00eb priten t\u00eb dh\u00ebna, p\u00ebr shembull, Koha e \u00c7mimeve 2 jav\u00eb dhe Koha e Vler\u00ebs t\u00eb Shtuar 2 dit\u00eb.<\/p>\n

Metrit e mbulojm\u00eb t\u00eb gjitha fazat.<\/p><\/blockquote>\n

\nBacklog<\/strong> \u2014 sa detyra ishin duke pritur pas se sa analist\u00ebt i menduan ato.<\/p>\n

\u0420\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0430<\/strong> \u2014 sa jav\u00eb zhvilluesit prit\u00ebn p\u00ebr sqarime mbi detyrat, stendat apo pajisjet \u2014 nuk ka r\u00ebnd\u00ebsi, por ata po presin di\u00e7ka. P\u00ebr shembull, 4 dit\u00eb ata realizojn\u00eb nj\u00eb ve\u00e7ori. K\u00ebtu shfaqet metri %C\/A. Zhvilluesit mor\u00ebn vet\u00ebm 80% t\u00eb detyrave nga Backlog. Ata mendojn\u00eb se 20% e tjera nuk kan\u00eb nj\u00eb specifikim t\u00eb qart\u00eb dhe i d\u00ebrguan p\u00ebr rishikim.<\/p>\n

Testimi<\/strong>. N\u00eb skem\u00eb LT \u00ebsht\u00eb caktuar 4 dit\u00eb. P\u00ebr shembull, testuesit prit\u00ebn t\u00eb lirojn\u00eb stend\u00ebn e testimit, VA 2 dit\u00eb ata v\u00ebrtet testojn\u00eb di\u00e7ka, dhe %C\/A = 40%. \u2014 vet\u00ebm 40% e kodit ose ve\u00e7orave q\u00eb zhvilluesit d\u00ebrguan, testuesit i konsideruan adekuate. T\u00eb gjitha t\u00eb tjerat nuk u p\u00eblqyen p\u00ebr nj\u00eb arsye.<\/p>\n

Nuk do t\u00eb ndalem shum\u00eb n\u00eb k\u00ebt\u00eb proces matjeje, n\u00eb fund t\u00eb artikullit do t\u00eb rekomandoj literatur\u00ebn nga e cila mund t\u00eb m\u00ebsoni p\u00ebr to.<\/p>\n

E vetmja q\u00eb do t\u00eb rekomandoja \u00ebsht\u00eb t\u00eb mos i besoni njer\u00ebzve q\u00eb do t\u00eb krijojn\u00eb me ju nj\u00eb Hart\u00eb t\u00eb Vler\u00ebs. Ata paraqesin se sa koh\u00eb zgjat\u00ebn proceset e ndryshme, por k\u00ebto vler\u00ebsime nuk jan\u00eb gjithmon\u00eb t\u00eb sakta, ndaj \u00ebsht\u00eb m\u00eb mir\u00eb ta matni vet\u00eb.<\/p>\n

Kemi pasur nj\u00eb rast kur shkuam n\u00eb departamentin e Operacioneve dhe pyet\u00ebm se sa koh\u00eb merrte dor\u00ebzimi i nj\u00eb funksionaliteti t\u00eb ri n\u00eb prodhim. Na u p\u00ebrgjigj\u00ebn se 10 minuta, dhe ne menduam, p\u00ebrse erdh\u00ebm direkt n\u00eb k\u00ebt\u00eb kompani? Doli se 10 minuta ishin koha e skriptit q\u00eb merrte kodin dhe e d\u00ebrgonte n\u00eb server. Por para k\u00ebsaj, l\u00ebshimi q\u00ebndronte p\u00ebr tre dit\u00eb n\u00eb server e duke pritur \u2014 n\u00eb Backlog kishte nj\u00eb detyr\u00eb q\u00eb duhej vendosur. Pra, rezulton se para faz\u00ebs s\u00eb l\u00ebshimit ka nj\u00eb faz\u00eb pritje, ku projekti thjesht q\u00ebndron. N\u00ebse nuk do t\u00eb kishim shkuar me nj\u00eb bllok sh\u00ebnimesh, nuk do t\u00eb ishim fokusuar n\u00eb detyr\u00ebn n\u00eb Jira dhe nuk do t\u00eb kishim filluar ta ndiqnim hap pas hapi, do t\u00eb kishim menduar se gjith\u00e7ka ishte mir\u00eb dhe nuk kishte asnj\u00eb problem.<\/p>\n

Prandaj, do t'ju duhet t\u00eb kryeni vet\u00eb matjet, preferohet jo nj\u00eb her\u00eb, p\u00ebr t\u00eb pasur nj\u00eb paraqitje q\u00eb \u00ebsht\u00eb af\u00ebr realitetit. N\u00eb var\u00ebsi t\u00eb Hart\u00ebs s\u00eb Fluksit t\u00eb Vler\u00ebs, do t\u00eb merrni vendimin se nga ku t\u00eb filloni dhe \u00e7far\u00eb t\u00eb korrigjoni si prioritet.<\/p>\n

Ekipi temporary<\/h2>\n

\nShum\u00eb kompani q\u00eb vendos\u00ebn t\u00eb implementojn\u00eb DevOps krijojn\u00eb nj\u00eb ekip, jo temporary, por q\u00eb ekziston p\u00ebr disa vite. N\u00ebse referoheni n\u00eb sh\u00ebrbimin DevOps, ku jan\u00eb p\u00ebrshkruar m\u00ebnyra t\u00eb ndryshme p\u00ebr nd\u00ebrtimin e struktur\u00ebs organizative n\u00eb DevOps, do t\u00eb kuptoni se kjo \u00ebsht\u00eb nj\u00eb anti-model.<\/p>\n

Kur ekipi DevOps ekziston vazhdimisht p\u00ebr disa vite \u2014 kjo \u00ebsht\u00eb nj\u00eb gabim i madh, sepse DevOps \u00ebsht\u00eb p\u00ebr komunikimin nd\u00ebrmjet departamenteve, p\u00ebr shpejt\u00ebsin\u00eb dhe efikasitetin.<\/p><\/blockquote>\n

\nN\u00ebse ekipi ekziston mes departamenteve, vet\u00ebm p\u00ebr t\u00eb b\u00ebr\u00eb di\u00e7ka tjet\u00ebr t\u00eb ve\u00e7ant\u00eb, dhe ekziston p\u00ebr nj\u00eb koh\u00eb t\u00eb gjat\u00eb, at\u00ebher\u00eb ai krijon nj\u00eb barrier\u00eb shtes\u00eb. Tashm\u00eb, programuesi, n\u00eb vend q\u00eb t\u00eb shkoj\u00eb menj\u00ebher\u00eb te administratori p\u00ebr t\u00eb zgjidhur nj\u00eb problem, duhet fillimisht t\u00eb kontaktoj\u00eb departamentin DevOps, dhe ai do t\u00eb shkoj\u00eb m\u00eb tej.<\/p>\n

Prandaj, p\u00ebr t\u00eb filluar, \u00ebsht\u00eb e nevojshme t\u00eb krijoni nj\u00eb ekip temporary<\/strong>. Ajo do t\u00eb ekzistoj\u00eb n\u00eb m\u00ebnyr\u00eb kushtore p\u00ebr gjysm\u00eb viti, maksimumi p\u00ebr nj\u00eb vit, n\u00eb var\u00ebsi t\u00eb q\u00ebllimit t\u00eb vendosur, vet\u00ebm p\u00ebr t\u00eb zgjidhur nj\u00eb kufizim t\u00eb vet\u00ebm q\u00eb ne zgjodh\u00ebm. M\u00eb pas ajo do t\u00eb vdes\u00eb. N\u00ebse ne do t\u00eb zgjedhim pik\u00ebn tjet\u00ebr ku ndiejm\u00eb dhimbje t\u00eb madhe dhe do t\u00eb kuptojm\u00eb se p\u00ebr t\u00eb na nevojitet gjithashtu nj\u00eb ekip i ve\u00e7ant\u00eb, at\u00ebher\u00eb ne do ta krijojm\u00eb p\u00ebrs\u00ebri. Por n\u00eb 'pjes\u00ebn e v\u00ebrtet\u00eb' ekipi si ky nuk duhet t\u00eb ekzistoj\u00eb \u2014 p\u00ebrndryshe ata vet\u00ebm do t\u00eb prishin komunikimin dhe do t\u00eb marrin p\u00ebrsip\u00ebr detyra t\u00eb ve\u00e7anta, vet\u00ebm p\u00ebr t\u00eb b\u00ebr\u00eb di\u00e7ka. K\u00ebto detyra mund t\u00eb mos ken\u00eb lidhje fare me DevOps dhe me transformimin. Pse t\u00eb mos ia japim k\u00ebt\u00eb detyr\u00eb departamenteve ekzistuese?<\/p>\n

Pse \u00ebsht\u00eb nj\u00eb ekip p\u00ebrkoh\u00ebs<\/h3>\n

\nKonflikti me proceset aktuale<\/strong>. Transformimi DevOps \u00ebsht\u00eb nj\u00eb ndryshim jo vet\u00ebm n\u00eb teknologjit\u00eb dhe mjetet q\u00eb p\u00ebrdorim, por edhe n\u00eb procesin e pun\u00ebs, mendimin dhe vlerat. N\u00ebse ekipi do t\u00eb punoj\u00eb ashtu si\u00e7 \u00ebsht\u00eb m\u00ebsuar, ai nuk do t\u00eb mund t\u00eb provoj\u00eb qasje t\u00eb tjera.<\/p>\n

K\u00ebta njer\u00ebz duhet t\u00eb jetojn\u00eb sipas rregullave t\u00eb tjera: t\u00eb injorojn\u00eb t\u00eb gjitha KPI-t\u00eb n\u00eb kompani, sepse po p\u00ebrpiqen t\u00eb punojn\u00eb ndryshe. Ekipet p\u00ebrkohshme nuk do t\u00eb plot\u00ebsojn\u00eb aplikacione p\u00ebr t\u00eb marr\u00eb nj\u00eb server, por do t\u00eb shkojn\u00eb drejtp\u00ebrdrejt n\u00eb departamentin q\u00eb zajis, me k\u00ebrkes\u00ebn p\u00ebr t'u dh\u00ebn\u00eb atyre n\u00eb radh\u00eb t\u00eb par\u00eb at\u00eb q\u00eb nevojitet, sepse kjo \u00ebsht\u00eb nj\u00eb detyr\u00eb prioritare dhe sepse po p\u00ebrpiqen t\u00eb jetojn\u00eb ndryshe. Ekipi ka nj\u00eb konflikt t\u00eb plot\u00eb me t\u00eb gjitha proceset aktuale. Q\u00eb metodat e tanishme t\u00eb pun\u00ebs t\u00eb mos u pengojn\u00eb atyre tani, dhe ata t\u00eb mos pengojn\u00eb t\u00eb tjer\u00ebt, ne do t'i izolojm\u00eb k\u00ebta njer\u00ebz duke i vendosur n\u00eb nj\u00eb ekip t\u00eb ve\u00e7ant\u00eb.<\/p>\n

Shmangia e byrokracis\u00eb n\u00eb eksperimente<\/strong>. N\u00eb ekipet p\u00ebrkohshme nuk ka byrokraci, ata nuk plot\u00ebsojn\u00eb raporte p\u00ebr or\u00ebt e pun\u00ebs, ata nuk raportojn\u00eb p\u00ebrpara menaxher\u00ebve. Ky \u00ebsht\u00eb nj\u00eb bot\u00eb krejt\u00ebsisht e ndar\u00eb, n\u00eb t\u00eb cil\u00ebn njer\u00ebzit jetojn\u00eb dhe mendojn\u00eb ndryshe dhe angazhohen n\u00eb gjera krejt t\u00eb tjera. Mos i pengoni ata pa nevoj\u00eb.<\/p>\n

Puna e pand\u00ebrprer\u00eb mbi sh\u00ebrbimin<\/strong>. N\u00eb pik\u00ebn e par\u00eb ne kemi zgjedhur di\u00e7ka mbi t\u00eb cil\u00ebn do t\u00eb eksperimentojm\u00eb. Eksperimentet dhe k\u00ebrkimi i m\u00ebnyrave p\u00ebr t\u00eb punuar m\u00eb mir\u00eb jan\u00eb t\u00eb mira, por ne duam t\u00eb zhvillojm\u00eb edhe karakteristika. N\u00ebse e gjith\u00eb ekipi merret me transformimin n\u00eb vend t\u00eb karakteristikave, ne do t\u00eb fillojm\u00eb t\u00eb humbasim t\u00eb ardhurat dhe defektet do t\u00eb kalojn\u00eb shum\u00eb koh\u00eb pa u zgjidhur \u2014 kjo nuk na nevojitet. Krijimi i nj\u00eb ekipi p\u00ebrkoh\u00ebs dhe lejon eksperimentimin, pa ndaluar pun\u00ebn mbi produktin.<\/p>\n

Mosp\u00ebrjekje p\u00ebr detyrat e pun\u00ebs<\/strong>. Kjo p\u00ebrs\u00ebri ka t\u00eb b\u00ebj\u00eb me produktin. P\u00ebr sa koh\u00eb q\u00eb ekipi t\u00eb provoj\u00eb mjete t\u00eb tjera e k\u00ebshtu me radh\u00eb, k\u00ebrkohet shum\u00eb koh\u00eb. P\u00ebr njer\u00ebzit t\u00eb m\u00ebsojn\u00eb mjete, t\u00eb fillojn\u00eb t\u2019i zbatojn\u00eb dhe t\u2019i p\u00ebrdorin n\u00eb m\u00ebnyr\u00eb t\u00eb duhur, duhen t\u00eb pakt\u00ebn gjasht\u00eb muaj. N\u00ebse ata do t\u00eb merren edhe me produktin \u2014 gjasht\u00eb muaj do t\u00eb zgjasin n\u00eb mas\u00eb t\u00eb madhe. N\u00ebse njer\u00ebzit merren me produktin, ata do t\u00eb punojn\u00eb p\u00ebrs\u00ebri me proceset e vjetra \u2014 kjo nuk na nevojitet.<\/p>\n

Prandaj nga departamente t\u00eb ndryshme ne caktojm\u00eb njer\u00ebz n\u00eb nj\u00eb ekip t\u00eb ve\u00e7ant\u00eb, i cili do t\u00eb merret me transformimin e sh\u00ebrbimit. Si rezultat, sh\u00ebrbimi funksionon, vazhdon t\u00eb zhvillohet, dhe n\u00eb t\u00eb nj\u00ebjt\u00ebn koh\u00eb ne vendosim disa eksperimente mbi t\u00eb.<\/p>\n

Ekipi p\u00ebrkoh\u00ebsisht merret vet\u00ebm me transformimin e DevOps \u2014 eliminimin e atij kufizimi q\u00eb gjet\u00ebm, dhe asgj\u00eb m\u00eb shum\u00eb.<\/p><\/blockquote>\n

\nEkipa p\u00ebrb\u00ebhet nga njer\u00ebz polyvalent\u00eb<\/strong>. Kjo do t\u00eb thot\u00eb se ne mor\u00ebm jo vet\u00ebm zhvilluesit. Ne nuk erdh\u00ebm n\u00eb sh\u00ebrbim dhe nuk e mor\u00ebm gjith\u00eb ekipin nga aty \u2014 jo, ne mor\u00ebm njer\u00ebz nga departamente t\u00eb ndryshme<\/strong>. Disa pika m\u00eb par\u00eb, gjet\u00ebm departamente t\u00eb ndryshme dhe punonj\u00ebs t\u00eb ndrysh\u00ebm q\u00eb kan\u00eb lidhje me sh\u00ebrbimin q\u00eb po transformojm\u00eb. Nga ata formojm\u00eb ekipin, sepse ai duhet t\u00eb jet\u00eb polyvalent \u2014 do t\u00eb ndryshojm\u00eb procesin e testimit, procesin e zhvillimit dhe procesin e sh\u00ebrbimit t\u00eb sh\u00ebrbimit. Ne kemi nevoj\u00eb p\u00ebr kompetenca t\u00eb ndryshme.<\/p>\n

Zakoni do t\u00eb merrnim nj\u00eb zhvillues, nj\u00eb testues dhe nj\u00eb inxhinier \u2014 secilin nga nj\u00eb, dhe s\u00eb bashku me ta do t\u00eb krijojm\u00eb nj\u00eb zgjidhje q\u00eb na lejon t\u00eb jetojm\u00eb ndryshe.<\/p>\n

Preferohet q\u00eb k\u00ebta njer\u00ebz t\u00eb ken\u00eb autoritet n\u00eb organizat\u00eb<\/strong>. Ndoshta do t\u00eb duhet t\u00eb angazhojm\u00eb nj\u00eb konservator, edhe pse nuk d\u00ebshirojm\u00eb. N\u00ebse kemi nj\u00eb kompani t\u00eb madhe, jo t\u00eb gjith\u00eb do t\u00eb besojn\u00eb n\u00eb planin ton\u00eb, dhe ndonj\u00eb mund t\u00eb p\u00ebrpiqet t\u00eb na pengoj\u00eb, p\u00ebr shembull, duke mos siguruar nj\u00eb stend\u00eb. K\u00ebtu ne do t\u00eb na nevojitet nj\u00eb \u00abautoritet\u00bb \u2014 nj\u00eb person i respektuar me shum\u00eb p\u00ebrvoj\u00eb, i cili ka fituar respektin e koleg\u00ebve. Autoriteti i nj\u00eb punonj\u00ebsi n\u00eb ekip do ta leht\u00ebsoj\u00eb detyr\u00ebn dhe pun\u00ebn e ekipit p\u00ebrkoh\u00ebsisht. Njer\u00ebzit do t\u00eb mendojn\u00eb:<\/p>\n

\u2014 Ah, ky \u00ebsht\u00eb ai tipi i madh q\u00eb t\u00eb gjith\u00eb e njohim dhe e duam, duket se n\u00eb DevOps ka di\u00e7ka, q\u00eb ia vlen ta shohim!<\/em><\/p>\n

Vendosim nj\u00eb q\u00ebllim<\/h2>\n

\nKemi mbledhur njer\u00ebzit, kemi zgjedhur sh\u00ebrbimin, kemi par\u00eb kufizimet, kemi p\u00ebrcaktuar se n\u00eb k\u00eb t\u00eb ndajm\u00eb ndikimin ton\u00eb. Tani duhet t\u00eb vendosim nj\u00eb q\u00ebllim dhe ai duhet t\u00eb jet\u00eb konkret sip\u00ebr SMART<\/strong> \u2014 \u00e7do gj\u00eb, si\u00e7 na p\u00eblqen.<\/p>\n

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

Measurable \u2014 e matshme<\/strong>. Ky \u00ebsht\u00eb nj\u00eb pik\u00eb shum\u00eb e r\u00ebnd\u00ebsishme e SMART. N\u00ebse nuk mund ta matni di\u00e7ka, at\u00ebher\u00eb nuk mund ta ndryshoni dhe nuk do t\u00eb kuptoni se \u00e7far\u00eb b\u00ebni m\u00eb mir\u00eb ose m\u00eb keq.<\/p>\n

Achievable \u2014 e arritshme<\/strong>. B\u00ebni nj\u00eb kompromis p\u00ebr specifik\u00ebn tuaj. N\u00ebse jeni nj\u00eb kompani enterprise me histori t\u00eb gjat\u00eb dhe nj\u00eb ngarkes\u00eb t\u00eb madhe p\u00ebrgjegj\u00ebsish, e cila l\u00ebshon nj\u00eb version produkti \u00e7do vit, nuk do t\u00eb mund t\u00eb arrini t\u00eb l\u00ebshoni versione t\u00eb reja produkti \u00e7do or\u00eb brenda gjasht\u00eb muajve. Kjo nuk \u00ebsht\u00eb e mundur. Prandaj, vendosni nj\u00eb q\u00ebllim real, t\u00eb arritsh\u00ebm brenda nj\u00eb periudhe t\u00eb pranueshme.<\/p>\n

Relevant \u2014 e r\u00ebnd\u00ebsishme. <\/strong>Ne eliminojm\u00eb vet\u00ebm at\u00eb kufizim q\u00eb v\u00ebrtet ndjek q\u00ebllimet tona aktuale.<\/p>\n

Time Limited \u2014 e kufizuar n\u00eb koh\u00eb<\/strong>. N\u00ebse nuk ka afat \u2014 ekipa do t\u00eb merret me \u00e7far\u00ebdo: t\u00eb provoj\u00eb 15 teknologji n\u00eb vend t\u00eb 3, t\u00eb shkruaj\u00eb raporte t\u00eb m\u00ebdha, t\u00eb b\u00ebj\u00eb hulumtime t\u00eb kota, t\u00eb rafinoj\u00eb implementimin e saj deri n\u00eb shk\u00eblqim, kur q\u00ebllimi tashm\u00eb \u00ebsht\u00eb arritur.<\/p>\n

Ne e marrim q\u00ebllimin duke p\u00ebrdorur Mapped Value Stream \u2014 s\u00ebrish mbledhim t\u00eb gjith\u00eb njer\u00ebzit dhe vizatojm\u00eb. Por tani, mbi baz\u00ebn e Mapped Value Stream t\u00eb m\u00ebparshme, vizatojm\u00eb at\u00eb q\u00eb duam t\u00eb arrijm\u00eb.<\/p>\n

\"Si
\n
\nDallo nj\u00eb kufizim q\u00eb do t\u00eb eliminojm\u00eb tani, \u2014 me k\u00ebt\u00eb do t\u00eb merret ekipa. P\u00ebr shembull, kam marr\u00eb pritjen nga l\u00ebshimi p\u00ebrfundimtar deri te vendosja n\u00eb prodhim \u2014 kjo \u00ebsht\u00eb kufizimi m\u00eb i shpesht\u00eb me t\u00eb cilin njer\u00ebzit i drejtohen konsulent\u00ebve.<\/p>\n

Bazuar n\u00eb k\u00ebt\u00eb, vendosim nj\u00eb detyr\u00eb: duam q\u00eb koha midis l\u00ebshimit t\u00eb p\u00ebrfunduar dhe daljes n\u00eb treg t\u00eb jet\u00eb maksimum nj\u00eb or\u00eb.<\/p>\n

Shembuj t\u00eb detyrave.<\/p>\n