Agilní vývoj ve veřejné správě

Obecné
,
1

Kéž by! :slight_smile: Software se tímhle způsobem dělá desítky let a troufnu si říct, že převažující výsledky a data tvrdí opak. „Jasné zadání“ je u softwaru utopie. „Tuším, co dostanu,“ je utopie. Tedy pokud se nebavíme o tom, že dostanu faktury za vícepráce :slight_smile: Celý agilní vývoj vznikl jako reakce na naprostou nefunkčnost tohoto modelu.

Chápu, že bychom tou diskuzí o iterativním vývoji vs. vodopádu mohli strávit dlouho, a klidně na to můžeme založit vedlejší téma, ty zkušenosti z různých metodik ve veřejné správě by mě zajímaly.

Chci ale říct něco jiného. Tady nejde o to, aby všichni dělali projekty iterativně, agilně. Jde o to, aby měli tu možnost, když jim to dává smysl. Tohle je to, co by jim ten zmíněný „framework“ nabízel. Teď mají v podstatě jedinou reálnou možnost, soutěžit to jako celek v režimu pevný čas, pevná cena. Což je podle mě ověřeně strašná shit show.

4 Likes
2

Já samozřejmě znám tu realitu, waterfallu se jako projektak vyhýbam jak to jenom jde. Na druhou stranu je tu nějaký veřejný zájem o efektivním využití peněz, a ta podle je téměř nemožné vypsat “férovou” agilní zakázku, protože se tak strašně špatně vybírán vendoři.

Další premisou, agile jako takového, je častý release do produkce, ale to už je úplný jiný příběh:)

1 Like
3

Té poznámce o férovosti nerozumím. Máš s tím vybíráním agilních dodavatelů nějaké zkušenosti, ideálně z veřejné správy? Můžeš se o tom rozepsat? Díky!

4

Viděl jsem to akorát z druhé strany - byl jsem u výběrek v soukromé sféře, v té veřejně jsem jich viděl akorát pár. Většinou tam jsou parametry cena, nějaké reference/relevantní zkušenosti a potom třeba interview. Správně by to interview mělo tvořit velkou část vyhodnocení (protože je důležitý, ať si obě strany sednou, že jo), na druhou stranu je to to nejhorší, co jde udělat z pohledu transparentnosti.

A k té férovosti - já si to představuji tak, že když se jedná o veřejnou správu, tak se jedná o veřejné peníze a v rozumných mezích by mělo být transparentní, jak a který dodavatel se vybral s tím, že ideálně by se měl vybrat ten nejlepší dodavatel. Zatímco u waterfall projektů jde tohle papírově docela jednoduše ukázat, u těch agilních je to o dost těžší. Jak se rozliší, kdy si někdo vybral za dodavatele svého kamaráda vs tu nejlepší možnost?

1 Like
5

Díky! Bereš to tak, že u vodopádu je to objektivnější, protože se soutěží kompletní zadání na nejnižší cenu? To je pro mě problematické z několika důvodů:

  • Asi se shodneme, že něco jako „kompletní zadání“ netriviálního digitálního produktu předem je prakticky nemožné. Často člověk zjistí, co přesně je potřeba, až když se dodá nějaká první iterace. Takže ten vodopád naopak může obrovsky plýtvat veřejné peníze dodáváním produktů, které neřeší skutečné potřeby uživatelů. To se podle mě reálně děje a je to strašlivě drahé.
  • Vybrat nejnižší cenu můžu skutečně objektivně, ale jaký je vztah mezi cenou a kvalitou? Podle mě velmi složitý, nejlevnější neznamená celkově nejlepší. Pokud ve výběrových řízeních na cenu objektivně vítězí například dodavatelé, se kterými přitom máme špatné předchozí zkušenosti, opět to vidím jako velké plýtvání zdroji (nejen finančními).
  • I samotná ta soutěž na cenu bývá nezřídka fiktivní, dodavatel prostě zvolí cenu x a domluví se s pár kamarády, kteří mu udělají křoví s cenami x+1, x+2 a x+3. Opět je zjevné, že takhle veřejné prostředky neušetříme.

