Projekty IT, w których Agile to za mało

Bank Gospodarstwa Krajowego to w wielu aspektach instytucja zbliżona do innych banków. Ma rozbudowany pion technologiczny, którego częścią jest departament rozwoju systemów. Jak w wielu innych instytucjach finansowych, jednostka odpowiada za terminowe dostarczanie nowych i zmodyfikowanych aplikacji, które wspierają procesy biznesowe.

Jednak Bank Gospodarstwa Krajowego ma nieco inną misję - wsparcie rozwoju gospodarczego i społecznego. Jednym z ważnych obszarów działalności BGK jest np. zarządzanie funduszami rządowymi i unijnymi, które trafiają do przedsiębiorstw, samorządów i osób indywidualnych w postaci programów pomocowych. Często te programy są wdrażane w ściśle określonych terminach ustawowych, których Bank musi dotrzymać. Oznacza to także sztywne terminy dostarczania systemów informatycznych wspierających takie działania. 

Analiza wymagań

Wytwarzanie aplikacji w BGK - jak w przeważającej większości innych organizacji - poprzedzone jest zbieraniem i szczegółową analizą wymagań. Wykonuje ją zespół analityków we współpracy z departamentami odpowiedzialnymi za rozwój biznesu, które później będą na co dzień korzystać z  tworzonych systemów. Aby zachować spójność w zbieraniu wymagań, stosujemy narzędzia wspierające tę pracę. Tym, czym różni BGK od innych banków jest fakt, iż część z tych oczekiwań biznesowych wynika wprost z zapisów ustawy lub rozporządzenia, w którym bank został wymieniony. Nasi analitycy muszą umieć czytać skomplikowany żargon prawniczy, bo tym językiem opisane są wymagania systemowe. Ten etap jest najtrudniejszy i musi uwzględniać także wymagania użytkowników.

Aby sprostać tym wyzwaniom połączyliśmy dwie metodyki projektowe: PRINCE2 i Agile. Zaadaptowaliśmy wiele elementów z podejścia zwinnego. Wszystkie wymagania muszą mieć określone kryterium odbioru (ang. Definition of Done). Dodatkowo dzielimy je na szczegółowe zadania techniczne, dla których także piszemy to kryterium. W prace analityczne bardzo mocno angażujemy stronę biznesową - od początku jest współautorem systemu, a nie jedynie odbiorcą. Współpraca nie kończy się jednak na wymaganiach. 

Wytwarzanie

Na tym etapie najmocniej korzystamy z metodyki zwinnej. Mimo klasycznej metodyki projektowej narzuconej przez organizację pracujemy w krótkich - maksymalnie dwutygodniowych - cyklach. Na początku każdego etapu organizujemy spotkanie, podczas którego wspólnie z odbiorcami biznesowymi omawiamy prace na najbliższe dwa tygodnie. Wyznaczamy zadania dla każdego członka zespołu (także dla biznesowych uczestników projektu), opisujemy ich szczegóły i oczekiwane efekty. Na koniec tego etapu podsumowujemy, co zostało zrealizowane. Nie jest to SCRUM, choć wydaje się bardzo podobny. Nie wykonujemy wdrożenia na koniec każdego etapu. Nie byłoby to możliwe, gdyż wdrożenie w takiej organizacji jak nasza jest działaniem trwającym jakiś czas, wymagającym przestrzegania z góry określonych procedur.

Zgodnie z rekomendacjami audytu wewnętrznego, KNF oraz najlepszymi praktykami wytwarzania oprogramowania w dużych organizacjach, działamy w środowiskach odseparowanych od siebie. Zatem proces wdrożenia oparty jest o cykliczny release, którego zakres ustalany jest dla całości prac programistycznych, jakie prowadzone są w Departamencie. Zaczerpnięte z metodyk zwinnych pomysły pozwalają nam jednak szybko reagować na zmieniające się otoczenie biznesowe i dostosować finalny produkt do oczekiwań naszych interesariuszy - nawet, jeśli nie zostały one wyrażone na początku projektu.

