Pentacomp przedstawia listę 6 słabości tradycyjnych modeli współpracy klientów 

i dostawców IT w zakresie wytwarzania oprogramowania. Jako alternatywę wskazuje jedną ze zwinnych (agile) metod: Scrum, która pozwala znacznie ograniczać ryzyko wprowadzania nowych produktów, szybciej przynosi oczekiwane korzyści biznesowe i zmniejsza budżety projektów.

Pentacomp wylicza słabości tradycyjnych metod wytwarzania rozwiązań IT

Spółka informatyczna Pentacomp, która od kilku lat z powodzeniem wdraża metodę Scrum w ramach swojego procesu wytwórczego opracowała listę sześciu, największych w jej ocenie, słabości tradycyjnych metod realizacji projektów IT – w szczególności powszechnie znanego i stosowanego modelu kaskadowego (ang. waterfall model), który opiera się na występujących kolejno po sobie etapach: analizy wymagań, szczegółowego projektowania, implementacji, testowania i wdrażania oraz na kontraktach zamkniętych próbujących definiować na początku „ostateczny” kształt realizowanego rozwiązania. Zdaniem Bartłomieja Klingera, Dyrektora ds. Produkcji w Pentacompie, stosowane przez lata podejście kaskadowe nie gwarantuje klientom uzyskania elastycznych rozwiązań, gotowych do szybkiego wprowadzenia na rynek, adekwatnych do rzeczywistych potrzeb biznesowych. Bardzo często się zdarza, że wymagana funkcjonalność określona na etapie żmudnych analiz później, w trakcie implementacji lub wręcz na etapie testów akceptacyjnych, diametralnie się zmienia. Dopiero realne zetknięcie się klienta z produktem (działającym systemem) pozwala ocenić jego dopasowanie do danych warunków i wymagań biznesowych. Niestety, w przypadku modelu kaskadowego zmiany w projekcie są trudne do przeprowadzenia zwłaszcza gdy zostaną zidentyfikowane na etapie testów akceptacyjnych – niosą ryzyko dodatkowych kosztów klienta, straty cennego czasu, i nierzadko powtórki wszystkich etapów projektu.

Lista słabości modelu kaskadowego opracowana przez Pentacomp:

1. Ryzyko uzyskania nieadekwatnego rozwiązania – model kaskadowy skazuje klienta na długi czas oczekiwania na efekt końcowy. Bardzo dużo czasu pochłaniają analizy przedwdrożeniowe i szczegółowe projekty, a ich wynik jest widoczny wyłącznie „na papierze”. Z punktu widzenia klienta, analizy to bardzo istotny koszt, który długo się zwraca – klient płaci za doradztwo, często nie widząc żadnego realnego rezultatu poza dokumentami. Skomplikowane i złożone projekty to dla organizacji wielka odpowiedzialność, tymczasem w podejściu kaskadowym im bardziej złożone projekty, tym mocniej rośnie ryzyko związane z rezultatem końcowym. Nierzadko klient łudzi się, że wymuszając szczegółowe analizy i specyfikacje dostanie w rezultacie to czego potrzebuje, podczas gdy na koniec sam dochodzi do przekonania, że jego pierwotna koncepcja nie przystaje do aktualnych realiów biznesowych. W skomplikowanych projektach etap realizacji bardzo się wydłuża. W okresie tym mogą ulec zmianie wymagania funkcjonalne. Zatem nawet jeśli dostawca w pełni wywiąże się z kontraktu, okazuje się, że klient, po długim wdrożeniu potrzebuje już innego rozwiązania. Przy zastosowaniu Scrum takie ryzyko praktycznie nie istnieje. Obie strony wiedzą, że w okresie współpracy mogą wypracować rozwiązanie, którego nie można było przewidzieć na początku projektu. Przy tym zwinnym podejściu coś takiego jak ostateczna definicja finalnej wersji produktu na początku projektu nie istnieje.

2. Opóźniony rezultat – celem IT bardziej niż kiedykolwiek wcześniej jest dziś wspieranie biznesu w jego codziennych działaniach i szybkie reagowanie na dynamiczne zmiany w otoczeniu biznesowym. W modelu kaskadowym na rezultat projektu czeka się długo, ponieważ określa go pełna, finalna wersja produktu. Kaskadowy proces realizacyjny już na początku wikła wielu ekspertów ze strony biznesu, uczestniczących w analizach, podczas gdy rozwiązanie realnego, nierzadko palącego problemu biznesowego najczęściej dostępne jest za późno i zwrot z takiej inwestycji nie jest zadowalający. Scrum daje biznesowi szanse uzyskania wsparcia dużo szybciej. Każda iteracja dostarcza działające rozwiązanie dopasowane do aktualnych potrzeb biznesowych, potencjalnie gotowe do wdrożenia produkcyjnego.

