Agilní vývoj – splněný sen dodavatele i klienta?

Měla by být agilní metodika vývoje ultimátním cílem klienta i dodavatele? Nebo je lepší waterfall metoda s fixní cenou? Přečtěte si náš článek o výhodách a nevýhodách vývoje mobilních aplikací za pomoci těchto dvou metod.

Nespálit se na změnových požadavcích a následných vícepracích, to je sen každého klienta i dodavatele, správné nacenění FTFP zakázky je totiž víc než komplikované. Jako ideální řešení této situace se na první pohled může jevit agilní metodika vývoje – kdy je její využití opravdu na místě?

„Každý softwarový produkt, který má na začátku vydefinovaný nějaký rozsah, se totiž mění. Vždycky. Když jsou obě strany v software vývoji nezkušené, dřív nebo později se slije chyba zadavatele i dodavatele a je z toho lidově řečeno jenom mrzení.“

Waterfall metodika a začínající software studia

Proč prakticky všechny agentury chtějí aplikovat agilní přístup? Protože v začátku jejich existence se velká část z nich na FTFP zakázkách spálila a projekt skončil nezdarem. Vývoj metodou waterfall je totiž bez předchozích zkušeností jen velice těžko definovatelný a ve výsledku je zakázka klidně i 2x dražší. To však jde na vrub dodavatele, který nebyl schopný na začátku objem práce odhadnout. Chce-li pak proplatit vícepráce, klient nereaguje velmi nadšeně 🙂

Typickým příkladem je, když začnou programátoři po škole pracovat na zakázkových projektech. Nacení je, podepíše se smlouva, jenže pak se zjistí, že vznikla spousta šedých zón, které nejsou zadané ve specifikaci a je nejasné, zda tam měly být. Zajisté se také objeví věci, na které se mělo myslet dopředu a nemyslelo… Následně se v takovémto waterfallovém projektu dostává do konfliktu zadavatel s dodavatelem nad tím, co bylo původně vyspecifikované. Již dříve jsme se tomu věnovali v článku Vývoj mobilních aplikací krok po kroku.

Na zkušenosti záleží

Ostřílené softwarové firmy už se ale nebojí tvořit některé projekty waterfallem. Nacení dle předchozích zkušeností a zadefinují jako fixed time, fixed price, fixed scope. Díky tomu vznikne práce např. na několik měsíců, která je neměnná a na konci se předá výsledek.

Agentura ale samozřejmě během procesu zjišťuje věci, které nebyly na začátku řečeny a ani je nelze odhadnout. Je to, jako kdybyste stavěli dům a měli se hned na začátku rozhodnout, jestli obraz bude v ložnici umístěný 7 cm od dveří nebo 10 cm od okna.

Trable na obzoru

„Každý, kdo na straně klienta viděl nějaký software produkt, má pocit, že se díky tomu může k vývoji mobilních aplikací fundovaně vyjadřovat. Jenže tak vznikají problémy.“

Aniž bychom chtěli být ke klientům neuctiví, takto zjednodušit ale situaci bohužel nejde. Klienti totiž často nevnímají, jak se mezi sebou liší webová stránka, vývoj mobilní aplikace, nebo (v krajním případě) plakát jako reklamní formát. Často vnímají jen vizuální stránku věci a berou dílo jako obrázek. Pokud je tedy třeba v aplikaci posunout tlačítko o něco výš, neuvědomí si, že jde o zásah do kódu, nýbrž věc berou jako jednoduché posunutí na dva kliky myší…

Proč vyvíjet agilně?

Agilní přístup je mnohem bezpečnější – pro obě strany. Agilní projektové řízení je o iteracích, 14denních sprintech, během kterých je tým plně vytížen prací pro klienta a placen za tento čas. Na konci sprintu se vždy iterace vyhodnocuje a zadává další.

Chce to však vůli ze strany klienta, kterého vývojářská firma potřebuje zapojit do procesu, aby na pravidelných schůzkách spojených s vývojem začal chápat fungování aplikace a vývojářského procesu.

