hociktore oddelenie moze byt kompetentne robit it vyvoj. len treba tu “capability” mať. o tom sa tu bavíme. v bankách sú to často produktové a procesné oddelenia, IT iba ladí formu a doplĺna IT parametre.
1 Like
“pred-diskutovali”
neviem ci vyzval zrovna na toto :-), ale v podstate sa zacinaju pekne profilovat otazky/problemy, na ktore by mali/mohli v diskusii reagovat(cize pomohol si to nastartovat). Asi nemame sancu nic ine urobit, kedze nic k comu by sa dalo vyjadrit do placu hodene nebolo.
Ano, dalsia dobre pomenovana dilema - z mojho pohladu, ako nastavit velkost projektov, tak aby sa dala efektivne zvladnut priprava aj realizacia a zaroven aby prilisnym rozdrobenim a spagetovou realizaciu projekty nepredrazili a nestratila kvalita, zodpovednost dodavatela/dodavatelov. (reakcia na predstavy, ze sa budu postupne po malych fazach rozvijat projekty a novy a novy dodavatel dorabat male zadania do existujucich zdrojakov alebo po malych moduloch)
Blockquote ociktore oddelenie moze byt kompetentne
Dalsi dobry postreh (na niektorych miestach sa vybudovala aj v statnej sprave a funguje to podobne resp. vnimam pozitivne naznaky, uracnici zacinaju zit a rozumiet IT z biznis hladiska je to asi prirodzene)
Akurat mam pocit, ze teraz sme sa vid. “Nove slovensko” vydali cestou centralizacie(2021) a nie posilnovania prave tychto schopnosti dolu(pisu, ze je to plan na 2022) ako uplne elementarny predpoklad toho, aby sa to IT zacalo niekam posuvat.
len to zase smerujeme do “fantazie”, tak len pripominam ze do jula 23 musia byt projekty zaplatene a ukoncene. a len teraz mirri potichu prestalo blokovat pkracovanie. musia uspesne prebehnut vo co vobec nie je samozrejme. realizacia zacne AZ po podpisani zmluvy s dodavatelom. A dnes hrozi ze vsetky krasne predstavy o QA ci aktivnom zasahovani budu znamenat dalsie oneskorovanie. A vieme co to bude znamenat, na vlastnu implementaciu, testovanie a pripadne zmeny ostane malo casu a tak sa preberu systemy s detskymi chybami ( zhruba opis x 3). Alebo rovno nedokoncene s tichym slubom ze to nejako dolepime v SLA.
toto je skutocne riziko a jeho mitigacia sa neobjavuje.
A okrem toho su tu dalsie rizika o ktorych sa nehovori. Projekty dostali do vienka povinnost vyuzivat centralne komponenty ( pretoze duplicita je silny buzzword) ale tie nie su a nebudu skor ako sa projekty dokoncia. Co s tym ?
Projekty budu potrebovat hw ( na testovanie, integracne testy atd. ) Ale vladny cloud nema kapacity a uspesne sa podarilo zabranit ich posilneniu, co s tym ?
1 Like
Jasne ze sa budu lisit :), ale to bolo len margo ze najlepsi je text :). Moznosti je viac, pripravit wireframe na klucove casti je samozrejme pracne a casto “pod uroven analytika - ergo nevie to”. Ale zazil som vselico a dobry obrazok je viac ako text. Na dobrom obrazku uzivatel napriklad zisti ze potrebuje udaje a v analyze sa o nich nic nevie. Alebo ze potrebuje zoznam niecoho co neexistuje pretoze doteraz si to zapisoval do pomocnej tabulky v exceli. A dobry analytik sa spozna prave podla toho ze pocuva a dokaze pochopit co uzivatel naozaj robi a nie to co mu hovori. A ze potom dokaze zistit aj to co robi ale taji to 
( to su vsetky tie vynimky na chyby co sa realne deju. A ked to vidim v analyze vtedy viem ze to je analytik co to da. Ale zdaleka to nie je pravidlo )
Dakujeme. “Shape Up is for product development teams”. Ako nam tato knizka pomoze v hladani odpoved v akej forme agile a do akej miery (a ako to premietnut do VO?) pri eGov projekte? (ked autori maju pre rozvinutie agile uplne tie neidealnejsie vychodiska?)
1 Like
Blockquote Jasne ze sa budu lisit :),
Ak som pochopil Tona tak hovoril o niecom inom. Je tu FA a akceptacia nejakeho analytickeho vystupu ako vstupu do impelementacnej fazy. Akakolvek zmysluplna metodika hovori o tom, ze analyza nekonci zaciatkom implementacie.(cize vzdy je rozumna a prirodzena nejaka miera agilnosti). Ak das wireframes a ten projekt sa nejako vyvoja, ukazujes/spristupnujes prototypy…tak jedina formalne spravna vec je aktualizovat spatne DFS a nechas si zmeny schvalovat. Cim komplexnejsiu analyzu urobis, tym vacsia rezia a nakoniec mozes skoncit ako oslik, ked niekto odmietne akceptovat, lebo Ty si v najelsej viere nieco urobil len si to zabudol premietnut niekde do analyzy.(fabulujem, ale viem si predstavit, ze ked do toho zacne vstupovat nejaka formalna QA toto je presne to, co sa moze stat problemom…)
Ta uvaha sa mi ale paci a suhlasim.
1 Like
to nie je fabulacia ale realita :), technicky by to samozrejme malo byt schvalene ako zmena DFS. Ale pri QA to znamena teraz neznamu casovu narocnost a ak nestaci projektovy zapis tak pride niekto z MIRRI a ten bude zrejme formalne kontrolovat sulad diela a DFS v podobe dokumentacie, bez ohladu na to co chce uzivatel a na com sa dohodli s dodavatelom. A teda projektak sa bude branit ako cert aby sa ziadne zmeny nerobili pretoze do toho vstupuje treti subjekt. To su take drobne efekty zlepsovania a zvysovania kvality.
Ale ok, to boli len take uvahy bokom, nastastie sa nikto nesnazi dostat wireframe do metodiky 
Co nebolo moze byt…a podla mna by to nebolo na skodu tam mat ale s dovetkom “Aplikuj, ak to dava zmysel, v rozsahu v akom to dava zmysel a prihliadaj na to s rozumom pri akceptacii”. To ale tomu QA cloveku, ktory nebude priamo sucastou projektoveho teamu, nebude brat zodpovednost za rozhodovanie o primeranosti je naprd. On chce bic, metodiku, ktora za neho vyriesi vsetko, ktorou by mohol posudzovat z nadoblacnych vysinna konci alebo v diskretnych casoch.
1 Like
toto je default vlastnost statu. a realne to vlastne chceme, len s tym treba pocitat a hamovat pri tvorbe metodiky. aby ten co to presadzuje chapal dosledky ze sa to bude aplikovat tak ako to je napisane a bez ohladu na to ci to dava zmysel v danej situacii. a tak zabranime aj zlym ale aj dobrym skutkom. A problem je ze snaha zabranit excesom nie je vyvazovana snahou umoznit progres, chyba pohlad “tradeoff”
nie, toto už neplatí, faktúra a akceptácia je až po odovzdaní plne funkčnej časti, nie len analýzy…
Na slovensku je málo inštitúcií pripravených na agilný vývoj. Veľkým problémom je, že úradníci nemajú záujem o zmenu, pretože nemajú motiváciu.
Motivácia je základný motor, ktorý vedie k úspešnému projektu. Cieľom riadenia projektu je zabezpečiť motiváciu členov tímu, jednak na strane zákazníka, jednak na strane dodávateľa. Ak ľudia nie sú motivovaný k zmene, že im niečo naozaj prinesie, že je potrebné danú zmenu urobiť, žiaden IT dodávateľ /a je jedno či štátna firma alebo súkromná/ neurobí dobrý systém alebo projekt.
To, ako sú dnes popísané legislatívne povinnosti znamená, že je neskutočne veľa povinností, ktoré majú realizátori projektu, brutálna administratíva, riziká z meniaceho sa prostredia a nejasné kritériá akceptácie / úspechu (čo sa vlastne očakáva, kedže viacero stakeholderov má odlišné ciele).
1 Like
Kym nebude servisne orientovana architektura na baze microservices alenbo nieco podobne (ale kompletne pre vsetky back.endy (dnes ani jeden taky nie je) a mnamiesto toho aby sa prerobili back.endy najprv, tak sa vymyslali sluzby pre obcanov, ktore z viac ako polovice vobec nepotrebuju a da sa to zabezpecit inak. Netrreba otravovat obcanov so sluzbami, ktore na takych back.endoch ako su, sa ani poriadne postavit nedaju.bb
odkial je tato info? platba az na zaver? vsetko je mozne ale toto je napad naozaj zly a tu ho vidim prvy krat.
Ano, ano, ak to tak bude, je to zly napad, potom nech neplatia ani za studie, ani ine pripravne dokumenty, co je samozrjeme tiez kravina. Ale viem si predstavit, ze priebezne mozu zaplatit max. 70% a zbytok az na konci na zaklade splnenia cielov (a tych 30% mozu dostat celych alebo len cast, podla totho ako sa naplnia kriteria. Samozrjem ale to je mozne len vetdy, ak tak bdue psotavene VO. oni si totiz neuvedimuju, ze vsetky take zasahy budu (platba na konci podla mna ani nie je mozna z danovych ani inych zakonov, to co nezaplatia nie je ich vlastnictvom a dan sa muis platit v tom obdobi ked bol produkt urobeny a dodany, proste toto, ze paltba cela na konci mohze povedat len clovek neznaly)
Problém je v tom, že sa štúdia robila 3 roky pred realizáciou. Nerobil ju dodávateľ, ľudia na druhej strane sa vymenili. Zákony sa zmenili, procesy nesedia a podobne.
Problémy pri aplikovaní agilného vývoja sú: fakturačné míľníky (a fixné harmonogramy), príliš veľké projekty, príliš špecifické fixné (niekedy nezmyselné) požiadavky, neschopnosť schvaľovať výstupy na strane štátu včas (tj. pri 2 týždňovom cykle sa nestíhajú schváliť výstupy ani len do ďalšieho stretnutia), pomalé odozvy pri komunikácii, vysoká byrokracia, príliš veľká previazanosť systémov, neschopnosť dodávateľov externých / centrálnych systémov (nekvalitné kontrakty, zlá komunikácia,porušovanie kontraktov), nedodržiavanie štandardov a štandardných postupov (pri integráciách, SSO, …), neexistencia flexibilného prostredia infraštruktúry (VC ešte nie je tam kde by mal byť, dá sa to spraviť u dodávateľa), nízka orientácia na pridanú hodnotu.
Postupne sa to však zlepšuje.
Mohol by som ešte rozpísať problémy pri aplikovaní mikroslužieb a SOA, ale tie sú viac menej totožné s komerčnou sférou pri väčších korporátoch ako banky, poisťovne, telco.
2 Likes
Je to podľa metodiky MIRRI, vždy može akceptovať a platiť zákazník až potom, ako má dodávateľ odovzdaný komplet časť diela, t.j. po nasadení do produkcie - nie po analýze …
prosím čítajme s porozumením, nie na konci projektu platba, ale po kompletnom odovzdaní časti diela. T.j. musí sa nasadiť hotová časť (nazvaná podľa vyhlášky inkrement) a tá akceptovať. Neplatí sa tak, ako voľakedy že po analýze faktura, po implementácii faktúra a pod…
vyhláška:
Ak ide o projekt podľa § 15 ods. 4 písm. d) zákona, cena jedného inkrementu podľa § 15 ods. 4 písm. d) tretieho bodu zákona nesmie presiahnuť 70 % z celkovej ceny projektu a lehota dodania každého inkrementu podľa § 15 ods. 4 písm. d) štvrtého bodu zákona nesmie presiahnuť 730 dní.
inkrementom čiastkové plnenie projektu, ktoré musí obsahovať z realizačnej fázy projektu aspoň etapu Implementácia a Testovanie a Nasadenie do produkcie; je možné ho realizovať viacerými iteráciami v závislosti od charakteru projektu; každý doručený inkrement projektu je nasadený na produkčnom prostredí informačnej technológie a je možné začať s dokončovacou fázou projektu alebo pokračovať ďalším inkrementom
iteráciou opakujúca sa činnosť v projekte, ktorej cieľom je časté overenie projektu a jej súčasťou je zapracovanie spätnej väzby z funkčných testov vrátane úpravy špecializovaných produktov a manažérskych produktov etapy Analýzy a Dizajnu; zahŕňa z realizačnej fázy projektu aspoň etapu Implementácia a Testovanie
2 Likes
aha toto, s tymto vedia zit vsetci aj ked je to komplikacia. v realite to nebude velka zmena
1 Like