როგორ დავიწყოთ DevOps ტრანსფორმაცია

თუ არ გესმით რა არის DevOps, აქ არის სწრაფი მოტყუების ფურცელი. DevOps არის პრაქტიკის ერთობლიობა, რომელიც ამცირებს ინჟინრების შიშებს და შეამცირეთ შეცდომების რაოდენობა პროგრამული უზრუნველყოფის წარმოებაში. როგორც წესი, ისინი ერთნაირია შეამცირეთ დრო ბაზარზე — პერიოდი იდეიდან მომხმარებლამდე საბოლოო პროდუქტის მიწოდებამდე, რაც საშუალებას გაძლევთ სწრაფად განახორციელოთ ბიზნეს ექსპერიმენტები.

როგორ დავიწყოთ DevOps ტრანსფორმაცია? მოკლედ: ჩვენ ვირჩევთ სერვისს, რომლითაც უნდა დავიწყოთ პროცესი, იდენტიფიცირება, ვინც დაკავშირებულია სერვისთან, ვაშენებთ Value Stream Map-ს, ვქმნით დროებით გუნდს, რომელიც პირველად გაუმკლავდება ტრანსფორმაციას და დასახავს დავალებას. ჩვენ ვიმეორებთ ციკლს საჭირო რაოდენობის ჯერ.

დეტალური DevOps ტრანსფორმაციის გეგმა მაგალითებით და ინსტრუქციებით ჭრილში - ტრანსკრიპტში ანგარიში ანდრეი ალექსანდროვი - ინჟინერი Express42-ში, რომელიც ურჩევს DevOps-ის გაშენებას, აჩქარებს ამ პროცესს, რადგან მან უკვე შექმნა საკომისიო რუკა. თუ გეჩვენებათ, რომ არ გჭირდებათ ტრანსფორმაცია, ან თქვენი სპეციფიკა ისეთია, რომ DevOps პრაქტიკა არ არის შესაფერისი, გამოიყენეთ ანგარიში, როგორც ინსტრუქციები შეზღუდვების პოვნისა და აღმოფხვრის მიზნით.

თუ თქვენ გაწუხებთ DevOps ტრანსფორმაციის საკითხი, მაშინ თქვენ გაქვთ დიდი კომპანია და თქვენ უნდა თანდათან გააფართოვოთ ეს პროცესი მთელ სტრუქტურაში. სანამ საჭიროა ბრძანების გარდაქმნა ან რაიმე შეზღუდვის აღმოფხვრა, ქვემოთ მოცემული ალგორითმი შეიძლება განმეორდეს.

სერვისის შერჩევა

ჩვენ ჩამოვწერეთ გეგმა, დავიწყოთ პირველი ნაბიჯით - სერვისის არჩევით. პირველი კრიტერიუმი სიცოცხლის ხანგრძლივობაა: არის ძველი სერვისები - მემკვიდრეობითი და ახლები. შეგიძლიათ დაიწყოთ ორივე.

ლოგიკურია აირჩიოს ახალგაზრდა სერვისი. ახალია, ჯერ არ არის ჩამოყალიბებული პროცესი გუნდში მუშაობისთვის, რომელიც მას ეხება. ირგვლივ ტექნიკური დავალიანების მთა არ არის, თქვენ არ გჭირდებათ მისი გამუდმებით გამოსწორება. ჩვენ შეგვიძლია გავაკეთოთ ის, რაც გვინდა.

ძველი სერვისის შემთხვევაში, პრობლემებია იმასთან დაკავშირებით, რომ ცვლილება ყოველთვის რთულია. უკვე არსებობს გარკვეული სერიოზული შეზღუდვები, მაგრამ, შესაძლოა, მათ ებრძვიან ადამიანები, რომლებიც მზად არიან ნიჩბების გადასაჭრელად - ისინი დაღლილები არიან და სურთ რაღაც სხვანაირად გააკეთონ, რადგან ტკივილები არიან.

ძველ სერვისთან მუშაობა ძლიერ პრეცედენტს ქმნის თქვენს კომპანიაში - შეგიძლიათ შეცვალოთ რაღაც. თუ ახალ სერვისს შეცვლით, ის საათში 100-ჯერ ჩამოდის და ყველაფერი კარგადაა, მაშინ თქვენი კომპანიის ადამიანებმა შეიძლება თქვან:

- ეს ახალი სერვისია! იქ ყველაფერი მარტივი იყო, სცადე რამე გააკეთო ჩვენს ნანგრევებთან.

აზრი აქვს Legacy სერვისის გამოყენებას ტრანსფორმაციისთვის, როდესაც ამას აკეთებთ ვინმესთან ერთად, მაგალითად, თუ მოიწვიეთ გარე კონსულტანტი. ვიყოთ გულწრფელები, ტრანსფორმაცია შეარყევს ყველაფერს, რაც შესაძლებელია. თქვენ ატარებთ ექსპერიმენტებს და არ იცით სად მოხვდებით, რა ტექნოლოგიებს გამოიყენებთ და რატომ, სად და რა ხარვეზები წარმოიქმნება პროცესებში. ამიტომ, ახლის შეცვლა უფრო ადვილია.

თუ ყველაფერს თავად აკეთებთ და კომპანიას არ აქვს სერიოზული კომპეტენცია, ჩვენ ვიღებთ ახალ სერვისს. თუ იცნობთ გარე კონსულტანტს და გაქვთ სახსრები, აირჩიეთ ძველი.

არის სერვისები, რომლებიც უბრალოდ ინტერფეისია მომხმარებლებისთვის, მაგალითად, მარტივი ვებსაიტი ან მობილური აპლიკაცია. მაგრამ არის სერიოზული რამ ბილინგის სულისკვეთებით. თუ რამე არასწორია ბილინგის დროს, რთული იქნება ამის გარკვევა. აქაც გვაქვს არჩევანი.

