Agilní implementace BI - nejlepší způsob, jak na to | Mňamka #183

Agilní metodiky tady s námi jsou už téměř 3 dekády a stále častěji se s nimi v rámci Business Intelligence (BI) projektů setkáváme. Ptáte se, jaké jsou výhody agilního vývoje BI oproti tradičním rigorózním metodikám? Jaké jsou naopak nevýhody a kdy do toho šlápnout právě agilně a kdy ne?Jaké jsou naše zkušenosti s agilním vývojem BI? Tak na tyto otázky se pokusím odpovědět v dnešní Bizztro Mňamce.

Agilní vs. Rigorózní

Nejprve se společně pojďme podívat na to, co to vlastně agilní a rigorózní přístup k vývoji softwaru (SW) či BI je.

Agilní metodiky a přístupy k vývoji software začaly vznikat v druhé polovině 90. let jako reakce na nedostatky tradičních rigorózních metodik. Tyto “lehké” metodiky vývoje vychází z myšlenky, že jedinou cestou, jak otestovat výsledné řešení, je co nejrychleji ho vyvinout (nebo alespoň jeho část), předložit zákazníkovi a na základě zpětné vazby jej upravit. Jednotlivé agilní metodiky používají rozdílné techniky, ale jsou založeny na společných principech a hodnotách. 

Základními vybranými principy agilních metodik (dle mého názoru ty nejdůležitější a nejvíce v rozporu s tradičními rigorózními metodikami) jsou:

• individuality (lidé jsou prvořadým faktorem) - důraz na spolupráci a komunikaci,
• tolerance ke změnám - změna požadavků i v průběhu vývoje,
• iterativní vývoj s krátkými iteracemi,
• důvěra a spolupráce se zákazníkem - zákazník určuje a mění priority projektu.

Zatímco v tradičních rigorózních přístupech je třeba požadavky a procesy předem specifikovat a snažíme se vyhnout či zabránit změnám v rámci projektu, tak u agilního přístupu je tomu naopak. Jedním z hlavních principů agilních metodik je včasná a kontinuální dodávka s hodnotou pro zákazníka, zatímco u rigorózních metodik je výsledek představen zákazníkovi zpravidla až na konci projektu.

Waterfall přístup k řízení projektu

Jedním z často využívaných modelů v rámci rigorózních metodik je taktéž vodopádový model (známý též jako waterfall). V rámci vodopádového modelu se striktně postupuje sekvenčním způsobem z jedné fáze do druhé (např. ze specifikace požadavků do návrhu celkového řešení). Tento model má mnoho příznivců ale i odpůrců, jako například Davida Parnase, který v článku A Rational Design Process: How and Why to Fake It píše: „Mnoho detailů postupně vyjde najevo v průběhu implementace. Některé věci, které zjistíme, zneplatní náš návrh a my se musíme vrátit zpátky.“ S tím samozřejmě nelze jinak než souhlasit, jelikož právě v dnešní době je na změnové požadavky a rychlosti jejich implementace kladen enormní důraz. I z těchto důvodů jsou agilní přístupy vývoje v současném světě stále více upřednostňovány.

Ale abychom agilní přístupy jen nevynášeli do nebes, pojďme si i říct, kdy se právě agilní přístupy nemusí vyplatit. 

Představte si, že třeba chcete agilně vyvinout nový systém pro leteckou dopravu. Spoustu z vás již napadlo, že agilní přístupy se právě u mission/business-critical projektů (projekty, u kterých by jejich selhání či zastavení způsobilo přímo katastrofické následky) využívají jen zřídka. V tomto případě je dobré metodiku vývoje opravdu směřovat spíše rigorózní cestou tak, abychom předem jasně vydefinovali výsledné řešení a kritéria úspěchu.

Agilní vývoj BI

