Wyobraź sobie, że długie miesiące, a może i lata tworzysz produkt, który w efekcie trafia jednak do kosza. Poczucie straconego czasu, pretensje do członków zespołu, frustracja i niezadowolenie to tylko niektóre z uczuć, które przychodzą na myśl w tej sytuacji. A gdyby tak tworzyć produkt etapami i na bieżąco weryfikować czy obrany przez nas kierunek działania jest właściwy? Popełniać błędy i nie stracić całej pracy, komunikować się bez żadnych barier i jasno określać cele? Przedstawiamy 8 powodów, dlaczego warto tworzyć produkt w metodyce Scrum i nie zmarnować potencjału, dzięki któremu osiągniesz sukces w swojej branży.

 

1. Jasno określone role w teamie

W Zespole Scrumowym są 3 jasno określone role. Product Owner to osoba, która ma pełną wiedzę o produkcie, wie, jaki cel ma zostać osiągnięty i ponieważ ma wizje, co ma być produktem końcowym, umie odpowiedzieć na pytania zespołu oraz odbiera wszystkie prace developerskie i ustala priorytety. Zespół Developerski to wszyscy specjaliści, którzy tworzą produkt końcowy – od designerów, przez developerów po testerów. Nie ma podziału na role – junior, senior, wszyscy są sobie równi i wspólnie działają na rzecz stworzenia produktu dla klienta. Scrum Master czuwa nad tym, żeby Scrum był dobrze realizowany i cały zespół działał zgodnie z jego zasadami. Pomaga w usuwaniu przeszkód w zespole, działa na rzecz zarówno Zespołu Developerskiego, jak i Product Ownera. Oprócz tego, że działa na usługach zespołu, wyznacza też kierunek działania, by później wspierać kiedy jest taka potrzeba. Ważne jest to, że zespół potrafi się sam zorganizować, gdy już wypracuje przyzwyczajenia i nawyki pracy, co przyspiesza proces tworzenia produktu.

2. Dostarczanie produktu w paczkach

Wyobraźmy sobie, że klient ma pomysł stworzenia produktu, który wesprze jego biznes. Może to być na przykład aplikacja mobilna wykorzystywana w samochodach, która będzie z biegiem czasu rozwijana o nowe funkcjonalności. Tworząc produkt w metodyce Scrum, klient nie otrzyma od razu całego produktu, ale jego części. Zwykle jest to jakaś funkcjonalność, która zaakceptowana stanie się częścią produktu końcowego. Zaletą tego rozwiązania jest to, że zespół może skupić się na stworzeniu dopracowanej mniejszej funkcjonalności, a klient ma poczucie, że realizacja idzie do przodu i tworzony produkt rośnie z jego udziałem. Pamiętajmy, że klient na każdym etapie może wdrożyć odebrane prace, czyli przykładowo uruchomić aplikację w wersji minimalnej już na wczesnym etapie prac, jeśli uzna to za wartościowe. Z czasem będzie ona rozbudowywana o kolejne funkcjonalności.

 

3. Zaangażowanie klienta w proces tworzenia produktu i jeszcze lepszy efekt końcowy

W branży IT wszystko zmienia się bardzo dynamicznie i ważna jest szybka reakcja. Przykładowo konkurencja wprowadza na rynek podobne rozwiązanie, dlatego jeśli wiemy o tym odpowiednio wcześnie możemy zmodyfikować nasz produkt i zaoferować coś lepszego. Dlatego istotna jest bieżąca i otwarta komunikacja z klientem. Ważne, żeby klient widział kierunek, w którym podąża zespół projektowy i dał bezpośredni feedback. W ten sposób ułatwia pracę zespołowi, który dąży do wyznaczonego efektu końcowego. Dzięki skutecznej komunikacji mamy możliwość szybkiego reagowania. Dodatkowo ścisła i oparta na komunikacji współpraca wymaga dyscypliny zarówno od zespołu, jak i od klienta – zespół musi być zdyscyplinowany i skupiony, by dostarczyć produkt w cyklach, a klient musi być dostępny, żeby na bieżąco odbierać kolejne etapy produktu i ustalać priorytety.

 

4. MVP – Twój produkt ma wartość

MVP (Minimum Viable Product) – to minimalna wersja produktu, która jest już możliwa do wprowadzenia na rynek. Jest to produkt wystarczająco określony tak, aby pokazać klientowi jego wartość, a nam pozwolić na sprawdzenie zainteresowania klienta zaproponowanym przez nas rozwiązaniem. Przykładowo tworzymy sklep internetowy i chcemy wdrożyć moduł logowania. Na początku pokazujemy jedynie proste logowanie przez Facebooka, później dodajemy do tego inne konta społecznościowe, rating i rozbudowujemy o kolejne funkcjonalności, które na bieżąco wskazuje klient. W ten sposób dostarczamy minimum, które przedstawia już jakąś wartość – umożliwia logowanie do sklepu online. Podobnie jest w przypadku tworzenia PoCów (Proof of Concept) – PoC pokazuje zarys produktu, wyznacza kierunek prac. Wszystko po to, by nie tracić dużo czasu na coś, co ostatecznie może pójść do kosza, ponieważ na przykład zmienił się rynek lub konkurencja wprowadziła już podobne rozwiązanie.

 

