Jak poznat vodopád

Dnes budu psát o vývoji pomocí metodiky vodopádu. Pro připomenutí uvedu její popis (přesný a naprosto nezaujatý):

Na začátku od zákazníka získáme dokonalý popis toho co chce. Poté to hodíme analytikům/architektům, kteří udělají bezchybný návrh a předají ho programátorům. Ti to naprogramují a předají testerům na otestování. Výsledek se pak s velkou slávou dodá zákazníkovi. To celé obvykle trvá několik měsíců. Vodopádem se to nazývá proto, že tok je výhradně od shora dolů, návrat je možný jenom mezi sousedními fázemi. Tzn. analytik/architekt může vyžádat upřesnění požadavků, tester může program poslat zpět programátorům atp.

Tento model má několik menších nedostatků, uvedu jich jen pár namátkou:

  1. Zákazník obvykle nemá moc jasno v tom co chce. A i kdyby byl zákazník dokonalý, dokument, který přesně a úplně popisuje netriviální systém je téměř nemožné sepsat.
  2. I kdyby měl architekt dokonalý popis toho co si zákazník přeje, není možné udělat přesný a bezchybný design systému. (Je to možné, ale takového architekta neseženete)
  3. Vývoj trvá zpravidla delší dobu. Nicméně se vstup od zákazníka je možný jenom na počátku procesu. Je téměř jisté, že se požadavky zákazníka za tu dobu změní. Vodopád na to není vůbec připraven.
  4. I kdyby se požadavky uživatele nezměnily, zpětnou vazbu od zákazníka dostaneme až na úplném konci projektu. Kupodivu se často stává, že je zákazník nepříjemně překvapen, že dostává něco úplně jiného než co si představoval (a co potřebuje).

Takže skoro všichni kdo se ve vývoji software pohybují, vědí, že vodopád není ideální. Proto také často tvrdí, že ho už dávno nepoužívají. Všichni používají RUP, Scrum, XP a kdoví co ještě.

Můj soukromý pesimistický a subjektivní pohled ne věc mi našeptává, že jde jenom o zástěrku. Takže někdo dělá vodopád se jménem RUP, někdo dělá vodopád se jménem Scrum a někdo dělá naprosto chaotický a neřízený vývoj a říká tomu XP. Vymyslel jsem si jednoduchý test jak vodopád zaručeně odhalit. Moderní metodiky mají jedno společné. Jsou iterativní. Tzn. jde o sekvenci iterací – malých vodopádů zřetězených za sebou. Vodopádů se vším všudy, tzn. včetně testování, integrace, nasazení a předvedení zákazníkovi (u RUPu je tam pár odlišností). Pokud jsou tyto iterace dostatečně krátké, máme šanci případné chyby opravit, neporozumění napravit a změny zapracovat v další iteraci.

Takže jak zjistit, jestli někdo praktikuje vodopád? Stačí se ho zeptat, kolik má jeho projekt iterací. Pokud odpoví jedna nebo dvě, tak už je jasné, že slyšíme nezaměnitelný hukot vodopádu.

6 thoughts on “Jak poznat vodopád

  1. lzap

    Nazývat XP “chaotickým a neřízeným” — to se mi moc nelíbí. Samostatná část XP zvaná TDD má například jasná pravidla: napiš test, zprovozni ho, napiš kód, review.

  2. Lukáš Křečan Post author

    To Izap: Plně s vámi souhlasím. Snažil jsem se napsat, že lidé jenom říkají, že používají XP, zatímco programují choticky a neřízeně. Používají z XP jenom jméno a tím obhajují to, že projekt neřídí. (trochu jsem teď danou větu trochu přeformuloval, aby byla jasnější)

  3. Honza Novotný

    S tvrzením, že firmy používají agilní metodiky popř. XP i když by pro ně spíš seděl termín “chaos programming”, jsem se setkal taky už mnohokrát. Je to škoda – protože tím XP a agilním metodikám jenom škodí. Někteří zákazníci mají po pár špatných zkušenostech s “agilními” firmami tak zkreslenou představu (a ani se jim nedivím), že jakmile se o těchto přístupech jenom zmíníte, už se na vás dívají skrz prsty.

  4. srakyi

    Docela nebezpecny je ale podle mne i dojem, ze nasazeni nektere agilni metodky spasi svet.
    Nerikam ze jsou agilni metodiky uplne na nic, ale je vzdycky potreba hledat ten spravny kompromis – urcite by se daly najit projekty, u nichz by jste s XP dopadli urcite jeste hur nez s vodopadem. To ale neznamena, ze by treba vyuziti *nekterych* practices z XP nemohlo docela pomoci ..

  5. Lukáš Křečan Post author

    Určitě, jsou projekty u kterých jsou agilní metody nepoužitelné. Článek byl spíše proti tomu, jak spusta lidí a firem tvrdí, že používají RUP nebo Scrum, ale ve skutečnosti jde o vodopád křížený s chaosem.

  6. Pingback: Java crumbs » Blog Archive » Co je na Scrumu to nejdůležitější?

Comments are closed.