ჩვენც ვმუშაობთ კრიტიკული სერვისით, მაგრამ ამის გამო ვიტანჯებით, შეზღუდვებს ქმნის, ან ვმუშაობთ ინტერფეისით. ეს არის მეორე შერჩევის კრიტერიუმი. ანალოგიურად, შესაძლებელია გამოცდილი კონსულტანტის მოზიდვა - ჩვენ ვმუშაობთ რთულ ვარიანტზე.

მაგრამ ამ შემთხვევაშიც არ გირჩევთ ამის გაკეთებას, რადგან სანამ არ გაიგებთ, რასთან უნდა იმუშაოთ და რა მიმართულებით უნდა გარდაქმნათ, კრიტიკული ნივთის აღება და მისი შერყევა არც ისე კარგი იდეაა. ამიტომ, ამ შემთხვევაში, ჩვენ გვირჩევნია ვიმუშაოთ ინტერფეისით, რომლის წარუმატებლობა არ არის კრიტიკული.

მოდით უფრო შორს გადავხედოთ მომსახურე გუნდი. ჩვენ მოგვიწევს მუდმივი მუშაობა და ძალიან მჭიდრო ურთიერთობა მათთან, ვინც ამ სერვისს უზრუნველყოფს.

გუნდში ხალხი იყოფა ორ კატეგორიად: კონსერვატორები — ცხოვრობთ ძველ სამყაროში, ან უბრალოდ არ იცით არაფერი DevOps-ის შესახებ და ინოვატორები, რომელიც გადაათრევს ყველა მოდურ პრაქტიკას. ამ უკანასკნელებს ყოველთვის არ ესმით თემა, მაგრამ მაინც მზად არიან ამისთვის.

ერთის მხრივ, კონსერვატორები გამოცდილი ადამიანები არიან: ისინი დიდი ხანია არიან კომპანიაში, ესმით შიგნითაც და გარეთაც, მაგრამ ზუსტად არ იციან პრაქტიკის შესახებ. თავის მხრივ, არიან ნოვატორები, რომლებმაც რაღაც გაიგეს, მაგრამ, სავარაუდოდ, დიდი ხანია არ მუშაობენ კომპანიაში. რომელთან ჯობია მუშაობა?

ნებისმიერ შემთხვევაში მოგიწევთ კონსერვატორებთან ურთიერთობა, რადგან ეს მათი სამსახურია. მოგიწევთ მათთან კომუნიკაცია, სერვისის სპეციფიკის გარკვევა, რა შეიძლება გაკეთდეს ამ გზით და კიდევ რა. მათ რჩევაზე ვართ დამოკიდებული. ალბათ მოგიწევთ მათ რაიმეს მინდობა, რადგან მათ თავიანთი სამსახური უკეთ იციან. აქედან გამომდინარე, მნიშვნელოვანია, რომელ გუნდთან დავასრულოთ კონტაქტი.

გუნდისთვის ნოვატორების არჩევა ლოგიკურია, რადგან კონსერვატორებს შეუძლიათ მასში ღორის ჩასმა.

პრაქტიკაში ხშირად ხდება, რომ კონსერვატიულ ადამიანებს აქვთ მნიშვნელოვანი გამოცდილება, მაგრამ არ აქვთ იმის გაგება, თუ როგორ იცხოვრონ შემდგომში. მათ უბრალოდ ეშინიათ, რომ სამსახურის გარდაქმნისა და გადამუშავების შემდეგ, სამსახურიდან გაათავისუფლონ, როგორც არასაჭირო. ზოგჯერ, უბრალოდ იმიტომ, რომ არ ესმით, რა ხდება, საბოტაჟს ახდენენ სამუშაოს.

მქონია შემთხვევა, როცა გუნდიდან ბიჭმა ყველაფერი შეაკეთა, რადგან ვითომ უფრო კრიტიკული იყო, ვიდრე ახლა რასაც ვაკეთებთ. ჩვენ დავსახეთ ამოცანა: დღეს განვახორციელოთ ეს ნაჭერი - არა, მსოფლიოს მეორე მხარეს ცეცხლია, ვაპირებთ გამოვასწოროთ. ასეთ ადამიანებთან მუშაობა რთულია.

კონსერვატიული გუნდის ადამიანები ხშირად ივიწყებენ ამოცანებს ან აყოვნებენ მათ ბოლო წუთამდე. და თუ, ჯონ უილისმა არ დაუშვათ, შეცდომა დაუშვით და მიანიჭეთ მათ KPI შესრულებული დავალებების რაოდენობის მიხედვით და რაიმე მიზეზით რაიმე ნაწილი არ შედიოდა KPI-ში, მაშინ ისინი საერთოდ არაფერს გააკეთებენ. ზოგადად, ისინი მართლები იქნებიან, რადგან შემდეგ კარგავენ ბონუსს.

ინოვატორებთან უფრო ადვილია - ისინი უფრო ლოიალურები არიან. რაღაც უკვე გაიგეს, სადმე უნდათ წასვლა, დაგეხმარებიან. ჩვენ გვჭირდება ადამიანები, რომლებიც მზად არიან იტანჯონ პირველად: თუ სერვისი შეიცვლება, მაშინ ნოვატორები პიონერებად დაიჭერენ ყველა მუწუკს და ჭურჭელს. ინოვატორებს სურთ ყველაფერი ახალი და მოდური და იტანჯებიან.

კონსერვატორები შეიძლება მოგვიანებით გადაიქცნენ. როდესაც აჩვენებთ, რომ შეცვალეთ ნაწილი და ყველაფერი კარგად მუშაობს, დიდი ალბათობით, მათაც მოინდომებენ სცადონ და აითვისებენ ახალ DevOps რელიგიას.

შევაჯამოთ. თუ ჩვენ თვითონ გავაკეთებთ მთელ ტრანსფორმაციას ჩვენს კომპანიაში, მაშინ ვირჩევთ: ახალ სერვისს, სასურველია მარტივი ინტერფეისი, რათა ძალიან არ დაზარალდეს მისი ავარია და ინოვატორების გუნდი.

