RegułyChaosu

W projektach informatycznych realizowanych w trybie agile wykorzystywane są praktyki pozwalające na skuteczną realizację takich projektów. Pośród praktyk, które mają „najwyższe notowania” występuje TDD (Test-Driven Development). Czy w projektach BI także można stosować taką praktykę?

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?

Odpowiedź w wersji „streszczenia dla kierownictwa”: oczywiście, że tak i daje się tak działać. W tradycyjnej typologii projektów IT, projekty BI (Business Intelligence) postrzegane są jako „ciężkie” – dużo analiz, dużo programowania, dużo infrastruktury, zanim zbudowana będzie „wartość biznesowa”, którą można się już pochwalić. Wszystkie te lematy są już bardzo wiekowe i – w dzisiejszych czasach – często nie są prawdziwe.

W dzieciństwie słyszałem, że żadna praca nie hańbi – każda męczy. Później, już w dorosłym życiu, uzupełniłem, że każda praca stresuje, choć w różnym stopniu. Bagaż doświadczenia konsultanta pozwala mi także twierdzić, że taki „zawód” dodatkowo może być mocno frustrujący. Co z tym zrobić?

Od pewnego czasu nawet w tzw. mainstreamowych publikacjach na temat IT pojawiają się wypowiedzi sugerujące, że czasy opłacalności budowy systemów na miarę minęły bezpowrotnie. Dzisiaj to wykorzystanie istniejących rozwiązań tworzy przewagę konkurencyjną, nie zaś budowa „doskonale dopasowanych do potrzeb” systemów. Kilka lat temu krytyczna publikacja “IT Doesn’t Matter” (Nicholas G. Carr) wzbudziła „święte oburzenie” i wywołała długą dyskusję. Po kilku latach wygląda jednak na to, że miał on rację.

To zdanie, jakie słyszę od szefów projektów IT, jest bez wątpienia prawdą. Sprzęt to jedyny komponent stosu technologii informatycznej, który musi być fizycznie dostarczony. Na to potrzeba czasu, choć nie sam czas dostawy (Lead Time) jest tu decydujący – najpierw ktoś go musi kupić. Pomijając sztuczki i triki zakupowe, sprzęt jest zwykle zamawiany na początku projektu i sporo czasu upłynie, zanim zacznie być wykorzystywany w stopniu zamierzonym. Tak, zakupy sprzętu zwykle zabierają tyle czasu.

Projekt, w jakim ostatnio uczestniczę, jest „nasączony” różnymi terminami zawierającymi chyba wszystkie możliwe formy i odmiany słowa „biznesowy” – model biznesowy, widoki biznesowe, wymagania biznesowe, architektura biznesowa. I niby nie ma w tym nic złego, bo przecież dobrze, że IT odnosi się jakoś do biznesu – tylko właśnie, do czego się odnosi?

To kolejne zdanie, jakie często słyszę od moich klientów, albo wyczytuję je z wyrazu twarzy, kiedy próbują zrozumieć, co takiego „ten cały złom” robi – kiedy robi to, co ma robić. Zagadnienie to ma dwa „dna” – oczywiste i behawioralne.

Oczywiste „dno” jest często artykułowane przez menedżerów IT – struktura infrastruktury i sposób