
W poprzednim artykule odniosłem się do pomysłu wydzielania dedykowanego zespołu w celu obsługi zgłoszeń serwisowych i poprawiania błędów na środowisku produkcyjnym. W tym chciałbym omówić inne podejście – wydzielenie czasu w trakcie sprintu na zadania związane z utrzymaniem i wsparcia systemu informatycznego
Innym podejściem, które może pomóc pogodzić rozwój systemu realizowanego w oparciu o framework Scrum z jego utrzymaniem i reagowaniem na incydenty związane z funkcjonowaniem środowiska produkcyjnego, jest wydzielenie czasu dedykowanego na wsparcie i utrzymanie systemu IT. Idea jest stosunkowo prosta – podczas planowania sprintu (Sprint planning meeting) pozostawiamy pewien margines czasu na rozwiązywanie zgłaszanych awarii (incydentów oraz problemów, które je spowodowały). Jeśli pojawi się incydent, który będzie wymagał natychmiastowego rozwiązania i zaangażowanie członków zespołu developerskiego w te prace, będziemy mieli w backlogu sprintu 'placeholder’ umożliwiający nam włączenie takich prac bezpośrednio do bieżącego sprintu. Innymi słowy dodajemy zadanie związane z rozwiązaniem problemu do sprintu backlogu, zanim jeszcze wystąpi 🙂
Dzięki temu unikamy problemu związanego ze zwiększeniem zakresu aktualnego sprintu, albo usuwaniem z niego zadań, które zostały tam umieszczone w trakcie planowania. Nie musimy też 'negocjować’ z zespołem dodania takiego zadania. O problemach związanych z obsługą krytycznych incydentów przy jednoczesnym trzymaniu się wytycznych Scrum 'by the book’ opisałem w tym artykule.
Oczywiście takie podejście rodzi inne problemy i pytania:
– ile czasu zarezerwować w każdym sprincie na utrzymanie systemu
– co zrobić, jeśli zarezerwowanego czasu będzie za mało na naprawienie wszystkich błędów pojawiających się na środowisku produkcyjnym w trakcie sprintu
– jak wykorzystać zarezerwowany czas w przypadku, gdy błędów i zgłoszeń serwisowych będzie mniej niż szacowaliśmy
Spróbujmy odpowiedzieć na te pytania.
Ile czasu na maintenance?
Być może w odpowiedzeniu na powyższe pytanie pomocne będą statystki prowadzone w projekcie, które pokażą ile historycznie czasu było poświęcane na prace związane z usuwaniem awarii na przestrzeni ostatnich miesięcy. Jeśli takie dane posiadamy to możemy je wykorzystać, uśredniając oczywiście wyniki. Taka informacja jest też bardzo pomocna w określeniu 'kondycji’ utrzymywanego systemu. Jeśli zespół developerski, który rozwija i utrzymuje kod aplikacji poświęca więcej niż 20% na 'gaszenie pożarów’ warto się zastanowić, czy dług technologiczny w projekcie nie jest na tyle duży, że dalsze rozwijanie tego systemu w tym stanie nie ma sensu.
Temat długu technicznego jest dość obszerny i nie będę go rozwijał w tym artykule. Generalnie dług techniczny może być zaciągany w sposób świadomy, bądź nieświadomy, ale prędzej czy później trzeba go spłacić. Im później zajmujemy się 'spłacaniem' takiego długu tym większe 'odsetki' przyjdzie nam zapłacić. Jeśli jednak nie zajmiemy się tym w odpowiednim czasie, to może się okazać, że rozwój systemu będzie praktycznie niemożliwy - będzie on wymagał głębokiego refaktoringu, albo w skrajnych przypadkach napisania od nowa.
Jeśli nie posiadamy danych historycznych (albo system jest dopiero niedawno uruchomiony produkcyjnie, albo wcześniej nie prowadziliśmy stosownego zbierania danych o czasie pracy poświęconej na naprawianie błędów produkcyjnych, to warto zastosować się do sugestii płynącej z metodyki DevOps, aby na maintenance systemu poświęcać od 20 do 25% czasu pracy zespołu developerskiego. Jeśli więc zespół ma określone w story point velocity, warto wypełniać sprintu zadaniami na ok 75 – 80% pojemości. Można też do każdego sprintu dodać zadanie, które nazwiemy 'prace utrzymaniowe’ i będzie wyceniony na 20% capacity zespołu.

Gene Kim, Patrick Debois, John Willis, Jez Humble, John Allspaw
W sytuacji gdy w trakcie trwania sprintu pojawią się zgłoszenia serwisowe wymagające zaangażowania czlonków zespołu developerskiego, nie będzie dylematu 'co wyrzucić ze sprintu’ – zadanie dotyczące usuwania awarii będzie już w sprincie uwzględnione.
A co jeśli prace serwisowe nie wystąpią w czasie sprintu?
Generalnie – trzeba się tylko cieszyć 🙂 Na pewno znajdzie się wiele prac utrzymaniowych, które można zrealizować w każdym sprincie w ramach czasu zaalokowanego na usuwanie potencjalnych incydentów. Musisz pamiętać, że usługi utrzymania i wsparcia (maintenance and support), to nie tylko reaktywne działania w przypadku zaistniałych problemów, ale też (a może przede wszystkim) monitoring oraz działania proaktywne mające na celu utrzymanie systemu w jak najlepszej kondycji.
Z pewnością w każdym projekcie tworzy się lista zadań, które powinny być zrobione, ale nigdy nie było na nie czasu – trzeba zaktualizować biblioteki wykorzystywane w projekcie, zrefaktorować fragmentu kodu, sprawdzić podatności systemu, przejrzeć logi systemowe, sprawdzić czy infrastruktura jest wystarczająca przy obecnej ilości użytkowników (a może jest przeskalowana i płacimy za nią za dużo) itd. Zadania tego typu ze względu na niski priorytet z punktu widzenia Właściciela Produktu lądują gdzieś na dnie backlogu – zawsze nowe wymagania kreowane przez użytkowników systemu są ważniejsze, bo ich wdrożenie przynosi widoczną wartość biznesową. Takie podejście mści się prędzej czy później – system, o który nie dba się odpowiednio, szybko 'odwdzięczy się’ problemami, które będą spędzały sen z powiek zarówno Product Ownera jak i zespołu developerskiego.
A jeśli awarii będzie więcej?
Jeśli prace związane z usuwaniem awarii zajmą więcej czasu niż planowane 20% być może rozsądne będzie zakończenie sprintu i zajęcie się usuwaniem przyczyn incydentów. We wcześniejszym artykule wspominałem o 'swarmingu’ – w sytuacji gdy pojawia się awaria systemu cały zespół przerywa swoje zadania i zajmuje się próbą usunięcia incydentu i zdiagnozowania jego przyczyn. Tak opisano tą metodę w książce DevOps Handbook:
“Gdy pojawią się problemy, trzeba zastosować technikę zwaną swarmingiem (od ang. swarm — „rój”), polegającą na zmobilizowaniu wszystkich osób, które są potrzebne do zażegnania kryzysu.
Według dr. Speara celem swarmingu jest opanowanie problemów, zanim zdążą się rozprzestrzenić, oraz zdiagnozowanie i naprawienie złej sytuacji, tak by nie mogła się powtórzyć. Mówi, że „tak budowana jest coraz głębsza wiedza na temat sposobu zarządzania systemami w celu realizacji naszych zadań. Następuje konwersja nieuniknionej początkowej niewiedzy w wiedzę”.
Wzorcem stosowania tej zasady jest mechanizm linki Andon montowanej w fabrykach firmy Toyota. W każdym centrum produkcyjnym jest linka, za którą może pociągnąć każdy pracownik i menedżer, gdy coś idzie nie tak, jak powinno — na przykład kiedy jakaś część jest wadliwa, kiedy potrzebne części są niedostępne lub nawet wtedy, gdy praca trwa dłużej, niż zostało to udokumentowane[2].
Gdy ktoś pociągnie za linkę Andon, powiadamiany jest lider odpowiedzialnego zespołu i natychmiast rozpoczyna pracę w celu rozwiązania problemu. Jeśli problemu nie można rozwiązać w określonym czasie (np. w ciągu 55 sekund), następuje zatrzymanie całej linii produkcyjnej. Dzięki temu można zmobilizować wszystkich pracowników do udziału w rozwiązywaniu problemu do czasu zastosowania skutecznego środka zaradczego.”
Gene Kim, Patrick Debois, John Willis, Jez Humble, John Allspaw. “DevOps. Światowej klasy zwinność, niezawodność i bezpieczeństwo w Twojej organizacji”.
Jeśli więc reagowanie na awarie zbyt często zakłóca pracę zespołu developerskiego, może jest to sygnał, że cel sprint polegający np. na dostarczenia jakiejś nowej funkcji w systemie jest na ten moment nieaktualny, ponieważ najważniejsza na obecną chwilę jest stabilność aplikacji i jej dostępność dla użytkowników końcowych. Jest to zresztą zgodne z następującym zaleceniem Scrum Guide:
Ogólnie rzecz ujmując Sprint powinien zostać przerwany, jeśli kontynuowanie prac nie ma sensu w zaistniałych okolicznościach.
The Scrum Guide – Sprint.
Podsumowując: w mojej opinii wydzielenie w każdym sprincie bufora wielkości ok 20% 'pojemności’ zespołu na prace utrzymaniowe oraz naprawę ew. błędów produkcyjnych jest podejściem o wiele rozsądniejszym niż wydzielenie dedykowanego zespołu (na stałe bądź na zasadzie rotacji), który ma zajmować się tymi zadaniami.
Uwaga: celowo w artykule odnoszę się tylko do błędów na środowisku produkcyjnym, które prowadzą do powstania incydentów (całkowitej lub częściowej niedostępności usługi IT, bądź jej nieprawidłowego działania). Błędy, które pojawiają się w trakcie developmentu powinny być naprawiana w ramach tego procesu.