Ha nem érted, mi az a DevOps, itt egy rövid emlékeztető. A DevOps egy olyan gyakorlatok összessége, amelyek csökkentik a mérnökök félelmeit és csökkentik a szoftvergyártás során fellépő hibák számát. Általában ezeket csökkenti a piacra jutási időt — az időtartam az ötlettől a végtermék ügyfelekhez való eljuttatásáig, amely lehetővé teszi a gyors üzleti kísérletezést..
Hogyan kezdjük el a DevOps átalakulást? Röviden: válasszuk ki azt a szolgáltatást, amellyel elkezdjük a folyamatot, határozzuk meg azokat, akik kapcsolatban állnak a szolgáltatással, készítsünk Value Stream Map-et, hozzunk létre egy ideiglenes csapatot, amely az átalakítással fog foglalkozni az első időszakban, és adjuk meg neki a feladatot. Ismételjük meg a ciklust szükség szerint.
Részletes DevOps átalakulási terv példákkal és útmutatókkal a leírásban található. Andrej Alekszandrov — mérnök az Express42 cégnél, amely DevOps kialakításában ad tanácsot, felgyorsítva ezt a folyamatot, mert már elkészítette a buktatók térképét. Ha úgy gondolod, hogy az átalakulásra nincs szükséged, vagy olyan sajátosságaid vannak, amelyek miatt a DevOps-gyakorlatok nem illenek, — használd a beszámolót útmutatóként a korlátok keresésére és megszüntetésére.
Ha aggaszt a DevOps átalakítás kérdése, akkor nagy céged van, és fokozatosan kell méretezni ezt a folyamatot az egész struktúrára. Amíg szükség van a csapat átalakítására vagy valamilyen korlátnak a megszüntetésére, az alábbi algoritmus ismételhető.
Szolgáltatás kiválasztása
A tervet felvázoltuk, kezdjük az első lépéssel — a szolgáltatás kiválasztásával. Az első kritérium — az életciklus időtartama: vannak régi szolgáltatások — legacy, és új szolgáltatások. Lehet kezdeni a régiekkel és az újakkal is.
Ésszerű új szolgáltatást választani.Friss, még nincs megrögzött munkafolyamat a csapatban, amely foglalkozik vele. Nincs komoly technikai adósság körülötte, így bármilyen formában kezelhetjük.
Régi szolgáltatás esetén problémák merülnek fel azzal kapcsolatban, hogy mindig nehéz változtatni.Már van egy komoly korlátozásokkal teli készlet, de lehet, hogy olyan emberek foglalkoznak vele, akik készen állnak mindent újra átgondolni — belefáradtak, és valami mást akarnak tenni, mert szenvednek.
Régi szolgáltatás kezelése erős precedenst teremt a cégedben — lehet valamit változtatni. Ha megváltoztattad az új szolgáltatást, amely százszor annyiszor megy át a gyártásba, és minden rendben van, akkor a céged emberei azt mondhatják:
— Ez egy új szolgáltatás! Próbálja ki, mit tud tenni a romos rendszerünkkel.
A hagyományos szolgáltatást akkor érdemes átalakítani, amikor valakivel együtt csinálja, például, ha külső tanácsadót hívott meg. Legyünk őszinték, az átalakítás mindenre kihat.. Kísérletezünk és nem tudjuk, hova jutunk, milyen technológiai megoldásokat alkalmazunk, hol és milyen buktatók léphetnek fel a folyamatokban. Ezért az újat könnyebb cserélni.
Ha mindent saját magunk csinálunk, és a cégben nincs komoly szakértelem — új szolgáltatást választunk. Ha tud külső tanácsadót és van rá keret — válassza a régit.
Vannak olyan szolgáltatások, amelyek csak felhasználói felületként működnek, például egy egyszerű weboldal vagy mobilalkalmazás. De léteznek komolyabb dolgok, mint a billing. Ha valami nem működik a billinggel — nehéz lesz megérteni. Itt is van választási lehetőség.
Vagy kritikus szolgáltatással dolgozunk, de már emiatt szenvedünk, korlátokat állít fel, vagy dolgozunk felülettel. Ez a második választási kritérium. Hasonlóan van lehetőség tapasztalt tanácsadó bevonására — dolgozunk a nehéz esettel.
De még ebben az esetben sem ajánlanám ezt, mert amíg nincs megértés arról, hogy mivel dolgozzunk és merre kell átalakulni, a kritikus dolgot átkonfigurálni — nem túl jó ötlet. Ezért viszont inkább a felülettel dolgozunk, amelynek meghibásodása nem kritikus.
Nézzük meg a szolgáltatás csapatát. Azokkal, akik ezzel a szolgáltatással foglalkoznak, folyamatosan kell dolgoznunk és nagyon szoros kapcsolatban lennünk.
Az emberek a csapatban lényegében két kategóriába sorolhatók: konzervatívok — a régi világban élnek, vagy egyszerűen nem ismerik a DevOps-ot, és innovátorok, akik a divatos gyakorlatokat hozják. Az előbbiek nem mindig vannak tisztában a témával, de legalább készülnek rá.
Egyrészt a konzervatívok — tapasztalt emberek: régóta a cégnél vannak, minden részletet ismernek, de nem tudnak a gyakorlatokról. Másrészt az innovátorok, akik hallottak valamit, de a cégben valószínűleg nem dolgoznak túl régóta. Kivel érdemesebb dolgozni?
A konzervátorokkal mindenképpen együtt kell működnünk, hiszen ez az ő szolgáltatásuk. Beszélnünk kell velük, tisztázni a szolgáltatás specifikációit, hogy mit lehet úgy megcsinálni, és mit pedig másképp. Függünk a tanácsaiktól. Bizonyára lesz, amit nekik kell majd megbízni, mivel ők jobban ismerik a szolgáltatásukat. Ezért fontos, hogy kivel fogunk végül kapcsolatba kerülni.
Logikus, hogy innovátorokat válasszunk a csapatba, mert a konzervátorok esetleg hátrányos helyzetbe hozhatják a helyzetet.
A gyakorlatban gyakran előfordul, hogy a konzervatív embereknek jelentős tapasztalatuk van, de nincsenek tisztában azzal, hogyan tovább. Egyszerűen félnek attól, hogy a szolgáltatás átalakítása és felújítása után elbocsátják őket. Néha csak amiatt, hogy nem értik, mi történik, akadályozzák a munkát.
Volt egy esetem, amikor a csapat egyik tagja mindent javított, mert szerinte az krónikusabb volt, mint amit éppen csinálunk. Feladatot adtunk: ma valamit megvalósítani — nem, a világ másik végén tűz van, menjünk azt javítani. Ezekkel az emberekkel nehéz dolgozni.
A konzervátorok csapatából származó emberek gyakran figyelmen kívül hagyják a feladatokat, vagy az utolsó pillanatig halogatják őket. Ha, Isten óvjon, hibát követett el, és KPI-t szabott nekik a végrehajtott feladatok számának alapján, de valamilyen részét nem számítják bele a KPI-ba, akkor ők egyáltalán nem fognak semmit csinálni. Valójában igazuk is van, mert akkor elveszítik a prémiumot.
Az innovátorokkal egyszerűbb — lojálisabbak.. Már hallottak valamit, szeretnének valamerre haladni, ezért segíteni fognak. Olyan emberekre van szükségünk, akik készek az elején szenvedni: ha megváltozik a szolgáltatás, az innovátorok fogják megkapni az összes hibát és akadályt, mint az első felfedezők. Az innovátorok a legújabb és legtrendibb dolgokat akarják, és hajlandók szenvedni.
A konzervátorokat később át lehet téríteni a saját hitükre. Amikor megmutatod, hogy módosítottál egy darabot, és minden jól működik, valószínűleg ők is ki szeretnék próbálni, és elfogadják az új DevOps vallást.
Összefoglalva. Ha a cégen belüli teljes átalakítást saját magunk végezzük, akkor válasszunk: új szolgáltatást, lehetőleg egyszerű felülettel, hogy ne szenvedjünk túlságosan a hibáktól, és a csapat innovátorokból.
Ha lehetőség van külső tanácsadó bevonására, ahelyett, hogy újat hoznánk be, a régi szolgáltatást vesszük igénybe, ami miatt már szenvedtünk. Azok az emberek, akik különböző cégeknél hosszú ideig foglalkoztak átalakítással, láttak különböző eseteket, és már tudják, hogyan kell helyesen csinálni, és merre kell menni.
Ki érintett?
Meg kell találnunk mindazokat, akiknek bármilyen kapcsolata van a szolgáltatással: fejlesztők, tesztelők, adminisztrátorok, biztonsági szakemberek, menedzserek és esetleg Product Owner-ek. Annak ellenére, hogy a Product Owner-ek nem technikai szakemberek, kapcsolatban állnak a szolgáltatással: ők hozzák meg a döntéseket és állítják fel a feladatokat.
Mindenkit meg kell találni, aki bármilyen döntést hoz és hatással van arra, ami a szolgáltatással történik, meg kell ismerkedni velük és beszélgetni velük.
Mire van szükségünk tőlük? Hogy tudjuk, kivel kell egyeztetni.. Az átalakítás során, amikor a szolgáltatás munkamódszere megváltozik, esetleg problémák merülnek fel. Egy ideig zökkenők lesznek, amíg teszteljük az új megközelítéseket. Az embereknek fel kell készülniük erre, és ezzel egyet kell érteniük.
Továbbá, fel kell építenünk a Value Stream Map-et, és ezek az emberek nélkül nem építhetjük meg, mert csak ők együtt ismerik a teljes folyamatot. Egy ember soha nem tud mindent, ami a szolgáltatással történik.
Ajánlani fognak embereket a csapatba. Később megbeszéljük, miért szükséges külön csapatot létrehozni. Olyan embereket kell bevonni, akik a meglévő osztályokból jönnek. Azok, akiknek kapcsolata van a szolgáltatással, ajánlhatnak kollégákat, akik a mi irányunkban gondolkodnak, tudnak segíteni és rendelkeznek a szükséges kompetenciával.
Ezután összegyűjtjük ezeket az embereket a különböző osztályokból egy terembe, és elkezdjük építeni a Value Stream Map-et.
Építsük a Value Stream Map-et
A Value Stream Map egy olyan diagram vagy térkép, amely megmutatja az értékáramokat az ügyfélhez.. Ez a teljes folyamat az ötlet megszületésétől a megvalósításáig, beleértve az összes közbenső lépést és azt, hogy végül hogyan jut el az érték az ügyfeleinkhez.
A Value Stream Map-re azért van szükség, hogy vizualizáljuk a fejlesztés minden lépését, lokalizáljuk a problémákat az aktuális folyamatban mért adatok alapján, és elkezdjük ezeket a problémákat megszüntetni, és meghatározzuk az elsődleges célt. Ez az a hely, ahol valódi lépéseket fogunk tenni.
Metrikák
A Value Stream Map-ról szóló irodalomban sok különböző metrikát leírnak, de kezdetnek elegendő mindössze három.
Lead Time — késlekedés/várakozás — az az idő, amikor várunk valamire. Például, a tesztelő várja, hogy felszabaduljon a tesztkörnyezet, és addig semmit sem tud tenni.
Value Added Time — hasznos munkaidő. — az az idő, amit egy adott szakaszban töltöttünk, hogy végső értéket teremtsünk a felhasználónak. Például, a tesztelő elindította a tesztjét, és elkezdte ellenőrizni valamit. Ez a hasznos munkaidő, amikor tényleg valamit csinálunk a termékért. Ez az, amiért az ügyfelek fizetnek — a minőségi szoftverért.
%C/A — az elfogadott munka százaléka. Van egy szakaszunk — a fejlesztés, a második szakasz — a tesztelés. Hány funkciót fogadtak el a tesztelők a fejlesztőktől, és ez a százalék.
Így néz ki a térképünk.
Másképp is kinézhet a szervezet felépítésétől, az osztályok számától és attól függően, hogy mivel foglalkozik. De általánosságban a térképen két szakasz lesz: ötlet és analitika. Ebben a szakaszban adatok várhatók, például a Lead Time 2 hét és a Value Added Time 2 nap.
A metrikákkal abszolút minden szakaszt lefedünk.
Backlog — hány feladat maradt, miután az elemzők kitalálták őket.
Fejlesztés — hány hetet vártak a fejlesztők a feladatok, környezetek vagy berendezések pontosítására — mindegy, de vártak valamire. Például, 4 nap alatt valósítanak meg egy funkciót. Itt megjelenik a %C/A metrika. A fejlesztők csak a backlogból a feladatok 80%-át vették át. Úgy hiszik, hogy a fennmaradó 20%-nak nem elég világos a műszaki specifikációja, és visszaküldték őket javításra.
Tesztelés. A diagramon az LT 4 napra van állítva. Például, a tesztelők vártak a tesztkörnyezet felszabadulására, a VA 2 nap alatt valóban valamit tesztelnek, és a %C/A = 40 %. — csak a kód vagy funkciók 40%-át, amelyet a fejlesztők küldtek, érezték megfelelőnek a tesztelők. Minden más valamiért nem tetszett nekik.
Nem fogok részletesen kitérni arra, hogyan kell ezeket a méréseket végezni, a cikk végén ajánlok irodalmat, amelyből többet megtudhat róluk.
Amit tanácsolni tudok — ne higgyenek azoknak az embereknek, akik veletek fogják készíteni a Value Stream Map-et. Ők azt mutatják be, mennyi időbe telik különböző folyamatok, de ezek a becslések nem mindig pontosak, ezért jobb, ha magunk mérjük.
Volt egyszer, amikor bementünk az Operations osztályra, megkérdeztük, mennyi időbe telik egy új funkció kiadása a produkcióban. Azt válaszolták, hogy 10 perc, és azon gondolkodtunk, miért is jöttünk ide a céghez? Kiderült, hogy a 10 perc az a szkript működési ideje, amely a kódot átvitelez a szerverre. De ez előtt a kiadás három napig pihen a szerveren — a Backlogban van egy feladat, amit ki kellene telepíteni. Tehát a telepítés szakasza előtt van egy várakozási szakasz, amikor a projekt csak hever. Ha nem vittünk volna magunkkal jegyzetfüzetet, nem akadtunk volna meg a Jira feladatnál, és nem kezdtük volna el nyomon követni lépésről lépésre, azt hinnénk, hogy minden rendben van, és nincs probléma.
Ezért az intézkedéseket mégis magunknak kell megtennünk, lehetőleg nem egyszer, hogy minél közelebbi képet kapjunk a valóságról. A Value Stream Map alapján fognak dönteni arról, hogy honnan kezdjék, és mit javítsanak először.
Ideiglenes csapat
Sok olyan cég, amely úgy döntött, hogy bevezeti a DevOps-t, létrehoz egy csapatot, de nem átmeneti, hanem évek óta fennálló csapatot. Ha megkeresi a DevOps apologize szolgáltatást, ahol különböző mintázatok vannak a DevOps szervezeti felépítésének leírására, rá fog jönni, hogy ez egy antipattern.
Amikor a DevOps csapat folyamatosan létezik néhány éven át, az nagy hiba, mert a DevOps a közötti kommunikációról, a sebességről és a hatékonyságról szól.
Ha a csapat létezik az osztályok között, csak azért, hogy valami mást tegyen, és hosszú ideig létezik, akkor extra akadályt teremt. Most a programozónak az adminisztrátorhoz való közvetlen eljutás helyett először a DevOps osztályhoz kell fordulnia, és az majd megy tovább.
Ezért, hogy elkezdjük, ideiglenes csapatot kell létrehozni.Ez nagyjából fél évig, maximum egy évig fog működni, a kitűzött céltól függően, csak azért, hogy megszüntessük egy korlátozást, amit kiválasztottunk. Utána meghal. Ha kiválasztjuk a következő pontot, ahol nagy fájdalmunk van, és megértjük, hogy ahhoz is szükségünk van egy külön csoportra, akkor újra létrehozzuk. De a 'tartós' csapatoknak nem szabad létezniük — csak megzavarják a kommunikációt, és teljesen külön feladatokat látnak el, csak azért, hogy valamit csináljanak. Ezek a feladatok lehet, hogy egyáltalán nem kapcsolódnak a DevOps-hoz és a transzformációhoz. Miért ne adnánk ezt a feladatot a meglévő részlegeknek?
Miért van szükség ideiglenes csapatra
Összeütközés a jelenlegi folyamatokkalA DevOps transzformáció nemcsak a technológiák és eszközök megváltoztatását jelenti, hanem a munka, a gondolkodás és az értékek megváltozását is. Ha a csapat úgy dolgozik, ahogy azt már megszokták, nem tudják kipróbálni az új megközelítéseket.
Ezeknek az embereknek más szabályok szerint kell élniük: figyelmen kívül kell hagyniuk a vállalat minden KPI-ját, mert más megközelítéssel próbálnak dolgozni. Az ideiglenes csapatok nem fognak kérelmet benyújtani a szerverért, hanem közvetlenül ahhoz a részleghez fordulnak, amelyik ezzel foglalkozik, és követelik, hogy először kapják meg azt, amire szükségük van, mert ez egy prioritási feladat, és mert próbálnak másképp élni. A csapat teljes konfliktusban van minden jelenlegi folyamattal. Annak érdekében, hogy a meglévő munkamódszerek ne zavarják őket jelenleg, és ők ne zavarják másokat, elkülönítjük ezeket az embereket, egy külön csapatba helyezve őket.
A bürokrácia elkerülése a kísérletek soránAz ideiglenes csapatokban nincs bürokrácia, nem töltik ki a munkaidőket, nem számolnak be a menedzsereknek. Ez egy teljesen külön világ, ahol az emberek másképp élnek és gondolkodnak, és teljesen más dolgokkal foglalkoznak. Ne zavarjuk őket feleslegesen.
Megállás nélküli munka a szolgáltatásonAz első pontnál kiválasztottunk valamit, amin kísérletezni fogunk. A kísérletezés és a jobb munkamódszerek keresése jó dolog, de új funkciókat is szeretnénk létrehozni. Ha a csapat a funkciók helyett csak a transzformációval foglalkozik, akkor kezdünk el veszíteni a bevételekből, a hibák sokáig ott fognak lógni — erre nincs szükségünk. Az ideiglenes csapat létrehozása lehetővé teszi a kísérletezést anélkül, hogy megállítanánk a terméken végzett munkát.
Ne pazarj időt munkahelyi feladatokra. Ez újra a termékről szól. Sok időt igényel, hogy a csapat más eszközöket próbáljon ki és egyebek. Ahhoz, hogy az emberek elsajátítsák az eszközöket, elkezdjék bevezetni és normálisan használni, legalább fél évre van szükség. Ha közben a termékkel is foglalkoznak, a fél év elnyúlhat.
Ezért külön csapatot hozunk létre a különböző osztályok embereiből, amely a szolgáltatás átalakításával foglalkozik. Ennek eredményeként a szolgáltatás működik, folyamatosan fejlődik, és közben kísérleteket végzünk rajta.
A ideiglenes csapat csak a DevOps átalakítással foglalkozik — a problémák megszüntetésével, amire rábukkantunk, és semmi mással.
A csapat sokoldalú emberekből áll. Ez azt jelenti, hogy nemcsak fejlesztőket hoztunk. Nem mentünk be a szolgáltatásba, hogy onnan elvigyünk egy fél csapatot — nem, vettünk embereket különböző osztályokból. Néhány ponttal ezelőtt különböző osztályokat és alkalmazottakat találtunk, akik kapcsolódnak az átalakított szolgáltatáshoz. Közülük állítjuk össze a csapatot, mert sokoldalúnak kell lennie — változtatnunk kell a tesztelési, fejlesztési és szolgáltatási folyamatokon. Különféle kompetenciákra van szükség.
Általában egy fejlesztőt, egy tesztelőt és egy mérnököt veszünk — mindegyikből egyet, és közösen dolgozunk ki olyan megoldást, amely lehetővé teszi a másként való működést.
Jó lenne, ha ezek az emberek tekintélyt élveznének a szervezetben. Lehet, hogy egy konzervatívabb személyt is be kell vonnunk, még ha nem is szeretnénk. Ha nagy cégről van szó, távolról sem mindenki fog hinni a tervünkben, és valaki akadályozhatja a munkát, például azzal, hogy nem biztosít állványt. Itt szükség lesz egy 'tekintélyre' — egy tiszteletnek örvendő, tapasztalt szakemberre, akinek jó a kapcsolata a kollégákkal. A csapattag tekintélye megkönnyíti a feladatot és a munka menetét az ideiglenes csapat számára. Az emberek így gondolkodnak:
— Aha, ez a klassz srác, akit mindannyian ismerünk és szeretünk, most ott van — valószínűleg van valami, amire érdemes lenne figyelni a DevOps-ban!
Célkitűzést állítunk fel
Összegyűjtöttük az embereket, kiválasztottuk a szolgáltatást, megnéztük a korlátokat, meghatároztuk, kikre van hatásunk. Most célt kell kitűznünk, és annak világosan kell megfogalmazódnia a SMART elvek szerint — minden úgy, ahogy szeretjük.
Specifikus — konkrét.
Mérhető — mérhető. Ez a SMART fontos része. Ha nem tudsz mérni valamit, akkor nem tudod azt megváltoztatni, és nem értheted, hogy mit és hogyan csináltál jobban vagy rosszabbul.
Elérhető — elérhető. Vegye figyelembe a saját sajátosságait. Ha ön egy nagy vállalat, amelynek hosszú története és sok kötelezettsége van, és évente ad ki termékverziót, akkor nem fog tudni fél év alatt óránként új termékverziót kiadni. Ez nem fog működni. Ezért tűzzön ki egy reális célt, amely elfogadható időkereten belül elérhető.
Releváns — releváns. Csak azt a korlátozást távolítjuk el, amely valóban követi aktuális céljainkat.
Időben korlátozott — időben korlátozott. Ha nincs határidő, a csapat bármi mással foglalkozik: 15 technológiát próbálnak ki 3 helyett, hatalmas jelentéseket írnak, haszontalan kutatásokba bocsátkoznak, és a megvalósításukat tökéletesítik, amikor a célt már elérték.
A célt pontosan a Value Stream Map segítségével tűzzük ki — újra összehívjuk az összes embert, és rajzolunk. De most az előző Value Stream Map-ra alapozva rajzoljuk azt, amit el szeretnénk érni.
Kijelölünk egy korlátozást, amelyet most azonnal el fogunk távolítani — ezzel fog foglalkozni a csapat. Például az időtartam a kész kiadástól a termelési telepítésig — ez a leggyakoribb korlátozás, amellyel az emberek a tanácsadókhoz fordulnak.
Ezen alapjából feladatot állítunk fel: azt szeretnénk, ha a kész kiadás és a bevezetés közötti várakozás legfeljebb egy óra lenne.
Feladatpéldák.
- Csökkenteni a tesztelési Lead Time-ot 4 napról 1 órára.
- Csökkenteni az értékteremtési időt a teszteléshez 2 napról 3 órára.
- Csökkenteni a telepítési Lead Time-ot 5 óráról 10 percre.
- Növelni a C/A-t 50%-ról 95%-ra, azaz növelni a tesztelők által elfogadott funkciók számát, más szavakkal, javítani a fejlesztők munkájának minőségét.
A feladatpéldák nem önkényesek — azok mérések alapján készültek, amelyeket a Value Stream Map kidolgozása során végeztünk.
Hasonló feladatot tűzünk ki a csapatunknak, és határidőt állítunk. Attól függően, hogy a vállalatában mennyire van minden rendben, különböző határidőket tűz ki. Átlagosan a korlátozás eltávolításához, ha az emberek először foglalkoznak ezzel, és még nem tudják, milyen technológiák segítségével és hogyan fogják megoldani a problémát, általában fél év szükséges.
Rövid tervezés
Tehát a csapatunk összeállt, megvan a célja, az emberek elkezdenek dolgozni. Fontos szempont a rövid távú munkatervezés: a sprintek egy-két hétigés nem tovább, megmérhető fejlődések minden héten és a kurzus korrekciója..
Például gyakran alkalmazzuk a megközelítést moving-moving, amikor a teljes csapat az adott hét elején összegyűlik, és megvitatják, hogy ki mit fog csinálni. Egy hét múlva rögzítjük: mi valósult meg, mi nem, ha nem, akkor miért, és gondolkodunk a további lépéseken.
A sprintek lehetővé teszik a kurzus időben történő korrigálását.
Egy-két hétig kipróbálunk valamit: technológiákat, megközelítéseket, munkamódszereket, utána újra mérjük és megnézzük - ezzel a megközelítéssel jobb lett vagy rosszabb? Ha rosszabb, akkor nem jó irányba megyünk, ki kell javítani a kurzust: más feladatot kell adni, más technológiát választani vagy valami mást csinálni. A rövid sprintek 1-2 héten keresztül lehetővé teszik, hogy ügyeskedjünk és időben eltávolodjunk a rossz döntésektől.
Megosztjuk a sikert
A csapat valamilyen sikert elér, kicsi vagy nagy - mindegy, mindig van valamilyen eredmény. Ezt az eredményt mindenkinek tudnia kell: a DevOps-hoz kapcsolódóknak és a szomszédos osztályoknak is. Ideális világban kívánatos, hogy ez eljusson mindenkihez a cégben.
Miért? Ha azt akarjuk, hogy ne csak a cég egy részét alakítsuk át, hanem minden akadályt eltüntessünk, hogy a cég rugalmas legyen, a kód gyorsan eljusson az ügyfélig, és semmi ne törjön el, akkor mindenkihez el kell jutnia a DevOps ötletének. Nem tudja alkalmazni a megközelítést olyan szolgáltatásokra és csapatokra, amelyek kategorikusan ellenzik azt.
A hűség kialakulásához mindenkinek el kell mondanunk, hogy ezt kipróbáltuk - van eredményünk, próbálja ki ön is! Ez növelni fogja az érdeklődést és a hűséget a tevékenységünk iránt, az emberek most azonnal próbálni fognak valamit. A gyakorlat azt mutatja, hogy amikor elmondjuk, mit próbáltunk és mit értünk el, más csapatok is kérdezni kezdenek, hogyan és mit csináltunk. Nézik a megvalósításokat, a kódot, a dokumentációt, kérdésekkel fordulnak hozzánk és próbálnak valamit megváltoztatni náluk.
Fontos elmondani, miben sikerült. Így meg tudja győzni a magát konzervatívnak tartókat, akik régi módon akarták csinálni a dolgokat, hogy átálljanak innovátorokká.
Összesen
Választunk egy szolgáltatást, mint a kiindulási pontot - azt a helyet, ahol megkezdjük a változásokat a cégen belül. Felkérjük azokat, akiknek bármilyen kapcsolata van a szolgáltatással és együtt velük megalkotjuk az Értékáramlási Térképet, mérjük és nézzük, hol és miként vannak korlátozások.
Létrehozunk egy új ideiglenes csapatot, amely megoldja a kitűzött feladatot. A mérések és az Értékáramlási Térkép alapján rajzolunk egy új térképet, ahol kiemeljük azt a korlátozást, amelyet meg kell oldanunk. E korlátozás alapján kitűzünk egy feladatot, amellyel a csapat foglalkozni fog. A feladatnak feltétlenül SMART-nak kell lennie — konkrét, mérhető, releváns a jelenlegi feladatokhoz és időben korlátozott.
Ismételjük meg a folyamatot, amíg minden szolgáltatásunkat a kívánt formára nem transformáljuk, és minden korlátozást meg nem szüntetünk.
Bónusz. Hasznos anyagok
Azoknak, akik úgy döntöttek, hogy saját maguk foglalkoznak a DevOps-szal.
Phoenix Projekt
Eredeti cím — „The Phoenix Project: A Novel about It, Devops, and Helping Your Business Win”. Ez a DevOps-ról szóló regény — történet arról, hogyan lett egy munkavállalóból a folyton tűzben lévő osztályvezető. Az új vezető feladatot kapott:
— Van néhány éved, hogy mindent kijavíts, hogy végre gyorsan és hatékonyan tudjuk szállítani termékünket ügyfeleinknek.
„A Főnix Projekt. Regény arról, hogyan változtatja meg a DevOps az életet a jobboldalra” — könyv minden vezető számára, mert pontosan ezek az emberek hozzák meg a döntéseket arról, mi történik a vállalatnál. Ha mérnök vagy programozó vagy, és szeretnéd, ha a cégedben megindulna a mozgalom és a transzformáció — vásárolj egy könyvet és ajándékozd meg a vezetőséget. Ez a regény mindent elmagyaráz, és gyorsan, könnyen olvasható.
DevOps útmutató
Ez a könyv kicsit nehezebb. Néhány évvel ezelőtt jelent meg angolul „The DevOps Handbook How to create world‑class agility, reliability, and security in Technology organizations” címmel, de most már van oroszul is. Ez egy igazi kézikönyv — gyakorlati útmutató: hogyan végezhetők el a mérések, mi az Értékáramlási Térkép és miért van rá szükség, merre érdemes haladni, milyen sorrendben. A könyv pontosan azoknak szól, akik mindent saját maguk akarnak elvégezni. A legfontosabb, hogy példákat tartalmaz más cégek tapasztalatairól.
Például itt elmondják, hogyan épített egy vállalat Value Stream Map-ot, és jött rá, hogy a korlátozása nem a termékben rejlik, hanem abban, hogy a pénztáros a bolt és a szomszédos iroda között járkál, hogy ezt a terméket felhasználja. Ahelyett, hogy a programmal foglalkoztak volna, egyszerűen vásároltak a saleseseknek tabletet, és most senki sem járkál, minden tevékenységet a munkahelyen végeznek. Következtetés: A Value Stream Map nemcsak a szoftverekre vonatkozik, hanem a szervezeten belüli összes folyamatra.
Gyorsítsa fel
Teljes cím: „Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations”. Ez a következő szint — hardcore. A könyv tavaly jelent meg, egyelőre csak angolul, és kutatásokról szól. Az írók — Nicole Forsgren, Jez Humble és Gene Kim — évekig különböző gyakorlatokat alkalmaztak különböző cégeknél, és kutatták, hogy ezek a gyakorlatok hogyan és milyen hatással vannak.
A második fejezetben, amely a mérésekkel foglalkozik, említésre kerül a Value Stream Map, azok a mutatók, amelyeket említettem, és sok más, valamint részletesen le van írva a mérési folyamat. Az írók kérdőívek és önálló feladatkövetés révén végeznek méréseket. Részletesen tárgyalják, hogy mely mutatókat érdemes pontosan mérni, melyeket nem, és az emberi hibákat a mérésekben. Ha nehézségei vannak a mérésekkel, keresse fel a „Accelerate” könyv második fejezetét. Ha a csapatában sok gyakorlat van, de nem világos, hogy most mely gyakorlatokat alkalmazzon, melyeket később, melyek hatékonyak, és melyek nem — olvassa el, a könyvben minden benne van.
A transzformáció — a DevOps és a menedzsment határvonalán helyezkedik el. Valahol ezen a területen, a fejlesztés, üzemeltetés és tesztelés kereszteződésében találhatók a témák, amelyeket megpróbálunk megvitatni a , ugyanaz az integráció szükséges a minőségi termék létrehozásához – a fő téma . A fesztiválon a menedzsment körülbelül 800 alkalmazás található. Az új alkalmazások fejlesztésének megkönnyítése érdekében készítettek egy sor standard — ez azt jelenti, hogy az átalakulás ötletei mind ide érkeznek. Csatlakozzon május 27-én és 28-án, integrálódjunk és átalakuljunk.
Forrás: habr.com