თუ შესაძლებელია გარე კონსულტანტის გამოძახება, ახლის ნაცვლად ვიღებთ ძველ სერვისს, რის გამოც უკვე ვიტანჯებით. ადამიანებმა, რომლებიც დიდი ხნის განმავლობაში იყვნენ ჩართულნი ტრანსფორმაციაში სხვადასხვა კომპანიაში, ნახეს სხვადასხვა შემთხვევები და უკვე ესმით, როგორ გააკეთონ ეს სწორად და რა მიმართულებით წავიდნენ ზოგადად.

ვინ არის ჩართული?

ჩვენ უნდა მოვძებნოთ ყველა, ვისაც აქვს გარკვეული კავშირი სერვისთან: დეველოპერები, ტესტერები, ადმინისტრატორები, უსაფრთხოების სპეციალისტები, მენეჯერები და, შესაძლოა, პროდუქტის მფლობელები. მიუხედავად იმისა, რომ პროდუქტის მფლობელები არ არიან ტექნიკური სპეციალისტები, ისინი დაკავშირებულია სერვისთან: ისინი იღებენ გადაწყვეტილებებს, ადგენენ ამოცანებს.

ყველას, ვინც იღებს სულ მცირე გადაწყვეტილებებს და გავლენას ახდენს იმაზე, რაც ხდება სერვისთან, უნდა მოიძებნოს, შეხვდეს და დაუკავშირდეს.

რისთვის გვჭირდება ისინი? იცოდე ვისთან უნდა მოლაპარაკება. ტრანსფორმაციის დროს, როცა სერვისთან მუშაობის ჩვეული პრინციპი იცვლება, ის მაინც შეირყევა. გარკვეული ხნით იქნება ხარვეზები, სანამ ჩვენ ვამოწმებთ ახალ მიდგომებს. ხალხი მზად უნდა იყოს ამისთვის და დაეთანხმოს ამას.

შემდეგ თქვენ მოგიწევთ შექმნათ Value Stream Map და ამ ადამიანების გარეშე თქვენ ვერ შეძლებთ მის აშენებას, რადგან მხოლოდ მათ ყველამ ერთად იციან სრული სურათი იმის შესახებ, რაც ხდება. ერთმა ადამიანმა არასოდეს იცის ყველაფერი, რაც ხდება სერვისით.

გუნდისთვის რეკომენდაციას გაუწევენ ხალხს, მოგვიანებით განვიხილავთ, რატომ არის საჭირო ცალკე გუნდი. მას მოუწევს ხალხის წაყვანა არსებული დეპარტამენტებიდან. მათ, ვინც ჩართულია სამსახურში, შეეძლებათ რეკომენდაცია გაუწიონ ჩვენს მიმართულებით მოაზროვნე კოლეგებს, რომლებიც დაგვეხმარებიან და კომპეტენტურები არიან იმაში, რაც გვჭირდება.

შემდეგი, ჩვენ ვაგროვებთ ყველა ამ ადამიანს სხვადასხვა განყოფილებიდან ერთ ოთახში და ვიწყებთ ღირებულების ნაკადის რუქის შექმნას.

ღირებულების ნაკადის რუქის შექმნა

Value Stream Map არის დიაგრამა ან რუკა, რომელიც აჩვენებს ღირებულებების ნაკადს კლიენტთან. ეს არის მთელი პროცესი იდეის მოფიქრებიდან მის განხორციელებამდე, ყველა შუალედური ეტაპის ჩათვლით და თუ როგორ აღწევს ღირებულება საბოლოოდ ჩვენს კლიენტებს.

Value Stream Map საჭიროა განვითარების ყველა ეტაპის ვიზუალიზაცია, პრობლემების ლოკალიზება იმ გაზომვების საშუალებით, რომლებიც არსებობს მიმდინარე პროცესში და დაიწყება ამ პრობლემების აღმოფხვრა და დაისახეთ საწყისი მიზანი. სწორედ აქ ვიწყებთ რეალურად რაღაცის გაკეთებას.

მეტრიკა

Value Stream Map-ის ლიტერატურაში აღწერილია მრავალი განსხვავებული მეტრიკა, მაგრამ მხოლოდ სამი საკმარისია იმისათვის, რომ დავიწყოთ.

მიწოდების დრო - დაგვიანება/ლოდინი - დრო, როცა რაღაცას ველოდებით. მაგალითად, ტესტერი ელოდება, სანამ სატესტო სტენდი თავისუფლდება და ამ დროის განმავლობაში ვერაფერს გააკეთებს.

დამატებული ღირებულების დრო - სასარგებლო სამუშაო დრო - რა დავხარჯეთ ამა და ასეთ ეტაპზე მომხმარებლისთვის საბოლოო ღირებულების შესაქმნელად. მაგალითად, ტესტერმა დაიწყო თავისი ტესტი და დაიწყო რაღაცის შემოწმება. ეს არის სასარგებლო მუშაობის დრო, როდესაც ჩვენ რეალურად ვაკეთებთ რაიმეს პროდუქტისთვის. ეს არის ის, რასაც კლიენტები იხდიან - ხარისხის პროგრამული უზრუნველყოფა.

%C/A არის მიღებული სამუშაოს პროცენტი. გვაქვს ერთი ეტაპი - განვითარება, მეორე ეტაპი - ტესტირება. რამდენი ფუნქციის ტესტერია მიღებული დეველოპერებისგან არის ეს პროცენტი.

დაახლოებით ასე გამოიყურება ჩვენი რუკა.

ეს შეიძლება განსხვავებულად გამოიყურებოდეს ორგანიზაციის სტრუქტურის, განყოფილებების რაოდენობისა და რას აკეთებთ. მაგრამ ზოგადად რუკაზე ორი ეტაპი იქნება: იდეა и ანალიტიკა. ამ ეტაპზე მოსალოდნელია მონაცემები, მაგალითად, წარდგენის დრო 2 კვირა და დამატებული ღირებულების დრო 2 დღე.

