Wspólna platforma technologiczna - dlaczego ją tworzymy?

PSI, jako dostawca oprogramowania dla różnych gałęzi przemysłu, dysponuje szerokim portfolio produktów. W związku z faktem, iż działy naszej firmy obsługujące konkretne branże mają dużą autonomię, a wymiana informacji między nimi nie była systematyczna, technologie użyte do stworzenia tych produktów nie były w żaden sposób współdzielone. Efektem takiej sytuacji było programowanie podstawowych funkcji systemu takich jak biblioteki graficzne, autoryzacja, zarządzanie profilami użytkowników, czy komunikacja z bazami danych osobno w każdym produkcie.

W roku 2006 po raz pierwszy w PSI pojawiła się koncepcja stworzenia wspólnej bazy technologicznej dla możliwie największej liczby produktów naszej firmy o nazwie PJF (od ang. PSI Java Framework). Ze względu na dużą różnorodność produktów PSI jest to długofalowy proces, rozłożony na lata i trwający do dzisiaj. Jednym z kluczowych jego elementów jest reorganizacja części firmy odpowiadających za tworzenie oprogramowania. W wyniku tej reorganizacji powołano do życia następujące ciała:

•    AK-Technik - grupa zrzeszająca dyrektorów ds. rozwoju oprogramowania z poszczególnych jednostek. Odpowiada za przydzielanie środków finansowych na przedsięwzięcia związane z rozwojem PJF.
•    Communities, czyli grupy reprezentujące specjalistów z różnych obszarów rozwoju oprogramowania jednostek (np. GUI – interfejsy użytkownika, BASE – serwery aplikacji, czy TOOLS - środowisko pracy programistów i konsultantów).
•    Dział Rozwoju Oprogramowania w PSI Polska (w skrócie: R&D) to specjalna jednostka naszej firmy zlokalizowana w Poznaniu, która odpowiada za rozwój PJF.
•    Zespół Utrzymania Oprogramowania w PSI Polska (w skrócie: PJF Maintenance) to specjalna grupa w ramach Działu Rozwoju Oprogramowania w PSI Polska odpowiedzialna za bieżące utrzymanie PJF (tzn. już wydanych jego wersji).

Proces wytwarzania oprogramowania

Taki model wytwarzania oprogramowania miał zapewnić reprezentację wszystkich zainteresowanych jednostek oraz kontrolę wydatków związanych z rozwojem oprogramowania „podstawowego” w PSI. Czym oryginalnie był „projekt” realizowany dla AK-Technik?

1.    Pracownik jednostki reprezentowanej w Community zgłasza potrzebę rozwoju komponentu platformy PJF.
2.    Community zbierając się na spotkaniu ocenia, czy propozycja jest jego zdaniem sensowna.
3.    W przypadku pozytywnej opinii Community, autor wymagania (lub PSI Polska w jego imieniu) występuje o przydzielenie finansowania z AK-Technik na napisanie specyfikacji wymagań nowego projektu.
4.    AK-Technik na zebraniu kwartalnym (z udziałem Zarządu) przydziela środki na napisanie specyfikacji.
5.    R&D pisze specyfikację i przedstawia Community do akceptacji.
6.    Community akceptuje specyfikację oraz decyduje, czy można złożyć ofertę na realizację.
7.    W przypadku akceptacji specyfikacji Community, R&D przedstawia na Community ofertę na realizację. Realizacja obejmuje: specyfikację testów, implementację oraz wydanie oprogramowania, czasem również dokument opisujący architekturę rozwiązania.
8.    Po akceptacji Community, oferta na realizację jest prezentowana AK-Technik na spotkaniu kwartalnym z udziałem Zarządu.
9.    W przypadku akceptacji Zarządu, projekt trafia do realizacji. Specyfikacja testów jest przedkładana Community i to na jej podstawie odbywa się odbiór projektu.
10.    Community akceptuje projekt.
11.    Rezultaty projektu są integrowane z pozostałymi częściami platformy przez PJF Maintenance.

