Ach ten serwis... zawsze problematyczny, zawsze nieprzewidziany, zawsze niepokojący. Każda firma wytwarzająca oprogramowanie musi je również utrzymywać. Jest to bardzo trudny etap w cyklu życia produktu i przysparza wielu problemów i kosztów. A co na to SCRUM? Czy można zastosować tą metodykę do poukładania maintenance'u, do jego zorganizowania? W jaki sposób uwzględnić serwis w scrumowym procesie wytwarzania?
Znów, wszystko zależy od organizacji firmy, od tego jak na wysokim poziomie abstrakcji firma ma poukładaną odpowiedzialność za poszczególne etapy procesu produkcji oprogramowania. Modele są różne. Możemy spotkać firmy, w których jeden zespół/dział analizuje, projektuje, programuje itd aż do serwisuje, a są też firmy, również klasyczne, które mają dedykowane zespoły/działy odpowiedzialne za każdy etap produkcji.
Często stosuje się też dwu- lub trzyliniowy front serwisowy. Pierwsza linia wsparcia to najmniej doświadczeni specjaliści, którzy odbierają zgłoszenia od użytkowników, ale rzadko kiedy potrafią je rozwiązać, więc przekazują je do drugiej linii. Ten poziom to albo stały zespół całkiem niezłych specjalistów, albo zespół dyżurujących programistów. Trzeci poziom to programiści, którzy wytwarzają oprogramowanie, do którego zgłoszono błąd. Przy takiej organizacji naszemu klasycznego SCRUMowi jest łatwiej, gdyż na 3cią linię wpada tych zgłoszeń niewiele, przy założeniu, że wcześniejsze linie wsparcia są dość kompetentne.
Gorzej niestety temat wygląda tam gdzie zespół scrumowy zajmuje się całym lub większością serwisu. SCRUM nie jest na to gotowy, a dlaczego? Gdyż SCRUM nie jest metodyką przeznaczoną do organizacji maintenence'u softu. SCRUM możemy zastosować tam, gdzie możemy zaplanować pracę, gdzie ta praca jest przewidywalna, gdzie mamy zdefiniowane cele na przyszłość. Serwis takim celem nie jest, gdyż, tak jak napisałem na początku, jest nieprzewidywalny.
No dobrze... ale jak żyć? Najpewniej sposobów radzenia sobie w takiej sytuacji jest wiele. Jako Scrum Master wyszedłem serwisowi naprzeciw i jeszcze raz zadałem pytanie o przewidywalność serwisu. Odpowiedź była wciąż ta sama - serwis jest nieprzewidywalny. Ale... jego wielkość... JEST przewidywalna. Korzystając z archiwów serwisowych możemy w bardzo prosty sposób stwierdzić ile czasu cały nasz zespół i jego konkretni członkowie poświęcali w przeszłości na serwis.
Dla przykładu, w jednym z zespołów weryfikowałem ile czasu każdy ze specjalistów poświęcił na serwis w każdym z ostatnich 3 miesięcy. Wyliczałem średnią. Korelowałem ją z nadchodzącym miesiącem (np czy nie jest to miesiąc, w którym standardowo, z jakiegoś powodu, użytkownik zgłasza więcej problemów) i miałem współczynnik, przez który mnożyłem czas dostępny na nadchodzący sprint. To tyle, nic więcej nie potrzebowałem. W wyniku takiej analizy otrzymywałem czas, który mogliśmy zaplanować danemu specjaliście w danym sprincie. Możliwym również jest stosowanie bardziej interesujących metod analizy serwisu, np trend czy algorytmy predykcji.
Jak zastosowanie tej metody wpłynęło na mój zespół? Bardzo dobrze - dzięki niej zyskaliśmy przybliżoną wiedzę o dostępnej mocy przerobowej każdego specjalisty - wcześniej było to niemożliwe, gdyż podczas planowania zostawialiśmy bliżej nieokreślony bufor na serwis, co często skutkowało nierealizowaniem zaplanowanych zadań LUB 'pustymi' godzinami roboczymi, które przecież można byłoby zapełnić innymi zadaniami z Product Backlogu.
Serwisu nie można się bać. Serwis trzeba analizować w każdy możliwy sposób. Podobnie jak stosowany w zespole SCRUM. Nigdy nie jest tak, że usprawnienia, które wprowadziliście będą działały zawsze - idea zwinności odnosi się nie tylko do podmiotu, który organizuje SCRUM, ale również do samego procesu stosowania tej metodyki.