ჩვენ ვფარავთ აბსოლუტურად ყველა ეტაპს მეტრიკით.

Backlog - რამდენი პრობლემა იყო მას შემდეგ, რაც ანალიტიკოსები გამოვიდნენ.

განვითარება - რამდენი კვირა ელოდნენ დეველოპერები ამოცანების, სტენდების ან აღჭურვილობის განმარტებას - არ აქვს მნიშვნელობა, მაგრამ ისინი რაღაცას ელოდებიან. მაგალითად, ფუნქციის დანერგვას მათ 4 დღე სჭირდება. აქ შემოდის %C/A მეტრიკა. დეველოპერებმა Backlog-დან ამოცანების მხოლოდ 80% აიღეს. მათ მიაჩნიათ, რომ დანარჩენ 20%-ს არ აქვს საკმარისად მკაფიო ტექნიკური სპეციფიკაცია და გაგზავნეს გადასინჯვისთვის.

ტესტირება. LT დიაგრამა დაყენებულია 4 დღეზე. მაგალითად, ტესტერები ელოდნენ ტესტის სკამზე გათავისუფლებას, VA ისინი რეალურად ამოწმებდნენ რაღაცას 2 დღის განმავლობაში და %C/A = 40%. — დეველოპერების მიერ გაგზავნილი კოდის ან ფუნქციების მხოლოდ 40% მიიჩნიეს ადეკვატურად ტესტერებმა. სხვა ყველაფერი რატომღაც არ მოსწონდათ.

მე არ ვისაუბრებ დეტალურად იმაზე, თუ როგორ უნდა განვახორციელოთ ეს გაზომვები; სტატიის ბოლოს გირჩევთ ლიტერატურას, საიდანაც შეგიძლიათ გაიგოთ მათ შესახებ.

ერთადერთი, რისი რეკომენდაციაც შემიძლია არის ის, რომ არ ენდოთ ადამიანებს, რომლებიც შეადგენენ თქვენთან ერთად ღირებულების ნაკადის რუკას. ისინი წარმოადგენენ წარმოდგენას იმის შესახებ, თუ რამდენ ხანს გრძელდება სხვადასხვა პროცესები, მაგრამ ეს შეფასებები ყოველთვის არ არის სწორი, ამიტომ უმჯობესია საკუთარი თავის გაზომვა.

ჩვენ გვქონდა შემთხვევა, როდესაც მივედით ოპერაციების განყოფილებაში და ვკითხეთ, რამდენი დრო დასჭირდა ახალი ფუნქციის წარმოებას. გვითხრეს, რომ 10 წუთი იქნებოდა და ჩვენ ვიფიქრეთ, რატომ მოვედით ამ კომპანიაში? აღმოჩნდა, რომ 10 წუთი არის სკრიპტის გაშვების დრო, რომელიც იღებს კოდს და აწვდის სერვერს. მაგრამ მანამდე, გამოშვება ზის სერვერზე სამი დღის განმავლობაში და უბრალოდ აგროვებს მტვერს - არის დავალება Backlog-ში, რომელიც უნდა განთავსდეს. გამოდის, რომ განლაგების ეტაპამდე არის მოლოდინის ეტაპი, როდესაც პროექტი უბრალოდ ზის. რვეულით რომ არ წავსულიყავით, ჯირაში დავალებას თვალი არ დაგვეჭირა და ეტაპობრივად თვალყურის დევნება არ დაგვეწყო, ვიფიქრებდით, რომ ყველაფერი მშვენივრად იყო და პრობლემა არ იყო.

ამიტომ, თქვენ მაინც მოგიწევთ გაზომვები თავად გააკეთოთ, სასურველია არაერთხელ, რათა გქონდეთ რეალობასთან მიახლოებული იდეა. Value Stream Map-ის მიხედვით, თქვენ გადაწყვეტთ სად დაიწყოთ და რა გამოასწოროთ ჯერ.

დროებითი გუნდი

ბევრი კომპანია, რომელიც გადაწყვეტს DevOps-ის განხორციელებას, ქმნის გუნდს, მაგრამ არა დროებით, არამედ ისეთს, რომელიც რამდენიმე წელია არსებობს. თუ მიდიხართ DevOps ბოდიშის მოხდის სერვისში, რომელიც აღწერს DevOps-ში ორგანიზაციული სტრუქტურის შექმნის სხვადასხვა შაბლონებს, მიხვდებით, რომ ეს არის ანტი შაბლონი.

როდესაც DevOps-ის გუნდი უწყვეტად არსებობს რამდენიმე წლის განმავლობაში, ეს დიდი შეცდომაა, რადგან DevOps ეხება დეპარტამენტებს შორის კომუნიკაციას, სიჩქარესა და ეფექტურობას.

თუ გუნდი არსებობს განყოფილებებს შორის მხოლოდ იმისთვის, რომ ცალკე რაღაც გააკეთოს და არსებობს დიდი ხნის განმავლობაში, მაშინ ის ქმნის არასაჭირო ბარიერს. ახლა პროგრამისტი, ნაცვლად იმისა, რომ დაუყოვნებლივ წავიდეს ადმინისტრატორთან პრობლემის გადასაჭრელად, ჯერ უნდა დაუკავშირდეს DevOps განყოფილებას და ის გადავა.

