Przewodnik po Agile Scrum dla Właścicieli Produktów. Część 1 – Coraz trudniejsze zmiany

Zwinne wytwarzanie oprogramowania zawładnęło firmami IT. Wszechstronność, elastyczność, łatwość adaptacji do zmian to tylko kilka z wielu zalet sprawiających, że zyskało ono przewagę nad klasycznymi, kaskadowymi metodologiami.

Wprowadzenie zwinności w wewnętrzne procesy software house’u jest relatywnie łatwe dzięki szkoleniom, praktyce i ciągłym usprawnieniom. We współpracy z klientem, który zazwyczaj jest też właścicielem produktu, trzeba doprecyzować pewne kwestie.

Spis treści

1. Manifest Agile
2. Rola właściciela produktu
3. Obowiązki na każdym etapie projektu
   – Inicjacja projektu
   – Wprowadzaj zmiany w odpowiednim czasie
   – Design
   – Zmiana jest mile widziana, o ile ma ona sens
   – Wytwarzanie produktu
   – Testowanie
   – Czas to pieniądz (klienta)
   – Im wcześniej, tym lepiej…
4. Podsumowanie

Zarządzanie projektem w stylu Agile opiera się na burzach mózgu, czynnym udziale i współpracy wszystkich członków zespołu – nie na dokładnie określonym planie i podążaniu za dokumentacją. Typowy zwinny zespół, na przykład taki pracujący w metodologii Scrum, składa się z trzech głównych ról – właściciela produktu, Scrum Mastera i grupy będącej zespołem developerskim. Większość teamu jest zasilana przez pracowników firmy programistycznej, ale właściciel produktu jest zewnętrznym, nieprzeszkolonym i najczęściej najmniej doświadczonym członkiem. Tak, jako klient zwinnego developera aplikacji, Ty (lub osoba, którą do tego wyznaczysz) stajesz się częścią zespołu na czas trwania projektu.

Jako że wśród firm istnieje tendencja do zatrudniania właścicieli produktu, oto nasza rada na początek: nie zatrudniaj kogoś, kto będzie zarządzał produktem za Ciebie. Jeśli nie możesz się zaangażować, znajdź kogoś, kto może to zrobić wśród swoich zaufanych pracowników – kogoś, kto podziela Twoją wizję.

Manifest Agile

Zwinność developmentu wymaga priorytetyzacji (nie zastępowania) jednych wartości względem drugich. Interakcje międzyludzkie ponad procesy i narzędzia, tworzenie działającego oprogramowania zamiast kompletowania dokumentacji, współpracę z właścicielem produktu zamiast negocjacji kontraktu oraz, co najważniejsze – reagowanie na zmiany zamiast kurczowego trzymania się planu.

Dwa ostatnie punkty są prawdopodobnie najważniejsze z punktu widzenia klienta. W obu przypadkach zaangażowanie klienta jest kluczowe, aby projekt okazał się sukcesem.

Więcej o zasadach Manifestu Agile przeczytasz w osobnym artykule.

Rola właściciela produktu

Czego oczekują developerzy od właściciela produktu w kwestii partycypacji w konkretnych fazach wytwarzania produktu? Koncentrujemy się przede wszystkim na komunikacji wewnątrz zespołu – zewnętrzne wpływy i interakcje nie są zgodne z metodologią Scrum i mogą zakłócać lub utrudniać proces.

Kim jest właściciel produktu?

To osoba, która staje się integralną częścią zespołu. Oznacza to bycie w stałym kontakcie z teamem od samego początku projektu. Twoim głównym zadaniem jest przede wszystkim poinformowanie ich o tym, co ma być zrobione – innymi słowy czego oczekujesz po gotowym produkcie. Wizja, pomysł, wartości biznesowe, oczekiwanie doświadczenia użytkownika, identyfikacja marki – wszystko to musisz przekazać swojemu zespołowi Scrum do akceptacji. Będziesz także tzw. Single Point of Contact (Pojedynczy Punkt Kontaktowy) – mostem komunikacyjnym pomiędzy zespołem a resztą zainteresowanych.

Najlepszym sposobem na przyczynienie się do sukcesu projektu jest klarowna wizja produktu, który zamawiasz.

Obowiązki na każdym etapie projektu

Inicjacja projektu

To moment, w którym projekt zacznie nabierać ogólnego kształtu. Oczekiwania, wymagania, ramy czasowe oraz zakres projektu powinny być zarysowane tak kompleksowo, jak to możliwe. Jako właściciel produktu musisz wiedzieć, czego chcesz. To twój produkt będzie wytwarzany i jesteś jedyną osobą, która wie, jakie powinien mieć funkcjonalności i jak powinien wyglądać.