3. Bardzo mała elastyczność podczas projektu – biznes ulega ciągłym zmianom, co w oczywisty sposób pociąga za sobą zmiany oczekiwań dotyczących funkcjonalności zamawianego oprogramowania. Model kaskadowy kontraktuje projekt na etapie analiz (lub nawet wcześniej), po czym obu stronom trudno jest bez ryzyka wnosić istotne zmiany do zaplanowanych prac. Z uwagi na wiążący kontrakt zarówno wykonawcy jak i zamawiającemu częściej zależy na wykonaniu jego sztywnych zapisów, niż wspólnym wypracowaniu rozwiązania, dopasowanego do zmieniających się warunków biznesowych. W ten sposób nierzadko powstają rozwiązania nieużyteczne, nie doczekujące się wdrożeń produkcyjnych. Scrum umożliwia uniknięcie takiej sytuacji, bowiem strony koncentrują się na tym, czego potrzeba biznesowi klienta „tu i teraz”, a wszelkie zmiany są naturalnym elementem procesu realizacyjnego – w ten sposób powstają wartościowe rozwiązania.

4. Potencjalnie większe koszty – w projektach IT liczy się nie tylko zwrot z inwestycji (ROI), ale też czas, w jakim poniesione inwestycje zaczynają się zwracać. Biznes jest dziś tak dynamiczny, że dużą korzyścią jest dla niego względnie szybki dostęp do dostatecznie dobrych rozwiązań. W podejściu kaskadowym czas oczekiwania na finalny produkt jest bardzo długi, podczas gdy w Scrum klient może bardzo szybko korzystać z jeszcze niepełnych, ale gotowych do wdrożenia rozwiązań, które są doskonalone i dostosowywane w kolejnych iteracjach. Mówiąc wprost, dzięki zastosowaniu Scrum klient szybciej uzyskuje minimalną wymaganą funkcjonalność za mniejsze pieniądze, podczas gdy w podejściu tradycyjnym nacisk jest położony na poszukiwanie rozwiązań optymalnych jeszcze w fazie przedprodukcyjnej, za to za większe pieniądze.

5. Duże ryzyko złych relacji – model kaskadowy z założenia dzieli obie strony kontraktu na dwa obozy: dostawcy i odbiorcy rozwiązania. Po obu stronach pracują zespoły odnoszące się do długoterminowego kontraktu. Sytuacja sprzyja temu, by formalizmy i sztywne zapisy wynikające z umowy brały górę nad zdrowym rozsądkiem. Prawdziwa potrzeba biznesowa i głos użytkowników, którym najbardziej zależy na rozwiązaniu, często schodzą na dalszy plan. Sytuacja niesie ryzyko dla obu stron, które wiąże się z niedoszacowaniem lub przeinwestowaniem projektu, a także narastaniem konfliktów interpersonalnych. W Scrum dzięki przejrzystości, kolejne sprinty ukierunkowują obie strony na współpracę i tworzenie wartościowych rozwiązań – nie zaś na trzymanie się kurczowo zapisów specyfikacji wymagań stanowiącej zazwyczaj w modelu kaskadowym element kontraktu.

6. Marnotrawstwo czasu i pieniędzy przez biurokrację – praca oparta na częstych iteracjach i powtarzalnym procesie (sprintach) pozwala bardzo szybko identyfikować niedoskonałości specyfikacji i luki w pierwotnej koncepcji. Strony mogą szybko zorientować się, że na etapie przygotowawczym np. nie wzięto pod uwagę istotnych komponentów lub interfejsów. W modelu wodospadowym wnoszenie zmian wiąże się najczęściej z pisaniem aneksów i renegocjowaniem kontraktu. Strony, zamiast dążyć wspólnie do wypracowania wartościowego i użytecznego rozwiązania problem biznesowego, grzęzną w biurokracji, nie mówiąc już o sporach przeniesionych na grunt sądowy,. W Scrum wszystkie niedopatrzenia można natychmiast uwzględnić na każdym etapie realizacji projektu, bez konieczności uruchamiania niewygodnej dla obu stron, i często burzącej relacje biznesowe, procedury obsługi zmian (Change Requests). Jeśli podejście służy projektowi, a tak jest w przypadku Scrum, dostawca i odbiorca elastycznie dopasowują się do siebie niezależnie od tego, jak dalece zmieniają się oczekiwania i potrzeby biznesowe.

