My pracujemy w SCRUM, a klient na tym korzysta

Framework SCRUM jest bardzo popularny w branży IT - wykorzystuje się go do zarządzania projektami. 

W naszej drupalowej agencji jakiś czas temu wdrożyliśmy SCRUM stanowiący podstawowe narzędzie pracy z klientem. W poniższym tekście przedstawię, w jaki sposób tego rodzaju współpraca przebiega i jakie niesie za sobą korzyści dla obu stron.

SCRUM jest łatwy w zrozumieniu, ale trudny we wdrożeniu. Pojęcia takie jak: Daily, Sprint, Retrospektywa, Sprint Review, Product Owner nie ułatwiają szybkiego startu dla osoby, która wcześniej ich nie używała. Jednak w praktyce SCRUM działa na bardzo prostej zasadzie.

Wyobraźcie sobie, że do Droptica przychodzi klient ze swoim zleceniem na wykonanie korporacyjnej strony WWW. Pierwszym etapem po poznaniu oczekiwań klienta jest zbudowanie zespołu, który będzie zajmował się tym konkretnym zadaniem.

Podstawą w SCRUM jest Sprint

Zespół w Droptica działa w dwutygodniowych cyklach pracy. Ze względu na krótki czas trwania nazywamy je Sprintami. Podczas Sprintu zespół skupia się na tym, aby zrealizować zadania postawione przed nim jako Cel Sprintu. Celem może być na przykład zaprojektowanie lub wdrożenie jakiejś funkcjonalności w portalu. Ważne jest, żeby Cel pozostawał realny do osiągnięcia w ciągu jednego Sprintu. Realizacja Celu składa się z małych zadań. Staramy się, aby pojedyncze zadania zajmowały mało czasu. W miarę możliwości duże zadania dzielimy na mniejsze, w wyniku czego mamy większą kontrolę nad zakresem, a klient szybciej może zobaczyć efekty naszej pracy. 

Dlaczego pracujemy na małych zadaniach?

Małe zadanie to takie, które członek zespołu może wykonać w kilka godzin. Dzięki temu, że realizacja takiego taska trwa krótko, widać szybki przyrost skończonej liczby zadań w trwającym Sprincie. Pozwala to klientowi na bieżąco obserwować rozwój projektu oraz daje poczucie kontroli nad wykonywanym zleceniem. To Product Owner (czyli jedna osoba reprezentująca klienta) oraz zespół ustalają Cel Sprintu na podstawie priorytetów biznesowych.

Główną zaletą SCRUM jest stopniowy, widoczny rozwój produktu. Product Owner posiada wgląd w przyrost postępów i ma kontakt z zespołem. Dzięki temu unika się problemu, jaki niesie ze sobą konkurencyjny model Waterfall, w którym dopiero po wielu miesiącach klient widzi to, nad czym pracowali deweloperzy. Efektem tego często są rozczarowanie i duży koszt, ponieważ za wykonaną pracę trzeba zapłacić.

SCRUM jest elastyczny. Dla przykładu: na początku ustalamy z Product Ownerem kolejność zadań do wykonania. Jednym z nich może być wykonanie funkcjonalności logowania i rejestracji na stronie WWW. Jeżeli jednak w trakcie trwania projektu okaże się, że ważniejsza dla Product Ownera jest strona produktu (klient chce jak najszybciej prezentować swoją ofertę), to razem z deweloperami może wyznaczyć to jako cel kolejnego Sprintu i zmienić priorytety. Product Owner i zespół działają “zwinnie”, reagują na okoliczności i rozwiązują aktualne problemy.

Proces w SCRUM skupiony jest na regularnym dostarczaniu wartościowych biznesowo funkcjonalności. Najczęściej już po kilku Sprintach klient dostrzega zaawansowany projekt i może go skonfrontować ze swoimi wstępnymi założeniami i oczekiwanym efektem. W razie redefinicji strategii biznesowej Product Owner może zmienić część pomysłu, wprowadzić korekty w liście zadań lub dodać nowe, które jako cele biznesowe nie były brane wcześniej pod uwagę i usunąć te, które nie są jeszcze ukończone albo zrezygnować z ich wykonania. Dzięki temu zespół realizuje prawdziwe cele biznesowe i nie brnie ślepo za rozbudowaną specyfikacją techniczną, jaką dostarczył klient na początku (jak to ma miejsce w modelu Waterfall).

