V poslední době, jsem řešil s kolegy téma rychlosti vývoje. Co potřebují k práci, co jim jí usnadňuje, co je nejvíce frustruje. Nezávisle na diskuzi, která probíhá prakticky neustále, jsem měl možnost osobně porovnat efektivnost dvou metod, dvou různých týmů (firem). Tenhle příspěvek se pokusí přiblížit obě metody. Pokud je to možné.

Oba týmy pracovaly na stejném projektu. Respektive projekt, webová prezentace, se lišil pouze grafickým návrhem. Výsledek srovnání byl však poněkud rozpačitý. Zadání zní: Vytvořit jednoduchou webovou aplikaci, která bude obsahovat několik statických stránek, dále neomezené množství dynamických stránek, kde každá stránka bude obsahovat jednovláknovou diskuzi a hodnocení. Celá prezentace slouží k tomu aby se stránky zobrazovaly, podle jejich hodnocení. Uživatel může hodnotit libovolné množství stránek, každé stránce však může dát pouze jeden hlas za den. Na stránkách nebude žádná registrace, proto je nutné maximálně ztížit, podvržení hlasování. K této aplikaci je samozřejmě nutná administrace. Grafický návrh dostanete připravený v HTML od grafika a kodéra.

Nyní si rámcově předstvíme oba týmy vývojářů. Budeme je nazývat jednoduše Tým A a Tým B. Tým A je tvořen jednou osobou. Bude využívat primitivní jazyk PHP a framework CodeIgniter. Tým B je tvořen 4 lidmi. Používá Python, šablonovací subsystém v C++ a verzovací systém, nasazuje pomocí balíčků a dodržuje hierarchi velkých vývojových firem. Tým B bude zvýhodněn tím, že začne pracovat v okamžiku, kdy tým A dokončí, odladí a spustí prezentaci, kterou Tým B dostane k dispozici.

Toť na úvod. Tým A začíná pracovat, je 16h odpoledne a začíná se od nuly. Během 1h jsou navrženy DB a základní model pro práci s daty. Použitím knihovny Rapyd pro framework se zkracuje doba na vývoji administrace, ta je prakticky hotová do 2h po navržení struktury databáze. Vývoj pokračuje úspšně, rychle a bez chyb. Jelikož je samozřejmě termín, jako obvykle kritický, pracuje se přes noc. Ve 4h ráno je prezentace hotová včetně administrace. Druhý den zhruba v 10h je předána lidem, kteří do ní plní data, tým pokračuje v dolaďování detailů. Ve večerních hodinách je prezentace dokončená, včetně datování a připravena na ostrý provoz. Úhrný součet hodin je zhruba 24.

Nyní se pokusím popsat práci vývojářů Týmu B. Dostávají projekt od Týmu A. Během 1 týdne je nasazena první verze na testovací server. 2 týden se ladí chyby. 3 týden se dělají opravy, 4 týden jde opravená verze na testovací server, 5 týden se ladí chyby, 6 týden se nasazuje na ostrý server. V okamžiku spuštění nefunguje administrace, nebo funguje jen částečně, mnoho prvků prezentace se musí opravovat zásahem do šablon nebo i kódu.

Srovnání je jednoduché 24h vs. 6 týdnů, přičemž tým B nedodržel zadání na funkční administraci.

Otázka je proč tomu tak je. Chyba je v plánování a efektivnosti jednotlivých metod. Zatímco Tým A pracuje metodou RAD, kdy je kladne důraz na využití hotových řešení (frameworku), jednoduchosti vytváření struktury aplikace a psaní co možná nejméně programového kódu. Druhý tým pracuje metodou Keep it Simply, což prakticky znamená, piš pořád všechno dokola. Metoda KIS neumožňuje pružně reagovat na změny a vzniklé potřeby, jelikož je nutné upravovat neustále velké množství kódu.
Místo odladěných komponent se neustále ladí nepodstatné chyby a to včetně syntaktických, které by se do testu vůbec dostat neměly. Bohužel vyvarovat se jim, je při objemu kódu těžké.

Druhá příčina neskutečně šnečího tempa týmu B je struktura týmu. Každá věc je řešena pomocí balíčků, které se instalují na server. Problém je v tom, že pro nasazení balíčku bylo třeba 2 osob. Jedné pro vytvoření balíčku a druhé pro nasazení. Pro vznik stránky je potřeba dalších 2 osob a to programátora v Pythonu a kodéra který ovládá šablonovací systém. Je tedy nutné koordinovat práce minimálně mezi čtyřmi lidmi. Z toho plynou časové prostoje a vzniká 4násobné množství chyb.

Dalším problémem je, že v týmu B prakticky neexsitovalo povědomí o práci dalších osob v týmu. Domluva mezi osobami je pak mnohem složitější.

Je to chyba?

Otázkou je zda lze pomalou metodu nazvat chybou? Lze. Výsledku se sice dobereme různými metodami, ale pokud se podíváte na věc po finanční stránce, bude to vypadat, že klienta tunelujete. Což v případě, že klient bude moci srovnat dva projekty může vést k problémům a hlavně diskreditaci týmu vývojářů.

Chyba č.2 je špatná volba

Project manager by měl být obecně znalý metod vývoje. Měl by znát možnosti svého týmu. Měl by vědět jak je která metoda efektivní na čas a využití lidských zdrojů, potažmo finančních zdrojů firmy. Bohužel neexistuje ideální způsob jak univerzálně řešit všechny možné aplikace. Obecně je však trendem využívat různé frameworky, které zrychlují a usnadňují práci. Umožňují pružně a rychle reagovat na změny s minmem nákladů na čas, lidské zdroje a finance.

Chyba č.3 - technologie

Vezmemeli v úvahu, že všichni rádoby velcí programátoři upřednostňují vyšší jazyky pro vývoj webu, v našem případě je to Python a vše ostatní považují za balast, musím se zastat těch “podprůměrných” progrmátorů, kteří mají vůbec odvahu, že programují například v PHP.
Ano PHP je pomalejší než Python (je 5x rychlejší než PHP), ale je levnější. Programátor v PHP mě bude stát min 1/2 toho co programátor v Pythonu. Bude pravděpodobně zvyklý dělat i jiné věci než jen programovat (bude znát např. HTML). Budu mít jistotu, že pokud ho přejede auto, do 3 dnů seženu někoho jiného, protože PHP dnes umí snad i batole. Pokud bude používat framework, pravděpodobně nebude moc dělat ani mnoho chyb a zároveň bude rychlý. Výsledkem tedy je, proč používat tank na vrabce. Pokud mi technologie umožní zvládnout dané požadavky, umožní mi to rychle, spolehlivě a efektivně, použiji klidně PHP. Za druhé, v případě PHP (pomalejší než Python) si mohu dovolit výkon dohnat lepším hardwarem na serveru a stále to bude levnější, navíc rozdíl ve výkonu není nijak propastný.

Závěr

Volte metody vývoje tak jak to vyžaduje konkrétní situace. Volite technologie, které problém zvládnou a vyberte tu efektivnější. V našem případě bylo příčinou “selhání”, právě volba technologie a neznalosti metod, které dovolí šetřit čas a několikanásobně zvyšují efektivitu.