Czy SCRUM nadaje się do projektów utrzymaniowych?

Framework Scrum jest często wykorzystywany przy wytwarzaniu systemów informatycznych. Czy można skutecznie zarządzać procesem utrzymania systemu IT wykorzystując tą metodykę. W poniższym artykule postaram się odpowiedzieć na to pytanie.

Do napisania poniższego tekstu zainspirował mnie:

• podcast „SCRUM w projektach informatycznych” https://porozmawiajmyoit.pl/poit-004-scrum-w-projektach-informatycznych/ – w końcowej części dyskusji autorzy rozmawiają o problemach związanych z pracą w metodyce SCRUM w projektach, gdzie trzeba na bieżąco obsługiwać zgłoszenia 'produkcyjne’;
• wpis na blogu #białko pt. „Czym jest DevOps” https://bialko.eu/agile/devops/, gdzie autor porównuje (niezbyt szczęśliwie moim zdaniem) metodykę DevOps ze Scrumem.
• Osobiste doświadczenia w prowadzeniu projektów utrzymaniowych połączonych z pracami rozwojowymi (co najmniej 10 projektów różnej skali).

Dla ustalenia uwagi przyjmijmy hipotetyczny scenariusz:

• wytwarzanym produktem jest system informatyczny (aplikacja webowa) – nie ma większego znaczenia, czy jest dostępna tylko dla użytkowników wewnętrznych (pracowników organizacji), czy zewnętrznych;
• proces wytwarzania produktu jest zgodny z metodyką Scrum z 2-tygodniowymi sprintami; nie ma istotnego znaczenia czy zespół developerski jest wewnątrz organizacji klienta, czy też jest on zespołem zewnętrznym (software house)
• po kilku/kilkunastu/kilkudziesięciu sprintach wytworzony produkt posiada wystarczającą ilość funkcji (MVP) aby można było go wdrożyć produkcyjnie i udostępnić użytkownikom końcowym.
• w backlog znajdują się kolejne wymagania do zrealizowania i jest na to budżet
• dostępność, stabilność i bezpieczeństwo systemu są istotnymi czynnikami dla interesariuszy.

Po 'go-live’ i okresie stabilizacji (early support) dość często uruchamia się tzw. umowę utrzymaniową, która gwarantuje odpowiedni poziom dostępności systemu informatycznego – dla uproszczenia będziemy w stosunku do całości systemu stosować również określenie usługa IT, chociaż definicja „usługi IT” w ITIL od wersji 3 jest szersza. Istotnym elementem takiej umowy jest SLA – Service Level Agreement. Opisuje ona szereg parametrów związanych z dostępnością usługi IT – m.in. gwarancję dotyczącą czasów reakcji oraz usuwania incydentów pojawiających się w środowisku produkcyjnym. Zwyczajowo parametry te mogą być opisane poprzez poniższą tabelkę:

Czasy zaprezentowane w powyższej tabeli są bardzo 'łagodne’ – dla wielu systemów działających w reżimie 24/7 wymaga się aby obejście było dostarczone w przeciągu 2-4 godzin zegarowych (także poza godzinami pracy).

Schematycznie powyższy scenariusz można by zilustrować w następujący sposób:

W tym momencie pojawia się pytanie …

Jak żyć?

Czyli w jaki sposób pogodzić rozwój produktu, realizowany w ramach wyznaczonych przez Scrum, oraz reagowanie na ewentualne incydenty/problemy, które pojawiają się na środowisku produkcyjnym i wymagają obsłużenia w deklarowanych czasach SLA.

Być może wyjaśnienia wymagają dwa użyte przeze mnie powyżej terminy: incydent i problem. Dla osób zaznajomionych z biblioteką ITIL są to pojęcie dobrze znane, ale z mojego doświadczenia wynika, że w 'zwinnym świecie’ już niekoniecznie. Definicje wg. ITIL v3 2011 (jest już wersja 4 – przypuszczam jednak, że definicje te nie uległy znacznym zmianom):

incydent – (ang. Incident) – nieplanowana przerwa w usłudze informatycznej lub obniżenie jakości usługi informatycznej;

problem – (ang. Problem) – przyczyna jednego lub wielu incydentów. Przyczyna nie zawsze jest znana w chwili rejestrowania (zapisu) problemu. Proces zarządzania problemami jest odpowiedzialny za dalsze badania i diagnozę.

Nawiązując do przedstawionej powyżej tabeli SLA można powiedzieć, że usunięcie incydentu jest dostarczeniem obejścia (workaround), natomiast rozwiązanie problemu jest 'naprawą’ systemu (Root cause). Oczywiście mogą się zdarzać sytuacje, gdy od razu będzie dostarczone rozwiązanie problemu, które rozwiąże wywołane nim incydenty.

