#Cyfryzacja | Agile to stan umysłu. Dlaczego firmy chcą pracować „zwinnie”? (cz.2)Jak prowadzić backlog?Jak wybrać optymalny sprint?Co zrobić, gdy na drodze do realizacji kolejnego etapu pojawi się problem z pozoru nie do rozwiązania?Kontynuujemy rozmowę o zwinnym zarządzaniu projektami. Tym razem goście studia Sage opowiedzą jak wygląda praca Scrum Mastera i Product Ownera na przykładzie projektów realizowanych w Sage.W studio Sage są Piotr Radaj, trener Agile, Scrum Master w Sage i współorganizator meetup’u Agile Warsaw oraz Łukasz Przezorski, Product Owner w Sage, wykładowca w kilku szkołach programowania w Warszawie.

Czym charakteryzuje się projekt, który na co dzień realizujecie w Sage.
Łukasz Przezorski: My jesteśmy odpowiedzialni za budowę jednej części softu, który nazywa się ERP (ang. Enterprise Resource Planning). To  wielkie oprogramowanie, którego celem jest zintegrowanie wszystkich procesów, zachodzących w przedsiębiorstwie lub innej organizacji. Gdybyśmy popatrzyli na to z drugiej strony, to będzie to bardzo skomplikowany rodzaj oprogramowania, w którym wiele różnych funkcjonalności łączy się z innymi funkcjonalnościami, mają na siebie wzajemne oddziaływanie, np. zmieniając coś w dziale związanym z podatkami, zmieniamy tak naprawdę obliczenia we wszystkich innych obszarach tego oprogramowania, więc projekt charakteryzuje się dużą komplikacją i mieszaniem się różnych funkcjonalności w różnych zespołach.

Ile osób pracuje w Waszym zespole? 
Piotr Radaj: Jesteśmy odpowiedzialni za jeden z modułów tego dużego oprogramowania – modułu dystrybucji. Jest to zespół Scrumowy, który składa się z Product Ownera – Łukasza, mnie jako Scrum Mastera i deweloperów, czyli członków zespołu deweloperskiego, którzy przekładają wizję Product Ownera na produkt. Jest ich sześcioro, czyli w sumie osiem osób.

Wasz zespół jest częścią większego międzynarodowego zespołu?
Łukasz Przezorski: Na co dzień mamy możliwość współpracować z osobami z Francji, Portugalii, a zdarzają się też osoby z Barcelony, z Hiszpanii, z Madrytu, więc rzeczywiście mamy takie środowisko międzynarodowe.

Rozumiem, że pracujecie w języku angielskim, jeśli jest to zespół międzynarodowy?
Piotr Radaj: Niestety moja znajomość języka francuskiego nie jest na wystarczającym poziomie. Jeżeli chodzi o Francuzów i ich znajomość języka polskiego, też nie jest wystarczająca, więc nie mamy wyboru.

Łukasz Przezorski: To co sprawia, że nasza praca jest ciekawsza, to fakt że w naszym zespole są osoby, które nie mówią w języku polskim. Jeden z członków zespołu deweloperskiego pochodzi z Kamerunu, i jego naturalnym językiem jest francuski. Ponieważ my nie jesteśmy w stanie komunikować się w tym języku, to angielski jest używany przez większą część dnia. Zarówno w rozmowach wewnątrz zespołu, jak i tych między zespołami.