Dlaczego nasze podejście wymagało zmiany?

Wydawałoby się, że opisany proces jest bardzo efektywny. Występuje w nim zarówno kontrola kosztów, jak i jakości wykonanych prac. Osoba zgłaszająca potrzebę jest reprezentowana w Community, kryteria odbioru są dobrze opisane, a celowość projektu potwierdzona (podwójnie) przez Zarząd firmy.

Niestety, wraz z rozwojem kolejnych elementów PJF (zwanych dalej komponentami) pojawiły się problemy. Warto kilka z nich opisać szerzej, ponieważ mogą one pojawić się w każdej organizacji tworzącej oprogramowanie, zwłaszcza na podstawowym poziomie (tzw. framework).

1.    Bardzo długi czas między zgłoszeniem potrzeby a jej faktycznym zaspokojeniem. Jak widać z opisu powyżej, same formalności związane z rozpoczęciem (lub nie) projektu mogą zająć do 3 miesięcy, a mówimy tutaj tylko o specyfikacji. W najgorszym przypadku klient (a raczej produkt/projekt zgłaszającej jednostki) może czekać ponad rok na prostą funkcjonalność.

2.    Kryteria akceptacji oddalone od potrzeb rynkowych. Wyniki projektu były akceptowane lub nie przez całe Community na bazie dostarczonej przez zespół specyfikacji testów. Specyfikacja ta była pisana bez udziału klienta, więc nie pokazywała realnych przypadków użycia. Dodatkowo, osoba faktycznie zgłaszająca potrzebę miała tylko jednego reprezentanta w Community i jej wizja mogła zostać niezrozumiana przez pozostałych członków grupy i przez to nieodzwierciedlona w specyfikacji testów.

3.    Brak obowiązkowego połączenia z konkretnym produktem/projektem. Projekty Community były rozpoczynane bez bezpośredniego związku czasowego z działaniami PSI odnoszącymi się do konkretnych klientów. Prowadziło to do sytuacji, gdy projekt Community kończył się długo po zakończeniu projektu, który potrzebował implementowanej tam funkcjonalności. Długofalową konsekwencją takiej sytuacji było ignorowanie przez niektóre projekty/zespoły Community („i tak nie dowiozą nam tego na czas”) i tworzenie na własną rękę oprogramowania, które mogłoby zostać częścią PJF. Powodowało to także demotywację zespołu tworzącego PJF („robimy rzeczy, których nikt nie używa”).

4.    Brak całościowej wizji platformy PJF jako produktu. Przez długi czas platforma PJF była postrzegana (zarówno przez jej twórców, jak i użytkowników) jako luźny zbiór komponentów, które można rozwijać osobno i wdrażać pojedynczo w projektach. Z biegem czasu jednak, okazało się, że kolejne projekty Community dotyczą zmian w kilku komponentach na raz (w dodatku znajdujących się pod kontrolą różnych Communities). Komunikacja między kilkoma Communities była właściwie niemożliwa (spotykały się one w różnych terminach), przez co projekty przedłużały się o kolejne miesiące. Oprócz tego, w różnych Communities zgłaszano wzajemnie sprzeczne wymagania, których nie było jak skoordynować.

Rozwiązanie - PJF Backlog

Problemy związane z procesem wytwarzania oprogramowania były dla nas motywacją do poszukiwania nowych rozwiązań. W tym celu zaczęliśmy najpierw doszkalać się, aby zdobyć wiedzę niezbędną do przeprowadzenia istotnej zmiany. Fundamentalne znaczenie miał dla nas wyjazd na konferencję Agile by Example w 2014 roku, gdzie trzy wykłady ostatecznie zainspirowały nas do działania:

•    Bob Marshall, którego prezentacja zawierała fundamentalne zdanie, warte przytoczenia w oryginale: „Software development is all about attending people’s needs”. Nasza interpretacja tego stwierdzenia skierowała nas w stronę zajęcia się przede wszystkim wymaganiami. Wszystkie inne elementy procesu wytwarzania oprogramowania są pochodnymi tego, w jaki sposób staramy się zaspokoić potrzeby klientów. Oczywiście, nie oznacza to, że bierzemy „na warsztat” każde zgłoszenie od razu, ale cały proces musi unaoczniać to, gdzie aktualnie znajdują się konkretne wymagania.

•    Mary Poppendieck, która pokazała nam, że ulubiona przez wszystkich menedżerów metryka kosztu wytworzenia oprogramowania jest jedynie pochodną wcześniejszych działań. Aby uzyskać istotną poprawę jakości implementowanych rozwiązań, należy przede wszystkim śledzić czas, w którym klient otrzymuje zauważalną wartość. Przekładając to na prostszy język: jeśli dostajemy coś szybko, jesteśmy bardziej skłonni za to zapłacić.

•    David Hussman, który doradził stworzenie najlżejszego możliwego procesu pokazując przykład (wymyślonej przez siebie nieco ironicznie) metodyki NonBan. Istotne dla nas było tutaj, że nie musimy wcale od razu wymyślać kombajnu obsługującego wszystkie przypadki, a spróbować rozwiązać najbardziej bolesne dla nas problemy.

Wszystko zaczyna się od zarządzania wymaganiami

Z taką dawką wiedzy i inspiracji zabraliśmy się do roboty. Podczas kilku kolejnych burz mózgów pojawił się wreszcie wymarzony koncept, który nazwaliśmy PJF Backlog. Oto jego struktura i główne założenia.

Wymaganie jest głównym obiektem, który przechowujemy w Backlogu. Wszystkie pozostałe obiekty pełnią wobec niego służebną rolę. Dodatkowo, wymaganie dzielimy na ogólne (dalej zwane epikami, właściwym słowem w języku polskim byłby tak naprawdę epos) oraz szczegółowe (dalej zwane historiami [ang. stories]). Jeden epik może zawierać wiele historii, a także być powiązany z innymi epikami. Każdy epik oraz historia zawiera oczywiście tytuł, opis, priorytet, osobę odpowiedzialną i inne informacje, które są niezbędne przy jego przetwarzaniu. Najważniejszą jednak cechą obu tych typów wymagań jest status. Status ten oznacza, na jakim etapie realizacji jest dane wymaganie. W PSI zdefiniowaliśmy następujące statusy:

1.    Backlog. Ten status uzyskują wszystkie nowe wymagania.
2.    Analysis. Wymaganie zostało przekazane do przeanalizowania osobie, która ma największe kompetencje w danym zakresie. Wynikiem analizy może być:
a.    Uszczegółowienie opisu wymagania.
b.    Podział wymagania na mniejsze, łatwiejsze do zarządzania obiekty oraz przypisanie go do komponentów PJF, w których miało by ono być potencjalnie zaimplementowane.
c.    Odrzucenie wymagania. Odrzucone wymagania trafiają z powrotem do statusu Backlog.
3.    Specified and confirmed. W tym statusie znajdują się wymagania, których uszczegółowiona treść odpowiada oczekiwaniom osoby zgłaszającej.
4.    Selected for development. Status ten oznacza wymagania, dla których uzyskano budżet na implementację.
5.    In Progress. W tym statusie znajdują się wszystkie wymagania, których implementacja jest w trakcie.
6.    Done. Wymagania w tym statusie zostały zaimplementowane i odebrane przez ich twórcę (lub osobę przez niego wyznaczoną).

Kluczową sprawą przy przejściach statusów jest zawsze osoba odpowiedzialna za dane wymagania. O ile autor wymagania nie zmienia się z reguły przez cały czas jego życia, osoba odpowiedzialna może być różna np. na etapie analizy i implementacji. Nie zmienia to jednak faktu, że osoba aktualnie odpowiedzialna jest zobowiązana do reagowania na komentarze / życzenia / pytania osób zainteresowanych realizacją wymagania.

Prostota i przejrzystość w backlogu