Scrum polega na wspólnym widzeniu celu, jakim jest rozwiązanie konkretnego problemu biznesowego. Jest to często dalekie odejście od sztywnej interpretacji zapisów kontraktowej specyfikacji wymagań, które same w sobie narzucają zespołom projektowym ograniczenia realizacyjne (techniczne) niezależnie od problemu jaki jest rzeczywiście do rozwiązania. Zaletą Scrum jest przejrzystość i wysoka elastyczność projektu. Obie strony mają większą kontrolę nad przebiegiem prac i rzeczywistym kształtem rozwiązania. Punktem odniesienia jest cel, którego realizację ma zapewnić wypracowywany produkt. Dodatkowym benefitem jest zbudowanie dobrej relacji biznesowej między zamawiającym a dostawcą, opartej na zaufaniu i przejrzystości, przynoszącej korzyści obu stronom.

Czym jest Scrum

Scrum to metoda organizacji procesu wytwórczego oraz współpracy dostawcy rozwiązania informatycznego z jego odbiorcą. Scrum szczególną wagę przykłada do dostarczanej wartości biznesowej z oprogramowania, a wyzwala energię i potencjał zespołów realizacyjnych, dzięki czemu minimalizuje ryzyko projektu.

Scrum definiuje ramy organizacyjne (ang. framework), w ramach których projekty są dzielone na względnie krótkie etapy (iteracje) zwane sprintami. W trakcie sprintów samoorganizujący się zespół realizuje kolejne obszary funkcjonalne – przyrosty docelowego rozwiązania. Sprinty nie powinny trwać dłużej niż jeden miesiąc kalendarzowy, przy czym w trakcie projektu mają one stałą długość. Podstawowe założenie Scrum: każdy sprint ma przynieść klientowi produkt (półprodukt), który zawiera realne funkcjonalności gotowe do wdrożenia produkcyjnego. Metoda koncentruje się zatem nie na dążeniu szerokim frontem prac do osiągnięcia celu ostatecznego, jakim jest finalne, rozbudowane rozwiązanie, lecz na jak najszybszym zaspokojeniu biznesowych oczekiwań klienta. W Scrum liczy się realna wartość biznesowa, która dostarczana jest w jak najkrótszym czasie. Kierunek rozwoju danego rozwiązania dostosowywany jest na bieżąco w oparciu o fakty znane na danym etapie rozwoju – stosowane jest podejście empiryczne.

W Scrum sprinty poprzedza etap przygotowawczy, podczas którego Właściciel Produktu (ang. Product Owner) tworzy uporządkowaną listę wszystkiego, co może być potrzebne w danym rozwiązaniu, w tym wymagań konkretnych użytkowników. W ten sposób powstaje tzw. Rejestr Produktu, który pozwala Właścicielowi Produktu nadać odpowiednie priorytety poszczególnym elementom rozwiązania, a zespołowi developerskiemu daje pewność że realizują to, co rzeczywiście jest potrzebne klientowi. W procesie wytwarzania rozwiązań obie strony mogą więc koncentrować się na wymaganiach biznesowych. Dzięki temu cele, jakie klient stawia przed dostawcą oprogramowania, można realizować znacznie szybciej niż w przypadku tradycyjnych metod, które najczęściej nie stosowały tak krótkich jak Scrum iteracji.

Po etapie przygotowawczym zespół developerski realizuje kolejne przyrosty rozwiązania, przy czym po każdym sprincie następuje przegląd, aktualizacja (w tym uzupełnienie!) i często zmiana priorytetów w Rejestrze Produktu. Takie podejście umożliwia klientowi zgłaszanie zmian na każdym etapie realizacji bez konieczności stosowania sformalizowanych procedur zarządzania zmianami (ang. Change Requests Management), ale wymaga ścisłej współpracy wytwórcy i zamawiającego opartej na przejrzystości i zaufaniu oraz poszanowaniu interesów obu stron.

Warto podkreślić, że w zakresie organizacji procesu wytwórczego bezcenną praktyką Scrum jest odbywanie codziennych, krótkich spotkań synchronizujących pracę zespołu (ang. Daily Scrum), w trakcie których każdy developer wypunktowuje zadania zrealizowane przez siebie poprzedniego dnia i problemy jakie napotkał podczas realizacji. Określa też, które zadania będzie wykonywał do czasu kolejnego spotkania.

Bartłomiej Klinger, Dyrektor ds. Produkcji i Serwisu
Pentacomp Systemy Informatyczne S.A.
www.pentacomp.pl