Wiadomości

SCRUM. Skraca drogę? Przyśpiesza efekt? Ulepsza produkt! - rozmowa z Pawłem Kocikiem, Service Delivery Director w Cludo

719

Angelika Słowik, Mobile Journalist: Dlaczego akurat Scrum? Jakie korzyści przynosi ta metodyka?

Paweł Kocik, Cludo: Scrum jest bardzo przyjemnym i dla wielu naturalnym narzędziem pracy do tworzenia produktów. Powód? Pracujemy nad projektem na podstawie tego, co już mamy, co widzimy. Zbieramy feedback i decydujemy co dalej. Ten empiryczny proces jest dużo łatwiejszy dla zespołów realizujących projekt i dodatkowo powoduje, że członkowie bardziej się angażują, wnosi dużo pozytywnej energii. W ten sposób podejmujemy też lepsze decyzje, a co za tym idzie, mamy bardziej wartościowy produkt. W klasycznie prowadzonych projektach często okazuje się, że to, co pierwotnie wydaje się niezbędne, okazuje się finalnie niepotrzebne i takie przypadki znamy również z naszych projektów. Scrum może pomóc temu zapobiec.

Ponadto Scrum zachęca do dyskusji, rozmowy. W naszym zespole niejednokrotnie pojawiają się różnice w postrzeganiu funkcjonalności i szacowaniu, jak skomplikowane jest dane wymaganie, historyjka. Dyskutujemy o tym, dzięki czemu lepiej wszystko rozumiemy i, koniec końców, każdy z nas bardziej świadomie podchodzi do swoich zadań. Scrum jest silnie oparty na zbieraniu informacji zwrotnej, przeprowadzaniu inspekcji, czy to w ramach zespołu, czy przez interesariuszy, w tym tkwi jego ogromna siła.

Jak wygląda stosowanie tego frameworka w praktyce?

Mechanika Scruma polega na tym, że całą pracę dzieli się na sprinty. Sprint rozpoczyna się od Planowania Sprintu, w ramach którego najbardziej priorytetowe, wnoszące największą wartość elementy Backlogu Produktu są włączane do pierwszego, a potem do kolejnych sprintów. Co istotne, nie robi się całego wielkiego planowania na początku, tak jak w klasycznym podejściu do realizacji projektu, tylko tyle ile jest niezbędne do rozpoczęcia prac. Inną ważną kwestią, o której trzeba powiedzieć przy planowaniu, jest to, że o tym, ile pozycji z Backlogu Produktu wejdzie to sprintu decyduje zespół, co zwiększa odpowiedzialność za powodzenie sprintu.

Na koniec każdego sprintu mamy spotkanie nazywane Przeglądem Sprintu (Sprint Review), gdzie zespół prezentuje efekty pracy, zrealizowany przyrost produktu. Jest to czas na zebranie informacji zwrotnej na temat dotychczasowych działań i zastanowienie się, co dalej. Ten pełen feedbacków mechanizm powoduje, że ludzie chętniej wiążą się z projektem, bardziej im zależy, żeby wszystko poszło dobrze i o wiele przyjemniej im się nad nim pracuje. W przypadku kilkumiesięcznych lub kilkuletnich projektów, na efekt końcowy musimy często bardzo długo czekać. Wtedy na końcu może być efekt „wow”, chociaż nie musi. Stosując Scrum możemy go mieć co tydzień lub dwa. Kiedy realizowaliśmy pierwszy projekt Scrumowy, zaobserwowaliśmy bardzo pozytywne reakcje interesariuszy. Praktycznie za każdym razem spotkanie review kończyło się brawami, co było niesamowicie budujące dla zespołu.

Ile powinien trwać sprint? Kiedy możemy uznać go za zakończony?

Scrum Guide podaje, że sprinty powinny trwać maksymalnie miesiąc i zwyczajowo są to jeden 1 lub dwa 2 tygodnie. Nasze sprinty trwały 3 tygodnie. Zaleca się, by cykl i czas takich spotkań pozostał niezmienny. Dzięki temu z czasem zespół zaczyna żyć rytmem danego projektu. Ponadto, jeżeli mamy tu pewną stałą, planowanie staje się łatwiejsze. Lepiej czujemy, co zdążymy zrobić, a czego nie uda się wykonać w sprincie.

