úterý 4. listopadu 2014

Když MVP dláždí cestu do pekel

MVP všichni tu zkratku milujeme nebo lépe řečeno to co se za ní skrývá. Minimum Viable Product - to nejnutnější minimum, které musíte dodat zákazníkovi, abyste vyřešili to nejdůležitější, co ho pálí. Zákazník to miluje, protože dostane v nejkratším čase to co chce nebo si to alespoň všichni myslí. Vývojáři to milují, protože se jim to vejde do sprintu a nebo se to dá alespoň naplánovat na menší části. Architekti to milují, protože nedochází k velkému designu a zbytečným rozhodnutím implikujícím změny, které možná nebudou potřeba. MVP je dobrý sluha, ale špatný pán. Snadno se z něj stane jednosměrka přímo do pekla. Není to bída MVP, ale důsledek toho, kam vede jeho nevhodné použití. Tento článek je o tom, jak se vyvarovat určitých úskalí s ním spojených.

Malé mentální cvičení kolem MVP dovedené ad absurdum.Přijde za vámi zákazník a řekne, že se potřebuje dostat z bodu A do bodu B. Chtěli byste navrhnout auto. To je ovšem složité a vůbec, potřebuje to zákazník? Co třeba motorku? Moc složité. Co třeba kolo? Ten zákazník bude jezdit vždycky z kopce. Ani kolo není potřeba, co třeba koloběžku? Bude jezdit vždy v zimě. Co třeba sáňky nebo rovnou lyže? Lyže budou ještě jednoduší a levnější. No možná bychom to mohli ještě zjednodušit. Co mu takhle dát pod zadek igelitový pytel, který vycpeme slámou? To nakonec stačí a voilà máme MVP. Zákazník má sice omrzliny prvního stupně, občas si rozbije hubu, ale MVP posloužilo svému účelu.

Podobné MVP má v podstatě dvě stinné stránky. To co je MVP pro zákazníka, může být noční můrou pro vývojáře z pohledu nějaké další údržby a rozvoje. Pokud si nasekáte do produkce několik MVP vedle sebe, může se jejich udržování podobat průchodu minovým pole. Mnohdy je totiž MVP velmi provizorní řešení. Mnohem horší problém s MVP je ten, že mnohdy zůstává na věky. To znamená, že už se do nich nikdy neinvestuje ani koruna. Slouží svému účelu, ale nikdo už je nedotáhne do požadovaného stavu. MVP je polovičatá práce jejíchž důsledky vás dříve nebo později doběhnou.

Pokud nehodláte udělat MVP a to dále rozvíjet, případně jej úplně zaříznout, je lepší nedělat ho vůbec. Úplně nejhorší situace je, pokud vám hromada MVP trčí v produktu, jako kostlivci ve skříni, kteří se jenom třesou na to, aby na vás mohli vypadnout v tu nejméně vhodnou chvíli, pokud možno dohromady, protože mezi nimi existuje nějaká vazba. Velmi se mi líbí myšlenka, kterou popsal Martin Fowler v článku SacrificialArchitecture. Ta s MVP souvisí na úrovni architektury. V kostce se jedná o to, že každá architektura je poplatná době svého vzniku a měla by mít datum expirace. Po jeho uplynutí by nám nemělo být líto danou část systému vyhodit a přepsat ji s ohledem na aktuální požadavky. MVP se dá dělat dobře, ale chce to velkou kázeň, mějte jí, až se k jeho použití uchýlíte.

  1. Nedělejte MVP pokud je to váš jediný modus operandi. Soustřeďte se na minimální řešení, kdy MVP nebude jenom výmluva pro oklamání akceptačních kritérií a pašování práce nízké kvality.
  2. Nedělejte MVP pokud ho nehodláte dále rozvíjet. Rozvíjet může znamenat úplně předělat a nebo zrušit, počítejte s tím.
  3. Nedělejte MVP stavějící na jiném MVP neboť riskujete efekt motýlích křídel.