5. W Scrumie wszystko, co jest robione ma sens

W projekcie prowadzonym w sposób kaskadowy, mało kto ze sobą konsultuje pomysły i możliwe rozwiązania. Projekt jest robiony od początku do końca. W Scrumie jest czas i miejsce na analizę, development, testy, dokumentację, dostarczenie, wszystko odbywa się w jednym czasie – w jednym cyklu, czyli Sprincie. Dzięki temu nie okazuje się, że coś, co zostało zaprojektowane nie zostało wyrzucone do kosza. Brak komunikacji i rozmowy powoduje frustracje i niepotrzebne napięcia. W projektach Scrumowych nie ma silosów, jest wspólna praca wszystkich członków zespołu w tym samym czasie. Celem jest implementacja rozwiązania, a cel i kierunek temu procesowi nadaje klient, który od początku do końca uczestniczy w procesie tworzenia.

 

6. Ciągle wprowadzane są usprawnienia

Scrum cechuje iteracyjność, czyli cykliczność. Sprinty trwają od jednego do czterech tygodni i są zakończone podsumowaniem prac oraz planowaniem kolejnych. To wprowadza rytm pracy i organizuje działanie zespołu, a także pozwala na bieżąco wprowadzać usprawnienia do procesu i eliminować wszystko co utrudnia bądź też blokuje prace. Ważne są retrospektywy – zawsze możemy cofnąć się w czasie i zastanowić się nad tym, co warto utrzymać, czego brakuje, co można usprawnić w procesie, a co jest złe i przeszkadza. Może to być organizacja biurek w pokoju projektowym, ale też kwestie architektury systemu, projektowe, komunikacyjne czy interpersonalne. Praca musi być nie tylko efektywna, ale też przyjemna, dlatego należy na bieżąco ją usprawniać.

 

7. Łatwo oszacować wydajność zespołu – wiesz kiedy Twój produkt do Ciebie trafi

W Scrumie częstą praktyką jest estymowanie z wykorzystaniem Story Pointów (SP). Tworząc nową funkcjonalność możemy porównać czas potrzebny na jej stworzenie do poprzedniej, podobnej funkcjonalności. Możemy oszacować, że np. stworzenie logowania będzie trudniejsze niż ratingu. W codziennej pracy do estymacji często używa się ciągu Fibonacciego – co oznacza, że im większa złożoność zadania tym trudniej powiedzieć ile czasu zajmie jego wykonanie. Z tego powodu prace rozbija się na mniejsze elementy, które będzie łatwiej oszacować czasowo, a także przewidzieć złożoność zadania i ryzyko, czyli niewiedzę wynikającą z nowych zadań. Mogą się zdarzyć zadania zarówno bardzo proste, jak i bardzo czasochłonne. Dzięki pracy w Scrumie, jesteśmy w stanie łatwo określić przybliżony czas realizacji produktu. Jeśli zespół jest stabilny i nie zmienił się jego skład to po kilku Sprintach jesteśmy w stanie przewidzieć jego prędkość, czyli jaką wartość biznesową (orientacyjna ilość Story Pointów) jest w stanie dostarczyć w Sprincie.

8. Koncentrujemy się na tym, co dzieje się tu i teraz

W Scrumie zespół projektowy skupia się na pracy w danym momencie i koncentruje tylko na najbliższej przyszłości, a nie na realizacji całego produktu. Ważna jest ścisła współpraca z klientem i uświadomienie mu, że aby zespół mógł pracować efektywnie, musi być skupiony i nie może poświęcać czasu na wprowadzanie zmian na tzw. ostatnią chwilę. Z tego powodu dba się, żeby Zespół Scrumowy nie rozpraszał się zmianami wymagań, ale by dostał jasne wytyczne dotyczące tego, jak dana część produktu ma wyglądać. Taki model pracy pozwala oszczędzić czas – nawet jeśli efekt końcowy będzie się różnił od oczekiwań klienta czy zmienią się trendy czy model biznesowy organizacji, zespół straci tylko dwa Sprinty, a nie np. pół roku pracy. Dla zespołu ważne jest to, że po zaplanowaniu i rozpoczęciu Sprintu, w trakcie jego trwania nie ma już żadnych zmian. Rozpraszanie przeszkadza, developerzy lubią konkretne zadania.

Jak widać, rozwijanie produktu zgodnie z metodyką Scrum ma wiele korzyści. To nie tylko ‘stand-upy’ i sprinty, ale pewnego rodzaju sposób myślenia o relacji pomiędzy odbiorcą końcowym a zespołem. Scrum pozwala rozwiązywać wiele bolączek projektów i jest potężnym narzędziem ułatwiającym pracę każdego zespołu IT.

Masz pomysł na produkt? Zgłoś się do nas, wspólnie zrealizujemy go z wykorzystaniem Scruma.

Oceń ten wpis
(4)
Dominika Grabowska
Dominika Grabowska
O autorze

Najnowsze posty autora |
więcej postow tego autora
MakoLab korzysta z plików cookie w celu realizacji usług zgodnie z Polityką prywatności. Możesz określić warunki przechowywania lub dostępu do cookie w Twojej przeglądarce lub konfiguracji usługi.
Obserwuj MakoLab na portalach społecznościowych
Chcesz być na bieżąco z MakoNewsami? Zapisz się na nasz newsletter.