Je to jen pár let zpátky, co vývoj systémů připomínal stavbu domu. Projekt se nejprve analyzoval, potom se navrhlo řešení a nakonec přišla realizace. Po dlouhém testování se produkt připomínkoval a případně upravoval. Fungovalo to tedy podobně, jako když se začíná navržením plánu stavby, podle nějž se postaví celý dům. Ovšem oblast informačních technologií a potřeby klientů se dnes mění tak rychle, že za tři měsíce nebo půl roku už nemusí jejich požadavky odpovídat realitě.
Programování proto směřuje k agilním metodám, které umožňují, aby se vyvíjený kód neustále opravoval nebo měnil. Představy zákazníků o vyvíjené aplikaci se totiž v průběhu procesu mění, přichází různé myšlenky na její zlepšení a dochází tak k častým změnám zadání. Původní waterfallové metody tuto flexibilitu neumožňovaly. Když zákazník nebyl s výsledkem spokojený, celý proces se vrátil na začátek nebo se kód dlouhé měsíce opravoval, čímž se celá realizace protahovala a zvyšovala rozpočet.
Metoda iterace neboli opakování
Dnes pracujeme metodou iterace, při níž pravidelně komunikujeme se zákazníkem, plníme jeho přání a potřeby, a zároveň s ním provedení dílčích úkolů pravidelně vyhodnocujeme. Základem je vytvořit projektový tým, kde všichni táhnou za jeden provaz, čímž se také stírají dřívější role dodavatel a odběratel. Společným cílem je vyvinout něco smysluplného a zákazníkům proto vždy říkáme, že to bude bolet. Společnost klienta totiž musí vyčlenit člověka, který má zodpovědnost, dostatečné pravomoci a zároveň také dostatek času. A přestože jsou to naši zákaznicí, dostávají od nás úkoly, které musí plnit. Pokud výše uvedené nejsou schopni zajistit, zpravidla to nedopadne dobře.
Narozdíl od waterfallu se v agilním procesu na začátku neřeší vše do posledního detailu. Úlohy se rozdělují do dílčích úkolů, které je třeba ve stanoveném čase poskládat do funkční podoby. Poté se jednotlivé segmenty mohou podle požadavků klientů upravit nebo nahradit jinými, ale narozdíl od waterfallových metod se vždy pracuje pouze s malými úseky. Aby takto průběžný vývoj dobře fungoval, je nutné mít aplikace pokryté automatickými testy. Zákazník si současně testuje aplikaci i sám a po celou dobu tak vidí průběh vývoje, čímž lze včas odladit řadu chyb a nedostatků.
Rychlost a průběžné opravování chyb
Výhodou této metody je i rychlost a kontrola nad termínem. Díky iteracím a průběžné validaci jednotlivých úkolů se dobře ukazuje postup vývoje a jasně pak také vidíme, jestli se zadání stíhá, nebo naopak jsme s vývojem pozadu. Díky tomu dokážeme se zákazníkem realizaci průběžně vyhodnocovat a případné problémy operativně řešit. Navíc už nemůže dojít k tomu, že po několika měsících práce je zákazník zklamaný, protože finální produkt nesplňoval jeho očekávání, což se dříve běžně stávalo. Výhodou agilní metody je, že zákazník má celý proces pod kontrolou, vše je transparentní, a to i proto, že sám je důležitou součástí týmu.
Aplikace jako puzzle
V současnosti nejsou aplikace psány v jednom jazyce, je to kombinace různých programovacích jazyků, ve finále se tak jedná o skládačku mnoha služeb a nástrojů. Aby taková skládačka mohla vzniknout, je důležité, aby při vývoji rovněž fungovala spolupráce mezi administrátory serverů a vývojáři. K tomu dnes slouží DevOps neboli Development and (IT) Operations, což je přístup k vývoji softwaru, kdy vývojáři komunikují a spolupracují s odborníky na infrastrukturu a provoz, tedy zpravidla s administrátory. DevOps tedy není o jednotlivcích, ale o spolupráci funkčních týmů.
K celkovému zlepšení a hladší implementaci aplikací přispívá také kontejnerizace, kdy každý vývojář pracuje ve svém izolovaném prostředí, které lze potom snadno přenést do produkce. Jedním z nástrojů, který toto umožňuje je Docker. Jedná se o software, jehož cílem je poskytnout jednoduché rozhraní pro izolaci aplikací do kontejnerů a zajistit jednotné vývojářské a produkční prostředí. Tato řešení jsou dobře škálovatelná, je ovšem důležité, aby vývojáři s administrátory spolupracovali už od samého počátku a správně nastavili celý DevOps proces.
Karel Diviš a Ondřej Hlaváč