Agilia2014 – 2 dzień – case studies i Gojko Adzic

logo-agiliaDrugi dzień konferencji Agilia upłynął pod znakiem mocnych prezentacji opisujących przypadki korzystania ze scruma w różnych specyficznych kontekstach. Samą konferencję w pięknym stylu zamknął Gojko Adzić, prezentując ideę będącą u źródeł Impact Mappingu.

Pierwsza godna uwagi prezentacja zawierała doświadczenia z korzystania ze scruma w agencji interaktywnej. Scrum Master i Product Owner z firmy edenspiekermann przedstawili jaka jest specyfika pracy scrumem w agencji reklamowej. Zdaniem Michaela i Christiana design i development nie mogą być odseparowane, dlatego tworzą u siebie interdyscyplinarne zespoły. W ich firmie designerzy rozumieją kod (i nie generują pomysłów niezrealizowalnych), a frontend developerzy design, dzięki czemu są w stanie efektywnie ze sobą współpracować. Ponieważ klienci agencji kompletnie nie rozumieją scruma, Michael i Christian odchodzą od czystych reguł metodyki i powołują dwóch Product Ownerów. Proszą o wyznaczenie PO po stronie klienta, a sami obsadzają w tej roli Creative Leada albo Creative Directora, który odpowiada w zespole za product backlog, a jednocześnie coachuje PO klienta i angażuje go w podejmowanie decyzji i udzielanie zespołowi informacji zwrotnej. Korzystając ze scruma, ustawiają się w roli partnera, a nie dostawcy usług. Sprzedają swoje doświadczenie i umiejętności, a nie obietnice konkretnych produktów. Nawet, gdy powstanie pierwsza wersja product backloga, wyraźnie podkreślają, że nie jest to kontrakt, ani obietnica zakresu i realizacji całości. Mimo tego zdarza się, że ich klienci myślą, że to, co znajduje się w backlogu, to kompletny zakres, który odbiera możliwość manewru podczas szukania minimalnej wersji produktu (MVP) i uniemożliwia elastyczność, gdy okazuje się, że pierwotny pomysł musi zostać zmieniony.

Przy tak ustawionych zasadach pracy, sami mieli wątpliwości, czy są w stanie konkurować z tradycyjnymi agencjami, które stawiają obietnice krótszych terminów i niższych cen (kosztem eksploatacji swoich ludzi i wyciągania pieniędzy z klienta po podpisaniu kontraktu). Czas i kolejne udane realizacje pokazały im, że tak naprawdę funkcjonują w innym obszarze. Ich przewagą jest zapewnienie dobrego doświadczenia interakcji z marką – coś, czego tradycyjne agencje nie są w stanie dać klientom.

Podsumowali swoje odczucia w subiektywnej ocenie tradycyjnych agencji:

  • Opierają się na braku zaufania
  • Decyzje opierają na wyczuciu smaku
  • Spowalniają je niekończące się rundy feedbacku
  • Klient jest wrogiem

Ich zdaniem agencja agile’owa realizuje zadania inaczej:

  • Zaufanie jest podstawą
  • Decyzje są oparte o testy z użytkownikami
  • Prezentowane jest jedno rozwiązanie wynikające z prac iteracyjnych
  • Współpraca to partnerstwo z klientem

W realiach pracy z klientem agencji kreatywnej Christian i Michael podkreślili też istotność fazy przed rozpoczęciem pracy w sprintach, gdy ustalają z klientem, po co ma być zrealizowany dany projekt i definiują wizję produktu.

Drugą wartą wymienienia prezentacją było wystąpienie Benta Myllerupa na temat rozwoju systemów budowanych z wykorzystaniem technik zwinnych. Zaczął od powodów, dla których typowo uważa się, że dla takich projektów agile się nie sprawdza:

  • Nie da się przygotować gotowej funkcjonalności w 4 tygodnie lub krócej
  • Zbyt dużo różnych kompetencji jest potrzebnych do przygotowania całego produktu, by stworzyć zespół interdyscyplinarny
  • Najpierw musi być przygotowany sprzęt (hardware), żeby można zacząć pisać oprogramowanie – nie ma tu miejsca na zrównoleglenie prac
  • Nie da się zrobić Ciągłej Integracji czy testów automatycznych dla sprzętu
  • Zmienianie wymagań w trakcie rozwoju produktu jest nierealne i ma katastrofalny wpływ na koszty
  • Formułowanie wymagań w postaci user stories jest niemożliwe
Slajd Benta nt MVP dla embeddowanego systemu

Slajd Benta na temat MVP