Jak wygląda typowy dzień pracy w tak złożonym zespole?
Piotr Radaj: Pracujemy w Scrumie. Scrum to Framework, który pozwala w krótkich odstępach czasu, w sprintach, iteracjach, stworzyć pewną część produktów, którą można zaprezentować interesariuszom, stakeholderom, klientom i zebrać od nich feedback. Dowiedzieć się, czy idziemy w dobrym kierunku, czy w niedobrym, czy coś trzeba zmienić i na bieżąco modyfikować zakres prac, który został jeszcze do wykonania. Typowy dzień pracy w Scrumie składa się z krótkich odcinków czasu nazywanych sprintami. Sprint trwa od 1-4 tyg. My pracujemy w sprintach dwutygodniowych, czyli zaczynamy od planowania, co przez te 2 tygodnie będziemy robić. To jest rola Product Ownera i Scrum Mastera, zespołu deweloperskiego podczas planowania. I jak już wiemy co będziemy robić przez dwa tygodnie, to mamy codzienne spotkania nazywane „daily”, które rozpoczynają nasz dzień pracy. Do 15 minut trwające spotkanie, na którym się synchronizujemy. Jest to spotkanie zespołu deweloperskiego, czyli deweloperzy między sobą, wszystkie osoby tworzące produkt informują co zrobili od zeszłego „daily”, czyli wczoraj, a co planują zrobić dzisiaj. I najważniejsze, czy mają jakieś problemy. Ta część – mówienie o problemach – jest najważniejsza. Problemy będą występowały, ale chodzi o to, żeby zespół rozwiązywał je możliwie jak najwcześniej. „Daily ” to właśnie miejsce na poinformowanie o tym, poproszenie o pomoc, i zaadresowanie tego rodzaju problemów. Co zrobiłem? Co zamierzam zrobić? Czy mam jakieś problemy? Pracujemy w ten sposób, aż do kolejnego „daily”.

Łukasz Przezorski: Odpowiedź na to pytanie zależy od roli, którą grasz w zespole. Moja rola jako Product Ownera powoduje, że mój typowy dzień pracy wygląda zupełnie inaczej niż dzień typowego członka zespołu deweloperskiego i też inaczej niż dzień Piotrka.  Mój dzień pracy to w większości kontakty z zespołem wewnętrznym, czyli tym, z którym realizujemy jakąś część tego produkt backlogu oraz z zewnętrznym – ustalanie priorytetów, rozmowy z zespołami, które budują np. funkcjonalność mającą wpływ na naszą. Ustawianie tego w ten sposób, abyśmy my i oni byli w stanie w tym samym czasie pracować i jednocześnie nie psuć sobie wzajemnie pracy. Moja praca polega w dużej części na komunikacji z innymi i rozmowami na temat tego, co się dzieje obecnie w zespole i będzie się działo w najbliższych dniach, tygodniach i miesiącach.

Piotr Radaj: Tak, to częsty obrazek, widzieć Łukasza na spotkaniach, gdy rozmawia przez słuchawkę. Czasami można mieć wrażenie, że Łukasz pracuje w call center.

Wspomnieliście, że zwinne podejście pozwala dość szybko identyfikować problemy, a jak w praktyce te problemy są rozwiązywane?
Łukasz Przezorski: To zależy z jakim problemem mamy do czynienia.

Piotr Radaj: Czy np. jest to problem programistyczny, czyli ktoś z deweloperów utknął w jakimś punkcie? Jak to jest rozwiązywane? Nie ma w tym żadnej magii, po prostu poprzez kontakt z innym członkiem zespołu deweloperskiego. Codzienna interakcja, niekoniecznie musimy czekać do kolejnego spotkania „daily”, by powiedzieć, że mamy problem, tylko normalna komunikacja twarzą w twarz, która bardzo ułatwia pracę. Szczególnie w tych metodykach zwinnych jest jak najbardziej polecana.

Łukasz Przezorski: Czasami pojawiają się też problemy związane z działaniem samego zespołu deweloperskiego, podczas takiej iteracji, podczas sprintu, podczas tych dwóch tygodni wynikają różne problemy z komunikacją wewnętrzną zespołu. Czasami nie dogrywamy pewnych rzeczy między sobą, gdzieś pewne rzeczy zawodzą i fajnym motywem i momentem na to, aby zastanowić się nad tymi problemami jest retrospektywa, czyli jedno ze spotkań, które mamy w Scrumie, następujące po ukończeniu tego dwutygodniowego okresu czasu iteracji,  kiedy rozmawiamy wszyscy jako zespół deweloperski na temat tego, jak nam poszedł sprint, co było fajnego, co może nie udało się nam najlepiej. Zawsze staramy się wyciągnąć wnioski i punkty do poprawy na przyszłą iterację.