Scrum pozwala osiągnąć bardzo wiele korzyści biznesowych w tym artykule skupię się tylko na dwóch z wielu aspektów. Jakość oraz Satysfakcja Klienta – są to dwie pierwsze najbardziej miarodajne efekty po wprowadzeniu Scruma.
Definition of „Done” – Definicja „Ukończenia”
Jest to zbiór wymagań niezbędnych do osiągnięcia, aby zadanie uznać za wykonane. Zespół Deweloperski podczas prac musi zapewnić tą samą jakość dla każdego realizowanego zadania. Przykładowa lista wymagań to np.:
- część programistyczna powinna posiadać testy,
- nie powinien powstać dług technologiczny
- testy użytkownika powinny zostać wykonane
- wygląd graficzny zapewniać czytelność zgodną wymaganiami WCAG.
Takie parametry wyznaczają oczekiwaną jakość zadania jakie jest w stanie zrealizować Team Development w trakcie jednego Sprintu. Dzięki doświadczeniu empiryzmu zespół w kolejnych sprintach jest w stanie precyzyjnie określić jakie zadania będzie w stanie zrealizować. Wymagania te dotyczą każdego realizowanego zadania, proste jak i złożone funkcjonalności powinny je spełniać – dzięki temu poziom jakości w ujęciu całego projektu jest równomierny i nie powstaje dług technologiczny.
Z biznesowego punktu widzenia oznacza to przewidywalność efektów pracy oraz pewność, że rozwój oprogramowania nie zatrzyma się w przyszłości z powodu długu technologicznego. Tutaj muszę zaznaczyć, że Scrum nie skupia się na redukcji długu technologicznego, lecz na ciągłym rozwoju produktu – oznacza to, że dług technologiczny może powstać, zwłaszcza w tak dynamicznym środowisku jak tworzenie oprogramowania.
Przewidywalne produkcyjne wydanie
Dzięki definicji „Ukończenia” zadania, można dokładnie przewidzieć, kiedy funkcjonalności zostaną ukończone – to pozwala Product Owner planować regularne publikacje Przyrostu. Bardzo często w „zwinnym” tworzeniu oprogramowania zadania są „prawie gotowe” przez co nigdy nie wiadomo czy produkcyjna wersja będzie działać poprawnie. W przypadku działania zgodnie z frameworkiem Scrum – taka sytuacja jest przejrzysta i jasna dla wszystkich.
Z punktu widzenia biznesowego to bardzo duża wartość, Klienci uwielbiają śledzić postęp projektu, ale z drugiej strony nienawidzą być testerami. Zazwyczaj wolą poczekać na podgląd funkcjonalności troszkę dłużej, aby tylko działał zgodnie z oczekiwaniami.
Feedback, dostosowanie
Dzięki częstym wydaniom, możemy otrzymywać na bieżąco informacje zwrotne od klienta. To pozwala na zmianę i dostosowania kolejnych wydań zgodnie z aktualnymi oczekiwaniami. Taki efekt współpracy powoduje większe zadowolenie klienta z otrzymanego produktu -> osiągamy tutaj sytuacje Win<>Win. W przypadku skomplikowanych procesów takich jak tworzenie oprogramowania ważne jest, aby końcowe wydanie spełniało wszystkie niezbędne aktualne oczekiwania klienta.
Często podczas planowania klient prezentuje swoje potrzeby, lecz wraz z upływem czasu – potrzeby się zmieniają – software house który nie dostosuje pierwotnych założeń do bieżących wymagań – nie utrzyma się długo na rynku.
Podsumowanie
Przykłady opisane w artykule są ściśle powiązane z trzema filarami Scrum:
- Przejrzystość, poprzez Definition od Done
- Inspekcja, poprzez wydania i kontakt z klientem
- Adaptacja, jako zmiany w trakcie realizacji projektu
Powyższy proces jest związany z empiryczną kontrolą procesu jaki proponuje Scrum. Iteracyjne i przyrostowe podejście jest najlepsze podczas tworzenia procesu oprogramowania, a pamiętajmy, że Scrum nie ogranicza się tylko do procesów programistycznych.