Jak zbudować “zwinny wodospad”

W ostatnich wpisach mniej lub bardziej szczegółowo podsumowywałem doświadczenia zebrane z projektów BI. Niezależnie czy mówimy o zespole projektowym, umowach czy podejściu do kwestii rozpoczęcia samego projektu, w efekcie cały projekt wymaga odpowiedniego modelu zarządzania oraz stosowania sprawdzonych praktyk, aby dotrzeć do określonego celu. Projekt BI to przykład projektu, którego efektem jest niewątpliwie oprogramowanie. Dość naturalnym wyborem mógłby zatem być tutaj model wodospadowy: Od analizy wymagań, przez projekt rozwiązania, wytwarzanie, testy, aż po gotowe rozwiązanie. Niestety dynamika projektów BI, nie do końca pozwala na stosowanie takiego podejścia. Rozwiązania business intelligence charakteryzują się bardzo dużą dynamiką zmian, zarówno w obszarze potrzeb, jak również możliwości ich adresowania. Właśnie dlatego bardzo często i chętnie do realizacji projektów BI stosuje się zwinne metody zarządzania. Najbardziej efektywnym wyborem, obok różnych metod zwinnych takich jak Feature Driven Development(FDD), Extreme Programming jest niewątpliwie Scrum. W tym miejscu pojawia się pierwszy z charakterystycznych elementów metodyk zwinnych – manifest. Manifest w odniesieniu do projektów BI wskazuje m.in na:

  • Postawienie nacisku na wykorzystanie danych i informacji, ponad procesami oraz narzędziami
  • Wartość i korzyść biznesową, ponad szczegółową i rozbudowaną dokumentację
  • Współpraca zespołu, ponad formalizmy i umowy (pamiętasz jak wspominałem o kilkukrotnym rozpoczęciu i realizacji projektów bez zbędnych umów  🙂 )
  • Reagowanie na zmiany, ponad plan i założenia

Taka charakterystyka i podejście do projektów BI prowadzi do kilku bardzo istotnych elementów, które należy stosować w każdym projekcie:

  • Najwyższym priorytetem projektu jest realizowanie potrzeb klienta poprzez ciągłe dostarczanie wartościowych informacji
  • Produkty projektu muszą być dostarczane często (max. do kilku tygodni)
  • Rozwiązania muszą skupiać wokół siebie developerów i ludzi biznesu- możliwie najbardziej zmotywowane jednostki, szukające rozwiązań swoich codziennych wyzwań.

Stosując podejście typowo Scrum-owe, należy również wskazać główne role i członków zespołu projektowego, ze względu na przyjętą metodykę, role te mają swoje konkretne nazwy i nieco różnią się od tych roboczo wskazanych przeze mnie w poprzednim wpisie. Jednak w efekcie jest to ten sam zespół projektowy, w którym każdy z członków jest bardzo ważnym jego ogniwem. Zatem w typowym zespole Scrum-owym, mamy:

  • Właściciela produktu(Product Owner)
  • Zespół developerski (Development Team)
  • Scrum Master

Nie chciałbym w tym miejscu opisywać jak działa Scrum, chcę za to dokonać odpowiedniego mapowania charakterystycznych dla projektu BI elementów, osób i działań, na ten właśnie model realizacji projektu. Co zatem charakterystycznego dla BI kryje się za poszczególnymi rolami projektowymi. Zacznę od Scrum Master-a, czyli osoby, która oprócz dbania o wiedzę i stosowanie praktyk Scrum-owych, powinna dysponować  dodatkowo wiedzą i doświadczeniem, które pozwoli skupić działania projektowe na takich aspektach jak jakość danych, scenariusze testowe wytwarzanych rozwiązań czy proces wdrażania nowych wersji oraz poprawek, które są kluczowe i dość charakterystyczne dla projektów BI.

Zespół developerski (Development Team) w przypadku obszaru BI podzielić można na dwie części. Część stałą/podstawową oraz na żądanie/dodatkową. Skąd taki podział? W procesie wytwórczym rozwiązania BI niezbędne są stałe role takie jak:

  • Architekt rozwiązania BI
  • Developerzy: Back-end (bazy danych, etl), Front-end (raporty, wizualizacje)
  • Analityk BI
  • Tester BI

Doraźnie(na żądanie), co nie oznacza, że nie jest to pomoc istotne, potrzebne jest wsparcie w zakresie:

  • Bezpieczeństwa i uwierzytelniania
  • Systemów źródłowych
  • User eXperience

Rola każdej z wymienionych osób, jest nieoceniona w każdym sprincie, jednak w zależności od postępu prac, w każdym sprincie zaangażowanie poszczególnych ról będzie zróżnicowane, zwłaszcza w odniesieniu do ról potrzebnych na żądanie.

Mając zespół projektowy zgodny ze stosowaną metodą zarządzania projektem można przejść do kolejnego elementu, czyli podziału prac, tak aby wpasować się poszczególne sprinty. Czy to coś trudnego? Nie da się ukryć, bo w końcu jak podzielić raporty na kilka części lub co gorsze, w jaki sposób podzielić hurtownię danych na elementy dopasowane do kilkutygodniowych (z reguły 2-4) sprintów? A może Ty masz na to pomysł? Czekam na sugestie i doświadczenia przed publikacją kolejnej części….

 

One Reply to “Jak zbudować “zwinny wodospad””

Comments are closed.