ZARREMGREGARROK: Imho i kdyby si to dělal třeba pomocí TDD (test driven development), který umožňuje větší modularitu (když je dobře aplikován), protože člověka k tomu vede a vede pak k menší závislosti na jiných objektech, protože při psaní unit testu ex-post pak už může být obtížné takový test napsat, tak k tomu nějakou analýzu potřebuješ
(Google třeba na přednáškách o TDD říkali, že vlastně umožňuje softwarový design takhle za běhu)
Na TDD a jiný Agile postupy potřebuješ mít aspoň nějaké jasné zadání a analýzu. To že se lidi potkávají, říkají si, co dělali minulý týden, jsou více v kontaktu a vývoj je více krokovýn na kratší (týdenní) celky si mnoho firem dnes (moderně) aplikuje do vývojového procesu. Jak to řeší absenci zadání a analýzy?
Vždycky se ti mění do nějaké míry jak zadání, tak i nutnost odklonit se od původní analýzy, ale že žádnou nepotřebuješ, je teda dost odvážné tvrzení.
Agile je filozofie, způsob jak managovat projekt, aby umožňoval snadnější odolnost na změny v průběhu. Že by ale někdo dělal projekt nemajíc zadání (u pokladen jsou jen jakési "draft" požadavky, které si některé dokonce protiřečí) ani analýzu, slyším poprvé. No, slyšel jsem teda už slušný zvěrstva kolem IT (viz.
http://thedailywtf.com )
Každopádně tohle všechno jsou filozofie až někdy vnímány až nábožensky a názory programátorů se liší. Někteří např. koukají na TDD skrz prsty. Ve výsledku ale tak nebo tak píšeš nějaký kód (TDD myslím má nejblíž k technické stránce věci,ale řadě programátorů to přijde jako blbost psát nejdřív test na něco, co neexistuje. Pak napsat kód, a později refaktorovat a sledovat, jestli test stále má zelenou barvu)