Jeśli nie rozumiesz, czym jest DevOps, oto krótkie streszczenie. DevOps to zestaw praktyk, które zmniejszają obawy inżynierów i skracają liczbę awarii w produkcji oprogramowania. Zazwyczaj również krótką czas wprowadzenia na rynek — okres od pomysłu do dostarczenia gotowego produktu do klientów, co pozwala na szybkie przeprowadzanie eksperymentów biznesowych..
Jak rozpocząć transformację DevOps? W skrócie: wybieramy usługę, od której zaczniemy proces, identyfikujemy osoby związane z usługą, budujemy Mapę Wartości, tworzymy tymczasowy zespół, który na początku zajmie się transformacją, i stawiamy mu zadanie. Powtarzamy cykl odpowiednią liczbę razy.
Szczegółowy plan transformacji DevOps z przykładami i instrukcjami pod spodem — w opracowaniu Andrieja Aleksandrowa — inżyniera w firmie Express42, która doradza w zakresie wdrażania DevOps, przyspieszając ten proces, ponieważ już zbudowała mapę pułapek. Jeśli uważasz, że transformacja nie jest dla ciebie potrzebna, lub twoja specyfika sprawia, że praktyki DevOps nie pasują, — korzystaj z raportu jako instrukcji do zidentyfikowania i usuwania ograniczeń.
Jeśli masz wątpliwości co do transformacji DevOps, to masz dużą firmę, i należy stopniowo skalować ten proces na całą strukturę. Dopóki istnieje potrzeba transformacji zespołu lub usunięcia jakiegoś ograniczenia, algorytm poniżej można powtarzać.
Wybór usługi
Plan nakreślony, zaczynamy od pierwszego kroku — wyboru usługi. Pierwszym kryterium jest czas życia: są stare usługi — legacy, oraz nowe. Można zacząć zarówno od jednych, jak i od drugich.
Wybór młodej usługi jest logiczny. Jest świeża, nie ma jeszcze ustalonego procesu pracy w zespole, który się nią zajmuje. Nie ma wokół niej góry zobowiązań technicznych, nie trzeba jej ciągle naprawiać. Możemy z nią robić, co chcemy.
W przypadku starej usługi pojawiają się problemy związane z tym, że zmiany zawsze są trudne. Istnieje już zestaw poważnych ograniczeń, ale być może zajmują się nimi ludzie, którzy są już gotowi wszystko przeorganizować — są zmęczeni i chcą coś zmienić, bo czują ból.
Praca ze starą usługą tworzy potężny precedens w twojej firmie — można coś zmieniać. Jeśli zmienisz nową usługę, działa na produkcji 100 razy na godzinę i wszystko jest dobrze, to ludzie w twojej firmie mogą powiedzieć:
To nowy serwis! Wszystko było proste, spróbuj zrobić cokolwiek z naszą starą wersją.
Serwis Legacy ma sens zmieniać, gdy robisz to z kimś, na przykład, jeśli zaprosisz zewnętrznego konsultanta. Bądźmy szczerzy, transformacja wstrząśnie wszystkim, co tylko można.Eksperymentujesz i nie wiesz, dokąd zmierzysz, jakie technologie i po co wykorzystasz, gdzie i jakie pułapki w procesach się pojawią. Dlatego łatwiej zmienić na nowy.
Jeśli wszystko robisz sam, a w firmie nie ma poważnej kompetencji — wybieraj nowy serwis. Jeśli znasz zewnętrznego konsultanta i masz środki — wybierz stary.
Są serwisy, które przedstawiają się tylko jako interfejs dla użytkowników, na przykład prosta strona internetowa lub aplikacja mobilna. Ale są też poważne rzeczy, takie jak bilingi. Jeśli coś pójdzie nie tak z billingiem — naprawa będzie trudna. W tym też mamy wybór.
Pracujemy albo z krytycznym serwisem, ale przez niego już cierpimy, tworzy ograniczenia, albo pracujemy z interfejsem. To drugi kryterium wyboru. Analogicznie, istnieje możliwość zaangażowania doświadczonego konsultanta — pracujemy z trudniejszą wersją.
Ale nawet w tym przypadku nie zalecałbym tego robić, ponieważ, dopóki nie ma zrozumienia, z czym pracować i w jaką stronę transformować, branie krytycznej rzeczy i jej przekształcanie — to niezbyt dobry pomysł. Dlatego w tym przypadku wolimy pracować z interfejsem, którego awaria nie jest krytyczna.
Dalej przyjrzymy się zespołowi serwisu. Z tymi, którzy zajmują się tym serwisem, będziemy musieli ciągle pracować i mieć bardzo bliski kontakt.
Ludzie w zespole dzielą się na dwie kategorie: konserwatyści — żyją w starym świecie lub po prostu nic nie wiedzą o DevOps, i innowatorzy, którzy wprowadzają wszystkie nowinki. Drudzy nie zawsze rozumieją temat, ale przynajmniej są na niego gotowi.
Z jednej strony konserwatyści — doświadczeni ludzie: długo w firmie, rozumieją wszystko od podstaw, ale nie znają praktyk. Z drugiej strony — innowatorzy, którzy coś słyszeli, ale w firmie prawdopodobnie są nie za długo. Z kim lepiej pracować?
W przypadku konserwatystów będziemy musieli nawiązać współpracę, bo to ich serwis. Będziemy musieli z nimi rozmawiać, wyjaśniać specyfikę serwisu, co można zrobić w ten sposób, a co w inny. Jesteśmy zależni od ich konsultacji. Z pewnością będziemy musieli im coś zlecać, ponieważ lepiej znają swój serwis. Dlatego ważne jest, z jakim zespołem w końcu będziemy mieli kontakt.
Logiczne jest wybranie do zespołu innowatorów, ponieważ konserwatyści mogą stwarzać problemy.
W praktyce często okazuje się, że konserwatyści mają znaczące doświadczenie, ale brakuje im zrozumienia, jak żyć dalej. Po prostu boją się, że po transformacji i przebudowie serwisu, stracą pracę. Czasami, z powodu niezrozumienia sytuacji, sabotują pracę.
Miałem przypadek, gdy chłopak z zespołu naprawiał wszystko, co popadnie, ponieważ uważał, że to rzekomo ważniejsze niż to, co robimy teraz. Stawiamy zadanie: zrealizować dziś ten kawałek — nie, na drugim końcu świata jest pożar, idziemy to naprawić. Praca z takimi ludźmi jest trudna.
Ludzie z zespołu konserwatystów często ignorują zadania lub odkładają je do ostatniej chwili. A jeśli, nie daj Boże, popełnisz błąd i nałożysz im KPI za liczbę zrealizowanych zadań, a jakaś część nie zostanie uwzględniona w KPI, to w ogóle nic nie będą robić. W zasadzie będą mieli rację, bo wtedy tracą premię.
Z innowatorami jest łatwiej — są bardziej lojalni.Słyszeli już coś, chcą iść do przodu, więc będą pomagać. Potrzebujemy ludzi, którzy są gotowi na trudności na początku: jeśli serwis się zmienia, to wszystkie wpadki i problemy przejmą innowatorzy jako pionierzy. Innowatorzy chcą wszystkiego, co najnowsze i najbardziej stylowe, i są gotowi na trudności.
Konserwatystów później można nawrócić na swoją wiarę. Kiedy pokażesz, że zmieniłeś kawałek i wszystko działa dobrze, najprawdopodobniej oni również będą chcieli spróbować i przyjmą nową religię DevOps.
Podsumowując. Jeśli przeprowadzamy całą transformację w naszej firmie samodzielnie, wybieramy: nowy serwis, najlepiej prosty interfejs, aby nie cierpieć z powodu jego awarii, i zespół innowatorów.
Jeśli istnieje możliwość zaproszenia zewnętrznego konsultanta, zamiast nowego — bierzemy stary serwis, przez który już cierpimy. Ludzie, którzy zajmowali się transformacją dość długo w różnych firmach, widzieli różne przypadki i już rozumieją, jak robić to właściwie i w którą stronę w ogóle iść.
Kto jest zaangażowany?
Musimy znaleźć naprawdę wszystkich, którzy mają jakikolwiek związek z serwisem: programistów, testerów, adminów, specjalistów ds. bezpieczeństwa, menedżerów i być może Product Owners. Mimo że Product Owners nie są techniczni, mają związek z serwisem: podejmują decyzje, stawiają zadania.
Wszystkich, którzy podejmują jakiekolwiek decyzje i mają wpływ na to, co dzieje się z serwisem, należy znaleźć, poznać i porozmawiać.
Po co nam oni? Aby wiedzieć, z kim się dogadywać. W trakcie transformacji, kiedy zmienia się zwyczajowy sposób pracy z serwisem, i tak będzie on poddawany zmianom. Przez jakiś czas będą występować problemy, podczas gdy testujemy nowe podejścia. Ludzie muszą być na to gotowi i się na to zgodzić.
Następnie trzeba będzie stworzyć mapę wartości (Value Stream Map) i bez tych ludzi tego nie zrobisz, ponieważ tylko oni wszyscy razem znają pełny obraz sytuacji. Jeden człowiek nigdy nie zna wszystkiego, co się dzieje z serwisem.
Sugerują ludzi do zespołu. Później porozmawiamy o tym, dlaczego potrzebny jest oddzielny zespół. Będziemy musieli wziąć ludzi z istniejących działów. Ci, którzy mają związek z serwisem, będą mogli polecić kolegów myślących w naszym kierunku, którzy mogą nam pomóc i mają kompetencje w tym, czego potrzebujemy.
Następnie zbieramy wszystkich tych ludzi z różnych działów w jednym pomieszczeniu i zaczynamy budować mapę wartości.
Budujemy mapę wartości
Mapa wartości (Value Stream Map) to schemat lub mapa, która pokazuje przepływ wartości do klienta. To cały proces od pomysłu do realizacji, włączając wszystkie etapy pośrednie i to, jak wartość ostatecznie trafia do naszych klientów.
Mapa wartości jest potrzebna, aby zwizualizować wszystkie etapy rozwoju, zlokalizować problemy za pomocą pomiarów, które istnieją w obecnym procesie, i zacząć te problemy usuwać, i ustalić początkowy cel. To miejsce, w którym zaczniemy coś naprawdę robić.
Metryki
W literaturze na temat mapy wartości opisano wiele różnych metryk, ale na początek wystarczą nam tylko trzy.
Lead Time — opóźnienie/oczekiwanie — czas, kiedy na coś czekamy. Na przykład, tester czeka, aż zwolni się stanowisko do testów, i w tym czasie nie może nic robić.
Czas wartości dodanej — czas użytecznej pracy — to, co wydaliśmy na danym etapie, aby stworzyć końcową wartość dla użytkownika. Na przykład, tester uruchomił swoje testy i zaczął coś sprawdzać. To jest czas użytecznej pracy, kiedy naprawdę robimy coś dla produktu. To jest to, za co klienci płacą — za wysokiej jakości oprogramowanie.
%C/A — procent przyjętej pracy. Mamy jeden etap — rozwój, drugi etap — testowanie. Ile funkcji testerzy przyjęli od programistów, a ten procent to właśnie.
Tak wygląda nasza mapa.
Może wyglądać inaczej w zależności od struktury organizacji, liczby działów i tego, czym się zajmujesz. Ale w ogólnym przypadku na mapie będą dwa etapy: idea i analityka. Na tym etapie oczekiwane są dane, na przykład, Lead Time 2 tygodnie i czas wartości dodanej 2 dni.
Metrykami pokrywamy absolutnie wszystkie etapy.
Backlog — ile zadań pozostało po tym, jak analitycy je wymyślili.
Rozwój — ile tygodni programiści czekali na wyjaśnienia dotyczące zadań, stanowisk lub sprzętu — nie ma znaczenia, ale na coś czekają. Na przykład, przez 4 dni realizują funkcję. Tutaj pojawia się metryka %C/A. Programiści wzięli z Backlog tylko 80% zadań. Uważają, że pozostałe 20% ma nie wystarczająco jasne specyfikacje i odesłali je do poprawki.
Testowanie. Na schemacie LT zadano 4 dni. Na przykład, testerzy czekali na zwolnienie stanowiska testowego, VA 2 dni faktycznie coś testują, a %C/A = 40%. — tylko 40% kodu lub funkcji, które przesłali programiści, testerzy uznali za odpowiednie. Wszystko inne im się nie podobało z jakiegoś powodu.
Nie będę szczegółowo omawiał, jak przeprowadzać te pomiary, na koniec artykułu polecę literaturę, z której można się o tym dowiedzieć.
Jedyna rzecz, którą doradzam — nie wierzcie ludziom, którzy będą z wami tworzyć Value Stream Map. Przedstawiają, ile czasu zajmują różne procesy, ale te oceny nie zawsze są prawdziwe, więc lepiej wszystko zmierzyć samodzielnie.
Mieliśmy sytuację, kiedy przeszliśmy do działu Operations i zapytaliśmy, ile czasu zajmuje wprowadzenie nowej funkcji na produkcję. Odpowiedzieli nam, że 10 minut, a my pomyśleliśmy, po co w ogóle przyszliśmy do tej firmy? Okazało się, że 10 minut to czas działania skryptu, który pobiera kod i dostarcza go na serwer. Jednak przed tym wydanie leży przez trzy dni na serwerze i po prostu się kurzy — w Backlogu leży zadanie, które trzeba wdrożyć. Oznacza to, że przed fazą wdrożenia jest faza oczekiwania, w której projekt po prostu leży. Gdybyśmy nie wzięli notatnika, nie przykuwając wzroku do zadania w Jira i nie zaczęli go śledzić krok po kroku, to bylibyśmy przekonani, że wszystko jest w porządku i nie ma żadnego problemu.
Dlatego pomiary i tak będzie trzeba zrobić samemu, najlepiej nie raz, aby mieć realistyczny obraz. W zależności od Value Stream Map, będziesz podejmować decyzję, od którego miejsca zacząć i co naprawić w pierwszej kolejności.
Zespół tymczasowy
Wiele firm, które zdecydowały się wdrożyć DevOps, tworzy zespół, tylko że nie tymczasowy, a istniejący od kilku lat. Jeśli zwrócisz się do usługi DevOps apologize, na której opisane są różne wzorce budowy struktury organizacyjnej w DevOps, to zrozumiesz, że to jest antipattern.
Kiedy zespół DevOps istnieje przez kilka lat — to duży błąd, ponieważ DevOps dotyczy komunikacji między działami, szybkości i efektywności.
Jeśli zespół istnieje między działami, tylko po to, aby robić coś jeszcze oddzielnego, i istnieje długo, to stwarza dodatkową barierę. Teraz programista zamiast od razu iść do administratora, aby rozwiązać problem, musi najpierw zwrócić się do działu DevOps, a ten już pójdzie dalej.
Dlatego, aby zacząć, należy stworzyć zespół tymczasowy.. Będzie istnieć warunkowo przez pół roku, maksymalnie rok, w zależności od postawionego zadania, tylko po to, aby wyeliminować jedno ograniczenie, które wybraliśmy. Później umrze. Jeśli wybierzemy kolejny punkt, w którym mocno boli, i zrozumiemy, że potrzebujemy dla niego także osobnego zespołu, wtedy znowu go stworzymy. Jednak na
Dlaczego potrzebny jest tymczasowy zespół
Konflikt z bieżącymi procesami. Transformacja DevOps to zmiana nie tylko technologii i narzędzi, z których korzystamy, ale także samego procesu pracy, myślenia i wartości. Jeśli zespół będzie pracować tak, jak już jest przyzwyczajony, nie uda mu się wypróbować innych podejść.
Ci ludzie muszą żyć według innych zasad: ignorować wszystkie KPI w firmie, ponieważ starają się pracować w inny sposób. Tymczasowe zespoły nie będą składać wniosków o serwery, lecz bezpośrednio zwrócą się do działu, który nimi zarządza, z żądaniem dostarczenia im jako pierwszym tego, czego potrzebują, ponieważ to zadanie ma priorytet i ponieważ próbują żyć inaczej. Zespół ma pełny konflikt ze wszystkimi bieżącymi procesami. Aby istniejące metody pracy nie przeszkadzały im teraz, a oni nie przeszkadzali innym, izolujemy tych ludzi, tworząc osobny zespół.
Unikanie biurokracji w eksperymentach. W tymczasowych zespołach nie ma biurokracji, nie wypełniają raportów dotyczących przepracowanych godzin, nie rozliczają się z menedżerami. To całkowicie odmienny świat, w którym ludzie żyją i myślą inaczej i zajmują się zupełnie innymi rzeczami. Nie trzeba im w tym dodatkowo przeszkadzać.
Nieprzerwana praca nad usługą. W pierwszym punkcie wybraliśmy coś, na czym będziemy eksperymentować. Eksperymenty i poszukiwanie lepszych sposobów pracy to dobrze, ale chcemy też realizować funkcje. Jeśli cały zespół zamiast funkcji zajmie się transformacją, zaczniemy tracić dochody, błędy będą długo wisieć - tego nie potrzebujemy. Utworzenie tymczasowego zespołu pozwala na eksperymentowanie, nie zatrzymując jednocześnie pracy nad produktem.
Nie tracić czasu na zadania robocze. To znowu o produkcie. Wymaga dużo czasu, aby zespół spróbował innych narzędzi i tym podobnych. Aby ludzie nauczyli się narzędzi, zaczęli je wdrażać i normalnie używać, potrzeba co najmniej pół roku. Jeśli będą zajmować się jeszcze i produktem, to pół roku rozciągnie się kosmicznie. Jeśli ludzie zajmują się produktem, znów pracują ze starymi procesami — tego nie potrzebujemy.
Dlatego z różnych działów wyodrębniamy ludzi do osobnego zespołu, który zajmie się transformacją usługi. W rezultacie usługa działa, rozwija się i jednocześnie przeprowadzamy na niej pewne eksperymenty.
Tymczasowy zespół zajmuje się tylko transformacją DevOps — likwidacją ograniczeń, które znaleźliśmy, i niczym więcej.
Zespół składa się z uniwersalnych ludzi. Oznacza to, że wzięliśmy nie tylko programistów. Nie przyszliśmy do usługi i nie zabraliśmy stamtąd pół zespołu — nie, wzięliśmy ludzi z różnych działów. Kilka punktów temu znaleźliśmy różne działy i różnych pracowników, którzy mają związek z transformowaną usługą. Z nich tworzymy zespół, ponieważ musi być uniwersalny — będziemy zmieniać zarówno proces testowania, jak i proces rozwoju oraz proces obsługi usługi. Potrzebne są różne kompetencje.
Zazwyczaj wyodrębniamy programistę, testera i inżyniera — każdego po jednym, a wspólnie z nimi wymyślamy rozwiązanie, które pozwala żyć inaczej.
Wskazane by było, aby ci ludzie mieli autorytet w organizacji. Możliwe, że trzeba będzie wziąć jednego konserwatystę, choć nie chcemy. Jeśli mamy dużą firmę, daleko nie wszyscy uwierzą w nasz pomysł, a ktoś może podkładać kłody, na przykład nie przydzielając środowiska testowego. Tutaj będzie potrzebny 'autorytet' — szanowany człowiek z dużym doświadczeniem, który zdobył dobre relacje z kolegami. Autorytet pracownika w zespole ułatwi zadanie i pracę tymczasowego zespołu. Ludzie pomyślą:
— Aha, ten fajny gość, którego wszyscy znamy i lubimy, wpasował się — chyba w DevOps jest coś, na co warto zwrócić uwagę!
Ustalamy cel
Zebraliśmy ludzi, wybraliśmy usługę, przyjrzeliśmy się ograniczeniom, określiliśmy, na jakich ludzi wpłyniemy. Teraz trzeba ustawić cel i powinien być on konkretny zgodnie z SMART — wszystko, jak lubimy.
Specyficzny — konkretna.
Mierzalny — mierzalna. To jest bardzo ważny punkt SMART. Jeśli czegoś nie możesz zmierzyć, nie możesz tego zmienić ani zrozumieć, co i jak poprawiłeś lub pogorszyłeś.
Osiągalny — osiągalna. Ustal swoje specyfikacje. Jeśli jesteś firmą z dużym doświadczeniem i wieloma obowiązkami, która wydaje wersję produktu raz w roku, nie będziesz w stanie w ciągu pół roku osiągnąć wydania nowych wersji produktu co godzinę. To nie jest możliwe. Dlatego wyznaczaj realistyczny cel, który można osiągnąć w rozsądnym czasie.
Relewantny — relewantna. Eliminujemy tylko te ograniczenia, które rzeczywiście wpływają na nasze obecne cele.
Ograniczone czasowo — ograniczona w czasie. Brak deadline'u spowoduje, że zespół zajmie się wszystkim: testowaniem 15 technologii zamiast 3, pisaniem ogromnych raportów, przeprowadzaniem bezużytecznych badań, dopracowywaniem swojej realizacji do perfekcji, kiedy cel już został osiągnięty.
Cel definiujemy przy pomocy Value Stream Map — znowu zbieramy wszystkich ludzi i rysujemy. Ale tym razem na podstawie wcześniejszej Value Stream Map rysujemy to, co chcemy osiągnąć.
Wybieramy jedno ograniczenie, które będziemy właśnie teraz eliminować — tym zajmie się zespół. Na przykład wziąłem czas oczekiwania od gotowego wydania do jego wdrożenia w produkcji — to najczęstsze ograniczenie, z którym ludzie zwracają się do konsultantów.
Na podstawie tego wyznaczamy zadanie: chcemy, aby czas oczekiwania między gotowym wydaniem a wdrożeniem do użycia wynosił maksymalnie godzinę.
Przykłady zadań.
- Skrócić Lead Time testowania z 4 dni do 1 godziny.
- Skrócić Value Added Time dla testowania z 2 dni do 3 godzin.
- Skrócić Lead Time wdrożenia z 5 godzin do 10 minut.
- Zwiększyć C/A z 50% do 95%, czyli zwiększyć liczbę funkcji, które akceptują testerzy, inaczej mówiąc, poprawić jakość pracy programistów.
Przykłady zadań nie są wymyślone — opierają się na pomiarach, które wykonaliśmy, kiedy opracowywaliśmy Value Stream Map.
Wyznaczamy podobne zadanie dla naszego zespołu z ograniczeniem czasowym. W zależności od tego, jak dobrze wygląda sytuacja w twojej firmie, ustalacie różne terminy. Średnio, na eliminację ograniczenia, gdy ludzie to robią po raz pierwszy i nie wiedzą jeszcze, jakimi technologiami i jak konkretnie będą rozwiązywać problem, zwykle potrzeba pół roku.
Skrócone planowanie
Tak, nasz zespół został utworzony, ma cel, ludzie zaczynają pracować. Ważnym punktem jest krótkie planowanie pracy: sprinty trwające jeden-dwa tygodniei nie więcej, mierzalne poprawy co tydzień i korekta kursu.
Na przykład często używamy podejścia moving-moving, kiedy cały zespół spotyka się na początku każdego tygodnia, notuje w pliku, co każdy będzie robił. Po tygodniu sprawdzamy: co zostało zrobione, a co nie, jeśli nie, to dlaczego, i zastanawiamy się, co robić dalej.
Sprinty pozwalają na bieżąco korygować kurs.
Przez tydzień lub dwa próbujemy czegoś: technologii, podejść, metod pracy, a potem znów mierzysz i patrzysz – czy przy takim podejściu jest lepiej czy gorzej? Jeśli gorzej, to znaczy, że idziemy w złym kierunku, trzeba skorygować kurs: ustawić inne zadanie, wziąć inną technologię lub coś innego zrobić. Krótkie sprinty trwające 1-2 tygodnie pozwalają na manewrowanie i w porę unikać złych decyzji.
Dzielimy się sukcesem
Zespół osiąga jakieś sukcesy, małe lub duże – to nieważne, zawsze jest jakiś wynik. O tym wyniku powinni wiedzieć wszyscy: zarówno ci, którzy są zaangażowani w DevOps, jak i sąsiednie działy. W idealnym świecie pożądane byłoby, aby to dotarło do wszystkich ludzi w firmie. Po co? Jeśli chcemy przekształcić nie część firmy, usunąć nie jedno ograniczenie, ale wszystko, aby firma stała się elastyczna, a kod szybko docierał do klienta i nic się nie psuło, musimy sprawić, aby wszyscy byli lojalni wobec idei DevOps. Nie będziesz w stanie zastosować podejścia do usług i zespołów, które są kategorycznie przeciwne..
Aby pojawiła się lojalność, musimy wszystkim opowiadać, że spróbowaliśmy tego – mamy wynik, spróbujcie też! To zwiększy zainteresowanie i lojalność wobec tego, czym się zajmujemy, ludzie zaczną próbować coś robić od razu. Jak pokazuje praktyka, kiedy opowiadamy, co próbowaliśmy i co osiągnęliśmy, inne zespoły zaczynają pytać, jak i co zrobiliśmy. Patrzą na realizacje, kod, dokumentację, podchodzą z pytaniami i próbują coś zmienić u siebie.
Mówienie o tym, co się udało – jest ważne. Tak przekonasz do przejścia na wasz oboz konserwatystów, którzy chcieli wszystko robić po staremu, i przekształcisz ich w innowatorów.
Wybieramy usługę
Podsumowując
, jako punkt wyjścia – miejsce, w którym rozpoczniemy zmiany w firmie., jako punkt odniesienia — miejsce, w którym rozpoczniemy zmiany w firmie. Identifikujemy wszystkich, którzy mają jakikolwiek związek z usługą i razem z nimi budujemy mapę strumienia wartości, mierzymy i patrzymy, gdzie i jakie są ograniczenia.
Tworzymy nowy zespół tymczasowy, który zajmie się postawionym zadaniem. Na podstawie pomiarów i mapy strumienia wartości rysujemy nową mapę, na której wyróżniamy to ograniczenie, które będziemy rozwiązywać. Na podstawie tego ograniczenia ustalamy zadanie, którym będzie się zajmował zespół. Zadanie musi być koniecznie SMART — konkretne, mierzalne, odpowiednie do bieżących zadań i ograniczone czasowo.
Powtarzamy proces, aż przekształcimy wszystkie nasze usługi do wymaganej postaci i wyeliminujemy wszelkie ograniczenia.
Bonus. Przydatne materiały
Dla tych, którzy postanowili zająć się DevOps na własną rękę.
Projekt "Feniks"
Oryginalny tytuł — „The Phoenix Project: A Novel about It, Devops, and Helping Your Business Win”. To powieść o DevOps — historia o tym, jak pracownik został szefem działu, który zawsze był w ogniu. Nowemu szefowi postawiono zadanie:
— Masz kilka lat, aby wszystko naprawić, abyśmy mogli w końcu szybko i efektywnie dostarczać nasz produkt naszym klientom.
„Projekt Feniks. Powieść o tym, jak DevOps zmienia życie na lepsze” — książka dla wszystkich menedżerów, ponieważ to właśnie ci ludzie podejmują decyzje o tym, co dzieje się w firmie. Jeśli jesteś inżynierem lub programistą i chcesz, aby w twojej firmie nastąpiły zmiany i transformacja — kup tę książkę i podaruj ją kierownictwu. Ta powieść wszystko wyjaśnia, a czyta się ją szybko i łatwo.
Podręcznik DevOps
Trochę trudniejsza książka. Wydana kilka lat temu w języku angielskim pod tytułem „The DevOps Handbook How to create world‑class agility, reliability, and security in Technology organizations”, ale teraz jest już także w języku rosyjskim. To prawdziwy podręcznik — praktyczny przewodnik: jak przeprowadzać pomiary, co to jest mapa strumienia wartości i po co jest potrzebna, dokąd warto zmierzać, w jakiej kolejności. Książka jest dla tych, którzy chcą wszystko zrobić samodzielnie. Najważniejsze, że zawiera przykłady doświadczeń innych firm.
Na przykład, przedstawiono tam, jak jedna firma stworzyła mapę strumienia wartości i zrozumiała, że jej ograniczeniem nie jest produkt, a fakt, że kasjer chodzi z sklepu do sąsiedniego biura, aby skorzystać z tego produktu. Zamiast rozwiązywać problem z programem, po prostu zakupili tablety dla swoich sprzedawców, dzięki czemu nikt już nigdzie nie chodzi, a wszystkie działania wykonują w miejscu pracy. Wniosek: mapę strumienia wartości można stosować nie tylko w oprogramowaniu, ale i we wszystkich procesach w organizacji.
Przyspiesz
Pełny tytuł: „Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations”. To kolejny poziom — hardcore. Książka ukazała się w zeszłym roku, na razie tylko w języku angielskim i dotyczy badań. Autorzy — Nicole Forsgren, Jez Humble i Gene Kim — przez wiele lat stosowali różne praktyki w różnych firmach i badali, jakie praktyki, w jaki sposób i na co wpływają.
W drugim rozdziale, poświęconym pomiarom, wspomniano o mapie strumienia wartości, tych metrykach, o których mówiłem oraz wielu innych, a także szczegółowo opisano proces pomiarów. Autorzy przeprowadzają pomiary za pomocą kwestionariuszy i samodzielnego śledzenia zadań. Dokładnie opisano, które metryki należy właściwie mierzyć, a które nie, oraz błędy ludzkie w pomiarach. Jeśli masz trudności z pomiarami, zapoznaj się z drugim rozdziałem książki „Accelerate”. Jeśli twoja drużyna ma wiele praktyk, ale nie wiesz, które zastosować teraz, które później, które naprawdę działają, a które nie — przeczytaj, wszystko jest opisane w książce.
Transformacja to pytanie na styku DevOps i zarządzania. Gdzieś w tej samej przestrzeni przecięcia rozwoju, eksploatacji i testowania znajdują się tematy, które staramy się omawiać na , ta sama integracja jest potrzebna również do tworzenia jakościowego produktu – głównego tematu . Zarządzanie na festiwalu znajduje się — to znaczy, wszystkie pomysły na transformację są tam. Dołącz do nas 27 i 28 maja, będziemy integrować się i transformować.
Źródło: habr.com
