V tomto článku se podíváme zblízka na první dvě otázky a ceně aplikace a faktorům, které ji ovlivňují, se budeme věnovat v samostatném článku. Není pro nás úplně železným pravidlem, že začínáme aplikaci vyvíjet vždy od nuly – stává se nám taky, že dostaneme do ruky rozdělaný projekt a máme za úkol ho dotáhnout.
Máme pochopení pro to, že klient potřebuje dokončit aplikaci za použití technologií, ve kterých vznikla, a nemůže si dovolit dosud investované peníze vyhodit oknem. Dává nám to smysl z hlediska dlouhodobého vztahu s klientem – rádi mu ušetříme peníze. Pro potřeby článku se ale podíváme na vývoj aplikace od A do Z a zmíníme následující fáze:
- Řízení projektu metodou waterfall
- Proč stále častěji dostává přednost agilní vývoj
- Řízení projektu metodou waterfall
- Design v pojetí Koaly
- Vývoj a zastupitelnost
- Komunikace mezi vývojářem a klientem
- Testování, opomíjená část vývoje
- Vydáním příběh nekončí
Řízení projektu metodou waterfall
Někteří klienti (vlastně jich je stále většina) otevírají spolupráci tak, že za softwarovou firmou přijdou s balíkem práce, balíkem peněz a otázkou „Kdy můžeme aplikaci očekávat?“ Mají často velký zájem o to, aby cenu za vývoj mohli zafixovat.
Co se ale snažíme vždy vysvětlit, je, že s metodou vývoje zvanou waterfall není možné klientovi dát přesnou představu, jak bude vypadat produkt, který vypadne na druhé straně. Postupuje se při ní tak, že se aplikace designuje a programuje v celé svojí šíři a ke každému dalšímu kroku se přistoupí, až když je ten předchozí považovaný za hotový.
Vývoj aplikace – ať už webové, nebo mobilní – se občas přirovnává k výrobě auta. Vodopádový model v této metafoře od začátku chystá závodní Ferrari, které klient dlouho vidí jenom na papíře a projet se v něm může až ke konci projektu.
Proč stále častěji dostává přednost agilní vývoj
Agilní vývoj si naproti tomu klade praktické cíle v kratších úsecích – sprintech. Na začátku každého sprintu, který trvá 14 dní, se definují jednotlivé dílčí úkoly (tasky) a programátoři je potom postupně z projektu ukrajují. U agilní metody se nedá závazně říct, jestli bude celý projekt trvat tři měsíce, nebo šest, ale klient může vývoj daleko více ovlivňovat. Na konci každého sprintu dostává report, ve kterém vidí, o jaký kousek vývoj zase pokročil kupředu, a může podle potřeby upřesnit zadání.
Pokud se vrátíme k metafoře s automobilem – nedodáváme klientovi po částech precizně sestrojený volant, nápravu, karoserii a tak dále. Dostane od nás rovnou koloběžku, která ho dopraví z bodu A do bodu B. V tu chvíli může aplikaci vzít a ověřit si její základní funkce v praxi se zákazníky.
Agilní vývoj počítá s tím, že se během projektu budou dít změny, takže když se s klienty bavíme o ceně a jejím zafixování, docházíme k tomu, že je pro obě strany lepší mít flexibilní budget. Vývojář pak nemá svázané ruce, když ze strany klienta přijdou v průběhu vývoje nové požadavky, a kromě toho dokáže pružně zakomponovat novinky z technologického pokroku.
Na začátku spolupráce si nejdřív ze všeho s klientem potvrdíme koncept aplikace a zjistíme od něj maximum informací o tom, jaké funkce od ní potřebuje. Během analýzy se snažíme co nejlépe pochopit, jak funguje klientův produkt (nebo procesy, pokud jde o interní aplikaci), na co klade největší důraz a jak může aplikace podpořit jeho „edge“, tedy konkurenční výhodu oproti ostatním v oboru.
Jak už bylo řečeno, naším úkolem je klientovi co nejdříve dodat pojízdný model – koloběžku, které se říká MVP (minimal viable product). Po MVP následuje kolo, které toho umí o něco víc, pak motorka a nakonec ono Ferrari, které mohlo být v plánu od samého začátku, ale mohlo se k němu taky dospět až cestou.
Někdy se může stát, že po kole přijde loď, protože si klient během vývoje aplikace uvědomil, že jeho podnikání je o něčem trochu jiném. Díky tomu, jakou flexibilitu agilní vývoj umožňuje, to ale nemusí být takový problém.
Design v pojetí Koaly
Už při vývoji koloběžky dbáme na to, aby design byl na dobré úrovni a aby byl funkční. V této fázi má hlavní slovo UX designér, který má za úkol nastavit logiku aplikace z pohledu uživatele – aby orientace v jejím rozhraní byla snadná a průchod jejími částmi logický.
Dohodnutou představu o aplikaci co nejdříve převádíme do vizuální podoby, kterou si klient může proklikat a prohlédnout do posledního detailu. Je lepší si aplikaci co maximálně odladit dřív, než se začne programovat. Později během samotného vývoje už jsou větší zásahy do produktu náročnější a zbytečně dražší.
Vývoj a zastupitelnost
Ve chvíli, kdy jsme si s klientem odsouhlasili podobu aplikace a shodli se, které funkce by zásadně měly být součástí MVP, se může rozjet samotný vývoj. Na začátku 14denního sprintu si s klientem řekneme, co je reálné stihnout, a na konci sprintu mu odevzdáváme funkční demo v takzvané dev verzi na testovacím serveru.
Podle náročnosti aplikace na programování případně jeden až tři z celkového týmu 13 zkušených vývojářů. Máme v týmu lidi s širokým záběrem v technologiích a programovacích jazycích, ale zároveň držíme kolektivní know-how projektu, abychom zaručili zastupitelnost a aby se sprinty v případě nemoci nebo náhlého výpadku lidí nezadrhávaly. Píšeme kód i dokumentaci tak, aby mohl kdokoli do projektu naskočit, rychle se zorientovat a navázat na kolegovu práci.
Komunikace mezi vývojářem a klientem
Je pro nás úplně běžné se s klientem synchronizovat denně nebo párkrát do týdne. Jsme dostupní na telefonu, na e-mailu, nebo chatovacích nástrojích. Všechny požadavky sepisujeme do backlogu, který v každém daném okamžiku přesně odráží současný stav aplikace. Máme potom pečlivý záznam o tom, kde zrovna ve vývoji jsme a na čem jsme se s klientem domluvili.
Každý projekt postupně roste. Koloběžka na sebe nabaluje další a další funkce a zakomponovat je bývá těžší než na začátku, protože už se jedná o změny v mnohem komplexnějším celku. I přesun tlačítka na jiné místo může trvat půl dne, protože k tomu nestačí Ctrl+X a Ctrl+V.
Vývojář musí nejdřív zjistit, co všechno změna ovlivní, musí ji naplánovat, provést a otestovat. Na backendu se může snadno stát, že se i menší změna nečekaným způsobem projeví v úplně jiné části aplikace.
O časové náročnosti ale s klientem otevřeně mluvíme a na konci sprintu ukazujeme, kolik hodin se strávilo na kterém úkolu, abychom případně mohli upravit priority.
Testování, opomíjená část vývoje
Pokud je na testování vyčleněná jenom malá část rozpočtu, nedají se naskriptovat a provést opravdu hloubkové, automatizované testy. Manuální testy jdou bohužel vždy jen po povrchu a nepokryjí každou představitelnou kombinaci kroků, kterou může později uživatel v reálu provést.
Může se potom stát, že aplikace se zasekne a spadne zrovna ve chvíli, kdy si ji prohlíží CEO – kdy jindy, že? – a problém je na světě. Automatizace je v testování vždy výhodná. Je důležitá kvůli zachycení případné regrese – tedy toho, že po nové změně přestane fungovat kód v dříve napsaných (a otestovaných) částech aplikace. Automatizace tedy šetří obrovské množství času vývojářům i testerům a my ji rozhodně považujeme za důležitý krok směrem ke špičkové výsledné kvalitě.
Vydáním příběh nekončí
Když je vše v pořádku otestováno a schváleno, můžeme provést release – aplikaci vydat. Vydání znamená přesun kódu aplikace na produkční server a publikaci na webu, případně v App Store (iOS) a/nebo Google Play (Android). Ať už je to koloběžka, kolo, nebo motorka, není to tak, že bychom si oprášili ruce, vystavili fakturu a šli od toho. Opravujeme bugy, které se mohou projevit až po nějaké době, a optimalizujeme v návaznosti na aktualizace operačních systémů.
Přeci jen jsme postavili funkční nástroj a je na nás, abychom ho udrželi při životě.
Kromě samozřejmých oprav klienta rádi upozorníme, když se objeví nová technologie, která by pro jeho projekt mohla mít nějakou zajímavou přidanou hodnotu, takže se potom spolupráce může rozvíjet roky. Záleží nám na dlouhodobých vztazích a kvalita u nás pokaždé zvítězí nad kvantitou. A proto máme projektů čím dál víc.
________________________________________________
Pokud byste si rádi přečetli více o naší práci, doporučujeme rozkliknout náš BLOG, na kterém shromažďujeme například rozhovory s našimi klienty nebo různé tipy a triky z oblasti technologií a podnikání.