Co na to Scrum Guide

Na początku sprawdźmy co sam Scrum Guide (SG) mówi na ten temat (wszystkie cytaty w tym artykule będą pochodzi z polskiej wersji z 2017 roku):

(…) Scrum został stworzony w celu zarządzania i wytwarzania produktów. Począwszy od wczesnych lat dziewięćdziesiątych był wykorzystywany powszechnie, na całym świecie, do:  (…)

2. tworzenia i rozbudowy produktów,  

3. wprowadzania na rynek produktów i ich rozszerzeń, nawet wielokrotnie każdego dnia, 

4. rozwijania i utrzymywania środowisk typu cloud (online, bezpiecznych, dostępnych na żądanie) oraz innych środowisk operacyjnych do zastosowań produktowych, 

5. utrzymywania i modernizacji produktów. 

W powyższym cytacie podkreśliłem te wyrażenia, które wskazują na to, że Scrum może być wykorzystywany nie tylko do procesu wytwarzania produktów, ale także ich późniejszego rozwijania i utrzymania. I z pewnością w wielu wypadkach tak jest, ponieważ Scrum opiera się na empirycznej kontroli procesu i z pewnością za powyższymi punktami z SG stoi wiele przykładów je potwierdzające („empiryzm reprezentuje pogląd, iż wiedza wynika z doświadczania i podejmowania decyzji w oparciu o to, co zostało poznane„). Spróbujmy jednak przeanalizować, w jaki sposób można zarządzić problemami i incydentami wykorzystując procesy, role i artefakty dostępne w Scrum.

P1 is comming.