ამიტომ, დასაწყებად, თქვენ უნდა შექმნათ დროებითი გუნდი. ის იარსებებს პირობითად ექვსი თვის განმავლობაში, მაქსიმუმ ერთი წლის განმავლობაში, დაკისრებული დავალების მიხედვით, მხოლოდ ერთი შეზღუდვის აღმოსაფხვრელად, რომელიც ჩვენ ავირჩიეთ. მაშინ ის მოკვდება. თუ მომდევნო პუნქტს ავირჩევთ, სადაც დიდი ტკივილი გვაქვს და მივხვდებით, რომ ამისთვის ცალკე გუნდიც გვჭირდება, მაშინ ისევ შევქმნით მას. მაგრამ ასეთი გუნდები არ უნდა არსებობდეს "მუდმივ საფუძველზე" - მაშინ ისინი მხოლოდ არღვევენ კომუნიკაციას და ზოგადად იღებენ ცალკეულ დავალებებს მხოლოდ რაღაცის გასაკეთებლად. ეს ამოცანები შეიძლება საერთოდ არ იყოს დაკავშირებული DevOps-თან ან ტრანსფორმაციასთან. რატომ არ ვაძლევთ ამ დავალებას არსებულ დეპარტამენტებს?

რატომ არის საჭირო დროებითი გუნდი?

კონფლიქტი მიმდინარე პროცესებთან. DevOps-ის ტრანსფორმაცია არ არის მხოლოდ ჩვენ მიერ გამოყენებული ტექნოლოგიებისა და ხელსაწყოების ცვლილება, არამედ სამუშაო პროცესის, აზროვნების და ღირებულებების ცვლილება. თუ გუნდი იმუშავებს ისე, როგორც გამოიყენება, ის ვერ შეძლებს სხვა მიდგომების ცდას.

ამ ადამიანებს სხვადასხვა წესებით უწევთ ცხოვრება: უგულებელყოთ კომპანიის ყველა KPI, რადგან ისინი ცდილობენ სხვაგვარად იმუშაონ. დროებითი გუნდები არ შეავსებენ აპლიკაციებს სერვერის მისაღებად, არამედ პირდაპირ მიდიან განყოფილებაში, რომელიც მათ მართავს და მოითხოვენ, რომ პირველ რიგში მიეცეს ის, რაც მათ სჭირდებათ, რადგან ეს არის პრიორიტეტი და იმიტომ, რომ ისინი ცდილობენ სხვაგვარად იცხოვრონ. გუნდი სრულ კონფლიქტშია ყველა მიმდინარე პროცესთან. იმის უზრუნველსაყოფად, რომ არსებულმა სამუშაო პრაქტიკამ მათ ახლა ხელი არ შეუშალოს და სხვებს ხელი არ შეუშალონ, ამ ადამიანებს ცალკე გუნდში ვყოფთ.

ექსპერიმენტებში ბიუროკრატიის თავიდან აცილება. დროებით გუნდებს არ აქვთ ბიუროკრატია, არ წარუდგენენ დროის ანგარიშებს, არ უწევენ ანგარიშს მენეჯერებს. ეს არის სრულიად ცალკე სამყარო, რომელშიც ადამიანები სხვაგვარად ცხოვრობენ და ფიქრობენ და სრულიად განსხვავებულ საქმეებს აკეთებენ. არ არის საჭირო მათი ხელახლა შეწუხება.

უწყვეტი მუშაობა სერვისზე. პირველ პუნქტში ჩვენ ავირჩიეთ რაღაც, რაზეც ექსპერიმენტებს ჩავატარებთ. ექსპერიმენტირება და უკეთესი მუშაობის გზების პოვნა კარგია, მაგრამ ჩვენ ასევე გვინდა შევქმნათ ფუნქციები. თუ მთელი გუნდი ფუნქციების ნაცვლად ტრანსფორმაციაზე გაამახვილებს ყურადღებას, მაშინ ჩვენ დავიწყებთ შემოსავლის დაკარგვას, შეცდომები დიდხანს დარჩება - ჩვენ ეს არ გვჭირდება. დროებითი გუნდის შექმნა საშუალებას გაძლევთ ექსპერიმენტების ჩატარება პროდუქტზე მუშაობის შეწყვეტის გარეშე.

ნუ დაკარგავთ დროს სამუშაო ამოცანებს. ისევ პროდუქტს ეხება. გუნდს დიდი დრო სჭირდება სხვა ინსტრუმენტებისა და ნივთების გამოცდას. ადამიანებს ინსტრუმენტების დაუფლებას, მათ დანერგვას და ჩვეულებრივ გამოყენებას დასჭირდებათ სულ მცირე ექვსი თვე. თუ ისინი ასევე ყურადღებას გაამახვილებენ პროდუქტზე, ექვსი თვე კოსმიურად გაიწელება. თუ ადამიანები მუშაობენ პროდუქტზე, ისინი კვლავ მუშაობენ ძველი პროცესებით - ჩვენ ეს არ გვჭირდება.

ამიტომ, სხვადასხვა განყოფილების ადამიანებს ვანაწილებთ ცალკეულ გუნდში, რომელიც გარდაქმნის სერვისს. შედეგად, სერვისი მუშაობს, აგრძელებს განვითარებას და ამავდროულად მასზე ვატარებთ ექსპერიმენტებს.

დროებითი გუნდი ეძღვნება მხოლოდ DevOps ტრანსფორმაციას - აღმოფხვრის შეზღუდვას, რომელიც აღმოვაჩინეთ და მეტი არაფერი.

გუნდი შედგება მრავალმხრივი ადამიანებისგან. ეს ნიშნავს, რომ ჩვენ დავიქირავეთ არა მხოლოდ დეველოპერები. ჩვენ არ მოვედით სერვის ცენტრში და იქიდან გუნდის ნახევარი წავიყვანეთ - არა, წავიყვანეთ ხალხი სხვადასხვა განყოფილებიდან. რამდენიმე პუნქტის წინ აღმოვაჩინეთ სხვადასხვა დეპარტამენტი და სხვადასხვა თანამშრომელი, რომლებიც დაკავშირებულია ტრანსფორმირებულ სამსახურთან. ჩვენ მათგან ვიღებთ გუნდს, რადგან ის უნდა იყოს უნივერსალური - ჩვენ შევცვლით ტესტირების პროცესს, განვითარების პროცესს და მომსახურების შენარჩუნების პროცესს. საჭიროა სხვადასხვა კომპეტენცია.