Projektując nasze rozwiązanie położyliśmy maksymalny nacisk na jego maksymalną prostotę i przejrzystość. W momencie powstawania PJF Backloga posiadaliśmy już system JIRA z dodatkiem Agile, był on więc naturalnym środowiskiem do zaimplementowania naszej koncepcji. Aby stworzyć nasz Backlog użyliśmy następujących funkcjonalności tego systemu:

JIRA jako łącznik Backloga z projektami

PSI Polska od wielu lat konsekwentnie używa JIRA jako podstawowego systemu do zarządzania projektami. Oznacza to, że prace programistyczne, testowanie naszych systemów, wsparcie klientów oraz nasze wewnętrzne zadania są zdefiniowane w JIRA. Po wdrożeniu PJF Backloga stopniowo łączyliśmy zadania opisujące wymagania z zadaniami z wewnętrznych projektów programistycznych oraz opisujących specyfikację testów manualnych oprogramowania. Oczywiście, w przypadku, gdy do zrealizowania wymagania potrzebny jest na przykład nowy serwer, możemy także połączyć zadanie je reprezentujące ze zgłoszeniem w naszym wewnętrznym helpdesku IT. Aby ułatwić pracę użytkownikom PJF Backloga, napisaliśmy kilka dodatkowych zapytań języka filtrów JIRA (tzw. JQL), które potrafią przeszukiwać zadania powiązane z zawartością dowolnego filtra.

Własna platforma do zbierania wymagań – co nam daje?

Dzięki prostocie rozwiązania i konsekwencji we wdrażaniu go PJF Backlog jest obecnie jedyną platformą do zarządzania wymaganiami dla naszej platformy. Obecnie znajduje się w nim prawie 3100 wymagań, które są na różnym etapie realizacji. Pracujące z Backlogiem osoby wyróżniają przede wszystkim następujące korzyści płynące z jego użycia:

•    Jedno miejsce zbierania wymagań. Każdy użytkownik i programista platformy wie, na jakim etapie są prace i jakie cele są aktualnie realizowane. Przed powstaniem Backloga wiedza ta była rozproszona w kilku(nastu) miejscach, często trudnych do znalezienia lub niedostępnych dla wszystkich.
•    Perspektywa użytkownika. W poprzednim modelu, wymagania były zgłaszane dla konkretnego komponentu PJF. Obecnie, to analityk decyduje o przydziale wymagania do jednego lub więcej komponentów i podział ten jest absolutnie wtórny wobec podziału funkcjonalnego wymagania (tj. wydzielenia najważniejszych i mniej ważnych funkcjonalności platformy, które muszą zostać dostarczone).
•    Transparentność procesu. Jeśli wymaganie nie jest przetwarzane lub zostaje odrzucone, użytkownik może w każdej chwili stwierdzić, dlaczego tak się stało, bez potrzeby wysyłania maili lub osobistego pytania wielu zaangażowanych osób.
•    Szybka komunikacja. System JIRA sprzyja komunikacji (dodanie swoich uwag do wymagania jest bardzo proste) oraz wymianie wiedzy, wszyscy użytkownicy widzą bowiem zmiany dokonane w wymaganiach i mogą wyrazić swoją opinię, przekazać istotne szczegóły, bądź zaprotestować przeciwko błędnej decyzji.

PJF Backlog cały czas rośnie w tempie kilkudziesięciu wymagań miesięcznie i rozwija się (dodawane są nowe funkcjonalności). Dzięki temu prostemu rozwiązaniu bazującemu na nowoczesnych praktykach zarządzania produktem jesteśmy w stanie szybciej i efektywniej reagować na wymagania naszych klientów, choć nasza podróż ku naprawdę zwinnemu procesowi ciągle trwa. Czas zatem trochę pozarządzać wymaganiami!

Tekst ten jest rozwinięciem prezentacji z konferencji Agile by Example 2016 poprowadzonej przez Wojciecha Burasa i Bartosza Zbierajewskiego – znajduje się ona pod adresem www.youtube.com/watch.