Agile BI – Backlog

Data: 2015-06-22
Autor: Sebastian Konkol
Agile BI – Backlog

W praktyce projektów realizowanych w trybie agile podstawą dla zarządzania zakresem projektu jest backlog. Ta sama zasada powinna obowiązywać także w przypadku projektów BI realizowanych w tym samym trybie. Jak sformułować backlog projektu agile BI, aby nadawał się on do zarządzania zakresem takiego projektu?

Według moich obserwacji, poszczególne wpisy w inicjalnych wersjach backlogu projektów BI są zwykle na tyle duże, że ich realizacja musi wykraczać poza ramy czasowe pojedynczej iteracji, nawet o rząd wielkości. Wpisy te odzwierciedlają zwykle poszczególne wymagania (np. zapewnić automatyzację jakiegoś raportu albo zapewnić zgodność z innymi raportami). Jeśli backlog ma pełnić swoją funkcję poszczególne jego wpisy powinny być znacznie mniejsze w wymiarze pracochłonności ich realizacji – powinny zostać zdekomponowane.

No tak, ale przecież realizacja każdego elementu backlogu powinna przynosić wymierną wartość biznesową. Dekompozycja musi więc przebiegać tak, aby tę wartość dało się zmierzyć i dostarczyć. Ślepa uliczka? Niezupełnie. W praktyce, sposób pomiaru wartości biznesowej projektu BI jest często zaburzony lub wręcz błędny, o czym pisałem już wcześniej. W dużym skrócie, nie jest prawdą, że dopiero „zapewnienie wszystkiego” tworzy wartość biznesową – prawdą jest, że każdy element integracji danych poprawiający ich jakość i wiarygodność tworzy taką wartość. Materia projektów BI jest w pewnym sensie prosta – istnieje podstawowy schemat analityczny dla realizacji zadań takiego projektu i według tego schematu można dekomponować elementy inicjalnego backlogu.

Schemat analityczny może być następujący. Wychodząc od oryginalnego wymagania, np. definicji raportu, trzeba określić jego strukturę i powody jego tworzenia. Na tej podstawie można określić reguły agregacji danych i wymiary agregacji. To z kolei prowadzi do zrozumienia danych atomowych podlegających agregacji – obiektów opisywanych danymi i sposobów ich identyfikacji, struktury i zawartości wymiarów agregacji oraz listy faktów i algorytmów ich wyliczania. No i, oczywiście, źródeł danych. Na każdym z tych „poziomów” dekompozycji istnieje potencjał budowania wartości biznesowej. Integracja źródła danych i poprawna identyfikacja obiektów analiz, nawet bez umieszczenia ich w strukturze wymiarów analizy, może być traktowana jako źródło „oficjalnych” danych dla wszelkich innych raportów. Podnosi to spójność raportowania, a przez to wiarygodność materiałów wspomagających decyzje biznesowe. Wartość jest oczywista. Jeśli więc uda się zdekomponować inicjalne wymaganie na takie elementy, to dla każdego z nich można mierzyć wartość biznesową, a wysiłek na realizację takich zdekomponowanych elementów ma szanse „zmieścić się” w zakresie jednej iteracji.

Realizacja takiego backlogu polega na wdrażaniu poszczególnych elementów opracowanych na podstawie schematu analitycznego – jeden krok w jednej iteracji. Wiele zagadnień jakości danych (np. spójność identyfikacji, wiarygodność źródeł danych, spójność wymiarów analiz, dodatkowe zależności w raportowaniu i „ręczne” korekty danych zagregowanych) „wychodzi” wtedy w pojedynczej iteracji. Mogą być one od razu adresowane, a dodatkowo budowane jest zrozumienie wiarygodności danych – podstawa dla podjęcia fundamentalnej decyzji w projekcie agile, czy jest już good enough, czy powinniśmy jeszcze pracować, gdyż opłaca się włożyć wysiłek kolejnej iteracji w poprawę tej wiarygodności.

Oczywiście, takie podejście ma swoje wady. Traktowanie każdego wymagania niezależnie prowadzi zwykle do powstawania rozwiązań suboptymalnych. To także jest jednak cecha wszystkich projektów realizowanych w trybie agile, nie zaś wyłącznie projektów BI. Na takie problemy ludzkość wymyśliła jednak refactoring.

Prawda, że proste?

Pozostaw komentarz