U toho agilního nebo obecně iterativního vývoje mně přijde dobré to, že můžeš dřív zasáhnout, když zakázka „nekonverguje“ nebo nejsi spokojený s dodavatelem. Nikoliv až v okamžiku, kdy zaplatíš stovky milionů za nefungující řešení. V tomhle to vnímám jako nákladově efektivnější metodiku.

Vůbec ale netuším, jak je možné ty dodavatele transparentně vybírat, aniž by hrozilo to podezření z nějakého kamarádšoftu.

2 Likes
6

Bereš to tak, že u vodopádu je to objektivnější, protože se soutěží kompletní zadání na nejnižší cenu?

I když u nás platí nejnižší cena = nejlepší nabídka, já bych to takto nechtěl, podle mě i u vodopádu by měl být nějaký faktor kvality (reference, předchozí zkušenost,…)

Já (obvykle) jsem velkým fanouškem Agile, jenom v té veřejné správě úplně nevím, jak by se to mělo řešit. Jinak.s těmi iteracemi a případným utnutím dříve souhlasím, mít nějaké milníky (např. nějaký proof of concept) určitě dává smysl a ve výsledku taky šetří peníze.

1 Like
7

Vlastně by šlo soutěžit nejnižší hodinovku za agilní dodávku, že, ale to jsme furt tam, kde bychom nechtěli být… O agilním vývoji v kontextu americké veřejné správy píše výborně a dlouho Waldo Jaquith, autor námi přeložené Příručky vývoje státních IT projektů. To by mohla být dobrá inspirace, tady má konkrétně něco podrobnějšího o soutěžení agilních dodávek, ale ještě jsem se k tomu nedostal:

2 Likes
8

Kouknu na to. Rychle jsem to přelétnul a o většině z toho jsem už slyšel, ale zkusím se na to podívat hlouběji :slight_smile:

2 Likes
9

Tohle je uplne bozi clanek a verim, ze to tak lze delat i v ramci ceske verejne spravy. Nekolik bodu k problematice vyse:

“waterfall se objektivne nacenuje” - Problem tohohle uvazovani je, ze to, jak pise Zoul, “teoreticky nejde” a ani se to nedeje prakticky. Nebudu pocitat pripady, kdy dodavatel reseni nedoda (ale i to se deje). Tak jasna vyhoda tohohle pristupu je, ze “dostanu, co jsem si naspecifikoval” a jasna nevyhoda je, ze “dostanu, co jsem si naspecifikoval”.

Waterfall zadani pro vyberko neni SW specifikace, ale v podstate velmi smutny zapis desetileti crowdsourcovanych zkusenosti. Kdyz jsem videl ve specifikaci “ISBN kod ve vypisu knih musi jit vybrat a zkopirovat”, tak jsem waterfallove prozrel. Predstavte si ten pain cloveka, co to tam napsal (pracoval se starym systemem od 90’s do ted).

“Kvalitu poznate z referenci” - Tohle je podle me jedna z nejvetsich pasti vyberu dodavatele. Za posledni mesice jsem videl nekolik zadani a vyberek na mestske weby a ti dodavatele si to v podstate “vysedeli” (to nejsou moje slova, ale slova pana radniho z JBC). Dodavaji sht weby 20 let => maji reference, z toho treba i jednu hezkou.

Spravna cesta je tu dobre nastaveny framework pro kontrolu kompetenci dodavatele. Bavil jsem se v ramci partnerstvi >c.d s lidmi, co to delaji ve Skodovce a jak resi kontrolu kvality SW dodavatelu. Kdyz se tu nastavi funkcni framework, da se pracovat bez referenci => vyrazne se rozsiri moznosti.

“Waterfall vyberko je tezsi hrat malou domu” - Tohle imo neni pravda. Ve vsech pripadech to jde stejne snadno, pokud neni externi kontrola. Viz zase ty mestke SW zakazky. Vyznamna cast z nich je napsana tak, ze podminky splnuje prave jeden dodavatel v Cesku. Minuly rok jsem celt specifikaci, co vyzadovala certifikaci na FW (ktery bezel na meste). Tu certifikaci maji v Cesku prave dva lide. Nahoda? Nemyslim si.

