{"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\/pl\/blog\/administrirovanie\/kak-nachat-devops-transformatsiyu","title":{"rendered":"Jak rozpocz\u0105\u0107 transformacj\u0119 DevOps","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Je\u015bli nie rozumiesz, czym jest DevOps, oto kr\u00f3tkie streszczenie. DevOps to zestaw praktyk, kt\u00f3re zmniejszaj\u0105 obawy in\u017cynier\u00f3w<\/strong> i skracaj\u0105 liczb\u0119 awarii w produkcji oprogramowania. Zazwyczaj r\u00f3wnie\u017c kr\u00f3tk\u0105 czas wprowadzenia na rynek<\/strong> \u2014 okres od pomys\u0142u do dostarczenia gotowego produktu do klient\u00f3w, co pozwala na szybkie przeprowadzanie eksperyment\u00f3w biznesowych.<\/strong>.<\/p>\n

Jak rozpocz\u0105\u0107 transformacj\u0119 DevOps? W skr\u00f3cie: wybieramy us\u0142ug\u0119, od kt\u00f3rej zaczniemy proces, identyfikujemy osoby zwi\u0105zane z us\u0142ug\u0105, budujemy Map\u0119 Warto\u015bci, tworzymy tymczasowy zesp\u00f3\u0142, kt\u00f3ry na pocz\u0105tku zajmie si\u0119 transformacj\u0105, i stawiamy mu zadanie. Powtarzamy cykl odpowiedni\u0105 liczb\u0119 razy.<\/p>\n

\"Jak<\/p>\n

Szczeg\u00f3\u0142owy plan transformacji DevOps z przyk\u0142adami i instrukcjami pod spodem \u2014 w opracowaniu referatu<\/a><\/noindex> Andrieja Aleksandrowa<\/b> \u2014 in\u017cyniera w firmie Express42, kt\u00f3ra doradza w zakresie wdra\u017cania DevOps, przyspieszaj\u0105c ten proces, poniewa\u017c ju\u017c zbudowa\u0142a map\u0119 pu\u0142apek. Je\u015bli uwa\u017casz, \u017ce transformacja nie jest dla ciebie potrzebna, lub twoja specyfika sprawia, \u017ce praktyki DevOps nie pasuj\u0105, \u2014 korzystaj z raportu jako instrukcji do zidentyfikowania i usuwania ogranicze\u0144.
\n<\/a><\/noindex>
\nJe\u015bli masz w\u0105tpliwo\u015bci co do transformacji DevOps, to masz du\u017c\u0105 firm\u0119, i nale\u017cy stopniowo skalowa\u0107 ten proces na ca\u0142\u0105 struktur\u0119. Dop\u00f3ki istnieje potrzeba transformacji zespo\u0142u lub usuni\u0119cia jakiego\u015b ograniczenia, algorytm poni\u017cej mo\u017cna powtarza\u0107.<\/p>\n

Wyb\u00f3r us\u0142ugi<\/h2>\n

\nPlan nakre\u015blony, zaczynamy od pierwszego kroku \u2014 wyboru us\u0142ugi. Pierwszym kryterium jest czas \u017cycia<\/strong>: s\u0105 stare us\u0142ugi \u2014 legacy, oraz nowe. Mo\u017cna zacz\u0105\u0107 zar\u00f3wno od jednych, jak i od drugich.<\/p>\n

Wyb\u00f3r m\u0142odej us\u0142ugi jest logiczny<\/strong>. Jest \u015bwie\u017ca, nie ma jeszcze ustalonego procesu pracy w zespole, kt\u00f3ry si\u0119 ni\u0105 zajmuje. Nie ma wok\u00f3\u0142 niej g\u00f3ry zobowi\u0105za\u0144 technicznych, nie trzeba jej ci\u0105gle naprawia\u0107. Mo\u017cemy z ni\u0105 robi\u0107, co chcemy.<\/p>\n

W przypadku starej us\u0142ugi pojawiaj\u0105 si\u0119 problemy zwi\u0105zane z tym, \u017ce zmiany zawsze s\u0105 trudne<\/strong>. Istnieje ju\u017c zestaw powa\u017cnych ogranicze\u0144, ale by\u0107 mo\u017ce zajmuj\u0105 si\u0119 nimi ludzie, kt\u00f3rzy s\u0105 ju\u017c gotowi wszystko przeorganizowa\u0107 \u2014 s\u0105 zm\u0119czeni i chc\u0105 co\u015b zmieni\u0107, bo czuj\u0105 b\u00f3l.<\/p>\n

Praca ze star\u0105 us\u0142ug\u0105 tworzy pot\u0119\u017cny precedens<\/strong> w twojej firmie \u2014 mo\u017cna co\u015b zmienia\u0107. Je\u015bli zmienisz now\u0105 us\u0142ug\u0119, dzia\u0142a na produkcji 100 razy na godzin\u0119 i wszystko jest dobrze, to ludzie w twojej firmie mog\u0105 powiedzie\u0107:<\/p>\n

To nowy serwis! Wszystko by\u0142o proste, spr\u00f3buj zrobi\u0107 cokolwiek z nasz\u0105 star\u0105 wersj\u0105.<\/em><\/p>\n

Serwis Legacy ma sens zmienia\u0107, gdy robisz to z kim\u015b, na przyk\u0142ad, je\u015bli zaprosisz zewn\u0119trznego konsultanta. B\u0105d\u017amy szczerzy, transformacja wstrz\u0105\u015bnie wszystkim, co tylko mo\u017cna.<\/strong>Eksperymentujesz i nie wiesz, dok\u0105d zmierzysz, jakie technologie i po co wykorzystasz, gdzie i jakie pu\u0142apki w procesach si\u0119 pojawi\u0105. Dlatego \u0142atwiej zmieni\u0107 na nowy.<\/p>\n

Je\u015bli wszystko robisz sam, a w firmie nie ma powa\u017cnej kompetencji \u2014 wybieraj nowy serwis. Je\u015bli znasz zewn\u0119trznego konsultanta i masz \u015brodki \u2014 wybierz stary.<\/p><\/blockquote>\n

\nS\u0105 serwisy, kt\u00f3re przedstawiaj\u0105 si\u0119 tylko jako interfejs dla u\u017cytkownik\u00f3w, na przyk\u0142ad prosta strona internetowa lub aplikacja mobilna. Ale s\u0105 te\u017c powa\u017cne rzeczy, takie jak bilingi. Je\u015bli co\u015b p\u00f3jdzie nie tak z billingiem \u2014 naprawa b\u0119dzie trudna. W tym te\u017c mamy wyb\u00f3r.<\/p>\n

Pracujemy albo z krytycznym serwisem<\/strong>, ale przez niego ju\u017c cierpimy, tworzy ograniczenia, albo pracujemy z interfejsem<\/strong>. To drugi kryterium wyboru. Analogicznie, istnieje mo\u017cliwo\u015b\u0107 zaanga\u017cowania do\u015bwiadczonego konsultanta \u2014 pracujemy z trudniejsz\u0105 wersj\u0105.<\/p>\n

Ale nawet w tym przypadku nie zaleca\u0142bym tego robi\u0107, poniewa\u017c, dop\u00f3ki nie ma zrozumienia, z czym pracowa\u0107 i w jak\u0105 stron\u0119 transformowa\u0107, branie krytycznej rzeczy i jej przekszta\u0142canie \u2014 to niezbyt dobry pomys\u0142. Dlatego w tym przypadku wolimy pracowa\u0107 z interfejsem, kt\u00f3rego awaria nie jest krytyczna.<\/p>\n

Dalej przyjrzymy si\u0119 zespo\u0142owi serwisu<\/b>. Z tymi, kt\u00f3rzy zajmuj\u0105 si\u0119 tym serwisem, b\u0119dziemy musieli ci\u0105gle pracowa\u0107 i mie\u0107 bardzo bliski kontakt.<\/p>\n

Ludzie w zespole dziel\u0105 si\u0119 na dwie kategorie: konserwaty\u015bci<\/strong> \u2014 \u017cyj\u0105 w starym \u015bwiecie lub po prostu nic nie wiedz\u0105 o DevOps, i innowatorzy<\/strong>, kt\u00f3rzy wprowadzaj\u0105 wszystkie nowinki. Drudzy nie zawsze rozumiej\u0105 temat, ale przynajmniej s\u0105 na niego gotowi.<\/p>\n

Z jednej strony konserwaty\u015bci \u2014 do\u015bwiadczeni ludzie: d\u0142ugo w firmie, rozumiej\u0105 wszystko od podstaw, ale nie znaj\u0105 praktyk. Z drugiej strony \u2014 innowatorzy, kt\u00f3rzy co\u015b s\u0142yszeli, ale w firmie prawdopodobnie s\u0105 nie za d\u0142ugo. Z kim lepiej pracowa\u0107?<\/p>\n

W przypadku konserwatyst\u00f3w b\u0119dziemy musieli nawi\u0105za\u0107 wsp\u00f3\u0142prac\u0119, bo to ich serwis. B\u0119dziemy musieli z nimi rozmawia\u0107, wyja\u015bnia\u0107 specyfik\u0119 serwisu, co mo\u017cna zrobi\u0107 w ten spos\u00f3b, a co w inny. Jeste\u015bmy zale\u017cni od ich konsultacji. Z pewno\u015bci\u0105 b\u0119dziemy musieli im co\u015b zleca\u0107, poniewa\u017c lepiej znaj\u0105 sw\u00f3j serwis. Dlatego wa\u017cne jest, z jakim zespo\u0142em w ko\u0144cu b\u0119dziemy mieli kontakt.<\/p>\n

Logiczne jest wybranie do zespo\u0142u innowator\u00f3w, poniewa\u017c konserwaty\u015bci mog\u0105 stwarza\u0107 problemy.\n<\/p><\/blockquote>\n

\nW praktyce cz\u0119sto okazuje si\u0119, \u017ce konserwaty\u015bci maj\u0105 znacz\u0105ce do\u015bwiadczenie, ale brakuje im zrozumienia, jak \u017cy\u0107 dalej. Po prostu boj\u0105 si\u0119, \u017ce po transformacji i przebudowie serwisu, strac\u0105 prac\u0119. Czasami, z powodu niezrozumienia sytuacji, sabotuj\u0105 prac\u0119.<\/p>\n

Mia\u0142em przypadek, gdy ch\u0142opak z zespo\u0142u naprawia\u0142 wszystko, co popadnie, poniewa\u017c uwa\u017ca\u0142, \u017ce to rzekomo wa\u017cniejsze ni\u017c to, co robimy teraz. Stawiamy zadanie: zrealizowa\u0107 dzi\u015b ten kawa\u0142ek \u2014 nie, na drugim ko\u0144cu \u015bwiata jest po\u017car, idziemy to naprawi\u0107. Praca z takimi lud\u017ami jest trudna.<\/p>\n

Ludzie z zespo\u0142u konserwatyst\u00f3w cz\u0119sto ignoruj\u0105 zadania lub odk\u0142adaj\u0105 je do ostatniej chwili. A je\u015bli, nie daj Bo\u017ce, pope\u0142nisz b\u0142\u0105d i na\u0142o\u017cysz im KPI za liczb\u0119 zrealizowanych zada\u0144, a jaka\u015b cz\u0119\u015b\u0107 nie zostanie uwzgl\u0119dniona w KPI, to w og\u00f3le nic nie b\u0119d\u0105 robi\u0107. W zasadzie b\u0119d\u0105 mieli racj\u0119, bo wtedy trac\u0105 premi\u0119.<\/p>\n

Z innowatorami jest \u0142atwiej \u2014 s\u0105 bardziej lojalni.<\/strong>S\u0142yszeli ju\u017c co\u015b, chc\u0105 i\u015b\u0107 do przodu, wi\u0119c b\u0119d\u0105 pomaga\u0107. Potrzebujemy ludzi, kt\u00f3rzy s\u0105 gotowi na trudno\u015bci na pocz\u0105tku: je\u015bli serwis si\u0119 zmienia, to wszystkie wpadki i problemy przejm\u0105 innowatorzy jako pionierzy. Innowatorzy chc\u0105 wszystkiego, co najnowsze i najbardziej stylowe, i s\u0105 gotowi na trudno\u015bci.<\/p>\n

Konserwatyst\u00f3w p\u00f3\u017aniej mo\u017cna nawr\u00f3ci\u0107 na swoj\u0105 wiar\u0119. Kiedy poka\u017cesz, \u017ce zmieni\u0142e\u015b kawa\u0142ek i wszystko dzia\u0142a dobrze, najprawdopodobniej oni r\u00f3wnie\u017c b\u0119d\u0105 chcieli spr\u00f3bowa\u0107 i przyjm\u0105 now\u0105 religi\u0119 DevOps.<\/p>\n

\"Jak
\n<\/p>\n

Podsumowuj\u0105c. Je\u015bli przeprowadzamy ca\u0142\u0105 transformacj\u0119 w naszej firmie samodzielnie, wybieramy: nowy serwis, najlepiej prosty interfejs, aby nie cierpie\u0107 z powodu jego awarii, i zesp\u00f3\u0142 innowator\u00f3w.<\/p><\/blockquote>\n

\nJe\u015bli istnieje mo\u017cliwo\u015b\u0107 zaproszenia zewn\u0119trznego konsultanta, zamiast nowego \u2014 bierzemy stary serwis, przez kt\u00f3ry ju\u017c cierpimy. Ludzie, kt\u00f3rzy zajmowali si\u0119 transformacj\u0105 do\u015b\u0107 d\u0142ugo w r\u00f3\u017cnych firmach, widzieli r\u00f3\u017cne przypadki i ju\u017c rozumiej\u0105, jak robi\u0107 to w\u0142a\u015bciwie i w kt\u00f3r\u0105 stron\u0119 w og\u00f3le i\u015b\u0107.<\/p>\n

Kto jest zaanga\u017cowany?<\/h2>\n

\nMusimy znale\u017a\u0107 naprawd\u0119 wszystkich, kt\u00f3rzy maj\u0105 jakikolwiek zwi\u0105zek z serwisem: programist\u00f3w, tester\u00f3w, admin\u00f3w, specjalist\u00f3w ds. bezpiecze\u0144stwa, mened\u017cer\u00f3w i by\u0107 mo\u017ce Product Owners. Mimo \u017ce Product Owners nie s\u0105 techniczni, maj\u0105 zwi\u0105zek z serwisem: podejmuj\u0105 decyzje, stawiaj\u0105 zadania.<\/p>\n

\"Jak
\n<\/p>\n

Wszystkich, kt\u00f3rzy podejmuj\u0105 jakiekolwiek decyzje i maj\u0105 wp\u0142yw na to, co dzieje si\u0119 z serwisem, nale\u017cy znale\u017a\u0107, pozna\u0107 i porozmawia\u0107.<\/p><\/blockquote>\n

\nPo co nam oni? Aby wiedzie\u0107, z kim si\u0119 dogadywa\u0107<\/strong>. W trakcie transformacji, kiedy zmienia si\u0119 zwyczajowy spos\u00f3b pracy z serwisem, i tak b\u0119dzie on poddawany zmianom. Przez jaki\u015b czas b\u0119d\u0105 wyst\u0119powa\u0107 problemy, podczas gdy testujemy nowe podej\u015bcia. Ludzie musz\u0105 by\u0107 na to gotowi i si\u0119 na to zgodzi\u0107.<\/p>\n

Nast\u0119pnie trzeba b\u0119dzie stworzy\u0107 map\u0119 warto\u015bci (Value Stream Map) i bez tych ludzi tego nie zrobisz, poniewa\u017c tylko oni wszyscy razem znaj\u0105 pe\u0142ny obraz sytuacji. Jeden cz\u0142owiek nigdy nie zna wszystkiego, co si\u0119 dzieje z serwisem.<\/p>\n

Sugeruj\u0105 ludzi do zespo\u0142u. P\u00f3\u017aniej porozmawiamy o tym, dlaczego potrzebny jest oddzielny zesp\u00f3\u0142. B\u0119dziemy musieli wzi\u0105\u0107 ludzi z istniej\u0105cych dzia\u0142\u00f3w. Ci, kt\u00f3rzy maj\u0105 zwi\u0105zek z serwisem, b\u0119d\u0105 mogli poleci\u0107 koleg\u00f3w my\u015bl\u0105cych w naszym kierunku, kt\u00f3rzy mog\u0105 nam pom\u00f3c i maj\u0105 kompetencje w tym, czego potrzebujemy.<\/p>\n

Nast\u0119pnie zbieramy wszystkich tych ludzi z r\u00f3\u017cnych dzia\u0142\u00f3w w jednym pomieszczeniu i zaczynamy budowa\u0107 map\u0119 warto\u015bci.<\/p>\n

Budujemy map\u0119 warto\u015bci<\/h2>\n

\nMapa warto\u015bci (Value Stream Map) to schemat lub mapa, kt\u00f3ra pokazuje przep\u0142yw warto\u015bci do klienta<\/strong>. To ca\u0142y proces od pomys\u0142u do realizacji, w\u0142\u0105czaj\u0105c wszystkie etapy po\u015brednie i to, jak warto\u015b\u0107 ostatecznie trafia do naszych klient\u00f3w.<\/p>\n

Mapa warto\u015bci jest potrzebna, aby zwizualizowa\u0107 wszystkie etapy rozwoju<\/strong>, zlokalizowa\u0107 problemy za pomoc\u0105 pomiar\u00f3w, kt\u00f3re istniej\u0105 w obecnym procesie, i zacz\u0105\u0107 te problemy usuwa\u0107, i ustali\u0107 pocz\u0105tkowy cel<\/strong>. To miejsce, w kt\u00f3rym zaczniemy co\u015b naprawd\u0119 robi\u0107.<\/p>\n

Metryki<\/h3>\n

\nW literaturze na temat mapy warto\u015bci opisano wiele r\u00f3\u017cnych metryk, ale na pocz\u0105tek wystarcz\u0105 nam tylko trzy.<\/p>\n

Lead Time \u2014 op\u00f3\u017anienie\/oczekiwanie<\/strong> \u2014 czas, kiedy na co\u015b czekamy. Na przyk\u0142ad, tester czeka, a\u017c zwolni si\u0119 stanowisko do test\u00f3w, i w tym czasie nie mo\u017ce nic robi\u0107.<\/p>\n

Czas warto\u015bci dodanej \u2014 czas u\u017cytecznej pracy<\/strong> \u2014 to, co wydali\u015bmy na danym etapie, aby stworzy\u0107 ko\u0144cow\u0105 warto\u015b\u0107 dla u\u017cytkownika. Na przyk\u0142ad, tester uruchomi\u0142 swoje testy i zacz\u0105\u0142 co\u015b sprawdza\u0107. To jest czas u\u017cytecznej pracy, kiedy naprawd\u0119 robimy co\u015b dla produktu. To jest to, za co klienci p\u0142ac\u0105 \u2014 za wysokiej jako\u015bci oprogramowanie.<\/p>\n

%C\/A \u2014 procent przyj\u0119tej pracy. <\/strong>Mamy jeden etap \u2014 rozw\u00f3j, drugi etap \u2014 testowanie. Ile funkcji testerzy przyj\u0119li od programist\u00f3w, a ten procent to w\u0142a\u015bnie.<\/p>\n

Tak wygl\u0105da nasza mapa.<\/p>\n

\"Jak
\n
\nMo\u017ce wygl\u0105da\u0107 inaczej w zale\u017cno\u015bci od struktury organizacji, liczby dzia\u0142\u00f3w i tego, czym si\u0119 zajmujesz. Ale w og\u00f3lnym przypadku na mapie b\u0119d\u0105 dwa etapy: idea <\/strong>i analityka<\/strong>. Na tym etapie oczekiwane s\u0105 dane, na przyk\u0142ad, Lead Time 2 tygodnie i czas warto\u015bci dodanej 2 dni.<\/p>\n

Metrykami pokrywamy absolutnie wszystkie etapy.<\/p><\/blockquote>\n

\nBacklog<\/strong> \u2014 ile zada\u0144 pozosta\u0142o po tym, jak analitycy je wymy\u015blili.<\/p>\n

Rozw\u00f3j<\/strong> \u2014 ile tygodni programi\u015bci czekali na wyja\u015bnienia dotycz\u0105ce zada\u0144, stanowisk lub sprz\u0119tu \u2014 nie ma znaczenia, ale na co\u015b czekaj\u0105. Na przyk\u0142ad, przez 4 dni realizuj\u0105 funkcj\u0119. Tutaj pojawia si\u0119 metryka %C\/A. Programi\u015bci wzi\u0119li z Backlog tylko 80% zada\u0144. Uwa\u017caj\u0105, \u017ce pozosta\u0142e 20% ma nie wystarczaj\u0105co jasne specyfikacje i odes\u0142ali je do poprawki.<\/p>\n

Testowanie<\/strong>. Na schemacie LT zadano 4 dni. Na przyk\u0142ad, testerzy czekali na zwolnienie stanowiska testowego, VA 2 dni faktycznie co\u015b testuj\u0105, a %C\/A = 40%. \u2014 tylko 40% kodu lub funkcji, kt\u00f3re przes\u0142ali programi\u015bci, testerzy uznali za odpowiednie. Wszystko inne im si\u0119 nie podoba\u0142o z jakiego\u015b powodu.<\/p>\n

Nie b\u0119d\u0119 szczeg\u00f3\u0142owo omawia\u0142, jak przeprowadza\u0107 te pomiary, na koniec artyku\u0142u polec\u0119 literatur\u0119, z kt\u00f3rej mo\u017cna si\u0119 o tym dowiedzie\u0107.<\/p>\n

Jedyna rzecz, kt\u00f3r\u0105 doradzam \u2014 nie wierzcie ludziom, kt\u00f3rzy b\u0119d\u0105 z wami tworzy\u0107 Value Stream Map. Przedstawiaj\u0105, ile czasu zajmuj\u0105 r\u00f3\u017cne procesy, ale te oceny nie zawsze s\u0105 prawdziwe, wi\u0119c lepiej wszystko zmierzy\u0107 samodzielnie.<\/p>\n

Mieli\u015bmy sytuacj\u0119, kiedy przeszli\u015bmy do dzia\u0142u Operations i zapytali\u015bmy, ile czasu zajmuje wprowadzenie nowej funkcji na produkcj\u0119. Odpowiedzieli nam, \u017ce 10 minut, a my pomy\u015bleli\u015bmy, po co w og\u00f3le przyszli\u015bmy do tej firmy? Okaza\u0142o si\u0119, \u017ce 10 minut to czas dzia\u0142ania skryptu, kt\u00f3ry pobiera kod i dostarcza go na serwer. Jednak przed tym wydanie le\u017cy przez trzy dni na serwerze i po prostu si\u0119 kurzy \u2014 w Backlogu le\u017cy zadanie, kt\u00f3re trzeba wdro\u017cy\u0107. Oznacza to, \u017ce przed faz\u0105 wdro\u017cenia jest faza oczekiwania, w kt\u00f3rej projekt po prostu le\u017cy. Gdyby\u015bmy nie wzi\u0119li notatnika, nie przykuwaj\u0105c wzroku do zadania w Jira i nie zacz\u0119li go \u015bledzi\u0107 krok po kroku, to byliby\u015bmy przekonani, \u017ce wszystko jest w porz\u0105dku i nie ma \u017cadnego problemu.<\/p>\n

Dlatego pomiary i tak b\u0119dzie trzeba zrobi\u0107 samemu, najlepiej nie raz, aby mie\u0107 realistyczny obraz. W zale\u017cno\u015bci od Value Stream Map, b\u0119dziesz podejmowa\u0107 decyzj\u0119, od kt\u00f3rego miejsca zacz\u0105\u0107 i co naprawi\u0107 w pierwszej kolejno\u015bci.<\/p>\n

Zesp\u00f3\u0142 tymczasowy<\/h2>\n

\nWiele firm, kt\u00f3re zdecydowa\u0142y si\u0119 wdro\u017cy\u0107 DevOps, tworzy zesp\u00f3\u0142, tylko \u017ce nie tymczasowy, a istniej\u0105cy od kilku lat. Je\u015bli zwr\u00f3cisz si\u0119 do us\u0142ugi DevOps apologize, na kt\u00f3rej opisane s\u0105 r\u00f3\u017cne wzorce budowy struktury organizacyjnej w DevOps, to zrozumiesz, \u017ce to jest antipattern.<\/p>\n

Kiedy zesp\u00f3\u0142 DevOps istnieje przez kilka lat \u2014 to du\u017cy b\u0142\u0105d, poniewa\u017c DevOps dotyczy komunikacji mi\u0119dzy dzia\u0142ami, szybko\u015bci i efektywno\u015bci.<\/p><\/blockquote>\n

\nJe\u015bli zesp\u00f3\u0142 istnieje mi\u0119dzy dzia\u0142ami, tylko po to, aby robi\u0107 co\u015b jeszcze oddzielnego, i istnieje d\u0142ugo, to stwarza dodatkow\u0105 barier\u0119. Teraz programista zamiast od razu i\u015b\u0107 do administratora, aby rozwi\u0105za\u0107 problem, musi najpierw zwr\u00f3ci\u0107 si\u0119 do dzia\u0142u DevOps, a ten ju\u017c p\u00f3jdzie dalej.<\/p>\n

Dlatego, aby zacz\u0105\u0107, nale\u017cy stworzy\u0107 zesp\u00f3\u0142 tymczasowy.<\/strong>. B\u0119dzie istnie\u0107 warunkowo przez p\u00f3\u0142 roku, maksymalnie rok, w zale\u017cno\u015bci od postawionego zadania, tylko po to, aby wyeliminowa\u0107 jedno ograniczenie, kt\u00f3re wybrali\u015bmy. P\u00f3\u017aniej umrze. Je\u015bli wybierzemy kolejny punkt, w kt\u00f3rym mocno boli, i zrozumiemy, \u017ce potrzebujemy dla niego tak\u017ce osobnego zespo\u0142u, wtedy znowu go stworzymy. Jednak na<\/p>\n

Dlaczego potrzebny jest tymczasowy zesp\u00f3\u0142<\/h3>\n

\nKonflikt z bie\u017c\u0105cymi procesami<\/strong>. Transformacja DevOps to zmiana nie tylko technologii i narz\u0119dzi, z kt\u00f3rych korzystamy, ale tak\u017ce samego procesu pracy, my\u015blenia i warto\u015bci. Je\u015bli zesp\u00f3\u0142 b\u0119dzie pracowa\u0107 tak, jak ju\u017c jest przyzwyczajony, nie uda mu si\u0119 wypr\u00f3bowa\u0107 innych podej\u015b\u0107.<\/p>\n

Ci ludzie musz\u0105 \u017cy\u0107 wed\u0142ug innych zasad: ignorowa\u0107 wszystkie KPI w firmie, poniewa\u017c staraj\u0105 si\u0119 pracowa\u0107 w inny spos\u00f3b. Tymczasowe zespo\u0142y nie b\u0119d\u0105 sk\u0142ada\u0107 wniosk\u00f3w o serwery, lecz bezpo\u015brednio zwr\u00f3c\u0105 si\u0119 do dzia\u0142u, kt\u00f3ry nimi zarz\u0105dza, z \u017c\u0105daniem dostarczenia im jako pierwszym tego, czego potrzebuj\u0105, poniewa\u017c to zadanie ma priorytet i poniewa\u017c pr\u00f3buj\u0105 \u017cy\u0107 inaczej. Zesp\u00f3\u0142 ma pe\u0142ny konflikt ze wszystkimi bie\u017c\u0105cymi procesami. Aby istniej\u0105ce metody pracy nie przeszkadza\u0142y im teraz, a oni nie przeszkadzali innym, izolujemy tych ludzi, tworz\u0105c osobny zesp\u00f3\u0142.<\/p>\n

Unikanie biurokracji w eksperymentach<\/strong>. W tymczasowych zespo\u0142ach nie ma biurokracji, nie wype\u0142niaj\u0105 raport\u00f3w dotycz\u0105cych przepracowanych godzin, nie rozliczaj\u0105 si\u0119 z mened\u017cerami. To ca\u0142kowicie odmienny \u015bwiat, w kt\u00f3rym ludzie \u017cyj\u0105 i my\u015bl\u0105 inaczej i zajmuj\u0105 si\u0119 zupe\u0142nie innymi rzeczami. Nie trzeba im w tym dodatkowo przeszkadza\u0107.<\/p>\n

Nieprzerwana praca nad us\u0142ug\u0105<\/strong>. W pierwszym punkcie wybrali\u015bmy co\u015b, na czym b\u0119dziemy eksperymentowa\u0107. Eksperymenty i poszukiwanie lepszych sposob\u00f3w pracy to dobrze, ale chcemy te\u017c realizowa\u0107 funkcje. Je\u015bli ca\u0142y zesp\u00f3\u0142 zamiast funkcji zajmie si\u0119 transformacj\u0105, zaczniemy traci\u0107 dochody, b\u0142\u0119dy b\u0119d\u0105 d\u0142ugo wisie\u0107 - tego nie potrzebujemy. Utworzenie tymczasowego zespo\u0142u pozwala na eksperymentowanie, nie zatrzymuj\u0105c jednocze\u015bnie pracy nad produktem.<\/p>\n

Nie traci\u0107 czasu na zadania robocze<\/strong>. To znowu o produkcie. Wymaga du\u017co czasu, aby zesp\u00f3\u0142 spr\u00f3bowa\u0142 innych narz\u0119dzi i tym podobnych. Aby ludzie nauczyli si\u0119 narz\u0119dzi, zacz\u0119li je wdra\u017ca\u0107 i normalnie u\u017cywa\u0107, potrzeba co najmniej p\u00f3\u0142 roku. Je\u015bli b\u0119d\u0105 zajmowa\u0107 si\u0119 jeszcze i produktem, to p\u00f3\u0142 roku rozci\u0105gnie si\u0119 kosmicznie. Je\u015bli ludzie zajmuj\u0105 si\u0119 produktem, zn\u00f3w pracuj\u0105 ze starymi procesami \u2014 tego nie potrzebujemy.<\/p>\n

Dlatego z r\u00f3\u017cnych dzia\u0142\u00f3w wyodr\u0119bniamy ludzi do osobnego zespo\u0142u, kt\u00f3ry zajmie si\u0119 transformacj\u0105 us\u0142ugi. W rezultacie us\u0142uga dzia\u0142a, rozwija si\u0119 i jednocze\u015bnie przeprowadzamy na niej pewne eksperymenty.<\/p>\n

Tymczasowy zesp\u00f3\u0142 zajmuje si\u0119 tylko transformacj\u0105 DevOps \u2014 likwidacj\u0105 ogranicze\u0144, kt\u00f3re znale\u017ali\u015bmy, i niczym wi\u0119cej.<\/p><\/blockquote>\n

\nZesp\u00f3\u0142 sk\u0142ada si\u0119 z uniwersalnych ludzi<\/strong>. Oznacza to, \u017ce wzi\u0119li\u015bmy nie tylko programist\u00f3w. Nie przyszli\u015bmy do us\u0142ugi i nie zabrali\u015bmy stamt\u0105d p\u00f3\u0142 zespo\u0142u \u2014 nie, wzi\u0119li\u015bmy ludzi z r\u00f3\u017cnych dzia\u0142\u00f3w<\/strong>. Kilka punkt\u00f3w temu znale\u017ali\u015bmy r\u00f3\u017cne dzia\u0142y i r\u00f3\u017cnych pracownik\u00f3w, kt\u00f3rzy maj\u0105 zwi\u0105zek z transformowan\u0105 us\u0142ug\u0105. Z nich tworzymy zesp\u00f3\u0142, poniewa\u017c musi by\u0107 uniwersalny \u2014 b\u0119dziemy zmienia\u0107 zar\u00f3wno proces testowania, jak i proces rozwoju oraz proces obs\u0142ugi us\u0142ugi. Potrzebne s\u0105 r\u00f3\u017cne kompetencje.<\/p>\n

Zazwyczaj wyodr\u0119bniamy programist\u0119, testera i in\u017cyniera \u2014 ka\u017cdego po jednym, a wsp\u00f3lnie z nimi wymy\u015blamy rozwi\u0105zanie, kt\u00f3re pozwala \u017cy\u0107 inaczej.<\/p>\n

Wskazane by by\u0142o, aby ci ludzie mieli autorytet w organizacji<\/strong>. Mo\u017cliwe, \u017ce trzeba b\u0119dzie wzi\u0105\u0107 jednego konserwatyst\u0119, cho\u0107 nie chcemy. Je\u015bli mamy du\u017c\u0105 firm\u0119, daleko nie wszyscy uwierz\u0105 w nasz pomys\u0142, a kto\u015b mo\u017ce podk\u0142ada\u0107 k\u0142ody, na przyk\u0142ad nie przydzielaj\u0105c \u015brodowiska testowego. Tutaj b\u0119dzie potrzebny 'autorytet' \u2014 szanowany cz\u0142owiek z du\u017cym do\u015bwiadczeniem, kt\u00f3ry zdoby\u0142 dobre relacje z kolegami. Autorytet pracownika w zespole u\u0142atwi zadanie i prac\u0119 tymczasowego zespo\u0142u. Ludzie pomy\u015bl\u0105:<\/p>\n

\u2014 Aha, ten fajny go\u015b\u0107, kt\u00f3rego wszyscy znamy i lubimy, wpasowa\u0142 si\u0119 \u2014 chyba w DevOps jest co\u015b, na co warto zwr\u00f3ci\u0107 uwag\u0119!<\/em><\/p>\n

Ustalamy cel<\/h2>\n

\nZebrali\u015bmy ludzi, wybrali\u015bmy us\u0142ug\u0119, przyjrzeli\u015bmy si\u0119 ograniczeniom, okre\u015blili\u015bmy, na jakich ludzi wp\u0142yniemy. Teraz trzeba ustawi\u0107 cel i powinien by\u0107 on konkretny zgodnie z SMART<\/strong> \u2014 wszystko, jak lubimy.<\/p>\n

Specyficzny \u2014 konkretna<\/strong>.<\/p>\n

Mierzalny \u2014 mierzalna<\/strong>. To jest bardzo wa\u017cny punkt SMART. Je\u015bli czego\u015b nie mo\u017cesz zmierzy\u0107, nie mo\u017cesz tego zmieni\u0107 ani zrozumie\u0107, co i jak poprawi\u0142e\u015b lub pogorszy\u0142e\u015b.<\/p>\n

Osi\u0105galny \u2014 osi\u0105galna<\/strong>. Ustal swoje specyfikacje. Je\u015bli jeste\u015b firm\u0105 z du\u017cym do\u015bwiadczeniem i wieloma obowi\u0105zkami, kt\u00f3ra wydaje wersj\u0119 produktu raz w roku, nie b\u0119dziesz w stanie w ci\u0105gu p\u00f3\u0142 roku osi\u0105gn\u0105\u0107 wydania nowych wersji produktu co godzin\u0119. To nie jest mo\u017cliwe. Dlatego wyznaczaj realistyczny cel, kt\u00f3ry mo\u017cna osi\u0105gn\u0105\u0107 w rozs\u0105dnym czasie.<\/p>\n

Relewantny \u2014 relewantna. <\/strong>Eliminujemy tylko te ograniczenia, kt\u00f3re rzeczywi\u015bcie wp\u0142ywaj\u0105 na nasze obecne cele.<\/p>\n

Ograniczone czasowo \u2014 ograniczona w czasie<\/strong>. Brak deadline'u spowoduje, \u017ce zesp\u00f3\u0142 zajmie si\u0119 wszystkim: testowaniem 15 technologii zamiast 3, pisaniem ogromnych raport\u00f3w, przeprowadzaniem bezu\u017cytecznych bada\u0144, dopracowywaniem swojej realizacji do perfekcji, kiedy cel ju\u017c zosta\u0142 osi\u0105gni\u0119ty.<\/p>\n

Cel definiujemy przy pomocy Value Stream Map \u2014 znowu zbieramy wszystkich ludzi i rysujemy. Ale tym razem na podstawie wcze\u015bniejszej Value Stream Map rysujemy to, co chcemy osi\u0105gn\u0105\u0107.<\/p>\n

\"Jak
\n
\nWybieramy jedno ograniczenie, kt\u00f3re b\u0119dziemy w\u0142a\u015bnie teraz eliminowa\u0107 \u2014 tym zajmie si\u0119 zesp\u00f3\u0142. Na przyk\u0142ad wzi\u0105\u0142em czas oczekiwania od gotowego wydania do jego wdro\u017cenia w produkcji \u2014 to najcz\u0119stsze ograniczenie, z kt\u00f3rym ludzie zwracaj\u0105 si\u0119 do konsultant\u00f3w.<\/p>\n

Na podstawie tego wyznaczamy zadanie: chcemy, aby czas oczekiwania mi\u0119dzy gotowym wydaniem a wdro\u017ceniem do u\u017cycia wynosi\u0142 maksymalnie godzin\u0119.<\/p>\n

Przyk\u0142ady zada\u0144.<\/p>\n