Customer Case – Zarządzanie wymaganiami przy użyciu historyjek użytkownika

1.1.1. Informacja o firmie i sytuacja rynkowa

Firma zajmująca się realizacją projektów przenoszących funkcjonalność systemów bankowych do aplikacji uruchamianych na urządzeniach mobilnych, takich jak tablety czy smartfony. Organizacja zatrudnia mały zespół 8 osób, które są bezpośrednio odpowiedzialne za budowanie aplikacji i podejmowanie wszelkich związanych z technologią decyzji. Zespół nie posiada wcześniejszych doświadczeń z formalnymi procesami wytwarzania oprogramowani i pragnie zachować obecną kulturę pracy wynikającą z niskiego poziomu dojrzałości organizacyjnej.

Firma zyskuje duża popularność na lokalnym i globalnym rynku z powodu innowacyjnego podejścia do projektowania aplikacji mobilnych, który zapewnia wysoki poziom intuicyjności oraz użyteczności rozwiązań.

1.1.2. Potrzeba

Organizacja na chwile obecną przeznacza ponad 30% dochodu na inwestycje w rozwój produktów i usprawnienie produktywności. Mimo swobodnego podejścia do realizacji projektów, firma stanęła przed wyzwaniem szacowania swoich projektów w taki sposób, by móc dostarczyć klientowi końcowemu rzetelne informacje na temat czasu realizacji projektu oraz jego kosztów. Zespoły pracujące w tym przedsiębiorstwie nigdy wcześniej nie planowały pracy w sposób formalny oraz nie dokumentowały wymagań. Dotychczasowe podejście koncentrowało się głównie na reagowaniu na zmiany i defekty zgłaszane przez klientów

Rozbudowa firmy oraz zwiększenie liczności zespołów wymuszają na kierownictwie wprowadzenie pewnych mechanizmów kontroli postępu oraz planowania, jednocześnie jednak firma chce uniknąć zbędnej formalizacji procesów zostawiając członkom projektów samodzielną organizację pracy.

1.1.3. Rozwiązanie

Firma zdecydowała się wprowadzić praktyki związane z programowaniem ekstremalnym w celu usprawnienia aspektów procesu związanego z wymaganiami oraz planowania. Wdrożono koncepcję historyjek użytkownika oraz metodę estymacji przy użyciu punktów historyjek (ang. User Story Points). Miało to na celu określenie potencjalnego zakresu projektu w sposób nieobciążający zbytnio zespołu projektowego a umożliwiający estymowanie i zarządzanie zakresem oraz czasem.

W każdym realizowanym projekcie historyjki były identyfikowane i uszczegóławiane w sposób iteracyjny, co pozwalało na zebranie pełnej dokumentacji projektowej oraz koncentrację zespołu na zadaniach, które dają klientowi największą wartość biznesową.

W początkowych etapach wdrożenia organizacja miała problemy z zaadaptowanie się na potrzeby szacowania metodą punktów historyjek użytkownika. Członkowie zespołów nie rozumieli ich miary w przeciwieństwie do dni roboczych, jednakże szybko zorientowano się, że znając efektywność pracy oraz wartość punktów dla wszystkich historyjek, można realizować szacowanie tą metodą. Zespół bardzo szybko przywykł do stosowania historyjek użytkownika jako formy specyfikowania wymagań, dzięki wewnętrznemu przekonaniu, że celem zmiany podejścia jest lepsza organizacja pracy i większa czytelność zakresu do realizacji.

Po zakończonym sukcesem wdrożeniem koncepcji historyjek użytkownika oraz estymacji, podjęto się wprowadzenia mechanizmów planowania w oparciu o praktykę „Planning Game”. Organizacja wprowadziła u siebie pojęcie iteracji, wydań oraz dnia roboczego. W jednym z zespołów, który dokonał dokumentowania wymagań przy użyciu historyjek, poproszono o rozpisanie przy udziale klienta oczekiwanego na kolejne wydania oprogramowania planowane co 3 miesiące zakresu. Przy planowaniu wydań, kierowano się przede wszystkim celem klienta oraz korzyściami dla niego. Każde wydanie miało przypisany osobny cel biznesowy – istotny z perspektywy klienta. Po odpowiednim wyznaczeniu celów podjęto decyzję o dokładniejszym rozbiciu wydań na iteracje trwające 30 dni, których cele także zakresu określane przez klienta. Istotną rolę w planowanie odegrała interakcja i współpraca klienta z zespołem realizującym prace. Pozwoliło to na lepsze zrozumienie obu stron i oparcie mechanizmów planowania na doświadczeniu i merytoryce. Dzięki pracy podczas pierwszego wydania i wyciągniętym wnioskom, zespół określił współczynnik produktywności (ang. velicity) umożliwiający określenie, ile pracy zespół jest w stanie wykonać podczas jednej iteracji. Pozwoliło to również szacować czas realizacji całości projektów. Organizacja doszła do wniosku, że w przypadku współczynnika produktywności należy uwzględnić fakt, iż jest on zmienny i należy monitorować jego aktualną wartość, tak by liczba punktów nie zmieniała się z upływem czasu.

Na ostatnim etapie planowania zespół dokonywał podziału pojedynczych historyjek na zadania, których wielkość nie przekraczała 8 godzin pracy. Czynność ta odbywała się już bez udziału klienta.

W chwili obecnej, wszystkie omawiane procesy zostały zautomatyzowane przy pomocy narzędzi wspierających zarządzanie w zespołach zwinnych.

1.1.4. Zyski

Rozwiązując swoje problemy biznesowe związane z wymaganiami, organizacja zainteresowała się obszarem metodyk zwinnych. Realizując swoje cele, firma wdrożyła zarządzanie w obszarze wymagań oraz ich planowania przy użyciu niezbyt sformalizowanego podejścia, jakim są historyjki użytkownika. Firma wprowadziła ponadto kilka praktyk pochodzących z XP oraz Scrum, które to podejścia są obecnie wdrażane w organizacji w pełnej wersji .

Do najważniejszych korzyści zrealizowanego rozwiązania można zaliczyć:

  • Udokumentowanie wymagań w postaci rejestru produktowego
  • Możliwość dokładnego szacowania przez użycie Planning Poker
  • Możliwość przyrostowego i adaptacyjnego planowania w projektach
  • Wzrost wartości biznesowej wynikającej z tworzonych produktów dla klienta końcowego
  • Utrzymano niezależność zespołów mimo wprowadzenia mechanizmów planowania pracy