metodologii vyvoje softwaru jako je Vodopad se vyvoj vyklonil opacnym
smerem:
Spousta projektu je velmi malo rozmyslena, ma mizernou nebo vubec zadnou
dokumentaci. Nektere nemaji ani README.
No to je pravda, ale co uz ma clovek delat kdyz nejakej debilni obchodak
uzavre smlouvu ze to jsme schopni udelat klidne do zitrka, takze je clovek
nucenej to pomalu delat hnusne bez jakekoliv analyzi, asi tak jako kdyz
programoval kdyz mu bylo 15.
Smlouvu podepisuji vzdy dve strany. Debilni obchodak tu neni od toho, aby
tohle rozhodoval. Clovek, ktery smlouvu podepise za tvuj tym, ma byt
informovany dostatecne tak, aby vysvetlil klientovi _financni_ a _casove_
vyhody toho, ze se udela analyza alespon v mire nutne. Tim se dobry obchodak
tez vysvihne nad konkurenci, nebot na nem bude znat, ze to tym ma vosefovany.
Klient a vyssi mgmt nezajimaji komplikace programatora a je to tak spravne.
Je zajimaji prachy a cas. Neznam primo tvou situaci, ale mam zato, ze pokud
se od tebe jako sefa tymu ti podstatni lidi nedozvi, ze si nezahrnutim
dokumentovane analyzy (byt miniaturni) pridelavaji soucasne, ale hlavne
budouci naklady, je to tak nejak i tvoje vina.
Cestou je jednak toto vysvetleni. Dalsi cestou k uleve je pouzivat jazyky a
frameworky, pri jejichz pouzivani nejsou "agilita" a "zmena" sprosta slova.
V Pythonu a Djangu jsem schopen prepracovat koncepci projektu (samozrejme ne
vsech) v radu hodin. Klient to nebyl schopen rict na zacatku, klient chce
zmenu, klient ji zaplati (a nektery se jeste omluvi). Proc mu za to nadavat?
Kdyz budes brecet po starejch dobrejch casech, tak nejak prehlednes vyhody
novejsich vyvojovych modelu vychazejicich z toho, ze kolem nas programatoru se
uz jaksi netoci svet. Uz nejsme ti, kolem kterych se nakracuje po spickach.
Nebudou se s nami mazlit a o co si razantne nereknem, to nebude. Agilni vyvoj
vznika mj. jako reakce na toto.
Pro zakaznika i vyssi management je dulezite aby to alespon vizualne
vypadalo
jako hotovy produkt i kdyz streva to ma zatim skoro prazdna a vetsina veci
nefunguje a nebo je zabugovana (styl "to se jeste trochu doladi a bude to
dobre")
Ale ono je vzdycky dobre ukazat klientovi co nejdriv zvonky a pistalky. Duvodu
proc je rada.
Pravdu povedit, uz jsem celkem dlouho nepracoval na projektu kde by se
nejdrive delala dobra analyza procesnich toku, delal ERD diagram a tak
podobne. Za starych dobrych casu jsme na analyze travili polovinu casu
projektu a tim automaticky byla dokumentace v hrubych rysech hotova jeste
predtim nez byla napsana prvni radka kodu.
A byla tak slozita analyza vzdycky potreba?
T.
|