ჩვეულებრივ, ჩვენ ვიღებთ დეველოპერს, ტესტერს და ინჟინერს სათითაოდ და მათთან ერთად ვიღებთ გადაწყვეტილებას, რომელიც საშუალებას გვაძლევს ვიცხოვროთ განსხვავებულად.

სასურველია ამ ადამიანებს ჰქონდეთ ავტორიტეტი ორგანიზაციაში. შეიძლება მოგიწიოთ ერთი კონსერვატივის მიღება, თუმცა არ გინდათ. თუ ჩვენ გვყავს დიდი კომპანია, ყველას არ დაიჯერებს ჩვენი იდეის და ზოგიერთმა შეიძლება ბორბლებში ჩააგდოს სპიკერი, მაგალითად, სტენდის არ უზრუნველყოფის გამო. სწორედ აქ დაგჭირდებათ „ავტორიტეტი“ - პატივცემული ადამიანი დიდი გამოცდილებით, რომელმაც დაიმსახურა თავისი კოლეგების კარგი დამოკიდებულება. გუნდში თანამშრომლის უფლებამოსილება გაამარტივებს დროებითი გუნდის დავალებას და მუშაობას. ხალხი იფიქრებს:

- ჰო, ეს მაგარი ბიჭი, რომელსაც ყველა ვიცნობთ და გვიყვარს, ჯდება - როგორც ჩანს, DevOps-ში ღირს რაღაცის ყურება!

მიზნის დასახვა

შევკრიბეთ ხალხი, ავირჩიეთ სერვისი, გადავხედეთ შეზღუდვებს და დავადგინეთ, რომელ ადამიანებზე მოვახდენდით გავლენას. ახლა თქვენ უნდა დაისახოთ მიზანი და ის უნდა იყოს სწორი SMART-ის მიერ - ყველაფერი რაც გვიყვარს.

სპეციფიკური - სპეციფიკური.

გაზომვადი - გაზომვადი. ეს არის ძალიან მნიშვნელოვანი SMART წერტილი. თუ რაიმეს გაზომვა არ შეგიძლია, მაშინ ვერ შეცვლი მას და ვერ გაიგებ რა და როგორ გააკეთე უკეთესი ან უარესი.

მიღწევადი - მიღწევადი. გააკეთეთ კორექტირება თქვენი კონკრეტული საჭიროებების შესაბამისად. თუ თქვენ ხართ ხანგრძლივი ისტორიის და პასუხისმგებლობის დიდი დატვირთვის მქონე საწარმო კომპანია, რომელიც გამოსცემს პროდუქტის ვერსიას წელიწადში ერთხელ, მაშინ ვერ მიაღწევთ პროდუქტის ახალი ვერსიების გამოშვებას ყოველ საათში ექვს თვეში. ასე არ იმუშავებს. ამიტომ დაისახეთ რეალისტური მიზანი, რომლის მიღწევაც მისაღებ ვადებშია შესაძლებელი.

შესაბამისი - შესაბამისი. ჩვენ ვხსნით მხოლოდ იმ შეზღუდვებს, რომლებიც რეალურად ემსახურება ჩვენს ამჟამინდელ მიზნებს.

Time Limited - დროში შეზღუდული. თუ ვადა არ არის, გუნდი გააკეთებს იმას, რაც უნდა: სცადეს 15 ტექნოლოგია 3-ის ნაცვლად, დაწეროს უზარმაზარი ანგარიშები, ჩაატაროს უსარგებლო კვლევები, გააუმჯობესოს მათი განხორციელება მანამ, სანამ ის გაბრწყინდება, როდესაც მიზანი უკვე მიღწეულია.

ჩვენ ვიღებთ მიზანს Value Stream Map-ის გამოყენებით - კვლავ ვაგროვებთ ყველა ადამიანს და ვხატავთ მათ. მაგრამ მხოლოდ ახლა, წინა Value Stream Map-ზე დაყრდნობით, ჩვენ ვხატავთ იმას, რისი მიღებაც გვინდა.

ჩვენ ხაზს ვუსვამთ ერთ შეზღუდვას, რომელსაც ახლავე მოვხსნით - ეს არის ის, რასაც გუნდი გააკეთებს. მაგალითად, მე ავიღე ლოდინი დასრულებული გამოშვებიდან მის წარმოებაში განთავსებამდე - ეს არის ყველაზე გავრცელებული შეზღუდვა, რომლითაც ადამიანები მიმართავენ კონსულტანტებს.

ამის საფუძველზე დავსახეთ ამოცანა: გვინდა, რომ დასრულებულ გამოშვებასა და ბრძოლაში წასვლას შორის ლოდინი იყოს მაქსიმუმ ერთი საათი.

დავალებების მაგალითები.

• შეამცირეთ ტესტირების დრო 4 დღიდან 1 საათამდე.
• შეამცირეთ ტესტირების დამატებული ღირებულების დრო 2 დღიდან 3 საათამდე.
• შეამცირეთ განლაგების დრო 5 საათიდან 10 წუთამდე.
• გაზარდეთ C/A ​​50%-დან 95%-მდე, ანუ გაზარდეთ ფუნქციების რაოდენობა, რომლებსაც ტესტერები იღებენ, სხვა სიტყვებით რომ ვთქვათ, გააუმჯობესეთ დეველოპერების მუშაობის ხარისხი.

ამოცანების მაგალითები არ არის აღებული ჩვენი თავებიდან - ისინი ეფუძნება გაზომვებს, რომლებიც გავაკეთეთ Value Stream Map-ის შემუშავებისას.

ანალოგიური დავალება დავუწესეთ ჩვენს გუნდს და ვადა. იმისდა მიხედვით, თუ რამდენად კარგად მუშაობს თქვენი კომპანია, თქვენ ადგენთ სხვადასხვა ვადებს. საშუალოდ, შეზღუდვის აღმოფხვრას, ჩვეულებრივ, ექვსი თვე სჭირდება, თუ ადამიანები ამას პირველად აკეთებენ და ჯერ არ იციან, რა ტექნოლოგიებით და კონკრეტულად როგორ მოაგვარებენ პრობლემას.