Pokud navážeme na business-critical projekty, se kterými jsem se v rámci datové analytiky v Bizztreat již několikrát setkal, tak tyto projekty mají většinou charakter datové integrace. Právě v závislosti na datech a dalších předdefinovaných mechanismech vytváříme řešení, které je kritické pro chod společnosti. V tomto případě chce zákazník mít jistotu, že řešení bude funkční a v době nasazení či provozu nedojde k výpadku. Proto je zde přirozeně vyvíjen tlak na předem definované a jasně popsané výstupy a cíle projektu (splňující určitá kritéria), které se opírají o vhodné smluvní dodatky. Především díky tomuto přístupu lze tyto projekty označit spíše za rigorózní.

Agilní přístup při vývoji BI nepotřebuje naprosto detailní zadání hned z počátku projektu, ale jak bylo řečeno, důraz je kladen na pružnost, rychlé přírůstky a možné změny v rámci vývoje. Proto je agilní přístup v rámci vývoje BI často preferován. 

Ptáte se stále proč? Je to jednoduché. Priority a zadání se často vyvíjí s tím, jak se vyvíjí BI a business samotný. Spousta firem v dnešní době vlastně ani nezná potenciál jejich dat a co se s nimi vše dá či nedá dělat. Spousta firem se vyvíjí tak překotnou rychlostí, že než by jsme dokončili půl roční projekt rigorózní povahy, tak jsou jejich priority úplně jinde.
Jak bychom pak měli vlastně postupovat podle rigorózních metodik a stanovovat cíle či výstupy projektu, když nemáme zmáklou ani základní analýzu dostupných datových zdrojů či se business vyvíjí tak rychle, že ve chvíli, kdy prezentujeme výsledky projektu, jsou tyto výstupy téměř nerelevantní? 

Co je dalším negativem rigorózního přístupu a souvisí s předešlým odstavcem je právě neznalost “datového prostředí” společnosti, která se pak odráží na výsledné cenovce řešení. 

No řekněte sami, nedali byste si v případě výstavby domu, který nevíte jak bude velký a jak náročné ho bude postavit nějakou finanční rezervu? Aby byly pokryty vaše náklady, ale zároveň jste měli alespoň nějaký zisk? Stejně tak to chodí i v případě BI projektů vyvíjených pomocí rigorózních metodik.

Jinými slovy u rigorózních “fixed time fixed price” projektů si prostě objednatel připlatí, jelikož zhotovitel nechce přijmout příliš velké riziko toho, že mu na začátku projektu něco uniklo. Samozřejmě lze v tomto případě argumentovat tzv. “před-projektem”, kde proběhne samotná analýza daného zadání z hlediska realizovatelnosti. Tato analýza samotnému projektu předchází, a díky ní lze výsledné odhady pracnosti celého projektu výrazně zpřesnit a časové rezervy minimalizovat.

Naproti tomu agilní vývoj v rámci pay-as-you-go, kdy zákazník platí jen za odvedenou práci, je dle mých zkušeností pro zákazníka v rámci vývoje BI nejvýhodnější. Nejenom, že může celkově lépe korigovat svou útratu, ale taktéž rychlost vývoje. Dalším důležitým pozitivem tohoto přístupu je právě onen zmiňovaný princip, že zákazník může korigovat a upravovat své zadání, čímž je schopen ho vyladit k dokonalosti. V rámci krátkých sprintů (časová okna, kdy se prochází stav projektu - v Bizztreat zpravidla 1x týdně) je zákazník více v kontaktu s tím, co se na projektu děje a je schopen včas zasáhnout, pokud by se projekt ubíral nesprávným směrem.

Závěr

Ať už jste data-driven firma či nikoliv je důležité si právě tyto aspekty různých přístupů k vývoji BI jednou za čas zopakovat a položit si otázku, jak to BI vlastně chceme dělat?

Ani jeden z přístupů není špatný, ale každý přináší svá pozitiva a negativa. Právě proto se nedá říci, že by firma vyvíjela BI právě buď agilně či rigorózně, ale ve většině případu se jedná o vývoj, kdy se tyto přístupy prolínají.

Zapomněl jsem na něco? Chcete se na něco zeptat? Napište mi. Rád to s vámi proberu.

Patrik