Díky tomu pak začne klient vidět benefity v tom, když se například během vývoje zjistí, že by pro uživatele aplikace bylo lepší některé funkce upravit, jiné vynechat, další přidat. Kdyby se taková věc stala během waterfall nacenění, jednalo by se o obří sumy za vícepráce překračující dohodnutou cenu za dílo. Takto není problém soustředit se při příštím sprintu na to, co je důležité a nutné upravit.

Proč se tedy agilně nevyvíjí více?

Přesto se může leckdo obávat, že cenu vývoje mobilní aplikace s pomocí agilního vývoje nebude mít pod kontrolou a výsledek bude mnohem dražší. Ani to není pravda. Agilně se dá totiž vyvíjet i s fixním rozpočtem. Pak je ale třeba prioritizovat nejdůležitější věci a ty méně důležité odlaďovat postupně.

Agilní vývoj je zárukou zdárného dosažení cíle

Je tu však i další výhoda agilního vývoje. Hypotetický příklad (v praxi ale bohužel rozhodně ne ojedinělý) – klient si s agenturou plácne na FTFP projekt. Ta 4 měsíce vyvíjí, ale klientovi se výsledek nelíbí. To znamená pro obě strany ztracený čas i peníze. Statisticky dosáhne zdárného cíle překvapivě jen 13 % FTFP projektů. V agilním vývoji tohle neplatí. Klient má již od počátku plně pod kontrolou vývoj projektu.

„Hlavní moto agilu je „people over processes“. Bavíte se se zákazníkem o tom, že postavíte funkční tým orientovaný na cílového uživatele a na použitelnost produktu. Pokud se shodnete, že se sešel takový tým, který chce jít společně nejlepší cestou k funkčnímu produktu, který řeší problém cílového uživatele, máte vyhráno.“

I agilní vývoj má svá úskalí

Stejně jako mladé agentury doplácejí na nezkušenost při zadání waterfallu, nebojíme se přiznat, že my jsme naopak ze začátku neuměli agile. Když jsme začali mobilní aplikace vyvíjet my, propůjčovali jsme naše kapacity na určitý čas, tedy typický agilní sprint. Bez precizně vydefinované smlouvy se nám ale občas stalo, že klient požadoval věci udělat jinak mimo vymezený čas, který jsme jako dobří lidé poskytli, ale pak se vývoj nevyplácel finančně.

Agilní vývoj je tedy dobré praktikovat, když jsou zkušené obě strany a mají k sobě maximální důvěru (klient bere vývoj aplikace jako proces, přičemž firma udělá vše, co je v jejích silách a je jedno, kolik to bude stát času).

Univerzální řešení?

Upřímně řečeno, spíše neexistuje. Ač jsme velcí fanoušci agilního vývoje, nedokáže-li být klient součástí vývojového procesu, nedává takový přístup smysl.

Zajímavostí je, že např. v Americe funguje většina vývoje právě agilní metodou. Zde mají ověřeno, že waterfall nefunguje, a tak se rovnou vrhají na agilní vývoj stylem 3-4 měsíční spolupráce - a pokud vše sedlo, pokračuje se dál. Nezřídka se ale stává, že se po daném období klient s dodavatelem rozloučí a na produktu pokračuje někdo jiný.

V SYNETECHu i my doporučujeme začít pracovat na MVP, abychom ukázali klientovi naše tempo a schopnosti a pak můžeme přejít na model, kdy poskytneme klientovi dedikovaný tým na určité období a může se dotvořit aplikace.

P. S. Chcete-li zjistit o agilním vývoji či waterfallu více, mrkněte na stránky ASWA, kterou jsme spoluzaložili a díky které se snad stane Česko softwarově lepším pro nás všechny.

Máte zájem o vývoj mobilní aplikace nebo se chcete jen na cokoliv zeptat?

Ozvěte se nám