Jeszcze o Agile BI

Data: 2015-08-28
Autor: Sebastian Konkol
Jeszcze o Agile BI

W ramach podsumowania mini cyklu o Agile BI, kilka myśli dotyczących praktyki stosowania podejścia agile do projektów BI.

Choć wygląda to na oczywistą oczywistość, aby realizować jakikolwiek projekt w trybie agile, także projekt BI, muszą być zachowane podstawy dla realizacji projektu w tym trybie. Najpoważniejszą „słabością” podejścia agile jest to, że bardzo szybko i bezwzględnie weryfikuje ono uzasadnienie biznesowe dla powoływania projektu do życia. System BI musi być naprawdę potrzebny (czytaj: jego wartość biznesową musi dać się mierzyć), a wiadomo to już przed planowaniem pierwszego przyrostu – czyli po upłynięciu pojedynczych tygodni czasu trwania projektu. Jeśli jednak spełniony jest warunek rzeczywistej potrzeby dla systemu BI, to dalsze uwarunkowania – krótkie czasy realizacji przyrostów, dostarczanie realnej wartości biznesowej przez każdy z nich, zapewnienie stałego zespołu pracującego nad projektem ze stałą „szybkością” – powinny być traktowane bardzo serio. Tak samo poważnie powinny być traktowane zakaz ingerencji w zakres bieżącego przyrostu oraz zobowiązanie do pracy zespołowej, przede wszystkim osób rzeczywiście potrzebujących tego systemu i jego danych.

W trakcie prac nad zakresem przyrostu należy unikać „kuszących” ewolucji user stories w kierunku „zróbmy więcej za jednym zamachem, bo przecież i tak coś w tym dłubiemy”. W efekcie takich ewolucji najczęściej okazuje się, że te „dodatki” są nieprzemyślane i często zaledwie „napomknięte” stanowią wierzchołek góry lodowej. Obsługa takich ewolucji przynosi poważne zaburzenia tempa realizacji przyrostu i może poważnie zagrozić stabilności całego projektu.

Refactoring w projektach agile BI jest bardzo silnym narzędziem. Rozwiązanie budowane w trybie przyrostowym jest z definicji nieoptymalne, a jego docelowa postać – w pełni produkcyjnie eksploatowana – powinna podlegać cyklom refactoringu przed każdym wdrożeniem. Należy przy tym pamiętać, że refactoring – z definicji – nie niesie dodatkowej wartości biznesowej, a jedynie zapewnia usunięcie konsekwencji przyrostowego budowania systemu oraz skutkuje zwykle poprawieniem jego wydajności, a zawsze ułatwieniem jego późniejszego rozwoju.

Podejście agile ma cudowną zdolność do obiektywnego określenia kiedy skończyć projekt – kiedy system jest już “good enough”. Skoro umiemy określić wartość biznesową danego przyrostu, a – przy stałym zespole pracującym nad projektem i ustalonym czasie realizacji przyrostu – znamy koszt realizacji przyrostu, jeśli koszt ten przewyższyłby biznesową wartość wygenerowaną w efekcie takiego przyrostu, to nie ma co tego przyrostu realizować. Właśnie zakończyliśmy projekt.

Piękno podejścia agile do wytwarzania systemów BI wyraża się także jego zdolnością do integracji prac pochodzących z wielu projektów. Jeśli istnieją działania powiązane tematycznie, obszarami realizacji lub w inny sposób merytorycznie, to można przejść do zaawansowanych metod zarządzania procesami wytwórczymi oprogramowania w trybie agile. Zarówno zarządzanie zakresem jak i podejście do testowania mogą integrować wiele projektów.

Bez względu jednak na praktyki, techniki i narzędzia absolutną podstawą dla realizacji każdego projektu agile są ludzie. Jeśli więc naprawdę zależy Wam na skuteczności, od tego wypada zacząć.

Pozostaw komentarz