Często niedocenianym elementem procesu jest retrospektywa. To czas, żeby omówić sam proces, powiedzieć, co poszło dobrze, a nad czym trzeba jeszcze popracować. W klasycznie prowadzonym projekcie miejsce na poprawę często jest dopiero na jego końcu. Na tym polega przewaga Scruma. Mamy możliwość bieżącej korekty tego, jak realizujemy proces. Naturalnie wymusza analizę tego, co już się wydarzyło i napędza wdrażanie zmian.

Opowiedziałeś o cyklicznych spotkaniach. Jak w takim razie wygląda codzienny Scrum?

Podstawą Scruma jest komunikacja. Wszystkie nowoczesne metody sprowadzają się do tego, że powinniśmy ze sobą rozmawiać. Wydaje się to takie oczywiste, ale często podczas realizacji projektu skupiamy się na swoich działaniach i ten ważny etap pracy pomijamy lub ograniczamy do niezbędnego minimum. Codzienny Scrum to okazja do tego, żeby cały zespół zobaczył, czy jest w dobrym miejscu do osiągnięcia celu sprintu i zaplanował pracę na kolejny dzień. O tej formule spotkań mówi się także stand-up, bo najlepiej, żeby spotkania odbywały się na stojąco. Chodzi o to, żeby spotkanie nie przerodziło się w wielką dyskusję. Codzienne spotkania, najlepiej o stałej porze i w stałym miejscu, maksymalnie piętnaście minut – tak w telegraficznym skrócie to powinno wyglądać.

Mówi się, że w Scrumie nie ma rzeczy częściowo ukończonych: są ukończone lub nie – jak w takim razie ustalić jasne kryteria oceny?

To jest tak, że w Scrumie pracujemy na czymś, co nazywamy Backlogiem Produktu, czyli zestawem funkcjonalności, które chcemy zrealizować. Nad Backlogiem Produktu czuwa Właściciel Produktu. Potem zespół działa w oparciu o tę listę z podziałem na poszczególne sprinty (Sprint Backlog). Przyjęło się, że funkcjonalności mają postać historyjek, czyli opisów wymagań językiem użytkownika. W klasycznym podejściu do wymagań, specyfikacji, często przedstawia się informacje o tym, co system ma robić, a czego nie, w takiej dość bezosobowej narracji. Z jednoznacznym rozumieniem tego typu wymagań może być różnie, co niekoniecznie pozytywnie wpływa na sukces projektu. W momencie kiedy przekazujemy informację o wymaganiu z punktu widzenia użytkownika, czyli „ja jako użytkownik chciałbym, żeby po kliknięciu tego guzika działo się to, żeby osiągnąć jakiś cel, efekt” – dla wszystkich, tj. dla programistów, testerów, użytkowników o mniej technicznych kompetencjach, zaczyna być jasne, co ma się wydarzyć lub przynajmniej jest to dobry początek do rozpoczęcia rozmowy.

Każda historyjka powinna być zrozumiała dla zespołu i uzupełniona o kryteria akceptacji. Wówczas mamy precyzyjny opis funkcjonalności, bardzo dobry fundament dla zespołu do zastanowienia się, jak podejść do realizacji historyjki. Drugim ważnym elementem tego zagadnienia jest definicja ukończenia (definition of done). W jej ramach znajdują się punkty, które zespół powinien zrealizować – zarówno kryteria akceptacji, jak i szczegóły dotyczące samego procesu tworzenia produktu. Wracając do Twojego pytania – są tylko dwie możliwości: ukończona historyjka, albo nie – i wtedy nie wejdzie do przyrostu w danym sprincie.

Czy Twoim zdaniem prawdziwe jest stwierdzenie, że Scrum jest lekki i prosty do zrozumienia, ale trudny do opanowania?

