W artykule „DevOps – Trzy drogi” opisałem podstawowe zasady jakimi kieruje się DevOps w strumieniu wartości technologii. Teraz chciałbym bliżej przyjrzeć się na czym polega pierwsza droga i w jaki sposób może pomóc w zarządzaniu usługami IT. Pierwsza droga obejmuje zasady przepływu pracy w strumieniu wartości technologii, czyli np wytwarzaniu oprogramowania. Co jest w niej najważniejsze?

Spraw aby praca była widoczna

Pracę można zobaczyć w fabryce, gdzie mamy materiały do produkcji, maszyny i linie produkcyjne oraz pracowników obsługujących te maszyny lub przemieszczających się po zakładzie. Jak jednak to zrobić w przypadku wytwarzania oprogramowania komputerowego? Z pomocą przychodzi bardzo ciekawy wynalazek, tablica kanban. Jest to sposób aby na tablicy zwizualizować pracę, jaka jest wykonywana w zespole. W kolumnach mamy poszczególne etapy, kroki pracy do wykonania. W poziomie możemy mieć np. osoby, które dana pracę wykonują. Bardzo prosto możemy zrobić tablicę kanban rysując ją na dużym arkuszu papieru lub tablicy ścieralnej i naklejając karteczki post-it w odpowiednich kolumnach, jako reprezentację zadań, kart pracy. Na tablicy kanban praca wpływa z lewej strony i jest przekazywana w prawą stronę, pomiędzy kolejnymi etapami pracy. Praca kończy się z prawej strony, która reprezentuje produkcyjne działanie, wykonaną pracę. Takie podejście pozwala na zarządzanie pracą i mierzenie czasu jej wykonania na poszczególnych etapach. Takie obrazowanie pracy pozwala lepiej określać priorytety dla zadań oczekujących w kolejce i w ten sposób zwiększać przepustowość systemu.

Ograniczenie pracy w toku

Kolejna zasada przepływu, pokazuje nam, że powinniśmy ograniczać pracę w toku, czyli tą która jest aktualnie wykonywana. Czy to ma sens? Mamy robić wszystko aby pracy było mniej? Brzmi trochę podejrzanie ale wcale takie nie jest. DevOps wskazuje, że wielozadaniowość jest nieefektywna i proponuje jej ograniczanie, tak aby koncentrować jest na wykonaniu jednego zadania. Do tego wykorzystywana jest oczywiście tablica kanban. Określamy limity pracy w toku (Work In Progress – WIP), dla każdej kolumny lub etapu/ośrodka pracy poprzez ograniczenie liczby kart, które mogą występować w jednej kolumnie. Żadna praca nie może być wykonana, dopóki nie stworzy się jej reprezentacji w postaci karty pracy. Takie podejście nie zmniejsza ale zwiększa efektywność pracy i powoduje, że jest jej wykonywane więcej a nie mniej.

Zmniejszenie wielkości partii

Aby przepływ pracy był jak najbardziej optymalny, musimy zastosować kolejną zasadę, czyli wykonywać pracę w małych partiach. Takie postępowanie prowadzi do skrócenia czasu realizacji pracy oraz zwiększa jej jakość. Przy małych partiach pracy, wcześniej możemy wykryć błędy i je skorygować, tym samym poprawiając jakość pracy. W ten sposób zmniejszamy też współczynnik pracy w toku, który jest kluczowy dla DevOps. Oczywiście jeżeli mamy mniejsze partie pracy to jest ona wykonywana szybciej i czas realizacji jest krótszy. Dodatkowo jesteśmy w stanie szybciej wykrywać błędy i wprowadzać działania naprawcze. Oznacza to także, mniejszą liczbę koniecznych zmian.

Zmniejszenie liczby przełączeń

Aby przepływ pracy był jak najkrótszy, konieczne jest zautomatyzowanie jak największej ilości pracy, aby mogła być wykonywana bez oczekiwania w kolejkach. To kolejna zasada przepływu, którą musimy zastosować. Aby z niej skorzystać musimy zmienić organizację zespołów, tak aby mogły dostarczać wartość bezpośrednio do klienta. W ten sposób skracamy czas jaki praca musi czekać w kolejce i nie przynosi wartości dodanej.

Stałe identyfikowanie i eliminowanie ograniczeń

Jeżeli chcemy aby nasz praca była efektywna, musimy stale identyfikować i eliminować ograniczenia systemu naszej pracy. Najczęściej występujące ograniczenia w wytwarzaniu oprogramowania to:

• Tworzenie środowiska. Kto nie spotkał się z sytuacją, że nie można wdrożyć oprogramowania bo nie ma środowiska do testów funkcjonalnych lub wydajnościowych lub brakuje zasobów do środowiska produkcyjnego? Dążymy do środowisk na żądanie i pełnej automatyzacji ich tworzenia.
• Instalacja kodu. Jeżeli instalacja oprogramowania składa się z wielu kroków i wymaga kilku specjalistów to nie może trwać krótko. Dlatego pracujemy nad pełną automatyzacją instalacji oprogramowania.
• Konfiguracja i uruchamianie testów. Wykonywanie testów ręcznie, przygotowywanie danych testowych, planowanie zasobów ludzkich do testów, to wszystko powoduje, że testy trwają tygodniami. Lekarstwem jest jak w poprzednich punktach zautomatyzowanie testów.
• Zbyt ścisła architektura. Jeżeli architektura nie pozwala wprowadzać zmian bez angażowania procesu zarządzania zmianą i CAB, to jest to ograniczenie. Dążymy do wprowadzania zmian bezpiecznie i z większą autonomią.

Eliminowanie trudności i odpadów w strumieniu wartości

