Jak wykorzystać zwinne metodologie w projektach biznesowych?

Autorki testu:
Katarzyna Jaśniewicz - Product Menedżerka w Unit4 Polska,
Agnieszka Żebrowska - Engineering Manager Unit4 Polska

Historia użytkownika, jako sposób na osiągnięcie pozytywnych doświadczeń uczestników projektów

Zwinne zarządzanie projektami w IT to standard wykorzystywany od wielu lat w firmach produkujących oprogramowanie. Sprawdzona efektywność kusi też inne branże, ze względu na możliwość osiągnięcia korzyści, takich jak: krótszy czas realizacji projektów, przyspieszenie dostarczenia pierwszych rezultatów dla użytkowników, możliwość weryfikacji szczegółowych potrzeb odbiorców wraz z możliwością iteracyjnego dostosowania produktu lub usługi do dynamicznie zmieniających się potrzeb organizacji.

Jakie elementy metodologii zwinnych (z angielskiego: agile) warto zaadaptować w projektach biznesowych, również w tych, które nie dotyczą oprogramowania?

Od czego zaczynamy?

Metodologia tworzenia oprogramowania rozpoczyna się od wybadania oczekiwanych rezultatów. A więc przystępując do nowego projektu,  na wstępie warto znaleźć odpowiedź na pytanie „Co chcemy osiągnąć?”. Uzyskane informacje pozwolą przedstawić projekt w firmie oraz zweryfikować z zarządem lub dyrektorem działu biznesowe efekty, które spodziewamy się przynieść do organizacji.

W kolejnym kroku należy zająć się zagadnieniem „Kto jest adresatem rozwiązania?”. Niezwykle ważne jest zdefiniowanie osób lub ról uczestniczących w procesie oraz wybranie wśród nich kluczowych użytkowników i odbiorców projektowanych rozwiązań i usług. Kluczowy, w tym wypadku oznacza osoby-role, dzięki którym zrealizujemy oczekiwane efekty.

Następny etap, który niewątpliwie polega na współpracy z adresatami projektowanego rozwiązania, to diagnoza potrzeb użytkowników. Teraz pytamy odbiorców projektowanego produktu lub usługi o potrzeby, oczekiwania i problemy, z jakimi mierzą się na co dzień. 

Warto podkreślić, że użycie nielubianego przez niektórych słowa „problem”, w tym przypadku jest newralgiczne. Bowiem jego zdefiniowanie wiąże się ze zrozumienie przyczyny złych doświadczeń lub złych wyników i pozwoli  opracować najważniejsze potrzeby użytkownika, które wyeliminują blokery i dotychczasowe uciążliwości.

Wynik diagnozy potrzeb warto spisać w postaci historii użytkowników, czyli tzw. user stories, niezwykle przydatnego narzędzia metodyk zwinnych we wdrożeniach i produkcji oprogramowania.

Czym jest user story? Metodyka wytwarzania oprogramowanie

User stories są narzędziem BDD (behaviour driven development), które pozwala na poznanie potrzeb i oczekiwań biznesu oraz stworzenie oprogramowania spełniającego te założenia. Struktura pojedynczej historii jest bardzo prosta, ponieważ opiera się na trzech pytaniach: Kto? Co? Dlaczego? 

W ten sposób przedstawiamy użytkownika, funkcjonalność, jakiej potrzebuje oraz korzyści z niej wynikające. W teorii definiowanie historii użytkownika wygląda prosto, w praktyce, podczas ustalania user story, należy przestrzegać pewnych zasad.

Zasada 3xC

Conversation (dyskusja), Card (karta), Confirmation (Zatwierdzenie) – to trzy przewodnie tematy w budowaniu dobrego user story.

Pierwsze C, czyli dyskusja.. Jest to rozmowa z kluczowymi adresatami rozwiązania, ktora ma nam pokazać, czego naprawdę potrzebujemy. Warto podkreślić, że w praktyce jest to jedno z trudniejszych zadań, ponieważ wynika z przyzwyczajenia do tradycyjnego sposobu zarządzania projektami, opierającego się trochę na zasadzie ograniczonego zaufania. Uczestnicy projektów są przyzwyczajeni, że wszystko trzeba mieć na papierze, w e-mailu lub w innej formie, która zapewni im tzw. „podkładkę”. Trudno się rozmawia o tym, co jest do zrobienia, dlatego wolą tworzyć specyfikację i spisywać wymagania w postaci listy. Metodą na przełamanie tych obaw i przyzwyczajeń są „drugie i trzecie C”.

