Każdy, kto jeszcze kilka lat temu wdrażał w swojej firmie oprogramowanie realizowane na zamówienie z pewnością pamięta ile czasu zajmował proces jego tworzenia: pisania specyfikacji, budowania systemu i testowania gotowego programu.
Testy, choć wg harmonogramu wskazują, że prace zmierzają ku końcowi ciągnęły się w nieskończoność, bo pracownicy zgłaszali kolejne uwagi i nowe pomysły a programiści wdrażali kolejne poprawki.
W najgorszej sytuacji znajdował się Klient, który po długich miesiącach uczestniczenia w projektowaniu, na zakończenie otrzymywał produkt, który nijak mu nie leży i jest daleki od tego co sobie wyobrażał. I nawet trudno jednoznacznie określić dlaczego tak się stało, bo wszystkie wymagania zostały uwzględnione, odbyły się dziesiątki spotkań z programistami, a zachwytu brak.
Aby do takich sytuacji nie dopuszczać, firmy IT zajmujące się projektowaniem rozwiązań na zamówienie zaczęły wykorzystywać SCRUM.
Pracując wg. SCRUM dzieli się proces powstawania produktu na mniejsze etapy, trwające miesiąc iteracje czyli cykle, zwane sprintami. Po każdym sprincie zespół projektowy jest w stanie zaprezentować działający prototyp oprogramowania, a więc Klient nie otrzymuje programu do testowania na etapie końcowym, tylko już na początku projektu.
Jak to wygląda w praktyce przedstawia Bartosz Błądek – kierownik projektu, który wg SCRUM realizuje rozbudowę systemu CRM dla jednego z Klientów z branży produkcyjnej.
Pierwszym etapem prac jest spotkanie z Klientem i ustalenie potrzeb, celu projektu oraz harmonogramu działań. Powstaje wstępna, dokumentacja zawierająca najważniejsze funkcje programu. Rozpoczyna się budowa prototypu systemu, którą już po miesiącu klient otrzymuje do testowania.
W drugim etapie. Klient po zapoznaniu się z prototypem, jego wyglądem graficznym i funkcjami zgłasza swoje uwagi. Zespół projektowy rozwija i uszczegóławia dokumentację, programista nanosi zmiany do prototypu oprogramowania. Podobnie wygląda etap trzeci. Dodatkowo na tym etapie prototyp może być już używany do realnych działań w firmie.Etap czwarty to przekształcenie prototypu w działającą wersję oprogramowania i testy końcowe.
Według Bartosza Błądka główną zaletą stosowania w pracy SCRUM jest elastyczne podejście do projektu.
Bartosz Błądek zwraca uwagę, że w bardzo wielu projektach ostateczny wygląd systemu znacząco różni się od pierwotnych założeń i w trakcie prac mocno ewoluuje. Pisanie szczegółowych wytycznych, które mogą okazać się nie zadowalające dla Klienta i wymagające dodatkowego czasu na ich zmianę lub rozpoczęcie prac od nowa to duża strata czasu. Pracując wg SCRUM prace rozpoczyna się bazując tylko na głównych założeniach.
Wielu Klientów na pierwszym etapie prac potrafi tylko ogólnie powiedzieć czego oczekuje od programu, ale nie wie jak ma wyglądać proces działania, jaki interfejs będzie czytelny, czy dana funkcja sprawdzi się w systemie. Dzięki SCRUM już po miesiącu może zobaczyć na własne oczy system i zwizualizować swoje oczekiwania testując prototyp, a tym samym upewnić się czy zaproponowane rozwiązania mu pasują. To pozwala na zmiany elementów oprogramowania na bieżąco bez ryzyka destabilizacji całego systemu.
Takie rozwiązanie jest też bardzo opłacalne finansowo dla Klienta, bo oszczędzając czas programistów mniej płaci za otrzymany produkt a otrzymuje dużo bardziej dopasowany system do swoich potrzeb niż przy zastosowaniu klasycznej metody projektowej.