Taky jsem ted opet narazil na kritiku, kdy neuspesni dodavatele ve vyberku maji prostredky, jak ho torpedovat az 6 mesicu. Tohohle pohledu se docela bojim. Pokud v nasem systemu ten nejvetsi problem je typu: “subjekty maji prava a dokazi je vymahat. (blasphemy! :fire:)”, tak spozornim. Ty problemy jsou jinde.

3 Likes
10

Waldo je celkově super, má výborné praktické postřehy a návody ohledně agilního vývoje ve veřejné správě. Třeba tady ještě: The work before the work: what agencies need to do before bringing on an Agile vendor. To jsou všecko relevantní problémy (a řešení) i pro nás.

PS. Walda možno sledovat na Mastodonu.

11

No vida, jako na zavolanou česká případovka o soutěžení zakázky podle kvality a s agilní dodávkou:

1 Like
12

Je to krasne, doufam, ze jich bude pribyvat i na komplexnejsich projektech. Ale zcela uprimne, ten text je pekelnej. To je 80% vaty.

Neni to nekde popsane lepe a lidsteji?

13

Je tam odkaz na případovou studii od ASWA, ta by pro tebe mohla fungovat líp?

1 Like
14

Rozhodne doporucuju procist tu samotnou zadavaci dokumentaci. Vyborne ukazuje prave ty detaily hodnoceni dodavatelu. Pokud nekdo v poslednich letech cetl zadavaci dokumentace, tak ten rozdil je videt na prvni pohled. Od presneho popisu hodnoceni az po realisticke pozadavky na tym.

Jestli tahle zakazka udelala neco dobre, tak je to fakt siroky zaber na dodavatele. Umim si predstavit, ze tyhle podminky realne splni >100 firem/skupin freelanceru v Cesku vs bezne jeden (dva, aby se nereklo).

https://nen.nipez.cz/file?id=1442028175

Dalsi zajimavost je vaha ceny, ktera byla 30%. Kdyz jsme se o tomhle bavili treba v JBC, tak byli urednici ochotni jit na 60% vahy ceny (vidal jsem nejcasteji 80%, ale mozna ani 100% neni vyjimka?)

2 Likes
15

Tady k tématu zajímavý rozhovor se šéfem IT na MPSV. Například:

[K]dyž potřebuji, dokoupím si kapacity. Pozor – nevypisuji výběrové řízení na dílo, dokoupím kapacity, které si řídím a které dělají práci, kterou potřebuji. Nenajímám si přitom firmy, ale konkrétní vývojáře. Respektive, na projektu mám business architekta, IT architekta, to jsou lidi, které mám standardně interní, nebo přes dlouhodobé smlouvy. A pak řeknu „na tuhle úlohu budu potřebovat pět vývojářů, tak mi dodejte pět vývojářů“. (…) A na rovinu – aby to fungovalo, potřebujete mít sladění s ministrem. Zatím tento model není ve státní správě standardní, ale je možné jej nasadit a není to těžké.

5 Likes
16

Tam je strašně důležitá ta věta potřebujete být sladění s ministrem. Pokud nemáš podporu nadřízeného můžeš vymýšlet co chceš a nedáš to.

3 Likes
17

Moderátorská vsuvka od @zoul: Tuhle debatu jsem přesunul z diskuze o digitalizaci stavebního řízení.

Tohle je obecně oblíbený omyl. Ačkoli mají agilní metodiky své nepopiratelné výhody, zrovna tento projekt je jasným dokladem toho, že jsou pro prostředí veřejné správy naprosto nevhodné.

Veřejná správa je postavena na tom, že k danému termínu musí být funkční systém, který dělá přesně to, co po něm zákony vyžadují. Tedy některá z vodopádových metodik. Případně hybridních, ale vodopád to musí zastřešovat. Snaha naroubovat některou agilní metodiku na tento typ úloh svědčí jen o tom, že autor buď nemá dost znalostí a zkušeností s různými metodikami, jejich výhodami a slabinami, a nebo nemá představu o specifickém prostředí veřejné správy.

V případě ISSŘ si myslím, že je nastalo oboje - jinak si neumím moc vysvětlit, proč jeho autoři ignorují požadavky legislativy. I když v případě Pirátů to není noc překvapivého - zrovna se znalostí platné legislativy v oblasti eGovermentu jsou dost na štíru.