Takie podejście okazuje się ogromnie ważne szczególnie, gdy pracujemy na projektowanych dopiero aktach prawnych. A jak wiemy, od projektu ustawy do jej finalnej wersji wiele może się zmienić. Aby przygotować rozwiązanie w oczekiwanym terminie, bardzo często zaczynamy prace jeszcze na etapie konsultacji ustaw. W przeciwnym wypadku nie mielibyśmy żadnych szans na doścignięcie terminów ustawowych.

Jakość

Po zakończeniu etapu lub całości projektu pałeczkę lidera przejmują nasi testerzy, którzy doskonale znają wymagania biznesowe i akty prawne, z których te wymagania wynikają. Bez tego przeprowadzenie kompletnych testów użytkowania aplikacji nie byłoby możliwe. Tutaj także przyszły nam z pomocą metodyki zwinne. Planujemy zakres i termin wykonania testów zgodnie z wcześniej ustalonym harmonogramem projektu, jednak w trakcie ich realizacji korzystamy znów z planowanych krótkich etapów, w których biorą udział wszyscy członkowie zespołu projektowego. Takie podejście pozwala nam wprowadzać poprawki do aplikacji na bieżąco,  a także na bieżąco pokazywać stronie biznesowej realizowane zmiany i uzyskiwać jej akceptację.

W banku realizujemy także formalne testy UAT (testy użytkownika). Dzięki zastosowaniu bardziej zwinnego i otwartego podejścia do testowania wewnętrznego są one dużo prostsze i kończą się szybciej niż w tradycyjnych metodykach twardych. Dostarczony w ten sposób produkt jest lepszy, bardziej odpowiada użytkownikom. Wszyscy, którzy realizowali projekt dla wymagającego odbiorcy biznesowego wiedzą, jak ważne jest, aby utożsamiał się on z powstającym produktem i był z niego zadowolony. Współpraca strony biznesowej na każdym etapie produkcji oprogramowania gwarantuje ten efekt, a wyzwanie, jakim jest dostarczenie dobrej jakości produktu, staje się osiągalnym celem.

Terminowość

Dostarczenie produktu w terminie - szczególnie krótkim, wymaganym ustawowo - jest największym wyzwaniem naszego departamentu. Tak jak w wielu innych organizacjach pracujemy ciągle nad ulepszaniem procesu wytwórczego, aby temu sprostać. Doświadczeni zarządzający mogliby w tym momencie powiedzieć, że przecież metodyki zwinne powstały właśnie po to, żeby poradzić sobie z takim problemem. Jednak stosowanie ich w przypadku projektów, w których istotny jest zarówno zakres, jak i termin, do końca się nie sprawdza.

Dodatkowym elementem, który utrudnia zadanie, jest konieczność poddania procesu wytwórczego pełnemu audytowi. Z tego powodu bank zdecydował się na zastosowanie metodyki opartej na PRINCE2 na poziomie strategicznym oraz metodyki zwinnej na poziomie wytwarzania poszczególnych elementów kodu. Ktoś mógłby zapytać, czy to w ogóle ma szansę zadziałać. Otóż udało nam się wyciągnąć z obydwu podejść to, co najlepsze. Z jednej strony mamy realny i pełny plan prac, w którym możemy zaznaczyć wszystkie najważniejsze kamienie milowe, a z drugiej strony działamy w bardzo krótkich i kończących się incrementem sprintach, dostarczających realną wartość biznesową. Pamiętamy jednocześnie o wymogach ustawowych, które musimy spełnić. Jest to kombinacja w pewnych aspektach wyjątkowa, ale w ogólnym rozrachunku nie w zupełności inna niż rozwiązania stosowane  w bankach i instytucjach finansowych na całym świecie.