Doświadczenie Benta pokazuje jednak, że agile jest możliwy. Co najwyżej trzeba zmienić podejście i założenia co do zespołów i projektów. Przede wszystkim warto skupić się na tworzeniu fantastycznego produktu końcowego, a nie zamykać w silosach technicznych kompetencji. Zespół Benta na początku projektu zbudował backlog produktu i zadał sobie pytanie, jak każda ze specjalności technicznych może się przyczynić do rozwoju całego produktu od początku. Zamiast budować cały hardware (w czasie którego programiści nie mogliby ruszyć z miejsca), zaczęli od MVP, kompletnego prototypu, którego nie sprzedaliby na rynku nikomu, ale w krótkim czasie mieli wersję sprzętu, dla którego można było zacząć pisać oprogramowanie, sprawdzić połączenia i interfejsy. Z perspektywy czasu Bent uważa, że nawet największe przeszkody i założenia, że coś jest niewykonalne w danym środowisku, nie są powodem, by nie spróbować stworzyć zespołów, bo tylko one poradzą sobie ze złożonością i chaosem. Ciekawym akcentem humorystycznym było zaprezentowanie na koniec sesji sposobu, w jaki zespół poradził sobie z automatyzacją testów – dla konkretnego produktu stworzył automat testujący, zbudowany przy użyciu Lego Mindstorms ®.

Konferencję zamykało wystąpienie Gojko Adzicia „Make Impact not Software”. W energiczny sposób Gojko pokazał, że tworzone przez nas user stories nie pozwalają ocenić sukcesu biznesowego, jaki zespół może wypracować. Można jedynie sprawdzić, czy przygotowane oprogramowanie odpowiada zamówieniu. Częsty jest też konflikt pomiędzy sposobem przedstawiania planów pracy – biznes preferuje komunikaty marketingowe i prezentacje Powerpointowe z roadmapami w punktach, zespoły bazują na liście tasków i user stories trzymanych w swoim narzędziu albo na tablicy, co prowadzi do kompletnie dwóch różnych wersji i źródeł prawdy. Gojko skrytykował również zbyt kurczowe trzymanie się miar, które określił miarami negatywnymi – takimi, które sygnalizują nam że jest coś źle (niskie pokrycie kodu, słabe velocity), ale nie pomogą nam powiedzieć w definitywny sposób, czy jest dobrze.

Zamiast tego Gojko proponuje stosowanie roadmap, które są mapą dróg ;), szeregiem opcji, mających doprowadzić nas do oczekiwanego rezultatu. Powinniśmy określić, jakie zmiany zachowań użytkowników chcemy osiągnąć i zacząć je mierzyć. Liniowe rozplanowanie backlogu zgodnie z ustaloną z góry ścieżką wybranego rozwiązania, to ślepa uliczka, która odbierze elastyczność w reagowaniu na zmiany – a to na tym polega przecież agile. Zamiast tego warto stosować wizualne przedstawienie backlogu, takie jak story mapping czy impact mapping. W kilku praktycznych przykładach Gojko pokazał, w jaki sposób przetransformował w firmie produkującej gry projekt dodania do systemu poziomów zaawansowania i osiągnięć (oceniany na 9 miesięcy pracy zespołu). Użył do tego serii  pytań o potrzebne zmiany w zachowaniach użytkowników:

  • po co? „by zwiększyć aktywność graczy”
  • a jakie mamy inne opcje by zwiększyć aktywność? „turnieje pomiędzy graczami”
  • ile zajmą nam turnieje? „1 sprint”

Zamiast systemu poziomów PO i zespół wybrali jako pierwszy krok rozwoju turnieje i szybko okazało się, że dodatkowe założenie zakładało, że aktywni i zdobywający osiągnięcia w grach gracze będą o tym chętnie pisać w swoich sieciach społecznościowych (co rozpropaguje grę wśród kolejnych osób). Podobny efekt spróbowali osiągnąć turniejami i w jeden sprint udowodnili, że nikt nie chce spamować swoich znajomych dodatkowymi informacjami z gry – tym samym udowodnili też, że ew. rozwój systemu przez 9 miesięcy byłby z góry skazany na porażkę.

Gojko zamknął swoją prezentacją analogią do „biznesowego” Test-Driven Development i zachęcił do tego, żeby przed rozpoczęciem prac określić wysokopoziomowy cel i oczekiwane zmiany w zachowaniu użytkowników oraz jak najszybciej przetestować i rzetelnie sprawdzić, czy hipoteza była prawidłowa. Tą myślą w świetny sposób zamknął klamrą konferencję, nawiązując do myśli Dave Snowdena z pierwszego dnia.

Czytaj także:

Agilia2014 – podsumowanie pierwszego dnia

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

*

Ta strona używa Cookies. Korzystając ze strony wyrażasz zgodę na używanie ciasteczek zgodnie z aktualnymi ustawieniami przeglądarki.
Akceptuję, bo lubię Was czytać.
x