Scrum Guide ma kilkanaście stron. Jest to uniwersalny przewodnik, który jednak wielu aspektów tworzenia produktów nie obejmuje: nie mówi o tym, jak przygotować Backlog produktu, nie wyjaśnia, jak zrobić pierwsze planowanie. Mówi o tym, że jest Backlog Produktu i że zarządza nim Właściciel Produktu, ale nie zawiera informacji o tym, jak stworzyć ten dokument za pierwszym razem. Nie porusza także kwestii związanych z wytwarzaniem oprogramowania. Scrum Guide nie jest więc, pod tym względem, wystarczający, zostawia puste miejsca, które trzeba wypełnić. Na forach i spotkaniach meetupowych często budzi to wiele emocji. Ktoś mówi, że stosuje Scrum i „robi tak i tak”, a ktoś inny odpowiada, że w przewodniku jest napisane coś innego i „ty wcale nie robisz Scruma”. Takich historii jest bardzo dużo i świadczy to o trudności w jego opanowaniu.

Każde zdanie w przewodniku ma swoje znaczenie. Pytanie tylko, jak daleko odchodzisz od książkowo rozumianego Scruma i na ile świadomie to robisz. Scrum wywodzi się z empiryzmu, dlatego na podstawie tego, jak nam idzie, powinniśmy oceniać, co jest dla nas dobre.

Stosowanie tej metodyki podnosi zadowolenie klienta?

Scrum wywodzi się ze zwinnych technik, a one zachęcają do otwartości na zmiany. To jest niezwykle istotne w realizacji projektów. Klienci zmieniają swoje wymagania i potrzeby, bo ich środowisko biznesowe bardzo szybko ewoluuje. W Cludo mamy dużo przykładów projektów robionych klasycznym podejściem waterfallowym, gdzie na początku definiowaliśmy cały zakres projektu, potem realizowaliśmy i oddawaliśmy całość prac na końcu. Często klient przyznawał nam się później, że już w połowie projektu wiedział, że nie wszystkie funkcjonalności będą wykorzystywane, ale my je robiliśmy, skoro się na to umówiliśmy na początku. Podejście Scrumowe może pomóc w realizacji projektu odpowiadającemu na zmieniające się potrzeby klienta, a to znacznie wpływa na jego zadowolenie.

Czy w takim razie poprawia komunikację na linii klient-dostawca?

Może pomóc, ale też Scrum nikogo nie wyręczy i nie zastąpi poprawnie realizowanej komunikacji. Natomiast może zapewnić, że klient będzie na bieżąco obserwował postęp w projekcie i na każdym etapie będzie widział, co się dzieje. To jest bardzo istotne. Klient zamiast rozmawiać z dostawcą, nieustannie pytając „kiedy”, będzie kierował swoje myślenie w kierunku pytań „co dalej” i co ewentualnie zmieniamy, w jaki sposób udoskonalamy produkt. Rozmowa poprowadzona w ten sposób niesie za sobą nową wartość.

Scrum oczywiście niesie pewną niewiadomą, jeśli chodzi o projekt, bo nie wiemy, gdzie dotrzemy. Oczywiście możemy bazować na planie i wstępnej wizji produktu. Natomiast, jeśli chcemy być zwinni, to musimy być także gotowi na zmianę.

Jakie są Wasze doświadczenia w pracy zgodnie z tą metodyką?

Dotychczas w pełnym Scrumie wykonaliśmy skrypter wspomagający pracę agenta contact center. Wykonane narzędzie ma poprowadzić konsultanta przez cały proces rozmowy z klientem. Po drodze pomaga zebrać dane o rozmówcy. Wprowadzenie tego rozwiązania, to była odpowiedź na wymagania naszych klientów. Narzędzie ułatwia im pracę i w dodatku są je w stanie sami konfigurować.

Do tego projektu przymierzaliśmy się już od dawna i kiedyś nawet próbowaliśmy go przeprowadzić klasycznie, tj. na początku zaprojektować w szczegółach całe rozwiązanie realizujące wszystkie znane i potencjalne oczekiwania klientów. Zaczęliśmy pisać wymagania, specyfikację tego, co narzędzie powinno robić, a następnie obmyślać, jak to wszystko powinno zostać zbudowane. Projekt poległ, nie przechodząc do fazy realizacji, m.in. dlatego, że wydawał się ogromną inwestycją, a mieliśmy też inne priorytety w tamtym czasie. W ubiegłym roku pojawił się pomysł, żeby powrócić do realizacji tego projektu. Tym razem postawiliśmy na Scrum. Posortowaliśmy wymagania zgodnie z hierarchią ważności, te najważniejsze przerobiliśmy na historyjki, a następnie zrobiliśmy pierwsze planowanie sprintu i przystąpiliśmy do realizacji. Tym razem się udało i duża w tym zasługa Scruma.

