Agar DevOps nima ekanligini tushunmasangiz, mana bu yerda tezkor cheat varag‘i. DevOps - bu amaliyotlar to'plami muhandislarning qo'rquvini kamaytiradi va dasturiy ta'minot ishlab chiqarishdagi nosozliklar sonini kamaytirish. Qoida tariqasida, ular bir xil bozorga chiqish vaqtini qisqartirish — g‘oyadan to yakuniy mahsulotni xaridorlarga yetkazib berishgacha bo‘lgan davr, bu sizni tezda amalga oshirish imkonini beradi biznes tajribalari.
DevOps transformatsiyasini qanday boshlash kerak? Qisqasi: biz jarayonni boshlash uchun xizmatni tanlaymiz, xizmatga aloqadorlarni aniqlaymiz, qiymat oqimi xaritasini tuzamiz, birinchi marta transformatsiya bilan shug'ullanadigan vaqtinchalik guruh yaratamiz va unga vazifa qo'yamiz. Biz tsiklni kerakli miqdordagi takrorlaymiz.
Kesim ostidagi misollar va ko'rsatmalar bilan DevOps-ni o'zgartirishning batafsil rejasi - transkriptda Andrey Aleksandrov - Express42 muhandisi, DevOps o'sishi bo'yicha maslahat beradi, bu jarayonni tezlashtiradi, chunki u allaqachon rake xaritasini tuzgan. Agar sizga o'zgartirish kerak emasdek tuyulsa yoki sizning xususiyatlaringiz DevOps amaliyotlari mos kelmasa, hisobotdan cheklovlarni topish va yo'q qilish bo'yicha ko'rsatmalar sifatida foydalaning.
Agar siz DevOps-ni o'zgartirish masalasidan xavotirda bo'lsangiz, demak sizda katta kompaniya bor va siz bu jarayonni butun tuzilma bo'ylab bosqichma-bosqich kengaytirishingiz kerak. Buyruqni o'zgartirish yoki ba'zi cheklovlarni bartaraf etish zarurati mavjud ekan, quyida keltirilgan algoritm takrorlanishi mumkin.
Xizmatni tanlash
Biz rejani belgilab oldik, keling, birinchi qadamdan - xizmatni tanlashdan boshlaylik. Birinchi mezon - umr bo'yi: eski xizmatlar mavjud - eski va yangilari. Siz ikkalasidan boshlashingiz mumkin.
Yosh xizmatni tanlash mantiqan. Bu yangi, u bilan shug'ullanadigan jamoada ishlash uchun hali o'rnatilgan jarayon yo'q. Uning atrofida texnik qarzlar tog'i yo'q, uni doimo tuzatishga hojat yo'q. Biz u bilan xohlagan narsani qila olamiz.
Eski xizmatga kelsak, bu bilan bog'liq muammolar mavjud o'zgartirish har doim qiyin. Allaqachon bir qator jiddiy cheklovlar mavjud, ammo, ehtimol, ular bilan hamma narsani belkurak bilan urishga tayyor bo'lgan odamlar shug'ullanmoqda - ular charchagan va og'riqli bo'lgani uchun boshqacha qilishni xohlashadi.
Eski xizmat bilan ishlash kuchli pretsedentni o'rnatadi kompaniyangizda - siz biror narsani o'zgartirishingiz mumkin. Agar siz yangi xizmatni o'zgartirsangiz, u soatiga 100 marta pasayadi va hammasi yaxshi bo'lsa, kompaniyangizdagi odamlar shunday deyishlari mumkin:
- Bu yangi xizmat! U erda hamma narsa oddiy edi, bizning halokatimiz bilan nimadir qilishga harakat qiling.
Transformatsiya uchun Legacy xizmatidan foydalanish mantiqan to'g'ri keladi, masalan, agar siz tashqi maslahatchini taklif qilgan bo'lsangiz. Rostini aytaylik, transformatsiya mumkin bo'lgan hamma narsani silkitadi. Siz tajriba o'tkazyapsiz va qayerga borishingizni, qanday texnologiyalardan foydalanishni va nima uchun, qaerda va jarayonlarda qanday tuzoqlar paydo bo'lishini bilmayapsiz. Shuning uchun yangisini o'zgartirish osonroq.
Agar siz hamma narsani o'zingiz qilsangiz va kompaniya jiddiy vakolatga ega bo'lmasa, biz yangi xizmatni qabul qilamiz. Agar siz tashqi maslahatchini bilsangiz va mablag'ingiz bo'lsa, eskisini tanlang.
Foydalanuvchilar uchun oddiygina interfeys bo'lgan xizmatlar mavjud, masalan, oddiy veb-sayt yoki mobil ilova. Lekin billing ruhida jiddiy narsalar bor. Agar hisob-kitobda biror narsa noto'g'ri bo'lsa, buni aniqlash qiyin bo'ladi. Bu erda bizda ham tanlov bor.
Biz ham ishlaymiz muhim xizmat bilan, lekin biz bundan azob chekamiz, cheklovlar yaratadi yoki biz ishlaymiz interfeysi bilan. Bu ikkinchi tanlov mezoni. Xuddi shunday, tajribali maslahatchini jalb qilish mumkin - biz qiyin variant bilan ishlaymiz.
Ammo bu holatda ham men buni qilishni tavsiya etmayman, chunki nima bilan ishlash va qaysi yo'nalishda o'zgartirish kerakligini tushunmaguncha, tanqidiy narsani olib, uni silkitish juda yaxshi fikr emas. Shuning uchun, bu holda, biz muvaffaqiyatsizligi muhim bo'lmagan interfeys bilan ishlashni afzal ko'ramiz.
Keling, batafsilroq ko'rib chiqaylik xizmat ko'rsatish jamoasi. Biz doimo ishlashimiz va ushbu xizmatni taqdim etayotganlar bilan juda yaqin aloqada bo'lishimiz kerak bo'ladi.
Jamoadagi odamlar ikki toifaga bo'lingan: konservatorlar — eski dunyoda yashang yoki DevOps haqida hech narsa bilmayman va innovatorlar, bu barcha moda amaliyotlarini tortadi. Ikkinchisi har doim ham mavzuni tushunmaydi, lekin hech bo'lmaganda ular bunga tayyor.
Bir tomondan, konservatorlar tajribali odamlardir: ular uzoq vaqt davomida kompaniyada bo'lishgan, ular buni ichkarida va tashqarida tushunishadi, lekin amaliyotlar haqida aniq bilishmaydi. Boshqa tomondan, biror narsa eshitgan, lekin kompaniyada uzoq vaqt ishlamagan innovatorlar bor. Qaysi biri bilan ishlash yaxshiroq?
Siz har qanday holatda ham konservatorlar bilan muloqot qilishingiz kerak bo'ladi, chunki bu ularning xizmati. Siz ular bilan bog'lanishingiz, xizmatning o'ziga xos xususiyatlarini, shu tarzda nima qilish mumkinligini va yana nimalarni bilib olishingiz kerak bo'ladi. Biz ularning maslahatiga ishonamiz. Ehtimol, siz ularga biror narsani ishonib topshirishingiz kerak bo'ladi, chunki ular o'z xizmatlarini yaxshiroq bilishadi. Shunday ekan, qaysi jamoa bilan aloqada bo'lishimiz muhim.
Jamoa uchun innovatorlarni tanlash mantiqan to'g'ri, chunki konservatorlar unga cho'chqa qo'yishlari mumkin.
Amalda, ko'pincha konservativ odamlar katta tajribaga ega, ammo bundan keyin qanday yashashni tushunmaydilar. Ular xizmatni o'zgartirish va qayta loyihalashdan so'ng, ular keraksiz deb ishdan bo'shatilishidan qo'rqishadi. Ba'zan ular nima bo'layotganini tushunmasliklari uchun ishni sabotaj qilishadi.
Menda shunday holat bor ediki, jamoadagi bir yigit hamma narsani tuzatdi, chunki bu bizning hozir qilayotgan ishimizdan ko'ra muhimroq edi. Biz vazifa qo'ydik: bugun bu asarni amalga oshirish - yo'q, dunyoning narigi tomonida yong'in bor, biz uni tuzatmoqchimiz. Bunday odamlar bilan ishlash qiyin.
Konservativ jamoadagi odamlar ko'pincha vazifalarni unutishadi yoki ularni oxirgi daqiqaga qoldiradilar. Va agar, Jon Uillis taqiqlasa, siz xatoga yo'l qo'ygan bo'lsangiz va ularga bajarilgan vazifalar soni uchun KPI tayinlagan bo'lsangiz va ba'zi sabablarga ko'ra KPI ga kiritilmagan bo'lsa, ular umuman hech narsa qilmaydi. Umuman olganda, ular to'g'ri bo'ladi, chunki keyin ular bonusni yo'qotadilar.
Innovatorlar bilan osonroq - ular sodiqroq. Ular allaqachon biror narsani eshitishgan, ular biror joyga borishni xohlashadi, shuning uchun ular yordam berishadi. Bizga birinchi marta azob chekishga tayyor bo'lgan odamlar kerak: agar xizmat o'zgarsa, innovatorlar kashshof sifatida barcha zarba va tirmalarni ushlaydi. Innovatorlar hamma narsani yangi va moda bo'lishini xohlashadi va azob chekishadi.
Konservatorlar keyinchalik konvertatsiya qilinishi mumkin. Biror narsani o'zgartirganingizni va hamma narsa yaxshi ishlayotganini ko'rsatsangiz, ular ham buni sinab ko'rishni xohlashadi va yangi DevOps dinini qabul qilishadi.
Keling, xulosa qilaylik. Agar biz kompaniyamizdagi barcha o'zgarishlarni o'zimiz amalga oshirsak, unda biz tanlaymiz: yangi xizmat, uning buzilishidan juda ko'p azob chekmaslik uchun oddiy interfeys va innovatorlar jamoasi.
Agar yangi maslahatchi o'rniga tashqi maslahatchini chaqirish mumkin bo'lsa, biz eski xizmatni qabul qilamiz, buning natijasida biz allaqachon azob chekmoqdamiz. Turli kompaniyalarda uzoq vaqt davomida transformatsiya bilan shug'ullangan odamlar turli xil holatlarni ko'rishgan va buni qanday qilib to'g'ri bajarish kerakligini va umuman olganda qaysi yo'nalishga borishni tushunishgan.
Kim ishtirok etadi?
Biz hech bo'lmaganda xizmatga aloqasi bo'lgan har bir kishini topishimiz kerak: ishlab chiquvchilar, testerlar, administratorlar, xavfsizlik bo'yicha mutaxassislar, menejerlar va, ehtimol, mahsulot egalari. Mahsulot egalari texnik mutaxassis bo'lmasalar ham, ular xizmat bilan bog'liq: ular qarorlar qabul qiladilar, vazifalarni qo'yadilar.
Hech bo'lmaganda ba'zi qarorlar qabul qiladigan va xizmat bilan nima sodir bo'lishiga ta'sir qiladigan har bir kishi topilishi, uchrashishi va muloqot qilishi kerak.
Ular bizga nima uchun kerak? Kim bilan muzokara qilish kerakligini bilish uchun. Transformatsiya paytida, xizmat bilan ishlashning odatiy printsipi o'zgarganda, u hali ham silkitadi. Biz yangi yondashuvlarni sinab ko'rayotganimizda bir muddat nosozliklar bo'ladi. Odamlar bunga tayyor bo'lishi va bunga rozi bo'lishi kerak.
Keyinchalik siz Value Stream xaritasini yaratishingiz kerak bo'ladi va bu odamlarsiz siz uni qura olmaysiz, chunki faqat ularning barchasi birgalikda nima sodir bo'layotganining to'liq rasmini bilishadi. Bir kishi hech qachon xizmat bilan sodir bo'lgan hamma narsani bilmaydi.
Ular jamoaga odamlarni tavsiya qiladilar.Alohida jamoa nima uchun kerakligini keyinroq muhokama qilamiz. Bu mavjud bo'limlardan odamlarni olishi kerak bo'ladi. Xizmatga jalb qilinganlar bizning yo'nalishda fikrlaydigan, bizga yordam bera oladigan va bizga kerak bo'lgan ishda malakali hamkasblarini tavsiya qilishlari mumkin.
Keyinchalik, biz turli bo'limlardagi barcha odamlarni bitta xonaga to'playmiz va qiymat oqimi xaritasini yaratishni boshlaymiz.
Qiymat oqimi xaritasini yaratish
Qiymat oqimi xaritasi - mijozga qiymatlar oqimini ko'rsatadigan diagramma yoki xarita. Bu g'oyani ishlab chiqishdan tortib uni amalga oshirishgacha bo'lgan butun jarayon, shu jumladan barcha oraliq bosqichlar va oxir-oqibat bizning mijozlarimizga qiymat qanday etib borishi.
Buning uchun Value Stream Map kerak rivojlanishning barcha bosqichlarini tasavvur qiling, joriy jarayonda mavjud bo'lgan o'lchovlar orqali muammolarni mahalliylashtirish va bu muammolarni bartaraf etishga kirishish, va boshlang'ich maqsadni qo'ying. Bu erda biz haqiqatan ham biror narsa qilishni boshlaymiz.
Ko'rsatkichlar
Value Stream Map adabiyotida tasvirlangan juda ko'p turli ko'rsatkichlar mavjud, ammo bizni boshlash uchun faqat uchtasi kifoya.
Yetkazib berish vaqti - kechikish / kutish - biz nimanidir kutayotgan vaqt. Misol uchun, tester test stendi bo'sh qolguncha kutadi va bu vaqt ichida hech narsa qila olmaydi.
Qo'shilgan qiymat vaqti - foydali ish vaqti - foydalanuvchi uchun yakuniy qiymatni yaratish uchun falon bosqichda nima sarfladik. Misol uchun, tester o'z testini ishga tushirdi va nimanidir tekshira boshladi. Bu foydali ish vaqti, biz aslida mahsulot uchun biror narsa qilamiz. Bu mijozlar to'laydigan narsa - sifatli dasturiy ta'minot.
%C/A – qabul qilingan ishlarning foizi. Bizda bir bosqich - rivojlanish, ikkinchi bosqich - test. Testerlar ishlab chiquvchilardan qancha xususiyatlarni qabul qilganligi bu foiz.
Bizning xaritamiz taxminan shunday ko'rinadi.
Tashkilot tuzilishiga, bo'limlar soniga va nima qilayotganingizga qarab u boshqacha ko'rinishi mumkin. Ammo, umuman olganda, xaritada ikki bosqich bo'ladi: fikr и tahlil qilish. Ushbu bosqichda ma'lumotlar kutilmoqda, masalan, etkazib berish muddati 2 hafta va qo'shilgan qiymat vaqti 2 kun.
Biz metrikalar bilan mutlaqo barcha bosqichlarni qamrab olamiz.
Orqa tomosha — tahlilchilar o‘ylab topganidan keyin qancha muammolar bor edi.
Rivojlanish - ishlab chiquvchilar necha haftadan beri vazifalar, stendlar yoki jihozlar bo'yicha aniqlik kiritishni kutishmoqda - bu muhim emas, lekin ular nimanidir kutishmoqda. Masalan, biror xususiyatni amalga oshirish uchun ularga 4 kun kerak bo'ladi. Bu erda %C/A ko'rsatkichi keladi. Ishlab chiquvchilar Backlogdagi vazifalarning atigi 80 foizini oldilar. Ularning fikricha, qolgan 20% yetarlicha aniq texnik shartlarga ega emas va ularni qayta ko‘rib chiqish uchun yuborgan.
Viktorina. LT diagrammasi 4 kunga o'rnatiladi. Misol uchun, testerlar test stendining bo'sh bo'lishini kutishgan, VA ular aslida 2 kun davomida nimanidir sinab ko'rishgan va %C/A = 40%. — ishlab chiquvchilar tomonidan yuborilgan kod yoki funksiyalarning atigi 40% sinovchilar tomonidan adekvat deb topildi. Ular negadir qolgan hamma narsani yoqtirmasdi.
Men ushbu o'lchovlarni qanday amalga oshirish haqida batafsil to'xtalmayman, maqolaning oxirida men ular haqida bilib olishingiz mumkin bo'lgan adabiyotlarni tavsiya qilaman.
Tavsiya qilishim mumkin bo'lgan yagona narsa, siz bilan Value Stream xaritasini tuzadigan odamlarga ishonmasligingizdir. Ular turli jarayonlar qancha davom etishi haqida fikr beradi, ammo bu taxminlar har doim ham to'g'ri emas, shuning uchun o'zingizni o'lchashingiz yaxshiroqdir.
Operatsion bo'limiga kelganimizda va yangi xususiyatni ishlab chiqarishga etkazib berish qancha vaqt kerakligini so'raganimizda, bizda shunday holat bor edi. Ular bizga 10 daqiqa bo'lishini aytishdi va biz nima uchun bu kompaniyaga keldik? Ma'lum bo'lishicha, 10 daqiqa - bu kodni qabul qiluvchi va uni serverga etkazib beradigan skriptning ishlash vaqti. Ammo bundan oldin reliz serverda uch kun o'tiradi va shunchaki chang to'playdi - orqada qo'yilishi kerak bo'lgan vazifa mavjud. Ma'lum bo'lishicha, joylashtirish bosqichidan oldin loyiha shunchaki o'tirganda kutish bosqichi mavjud. Agar biz bloknot bilan bormaganimizda, Jiradagi vazifaga e'tibor qaratmaganimizda va uni bosqichma-bosqich kuzatishni boshlaganimizda, biz hamma narsa ajoyib va hech qanday muammo yo'q deb o'ylagan bo'lardik.
Shuning uchun, haqiqatga yaqin fikrga ega bo'lish uchun siz hali ham o'lchovlarni o'zingiz qilishingiz kerak bo'ladi, tercihen bir necha marta. Value Stream xaritasiga qarab, siz qaerdan boshlash va birinchi navbatda nimani tuzatish kerakligini hal qilasiz.
Vaqtinchalik jamoa
DevOps-ni amalga oshirishga qaror qilgan ko'plab kompaniyalar vaqtinchalik emas, balki bir necha yillardan beri mavjud bo'lgan jamoani yaratadilar. Agar siz DevOps-da tashkiliy tuzilmani qurishning turli naqshlarini tavsiflovchi DevOps uzr so'rash xizmatiga kirsangiz, bu anti-naqsh ekanligini tushunasiz.
Agar DevOps jamoasi bir necha yil davomida doimiy ravishda mavjud bo'lsa, bu katta xato, chunki DevOps bo'limlar o'rtasidagi aloqa, tezlik va samaradorlik haqida.
Agar jamoa bo'limlar o'rtasida faqat boshqa alohida ishlarni bajarish uchun mavjud bo'lsa va uzoq vaqt mavjud bo'lsa, u keraksiz to'siqni yaratadi. Endi dasturchi muammoni hal qilish uchun darhol administratorga murojaat qilish o'rniga, avvalo DevOps bo'limiga murojaat qilishi kerak va u davom etadi.
Shuning uchun, boshlash uchun siz vaqtinchalik jamoani yaratishingiz kerak. Bu biz tanlagan bitta cheklovni yo'q qilish uchun shartli ravishda olti oy, eng ko'pi bir yil, topshirilgan vazifaga qarab mavjud bo'ladi. Keyin u o'ladi. Agar biz juda og'riqli keyingi nuqtani tanlasak va buning uchun alohida jamoa kerakligini tushunsak, uni yana yaratamiz. Ammo bunday jamoalar "doimiy asosda" mavjud bo'lmasligi kerak - keyin ular faqat aloqani buzadi va umuman biror narsa qilish uchun alohida vazifalarni oladi. Bu vazifalar DevOps yoki transformatsiya bilan bog'liq bo'lmasligi mumkin. Nega bu vazifani mavjud bo‘limlarga bermaymiz?
Vaqtinchalik jamoa nima uchun kerak?
Joriy jarayonlar bilan ziddiyat. DevOps transformatsiyasi nafaqat biz foydalanadigan texnologiyalar va vositalarning o'zgarishi, balki ish, fikrlash va qadriyatlar jarayonining o'zgarishidir. Agar jamoa o'ziga xos tarzda ishlasa, u boshqa yondashuvlarni sinab ko'ra olmaydi.
Bu odamlar turli qoidalar bilan yashashlari kerak: kompaniyadagi barcha KPIlarni e'tiborsiz qoldiring, chunki ular boshqacha ishlashga harakat qilishadi. Vaqtinchalik jamoalar server olish uchun arizalarni to‘ldirmaydi, balki ularni boshqaradigan bo‘limga to‘g‘ridan-to‘g‘ri borib, ularga birinchi navbatda kerakli narsani berishni talab qiladi, chunki bu ustuvor vazifa va ular boshqacha yashashga harakat qilishadi. Jamoa barcha joriy jarayonlar bilan to'liq ziddiyatda. Mavjud ish amaliyotlari hozir ularga xalaqit bermasligi va boshqalarga xalaqit bermasligi uchun biz bu odamlarni alohida jamoaga ajratamiz.
Tajribalarda byurokratiyadan qochish. Vaqtinchalik jamoalarda byurokratiya yo'q, ular vaqt hisobotini taqdim etmaydilar, menejerlarga hisobot bermaydilar. Bu butunlay alohida dunyo bo'lib, unda odamlar boshqacha yashaydi va o'ylaydi va butunlay boshqa narsalarni qiladi. Ularni yana bezovta qilishning hojati yo'q.
Xizmatda uzluksiz ishlash. Birinchi nuqtada biz tajriba o'tkazadigan narsani tanladik. Tajriba qilish va yaxshiroq ishlash yo'llarini topish yaxshi, lekin biz xususiyatlarni ham yaratmoqchimiz. Agar butun jamoa xususiyatlar o'rniga transformatsiyaga e'tibor qaratsa, biz daromadni yo'qotishni boshlaymiz, xatolar uzoq vaqt davomida saqlanib qoladi - bizga bu kerak emas. Vaqtinchalik jamoani yaratish mahsulot ustida ishlashni to'xtatmasdan tajriba o'tkazish imkonini beradi.
Ish vazifalariga vaqt sarflamang. Bu yana mahsulot haqida. Boshqa vositalar va narsalarni sinab ko'rish uchun jamoaga ko'p vaqt kerak bo'ladi. Odamlar asboblarni o'zlashtirishlari, ularni amalga oshirishni boshlashlari va odatdagidek foydalanishlari uchun kamida olti oy kerak bo'ladi. Agar ular mahsulotga ham e'tibor qaratishsa, olti oy kosmik jihatdan cho'ziladi. Agar odamlar mahsulot ustida ishlasa, ular yana eski jarayonlar bilan ishlaydilar - bu bizga kerak emas.
Shuning uchun biz turli bo'limlardan odamlarni xizmatni o'zgartiradigan alohida guruhga tayinlaymiz. Natijada, xizmat ishlaydi, rivojlanishda davom etmoqda va shu bilan birga biz bu borada ba'zi tajribalar o'tkazamiz.
Vaqtinchalik jamoa faqat DevOps-ni o'zgartirishga bag'ishlangan - biz topgan cheklovni yo'q qiladi va boshqa hech narsa yo'q.
Jamoa ko'p qirrali odamlardan iborat. Bu biz nafaqat ishlab chiquvchilarni yollaganimizni anglatadi. Biz xizmat ko'rsatish markaziga kelmadik va u erdan jamoaning yarmini olmadik - yo'q, biz oldik turli bo'limlardan kelgan odamlar. Bir necha daqiqa oldin biz o'zgartirilgan xizmat bilan bog'liq bo'lgan turli bo'limlar va turli xodimlarni topdik. Biz ulardan jamoani jalb qilmoqdamiz, chunki u universal bo'lishi kerak - biz sinov jarayonini, ishlab chiqish jarayonini va xizmat ko'rsatish jarayonini o'zgartiramiz. Turli xil malakalar talab qilinadi.
Odatda biz ishlab chiquvchi, tester va muhandisni birma-bir qabul qilamiz va ular bilan birgalikda boshqacha yashashga imkon beradigan yechimni topamiz.
Bu odamlar tashkilotda vakolatga ega bo'lishlari ma'qul. Siz xohlamasangiz ham, bitta konservativni olishingiz kerak bo'lishi mumkin. Agar bizda katta kompaniya bo'lsa, hamma ham bizning g'oyamizga ishonmaydi va ba'zilar, masalan, stendni taqdim etmasdan, bizning g'ildiraklarimizga spiral qo'yishlari mumkin. Bu erda sizga "hokimiyat" kerak bo'ladi - katta tajribaga ega, hamkasblarining yaxshi munosabatini qozongan hurmatli odam. Jamoadagi xodimning vakolati vaqtinchalik jamoaning vazifasi va ishini soddalashtiradi. Odamlar shunday deb o'ylashadi:
- Ha, biz hammamiz biladigan va yaxshi ko'radigan bu ajoyib do'st u erda - DevOps-da ko'rishga arziydigan narsa bor shekilli!
Maqsad qo'yish
Biz odamlarni to'pladik, xizmatni tanladik, cheklovlarni ko'rib chiqdik va qaysi odamlarga ta'sir qilishimizni aniqladik. Endi siz maqsad qo'yishingiz kerak va u to'g'ri bo'lishi kerak SMART tomonidan - biz sevadigan hamma narsa.
Maxsus - o'ziga xos.
O'lchanadigan - o'lchanadigan. Bu juda muhim SMART nuqtasi. Agar biror narsani o'lchay olmasangiz, unda siz uni o'zgartira olmaysiz va nimani va qanday qilib yaxshiroq yoki yomonroq qilganingizni tushunolmaysiz.
erishish mumkin - erishish mumkin. Muayyan ehtiyojlaringizga mos keladigan tuzatishlar kiriting. Agar siz uzoq tarixga ega va yiliga bir marta mahsulot versiyasini chiqaradigan katta mas'uliyatli korxona bo'lsangiz, unda siz olti oy ichida har soatda mahsulotning yangi versiyalarini chiqarishga erisha olmaysiz. Bu shunday ishlamaydi. Shuning uchun, maqbul vaqt oralig'ida erishish mumkin bo'lgan real maqsadni qo'ying.
Tegishli - tegishli. Biz faqat hozirgi maqsadlarimizga xizmat qiladigan cheklovlarni olib tashlaymiz.
Vaqt cheklangan - vaqt cheklangan. Agar muddat bo'lmasa, jamoa xohlagan narsani qiladi: 15 ta o'rniga 3 ta texnologiyani sinab ko'ring, katta hisobotlar yozing, foydasiz tadqiqotlar o'tkazing, maqsadga erishilgandan keyin porlashigacha ularni amalga oshirishni jilolang.
Biz maqsadni Value Stream Map yordamida olamiz - biz yana barcha odamlarni yig'amiz va ularni chizamiz. Lekin faqat hozir, oldingi Value Stream Map asosida, biz olishni xohlagan narsani chizamiz.
Biz hozirda yo'q qiladigan bitta cheklovni ta'kidlaymiz - jamoa shunday qiladi. Misol tariqasida, men tugallangan relizdan uni ishlab chiqarishga joylashtirishgacha kutishni oldim - bu odamlar maslahatchilarga murojaat qiladigan eng keng tarqalgan cheklovdir.
Shunga asoslanib, biz vazifani qo'ydik: biz tugallangan reliz va jangga kirish o'rtasidagi kutish maksimal bir soat bo'lishini xohlaymiz.
Vazifalarga misollar.
- Sinov muddatini 4 kundan 1 soatgacha qisqartiring.
- Sinov uchun qo'shimcha qiymat vaqtini 2 kundan 3 soatgacha qisqartiring.
- O'rnatish vaqtini 5 soatdan 10 daqiqagacha qisqartiring.
- C/A ni 50% dan 95% gacha oshirish, ya'ni testerlar qabul qiladigan xususiyatlar sonini oshirish, boshqacha qilib aytganda, ishlab chiquvchilar ish sifatini yaxshilash.
Vazifalar misollari bizning boshimizdan olinmaydi - ular qiymat oqimi xaritasini ishlab chiqishda qilgan o'lchovlarga asoslanadi.
Biz jamoamiz oldiga xuddi shunday vazifa va vaqt chegarasini qo'yganmiz. Sizning kompaniyangiz qanchalik yaxshi ishlayotganiga qarab, siz turli muddatlarni belgilaysiz. Agar odamlar buni birinchi marta qilayotgan bo'lsalar va qanday texnologiyalar yordamida va qanday qilib muammoni hal qilishlarini hali bilmasalar, cheklovni bartaraf etish uchun o'rtacha olti oy kerak bo'ladi.
Qisqa rejalashtirish
Demak, jamoamiz yaratilgan, uning maqsadi bor, odamlar ishlay boshlaydi. Muhim nuqta - ishni qisqacha rejalashtirish: bir-ikki hafta sprintva boshqa emas, o'lchanadigan yaxshilanishlar har hafta va kursni tuzatish.
Misol uchun, biz tez-tez yondashuvdan foydalanamiz harakatlanuvchiHar haftaning boshida butun jamoa yig'ilsa, hamma nima qilishini faylga yozib qo'yadi. Bir hafta o'tgach, biz nima qilinganligini va nima qilinmaganini, agar bo'lmasa, nima uchunligini qayd qilamiz va bundan keyin nima qilish kerakligini o'ylaymiz.
Sprintlar kursni o'z vaqtida tuzatishga imkon beradi.
Bir yoki ikki hafta davomida siz nimanidir sinab ko'rdingiz: texnologiyalar, yondashuvlar, ishlash usullari, shundan so'ng siz yana o'lchab ko'rasiz - bu yondashuv bilan yaxshiroq yoki yomonroq bo'ldimi? Agar u yomonroq bo'lsa, bu biz noto'g'ri yo'nalishda ketayotganimizni anglatadi, biz kursni to'g'rilashimiz kerak: boshqa vazifani qo'ying, boshqa texnologiyani oling yoki boshqa biror narsa qiling. 1-2 haftalik qisqa sprintlar sizga manevr qilish va o'z vaqtida noto'g'ri qarorlardan qochish imkonini beradi.
Muvaffaqiyatni baham ko'rish
Jamoa kichik yoki katta muvaffaqiyatlarga erishadi - bu muhim emas, har doim qandaydir natija bo'ladi. Bu natija haqida hamma bilishi kerak: DevOps bilan shug'ullanuvchilar ham, qo'shni bo'limlar ham. Ideal dunyoda buning umuman kelishi ma'qul bo'lardi kompaniyadagi barcha odamlarga.
Nima uchun? Agar biz kompaniyaning bir qismini emas, balki faqat bitta cheklovni emas, balki umuman hamma narsani o'zgartirmoqchi bo'lsak, kompaniya moslashuvchan bo'lib, kod tezda mijozga etib boradi va hech narsa buzilmaydi, biz hammamiz g'oyaga sodiq bo'lishimiz kerak. DevOps. Siz bunga qat'iyan qarshi bo'lgan xizmatlar va jamoalarga yondashuvni qo'llay olmaysiz.
Sadoqat paydo bo'lishi uchun biz buni sinab ko'rganimizni hammaga aytishimiz kerak - bizda natijalar bor, siz ham sinab ko'ring! Bu biz qilayotgan ishimizga qiziqish va sodiqlikni oshiradi, odamlar hozirdanoq biror narsa qilishga harakat qila boshlaydilar. Amaliyot shuni ko'rsatadiki, biz nimaga harakat qilganimizni va nimaga erishganimizni aytsak, boshqa jamoalar qanday qilib va nima qilganimizni so'rashni boshlaydilar. Ular ilovalar, kodlar, hujjatlarni ko'rib chiqadilar, savollar tug'diradilar va o'zlarida nimanidir o'zgartirishga harakat qilishadi.
Nima qilganingiz haqida gapirish juda muhim. Shunday qilib, siz hamma narsani eski usulda qilishni xohlagan konservatorlarni lageringizga qo'shilishga va ularni innovatorga aylantirishga ishontirasiz.
jami
Xizmatni tanlash, boshlang'ich nuqtasi sifatida - biz kompaniyadagi o'zgarishlarni boshlaydigan joy. Biz xizmatga aloqasi bo'lgan har bir kishini aniqlaymiz va ular bilan qiymat oqimi xaritasini yaratish, biz o'lchaymiz va qaerda va qanday cheklovlar borligini ko'ramiz.
Yangi vaqtinchalik jamoani yaratish, bu muammoni hal qiladi. O'lchovlar va qiymat oqimi xaritasi asosida biz yangi xarita chizamiz, u erda biz hal qiladigan cheklovni ta'kidlaymiz. Ushbu cheklov asosida vazifa qo'ying, bu bilan jamoa shug'ullanadi. Vazifa bo'lishi kerak albatta SMART - o'ziga xos, o'lchanadigan, joriy vazifalarga tegishli va vaqt bilan cheklangan.
Jarayonni takrorlang, biz mutlaqo barcha xizmatlarimizni kerakli shaklga aylantirmagunimizcha va barcha cheklovlarni bartaraf qilmagunimizcha.
Bonus. Foydali materiallar
DevOps-ni mustaqil ravishda qilishga qaror qilganlar uchun.
"Feniks" loyihasi
Asl nomi "Feniks loyihasi: bu haqda roman, ishlanmalar va biznesingizga g'alaba qozonishga yordam berish". Bu DevOps haqidagi roman - xodim qanday qilib doimo yonib turgan bo'lim boshlig'i etib tayinlangani haqidagi hikoya. Yangi boshliqqa vazifa berildi:
"Sizda hamma narsani to'g'ri yo'lga qo'yish uchun bir necha yil vaqtingiz bor, shunda biz nihoyat o'z mahsulotimizni mijozlarimizga tez va samarali yetkazib bera olamiz."
"Feniks loyihasi" DevOps hayotni yaxshi tomonga o'zgartirishi haqidagi roman" bu barcha menejerlar uchun kitobdir, chunki kompaniyada nima sodir bo'lishi haqida qaror qabul qiladigan odamlardir. Agar siz muhandis yoki dasturchi bo'lsangiz va kompaniyangizda harakat va o'zgarishlar boshlanishini istasangiz, kitob sotib oling va uni rahbariyatga bering. Ushbu roman hamma narsani tushuntiradi va tez va oson o'qiladi.
DevOps qo'llanma
Kitob yanada murakkabroq. U bir necha yil oldin ingliz tilida “The DevOps Handbook qanday qilib texnologiya tashkilotlarida jahon darajasidagi chaqqonlik, ishonchlilik va xavfsizlikni yaratish mumkin” nomi bilan nashr etilgan, ammo hozir u rus tilida ham mavjud. Bu haqiqiy qo'llanma - amaliy qo'llanma: o'lchovlarni qanday amalga oshirish kerak, Value Stream Map nima va u nima uchun kerak, qaerga borish kerak, qanday tartibda. Kitob faqat hamma narsani o'zi qilishni xohlaydiganlar uchun. Eng muhimi, unda boshqa kompaniyalar tajribasidan misollar keltirilgan.
Misol uchun, u qanday qilib bir kompaniya Value Stream Map-ni yaratgani va uning cheklanishi mahsulotda emasligini, balki kassirning ushbu mahsulotdan foydalanish uchun do'kondan keyingi ofisga yurishida ekanligini tushunganini aytadi. Dastur bilan muammoni hal qilish o'rniga, ular oddiygina sotuvchilari uchun planshetlar sotib oldilar va endi hech kim hech qaerga bormaydi va barcha harakatlar ish joyida amalga oshiriladi. Xulosa: Value Stream Map nafaqat dasturiy ta'minotga, balki tashkilotdagi barcha jarayonlarga ham kengaytirilishi mumkin.
tezlashtirish
To'liq sarlavha: "Tezlashtiring: tejamkor dasturiy ta'minot va DevOps fani: yuqori samarali texnologiya tashkilotlarini qurish va kengaytirish." Bu keyingi daraja - hardkor. Kitob o'tgan yili nashr etilgan, hozircha faqat ingliz tilida va tadqiqot haqida. Mualliflar - Nikol Forsgren, Jez Humble va Gen Kim - ko'p yillar davomida turli kompaniyalarda turli xil amaliyotlardan foydalanib, qaysi amaliyotlar nima va qanday ta'sir qilishini o'rganishgan.
O'lchov bo'yicha ikkinchi bobda Qiymat oqimi xaritasi, men aytib o'tgan ko'rsatkichlar va boshqalar haqida so'z boradi, shuningdek, o'lchash jarayoni batafsil tavsiflanadi. Mualliflar anketalar va o'z-o'zini kuzatish vazifalari yordamida o'lchaydilar. Qaysi ko'rsatkichlarni o'lchash uchun to'g'ri ekanligini, qaysilarini o'lchamaslik kerakligini va o'lchovlardagi inson xatolarini batafsil tavsiflaydi. Agar siz o'lchovlarda qiyinchiliklarga duch kelsangiz, "Tezlash" kitobining ikkinchi bobiga qarang. Agar sizning jamoangiz juda ko'p amaliyotlarga ega bo'lsa, lekin hozir qaysi amaliyotlarni qo'llash kerakligi, qaysi biri keyinroq, qaysi biri haqiqatan ham ishlaydi va qaysi biri ishlamasligi aniq bo'lmasa - o'qing, kitobda hamma narsa tushuntiriladi.
Transformatsiya - bu DevOps va boshqaruv kesishmasidagi muammo. Rivojlanish, operatsiyalar va sinovlar kesishgan joyda biz muhokama qilishga harakat qiladigan mavzulardir. , sifatli mahsulotni yaratish uchun bir xil integratsiya kerak - asosiy mavzu . Festivalni boshqarish tomonidan taqdim etilgan - demak, hamma o'zgarish uchun g'oyalar uchun u erda. 27 va 28 may kunlari bizga qo'shiling, biz birlashamiz va o'zgartiramiz.
Manba: www.habr.com