მოკლე დაგეგმვა

ასე რომ, ჩვენი გუნდი იქმნება, აქვს მიზანი, ხალხი იწყებს მუშაობას. მნიშვნელოვანი პუნქტია სამუშაოს მოკლე დაგეგმვა: სპრინტები ერთიდან ორ კვირამდედა მეტი არა, გაზომვადი გაუმჯობესებები ყოველ კვირას და კურსის კორექტირება.

მაგალითად, ჩვენ ხშირად ვიყენებთ მიდგომას მოძრავ-მოძრავიროდესაც მთელი გუნდი იკრიბება ყოველი კვირის დასაწყისში, ისინი ჩაწერენ ფაილში რას გააკეთებს ყველა. ერთი კვირის შემდეგ ჩვენ აღვნიშნავთ, რა გაკეთდა და რა არა, თუ არა, მაშინ რატომ და ვფიქრობთ, რა გავაკეთოთ შემდეგ.

სპრინტები საშუალებას გაძლევთ დროულად განახორციელოთ კურსის კორექტირება.

ერთი-ორი კვირა რაღაცას ცდილობდი: ტექნოლოგიები, მიდგომები, მუშაობის გზები, ამის შემდეგ ისევ იზომებ და ხედავ - ამ მიდგომით უკეთესი გახდა თუ უარესი? თუ ეს უარესია, ეს ნიშნავს, რომ არასწორი მიმართულებით მივდივართ, ჩვენ უნდა გამოვასწოროთ კურსი: დავაყენოთ სხვა დავალება, ავიღოთ სხვა ტექნოლოგია ან გავაკეთოთ სხვა რამ. 1-2 კვირიანი მოკლე სპრინტები საშუალებას გაძლევთ მანევრირება და დროულად თავიდან აიცილოთ ცუდი გადაწყვეტილებები.

წარმატების გაზიარება

გუნდი აღწევს გარკვეულ წარმატებებს, მცირე თუ დიდ - არ აქვს მნიშვნელობა, ყოველთვის არის გარკვეული შედეგი. ყველამ უნდა იცოდეს ამ შედეგის შესახებ: როგორც DevOps-ში ჩართული, ისე მეზობელ განყოფილებებში. იდეალურ სამყაროში სასურველი იქნებოდა ეს საერთოდ ჩამოვიდეს კომპანიის ყველა ადამიანს.

Რისთვის? თუ გვსურს კომპანიის არა მხოლოდ ნაწილის გარდაქმნა, არა მხოლოდ ერთი შეზღუდვის აღმოფხვრა, არამედ ზოგადად ყველაფერი ისე, რომ კომპანია გახდეს მოქნილი, კოდი სწრაფად მიაღწიოს კლიენტს და არაფერი გატეხოს, ჩვენ გვჭირდება, რომ იდეის ერთგული ვიყოთ. DevOps-ის. თქვენ ვერ შეძლებთ მიდგომის გამოყენებას სერვისებისა და გუნდების მიმართ, რომლებიც კატეგორიულად ეწინააღმდეგებიან მას.

ერთგულება რომ გამოჩნდეს, ყველას უნდა ვუთხრათ, რომ ეს ვცადეთ - შედეგი გვაქვს, თქვენც სცადეთ! ეს გაზრდის ინტერესს და ლოიალობას იმის მიმართ, რასაც ვაკეთებთ, ხალხი დაიწყებს რაღაცის გაკეთებას ახლავე. როგორც პრაქტიკა გვიჩვენებს, როდესაც გეუბნებით რა ვცადეთ და რას მივაღწიეთ, სხვა გუნდები იწყებენ კითხვას, როგორ და რა გავაკეთეთ. უყურებენ განხორციელებებს, კოდს, დოკუმენტაციას, სვამენ კითხვებს და ცდილობენ რაღაცის შეცვლას საკუთარ თავში.

მნიშვნელოვანია საუბარი იმაზე, რაც გააკეთე. ამ გზით თქვენ დაარწმუნებთ კონსერვატორებს, რომლებსაც სურდათ ყველაფერი გაეკეთებინათ ძველი გზით, შეუერთდნენ თქვენს ბანაკს და გარდაქმნან ისინი ნოვატორებად.

საერთო ჯამში

სერვისის არჩევა, როგორც ამოსავალი წერტილი - ადგილი, სადაც ჩვენ დავიწყებთ ცვლილებებს კომპანიაში. ჩვენ ვაფიქსირებთ ყველას, ვისაც რაიმე კავშირი აქვს სერვისთან და მათთან ერთად ღირებულების ნაკადის რუქის შექმნა, ვზომავთ და ვხედავთ სად და რა შეზღუდვებია.

ახალი დროებითი გუნდის შექმნა, რაც პრობლემას მოაგვარებს. გაზომვებზე და ღირებულების ნაკადის რუკაზე დაყრდნობით ვხატავთ ახალ რუკას, სადაც გამოვყოფთ შეზღუდვას, რომელსაც გადავჭრით. ამ შეზღუდვის საფუძველზე დავალების დაყენება, რომელსაც გუნდი გაუმკლავდება. ამოცანა უნდა იყოს აუცილებლად SMART - სპეციფიკური, გაზომვადი, მიმდინარე ამოცანების შესაბამისი და დროში შეზღუდული.

გაიმეორეთ პროცესი, სანამ არ გადავიყვანთ აბსოლუტურად ყველა ჩვენს სერვისს საჭირო ფორმაზე და არ მოვხსნით ყველა შეზღუდვას.

ბონუსი. სასარგებლო მასალები

მათთვის, ვინც გადაწყვიტა DevOps დამოუკიდებლად გაეკეთებინა.

პროექტი "ფენიქსი"

