Dane statystyczne dotyczące realizacji projektów o różnej wielkości, z użyciem metodyk zwinnych, wskazują średnio 350% więcej wdrożeń zakończonych sukcesem, w stosunku do podejścia kaskadowego. W kategorii projektów dużych aż 600% więcej wdrożeń Agile kończy się sukcesem w stosunku do standardowych wdrożeń kaskadowych (źródło: CHAOS Report 2015).

Ale czym właściwie jest to podejście Agile, o którym wszyscy mówią, a w naszej dziedzinie BI mało kto stosuje. „Szybsze, lepsze, tańsze”. Piękny slogan, który przez ostatnią dekadę był wykrzykiwany przez czołowych zwolenników tej metodyki. Ten styl pracy przyjął się już głównie w organizacji programowania w systemach transakcyjnych, czy dziedzinach gdzie iteracyjny cykl rozwoju produktu, oraz doskonalenia usługi jest czymś naturalnym. W tych obszarach wdrożenie metodyki wymagało jedynie adaptacji na potrzeby przeniesienia procesów w cyfrową przestrzeń. Nasze BI (Business Intelligence) jest nadal ziemią niczyją, gdzie nieliczni pionierzy starają się „udomowić” tę metodykę. Na szczęście, albo i nieszczęście, korporacyjne departamenty pod natłokiem katastrof projektów realizowanych za pomocą standardowego podejścia a także innych czynników utrudniających ich realizację w kaskadowym modelu coraz przychylniej patrzą na metodyki zwinne.

Zastanówmy się chwilę nad tym, dlaczego tak się dzieje, że popularność zwinnego podejścia nie nadąża w BI za prędkością, z jaką tę popularność zyskuje ono w systemach transakcyjnych. Dla rozwiązań, w których jednym z celów jest prezentacja danych, realizacja tej funkcjonalności ogranicza się do prostego przygotowania kolumny w bazie danych, a następnie zmapowania tej kolumny/wpisu na przygotowane pole we front endzie użytkownika. Puf! I jest. Proste. Szybkie. Skuteczne. I gotowe do szybkiej zmiany, gdyby Klient chciał inaczej w kolejnej iteracji.

Na naszym poletku jest jednak inaczej. Dostarczenie nowego atrybutu w Hurtowni Danych wiąże się z przygotowaniem zazwyczaj kilku/kilkunastu procesów (do ekstrakcji, oczyszczania, integracji, ładowania) i zwymiarowaniem zestawu danych zawierających dany element, który ma finalnie trafić do tej prostej, szybkiej kolumienki wspomnianej powyżej. Cała logika jest pod spodem, i to właśnie ją kształtujemy i ją mamy dostarczyć, gdyż z zasady jest bazą dla każdych kolejnych działań w systemie operującym na danych. Aby uznać obszar danych za kompletny, trzeba z reguły napisać od kilku do kilkudziesięciu nawet jobów/przetwarzań. Istnieje dużo warstw logicznych i architekturalnych do szybkiego zarządzenia i wytworzenia przez zespół pragnący spełnić oczekiwania Klienta. I tymi to właśnie stanowi podstawową trudność w adaptacji metodyk zwinnych -skomplikowana sieć powiązań, którą trzeba metodycznie rozplatać koncepcyjnie, aby finalnie połączyć w funkcjonującą całość.

Z drugiej strony, zalety widoczne na pierwszy rzut oka, o których napiszę dalej, sprawiają, że pojawiają się zespoły pragnące eksperymentować ze zwinnym podejściem. Zespoły, które modyfikują generyczne zwinne podejście, nierzadko tworząc odrobinę bardziej skomplikowane hybrydy, jednakże NIE MNIEJ EFEKTYWNE! W praktyce poprawne zastosowanie metodyki zwinnej w projektach integracji oraz wizualizacji danych powodowało spadek defektów do ZERA, przy zachowaniu stabilnego i częstego wzrostu wartości biznesowej wytwarzanego produktu. Nie wspominając o ograniczeniu budżetu i nakładów pracochłonności ponoszonych podczas standardowego, przestarzałego kaskadowego podejścia (czyli czegoś co zostało wytworzone w 1896).

Dla tych, którzy swoją przygodę z “uzwinnieniem” dopiero rozpoczynają, kilka informacji na temat tego, jak kluczowe problemy kaskadowego podejścia adresuje podejście zwinne.

1. Z czym boryka się podejście tradycyjne: kaskadowe/waterfall?
2. Słaba jakość dostarczanego rozwiązania.
3. Słabo widoczny cel projektu.
4. Zbyt duże ryzyko projektowe.
5. Usztywnione i problemogenne podejście do obsługi zmian.

Jak z tymi problemami radzi sobie podejście zwinne?

1. Jakość się poprawia od pierwszego dnia pracy (…ponieważ testy startują pierwszego dnia pracy.)
2. Cel projektu wizualizuje się już od pierwszego sprintu. Rozwiązanie materializuje się na koniec każdej iteracji/sprintu.
3. Ryzyko jest ograniczane, ponieważ potencjalne problemy są szybko wykrywane. (tzw. Fail-Fast – im szybciej upadniemy, tym szybciej wstaniemy.)
4. Klient jest zadowolony, ponieważ dowolnie realizuje zmiany w trakcie trwania projektu, nie ponosząc dodatkowych, nieprzewidzianych kosztów.

Teraz należy postawić sobie pytanie, nie “czy warto?”, lecz “kiedy wchodzimy na zwinną ścieżkę?”.

Niniejszym artykułem, rozpoczynam cykl poświęcony wdrożeniu zwinnych metodyk do obszaru BI.