Uz nebudem pisat v tomto vlakne, detailnych metodik vyvoja su desiatky. Iterativny vyvoj (stale je iterativny, otazka ci ta iteracia je interna a aka silna v tych iteraciach je spolupraca s koncovym zakaznikom a ci sa realne iteracia konci odovzdanim niecoho co ide zakaznikovi a do prevadzky). dalsim faktorom je ci na zaciatku presnne viem co idme robit,a el mam len matnu prestavu co chcem riesit, stale je to o 3 suvztaznych veciach (co mam dodat, aky je termin, kolko to stoji), ktore su z toho pevne a ktore menitelne. Ak mam vsetky 3 veci pevne definovane, tak v ziadnom pripade nemozem hovorit o metodike Agile (RUP ano). Agile moze byt aj vo velkych timoch, pretoze tie sa delia na viacere timy a pracuju paralelne, kde kazdy zije svojim zivotom (samozrejme je to tazsie zmanzovat a dat dokopy, ked Agile nema v principe Projektoveho manazera, takze koordinacia timov je mozno troska zlozitejsia). Iteracie vo waterfalle (interne bez uzkej kooperacie s end-userom a bez odovzdavania inkrementu do prevadzky) sa pouzivaju od kedy sa SW vyvija (inak by sa nikdy nic vacsie nespravilo).
Myslím, že toto mi vysvetlilo všetko čo som si potreboval potvrdiť. Ďakujem.
Chvilu som rozmyslal, ci budem este rragovat ale ok, skusim to rozpliest. Tato diskusia ukazuje, kolko casu sa vyplytva na nejake zakopove vojny a pritom si staci pozametat v pojmoch a normalne si veci vysvetlit.Polovica ludi zisti, hovoria o tom istom len to inak valaju a druha polovica riesi vykonstrukovany problem. (podobny problem diskusia na temu SOA,Microservices etc.)
Dakujem. Na existenciu roznych metodik som uzporonoval. Cize uz to nie je ten ciernobiely svet “waterfall vs. agile”. Zrejme si ale nepostrehol, ze ja som hovoril o PRINCIPOCH agilneho vyvoja, ktore su premietnute v tej ci onej miere do nejakej METODIKY. A iterativnost prave takym premietnutim je. (po kazdej iteracii o.i. robis redesign na zaklade feedbacku aj od pouzivatelov, to je jeden z hlavnych zmyslov iteracie)
otazka ci ta iteracia je interna…teracia konci odovzdanim niecoho co ide zakaznikovi a do prevadzky
toto bola skareda barlicka… riesime vztah dodavatel a zakaznik, cize iterativny vyvoj, ktory je pre zakaznika neviditelny nie je zaujimavy. (nie je to iterativny vyvoj a nie je to RUP)
dalsim faktorom je ci na zaciatku presnne viem co idme robit,a el mam len matnu prestavu co chcem riesit,
Vyssie som sa pytal, ci existuje projekt, ktory zacinal tak dokonalou analyzou, ze nebolo treba chodit za zakaznikom a upresnovat, dalej hlbsie analyzovat, ze sa behom implementacie veci neprisposobovali/neprerabali. Ja tvrdim, ze taku nikto nikdy na projekte pokryvajucom komplexnejsiu domenu nemal v ruke.
Pri RUP mam requirementy ale nemam detailnu analyzu. (mam zanalyzovane requirementy po urcitu uroven). Navyse si pozri ten tradicny farebny rup obrazok, analyza sa prekryva napr. s impementaciou. To je ten “waterfall”?
Ak mam vsetky 3 veci pevne definovane, tak v ziadnom pripade nemozem hovorit o metodike Agile(RUP ano)
To je spravny zaver… AK, TAK zaver(s vynimkou toho RUP samozrejme). Akurat sme spat pri otazke, ci naozaj mozes mat realne dokonalu a dostatocne detailnu analyzu, aby bez upresnovania a ziskavania priebeznej spatnej vazby od zakaznika mohol vyvojovy team spokojne vyvinut a dodat a zakaznik bude happy (predpokladame urcitu komplexitu)
Pri RUP mas na zaciatku k dispozicii poziadavky (requirements)… po urcitu uroven. Analyza sa riesi iterativne a prekryva sa aj v ramci iteracie s implementaciou.(tak ako ine cinnosti)
Agile moze byt aj vo velkych timoch, pretoze tie sa delia na viacere timy a pracuju paralelne
ano, moze, tvrdim nieco ine? (akurat nutnost urcitej vzajomnej koordinacie mieru tej do urcitej miery limituje)
Agile nema v principe Projektoveho manazera
dalsia skareda barla…a “v pricipe”…takze si to aj uvedomujes…ano, specialne pri produktovom agilnom vyvoji (povedzme scrum) je riadenie rozprestrete medzi productownera,scrummastera a samotny team (z hladiska rozdelovania uloh ma team autonomne postavenie). A v realite specialne ak je tam rozmer koordinacie roznych teamov je to este pestrejsie. Co z toho vyplyva?
Mam niekoho, kto sa vola projekt manager = waterfall, nemam = agile? 
Ak budem mat projekt, kde budem mat tyzdenne iteracie a zakaznik mi bude diktovat co v danej iteracii robit a bude tie ulohy pridelovat nejaky PM, povie mi, kolko mi to ma trvat, nebude si ich vyberat zo stacku team. Nebudem mat “agile”(aplikovane niektore agile principy)? (toto sa urcite nesnazis povedat, vsak)
> “Iteracie vo waterfalle”
su oxymoron…su to mozno etapy/fazy ale nie iteracie (aj ked najdes urcite niekoho, kto to nepochopil a snazi sa medzi tym lavirovat)
uz len jedna poznamka, ak sa cchete Agile bavit o tom kto je end-user, tak je to obca a predstavitel foimy a nie uradnik na ministerstve (ten je az v druhom-tretom rade). Takze eGov Agile robte s realnym end-userom
Naco bol dobry tento vystrel do tmy?
Aj pri scrum definuje/riadi features v backlogu product ower, neriadi ich pouzivatel (primarnym akterom pri casti UC ale je aj uradnik - pisal Ti Jano uz vyssie a vzdy je ten uradnik aspon stakeholder).
Mimochodom ano, ak je to mozne, treba co najskor ziskat spatnu vazbu aj od “end-userov”. (a ak to dava aspon trochu zmysel a je to ucelne, tak aj na eGov projektoch)
za mna len poznamka, snahu zvysit agilitu povazujem za fajn. Ale v situacii ked ked trva 5 rokov od myslienky k VO je to jednoducho menej podstatne. A kratky cas na realizaciu sa podpise na tom ze to agillitu len potlaci a rovnako kvalitu. A umele snahy dostat do metodiky " quasi agilitu" su kontraproduktivne.
A pravda je tiez taka ze metodika nie je vseliek, a vzdy je potrebny aj “zdravy rozum”.
S tymto plne suhlasim, dokonca to o tej metodike pisem vyssie.(a uznavam, ze som schizofrenik, viem, ze sa bez urcitej/primeranej miery agilnosti neda robit kvalitny SW, ale nemam zazracne riesenie v sufliku, specialne v kontexte VO. Napady nejake mam, ale kazdy sa moze zvrhnut. Vsetko je na konci dna v tej, ci onej miere o profesionalnej cti a nejakom prostredi, kde to bude hrat rolu)
nasiel som zabavny diskusny prispevok do temy https://index.sme.sk/c/22525643/nemecka-dialnica-do-kosic-s-hanbou-otvorili-bizarne-letisko-v-berline.html?ref=trz
nie je to it ale stavebnictvo, ale na zaciatku boli dobre napady s delenim zakazky, agilitou, odstranenim diskriminacie v podobe referencii.
stoji za precitanie
Dobra paralela s tym co sa chysta, len to mali troska jednoduchsie, v stavebnictve nie su zdrojaky len projekty
Bohuzial neviem si to precitat, ale viem si domysliet. Co sa tyka urcitej miery agilnosti a delenia zakazky, moze to byt v protiklade.(napr. je cudne ak v strategickom dokumentu hovorim o tom, ze analyzu ma riesit niekto iny ako implementaciu a zaroven hovorim o tom, ze chcem viac agilnosti)
v skratke, prisli s napadom ze ked takyto velky projekt rozdelia na kusky tak bude obstarany lacnejsie a skoncili s 35 dodavatelmi, zakaznik zacal menit predstavu co chce a potom sa im cely projekt rozsypal. a tak to stalo o 3 mld viac a o 8 rokov dlhsie. A k tomu sudne spory, neplatenie faktur. no skoro ako na slovensku. Nehovorim ze to delenie bolo jedinym dovodom ale zvysilo riziko a tu sa to nevyplatilo.
JA ten nezmysel, ze 1 robi analyzu a iny programovanie, vidim tak, ze nova zalozane firma s programatormi nema analyticke schopnosti a chce mat vlastny biznis, tka nech niekto urobi analyzu a ked porozumeju biznisu, tak uz to dopracuju so zakaznikom. Proste ucel svati prostriedky, ale rad by som sa mylil, pretoze ten nezmysel hlavne v suvislosti s agilitiou, zatial nikto nevysvetlil.
Na margo agilinosti a delenia zakazok:
Nerozumiem potrebe v argumentacii vzdy pouzivat extremne priklady ci uz waterfall alebo agilnosti a takisto extremne priklady delenia zakazok pomaly na microservice - ani jeden extrem nieje spravny.
K deleniu zakazok - mali by sme si veci povedat narovinu ani zdaleka nie sme v takom stave ze by sa uz zachadzalo do nezmyselneho delenia zakazok na granularitu ktora sa neda beznymi kapacitami na strane zakaznika ustražiť. Prave naopak podla mna sme vstave ze sa zakazky stale extremne spajaju bez dovodne - uvediem priklad a nebudem chodit daleko do minulosti ( budem abstrahovat od poznamok typu ci sme to potrebovali alebo nie a ceny za projekt)
- projekt https://www.crz.gov.sk/zmluva/5053015/ - hodnota cca 17m - dodavetal interway
-
zmluvu uzatvoril jeden dodávateľ - má evidentných subdodávateľov a velkých -
-
delenie je zrejmé niekto dodá licencie niekto prácu a tá práca sa dá tiež delit nakonci dna ide len o popridávanie imagov do ICO a nakonfigurovanie, kludne sa to dalo rozdelit do minimálne 4 súťaží - licencie, Natívne PaaS, Licenčné PaaS, Dev OPS - a kludne aj v case a podla potreby sa to mohlo obstarat - cize onebostoji ani argument že v prípade že jedno obstarko zlyhá dostaneme sa do sklzu
- projekt https://www.crz.gov.sk/zmluva/5049685/ - dodavatel Anasoft - cena diela cca 5m
- v rámci diela sa dodáva agendový systém pre podporenie agendy IS KaSP
- ERP - čisto vnútorná správa takmer vôbec neprepojená na agendový systém - obsahuje mzdy, presonalistiku, evidencie majetku a pod
- podporné systémy - zmeska rôzny aplikácií z ktorý by sa taktiež dali vyselektovať samostatné zákazky nesúvisiace alebo minimálne súvisiace hlavným IS KaSPnapr archív, reporting a DWH
a takto sa dá ísť rad radom projekt za projektom. a argument že treba velkého systémového integrátora neobstojí lebo tia jednotlivé časti spolu takmer ani nesúvisia
K agilnosti podľa mňa ak budú zákazky správne rozdelené tak v rámci každej dodávky je možné rôzna variabilita stupna agilnosti, a za posledne roky som sa nestretol teda s projektom ktory by bol striktne waterfall ze tu je DFS a co tam nieje napisane neplati a musi to byt len presne co je napísané (takýto posledný dodávateľ ktorý to robil bol Ditec a NESS). Každý dodávateľ bez problémov a vo vlastnom záujme komunikuje so zákazníkom a snaží sa mu vyjsť v ústrety aby bol spokojný, otázka je len tá miera že dokedy vychádzať v ústrety dokedy projektovemu manažerovi dovoli budget projektu ? a tu nastupuje otazka ake su marze projektu a kam by mohli jednotlive firmy az zajst v rámci agilnosti ? (a na to si na slovensku vo verejnej sprave nech kazdy odpovie sam. :D:D)
Zaver za mna - stale axistuje velky priestor pre uplatnovanie vačšej granularity zakazok, a takisto pri tych government cenach je podla mňa možná aj velká miera agilnosti práve v časti scopu.
Problemom je VO, ktore na Slovensku nefunguje a kazda druha sutaz nekonci zmluvou, niektore trvaju 100 dni a neiktore aj 800dni. Nuz a ked rozdelite zakazku na casti a na samostatne obstaravania a jedna cast nema zmysel bez druhej casti, tak potom delenie je kontraprodktivne. pretoze napr. nebudete vediet dodat svoju cast bez niecoho co neexistuje. Takze aj tento problem je potrebne brat v uvahu (hlavne kym mame VO ake mame). A ten priklad s berlionskym lletiskom si je potrebne tiez precitat. inak, ale nemam nic na delenie na castio ak sa to naozaj rozumne urobi, nebude sa delite tak, ze jedno bez druheho da neda odovzdat alebo pouzivat.
Este si je potrbne uvedomit, ze urobit 4 VO napr, na 1,5m EUR je pracnejsie ako jendo na 6M EUR a dtto schvalit v Bruseli 4 proejkty meisto jedneho (ak to bude z EU fondov), bdue to takisto viacej
kontrol atd. atd.
K agilnosti podľa mňa ak budú zákazky správne rozdelené tak v rámci každej dodávky je možné rôzna variabilita stupna agilnosti,…ze tu je DFS a co tam nieje napisane neplati
presne tak. Nevierim, ze niekto z praxe moze mat na to iny nazor. Jedinou (tazkou) otazkou je, ako tu agilnost premietnut/sformalnit aj do VO a realizacie projektu. Opakujem sa asi…aby to nebolo len o profesionalnej cti dodavatela/realizacneho teamu. Bez urcitej miery agilnosti sa neda uspesne (nemusim rozvadzat, ze sa tym nemysli vyfakturovanie) realizovat ziaden trochu komplexnejsi projekt.
Myslim, ze to @Joz vysvetlil. Akademicky. Tam, kde je prirodzena vysoka miera kohezie konkretnych kompenentov, nema zmysel delit zakazku. Tam, kde medzi nimi neexistuje ziadne previazanie alebo sa praveze ocakava volne je ziaduce oddelit aj z hladiska VO. Nasilne delenie zakazky(popri tom vsetkom, co bolo spominane vyssie pri priklade z nemecka) povedie popri vsetkom aj k ovela vyssej komplexite. Naopak, ak sa oddelenie ocakava rozdelenim zakazky sa lahsie vynuti volne previazanie. (samozrejme netvridim, ze volne previazanie nema zmysel (s rozumom a v primeranej forme) aj v ramci ucelenej dodavky, pre istotu…)
…a zase len povzdychnutie pri vsetkej skromnosti, ze kde su ti architekti, ktori toto budu strazit. Matne si spominam napr. na jeden “stratetegicky” dokument na temu “microservices”, ktory bol velmi zlym prekladom/plagiatom a autor zjavne nerozumel tomu, co preklada.(pochopil som o com pise, az ked som sa dostal ku vykradanemu zdroju) A takto to tu funguje roky, bolo treba nieco konecne vyproduktovat, akvizovat nejaky “buzzword”, tak sa to urobilo. Miesto sirenia osvaty, postupneho zavadzania principov, budovania autority, ku ktorej bude clovek vzhliadat a chodit po rozumy, moze IT trh/dodavatelia vzhliadat akurat ku zlym plagiatorom.
este k tej agilnosti moj osobny postoj - pri pevne stanovenej cene radsej budem dodavat agilne zakaznikovi to co chce a ukazovat to stale, dodrziavat neake zasady CI/CD - a dovolim mu to az do takej miery ze radsej ako robit DFS so stanovenym scopoma ist strikne podla nej, tak radsej ked uz nebude budget sa budem so zakaznikom hadat aby pochopil ze aj on to musi cutnut poziadavky lebo budget je uz na konci - a mam na to jednoduchu vyhovorku komu sa chce robit v dnesnej dobe robustna DFS ? - radsej spravim kvalitnu prevadzkovu a pouzivatelsku dokumentaciu ale DFS bleeee -
a tu je prave priestor na to ako dostat agilnost do VO aj eurofondovych projektov - mame zakladne ciele ktorych si je vedomy ziadatel aj dodavatel a treba ich plnit v zmysle ZoNFP - ale ani v Studii ani ZoNFP nie je detailne povedan ze ako sa to ma spravit. Jediny problem preco sa robia komplikovane DFS je ze je v ZoNFP uvedena faza Analyza a Dizajn a tvrdohlave QA bude vyzadovat komplexne robustne vystupy z tejto fazy. Aby sa mohla premietnut aj vyssia miera agilnosti do eurofondových projektov je ze treba zmenit postupy QA (napríklad že nebudú hodnotiť prces tvorby, procesy pripominekovania a schvalovanie DFS ale budú v zmysle princípov agilnosti hodnotit či sa doržiavaju sprinty, ako sa zadávajú a poťty kolko sa realizuje taskov v rámci šprintov, dodržanie zapojenia zákazníka do procesu development a spôsob schvalovania taskov, hodnotili by pokrytie kody testami - proste nastavenie CI/CD. Zaver: vidim priestor aj v súčasných existujúcich nástrojoch SORO práve v úprave metodiky QA
Bolo by dobre aby to niekto najprv pilotne par razy overil, skor ako to zacnu aktivisti natlacat do povinnych metodik.
Osobne to vidim mierne odlisne, hlavne tu agilnost 
Ale veci sa daju menit, ale nie tak ako dnes. Verba movent, exempla trahunt
suhlasim a netvrdim ze v metodike QA to musi byt ako povinnost lebo to je tiez blbost, kazdy projekt je iny na kazdy je vhodne nieco ine a tomu by sa mal prisposobit aj to mnou spominane QA - lebo teraz je to nastavene ze sa skontroluje strikne dodana dokumentacia DFS, prirucky, testovacie scenare a pod - a pritom DFS vsetci vedia ze uz je neaktualna v dobe schvalovania RV, proste cela QA a kontrola je nastavena na waterfall.
Ja uvediem striktny priklad kontroly QA a kontroly na mieste v casoch OPIS z osobnej skusenosti cca 2010/2011 - jeden z prvych odovzdavanych projektov OPIS - mali sme vystavene rozhrania - aby sme naplnil ciel musi byt sluzba - rozhranie sme mali REST/JSON, to boli neskutocne hadky z mojej strany ked mi QA vysvetlovalo ze som mimo standardov a mam mat SOAP a wsdl popis k rozhraniu a ze to mame prerobit.
A kludne nech si projekt tailrojue metodiku, len proste nech nieje len jeden must pre všetky projekty, lebo vzdy narazime na vynimku a extrem a potom sa budeme dohadovat ze to nie je dobre vseobecne, pritom to nebolo dobre len pre ten jeden pripad.