Maintenance w agile [agilestarter]

Kiedy rozwijamy produkt stosując agile, developerzy (programiści, testerzy, UXy) dzielą sią na zespoły. Zespoły te mają wiedzę, jak budować oczekiwane funkcjonalności i jak je dostarczać do końcowych użytkowników. Aby nowo powstałe zespoły były prawdziwie zwinne, nie powinny one czekać z dostarczaniem wymagań (poszczególnych funkcjonalności), aż cały nowy / udoskonalony produkt powstanie. Aby zrealizować to założenie, musimy być świadomi, że oddawanie po “kawałku” nowych funkcjonalności będzie powodowało “spływanie” do zespołu zgłoszeń już od momentu pierwszego wdrożenia. Użytkownicy zaczną używać produktu, a żaden produkt nie jest na początku doskonały. Powstaną zgłoszenia, czyli tzw. maintenance (utrzymanie).

Jak wspomniałem na wstępie, dostarczanie końcowym użytkownikom nowych / zmienionych wymagań będzie skutkowało pojawianiem się zgłoszeń. Zgłoszenia te także mogą powstawać “od strony” zespołu, kiedy on sam zaobserwuje, że coś nie działa. Czasami może to być dług techniczny, ale o tym pisałem w osobnym artykule.

Sposoby obsługi zgłoszeń (użytkowników, ale też “wewnętrznych” od zespołu) mogą być najróżniejsze, ale nimi zajmę się w dalszej części artykułu. Na początek chciał bym poruszyć temat ich krytyczności, czyli kiedy zespół uznaje, że problem jest poważny albo nie.

 

Klasyfikacja zgłoszeń

Nie ma większego znaczenia, wg jakiej metodologii pracuje zespół. Może on używać Scruma, Kanbana, albo podejścia hybrydowego. Najważniejsze jest to, aby cały zespół był świadomy reguł, które rządzą ustaleniem typu i krytyczności zgłoszenia.

Podstawowe typy zgłoszeń wymieniłem poniżej:

  • Bug (pol. błąd)- nasz produktu nie działa i użytkownicy nie mogą z niego korzystać (z części funkcjonalności albo z całego produktu). Błędy występujące w systemie powinniśmy dalej podzielić i przypisać im odpowiednią krytyczność:
    • critical (pol. błąd krytyczny),
    • high (major, pol. błąd istotny),
    • medium (minor, pol. błąd)
    • low (trivial, pol. błąd “błahy”).

Celowo nie podaję rozwinięcia krytyczności błędów, ponieważ to od zespołu i produktu zależy, czym dana krytyczność jest. Błąd krytyczny oznacza dla Was zaprzestanie działania całego produktu, czy tylko jego części? A może jako zespół określiliście ścieżkę krytyczna i niedostępność funkcjonalności na niej oznacza błąd krytyczny? Jak wielu użytkowników musi błąd “dotknąć”, abyście uznali go za high? A może to zgłaszający określa krytyczność? Wg jakich kryteriów?

To tylko niektóre z pytań, które zespół jest zobowiązany przed sobą postawić zanim określi krytyczność błędu. Potrzebne są zasady, które “rządzą” krytycznością.

Wikipedia.org określa ‘severity’ i ‘priority’. Zachęcam Was do zapoznania się z tymi definicjami.

Wracając do naszej klasyfikacji mamy jeszcze:

  • Maintenance (pol. Utrzymanie)- zadanie związane z utrzymaniem systemu. Założenie nowego użytkownika, dodanie nowego parametru, itd,
  • New feature (pol. nowa/ zmiana funkcjonalności)- coś, co w systemie powinno być, ale nie jest. Często jest tak, że ktoś rejestrujący zgłoszenie na podstawie może komunikatu od użytkownika, stwierdza, że aby wykonać dane działanie, potrzebna jest rozbudowa istniejącej już funkcjonalności. Ale uwaga! Jak wielu użytkowników korzysta z obecnej możliwości, jak wiele mamy zgłoszeń, że czegoś brakuje? Product Owner w Scrumie, tudzież inna osoba(y) w Kanbanie, powinny określić, dopytać o te informacje, aby poprawnie ustalić priorytet tego zgłoszenia (jako ‘New feature’ jest ono częścią Product Backlogu, w którym wszystkie elementy są ‘poddawane’ takiej analizie).

