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.