Twoją odpowiedzialnością jest także akceptowanie zaproponowanych rozwiązań. Wszystkie wymagania zostaną ujęte w backlogu produktu – liście wszystkich elementów, które muszą zostać zbudowane.

Wprowadzaj zmiany w odpowiednim czasie

To etap, gdy wdrażanie zmian jest najprostsze. Wszystko, co do tej pory zostało zrobione jest głównie “na papierze”, a programowanie się nie rozpoczęło. Zmiana zdania na niektóre tematy nie powoduje trudności i nie marnuje (cennego) czasu developerów. Nie wzbraniaj się przed zadawaniem pytań, dyskutowaniem, proponowaniem i podążaniem za swoją intuicją. Im dokładniej wyjaśnisz swój pomysł, tym lepsze (i tańsze) będą efekty w dalszej perspektywie.

Design

Po ustaleniu backlogu produktu można rozpocząć projektowanie. Twoją rolą będzie akcept proponowanych rozwiązań lub też ich odrzucenie i zaproponowanie lepszej opcji. Zespół będzie tak długo zmieniał, dostosowywał i doskonalił design produktu, aż wyrazisz aprobatę dla wypracowanych rezultatów. Przekazuj jak najwięcej informacji zwrotnych, aby łatwiej było im stworzyć satysfakcjonujące rezultaty.

Wprowadzanie istotnych oraz mniejszych zmian jest jeszcze proste, ale warto pamiętać, że zespół poświęcił już część swojego czasu na pracę nad produktem. Znaczenie każdej zmiany powinno być przemyślane. Czy rzeczywiście będzie widać różnicę? Jaką wartość otrzymamy? Czy wydanie dodatkowych pieniędzy się opłaci?

Zmiana jest mile widziana, o ile ma ona sens

To prawda, że zwinne wytwarzanie oprogramowania wyróżnia się otwartością na zmiany i umiejętnością dostosowywania się do nich, rzeczywistość jednak pokazuje, że im później takie zmiany wprowadzamy, tym implementacja jest bardziej skomplikowana i czasochłonna.

W fazie designu warto myśleć o konsekwencjach zmieniania produktu z wyprzedzeniem. Wtedy wizja jego ostatecznego kształtu powinna być mniej więcej gotowa, a wszystkie ważne elementy zawarte w backlogu produktu i przygotowane do developmentu.

Wytwarzanie produktu

To etap, gdy zaczyna się prawdziwa (czytaj: droga) praca. Podzielenie backlogu na sprinty, ustalenie ram czasowych dla każdego z nich, zdefiniowanie modułów możliwych do dostarczenia w jednym sprincie oraz ustalenie warunków ich akceptacji. Dla właściciela produktu istotna jest obecność na początku każdego sprintu – aby uzgodnić backlog dla tej konkretnej jednostki pracy. Jeżeli w trakcie trwania sprintu pojawią się problemy lub będą potrzebne wyjaśnienia, będzie trzeba znaleźć czas dla zespołu.

Zidentyfikuj problemy i szybko się do nich odnieś

Im szybciej odniesiesz się do problemu, tym mniej zasobów będzie potrzebnych do naprawienia go. Typowe sprinty trwają od 1 do 4 tygodni, w zależności od ich złożoności, rozmiaru backlogu i przewidywanych trudności. To faza projektu, w której wprowadzanie zmian może stawać się coraz trudniejsze.

Zasady Scruma zakładają, że każdy sprint po rozpoczęciu staje się jednostką zamkniętą. Oznacza to, że nie można dodawać nowych pozycji do backlogu w trakcie trwania sprintu. To dotyczy nie tylko ogólnego backlogu produktowego, ale także zmian i wariacji na temat pozycji zawartych w trwającym sprincie. 

Zmiany i usprawnienia najlepiej proponować podczas sprintowej retrospektywy. W Scrumie jest to czas rewidowania pracy i identyfikowania problemów wymagających uwagi.

Nie eksperymentuj z trwającym już sprintem

Jeśli uważasz, że zmiana jest nieunikniona, a dotyczy ona trwającego właśnie sprintu, najlepszą i najtańszą opcją będzie porzucenie go i rozpoczęcie kolejnego z nowym backlogiem. Wszelkie poprawki muszą być najpierw umieszczone w backlogu produktowym, aby potem można je było zawrzeć w sprincie. 