ორიგინალური სათაურია "Phoenix Project: A Novel on It, Devops, and Help Your Business Wine". ეს არის რომანი DevOps-ის შესახებ - ისტორია იმის შესახებ, თუ როგორ დააკავეს თანამშრომელი იმ განყოფილების უფროსად, რომელიც ყოველთვის იწვოდა. ახალ უფროსს დაევალა დავალება:

”თქვენ გაქვთ რამდენიმე წელი იმისათვის, რომ ყველაფერი სწორად მიიღოთ, რათა საბოლოოდ მივაწოდოთ ჩვენი პროდუქტი ჩვენს მომხმარებლებს სწრაფად და ეფექტურად.”

"პროექტი ფენიქსი" რომანი იმის შესახებ, თუ როგორ ცვლის DevOps ცხოვრებას უკეთესობისკენ” არის წიგნი ყველა მენეჯერისთვის, რადგან სწორედ ეს ადამიანები იღებენ გადაწყვეტილებებს იმის შესახებ, თუ რა ხდება კომპანიაში. თუ ინჟინერი ან პროგრამისტი ხართ და გსურთ მოძრაობა და ტრანსფორმაცია დაიწყოს თქვენს კომპანიაში, იყიდეთ წიგნი და გადაეცით მენეჯმენტს. ეს რომანი ხსნის ყველაფერს და იკითხება სწრაფად და მარტივად.

DevOps სახელმძღვანელო

წიგნი უფრო რთულია. იგი გამოიცა რამდენიმე წლის წინ ინგლისურად, სახელწოდებით „DevOps Handbook, როგორ შევქმნათ მსოფლიო დონის სისწრაფე, საიმედოობა და უსაფრთხოება ტექნოლოგიურ ორგანიზაციებში“, მაგრამ ახლა ის უკვე ხელმისაწვდომია რუსულ ენაზე. Ეს რეალურია სახელმძღვანელო - პრაქტიკული სახელმძღვანელო: როგორ განვახორციელოთ გაზომვები, რა არის Value Stream Map და რატომ არის საჭირო, სად წავიდეთ, რა თანმიმდევრობით. წიგნი მხოლოდ მათთვისაა, ვისაც სურს ყველაფერი თავად გააკეთოს. რაც მთავარია, ის შეიცავს სხვა კომპანიების გამოცდილების მაგალითებს.

მაგალითად, ის მოგვითხრობს, თუ როგორ შექმნა ერთმა კომპანიამ Value Stream Map და გააცნობიერა, რომ მისი შეზღუდვა არ იყო პროდუქტში, არამედ იმაში, რომ მოლარე მაღაზიიდან მომდევნო ოფისში დადიოდა ამ პროდუქტის გამოსაყენებლად. პროგრამით პრობლემის გადაჭრის ნაცვლად, მათ უბრალოდ იყიდეს ტაბლეტები თავიანთი გამყიდველებისთვის და ახლა არავინ არსად მიდის და ყველა მოქმედება მათ სამუშაო ადგილზე სრულდება. დასკვნა: Value Stream Map შეიძლება გავრცელდეს არა მხოლოდ პროგრამულ უზრუნველყოფაზე, არამედ ორგანიზაციის ყველა პროცესზე.

დააჩქაროს

სრული სათაური: "აჩქარება: მეცნიერება მჭლე პროგრამული უზრუნველყოფისა და DevOps-ის შესახებ: მაღალი ხარისხის ტექნოლოგიური ორგანიზაციების შექმნა და მასშტაბირება." ეს არის შემდეგი დონე - ჰარდკორი. წიგნი შარშან გამოიცა, ჯერჯერობით მხოლოდ ინგლისურ ენაზე და საუბარია კვლევაზე. ავტორები - ნიკოლ ფორსგრენი, ჯეზ ჰუმბლი და ჯინ კიმი - მრავალი წლის განმავლობაში იყენებდნენ სხვადასხვა პრაქტიკას სხვადასხვა კომპანიაში და იკვლევდნენ, თუ რომელი პრაქტიკა გავლენას ახდენს რაზე და როგორ.

მეორე თავში, გაზომვის შესახებ, ნახსენებია Value Stream Map, მეტრიკა, რომელიც აღვნიშნე და მრავალი სხვა, ასევე დეტალურად არის აღწერილი გაზომვის პროცესი. ავტორები ზომავენ კითხვარებისა და თვითმმართველობის თვალთვალის ამოცანების გამოყენებით. იგი დეტალურად აღწერს რომელი მეტრიკა არის სწორი გასაზომად, რომელი არ უნდა გაიზომოს და ადამიანის შეცდომები გაზომვებში. თუ გაზომვები გიჭირთ, იხილეთ წიგნის „აჩქარება“ მეორე თავი. თუ თქვენს გუნდს უბრალოდ ბევრი პრაქტიკა აქვს, მაგრამ გაურკვეველია, რომელი პრაქტიკა გამოიყენოს ახლა, რომელი მოგვიანებით, რომელი ნამდვილად მუშაობს და რომელი არა - წაიკითხეთ, წიგნი ხსნის ყველაფერს.

ტრანსფორმაცია არის პრობლემა DevOps-ისა და მენეჯმენტის კვეთაზე. სადღაც განვითარების, ოპერაციების და ტესტირების კვეთის იმავე არეალში არის ის თემები, რომლებზეც ჩვენ ვცდილობთ განვიხილოთ DevOpsConf, იგივე ინტეგრაციაა საჭირო ხარისხიანი პროდუქტის შესაქმნელად - მთავარი თემა QaulityConf. ფესტივალის მენეჯმენტი RIT++ წარდგენილი ვეშაპ მხედარი - ეს ნიშნავს, რომ ყველას აქვს იდეები ტრანსფორმაციისთვის. შემოგვიერთდით 27 და 28 მაისს, ჩვენ გავერთიანდებით და გარდაქმნით.

წყარო: www.habr.com