Těch opravdu fatálních chyb je tam víc. Nejen to, že se obec nemůže přihlásit jako stavebník (což se dá opravit relativně snadno). Mnohem horší je to, že nemá rozhraní na spisovky a to znamená, že naprosto odignorovali Zákon o archivnictví a spisové službě a hlavně jeho vyhlášky. A podle všeho si pravděpodobně ani moc nebrali k srdci Správní řád - což jsou dva základní zákony pro fungování veřejné správy jako takové.

A tohle je systémová chyba. Ta se změnou nastavení opravit nedá.

18

V tomhle se vůbec neshodneme :slight_smile: Vodopád ověřeně nefunguje, jsou na to dekády zkušeností a dat. Iterativní vývoj jen reaguje na problémy, které takhle vznikají – tedy na neustálé masivní nedodržování termínů, překračování rozpočtů a dodávání softwaru, který neodpovídá potřebám uživatelů. Pokud je ten současný systém pro stavební řízení špatný, není to kvůli iterativnímu vývoji. Který se mimo jiné používá v jiných veřejných správách, například ve Spojených státech.

2 Likes
19

Já si taky myslím, že to není o způsobu vývoje (vodopád, agile, cokoliv jiného). Pokud zákon definuje nějaké podmínky, procesy apod, tak ano, ty musí být povinnou součástí při prvním spuštění - a je chyba, pokud něco takového chybí. Kromě toho budou vždycky desítky, tady stovky, spíš i tisíce dalších požadavků “should” nebo “nice to have” - bez kterých aplikace pořád splní zákon, ale s nimi bude používání příjemnější a efektivnější. Řada z nich navíc vznikne až zkušeností z reálného provozu, tj. je naopak docela žádoucí přidávat je postupně. Protože definovat úplně všechny detaily na začátku x letého projektu vede vždycky k tomu, že v reálu se pak ani nepoužijou nebo se stejně musí upravovat… Takových “business requirements” jsem od stolu napsal spousty - a stejně to nakonec za ty 2 roky chtěli uživatelé jinak = vyhozené peníze i čas :slight_smile:

2 Likes
20

To, co píšete platí pro komerční sféru. Ve veřejné správě, a speciálně u klíčových informačních systémů, to tak není. A tvrdím to na základě svých, už skoro 20 let zkušeností s projektovým řízením ve veřejné správě.

Všechny opravdu průšvihové ve veřejné správě projekty, o kterých vím (bez ohledu na to, jestli jsou veřejně známé nebo ne) zkolabovaly kvůli jedné ze dvou příčin (a je to tak 50/50): Buď se nějaká firma bez zkušeností, ale se svatým nadšením pokusila řídit projekty agilně a nebo šlo o “politicky projekt tlačený na sílu”, který ale narazil na hradbu odmítnutí (což v praxi znamená ignorování snahy takový projekt implementovat).

Existují zavedené a dlouhodobě osvědčené postupy, jak zajistit, aby podobné projekty dopadly dobře a včas - o těch úspěšných se nemluví, nejsou sexy. Pokud se ale k tendru dostane firma, která s tím nemá zkušenosti a pokusí se přenést to, co zná z komerčního světa do veřejné správy, skončí to katastrofou.

A znovu - zásadní odlišnost je v legislativě. Úřady mohou dělat jen a pouze to, co zákon výslovně požaduje a umožňuje. Nic víc, nic méně. A musí to fungovat v termínu daném účinností zákona (nebo termínu, který z účinnosti zákona vyplývá). Je to úplně jiný svět, který vyžaduje úplně jiné postupy, má jiné předpoklady a musí být testován velmi specifickým způsobem.

Čímž netvrdím, že některé okrajové, podpůrné systémy jako jsou webové stránky obcí - nemohou být implementovány agilně. Mohou a občas se to dělá. I já to občas dělám, i když zrovna u mě se víc vyplatí použít metodiky na principu prototypování. V případě klíčových informačních systémů veřejné správy je ale použití vodopádu (nebo některé hybridní metodiky) nutné.

A není úplně pravda, že vodopád musí být nutně rigidní a neměnný - proto mám rád například RUP, protože dokáže sledovat výrony legislativních aktivit poblázněných poslanců. Nebo Prince 2 7ed. Nicméně ve finále jde jen o to co, kdy a za kolik.