sobota 21. září 2013

Agilním vývoj není Scrum nebo Kanban


Když jsem byl malej smrad, na Štědrý den mi rodiče kladli na srdce, abych se postil - rozuměj nejedl maso až do štědrovečerní večeře - jinak neuvidím zlaté prasátko. To jsem samozřejmě poctivě dělal až do dovršení věku deseti let. Pak mi došlo, nejenom že žádné prasátko neuvidím, natož zlaté, ale že vlastně ani nevím co si pod tím mám představit. S pojmem Agilní vývoj případně Agile to má většina vývojářů a manažerů podobně. V tom lepším případě si představí Kanban nebo Scrum, případně nějakou konkrétní techniku - párové programování, standup meetings. V tom horším vůbec nic případně to zaškatulkuje pod klíčové slovo bullshit. Většinou je spojuje, že teoreticky zažili všechno, prakticky nic, a od určité doby přestali věřit podobně jako já na to zlaté prasátko. Cynik by mohl dodat, že obojí je to pěkná pohádka.

V tomhle článku se pokusím rozmetat představu, že praktikování Scrumu nebo Kanbanu vede k agilnímu vývoji. Je to asi stejná mentální zkratka, jako od sexu k početí potomka. Můžete mít orální sex, ale jenom těžko můžete očekávat, že z toho někdo otěhotní. Úplně stejně to funguje s agilním vývojem. Praktikujete Kanban a místo agilního vývoje máte produkt doručovaný jednou za půl roku s nulovou přidanou hodnotou zákazníkovi. Zatímco ten orální sex si někdo užije, po zpackaném agilním vývoji zůstane pouze frustrovaný zákazník a zpruzení vývojáři. Když dva dělají totéž nebývá to obvykle totéž.

Položme si jednoduchou otázku. Existoval agilní vývoj, před tím než byly představené metodologie jako Kanban? Samozřejmě, že existoval, jenom se tomu tak neříkalo. Mimochodem techniky, které se postupem času zpopularizovaly, jako například Párové programování nebo Test Driven Development existovaly pravděpodobně ještě před tím, než někoho napadlo přemýšlet o tom, že z nich udělá sadu pravidel. Pokud tedy agilní vývoj existoval před tím, než se ho snažil někdo sešněrovat do řekněme Scrumu, pak ovšem platí, že můžete dělat agilní vývoj, bez toho aniž byste se snažili slepě aplikovat řekněme opět Scrumu. Abych nebyl chycen za slovo, samozřejmě že Scrum nebo Kanban jsou velmi pružné a navržené, aby je bylo možné upravit podle kontextu použití, jak vám jistě řekne nejeden agile expert. Ještě jednou, není důležité jak tomu říkáte, ale jak to funguje.

Vezměte si prosím tužku a papír případně si jinak zaznamenejte, to co si představujete pod agilním vývojem.

Máte je? Výborně! Za chvilku se nám budou hodit.

Další část našeho cvičení pokračuje, kterou z možností (levou nebo pravou) v níže uvedených větách intuitivně preferujete.

  • Jednotlivci a interakce před procesy a nástroji
  • Fungující software před vyčerpávající dokumentací
  • Spolupráce se zákazníkem před vyjednáváním o smlouvě
  • Reagování na změny před dodržováním plánu

Pokud preferujete možnosti nalevo od slova před, pak máte správné mentální nastavení pro odbourání jakýchkoliv stereotypů o agilním vývoji. Pokud preferujete možnost napravo od slova před, pak v uvozovkách stále věříte na zlaté prasátko. V každém případě předchozí věty jsem si nevycucal z prstu, ale pocházejí z Agile manifesto tj. dokumentu absolutně zásadního k pochopení agilního vývoje. V tom samém dokumentu najdete 12 jednoduchých pravidel, kterými je definován agilní vývoj.

  1. Naší nejvyšší prioritou je vyhovět zákazníkovi časným a průběžným dodáváním hodnotného softwaru.
  2. Vítáme změny v požadavcích, a to i v pozdějších fázích vývoje. Agilní procesy podporují změny vedoucí ke zvýšení konkurenceschopnosti zákazníka.
  3. Dodáváme fungující software v intervalech týdnů až měsíců, s preferencí kratší periody.
  4. Lidé z byznysu a vývoje musí spolupracovat denně po celou dobu projektu.
  5. Budujeme projekty kolem motivovaných jednotlivců. Vytváříme jim prostředí, podporujeme jejich potřeby a důvěřujeme, že odvedou dobrou práci.
  6. Nejúčinnějším a nejefektnějším způsobem sdělování informací vývojovému týmu z vnějšku i uvnitř něj je osobní konverzace.
  7. Hlavním měřítkem pokroku je fungující software.
  8. Agilní procesy podporují udržitelný rozvoj. Sponzoři, vývojáři i uživatelé by měli být schopni udržet stálé tempo trvale.
  9. Agilitu zvyšuje neustálá pozornost věnovaná technické výjimečnosti a dobrému designu.
  10. Jednoduchost--umění maximalizovat množství nevykonané práce--je klíčová.
  11. Nejlepší architektury, požadavky a návrhy vzejdou ze samo-organizujících se týmů.
  12. Tým se pravidelně zamýšlí nad tím, jak se stát efektivnějším, a následně koriguje a přizpůsobuje své chování a zvyklosti.

Kolik z toho, co jste si představovali pod agilním vývojem, viz papír a tužka, vám sedí proti těmto pravidlům. Těchto 12 pravidel nic neříká o Scrumu, nic neříká o tom, že musíte dělat každý den standup meeting a dokonce to ani nic neříká o tom, jak ta pravidla realizovat. Ještě zajímavější srovnání se nabízí, pokud se snažíte používat Scrum nebo Kanban. Pokud ano, zkuste si položit otázku, jestli podle těch pravidel skutečně fungujete.

V GoodData jsme se pokoušeli dělat agilní vývoj několik let. Bohužel jsme na to šli přes Scrum a později přes Kanban a většinou selhali. Ten důvod nebyla ani jedna z těchto metodologie, ale to že jsme si nikdy neřekli, že to podle čeho chceme skutečně fungovat je těchto 12 pravidel - cíl. Scrum nebo Kanban může (a nemusí) být prostředek - cesta, jak se k němu dostat. Teprve potom, co se snažíme zaměřit na tyto pravidla, začíná agilní vývoj skutečně fungovat. Nedělejte proto stejnou chybu a místo na konkrétní metodologii si zaměřte na to, aby jste se snažili vždy fungovat podle těchto jednoduchých pravidel. Výsledkem bude skutečný agilní vývoj nikoliv jeho předstírání a lhaní si do kapsy.