Ta zasada przepływu mówi, że powinniśmy dążyć do zmniejszenia trudności i uciążliwości codziennej pracy przez ciągłe uczenie się w celu osiągnięcia stawianych celów. Przykładowe kategorie trudności i odpadów to:

• Prace wykonane częściowo
• Dodatkowe procesy
• Dodatkowe funkcjonalności
• Oczekiwanie
• Defekty
• Prace niestandardowe i ręczne

Podsumowanie

Opisałem najważniejsze zasady przepływu, będące pierwszą drogą. Praca musi być widoczna, aby można było nią lepiej zarządzać. Należy zmniejszać pracę, która jest aktualnie wykonywana oraz dzielić pracę na małe partie i części. Zmniejszamy liczbę przekazywania pracy z etapu do etapu i z zespołu do zespołu. Ciągle identyfikujemy i eliminujemy ograniczenia systemu pracy. Stale eliminujemy trudności i problemy w strumieniu wartości technologii. Ich zastosowanie i przestrzeganie pozwoli na jak najkrótszy przepływ pracy.

Na podstawie książki „DevOps – Światowej klasy zwinność, niezawodność i bezpieczeństwo w twojej organizacji”.

Artykuł DevOps – Pierwsza droga – Zasady przepływu pochodzi z serwisu Mariusz Siek.

Świat się zmienia. Zarządzanie usługami IT też. To co dziesięć lat temu wydawało się dobre i skuteczne dzisiaj stało się trochę skostniałe i mało elastyczne. Nie znaczy, że całkowicie jest niepotrzebne ale wymaga odświeżenia i dostosowania do istniejących warunków. Tak dzieje się np z ITIL, który w tym roku wprowadza czwartą wersję swojej biblioteki. Zanim jednak Axelos odkryje wszystkie karty postanowiłem bliżej przyjrzeć się DevOps. W tym celu nabyłem książkę „DevOps – Światowej klasy zwinność, niezawodność i bezpieczeństwo w twojej organizacji”. Autorami są Gene Kim, Jez Humble, Patrick Debois i John Willis. Zacząłem ją zgłębiać i chciałbym się podzielić podstawową wiedzą o trzech drogach w DevOps.

Trzy drogi

Jako fundamentalne zasady DevOps wprowadza pojęcie trzech dróg:

• Pierwsza droga – Zasady przepływu pracy
• Druga droga – Zasady sprzężenia zwrotnego
• Trzecia droga – Zasady ciągłego uczenia się i eksperymentowania

Pierwsza droga – Zasady przepływu pracy

Pierwsza droga mówi o zasadach związanych z przepływem pracy od jej rozpoczęcia do zakończenia. W przypadku strumienia wartości technologii, czyli działu wytwarzania oprogramowania, początkiem przepływu pracy jest zdefiniowanie wymagań biznesowych a końcem wdrożenie oprogramowania zawierającego funkcjonalności dotyczące tych wymagań na produkcję. Proces ten obejmuje przejście od developmentu do operacji (utrzymania). Jakoś nie lubię terminu operacje, bo źle mi się kojarzy i wolę używać „utrzymanie”. Według mnie lepiej odzwierciedla funkcje tej aktywności.

Zasady z pierwszej drogi koncentrują się na zwiększeniu przepływu pracy, tak aby czas od rozpoczęcia do zakończenia pracy był jak najkrótszy. Najważniejsze elementy to:

• Zwiększenie widoczności praca, które najlepiej wykonać poprzez tablicę kanban, umieszczoną w miejscu pracy zespołu
• Zmniejszenie rozmiaru partii, sprowadza się do dzielenia pracy, na jak najmniejsze, niezależne zadania
• Zmniejszenie interwału pracy, poprzez skracanie okresów wydań oprogramowania z miesięcy do tygodni, dni i godzin.
• Tworzenie jakości poprzez przeciwdziałanie przekazywania defektów, pomiędzy poszczególnymi etapami wytwarzania oprogramowania. Jednym słowem usuwanie błędów jak tylko się pojawią.
• Stałe optymalizowanie pracy, poprzez dążenie do ciągłego zwiększania efektywności i usuwania wąskich gardeł

Druga droga – Zasady sprzężenie zwrotnego

Druga droga skupia się na szybkim i stałym przepływie informacji zwrotnych. Najważniejsze jest aby wszystkie informacje, które mogą przyczynić się do skutecznego usuwania problemów były przekazywane na bieżąco z zespołu operacji (utrzymania) do zespołu developerskiego. Celem takiego działania jest:

• Zapobieganie występowaniu podobnych problemów w przyszłości
• Zwiększenie efektywności procesów wykrywania problemów i eliminowania ich skutków.

Budujemy w ten sposób mechanizmy pracy, które mogą rozwiązywać problemy na wczesnym etapie i zapobiegać ich katastrofalnym skutkom.

Trzecia droga – Zasady ciągłego uczenia się i eksperymentowania

Trzecia droga koncentruje się na:

• Dynamicznym, zdyscyplinowanym i naukowym podejściu do eksperymentowania i podejmowania ryzyka
• Czerpaniu nauki z sukcesów jak i porażek
• Ciągłym skracaniu i wzmacnianiu pętli sprzężenia zwrotnego

Poszukujemy takich usprawnień w naszym codziennym działaniu, które będzie można zastosować globalnie i przyczynią się do poprawy działania innych osób w zespole.

Podsumowanie

Trzy drogi to dopiero początek mojej drogi w DevOps. Podane zasady wyglądają na proste i zrozumiałe. Pozostaje tylko zastosować je w praktyce i zweryfikować jak się sprawdzają. Do zobaczenia na dalszej drodze w odkrywaniu tajników DevOps.

Artykuł DevOps – Trzy drogi pochodzi z serwisu Mariusz Siek.