Kedze je to o inkrementoch tak to plati zrejem pre Agile projekty (akurat je tam - nesmie presiahnut 730 dni, tak taky pocet dni to nemoze byt ine ako Waterfall, pozna niekto IT firmu co sa prihlasi na projekt, kde nebude ziadna platba az po 2 rokoch? NUz tu su zjavne porusene aj danove zakony, som zvedavy co na to MF a zakom o daniach ci uctovnictve - pretoze tam kde nejaka dodavka trva 2 roky a viest ju ako rozpracovanu vyrobu a nemoznost si dat mzdove nakaldy ako danovy vydavok a nezapalti dan, nuz to ani statnej kase sa nebude pacit), OPre Agile projekt OK, pre waterfall nie OK. Za kazdu cast diela, ktora sa neplati, zakaznik ju moze vidiet, ale nema/nesmie judostat pretoze nie je jeho az do zaplatenia (takze ked nechce mat zakaznik analyzu, tak OK, ked sa za nu neplati, tak sa ani neakceptuje a nefakturuje (ano pouziva sa ako konzultacia)
Z principu danoveho,a uctovneho, su 3 moznosti, ide o dielo, sluzbu alebo podporu pravadzky/prevadzku, Kedy sa fakturuje a odvadza dan:
Dielo - po akceptacii casti diela alebo celku (cast diela je vsetko co sa odovzdava zakaznikovi, aj analyza)
Sluzba - mesacne na zaklade protokolu o vykonanych pracach/dodanej sluzbe
Prevadzka - na zaciatku dohodnuteho obdobia (kvartal, rok, …)
AK je to Agile - odovzdavaju sa len inkrementy (je to tiez dielo, na dielo plati autorsky zakon), ale inkrementy nie su presne definvoane na rok dopredu, zakaznik nevie 2 roky dopredu co presne dostane (nie je detailna analyza ani detailna specifikacia, ani nemaju presnu cenu dopredu). Takze nemali by sa pliest spolu waterfall alebo agile, pretoze to su uplne odlisne veci
Len tak pre zaujimavost - Agile for Government large projects (aby some neslapli vedla)
Osobne som veľmi skeptický voči agile v Goverment v našich reáliách. Je to príliš veľká zmena s veľmi problematickým politickým aspektom: nevieš predikovať rozpočet a problematickým praktickým bodom: vyžaduje kvalifikovaného zadávajúceho/kupujúceho=štát.
By som sa snažil dotiahnuť rozdelenie na menšie časti a keďže je to sofistikovanejší prístup, ktorý vyžaduje aby pred VO vznikla oveľa konkrétnejšia predstava ako tomu bolo v minulosti, budovala by sa kvalifikácia. Uvediem príklad ktorý je mne blízky: obchodný register by sa dal rozdeliť na nasledujúce časti:
- elektronické služby
- portál orsr
- vnútrorezortná integrácia
- backoffice = neverejná časť pre súdy
- hw
V tomto prípade by sa dalo postupovať všelijak, spojiť portál a elektronické služby (alebo aj nie), vnutrorezortnú by dalo možno mssr aj vlastnými silami. obstarávanie a realizácia backofficu by bola oveľa jednoduchšia, hlavne by bola bez tých šedých miest. Bolo by to však potrebné nakresliť aj s návrhom hi level integračných kontraktov, vymedziť zodpovednosť a vyžadovalo by si to poriadnu koordináciu, keďže by to muselo prebiehať paralelne.
MAterial som tam dal preto, ze to rozobera dobre (co je potrebne urobit aby to mohlo zafungovat, podla mna u nas malo realne). Ale inak to rzdelenie je tiez malo realne - pretoze to musia urobit pred VO (musela by byt celkom ina kvalita tych meterialov na co nemaju ludi (este niekto povie, ze analyza sa nepalti, nuz bez to poriadne nerozdelite, len aby sa nepovedalo a potom to ani neodovzdatea tazko zakceptujete - ako kto preberie back-end bez front-endu alebo naopak, portal bez back.endu (mozno delenie bolo myslene inak, ale vzdy to bdue problem aby to urobili dobre zadefinovane pred tendrom a dali do zadania)? to musia byt ucelen celky, ktore maju samostatny vyznam a samostatne sa daju prebrat, potom integracia ako sa bude preberat - asi samostatne a vsetci povedia ved my to mame podla zadania, u nas problem nie je, to chcem vidiet tie tanecky)
tak prosim or
v skutocnosti by ale ziadna cast nesla do prevadzky, alebo aspon si neviem predstavit ako. pokial nepreprepnes stary or na novy tak mozes agilne robit co chces ale bude to bud alebo. a samozrejme ze to pobezi paralelne a to hlbsej granularite ale do prevadzky to nepojde.
Ale este inak, tato snaha o agilitu v skutocnosti dosiahla len veci ktore nechcela, malym firmam pridala dalsiu prekazku ( aj ked samotne eurofondy to robia dostatocne a tak to nie je zasadne) a kedze snaha o plynulejsie uctovanie projektu je u vsetkych ( zakaznik, dodavatel, mirri) tak to spolocne obidu. inkrementom sa zrejme nazve vselico, vykazovanie sa dalej vzdiali realite a pod.
Nezjednodusoval by som to, ak sa chceme niekam pohnut. Niektori naozaj chcu robit len povinnu jazdu na ktoru boli zvyknuti a maju odpor ku zmene, niektori su znechuteni zo skusenosti z IT (aj ked sa do toho vlozili, vysledok bol pruser, s ktorym oni nadalej denno denne zapasia), cize tiez odpor ku zmene, niektori napriek zlej skusenosti su ochotni sa do veci stale vlozit, ak v tom vidia zmysel a pod.
Treba ludi, ktori zdvihne zastavu a povedu utok…nielen strategickych planovacov daleko od zakopov.
uplne suhlasim, nielen toto, ale aj toto, zaroven podmienky pre realizaciu (co potrebujete? co mam zabezpecit aby to fungovalo?) …samozrejme riadenie inym, ako autoritativnym stylom funguje len tam, kde existuje nejaka zakladna spolocna motivacia ludi (napr. chut sa sebarealizovat), ale nie tam kde dominuje linivost,zatrpknutost,odpor ku zmene, nedovera, prilisny individualizmus alebo nejake plytke zaujmy. A autoritativne riadenie v IT neprinasa vysledky, aspon nie dlhodobo. Cize sme zase pri ludoch a budovani veci zo spodu a nie zhora.
realne je, to ze nemaju ludi, ktory vedia spravit je podstata problemu ktory tu riesime.
ten backend som zle nazval myslel som tym backoofice aplikaciu pre spracovanie, som to hned aj opravil
ja som pisal ze agilne nie, ale na mensie casti watterfall. v skutocnisti elektronicke sluzby sa daju urobit nezavisle aj nad sucasnym riesenim
ano, da sa rozvijat sucasne riesenie s cielom vytvorit z neho nove. ale dava to zmysel? to nie je basnicka otazka, to vyzaduje analyzu, ciel a odhad ako bude nakladna takato cesta. kazdy dom sa da prestavat ale casto je lepsie ho zrucat a postavit novy.
ale ideme asi mimo topic
ale napriklad cesta zmeny je doporucena pre cssr( aka sudny managment) okrem ineho aj preto ze nie je mozne vyclenit dost kapacit na testovanie noveho riesenia pri zachovani normalnej prevadzky
[quote=“Jody, post:34, topic:7167”]
Kym nebude servisne orientovana architektura na baze microservices alenbo nieco podobne [/quote]
Ona nebude. Ju treba tvorit. Cielom by mala byt volne previazana architektura, ktora umoznuje jednoduche budovanie (mensia vysledna komplexnost) a udrziavanie jednotlivych autonomnych systemov. Toto su principy znamene davno pred buzzwordom microservices. A prostriedkov, ako to robit na roznych urovniach resenia, treba volit ten najvodhodnejsi.Inak povedane, aj tie microservices a niekoho konkretna predstava o nich sa mozu zvrhnut.(je bezna predstava ze treba teraz rozbijat vsetko co sa da na atomicke autonomne komponenty fyzicky oddelitelne a skalovatelne, lebo v takom kontexte niekto prezentoval microservices(a mozno on tie dovody mal) a teraz to bude bezhlavo aplikovat aj tam, kde kde to nema absolutne opodstatnenie a navyse tak neiskovne, ze vyrobim monolit, ktory je ale 5x komplexnejsi ako by bol ten “staromodny”)
nie rozvijat. vyvinut nove riesienie pre el. sluzby, ktore bude fungovat aj s legacy aj s pripadnym novym is, uplne bez akehokolvek problemu to fungovat bude a vies zakazky delit na mensie casti a obsataravat ich osobitne.
no mozno, som k tomu skepticky. napriklad ako moze sluzba byt nezavisla na procesnom modeli a datach? ak napriklad chceme hovorit o tom ze zapis zmien bude u notarov tak potrebujem pridat nove udaje do modelu. viem si teda predstavit nove sluzby nad starym systemom ale bude ich treba zasadne zmenit nad novym modelom.
ale ok, moja vyrazna skepsa k deleniu obstaravania je znama a tak nejdem opakovat preco to nie je dobry napad.
ale tu sa bavime o stave PO vo, ako uspesne realizovat projekt, nemusime to komplikovat podla mna skodlivou snahou to riesit pred vo delenim na casti
nic nebude treba menit, vystupom s esluzieb je podanie v sktalk. to je vstup pre spracovanie na rezortnej urovni a nasledne na sude. backoffice app pracuje s vlastnou strukturou, vysledkom je rozhodnutie a zapis. datovo budu tieto cati oddelene, teda mali by aj byt. keby to bolo inak tak to je monolit, co je podla mna bad practice
Vdaka za info, nezachytil soNechce sa mi to rozmazavat, zase skoncili len pri profesionalnej cti a nejakom predpise, ktory sam o sebe neriesi aboslutne nic.(priebezne vytahovanie penazi a na konci snaha odovzdat mrzaka)
ok na takto vrtulnikovej urovni ale jasne elektronicke sluzby koncia na ebuse a teda su oddelene. to je technicka uroven, ale okrem nej je idea co chces spravit na bussines urovni a tam su sluzby integralnou sucastou, modelujes a menis ich tak aby si tu zmenu spravil a riesi sa to v jednom teame nie v oddelitelnych castiach.
K tomu rozdeleniu. Toto pisem asi prilis casto, nemam vyhraneny nazor. Ale vysledkom takeho rozdelenia moze byt aj kategoricke predrazenie(pomenovavas na konci prispevku cast tych dovodov) a celkovo ovela vacsia komplexnejsia a mozno aj zvratenejsia architektura. Vid. prax a napr. UVO.
suhlasim len dodam, snaha vytiahnut peniaze cim skor je normalna motivacia dodavatela, tak su postavene vsetky procesy u neho. Ale snaha odovzdat mrzaka nie, na zaciatku je uprimna snaha dodat co najlepsie riesenie, aspon teda vacsinou. chce to zakaznik, programatori, analytici atd. Problem vznikne az pocas projektu, ked treba splnit milniky a nejde to. Az vtedy vznika tlak na odovzdanie “niecoho”.
podla mna taketo delenie vzdy zvysi rizika a problemy. Vynimka su excesy ked su vo uplne nesuvisiace projekty spojene do jedneho obstaravania ( ano deje sa to pretoze vo je vzdy komplikovane a robit dve je dva krat komplikovanejsie)
Blockquote yvinut nove riesienie pre el. sluzby, ktore bude fungovat aj s legacy
Ine riesenie asi neexistuje. Len ked to zacnes rozmienat na drobne, zacne to byt zaujimave.(ako zacat a co ako prerobit)
Moj nazor, co by sa dalo urobit je takyto. Siroke pilotne/PoC postupne budovane riesenie, ktore bude sluzit ako model, zodpovedie na zakladne arch. dilemy a bude zakladom buduceho riesenia/patternov.(cize zodpovie implementavcne na staroslivo vybrane a velmi komplexne scenare) Nasledne dobre planovanie a postupne dobudovanie/prerabka/ohybanie existujucich centralnych systemov a nasledne agendovych systremov, ale uz v tej prvej faze je problem.
- Moze to robit skupina nadsencov stylom OS (neralne)
- Moze to robit statna firma stylom OS a nadsenci sa nevylucuju (neralne)
- Moze to rotbit dodavatelia stylom OS (nerelane, zvrhne sa)