Jak pogodzić rozwój i utrzymanie systemu IT

W poprzednim artykule starałem się wykazać, że zastosowanie frameworka SCRUM ‚by the book’ do projektów, które łączą rozwój oprogramowania z jego utrzymaniem (obwarowanym wymogami umowy SLA), jest zadaniem nieco karkołomnym. Jak więc podejść do tego typu sytuacji? W tym i następnych wpisach chciałbym omówić kilka możliwych rozwiązań oraz wskazać na ich mocne i słabe strony.

Dedykowane zespoły

Takie rozwiązanie może przyjść na myśl, jeśli weźmiemy pod uwagę różną charakterystykę pracy osób zajmujących się rozwojem systemu (kodowaniem nowych funkcji) oraz tych zajmujących się usuwaniem awarii. Wydzielony zespół zajmuje się wyłącznie rozwojem systemu, pracując w typowym modelu Scrumowym, współpracując z Product Ownerem.
Jeśli pojawiają się błędy na środowisku produkcyjnym, inny dedykowany zespół ma za zadanie naprawienie tych błędów w reżimie czasowym określonym w umowie SLA. Brzmi nieźle? Niestety – w moim odczuciu takie rozwiązanie może prowadzić do kilku problemów.

Demotywacja zespołu maintenance – Wydzielenie zespołu osób zajmujących się tylko ‚łataniem’ błędów może wpłynąć na nich demotywująco – szukanie i poprawianie błędów w cudzym kodzie nie należy do ulubionych zajęć developerów. Dodatkowo często osoby pracujące w takim zespole/projekcie narzekają na brak rozwoju i ciekawych wyzwań, monotonną pracę, legacy code itd. Osoby takie mogą być bardziej skłonne do zmiany firmy w której pracują.

Gorsza jakość kodu – Dodatkowo – programiści, którzy zajmują się rozwojem aplikacji mogą w mniejszym stopniu dbać o jakość pisanego kodu i niezawodność tworzonych rozwiązań – „Przecież nie ja to będę utrzymywał”, „Jeśli w kodzie będą błędy, do ktoś je poprawi”.

Nierównomierne obciążenie pracą – problemem może być też to, że zespół odpowiedzialny za utrzymanie systemu będzie nierównomiernie obciążony pracą – być może będą okresy, gdzie nie będzie miał wiele zgłoszeń i awarii do usunięcia (np. po większym release), oraz takie gdzie pracy będzie zdecydowanie mniej.

Rotowany zespół maintenance

Pewnym rozwiązaniem problemów opisanych powyżej może być rotowanie osób, które w danym tygodniu/sprincie zajmują się utrzymaniem systemu, o potem wracają do prac rozwojowych. Takie podejście moim zdaniem też nie jest do końca szczęśliwe, ponieważ nadal tylko część zespołu jest w danym momencie odpowiedzialna za ‚gaszenie pożarów’ jeśli się pojawią – z drugiej strony może się zdarzyć okres, w którym zgłoszeń będzie bardzo mało, albo wcale.

Rotowany zespół zajmujący się utrzymaniem aplikacji może prowadzić do jeszcze jednego problemu – załóżmy, że z 8 osobowego zespołu developerskiego jedna lub dwie osoby w danym tygodniu/sprincie odpowiadają za usuwanie awarii – jest spora szansa, że będą rozwiązywały problem, który pojawił się we fragmencie kodu pisanym przez innego członka zespołu. W rezultacie spędzi nad usunięciem bug-a więcej czasu niż autor danej metody/klasy/modułu, albo poprosi o pomoc kolegę, który lepiej zna ten kod, przez co odciągnie go od realizowania bieżących zadań w sprincie, co może się przyczynić do nieosiągnięcia celu sprintu, lub nie zrealizowania wszystkich zadań zaplanowanych na dany sprint.

I na koniec jeszcze jeden ‚problem’, który może się pojawić w modelu z ‚rotowanym zespołem maintenance’. W przypadku pojawienia się awarii typu P1, które wymagają (zgodnie z ustalonym SLA) podjęcia jak najszybciej działań mających na celu przywrócenia działania systemu, może pojawić się podejście, że jest to problem wyłącznie osób, które zajmują się w danym okresie wsparciem. Pozostali członkowie zespołu developerskiego, którzy w danym momencie nie są odpowiedzialni za utrzymanie systemu mogą nie czuć ‚potrzeby’ wsparcia kolegów walczących z pożarem w projekcie. Dlatego też metodyka DevOps zaleca tzw. swarming (od swarm – rój) w sytuacjach awarii krytycznych – na wzór pociągnięcia za linkę Andon w fabrykach Toyoty.

“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.”

Excerpt From: Gene Kim, Patrick Debois, John Willis, Jez Humble, John Allspaw. “DevOps. Światowej klasy zwinność, niezawodność i bezpieczeństwo w Twojej organizacji”.

Swarming pozwala na opanowanie problemów, zanim zdążą się rozprzestrzenić, oraz zdiagnozowanie i naprawienie złej sytuacji, tak by nie mogła się powtórzyć. Dzięki temu 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ę.

Podsumowując – moim zdaniem dedykowany (lub rotowany) zespół maintenance to zdecydowanie zły pomysł – może wydawać się atrakcyjny z ‚zarządczego’ punktu widzenia, ale docelowo może przynieść więcej problemów niż pożytku.
W kolejnym artykule rozważę inną możlwość.

Uwaga – w tym wpisie odnoszę się jedynie do pomysłu wydzielenia zespołu developerskiego dedykowanego do naprawy błędów powodujących incydenty (awarie) na środowisko produkcyjnym. Oczywiście w wielu sytuacjach i organizacjach celowe będzie utworzenie tzw. pierwszej linii wsparcia, która będzie zajmowała się udzielaniem pomocy w typowych problemach zgłaszanych przez użytkownika oraz próbowała rozwiązywać incydenty zgodnie z dostarczonymi wskazówkami.

5 1 vote
Article Rating
Subscribe
Powiadom o
guest
1 Komentarz
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
trackback
9 dni temu

[…] poprzednim artykule odniosłem się do pomysłu wydzielania dedykowanego zespołu w celu obsługi zgłoszeń […]