V tomto článku bych chtěl vyjádřit pár myšlenek, které jsem pochytil v průběhu několika projektů v poslední době. Často jsme s přáteli v hospodě rozebírali, zda je lepší použít pro vývoj projektů metodiku typu vodopád, nebo je lepší používat některé z typů iterativního vývoje jako např. Scrum jak se říka (agile software development). Jenom ve zkratce pro nezasvěcené v čem je rozdíl. První typ metodiky vodopád (Waterfall) by měl probíhat zhruba takto. Samozřejmě se toto může lišit v závislosti na firmě a na řešeném problému.

• provede se detailní analýza zadání
• vymyslí se obchodní model
• napíše se specifikace
• zpracuje se plán projektu
• stanoví se náklady
• začne se programovat

• vývojář je přesně seznámen s celou problematikou prostřednictvím zadání
• návrh architektury může být robustnější a komplexnější
• úkoly jsou přesně dané (neměnné)

• nepřesné a složité stanovení nákladů z několika důvodů a to zejména
• už při prvotním návrhu se zapomíná na drobné, ale důležité věci, bez kterých projekt nevede k cíli
• nepřesně odhadnutá složitost problému
• problémy, které vyplynou v průběhu projektu

Ve zkratce, klady jsou velice příjemné, hlavně pro programátory. Pokud se všechno povede, většinou vzniká kvalitní, dobře postavená aplikace. Už tak méně příjemné pro toho, kdo projekt připravuje. Příprava většinou stojí hodně času a tyto náklady se musí započítat do celkových nákladů na projekt.

Už při prvním pročtení nevýhod je jasné, že se projekt může nepředpokládatelně protáhnout a prodražit. Dále se může stát, že v půběhu projektu zjistíme, že se projekt (aplikace) stáčí nekontrolovatelně jiným směrem, než bylo původně zamýšleno a co je nejhorší, můžeme zjistit, že výsledek bude v konečném důsledku pro koncového uživatele nepoužitelný. Takové projekty dále trpí nestálostí zadání. Toto je samo o sobě přirozená věc, protože projekt tohoto typu je většinou naplánován na delší dobu a za strany zadavatele hrozí nebezpečí změny názorů.

• vizi projektu
• základní charakteristiky jednotlivých částí

• projekty bývají levnější
• rychleji zpracované

• vývojáři jsou s problematikou seznamováni postupně
• nelze navrhnout přesně
• úkoly se mohou měnit

Ovšem pozor. Není to tak jednoduché, jak by se ve druhém případě mohlo zdát. V tomto případě v podstatě neexistuje projektová příprava. Všechno je na bedrech mamagera projektu, chcete-li Scrum Mastera. To znamená, že se jeho kvalita projeví až v průběhu projektu, což je velice nebezpečné. Projekt manager musí v tomto případě co nejvíce komunikovat s vývojovým týmem formou meetingu a plánovat tzv Sprinty. Nejlépe každý den a buď jasně stanovovat úkoly pro každého zůčastněného, nebo úkoly delegovat přes team leadera. V opačném případě se velice lehce může stát, že se bude programovat stylem vymysli si sám a on nám to projekt manager nějak odklepne, případně se to pak nějak udělá. A to rozhodně není cesta.

Po několika prožitých, či protrpěných projektech jsem došel k tomuto názoru:

• neexistuje ideální metodika vedení, ideální je kombinace několika typů
• na začátku projektu musí být zpracována alespoň základní kostra specifikace
• pokud má projekt přinášet zisk, musí být stanoven obchodní model dříve, než se začne programovat
• je důležité nasadit maximální počet programátorů hned v počátku projektu, kdy je třeba naprogramovat co nejviditelnějsí část
• přesně stanovovat úkoly pro každého ze zůčastněných
• neplýtvat časem na nedůležité věci a části, u kterých není přesně stanovená funkčnost
• několikrát se ptát, zda je daná funkčnost opravdu nepostradatelná
• nevyjasněné úkoly odkládat co nejdéle, pokud je to možné
• v určité fázi projektu již není důležitá specifikace, ale osobnost projekt managera, který musí znát odpověď na jakoukoliv otázku
• úspěch projektu záleží hlavně na jeho vedení

• jasnou vizi
• povědomí o všem okolo, co je projektem dotčeno
• musí si umět obhájit sve myšlenky
• musí vědět všechno
• musí s projektem žít

Samozřejmně, že celá problematika je daleko složitější. Všechny myšlenky, které jsem zde uvedl vycházejí z praxe a můžou se lišit v závislosti na organizaci.