Możecie spotkać się również z pojęciem ‘Zero Bug Policy’. Generalnie chodzi o zasadę, która mówi, że jako zespół nie tolerujemy na naszym produkcie żadnych błędów i każdy takowy ma wyższy priorytet niż nowe funkcjonalności.

Pamiętajcie jednak, że to od szeroko rozumianego zespołu zależy, jak z danym zgłoszeniem (typem i krytycznością) zamierza dalej “walczyć”. Osobiście zorganizowałbym warszaty, aby wypracować reguły postępowania, spisałbym je i powiesił w widocznym miejscu. I sprawdził w następnym sprincie (okresie), czy wypracowane reguły się sprawdzają.

I jeszcze jedno mi się nasuwa pisząc o klasyfikacji zgłoszeń. Każde zgłoszenie dotyczące utrzymania jest docelowo w Product Backlogu (PBL). PBL jest jedynym miejscem, gdzie są trzymane wszystkie kwestie dotyczące produktu, więc jest też naturalne, że zawiera on zadania związane z utrzymaniem (i błędami). Czasami oczywiście się zdarzy, że zanim zespół/ Product Owner umieści dane zgłoszenie w PBL to już zostanie ono ‘zrobione’. W takim przypadku oczywiście nie ma sensu tego zlecenia wpisywać/ przeklejać post factum. Zespół może zrobić sobie dużą krzywdę tworząc zupełnie oddzielną listę zadań utrzymaniowych, których nie widać, tworzących szarą strefę, nie priorytetyzowanych względem innych zadań w PBL, a czasem nawet nie są zarządzanych przez Product Ownera.

 

Sposoby na obsługę utrzymania

Jako zespół developerski po zdefiniowaniu krytyczności zastanówmy się, jak obsłużyć pojawiające się zgłoszenia.

Wiele zespołów zastanawia się, jaką opcję wybrać. Jest to trudny wybór, ponieważ w momencie pierwszego wyboru trudno ocenić, czy dana opcja będzie pasowała czy też nie. Poniżej znajdziecie kilka przykładowych rozwiązań, jednak na pwno nie wyczerpują one listy możliwych opcji.

Możliwe, przykładowe warianty to:

  • wyznaczony dyżurny na sprint / określony czas

W tej opcji wiele zależy od nastawienia i chęci obsługi tego typu zgłoszeń przez deweloperów. Developerzy mogą niechętnie być dyżurnymi, gdyż jest to źle postrzegane, nudne, itd. Pomóc w tym wariancie może zasada kolejki, która w sprawiedliwy i powtarzalny sposób zapewnia, że dyżurnym jest każdy członek zespołu raz na jakiś czas i obciążenie tym obowiązkiem jest rozłożone na cały zespół.

  • plusy
    • plusem wyznaczenia dyżurnego jest to, że wszyscy pozostali członkowie zespołu mogą się w całości skupić na realizacji celu sprintu,
    • wyznaczona osoba na czas sprintu może nie wiedzieć, czym aktualnie się zespół zajmuje. Ale przez fakt, że jest to rola rotacyjna, przerwa w pracy nad rozwojem funkcjonalności trwa tylko długość iteracji. Innymi słowy praktycznie cały czas następuje wymiana wiedzy w zespole i każdy członek zespołu wie, nad czym aktualnie zespół pracuje,
  • minusy
    • brak naprawienia danego problemu w iteracji wymaga dodatkowych uzgodnień- czy nadal się tym zajmuje “dyżurny” z konsekwencjami obciążenia sprintu zadaniami nierozwojowymi, czy też zadanie przechodzi na nową osobę z konsekwencjami możliwego braku u niej wiedzy o przyczynie problemu,
  • osobny zespół

Opcja dotyczy powołania nowego, dedykowanego zespołu, który zajmuje się tylko zgłoszeniami związanymi z utrzymaniem.

  • plusy
    • zawsze wiadomo do kogo się zwrócić,
    • osoby chcące pracować przy tego typu zadaniach mogą się realizować,
  • minusy
    • kwestia motywacji- jak zmotywować taki zespół?
    • kwestia postrzegania- zespół zajmujący się utrzymaniem zawsze będzie gorzej postrzegany niż zespół zajmujący się rozwojem,
    • brak wiedzy o zmianach w produkcie- po pewnym czasie od powstania takiego zespołu wiedza w nim zawarta będzie się co raz bardziej różniła od wiedzy zespołu “rozwojowego”,
  • pozostawione capacity w sprincie na maintenance