W kontekście powyższego klient kontroluje koszty i wydatki. Może planować na co w pierwszej kolejności wydane zostaną jego pieniądze. Pracując blisko z klientem, zespół lepiej poznaje jego oczekiwania. Developerzy są na wyciągnięcie ręki Product Ownera, a dzięki takiej relacji projekt jest bardziej dopasowany do tychże oczekiwań.

Skąd się biorą zadania dla zespołu?

Zadania dla zespołu wyznacza Product Owner na podstawie celów biznesowych. Wspólnie z programistami tworzona jest ogólna lista zadań nazywana Backlogiem. Z Backlogu zadanie może zostać przeniesione do Sprintu lub może czekać na swoją kolej do realizacji. Może także zostać z Backlogu wykreślony, co oznaczać będzie rezygnację z niego.

Scrum i spotkania

W SCRUM zespół spotyka się na spotkaniach, które odbywają się w stałych terminach. Wyznaczane są zadania, które przypisuje się do konkretnych członków zespołu. Po planowaniu, przez kolejne czternaście dni, następuje ich realizacja. Zespół spotyka się codziennie rano na krótkim spotkaniu (max. 15 minut) zwanym Daily. W trakcie Daily każda osoba przedstawia odpowiedzi na konkretne pytania: co zrobiła od poprzedniego Daily?; co planuje robić do kolejnego Daily?; czy są jakieś rzeczy, które ją blokują i czy potrzebuje wsparcia od innych członków?. Meetingi uskuteczniają komunikację i współpracę wewnątrz teamu. Wszyscy są na bieżąco z tematem i pomagają sobie realizować Cel Sprintu.

Na koniec Sprintu odbywa się podsumowanie rezultatów i prezentacja efektów pracy. Sprint Review to spotkanie mające na celu prezentację przyrostu i uzyskanie feedbacku na temat efektów pracy zespołu.

Retrospektywa to meeting, podczas którego zespół dzieli się swoimi uwagami i komentuje zakończony Sprint. Członkowie mają prawo zgłosić uwagę do procesu oraz propozycję usprawnienia pracy w kolejnych Sprintach. Celem Retrospektywy jest podsumowanie dobrych praktyk i poprawienie procesów, które wymagają dopracowania w następnych Sprintach. W Droptica zależy nam, aby każdy kolejny Sprint był lepszy od poprzedniego i żeby z biegiem czasu zespół się rozwijał i lepiej wykonywał postawione przed nim zadania.

W Droptica nie ma stałych teamów. Zespół tworzony jest indywidualnie do każdego projektu. Czasami jest większy, a czasami mniejszy. To oczekiwania klienta i jego projekt determinują potrzebny charakter zespołu oraz jego skład.

W każdym spotkaniu może uczestniczyć Product Owner, ale jego obecność nie jest niezbędna na wszystkich meetingach. Na przykład w trakcie Daily nie jest ona konieczna (jest jednak pożądana). PO może posłuchać o tym, nad czym aktualnie pracuje zespół. 

Product Owner jest potrzebny w planowaniu (ustalanie Celu Sprintu) oraz podczas Sprint Review (prezentowanie efektów Sprintu), na Retrospektywie (podsumowanie Sprintu) jego udział nie jest konieczny, ale też może w nim uczestniczyć.

SCRUM jest idealnym narzędziem do budowania złożonych projektów, w których zaangażowane jest sporo osób. Dzięki swojej transparentności pozwala naszym klientom widzieć proces i jego efekty oraz daje kontrolę nad realizacją potrzeb i oczekiwań. Stanowi ponadto istotne narzędzie do oszczędzania budżetów, ponieważ klient nie wydaje pieniędzy na zbędne funkcjonalności, które nie są w danej chwili potrzebne. Mówiąc w skrócie: klient płaci za to, co jest mu realnie potrzebne. Takie podejście idealnie sprawdza się w relacji Klient-Droptica, czego efektem są zadowoleni klienci i projekty, które cały czas są rozwijane przez nasze zespoły.