Dwuoosobowa reprezentacja agile247.pl pojawiła się 7 kwietnia w Warszawie, aby wraz z kilkuset innymi osobami wziąć udział w konferencji 4Developers. Ponad 16 scieżek tematycznych powodowało, że wybór tematów był ogromny i trzeba było spędzić chwilę czasu, aby spośród wielu prezentacji wybrać takie, na których warto się pojawić. Nas oczywiście najbardziej interesowały te, które w jakiś sposób dotyczyły agile.
Poniżej przedstawiamy trzy – naszym zdaniem – najciekawsze prezentacje, które z czystym sumieniem polecilibyśmy każdemu entuzjaście zwinnych metod pracy.
Zarządzanie projektem przyjazne programiście – Robert Pankowiecki
Robert Pankowecki zaprezentował 4 rady, które stosuje w swojej firmie, rady uniwersalne względem wielu zespołów, ale jemu szczególnie sprawdzające się w kontekście swojej firmy, złożonej w całości z programistów pracujących zdalnie.
Pierwszą radą jest stosowanie tylko User Stories o rozmiarze 1, przy czym dokładnie dookreślonych, jako temat, który zajmuje typowo 4 godziny pracy, posiada business value i jest niepodzielne na mniejsze elementy. Tak agresywne podejście do dekompozycji zadań powoduje później łatwość mierzenia postępu prac, psychologiczny efekt częstego kończenia zadań (1-2 razy dziennie zamykasz User Story) oraz minimalizowane jest ryzyko niedostarczenia potrzebnych elementów produktu, ponieważ produkt przyrasta krokowo.
Drugą radą było nie przypisywanie zadań do konkretnej osoby w trakcie planowania iteracji. Zadania ułożone są według priorytetów i według priorytetów powinny być kończone. Zadania nie przypisane dają wolność i elastyczność w realiach pracy zdalnej, gdzie członkowie nie ustalają sobie na sztywno jako zespół, że codziennie pracują po x godzin. W jedne bowiem dni mogą pracować więcej, a w inne zupełnie sobie odpuścić – dzięki braku przypisania zadań, w takich przypadkach nie muszą się zobowiązywać do niczego przed sobą. Dodatkowo, projekt nie ucierpi, jeśli pierwotny plan realizacji zadań przez osoby z różnych powodów nie został zrealizowany.
Wspierającą zasadą do powyższego jest zasada „weź pierwsze zadanie z Product Backlogu”. Zadania w Product Backlogu są poukładane według priorytetów, więc każdy kto jest wolny i może rozpocząć kolejne User Story, bierze pierwsze od góry, niezależnie od tego, na czym ona polega. Tym sposobem dbają o wymianę wiedzy, o rozwój szerokich kompetencji u członków zespołu, jako efekt uboczny od reguły zapewniają też, że cały zespół w każdej chwili pracują nad najistotniejszymi zadaniami, a nie nad tymi, które jest danej osobie najwygodniej wykonać.
Ostatnią radą, jaką przekazał Robert, było pokazanie triku na radzenie sobie z za dużymi User Stories – jako oczywiste podał rozbicie całości na mniejsze historyjki (znalezienie sposobu na takie rozbicie jest zadaniem każdego developera). Natomiast ciekawą alternatywę podał na momenty, gdy panuje poczucie, że całej dużej historyjki rozbić niestety się nie da. Zaproponował, by z dużej historyjki (czy fragmentu specyfikacji wymagań od klienta) wydobyć fragmenty, które są pewne i samodzielne, potraktować ich jako oddzielnej User Story i z dużego zadania wykreślić te wymagania. Tym samym nie silimy się na kompletne rozbicie całego wielkiego zadania, a skupiamy się na „pewniakach”, które wiadomo jak oddzielić i pozostawienie sobie kłopotu z resztą teoretycznie niepodzielną na później, z opcją aby dać takie zadanie do przepracowania innej osobie.
Agile na poziomie portfolio – Karol Traczykowski
Kolejną prezentacją godną wspomnienia, było wystąpienie Karola Traczykowskiego z GoldenLine, który opowiedział jak zarządzają portfelem agilowych projektów. Karol zdefiniował zarządzanie portfelem jako zadanie mające na celu wybranie ze wszystkich możliwych prac tych, których podjęcie przyniesie najwięcej korzyści. By zminimalizować szum informacyjny i skupić się na ważnych rzeczach na poziomie portfela projektów, w Goldenline nie zajmują się zadaniami drobnymi (maintenance, bugfixing), są to zadanie od razu przekazywane osobom w roli „strażaka”. Jest to rola, którą w rotacyjny sposób, w tygodniowym interwale, obejmują po kolei wszyscy programiści.
Najważniejsze pytanie, jakie Karol widzi w momencie pracy nad portfelem to „czy w ogóle robimy to zadanie?”. Jeśli decydują się na spróbowanie, większość zadań zamieniają w MVP, drobną próbę która sprawdzi, czy jest w ogóle sens wrzucać całość przedsięwzięcia do portfela. Pojawiło się też na prezentacji ostrzeżenie, by nie podążać przy priorytetyzacji ślepo za ROI, ponieważ ciężko nam zazwyczaj trafnie oszacować potencjalny zysk.
Rzeczy najważniejsze w danym momencie przekazywane są zespołom, które proszone są o oszacowanie całości zadania i określenie przewidywanej daty dostarczenia. Jest to jednocześnie okazja do skonfrontowania pomysłów i usłyszenia od zespołu najlepszych sposobów realizacji danego celu.
Na poziomie całego portfela co 1-2 tygodnie sprawdzają, jak idą postępy prac nad poszczególnymi elementami. Postęp oceniany jest na podstawie produktów dostarczonych przez zespoły. Co do każdego projektu podejmują jedną z trzech decyzji:
- Commit – idzie OK, kontynuujmy pracę
- Transform – coś jest nie tak, zmieńmy coś w projekcie (zmniejszmy zakres, dodajmy ludzi o brakujących kompetencjach do składu zespołu, skonsultujmy dodatkowo z interesariuszami pewne założenia)
- Kill – zatrzymajmy projekt
Do wizualizacji tak zebranego portfela korzystają z tablicy kanbanowej, z limitem na „pracę w toku” i szacowaniem wielkości projektów. Projekty duże (XL) rozbijają na Epiki i mniejsze User stories, by realnie widzieć postępy z tygodnia na tydzień, a nie ciągle widzieć, że tygodniami jakiś wielki projekt jest w trakcie.
Ustalili sobie w toku usprawniania się, że nawet największy projekt musi być wydawany do korzystania użytkownikom przynajmniej w części nie rzadziej niż raz na miesiąc, de facto releasy zdarzają się bardzo często, do kilku razy w tygodniu. Ogólnie Karol mocno podkreślił fakt ewolucji tablicy kanbanowej dla portfela i fakt tego, że każda firma czy każdy produkt musi przejść swoją drogę usprawnień i eksperymentów w pracy nad procesem zarządzania portfelem.
Post-Mortem Call of Juarez Gunslinger z punktu widzenia dewelopera – Michał Nowak
Kolejną ciekawą prezentacją – niejako “ukrytą”, zamieszczoną bowiem na ścieżce “Game Development” – była prezentacja reprezentanta firmy Techland, Michała Nowaka. Po zwięzłym przedstawieniu sukcesów i liczb stojących za samą grą “Call of Juarez: Gunslinger”, prelegent skupił się na przedstawieniu drogi, której przebycie pozwoliło im osiągnąć wspomniane wyniki.
Co ciekawe, Techland już 3 raz podchodził do korzystania ze Scruma i w końcu można powiedzieć, że z sukcesem – natomiast dwa poprzednia wdrożenia zakończyły się niepowodzeniem. Jeśli miałbym ogólnie podsumować, dlaczego im się tym razem udało, to zapewne konkluzja Michała byłaby najbardziej trafna – “wybiórcze traktowanie Scruma się nie sprawdza”. Wypunktował takie słabości poprzednich wdrożeń jak brak Product Backlogu, niewłaściwe zarządzane produktem, braki w edukacji załogi (Product Owner, Scrum Master, Zespół Deweloperski) czy “spowiadanie się pod tablicą” w zastępstwie przeprowadzenia wartościowego spotkania Daily Scrum.
To co najbardziej zapada w pamięć z prezentacji, to kilka smaczków dotyczących sposobu testowania w branży game dev.
Michał zwrócił uwagę na specyfikę pracy testera, która polega na… codziennym graniu w najnowszego builda gry 🙂 Pomijając już nawet fakt, że docenili wartość z przesiadywania programistów oraz testerów wspólnie w jednym pomieszczeniu, interesująca była informacja, że testerzy grają na docelowej wersji gry, na prawdziwych mapach, co powoduje, że ich feedback przynosi większą wartość i jest wzbogacony o kontekst sytuacyjny.
Równie udanym pomysłem było zaangażowanie kilkudziesięciu (ok. 36) osób z zewnątrz firmy w testy, które regularnie (po każdym Sprincie) odbywały się w studio, co owocowało kolekcjonowaniem feedbacku w regularnych odstępach czasu, na wczesnym etapie rozwoju gry. Pozwala to programiście, który przykładowo implementował zachowanie się broni maszynowej w grze zobaczyć, jak końcowy użytkownik korzysta z niej w praktyce.
To co było wyraźnie widoczne podczas prezentacji to fakt, że prelegent dzielił się zarówno sukcesami, jak i porażkami. Jedna z nich dotyczyła decyzji pozostawienia optymalizacji technicznych, wymaganych przez producentów konsol XBox oraz PS3, na sam koniec trwania projektu. Jak łatwo sobie wyobrazić, spowodowało to odkrycie wielu błędów i niedociągnięć, które zaowocowały koniecznością naprawienia ich po godzinach, czyli tzw. crunch.
Podsumowanie
Lista ścieżek dostępnych podczas konferencji
To co ucieszyło nas najbardziej to fakt, że coraz więcej firm, w coraz śmielszy sposób dzieli się swoimi przemyśleniami dotyczącymi sposobu wytwarzania oprogramowania. Zdaje się, że już wkrótce łatwo będzie spotkać konferencję, na której agile, Scrum czy kanban w taki, czy inny sposób, przewijać się będzie przez każdą prezentację.
Trzeba przyznać, że organizacja konferencji była całkiem udana. Przestrzeni dostępnej dla uczestników było zdecydowanie więcej niż rok temu, oznaczenie poszczególnych ścieżek było jasne i czytelne, a każda ścieżka posiadała swojego “anioła”, który oprócz ogólne wsparcia dla prelegenta, dbał o terminowe rozpoczęcie wykładu oraz jego zakończenie.
Nam osobiście trochę doskwierał brak papierowej wersji agendy – trzeba przyznać, że aplikacja mobilna, która zapewniała te informacje była znośna, nie była jednak aż tak wygodna, jak agenda offline’owa, którą można było przecież dołączyć do identyfikatorów, jak miało to miejsce w poprzednich latach.
W napiętym harmonogramie prezentacji brakowało trochę czasu na networking. Być może warto by było w przyszłości rozważyć scenariusz, w którym prelegenci mają mniej czasu na prezentację (np. maksymalnie 30 min), na korzyść dłuższych przerw, podczas których można by było dopytać prelegentów o szczegóły oraz nawiązać nowe kontakty.
Nie zmienia to jednak faktu, że śmiało możemy zadeklarować – do zobaczenia na kolejnej edycji!