Wyobraźmy sobie (wcale nieteoretyczną) sytuację, gdy w trakcje trwania sprintu do zespołu trafia informacja, że system produkcyjny jest niedostępny i został zgłoszony incydent o priorytecie P1. Pomińmy rozważania, w jaki sposób jest ona komunikowana – załóżmy, że umowa utrzymaniowa definiuje sposób przekazywania zgłoszeń tego typu za pomocą dedykowanej aplikacji, wiadomości e-mail czy sms/telefonu. Jak możemy potraktować takie zgłoszenie wykorzystując artefakty Scrum? O ile biblioteka ITIL posiada dokładnie zdefiniowane procesy (w wersji 4 zwane 'praktykami’) i role, które są wykorzystywane w takich sytuacjach, o tyle w SG nie znajdziemy takich bytów. Jedynym miejscem, w którym można by umieścić taki incydent jest Product Backlog. Formalnie należałoby tam wpisać nie samą informację o incydencie, a raczej zadanie związane z jego usunięciem (znalezieniem obejścia) oraz drugie zadanie/poprawkę, związaną z rozwiązaniem problemu, który taki incydent spowodował. Zgodnie z definicją:

Backlog Produktu jest listą wszystkich cech, funkcji, wymagań, ulepszeń i korekt, które reprezentują zmiany wprowadzane do produktu w jego przyszłych wydaniach.

Kto może dokonać takie 'dodania’ nowego elementu do PB? Jak wiemy „Właściciel Produktu jest jedyną osobą odpowiedzialną za zarządzanie Backlogiem Produktu (ang. Product Backlog). Pojęcie zarządzania Backlogiem Produktu mieści w sobie (…) jasne artykułowanie elementów Backlogu Produktu (…)”. Ponieważ PO jest zawsze jedną, konkretną osobą, założenie że wszystkie zgłoszenia typu incydent będą rejestrowane w PB przez niego jest dość niebezpieczne – szczególnie jeśli umowa SLA jest w reżimie 24/7. Na szczęście „Właściciel Produktu może wykonywać powyższe zadania samodzielnie lub zlecać je Zespołowi Deweloperskiemu (…)„. Można więc założyć, że wybrany członek Zespołu Developerskiego będzie odpowiedzialny w danym momencie za dodanie do PB zgłoszenia związanego z wystąpieniem incydentu (w szczególności np. developer pełniący dyżur).

Nowy element PB powinien zostać poddany refinementowi, żeby można było określić atrybuty takie jak „opis, kolejność, oszacowanie i wartość.” Kolejność elementu odpowiadającego zgłoszonemu incydentowi będzie zdeterminowana przez jego priorytet – w przypadku zgłoszenia typu P1 taki element powinien powędrować na samą górę PB. Z oszacowaniem czasu potrzebnego na rozwiązanie takiego incydentu może być problem – jeśli nie jest znane obejście (workaround), to zwykle trudno jest ocenić ile czasu potrzebujemy na jego znalezienie (rozwiązanie incydentu) a następnie znalezienie i usunięcie przyczyn incydentu (rozwiązanie problemu). Nie czas tu i miejsce na akademickie dyskusje, czy bug-fixy powinny być estymowane – wg. SG ulepszenia i korekty są elementami PB i co do zasady taką estymatę posiadać powinny. W sytuacjach wystąpienia incydentów typu P1, P2 zwykle nie ma to jednak większego sensu i nie ma na to czasu – gdy pali się dom nie zastanawiamy się ile czasu zajmie ugaszenie pożaru, tylko jak najszybciej się za to zabieramy. W przypadku poważnych incydentów zwykle po ich rozwiązaniu robi się analizę 'post-mortem’ i jest to dobry moment na przeanalizowanie ile czasu zajęło usunięcie awarii, oraz czy można to było zrobić lepiej/szybciej (w przypadku Scrum można by wykorzystać Sprint Retrospective to przeprowadzenia takiej dyskusji – bardzo ważnym elementem tego spotkanie jest bowiem określenie elementów, które mogą zostać usprawnione/poprawione). Osobną kwestią jest określenie ’wartości’ takiego zadania – z jednej strony można przyjąć, że usuwanie błędów/awarii nie przynosi żadnej wartości biznesowej, z drugiej strony można próbować szacować utracone korzyści w wyniku wystąpienia awarii (np. ilość niezrealizowanych transakcji w związku z niedostępnością systemu czy jego elementu).

Załóżmy, że w product backlog’u znajduje się już stosowny element związany z naprawą awarii – teraz musi się znaleźć w sprint backlogu, żeby zespół mógł się jak najszybciej zająć jego realizacją (zgodnie ze Scrum zespół developerski pracuje w trakcie trwania sprintu tylko nad zadaniami, które znajdują się w SB). Jeśli problem pojawił się w trakcie trwania sprintu, to dodanie zadania do sprint backlog’u oznacza jego modyfikację. SG w tym temacie wypowiada się następująco:

Podczas Sprintu:
– nie są wprowadzane zmiany stanowiące zagrożenie dla realizacji Celu Sprintu,

– cele jakościowe nie są obniżane,

– zakres prac, wraz ze zdobywaniem nowych informacji, może być wyjaśniany i
renegocjowany pomiędzy Właścicielem Produktu a Zespołem Deweloperskim.

—-
Jeśli pojawia się potrzeba wykonania dodatkowej pracy, Zespół Deweloperski dodaje ją do Backlogu Sprintu. (…) Jedynie Zespół Deweloperski może zmieniać swój Backlog Sprintu w trakcie Sprintu

Jak wynika z powyższego, dodanie nowego elementu do backlogu sprintu jest co prawda możliwe, ale: (a) nie powinno negatywnie wpłynąć na realizację celu sprintu oraz (b) może tego dokonać tylko Zespół Developorski (Właściciel Produktu może renegocjować zakres prac z Zespołem, ale nie może nakazać zmiany zakresu Sprintu). Te założenia są oczywiście bardzo problematyczne w przypadku awarii, których rozwiązanie może wyłączyć cały, lub większą część zespołu na dzień lub dłużej (metodyka DevOps zaleca całkowite wstrzymanie prac w sytuacjach pojawienia się krytycznych błędów na produkcji – analogicznie jak pociągnięcie linki Andon w fabrykach Toyoty zatrzymuje całą linię produkcyjną) – w takiej sytuacji prawdopodobnie nie zrealizuje się niektórych zadań przypisanych do sprintu w trakcie planowania i cel sprintu może być zagrożony. Dodatkowo zespół developerski może teoretycznie nie zgodzić się na zajęcie takim dodatkowym taskiem i Scrum Master stojący na straży przestrzegania zasad Scruma opisanych w Przewodniku powinien stanąć po ich stronie. Załóżmy jednak, że członkowie zespołu kierując się wartościami Scruma takimi jak zaangażowanie, odwaga, skupienie, otwartość i szacunek, i rozumiejąc powagę sytuacji podejmą decyzję o włączeniu dodatkowego zadania do Sprintu i natychmiast zajmą się jego realizacją. Co jednak w sytuacji, gdy obsługujemy SLA w reżimie 24/7, a awaria zdarzy się w nocy lub w weekend i większość zespołu developerskiego jest niedostępna? Na to pytanie SG niestety nie udzieli odpowiedzi – ale już np. ITIL posiada procesy związane z poważnymi incydentami (major incidents) i wskazuje ścieżki eskalacji w takich sytuacjach.

Do 'obsługi’ awarii typu P1 z wykorzystaniem procesu opisanego w SG można by podejść jeszcze w następujący sposób – skoro aktualnie cały system, nad którego rozwojem pracujemy, nie działa (lub nie jest dostępna jakaś jego kluczowa funkcja), to cel sprintu na ten moment przestaje być aktualny. Można wtedy myśleć o przerwaniu sprintu:

Sprint może zostać przerwany przed upływem ograniczenia czasowego. Tylko Właściciel Produktu ma prawo przerwać Sprint, jednak może podjąć taką decyzję pod wpływem opinii interesariuszy, Zespołu Deweloperskiego lub Scrum Mastera.
Sprint może zostać przerwany, jeśli Cel Sprintu się zdezaktualizuje. (…). Ogólnie rzecz ujmując Sprint powinien zostać przerwany, jeśli kontynuowanie prac nie ma sensu w zaistniałych okolicznościach.

Trzeba jednak pamiętać, że

przerwania Sprintów są zwykle traumatyczne dla Zespołu Scrumowego i zachodzą bardzo rzadko

Dlatego takie rozwiązanie miałoby moim zdaniem sens jedynie w przypadku bardzo poważnych awarii, które powodują niedostępność całego systemu a czas ich usunięcia może być trudny do oszacowania (np. awaria centrum danych i konieczność zastosowania disaster recovery).

Daily Scrum

Formalnie codzienny Scrum powinien służyć do „oceny postępów pracy nad realizacją Celu Sprintu”:

Może ono (spotkanie Daily Scrum) być przeprowadzane na wiele sposobów, jeśli tylko pozostaje poświęcone postępom prac w kierunku osiągnięcia Celu Sprintu. (…) Oto przykład pytań, które mogą być wykorzystywane podczas tego spotkania:
– Co zrobiłem wczoraj, co pomogło Zespołowi Deweloperskiemu przybliżyć się do osiągnięcia Celu Sprintu?
– Co zrobię dzisiaj, co pomoże Zespołowi Deweloperskiemu przybliżyć się do osiągnięcia Celu Sprintu?
– Czy widzę jakiekolwiek przeszkody mogące uniemożliwić mi lub Zespołowi Deweloperskiemu osiągnięcie Celu Sprintu?

W sytuacji 'pożarowej’ omawianie postępów prac w kierunku osiągnięcia Celu Sprintu wydaje się mało sensowne – wszyscy powinni być raczej skupieni na tym, jak najszybciej przywrócić działanie systemu. Poza tym z taką dyskusją zwykle nie ma co czekać do najbliższego Daily (np. jeśli tak awaria wystąpi np zaraz po spotkaniu). Często istnieje też potrzeba częstszego (niż raz dziennie) synchronizowania swoich działań oraz przygotowania informacji o postępach w przywracaniu usługi (w przypadku jednej z umów utrzymaniowych miałem obowiązek przesyłania raportu do klienta co godzinę, do momentu usunięcia awarii typu P1). W związku z tym codzienny Scrum w obliczu poważnych incydentów staje się spotkaniem mało przydatnym, które trzeba zastąpić serią krótkich spotkań mających na celu ustalenie statusu prac i zsynchronizowania działań członków zespołu. Metodyka DevOps zaleca tzw. 'swarming’ w sytuacji gdy wystąpią problemy, co wiąże się z zaprzestaniem innych prac (wspomniane wcześniej pociągnięcie za linkę Andon), oraz zaangażowanie natychmiast wszystkich osób, które są w stanie pomóc w rozwiązaniu problemu (The DevOps Handbook – “SWARM AND SOLVE PROBLEMS TO BUILD NEW KNOWLEDGE”)

Podsumowanie

Jak widać, można teoretycznie próbować obsłużyć 'incydenty’ i 'problemy’ z wykorzystaniem zdarzeń, artefaktów i ról zdefiniowanych w Scrum, ale jest to rozwiązanie generujące wiele potencjalnych problemów – w szczególności w przypadku umów gwarantujących obsługę systemu w trybie 24/7. Scrum Guid nie daje nam bezpośrednich wskazówek jak obsługiwać incydenty i problemy – tak jak np. biblioteka ITIL gdzie znajdujemy dedykowane, dobrze opisane procesy/praktyki w tym obszarze.

Jeśli więc chcielibyśmy nadal prowadzić prace rozwojowe z wykorzystaniem ram postępowania opisanych w SG, to konieczne byłoby zbudowanie podejścia hybrydowego, w którym zasady SCRUMa musiałby w sytuacjach wystąpienia awarii ustępować dobrze przemyślanym i opisanym procesom utrzymaniowym (opartych np. na wskazaniach ITIL).

Oczywiście można zastosować kilka 'obejść’, które mogą uczynić wykorzystanie Scrum w projektach utrzymaniowo-rozwojowych znośniejszym w implementacji oraz codziennym wykorzystaniu – ale i tym może w kolejnym artykule.