Na planningu nie planujemy zadań ‘pod korek’, wykorzystując wszystkie możliwości ale zespół zostawia sobie trochę przestrzeni pod spodziewane zgłoszenia dotyczące utrzymania, które się pojawią w momencie gdy sprint już będzie biegł. Pojemność niezaplanowana jest specyficzna dla danego zespołu i produktu i bazuje na historycznym doświadczeniu, ile takich zleceń można się spodziewać.

  • plusy
    • jest jeden zespół, co skutkuje znajomością bieżących zadań i w przeciwieństwie do poprzedniej opcji, zespół może w sposób ciągły szerzyć między sobą wiedzę o produkcie,
    • zespół zawsze ma możliwość “przerobienia” utrzymaniówki,
  • minusy
    • nie pojawiają się zgłoszenia, nie wykorzystujemy w pełni potencjału zespołu chyba, że zespół może dobierać sobie zadania z PBL,
    • Product Owner nie priorytetyzuje maintenace’u, jeżeli jest go mało i cały na bieżąco mieści się w buforze,
    • jest tylko określona ilość godzin/ dni na zgłoszenia dotyczące utrzymania. Jeżeli pojawi się w międzyczasie zgłoszenie o wysokim priorytecie i Product Owner postanowi, że zespół musi je zrealizować od razu, “wejdzie” ono na zadania rozwojowe wywłaszczając ludzi je robiących,
  • bufor na utrzymanie

Jeff Sutherland proponował podobnego typu podejście j.w. ale bardziej surowe. Utrzymanie (maintenance) jest zapisywany w Product Backlogu i może być dokładany do Sprint Backlogu przez PO pod warunkiem, że założony bufor się nie wyczerpał. Gdy bufor w danym sprincie się wyczerpał, PO decyduje, czy nowo pojawiający się maintenance jest bardziej krytyczny niż cel sprintu (i wtedy przerywa sprint, informuje całą firmę, że to, co się pojawiło jako zgłoszenie, jest pilniejsze i bardziej krytyczne niż realizacja założonego celu) a jeśli nie jest bardziej krytyczny – czeka na kolejny sprint jako element PBL.

  • plusy
    • każde krytyczne zgłoszenie (albo takie, jakie uzna PO za krytyczne) powoduje, że jest ono realizowane,
    • następuje na bieżąco priorytetyzacja zgłoszeń,
  • minusy
    • przerywamy sprint co zawsze źle się odbija na zespole i interesariuszach,

 

Podsumowanie

Pamiętajcie, że sposób obsługi utrzymania zależy od zespołu. Rozmawiajmy o tym na retrospektywie, sprawdźmy, czy nasza metoda obecna na radzenie sobie z utrzymaniem się sprawdza (jak szybko trwa realizacja tych zadań, jak wartościowe jest to, co realizujemy, jak zadowoleni są członkowie zespołu, jak zadowoleni są interesariusze). Próbujmy eksperymentów z podejściem, np, zmiana sposobu zarządzania przez jeden sprint.

PS. Są zespoły, których praca nad zadaniami utrzymaniowymi stanowi większość czasu. Zadania te często stanowią z jednej strony walkę długiem technicznym, z drugiej strony są to zadania związane z parametryzacja systemów, zarządzaniem użytkownikami, itp. Może w takim przypadku bardziej zasadne jest użycie Kanban Methods niż Scrum?

PS2. Warto też się zastanowić, jakie zlecenia do zespołu trafiają, skąd, czego dotyczą. Nadmieniam to ponieważ od czasu do czasu warto robić przegląd całej kolejki ze zgłoszeniami, kategoryzować je i zastanowić się, czy aby nie da się tego usprawnić. Przykładowo, jeżeli ciągle dostajemy zlecenia dotyczące parametryzacji systemu czy nie warto zarejestrować nowego zadania w backlogu zespołu i zautomatyzować ten proces albo dać odpowiednie narzędzie użytkownikom systemu?

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

*

Ta strona używa Cookies. Korzystając ze strony wyrażasz zgodę na używanie ciasteczek zgodnie z aktualnymi ustawieniami przeglądarki.
Akceptuję, bo lubię Was czytać.
x