Software Development

Scrum w zespołach utrzymania systemów informatycznych?

Listopad 26, 2015 0
Podziel się:

Scrum to jedno z głównych podejść do zwinnego zarządzania projektami. Powszechnie stosowany w tworzeniu oprogramowania – sprawdza się w tych zastosowaniach bardzo dobrze. Zespoły projektowe pracują w tym podejściu efektywnie, same się organizują, uczą i dostarczają produkt swojej pracy w regularnych odstępach czasu zwanych Sprintami. Zainteresowani mogą przeczytać dokument określający czym jest Scrum tutaj: http://www.scrumguides.org.

Zalety podejścia Scrum są w większości bezdyskusyjne jeśli chodzi o projekty, których celem jest wytworzenie działającego oprogramowania. Istnieją jednak organizacje, które starają się zastosować reguły Scrum także do prac, które projektami nie są – chodzi o utrzymanie środowiska i infrastruktury informatycznej. Czy przynosi oczekiwane efekty? Czy jest to w ogóle możliwe?

Zespoły odpowiedzialne za infrastrukturę mają, bardzo ogólnie ujmując, dwa zadania: rozwój systemów informatycznych zgodnie z wymaganiami biznesowymi organizacji oraz utrzymanie infrastruktury IT.

W przypadku rozwoju infrastruktury IT można śmiało mówić o projektach infrastrukturalnych – wdrożenie nowego systemu, wdrożenie zmiany w systemach istniejących, realizacja zapotrzebowania organizacji na nowe środowiska itp., do tych działań wymagane jest określenie zasobów, pracochłonności, czasem budżetu a także wpływu planowanych zmian na istniejącą infrastrukturę i systemy. Podejście Scrum pomaga w takich przypadkach usystematyzować i odpowiednio kolejkować prace zespołów infrastrukturalnych. Zgodnie z tym podejściem backlog prac wypełniany jest wymaganiami biznesowymi (lub technicznymi), ustalane są priorytety i zasoby niezbędne do realizacji działania. Do Sprintu wciągane są zadania o pracochłonności zgodnej z pojemnością zespołu, raportowany jest czas poświęcony na ich wykonanie. Długość Sprintu infrastrukturalnego można skorelować ze Sprintami pozostałych zespołów (np. deweloperskich), co pozwoli lepiej planować prace i wdrożenia produktów wytworzonych przez te zespoły.

Czy jednak Scrum nadaje się do prac utrzymaniowych, które przecież stanowią bardzo istotną część pracy zespołów infrastrukturalnych? Administratorzy dużą część swojego czasu poświęcają na analizę logów systemowych, rozwiązywanie problemów/awarii, realizację zgłoszeń (np. w ramach 3. linii wsparcia). Nie ma w tych zadaniach miejsca na planowanie i szacowanie pracochłonności. Przecież gdyby wiedzieli, że nastąpi awaria, to raczej by do niej nie dopuścili J

Jedną z podstawowych wartości Scrum jest możliwość (w miarę) dokładnego zaplanowania prac, bazując na doświadczeniu zespołu i historii poprzednich Sprintów. W przypadku prac utrzymaniowych nie da się przewidzieć ile czasu zajmie naprawa awarii, czy w ogóle takie awarie będą miały miejsce i ile ich będzie. Zespół realizujący wsparcie na poziomie 3. linii nie jest w stanie dokładnie określić ile zgłoszeń będzie musiał zrealizować i ile czasu będzie musiał na to poświęcić.

Pojemność zespołu zwykle nie ulega zmianie w trakcie Sprintu, skoro więc może się zmienić ilość czasu poświęconego na prace utrzymaniowe, to ucierpieć mogą na tym zaplanowane prace rozwojowe i realizacja potrzeb biznesowych organizacji.

Bez wątpienia wiele elementów Scrum będzie przydatnych dla zespołów infrastrukturalnych – planowanie zmian dla nadchodzącego Sprintu, wycena czasochłonności prac, raportowanie wdrożonych elementów backlogu. Zgodnie jednak z tym, co mówią jego twórcy: „[…]reguły Scruma są niezmienne i choć możliwe jest wykorzystanie tylko wybranych jego elementów, wynikiem takiego postępowania nie będzie Scrum. Skoro więc nie możemy precyzyjnie zaplanować prac zespołu, pominiemy niektóre Role, Zdarzenia czy Artefakty Scrum, praca takiego zespołu nie będzie pracą Scrumową.

Warto zastanowić się, czy inna lekka technika prac – KANBAN – nie będzie bardziej efektywna w organizacji prac zespołów odpowiedzialnych za rozwój i utrzymanie systemów informatycznych. Ale o tym może już w kolejnym artykule…

Oceń ten post
Tagi: ,
Piotr Wieczorek
Autor: Piotr Wieczorek
Architekt rozwiązań infrastrukturalnych w Praktyce IT Infrastructure. Pełni również rolę Senior Administratora Wintel w dziale Internal IT Infrastructure. Pracuje w Sii ponad 5 lat, wcześniej zajmował się administrowaniem pocztą Exchange oraz Active Directory.

Imię i nazwisko (wymagane)

Adres email (wymagane)

Temat

Treść wiadomości

Zostaw komentarz