Ewentualnie można stworzyć całkowicie nowy sprint dedykowany jednej zmianie. To rozwiązanie poleca się dla takich zmian, które mogłyby przekroczyć rekomendowaną długość sprintu, czyli 1 do 4 tygodni.

Odpuść, aby wygrać

Zmiany, które zaproponujesz w projekcie, mogą mieć różny wpływ na ramy czasowe i ogólny koszt. Warto rozważyć redukcję podpunktów w backlogu produktu i usunąć funkcjonalności, które nie są kluczowe lub mogą być stworzone później. To wyrówna straty w kontrakcie T&M (Time & Materials) spowodowane wprowadzaniem nowych funkcji i zmian.

Z każdym zakończonym sprintem trudność we wprowadzaniu zmian rośnie. Poprawki, które z Twojego punktu widzenia wydają się proste, mogą wymagać znacznych zmian w kodzie, warto więc powierzyć estymację potrzebnych zasobów specjalistom. Jeśli nie spodoba Ci się to, co usłyszysz, lepiej pozostawić rzeczy takimi, jakimi są i kontynuować projekt zgodnie z wcześniejszymi ustaleniami.

Im większy progres w procesie developmentu, tym więcej elementów produktów zostanie stworzonych, przetestowanych i oddanych do użytku. W pewnym momencie możesz zdecydować, że jedna z funkcjonalności nie jest już potrzebna – jednak zasoby zostały już wykorzystane. Oznacza to, że i tak trzeba będzie się rozliczyć za element, który nie zostanie zawarty w finalnej wersji produktu.

Chcesz wiedzieć więcej o tym jak wytwarzamy oprogramowanie? Przeczytaj nasz poradnik na temat developmentu aplikacji na Androida i iOS.

Testowanie

Gdy produkt jest gotowy, czas go przetestować. Moduły opracowane podczas każdego sprintu były już przetestowane, jednak musimy sprawdzić, czy działają poprawnie, gdy są złożone w jeden produkt. Końcowe testy są kluczowe, aby sprawdzić, czy wszystko do siebie pasuje i tworzy zamówiony przez klienta produkt.

Na tym etapie prac wprowadzanie zmian jest niezwykle problematyczne. Dodawanie nowych funkcjonalności czy ekranów do ukończonego, nieprzetestowanego produktu to koszmar z punktu widzenia programistów.

Czas to pieniądz (klienta)

Być może tego nie wiesz (choć ta informacja powinna zostać Ci przekazana), ale wprowadzanie zmian często oznacza, że trzeba “rozpruć” kod i przepisać sporą część, aby poprawić już stworzone i przetestowane elementy. W ekstremalnych przypadkach możesz usłyszeć, że zrobienie tego, o co prosisz, oznacza powrót do fazy wstępnej.

To bezpośrednio przekłada się na koszt i czas. Może się pojawić potrzeba zmian w zespole, a zaplanowane testy się opóźnią. Dodanie nowego specjalisty do teamu też może być konieczne – zwłaszcza, jeżeli zmiany wykraczają poza wcześniej ustalony zakres projektu.

Testy końcowe to faza, w której wprowadzanie jakichkolwiek zmian przekłada się na znaczący wzrost kosztów. Im większe zmiany, tym więcej trzeba zapłacić i dłużej czekać na implementację.

Im wcześniej, tym lepiej…

Na początku drogi otrzymasz estymację projektu. W każdym szanującym się software housie z góry zakłada się, że pojawią się jakieś zmiany lub niespodziewane okoliczności. Szacowanie kosztów zawsze jednak powinno być oparte na zdrowym rozsądku.

Zasady i wartości Agile są otwarte na zmianę w procesie developmentu. Jednak jego przyczynowo-skutkowa natura sprawia, że czas wprowadzania zmian wywołuje określone konsekwencje. We wczesnych stadiach nie są one aż tak istotne. Ale im później padają propozycje, tym wprowadzanie zmian jest bardziej bolesne – zarówno dla developera, jak i dla portfela klienta.

Gdy zbudujesz dom, ciężko jest go rozebrać

W skrócie, zwinne wytwarzanie oprogramowania można porównać do budowy domu. Gdy rozmawia się tylko o pomyśle (faza wstępna) – zmiany są darmowe i proste. Oddanie go do architekta, który wykona projekt, oznacza, że zmiany zdania będą bardziej kosztowne.

Po rozpoczęciu budowy (czyli developmentu) wprowadzanie poprawek wymaga znacznie więcej pracy i materiałów. Na koniec, gdy budynek jest gotowy i zostaje poddany ostatecznemu przeglądowi (faza testów), zmiany wymagają rozbiórki pewnych elementów i stworzenia ich od nowa.