cisty waterfall je tema pre akademikov, rovnako boj s nim. v praxi to je farebnejsie, vzdy existuju nejake iteracie len sa to tak nevykazuje a nefakturuje. tema je ako tomu pomoct aby to slo lahsie.
ale “ na kazdy zlozity problem existuje jefno lahko pochopitelne nespravne riesenie” a zda sa ze toto je ten pripad.
vyborna hlaska “…minimalne jedno…” a uz to bude dokonale.
To ci funguje waterfall alebo agile, je vecou pristupu a ludi na projekte, hklavne manazmentu projektu a nie v samotnom sposobe. Funguje aj nefunguje aj jedno aj druhe. Ako vsak aj vcera bolo jasne povednae OPII nemoze byt Agile, statne projekty mimo OPII mozu byt Agile, ale stat a jeho ludia zatial na to nie su pripraveni
Nesuhlasim. Ci bude fungovat waterfall alebo agile je dane typom projektu/prostredia (nejasne zadanie, rychlo sa meniace sa prostredie…). Mozes mat najlepsieho manazera na svete, ak ho donutis robit cyklus DFS, implementacia, akceptacia, deploy na projekte, ktoremu sa po ceste bude 5x menit zadanie, tak to inak ako zlyhanim dopadnut nemoze. Otazka teraz skor je, ze ci vacsina egov projektov je taka, ze vieme co chceme alebo nevieme resp. ci sa nieco bude turbulentne menit po ceste alebo nebude. Podla toho si treba vybrat sposob vyvoja.
Ak zakaznik nevie co chce, tak mu ani Agile nepomoze. Len tak na okraj: Kto je zakaznikom pre eGov? Nuz obcan, firma atd., ale nie ministerstvo. Takze ak niekto chce robit sluzby pre obcana a firmy, tak sa ma spytat ich ake chcu sluzby a nie vymysliet za nich a snazit sa ich do toho dotlacit, potom vysledok nemoze byt iny a je jedno ci pouzijete waterfall alebo agile. Len taka poznamka pod ciaru, bolo niekolko uspesnych velkych statnych IT systemov vybudovanych aj v tejto republike waterfallom a nepoznam jeden velky IT statny system Agilom na Slovensku (v sukromnej sfere ano) a doporucujem si precitat studiu od Delloitu v tomto vlakne nalinkovanu, kedy moze agile zafungivat na velkych statnych systemoch.
No urcite mu to pomoze viac ako waterfall Minimalne to bude vediet nejako rozumne ukoncit a netlacit pred sebou.
A co uradnici? Ci to su ti ludia?
Trosku sampling bias nie?
pokial beries agile ako dogmu, tak mam pochybnosti ci je vhodna na vacsie projekty, ale ak z nej pouzijes rozumne veci tak urcite je pouzitelna aj statne projekty. Nevidim napriklad problem v tom ze niektore casti ( hlavne casti user interface ) mozu byt vyvijane agilne. Pripadne aj analyza moze byt agilnejsia, nie tak ze na zaciatku sedia analytici a pocuvaju a potom po troch mesiacoch poslu tisic stran, ktore ma niekto schvalit. Niektore casti mozu davno predschvalene v agilnom mode. A toto sa v niektorych projektoch dialo, ide to.
Ale casti kde nemas uzivatela a spatnu vazbu dostanes az ked to zapasujes do celku, tak si agile neviem predstavit. Ale mozno mam len malu predstavivost 
Neviem ako v OPII chcete urobit Agile, v principe mozte dosiahnut len nepodareneho bastarda, co nebude lesie skor naopak. Ak napr. Socialna poistovna budr nutena vymenit svoj Cobol dochodkovy base, pretoze uz nema ludi na udrzbu a rozvoj a nebude ho vediet “owrapovat”, tak bude musiet vybudovat novy system (podla mna uz skoro po funuse) a tam Vam ziaden Agile nepomoze, ani zastavit sa projekt nebude dat, ptetoze musi aj keby neviem aky problem nol, uspesne skonciy, pretoze ina dochodky budu tobit v exceli, tak ako robia ine veci, napr. stavebne konania a ine. Proste “dom nema zaklad”, ale riesime sku koncovku bude mat komin a aka bude fasada.
Ja som niekde tvrdil, ze socpoist cobol-base sa ma urobit nejako agilne? Naopak, toto snad ukazkovy priklad toho, ze tam je extremne dobra znalost toho “co treba urobit” a pravdepodobne sa to menit nebude (pokial s tym nepride nejaka reforma) => da sa DFS vytesat aj do kamena => vodopad.
Ja uz naozaj neviem ako tu napisat, ze aj agile aj vodopad funguju resp. nefunguju v nejakych kontextoch.
Hovorim takmer to iste, lenze nie je to len o kontexte, je to hlavne o ludoch, vztahoch, zmluvach, obstaravani, financiach, takze nemozte sa rozhodvat len na zaklade kontextu, pretoze ked neviete k tomu urobit spravnu zmluvu (nie na pevny predmet, nie na pevne financie, nie na pevne etapy, …), neviet urobit obstaravanie na taku zmluvu (nerozhoduje len cena, mozte urobit taku zmluvu aku potrebujete, …), ma zakaznik ludi na to vhodnych a maju na to kompetencie a chce sa budovat vztah (agile okrem ineho je o budovanoi vztahu, nie je jednoduche menit timy a dodavatelov) atd. Takze sorry, kontext nie je urcite viac ako 50% pri rozhdovani
Nuz aby ste nebol prekkvapeny, ze dochodkovy system je len tak vytesat do kamena (aj tam je mozne menit a optimalizovat procesy a nerobit vsetko tak ako sa robi 25 rokov)
Ale no tak už. Hovoríme o projekte výmeny cobolu, nie reforme. Zase netreba oponovať za každú cenu.
1 Like
Kolegovia ja sa uz stracam
Naozaj niekto veri, ze waterfall(taky, ktory je v ostrom protiklade voci agile) je realny, ucelny, efektivny? Existuje priklad uspesneho projektu radovo stovky az tisice MD (aj v komercnej sfere), pokryvajuceho nejaku priemerne zlozitu domenu, kde vyvojovy team dostal analyzu/navrh a nemal uz otazky? Kde nechodil za analytikom s otazkami, ten analytik nechodil preverovat k zakaznikovi, ked si nebol isty, nerobila sa dodatocna analyza a neprisposobovala sa implementacia za jazdy, ked nieco prestalo hrat(vynimka alebo rozsirenie scenara, ktora analytika pocas analyzy nenapadla) etc.
Sprostredkujete mi nahliadnutie do takejto analyzy?
Pointa:Otazka nie je ci Agile, ale do akej miery/v akej forme.
Nuz ked budem menit taku Appklu, tak snad nebudem taky zadebneny, ze uz nepouvazujem o zmenach, aby appka bol vobec pripravena na dochodkovu reformu, kt. bude musiet prist alebo potom bduem robit druhu pretoze poviem to som len vymenil Cobol? No gratulujem.
Zbasterdeny Agile je mozno niekedy horsi ako waterfall. Waterfall predsa tiez nie je pravda, ze analyza sa neupravuje, analyza sice na zaciatku sa urobi na cely system alen analytik zije pocas celho projektu az do konca a analyza sa upravuje v case (napriek tomu, hze je waterfall). Ano, urcite su priklady uspesnych projektov waterfallom robenych.
Neviem, podla mna si zahodil zbrane aj pri tomto priskoro. OK, nahrada existujucej aplikacie. Domenovy experti poznaju ako fungovala povodna aplikacia. Niektori z domenovych experov maju nazor na to, co bolo zle. Cim dlhsie ju pouzivali, tym viac je ohnute ich myslenie.(to je prirodzene) Pri troche stastia tam bude nejaky expert, ktory len velil a appku nepouzival. To je vychodisko. Pridana hodnota pri prerabani takejto aplikacie bude asi aj o tom urobit to efektivnejsie z biznis hladiska, zmenili sa mozno aj technologicke moznosti. Ak neexistuje takyto driver, preco by nemali nadalej fungovat v starej aplikacii.(ok, niekde mozno EoL, berim do uvahy) Tu je ten agilny vyvoj (paradoxne) rovnako ucelny. Postupne ti experti, ak maju dobreho partnera sa oslobodzuju od starej schemy myslenia zajateho v praci s aplikaciou(je bezne ze sa supluje na zaciatku biznisovejsi pohlad a experti hovoria o obrazovkach, kde kliknu a kam co zadaju) ak su spravne integrovani, postupne zistuju ake su moznosti, ucia sa mysliet po novom a sami zacinaju zistovat co vsetko bolo neefektivne, kreovat atd.
Tuto pan jody dal priklad, ze “haha to som zvedavy ako to agile spravite pri vymene cobol-base v socialke”, potom som mu povedal, ze vymena je predsa jasny waterfall, lebo specka je jasna, dokonca aj limitacie su jasne ak sa nerobi velka reforma. Potom pan jody, povedal, ze “to by si bol prekvapeny, ze ako sa da menit dochodkovy system” a zakoncil tom teda tym, ze by si musel byt riadne zabedneny, keby si chcel robit novy system tak, ze nebudes uvazovat o zmenach.
Nejako ma toto cyklenie prestalo bavit a netusim, co sa tym vlastne chcelo povedat. Nijako to debatu neposuva, ospravedlnujem sa, ze som to tu sposobil uz budem ticho.
2 Likes
Ach, ja som Ta chcel podporit v tom, ze aj pri prerabke existujucej appky ma agile zmysel. (=urobil si zbytocne skoro zaver, zlozil zbrane), A ak zmysel nema, tak nema ani zmysel prerabat appku (samozrejme, problem zostava to VO, to ma zase Jody pravdu)
mne uz teraz unika o com je debata. Tak inak, s agilnym programovanim nemam priame skusenosti, to co o nom viem je zalozene len na par strankach a ked pocujem maly tim co sa sam organizuje a jeho clenom je clovek od zakaznika co priamo urcuje poziadavky a ich prioritu, tak jednoducho to neviem naparovat na realitu pre velke projekty.
Za druhe, klasicky waterfall zanikol este v mojej mladosti, najcastejsie som pracoval v RUP a ta predpoklada iteracie v ktorych sa robia zmeny ale rozhodne nie je agilna v zmysle ze maly tim pracuje samostatne.
Boj s waterfallom je cisty boj so slamennym panakom, tomu sa podobaju akurat fakturacne milniky ale to je tak vsetko.
2 Likes
Vsetko sedi. Scrum ako konkretna podoba/forma agilneho vyvoja(jedna z mnohych) je usita na produktovy vyvoj a riesi (barlicka) az take veci, kto v teame vari kavu. Problem je, ze vacsina ludi chape pod agile parave tuto jej konkretnu formu alebo aspon ma predstavu formuovanu zoznamenim sa so scrumom.
RUP ako (ina, jedna z) metodologia reflektoval principy agilneho vyvoja davno pred scrumom. A pricnipy agilneho vyvoja su zname uz desatrocia. Dilema agilneho vyvoja je tu v podstate od pociatkov SW vyvoja. (a RUP, zjednodusim, si myslim, ze je to spravne vychodisko pre eGOV projekty, hoci neprecenujem vyznam ziadnej metodiky ani neprecenujem jej moznost samej nieco vyriesit. A on sa tam svojho casu aj sklonoval.)
Cize clovek, ktory ma pred ocami RUP. je patologickym vstupencom agilneho vyvoja. Samozrejme popritom moze ako neadekvatnu odmietat predstavu o tom, ze by sa agilna forma odvodena od Scrum dala aplikovat v eGov prostredi.