A jeśli chodzi o projekty zewnętrzne?

Pracujemy z klientami kawałkami Scruma. Wiem, że znawcy mogą tu powiedzieć, że to już nie jest Scrum (uśmiech). Na ten moment nie robiliśmy stricte Scrumowych projektów z klientami. Nasz wewnętrzny projekt software’owy zrealizowaliśmy w oparciu o tę metodę i planujemy w ten sposób realizować kolejne. Jeśli chodzi o dostarczanie naszej usługi klientom, to jeszcze nie mieliśmy okazji wykorzystać do tego pełnego Scruma, ale z dużą chęcią przeszlibyśmy ten proces razem z naszym klientem.

Jak stosowanie Scruma we współpracy na linii klient-dostawca przekłada się na korzyści, które uzyskuje klient końcowy?

Wytwarzając produkt Scrumowo często dostarczamy nowe wersje oprogramowania, nowe funkcjonalności, co dla klienta końcowego będzie ogromną wartością dodaną. W przeciwieństwie do klasycznie zarządzanego projektu, w którym aktualizacje będą następowały raz na kwartał czy pół roku; tutaj efekty naszych działań będą widoczne dużo szybciej.

Jakie metody zarządzania projektem stosujecie w Cludo?

Wywodzimy się z klasycznego podejścia waterfallowego. Widoczne jest ono szczególnie w projektach uruchomienia usługi Cludo, projektach startowych, gdzie na początku definiujemy projekt, tworzymy specyfikację. Wtedy powstaje dokument z opisem, co zostanie dostarczone, następnie przystępujemy do realizacji, a potem testujemy i przekazujemy klientowi. Przechodzimy więc przez kolejne fazy inicjalizacji projektu, planowania, realizacji, kontroli i zamknięcia projektu. Nasze działania czerpią tu sporo z metodyki PMP (Project Management Professional) w zakresie komunikacji czy podejścia do budowania planu projektu. Staramy się, aby osoby realizujące zadania w projekcie były mocno zaangażowane w przygotowanie planu projektu, co pozytywnie wpływa na odpowiedzialność za zadanie.

Od jakiegoś czasu w naszych projektach startowych przebijają się różne wydarzenia scrumowe. Wspólnie z naszymi klientami organizujemy pracę wokół sprintów. Tak więc Scrum wkracza do naszych projektów startowych. Co jest ważne jednak w pracy Cludo jako dostawcy usługi chmurowej, to fakt, że bardzo dużo pracy z klientem wykonujemy już po zakończeniu projektu startowego, gdy usługa działa już produkcyjnie. Tutaj często projekt startowy jest tylko niewielkim fragmentem wszystkich rzeczy, które robimy wspólnie w ciągu całego okresu współpracy. I, co ciekawe, w trakcie współpracy jesteśmy gotowi na zmiany i wprowadzanie nowości czasami w tempie szybszym niż przewiduje to Scrum. Można powiedzieć, że jesteśmy bardzo zwinni bez stosowania Scruma.

Co jest najbardziej pomocne przy tworzeniu dedykowanych rozwiązań dla klientów?

Potrzebny jest otwarty, bardzo sprawny i doświadczony zespół, taki, który pod różnym kątem potrafi przeanalizować potrzeby klienta, pomoże zaprojektować często dość skomplikowane procesy, umie przewidzieć ryzyka, które wiążą się z daną funkcjonalnością oraz będzie w stanie dobrze doradzić zamawiającemu i pokierować go, kiedy zajdzie taka potrzeba. My „niestety, a może stety” mamy dużo ludzi, którzy potrafią to robić, więc, jak pojawiają się nowe wymagania od klientów, to nasi inżynierowie, eksperci wręcz się prześcigają w wymyślaniu najlepszych rozwiązań. Dedykowane rozwiązania mają jednak też swoje wady, więc tym chętniej idziemy w kierunku produktów – i tutaj Scrum okazuje się bardzo pomocny.