Karta, czyli „drugie C” to lakoniczny opis funkcjonalności, której oczekuje kluczowy użytkownik. Zawiera minimum informacji, pozwalającej stwierdzić, co należy zrobić. Karta może być stworzona w postaci papierowego kartonika lub elektronicznego odpowiednika kartonika.

Zbiór takich kart znakomicie się sprawdza podczas planowania prac w projekcie, ustalania kolejności i priorytetów.

„Trzecie C”, zatwierdzenie. Jest zorientowane na przyszłe testy rozwiązania i polega na zdefiniowaniu kryteriów akceptacyjnych. Są one naturalnym domknięciem konwersacji z klientem – adresatem rozwiązania. Z praktyki wynika, że maksymalną liczbą kryteriów akceptacyjnych dla jednej historii jest 10 (najlepiej się wówczas pracuje). Jeżeli osiągniemy ten limit, historię należy podzielić na mniejsze części.

Jakie powinny być kryteria akceptacyjne?

Na pewno muszą być konkretne, czyli możliwe do przetestowania i udzielenia jednoznacznej odpowiedzi – spełnione lub niespełnione. Przykładowo, historia, w której napiszemy, że aplikacja powinna działać szybko, nie przyniesie dobrego rezultatu, ponieważ określenie „szybko” może oznaczać co innego w zależności od konkretnego odbiorcy. Natomiast, jeżeli kryterium zdefiniujemy przy użyciu konkretnego miernika, np. „ładowanie formularza X nie powinno zająć więcej niż 3 sekundy” – wtedy możemy ten czas zmierzyć i jednoznacznie określić, czy spełniono kryterium odbioru.

Czas i koszty projektu

Niezwykle istotnymi aspektami każdego projektu są: czas trwania oraz związane z nim bezpośrednio koszty. Projekt oparty o prawidłowo zbudowane historie użytkowników ułatwia oszacowanie tych wskaźników.

Oszacowanie czasu i zasobów potrzebnych do realizacji zestawu historii ułatwi zastosowaniu takich zasad, jak:

• Ograniczenie wielkości (złożoności) pojedynczej historii

• Niezależność historyjek

• Tworzenie wartościowych user stories.

Ograniczona wielkość pojedynczej historii sprzyja szybkiej estymacji czasu i określeniu kompetencji niezbędnych do jej realizacji. 

Historie warto opisać w taki sposób, aby w poczuciu zespołu były uważane za krótkie. Dzięki temu o wiele łatwiej jest oszacować harmonogram projektu i monitorować jego realizacje oraz szybko interweniować w przypadku opóźnienia.

Dobrze napisane historie powinny być niezależne, a to oznacza, że możemy je realizować w dowolnej kolejności. Takie podejście bardzo ułatwia planowanie pracy, w szczególności ustalanie priorytetów. Zależne od siebie historie komplikują proces szacowania czasu i zasobów potrzebnych na ich realizacje.

To, czy dana historia jest wartościowa, czy nie, może zostać różnie ocenione przez różne osoby. Dla użytkowników biznesowych miernikiem wartości może być wygląd interfejsu użytkownika. Dla zespołów technicznych wartościowe będą user stories opisujące aspekty technologiczne. Z punktu widzenia osoby prowadzącej projekt lub właściciela projektowanego produktu oba aspekty są interesujące i wartościowe, dlatego najlepsze historie pisane są przez Właściciela Produktu, z jego perspektywy.

Dynamiczne zmiany kierunków rozwoju firm i oczekiwanie szybkich efektów tych zmian to obecnie rynkowa rzeczywistość. Organizacje szukają wyróżników i przewag konkurencyjnych, w wyniku których będą świadczyć usługi lub oferować produkty lepiej i szybciej niż konkurenci. Metodologia i techniki programowania zwinnego a sprzyjają osiąganiu szybkich efektów, co buduje ich atrakcyjność niezależnie od branży, w jakiej działa firma.