Projekt SISTA - etapa 2: Základní principy a procesy řízení projektu

Úvod

Sdílený informační systém Technologické agentury ČR (dále jen „SISTA”) je svým charakterem inovačním projektem bez spolehlivé znalostní báze pro jeho striktní naplánování. Z principu hrozí zvýšená rizika předělávek plynoucích z nedostatečného zadání tématu projektu a je nezbytně nutné postupovat iterativním (agilním) způsobem, tj. po určitých ucelených částech (byznysových/průřezových službách), které lze řešit jako samostatné celky. Rozsah iterace se vždy odvíjí od míry jistoty zadání tématu.

Finanční alokace a čas jsou rámcovou dohodou pevně dány, odhadovány budou konkrétní požadavky, a to po celou dobu řešení projektu SISTA. Při řízení dodávek přírůstků služeb SISTA využíváme agilní procesní rámec Scrum doplněný o některé vybrané konvenční procesy projektového managementu.

Vzhledem k vyššímu počtu účastníků rámcové dohody (dále jen „dodavatelé”) stanovujeme pouze základní principy a závazné požadavky. Nemáme ambici řídit kapacity a způsob koordinace vývojových týmů dodavatelů, vycházíme však z předpokladu našich doménových znalostí v oblasti podpory aplikovaného výzkumu, vývoje a inovací (VaVaI). Tyto znalosti bude nutné při řešení jednotlivých minitendrů správným způsobem propojit s know-how a odbornými kapacitami dodavatelů.

Předpokládáme, že existuje více dodavatelů softwarových řešení nad zvolenou technologií, kteří mohou efektivně spolupracovat při naplnění účelu rámcové dohody etapy 2 projektu SISTA. Věříme, že dodavatelé svými zkušenostmi přispějí k návrhu nových funkcionalit a vytvoření vylepšeného (inovovaného) softwarové řešení.

Nový informační systém nemusí být nutně plnou náhradou stávajících softwarových řešení, ale musí obstát novým a budoucím požadavkům, které v dalším období budou na softwarová řešení kladeny. Naším záměrem je vybudovat a provozovat SISTA jako cloud native systém. Takový informační systém má být odolný, snadno kontrolovatelný, škálovatelný, robustní a nezávislý na dodavatelích konkrétních technologií.

1. Obecná ustanovení

1.1. Kontext projektu SISTA

TA ČR od roku 2017 provozuje za účelem zajištění celého životního cyklu poskytování účelové podpory aplikovaného výzkumu a vývoje podle [ZPVV] softwarové řešení „Informační systém TA ČR” (dále jen „ISTA”) a softwarové řešení „Informační systém řízení BETA 2” (dále jen „IS BETA 2”) k řízení projektů veřejných zakázek, zahrnující jejich projektovou přípravu a funkcionality spojené s podáváním nabídek ve smyslu požadavků elektronického nástroje podle [ZZVZ].

TA ČR uzavřela dne 3. 6. 2020 se 7 dodavateli rámcovou dohodu (dále jen „RD1") k veřejné zakázce vyhlášené na profilu zadavatele pod VZ0079797: Sdílený informační systém TA ČR.

Plnění RD1 bylo ukončeno, a to s ohledem na dosažení maximálně možného postupu v řešení projektu SISTA spočívající v:

ověření použitelnosti rozhraní stávajících softwarových řešení ISTA a IS BETA 2,
dosažení předpokládaného ročního období pro podrobné seznámení dodavatelů s použitými technologiemi, principy a postupy spojenými se stávajícími softwarovými řešeními tak, aby byli schopni účelně naplnit cíle RD1,
provedení analýz možného řešení a postupu,
rozhodnutí TA ČR o zvolené technologii,
dosažení kapacity dodavatelů RD1 pro zvolenou technologii,
zavedení agilního procesního rámce řízení a způsobu vývoje na straně TA ČR.

TA ČR se s ohledem na další zájem resortů o sdílení funkcionalit softwarových řešení, existenci jiných informačních systémů a potřeby datové výměny mezi nimi, požadavky na konsolidaci existujících softwarových řešení, návrh nových funkcionalit a vylepšení stávajících softwarových řešení, rozhodla pokračovat v řešení projektu SISTA.

TA ČR uzavřela dne 31. 1. 2022 s 15 dodavateli rámcovou dohodu etapy 2 (dále jen „RD2") a to na základě veřejné zakázky VZ0125322: Sdílený informační systém TA ČR - etapa 2. Vytvoření softwarového řešení SISTA bude pokračovat v intencích následujících bodů:

seznámení dodavatelů s dosavadními výstupy projektu SISTA formou řízeného onboardingu,
zavedení GCP jako technologického základu SISTA a REST API jako komunikačního rozhraní,
provádění analýz funkcionalit za účelem zlepšení jejich efektivity a navrhování nových funkcionality při dodržení technologického rámce,
analyzování s návrhem řešení provozu funkčních vzorků a prototypů,
ověření předpokladů pro zavedení nových funkcionalit a nových technologií,
vyvíjení nových funkcionalit a zlepšení na nových technologiích,
uvádění technologií v produkční provoz a řešení souvisejících otázek.

1.2. Účel dokumentu

TA ČR buduje v postupných krocích cloud native systém a to na základě výstupů analytických minitendrů RD1, diskusí s řešiteli implementačních minitendrů RD2, aplikuje DevOps přístup mezi IDP týmem/dodavateli a vytvořila další potřebné prerekvizity (GCP, GitLab, CI/CD pipelines, pravidla architektury, platformy, vývoje, vedení dokumentace, design systém, knihovnu UI komponent, katalog služeb a datový katalog) pro další pokračování projektu. Na následujícím obrázku je znázorněn konceptuální rámec SISTA:

Obrázek 1. Konceptuální rámec projektu SISTA

Dokument popisuje jednotlivé aspekty řízení projektu v souladu s výše uvedeným konceptuálním rámcem a je hlavním informačním zdrojem pro projektový tým SISTA/dodavatele minitendrů.

Dále jsou zohledněny principy, procesy, doporučení popsaná v následujících dokumentech a standardech:

Informační koncepce České republiky [IKCR],
Průvodce světem řízení IT projektů [PrIT],
Bezpečnostní doporučení pro vývoj otevřeného software [NUKIB],
The Definitive Guide to Scrum: The Rules of the Game (November 2020) [Scrum],
Vybrané konvenční procesy managementu projektu dle ISO 21502:2020 promítnuté do kapitoly 6, Konvenční procesy.

Poznámky

Popisy procesů, nástrojů a technik jsou zúženy na míru nezbytně nutnou pro metodicky dostatečné řízení projektu.
Základní principy řízení projektu nenahrazují rámcovou dohodu, pouze definují vybrané postupy tak, aby byl projekt realizován v řízených podmínkách a jsou součástí pravidel zadavatele pro vývoj služeb a vedení související dokumentace.
Dodavatelé mají v rámcové dohodě uloženou povinnost pravidla zadavatele respektovat.

1.3. Aktualizace dokumentu

Dokument je v pravidelných intervalech - obvykle na sklonku kalendářního roku - aktualizován o nové poznatky z průběhu řešení (zejména na základě vyhodnocení naplnění cílů minitendru a zpětné vazby získané při retrospektivách sprintů), přičemž:

Za aktualizaci dokumentu odpovídá projektový manažer.
Změny dokumentu se provádějí vytvořením a schválením nové verze.
Přírůstek pravidel podléhá interní diskusi v rámci SISTA DevOps (IDP tým a dodavatelé).
Schválená verze je uložena do adresářů sdílených disků viz Oddíl 3.2.1, “Projektové knihovny”.
Zástupci dodavatelů jsou o změnách pravidel řízení projektu SISTA informováni.

2. Organizační zajištění projektu

2.1. Organizační struktura projektu

V souladu s interními pravidly řízení projektů [SME-33] ustavila agentura pokynem ředitele Kanceláře TA ČR tyto orgány řízení projektu: řídící výbor, sponzora projektu, projektový tým a Focus Group SISTA viz obrázek:

Obrázek 2. Organizační struktura projektu SISTA
V organizační struktuře projektu jsou vyznačeny role vycházející z procesního rámce Scrum.
Scrumové týmy vznikají dynamicky dle potřeb aktuálně řešeného tématu (srov. s Oddíl 2.2.4, “Scrumový tým”).
V rámci scrumového týmu již nejsou žádné dílčí týmy ani hierarchie. Jedná se o skupinu spolupracujících profesionálů zaměřenou na dosažení konkrétního cíle.

Řešení témat projektu SISTA může vyvolat ad hoc potřebu vytvoření dočasné pracovní skupiny či mikrotýmu - například pro účely hledání vhodného technického řešení identifikovaného problému nebo prototypování v SW Figma. Konkrétní podobu a způsob fungování stanoví projektový tým SISTA.

2.2. Role a odpovědnosti

2.2.1. Řídící výbor

TA ČR ustavila pro potřeby směřování projektu řídící výbor složený z těchto rolí: zástupci předsednictva, ředitele Kanceláře TA ČR, ředitelů sekcí, ředitele odboru ICT, IDP týmu, projektového manažera, koordinátora projektu a vlastníků aktuálně řešených témat.
Řídící výbor je vrcholným řídícím orgánem projektu, který průběžně vytváří vhodné podmínky pro úspěšnou realizaci projektu.
Řídící výbor při realizaci projektu:
1. schvaluje věcný a finanční rámec témat minitendrů,
2. bere na vědomí měsíční zprávu o stavu projektu ve formě prezentace,
3. rozhoduje o záležitostech, jejichž rozhodnutí není možné učinit na úrovni řízení projektu,
4. kontroluje realizaci a postup plnění minitendrů,
5. schvaluje dokumenty projektu dle Oddíl 3.5, “Schvalování klíčových dokumentů”,
6. vyjadřuje své stanovisko k výsledku akceptačního řízení,
7. ukládá svým členům úkoly, které mohou podpořit realizaci projektu,
Pravidla jednání upravuje Oddíl 2.3.1, “Jednání řídícího výboru”.

2.2.2. Sponzor projektu

Sponzorem projektu je ředitel Kanceláře TA ČR.
Sponzor projektu rozhoduje o klíčových aspektech projektu, neboť odpovídá za přínos pro organizaci.
Sponzor projektu při realizaci projektu:
1. na základě týdenních status reportů a operativních schůzek rozhoduje o směřování projektu,
2. řeší eskalace provozních záležitostí projektu, konflikty zdrojů či problémy s poskytnutím součinnosti projektu v rámci organizační struktury,
3. vytváří odpovídající prostředí a podporuje uplatňování dobré praxe (nejen agilního) řízení.
Je statutárním zástupcem pro smluvní záležitosti.

2.2.3. Projektový tým

Základní výkonný orgán projektu SISTA ustanovený interním pokynem ředitele Kanceláře TA ČR, který zajišťuje:
1. aktivní plnění projektových úkolů a dodržování dílčího harmonogramu sprintu,
2. aktivní plnění úkolů uložených sponzorem projektu nebo řídícím výborem,
3. řízení identifikovaných rizik (posuzování dopadů, návrhu odezvy apod.),
4. návaznosti na existující nastavené postupy maticového řízení. Jedná se o:
  1. změnové řízení [SME-37] (zásadní změny v nastavení procesů mají být řešeny řízeným způsobem jako změnové požadavky),
  2. metodické řízení (diskuse nad věcným zadáním řešeného tématu s metodiky),
  3. programové týmy (prostřednictvím vedoucích programových týmů).
5. sdělování inovací a vylepšených postupů, kterých projekt dosáhl či mohl by dosáhnout, členům řídícího výboru.
Projektový tým přijímá rozhodnutí v rozsahu, který nevyžaduje rozhodnutí řídícího výboru.
Pravidla jednání upravuje Oddíl 2.3.2, “Jednání projektového týmu”.

2.2.4. Scrumový tým

Scrumový tým (řešitelský tým):
1. jedná se vždy o menší tým^[1] utvářený dle potřeb minitendru/konkrétního sprintu,
2. skládá se z vlastníka produktu, vývojářů (zástupců dodavatele) a volitelně také ze Scrum Mastera. Prostřednictvím vlastníka produktu má scrumový tým potřebný kontakt s byznysem,
3. obsahuje všechny odbornosti potřebné k práci na úkolech sprintu tak, aby nevznikaly časové prodlevy v práci. Požadavky na odbornost se mohou s každou iterací sprintu měnit,
4. sám volí způsob, jak nejlépe vykonávat svou práci a má všechny kompetence potřebné pro dokončení práce bez závislosti na lidech, kteří nejsou bezprostřední součástí týmu,
5. odpovídá za dodávku vymezených aktivit a výstupů v požadované kvalitě a dle časového harmonogramu sprintu. Tým jako celek přijímá závazek dosáhnout cílů každého sprintu a rozhodující měrou se podílí na každém Oddíl 4.4.2, “Plánování sprintu”.
Pravidla jednání upravuje Oddíl 2.3.3, “Jednání scrumového týmu”.

2.2.5. IDP tým

IDP tým poskytuje Dev týmům Internal Developer Platform (IDP) zahrnující správu vrstev kompletního provozu technologické platformy včetně CI/CD pipelines.
IDP tým je v projektu SISTA organizačně podřízen sponzorovi projektu a to z důvodů oddělení odpovědností za dodávku a následného provozu služeb SISTA.
IDP tým odpovídá zejména za zajištění:
1. běhových prostředí TESTING, STAGING a PRODUCTION v Google Cloud Platform,
2. šablon předpisů kontejnerů a konzultací DEV týmům při prvotních nasazeních,
3. nástrojů pro deploy do prostředí GCP a to prostřednictvím služby GitLab Pipelines,
4. pravidelných koordinací DevOps, kterých se účastní zástupci dodavatelů (Dev) a IDP týmu (Ops),
5. rozvoje platformy SISTA a souvisejících pravidel viz kapitola 5, Architektura, vývoj a dokumentace.
Pravidla jednání DevOps SISTA upravuje Oddíl 2.3.4, “Jednání DevOps SISTA”.

2.2.6. Business analytici SISTA

Vytvoření týmu business analytiků SISTA vyplynulo z řešení byznysových/průřezových služeb SISTA a postupného nahrazování stávajících softwarových řešení.
Z pohledu řízení projektu jsou business analytici SISTA podřízeni projektovému manažerovi.
Tým business analytiků SISTA odpovídá zejména za zajištění:
1. odborného zázemí a poskytování konzultací garantům jednotlivých minitendrů v otázkách průřezových témat, testování, modelování procesů a architektury služeb,
2. UX/UI podpůrných aktivit (interview s uživateli, prototypování v SW Figma, ergonomie služeb, které mají UI),
3. spolupráce při přípravě definice funkčních/nefunkčních požadavků na připravovanou službu,
4. spolupráce při řešení otázek spojených s postupným přechodem agend ze stávajících softwarových řešení,
5. přípravu a realizaci tematických workshopů (ve spolupráci s projektovým manažerem) např. k modelování v SW Archi, AsciiDoc formátu, procesnímu rámci Scrum, PlantUML a další.

2.2.7. Projektový manažer

Pracovník jmenovaný interním pokynem ředitele Kanceláře TA ČR, který odpovídá za řízení projektového týmu a řádné plnění projektu.
Projektový manažer odpovídá zejména za zajištění:
1. realizace projektu v souladu s celkovou vizí a rámcovými cíli projektu,
2. komunikace vůči dodavatelům tak, aby bylo zajištěno pochopení požadavků zákazníka projektu,
3. součinnosti členů projektového týmu při realizaci sprintů a dalších projektových aktivit,
4. dodržování harmonogramu projektu/minitendrů a termínů vyplývajících z evidence úkolů,
5. konzistentní a očekávané kvality všech dodávek s navazujícími akceptacemi viz Oddíl 4.5, “Akceptace a uzavření minitendru”.
Projektový manažer je členem řídícího výboru s hlasem poradním.
V kontextu agilního rámce řízení může plnit roli Scrum Mastera ^[2]:
1. zajišťuje, aby cíle, rozsah a doména produktu byly členy scrumového týmu chápány tak dobře, jak je to jen možné,
2. zajišťuje, aby vlastník produktu věděl, jak uspořádat produktový backlog, aby maximalizoval získaný přínos,
3. pomáhá scrumovému týmu porozumět, proč je potřeba mít položky v produktovém backlogu vyjádřené srozumitelně, stručně a jasně,
4. odpovídá za realizaci scrumových procesů – facilituje jednání, dbá na dodržování termínů a konání scrumových událostí,
5. odstraňuje překážky a rušivé vlivy, aby se scrumový tým mohl soustředit na dodání výstupů sprintu/minitendru.

2.2.8. Koordinátor projektu

Koordinátor projektu spolupracuje s projektovým manažerem a dále zajišťuje:
1. aktivní organizační podporu manažera projektu po celý životní cyklus realizace projektu/sprintů minitendru,
2. koordinaci jednání řídícího výboru - naplánování, finální kontrola předkládaných podkladů, zpracování a uzavření zápisu z jednání,
3. distribuci a vypořádání zápisu z jednání projektového týmu,
4. spolupráci při řízení komunikace mezi subjekty zainteresovanými v projektu - například zaplánování události do kalendáře SISTA external, rozeslání podkladů na jednání, zodpovídání dotazů dodavatelů,
5. udržování adresářové struktury projektových knihoven: Interní projektová knihovna a Projektová knihovna pro dodavatele viz Oddíl 3.2.1, “Projektové knihovny”,
6. udržování spisů projektu SISTA v elektronické spisové službě,
7. udržování registru minitendrů uloženého v interní projektové knihovně.

2.2.9. Focus group SISTA

Focus group SISTA je složena z vybraných členů předsednictva, výzkumné rady TA ČR a společně tvoří expertní poradní orgán projektu.
Jednání s Focus group SISTA plánuje sponzor projektu. Projektový manažer připraví potřebné podklady pro vlastní jednání.
Vstupem pro jednání je prezentace témat pro Focus group SISTA s informacemi o postupu realizace či směřování projektu.

2.3. Pravidla jednání

2.3.1. Jednání řídícího výboru

Jednání řídícího výboru se konají pravidelně jednou měsíčně (zpravidla druhé pondělí v měsíci) bezprostředně po poradě sekčních ředitelů.
V naléhavých případech je možná změna termínu jednání - tato změna musí být oznámena členům řídícího výboru nejméně 2 pracovní dny předem.
Koordinátor projektu rozesílá odkaz na prezentaci nejpozději 1 pracovní den před termínem jednání.
Agenda jednání řídícího výboru:
1. odečet evidence úkolů uložených na předchozím jednání řídícího výboru,
2. celkové shrnutí hodnoceného období (objem a tempo práce, histogramy výsledků,…),
3. čerpání rozpočtu projektu za hodnocené období,
4. shrnutí jednotlivých minitendrů - aktuální stav, akceptace a případné překážky řešení,
5. eskalace otevřených bodů z řízení projektu,
6. výhled témat s odhadem finanční alokace,
7. případné návrhy rozhodnutí řídícího výboru k jednotlivým otázkám,
8. stav přípravy nových témat,
9. diskuse.
Případné další návrhy bodů pro konkrétní jednání musí být oznámeny předem, aby se členové řídícího výboru mohli připravit na rozhodnutí.
Jednání nebo části jednání řídícího výboru se mohou zúčastnit i další osoby. Takové osoby se však nepodílí na rozhodování řídícího výboru a musí být známy před jednáním.
Řídící výbor přijímá rozhodnutí konsensuálně, tj. shodou všech přítomných členů. V odůvodněných případech je možné přijmout rozhodnutí per-rollam s dodatečným potvrzením rozhodnutí.
Zápis z jednání řídícího výboru je do 2 pracovních dnů následujících po jednání rozeslán k připomínkám a do 5 pracovního dne následujícího po jednání uzavřen.
Finální zápis je uložen v adresáři příslušného jednání řídícího výboru a ve spisové službě.

Šablona zápisu je připojena v přehledu Příloha A, Šablony a formuláře.

2.3.2. Jednání projektového týmu

Jednání projektového týmu probíhá pravidelně každé pondělí od 9:00 hod.
Projektový manažer připravuje jednotlivé body jednání k projednání projektovým týmem:
1. manažerské shrnutí ww - informace o předchozím týdnu z pohledu tempa práce, uzavřených nebo zpožděných milníků,
2. koordinace projektu SISTA se zástupci dodavatelů - zpětná vazba z pátečních schůzek,
3. odečet postupu řešení sprintů (minitendrů),
4. kontrola evidence úkolů projektu nad rámec běžících sprintů,
5. ostatní operativní témata k řízení projektu a podněty projektového týmu.
Koordinátor projektu bezprostředně po jednání rozesílá odkaz na zápis k připomínkám. Členové projektového týmu jej do 2 pracovních dnů připomínkují.
Finální zápisy jsou uloženy v adresáři: 02. Projektový tým SISTA projektové knihovny.
Koordinátor projektu uloží kopii zápisu ve formátu PDF do adresáře: „PDF verze pro tisk” a příslušného spisu v elektronické spisové službě.

Šablona zápisu je připojena v přehledu Příloha A, Šablony a formuláře.

2.3.3. Jednání scrumového týmu

Jednání scrumového týmu probíhají podle potřeb každého sprintu a jsou organizována vlastníkem produktu.
Požadavek na každodenní koordinaci scrumového týmu (Daily Scrum) je aplikován přiměřeně.
Dodavatelé aktuálně běžících minitendrů mají k dispozici pravidelné koordinace na konci týdne (max. 15 minut na minitendr) s projektovým manažerem.
Z úrovně řízení projektu jsou akceptovány jakékoliv flexibilní nástroje komunikace, které nebudou omezovat dodávku přírůstku sprintu. Vycházíme z předpokladu, že je v zájmu obou stran dodat přírůstek v požadované kvalitě a dle harmonogramu.
Vlastník produktu je povinen zaznamenat realizované konzultace prostřednictvím strukturované tabulky Google pro záznam jednání, která je po celou dobu trvání řešení minitendru sdílena s „tacr-external” účtem dodavatele.
Projektový manažer může dle aktuálního stavu řešení minitendru pravidla vedení dokumentace scrumového týmu upravit.

Dobrou praxí pro týmovou komunikaci v rámci scrumového týmu je používání Spaces v prostředí Google Chat, které kromě klasického chatu podporují připojení souborů a jednoduchou správu úkolů.

2.3.4. Jednání DevOps SISTA

Jednání DevOps SISTA probíhá pravidelně v intervalu 1x14 dní za účasti zástupců IDP týmu a dodavatelů s tím, že věcnou náplní těchto jednání jsou výhradně otázky týkající se technické stránky řešení SISTA s vyloučením jakýchkoliv zásahů do byznys části služeb.
Jednání DevOps SISTA organizuje a řídí vedoucí oddělení vývoje IS.
DevOps SISTA přijímá rozhodnutí konsensuálně s cílem dosažení nejlepšího možného řešení ve prospěch DevOps/projektu SISTA.
DevOps SISTA z pohledu přínosů zajišťuje:
1. řešení identifikovaných incidentů napříč službami SISTA,
2. koordinaci nasazení služeb na STAGING a PRODUCTION prostředí,
3. diskuzi a výběr nejvhodnějších variant řešení napříč všemi dodavateli,
4. rozvíjení služeb platformy, pravidel architektury, vývoje a vedení dokumentace.
Vedoucí oddělení vývoje IS vypracuje a rozešle z jednání DevOps SISTA zápis, který je připojen k události.
Vedoucí oddělení vývoje IS má pravomoc po dohodě s Dev týmy a projektovým manažerem upravovat termíny/četnost jednání DevOps SISTA dle aktuálních potřeb řešení projektu.

Šablona zápisu je připojena v přehledu Příloha A, Šablony a formuláře.

2.4. Odpovědnost vedení projektu

Vedení projektu zastoupené řídícím výborem a projektovým týmem odpovídá za řízení projektu a plnění požadavků kladených na výstupy projektu. Vedení projektu také vyžaduje dodržování stanovených pravidel řízení od všech členů projektového týmu.

Vedení projektu se dále zasazuje o transparentní a otevřenou komunikaci s cílem seznamovat všechny členy projektového týmu a zástupce dodavatelů se zásadními informacemi o:

vývoji projektu,
výsledcích dílčích projektů a jejich využití k rozvoji činností agentury,
požadavcích zainteresovaných stran při realizaci témat projektu,
změnách regulatorních požadavků s dopady na projekt,
významu plnění požadavků kladených na projekt.

2.5. Závazek projektového týmu

Projektový tým se zavazuje realizací projektu SISTA vytvořit pro TA ČR co nejvyšší přidanou hodnotu, dosahovat specifických cílů minitendrů a navzájem se podporovat při plnění úkolů. Členové projektového týmu mají odvahu dělat správnou věc a pracovat na náročných úkolech. Všichni se budou plně soustředit na práci v konkrétním sprintu a na směrování projektu k naplnění jeho cílů.

Projektový tým a další klíčoví účastníci projektu budou otevření ohledně veškeré práce a všech výzev, jimž budou během práce na projektu čelit.

Scrumové týmy složené z projektového týmu a zástupců dodavatelů se navzájem respektují a považují ostatní za schopné a nezávislé spolupracovníky se stejným cílem.

2.6. Evidence úkolů projektu

Evidenci úkolů projektu spravuje projektový manažer prostřednictvím zápisů z jednání řídícího výboru nebo projektového týmu. S ohledem na agilní přístup k řízení není žádoucí projekt jakkoliv zatěžovat nadbytečnými administrativními agendami.

Scrumové týmy si evidují dílčí úkoly podle potřeby samy - zajišťuje vlastník produktu prostřednictvím evidence konzultací s dodavatelem minitendru.

Na základě retrospektivy sprintu a stavu řízení rizik projektu může být rozhodnuto o jiné formě řízení úkolů projektu.

2.7. Procesní rámec Scrum

Procesní rámec Scrum ^[3] vznikl na počátku 90. let a první oficiální průvodce pravidly hry byl vydán v roce 2010. Scrum se skládá ze scrumových týmů, přidružených rolí, scrumových událostí, artefaktů a pravidel. Scrum využívá iterace zvané sprinty s přesně danou dobou trvání - typicky 1 až 2 ww, ne delší než 4 ww.

Obrázek 3. Iterace sprintu metody Scrum

Na počátku každého minitendru dochází ke sběru požadavků na výsledný produkt (budoucí stav produktu, který je definován prostřednictvím produktových cílů a jejich prioritizací).

Do definice požadavků a produktových cílů vstupují požadavky sponzora projektu a zainteresovaných stran, dalším zdrojem mohou být rámcové cíle SISTA vypracované projektovým týmem v úvodní části projektu, různé seznamy „nice to have” funkcionalit či problémů současných softwarových řešení. Výsledkem je produktový backlog, který obsahuje rámec veškerých požadavků kladených na nový produkt.

Z hlediska priorit a logické návaznosti jsou požadavky během plánování sprintu řazeny do sprintového backlogu, který představuje plán práce na nadcházející období.

V průběhu sprintu se scrumový tým pravidelně schází, aby vyhodnotil postup a přijal potřebná rozhodnutí - neprovádí se však žádné změny ohrožující cíle sprintu.

Na konci sprintu by měl být hotový produkt, resp. jeho přírůstek, který je samostatně funkční (nasaditelný) a splňuje produktový cíl. Scrumový tým se u prvních iterací sprintů soustředí především na dodání minimálního životaschopného produktu.

Hotový produkt (přírůstek produktu) je předán prostřednictvím revize sprintu. Závěrečná retrospektiva sprintu slouží k ohlédnutí a poučení se ze zkušeností získaných v uplynulém sprintu (nejen, co se nepodařilo, ale také pozitivní zkušenosti).

Poznatky sebrané po uzavření řešení minitendru jsou později využívány při lessons learned prezentacích, diskuzích projektového týmu s vedením agentury a sdílení poznatků mezi vlastníky produktů.

Nedílnou součástí řešení implementačních minitendrů jsou také prezentace dosažených výsledků (funkcionalit) ostatním účastníkům rámcové dohody.

3. Administrace a konvence projektu

V následující kapitole jsou popsána základní pravidla řízení dokumentů projektu. Postupy upravené vnitřním předpisem [SME-01] se použijí přiměřeně.

Řízení dokumentů projektu podléhají také Příloha A, Šablony a formuláře tvořící přílohy pravidel řízení.
Dojde-li k potřebě změny šablony formuláře, vyvolá projektový manažer změnové řízení a dále postupuje dle matice Oddíl 3.5, “Schvalování klíčových dokumentů”.

3.1. Formální požadavky

V souladu s podmínkami zadávací dokumentace nadlimitní veřejné zakázky je veškerá komunikace k řešení minitendrů mezi zadavatelem a dodavateli vedena v českém jazyce.
Při vytváření dokumentů používají týmy takové typy fontů, které zajistí korektní zobrazení napříč běžně používanými operačními systémy (Titillium Web^[4], Open Sans, Roboto a naopak zcela nevhodné jsou fonty: Calibri, Cambria či další proprietární fonty).

Scrumové týmy sdílí dokumentované výstupy projektu - pokud to jejich charakter umožňuje - prostřednictvím Google Workspace. Klíčové výstupy budou na titulní straně opatřeny jednoduchou tabulkou obsahující informace o historii posledních dvou verzí viz příklad:

Tabulka 1. Základní tabulka historie změn dokumentu
Verze	Datum	Autor	Popis změny
01	dd/mm/yyyy	Jméno a příjmení	Návrh zprávy předložený projektovému týmu.
draft	dd/mm/yyyy	Jméno a příjmení	Finální verze předložená k akceptaci.

Doporučujeme poslední verzi v historii dokumentu, tabulky či prezentace Google z preventivních důvodů pojmenovat např. „Finální verze 1” nebo „Verze k akceptaci dd.mm.yyyy” (Soubor › Historie verzí › Pojmenujte současnou verzi).
Názvy souborů v projektové knihovně vystihují jejich obsah, nepřípustné jsou výchozí názvy typu „Tabulka bez názvu” nebo „Dokument bez názvu”. Doporučujeme do názvu souboru doplnit jako prefix číslo řešeného minitendru.
Výstupy minitendru vytvářené ve formátu AsciiDoc mají ze strany projektového týmu TA ČR vždy předem určenou strukturu, kterou dodavatel respektuje a nadbytečně nerozšiřuje.
Pokud je nutné zaslat soubory e-mailem, uživatel doplní do názvu souboru datum poslední úpravy (např. handbook-SISTA-2024-01-08.zip, MT090-definice-pozadavku-2024-01-08.pdf,…).
Finální dokumenty (hodnocení návrhů řešení, akceptační protokoly, akceptované výstupy a další dokumenty) jsou v souladu s interními pravidly [RAD-07] ukládány do elektronické spisové služby.

Dokumenty ve formátu AsciiDoc budou vždy obsahovat hlavičku v minimální struktuře:

Základní a uživatelské atributy:

// Hlavicka dokumentu 
= MTXYZ Nazev minitendru : specifikace dokumentu
:author: Jméno a příjmení autora, Název dodavatele
:email: e-mail autora dokumentu
:revnumber: 1
:revdate: dd/mm/yyyy
:revremark: Stručná charakteristika verze.
:pdf-themesdir: resources/themes
:pdf-fontsdir: resources/themes/fonts
:pdf-theme: brand-tacr
:pdf-page-layout: portrait
:doctype: book/article  
:encoding: utf-8
:lang: cs
 include::locale/attributes.adoc[]
:toc-title: {toc-title}
:toc: left
:toclevels: 4
:sectnums:
:xrefstyle: full
:table-stripes: even
:experimental:
:chapter-signifier:
:chapter-refsig: {chapter-signifier}
// Uživatelské atributy
:templateID: T-XYZ
:document-classification: Neveřejný
:discarding-symbol:
:retention-period:
:Custom_1: TACR/XX-YY/2023
:Custom_2: {doctitle}
:Custom_3: {output-generated} : {docdatetime}
:keywords:

Historie změn:

// Na konci dokumentu
== Historie změn 

[%hardbreaks]
Verze: {revnumber}
Datum aktualizace: {revdate}
Autor: {author}, {email}
Poznámka k verzi: {revremark}

''''
[underline]#Popis hlavních změn verze 1:#

* Lorem ipsum dolor sit amet, consectetuer adipiscing elit.

Minimální atributy hlavičky AsciiDoc dokumentu.
Typ dokumentu - rozdíly popisuje uživatelská dokumentace AsciiDoc.
Historie změn uvedená jako samostatná kapitola nebo prostřednictvím funkce include vložený adoc.

Zájemce odkazujeme na dokumentaci projektu AsciiDoctor, případně AsciiDoc a nespočet internetových tutoriálů.
Projektový tým SISTA dále disponuje pravidelně aktualizovanou příručkou („cheatsheet“) k používání adoc formátu.

3.2. Ukládání dokumentů projektu

3.2.1. Projektové knihovny

Za účelem ukládání dokumentů souvisejících s realizací projektu byly zřízeny dva sdílené disky Google a GitLab repozitáře pro jednotlivé služby SISTA:
1. Interní projektová knihovna - strukturované úložiště pro potřeby projektového týmu.
2. Projektová knihovna pro dodavatele - strukturované úložiště pro potřeby sdílení akceptovaných a uzavřených výstupů minitendrů se zástupci dodavatelů.
3. GitLab repozitář projektu SISTA - strukturované úložiště zdrojových kódů a související dokumentace viz kapitola: 5, Architektura, vývoj a dokumentace.
Koordinátor projektu spravuje strukturovaný Přehled předané dokumentace, který je uložen v projektové knihovně pro dodavatele.
Primárním úložištěm dokumentů souvisejících s řešením minitendru je interní projektová knihovna spravovaná koordinátorem projektu a projektovým manažerem.
Vlastníci produktů si sami organizují obsah adresáře projektové knihovny každého sprintu a odpovídají za dodržování pravidel administrace projektu.
Řešitelé minitendrů mají do adresářů projektové knihovny přidělena přístupová práva. Sdílení souborů se zástupci dodavatelů mimo účty domény „tacr-external.cz” je zakázáno.
Při uzavření minitendru provedou koordinátor projektu ve spolupráci s vlastníkem produktu revizi přístupových práv a dle potřeby ponechá/odebere přístupy z domény „tacr-external.cz”.
Pro každou vyvíjenou službu existuje vždy samostatný GitLab repozitář a řešitel je povinen vyvíjet proti tomuto repozitáři. Další požadavky upravují Oddíl 5.4, “Pravidla vývoje” a Oddíl 5.6, “Pravidla vedení dokumentace”.

3.2.2. Adresářová struktura MT

Koordinátor projektu odpovídá za vytvoření adresářové struktury nového tématu v interní projektové knihovně. Závazná struktura je uvedena na následujícím obrázku:

Obrázek 4. Adresářová struktura minitendru v projektové knihovně
- 01. Analýzy a příprava zadání: všechny podpůrné podklady zadání minitendru. Postup přípravy upravuje Oddíl 4.2, “Příprava zadání minitendru”. Adresář není přístupný dodavatelům.
- 02. Výzva k podání a hodnocení návrhů řešení: finální znění výzvy k podání návrhů řešení ve formátu PDF. Následně je do tohoto adresáře přesunuta celá složka s návrhy řešení, podklady pro hodnocení a závěry hodnotící komise. Adresář není přístupný dodavatelům.
- 03. Realizace řešení - sprinty a scrumové události: adresář s kopií dílčí realizační smlouvy a dále adresáře ve struktuře dílčích sprintů. Každý adresář sprintu obsahuje vnořený podadresář pro uložení podkladů scrumových událostí. Adresář je po dobu řešení přístupný dodavateli minitendru.
- 04. Akceptační řízení a fakturace: finální výstupy a podklady, které jsou předmětem Oddíl 4.5, “Akceptace a uzavření minitendru”. Adresář není přístupný dodavatelům.
- 05. Lessons learned minitendru: podklady pro společný workshop s vedením agentury a projektovým týmem viz Oddíl 6.4, “Shromáždění poznatků”. Adresář není přístupný dodavatelům.
- 06. Záznamy o jednání s dodavatelem: výkaz realizovaných konzultací a uložených úkolů ve formě Tabulky Google. Adresář je po dobu řešení přístupný dodavateli minitendru.
  
  Na druhé záložce výkazu jsou uvedeny přístupy poskytnuté dodavateli v rámci součinnosti.
- 07. Závěrečná prezentace pro ostatní účastníky RD: prezentace s představením funkcionalit či dosažených výsledků řešení minitendru. Adresář není přístupný dodavatelům.
- 08. Sanity check minitendru: podklady provedené kontroly dodaného plnění před Oddíl 4.5, “Akceptace a uzavření minitendru”.

3.3. SW nástroje a formáty souborů

Při vytváření výstupů projektu budou přednostně používány následující SW nástroje a formáty souborů:
- Adobe Acrobat nebo Okular: .pdf,
- Archi: .archimate,
- AsciidocFX: .adoc,
- Draw.io Desktop: .drawio,
- Gantter for Google Workspace: .gantter,
- GanttProject: .gan,
- Google Workspace: .gdoc, .gsheet, .gslides, .gform a .gdraw,
- LibreOffice: .odt, .ods, .odp, .odg,
- PlantUML: .puml nebo .txt (text/plain),
- Swimlanes.io: .txt (text/plain),
- Inkscape: .svg (SVG Inkscape),
- Figma: .fig nebo Penpot: .penpot.
V případě potřeby může být výše uvedený výčet po vzájemné dohodě rozšířen - platí však zásada, že jednotlivé týmy v maximálně míře využívají SW nástroje, které nezatěžují projekt dodatečnými náklady spojenými s pořízením licencí a pokud je to možné, používané aplikace jsou multiplatformní (macOS/Linux/Windows) z kategorie open-source software.

3.4. Klíčové artefakty projektu

Klíčové artefakty projektu vychází z procesního rámce Scrum a požadavků na řízení vybraných procesů projektového řízení:

Soubor pravidel publikovaných na rozcestníku dokumentace SISTA:
- Handbook projektu - základní principy a procesy řízení projektu viz Oddíl 1.2, “Účel dokumentu”.
- Archimate modely – HTML export obsahující pohledy na procesy, byznysové/průřezové/integrační služby, platformu SISTA a dalšími kontextovými informacemi k projektu SISTA.
- Katalog služeb - základní přehled všech aktuálně existujících služeb spolu s informacemi o vzájemných závislostech. Ke každé službě jsou v katalogu připojeny odkazy na repozitář, HOWTO-DEVS-OPS dokumentaci a dokumentací API rozhraní.
- Pravidla architektury - základní pravidla pro stavbu architektury SISTA spolu s principy spolupráce mezi DEV a OPS týmy prostřednictvím DevOps.
- Pravidla platformy - soubor pravidel udržování a rozvoje běhových prostředí TA ČR v Google Cloud Platform s vodítky pro nasazování služeb a dalšími praktickými doporučeními ve vztahu k využívání GCP.
- Pravidla vývoje - soubor pravidel k udržení minimalistické standardizace a popisu vývoje služeb, určení zásadních kroků vývoje, údržby spolu s definicí základních zodpovědností na úrovni DevOps týmů, stanovení způsobu verzování a dlouhodobé údržby zdrojových kódů.
- Pravidla UX a design systém - soubor principů, pravidel, UI elementů a dalších podkladů pro tvorbu uživatelského rozhraní SISTA.
- Pravidla vedení dokumentace - určují minimální rozsah dlouhodobě udržitelné dokumentace při vývoji, údržbě a dalším rozvoji služeb SISTA.
- HOWTO Platform – soubor praktických rad a návodů nejen pro dev týmy. Jedná se o živý dokument, který je ze strany IDP týmu průběžně doplňován o nové poznatky k prostředím, platformě, GITu, nasazování služby na platformu, synchronní/asynchronní komunikaci, logování a monitoringu služeb, secret managementu atd.
- Metodika sanity checku – jedná se o šablonu pro realizaci kontroly dodaného plnění minitendru a provedení code review. Mezi mandatorní položky sanity checku patří kontrola repozitáře, dokumentace, zdrojového kódu, internacionalizace, přítomnost testů a další.
- Knihovna UI komponent - základní UI komponenty vytvořené s využitím JavaScriptové knihovny React a Material UI. Jednotlivé UI komponenty jsou přizpůsobeny požadavkům DISTA UI Kit. Výsledná knihovna Storybook je nasazována prostřednictvím Chromatic.
- Datový katalog - přehled existujících i plánovaných datových entit včetně jejich popisu a dalších informací (např. vlastník entity). Datové entity jsou reprezentovány jak na byznys úrovni, tak technické úrovni. V katalogu jsou také etalony pro technickou implementaci entit v rámci služeb.
Registr minitendrů - obsahuje průběžně aktualizované informace o stavu realizace minitendrů. K registru jsou připojeny: znění výzvy minitendru, finální výstupy, akceptační protokol a odkaz na adresář minitendru v projektové knihovně. Registr minitendrů je dostupný zde.
Přehled čerpání rozpočtu - vedený projektovým manažerem formou tabulky s čerpáním rozpočtu ve vztahu k rámcovým dohodám, minitendrům, dodavatelům a přehledem podaných návrhů řešení.
Souhrnný harmonogram - vedený projektovým manažerem v SW Gantter. Další požadavky na vedení harmonogramu projektu upravuje Oddíl 6.1, “Řízení času”.
Specifikace zadání minitendru - vymezuje obsah plnění s další atributy zadání (např.: vlastník produktu, název, potřebnost, nejistota, cíle řešení, minimální výstupy, součinnost, zdroje, doba řešení, cena řešení a případné další požadavky).
Výstupy prototypování - jsou poskytovány buď ve formátu offline souboru SW Figma (*.fig) nebo přístupu do online prostředí Sw nástroje s jednotlivými prototypy (obrazovkami) služeb.
Návrh řešení - strukturovaný dokument předložený do výzvy k podání, kterým dodavatel popisuje způsob naplnění cílů minitendru.
Produktový backlog - seznam všeho, o čem se ví, že bude v produktu potřeba. Jedná se o jediný zdroj požadavků práce scrumového týmu. V úvodní fázi vývoje obsahuje zpočátku známé a nejlépe uchopitelné požadavky.

V podmínkách projektu SISTA je produktový backlog veden ve formě tabulky Google, kterou scrumový tým nejpozději před revizí sprintu aktualizuje.
Sprintový backlog - množina položek vybraných z produktového backlogu do sprintu, a to včetně plánu na dodání produktového přírůstku a splnění cíle sprintu. Na výběru položek spolupracuje vlastník produktu se zástupcem dodavatele (srov. s Oddíl 4.4.2, “Plánování sprintu”).
Týdenní status report - zasílá projektový manažer na konci pracovního týdne za účelem informování klíčových zainteresovaných stran o plnění harmonogramu sprintů s popisem stavu aktuálně řešených témat. Status report slouží také k plánování a určení priorit dalšího ww projektu.

Dále budou při řešení projektu vznikat zejména následující dokumenty/výstupy:

Zpráva o stavu projektu ve formě prezentace pro řídící výbor,
Zápis z jednání projektového týmu/řídícího výboru,
Záznamy jednání s dodavatelem,
Prezentace pro účely scrumových událostí (revize a retrospektiva sprintu),
Lessons learned prezentace uzavřeného minitendru,
Záznamy testování (automatizované testy, uživatelské testy),
Předávací a akceptační protokoly.

3.5. Schvalování klíčových dokumentů

Schvalování vybraných typů dokumentů se řídí následující tabulkou:

Tabulka 2. Matice schvalování klíčových dokumentů
Dokument	Vytváří	Schvaluje	Forma	Úložiště
Rámcové cíle projektu	Porada SŘ	Řídící výbor	Elektronická	Proj. knihovna
Základní principy a procesy řízení	Projektový manažer	Řídící výbor	Elektronická	GitLab
Pravidla architektury	Ředitel odboru ICT	DevOps	Elektronická	GitLab
Pravidla platformy	Ředitel odboru ICT	DevOps	Elektronická	GitLab
Pravidla vývoje	Ředitel odboru ICT	DevOps	Elektronická	GitLab
Pravidla UX a design systém	Ředitel odboru ICT	DevOps	Elektronická	GitLab
Pravidla vedení dokumentace	Ředitel odboru ICT	DevOps	Elektronická	GitLab
Souhrnný harmonogram projektu	Projektový manažer	Řídící výbor	Elektronická	Proj. knihovna
Harmonogram sprintu	Dodavatel MT	Vlastník produktu	Elektronická	N/A
Specifikace zadání minitendru	Vlastník produktu	Projektový manažer	Elektronická	Proj. knihovna
Produktový backlog	Vlastník produktu	Projektový tým	Elektronická	Proj. knihovna
Sprintový backlog	Dodavatel MT	Vlastník produktu	Elektronická	N/A
Zpráva o stavu projektu pro ŘV	Projektový manažer	Řídící výbor	Elektronická	Proj. knihovna
Zápis z jednání řídícího výboru	Projektový manažer	Řídící výbor	Elektronická	Proj. knihovna
Zápis z jednání projektového týmu	Koordinátor projektu	Projektový tým	Elektronická	Proj. knihovna
Inkrementy produktů / finální produkty	Scrumové týmy	Řídící výbor	Elektronická	Proj. knihovna
Záznamy o testování pro účely akceptace	Dodavatel MT	Vlastník produktu	Elektronická	Proj. knihovna
Záznam o provedeném sanity checku	Dodavatel MT	Vlastník produktu	Elektronická	Proj. knihovna
Checklist převzetí služby	Vlastník produktu	Projektový manažer	Elektronická	Proj. knihovna
Předávací a akceptační protokoly	Projektový manažer	Zástupce dodavatele Projektový manažer Ředitel odboru ICT Ředitel sekce interní podpory Sponzor projektu	Elektronická	Proj. knihovna Spisová služba

4. Realizace minitendrů

4.1. Typy minitendrů

TA ČR za účelem efektivního řešení projektu SISTA vymezila níže uvedené typy minitendrů (čl. 1, odst. 1 RD2):
1. analytické a konzultační - zaměřené na získání jednoho výstupu, tj. analýz či pořízení služby konzultací,
2. inovativně vývojové - předpokládající vícefázový přístup k hledání řešení. V rámci fází může být vybráno více prototypových řešení, která postupně prokážou předpokládanou funkčnost, přičemž z těchto řešení bude určena výsledná technologie, produkt či jeho vlastnosti,
3. programátorské a vývojářské - zaměřené výhradně na získání jednoho řešení postupem vývoje produktu (programováním) a to částí / služeb v projektu SISTA. Vlastností těchto minitendrů je dodržení způsobu vývoje (programování) podle předem daných kritérií, postupů, metodik či pravidel pro vývoj, testování a dokumentaci, a
4. ostatní.

Poznámky

Plnění minitendru typu „A” může být zadáno kterémukoliv dodavateli, pokud hodnota plnění v takovém minitendru nepřesáhne max. 300 tis. Kč bez DPH, přičemž:
- postup lze opakovat maximálně 6x v každém kalendářním roce.
- pro tento typ zadání se nepoužijí hodnotící kritéria dle RD2 (čl. 7, odst. 2).
V případě inovativně vývojových minitendrů typu „B” mohou být pro řešení vybráni až tři dodavatelé, kteří budou odděleně řešit své návrhy řešení s tím, že TA ČR může po jednotlivých etapách jednotlivá řešení ukončit (čl. 5, odst. 12 RD2).
Pro dosažení účelu plnění cíle minitendru typu „C” může TA ČR z důvodu doplnění kapacit využít vedle rámcové dohody také DNS, aby posílila programátorské a vývojářské kapacity na určené technologii (čl. 4, odst. 3 RD2).

4.2. Příprava zadání minitendru

4.2.1. Určení vlastníka produktu

Uvažovaná témata minitendrů jsou řídícím výborem projednána, schválena a stávají se pro projektový tým závazná.
Projektový tým témata postupně odebírá dle kapacitních možností a s přihlédnutím k aktuální situaci na projektu.
Projektový manažer po diskusi se sponzorem projektu a projektovým týmem určí vlastníka produktu spolu se závazným termínem pro vypracování zadání.
Vlastník produktu:
- Definuje a následně také srozumitelně sděluje produktové cíle („kam se chceme prostřednictvím přírůstků SISTA posunout”);
- Má jasnou vizi a představu o budoucím směru řešeného tématu;
- Zodpovídá za maximalizaci hodnoty produktu, který bude vytvářen;
- Zpravidla nedisponuje znalostmi technologií, avšak ovládá doménu byznysu agentury;
- Zná regulatorní mantinely, ve kterých se zvolené řešení musí pohybovat;
- Rozumí současné implementaci tématu v ISTA nebo IS BETA 2;
- Zná požadavky zainteresovaných stran.

Tipy

Vlastník produktu je určen podle věcné náplně tématu tak, aby byla zajištěna dostatečná odbornost po celou dobu řešení.

4.2.2. Analýza a definice požadavků

Vlastník produktu před vypracováním věcného zadání minitendru analyzuje současný stav řešené agendy za účelem návrhu nových funkcionalit či zefektivnění stávajících funkcionalit. Z analýzy současného stavu vzniká jako součást výzvy k podání návrhu řešení tzv. „definice požadavků“ na budoucí službu.
Vlastník produktu doplní k definici požadavků hledisko spolupráce obchodních procesů (Business Process Cooperation) a hledisko struktury aplikace (Application structure). Jedná se o specifické archimate modely vytvořené prostřednictvím open-source Archi.
Hledisko obchodních procesů obsahuje:
1. abstraktní pohled SIPOC (interně „helicopter view”) - definuje elementární kroky procesu, organizační jednotku, hlavní vstupy/výstupy, zákazníka procesu, kontextovou vazbu na modul/službu SISTA a dále obsahuje odkazy na podřízené diagramy:
  
  Obrázek 5. Uzavření smlouvy o poskytnutí podpory - helicopter view
2. procesní pohled (flow) - popisuje detailní kroky zasazené do kontextu procesních rolí vizualizovaných prostřednictvím plaveckých drah a obchodních objektů/reprezentací:
Obrázek 6. Jednání kolektivního orgánu - detailní flow
Hledisko struktury aplikace - popisuje se kterými dalšími službami bude připravovaná služba komunikovat či spolupracovat.

Obrázek 7. Byznysová služba Jednání - struktura aplikace
Vlastník produktu dále formuluje produktové cíle, které jsou zasazeny do kontextu definice požadavků a očekávání zainteresovaných stran.
Vlastník produktu s projektovým manažerem rozhodnou o:
- Způsobu výběru nejvhodnějšího návrhu řešení - postupem s obnovením soutěže (čl. 5 RD2) či postupem bez obnovení soutěže (čl. 6 RD2). Typickým příkladem pro uplatnění postupu bez obnovení soutěže jsou rozvojové požadavky kladené na některou z existujících služeb SISTA.
- Způsobu vypracování produktového backlogu - pokud je jasná představa výstupu řešení minitendru, je možné produktový backlog vypracovat samostatně. V ostatních případech lze za tímto účelem využít analytický a konzultační minitendr viz Oddíl 4.1, “Typy minitendrů”.
- Uložení povinnosti dodavatelům podat návrh řešení - zda bude využit tzv. povinně nabídkový minitendr dle čl. 2, odst. 2 rámcové dohody pro potřeby získání co největšího počtu možných řešení.
- Možnosti uvedení podmínek, za jakých může být dle čl. 5, odst. 18 RD2 vyplacena odměna za návrh zaměřený na hledání složitějšího řešení problému, postupu či způsobu řešení.
- Potřebě určení smluvní pokuty dle čl. 11, odst. 6 RD2. Výše smluvní pokuty bude stanovena ve výzvě přiměřeně k předmětu plnění.
- Časové náročnosti realizace minitendru - řešení delší než 4ww je rozděleno do více navazujících sprintů tak, aby byla dodržena jejich doporučená délka. Dále jsou stanoveny požadavky na případné konzultace k řešení tématu a závěrečné prezentace pro ostatní dodavatele.

Poznámky

Při řešení projektu SISTA se osvědčila praxe, při které jednotliví účastníci svými požadavky přispívají k vytvoření PoC průřezové služby, která je využívána ostatními byznysovými službami (typicky: společné vyhledávání, číselníková služba, PDF Generátor). V takovém případě se již neprovádí analýza současného stavu a PoC je základem specifikace zadání minitendru.
U komplexnější služby s větším množstvím funkcionalit a inkrementů je vhodné využít možnosti dílčích akceptačních řízení s více fakturačními milníky.
Při plánování času potřebného k realizaci je třeba brát v úvahu minimální lhůtu 7 kalendářních dnů pro podání návrhu řešení (viz. čl. 5, odst. 6 RD2) a dále čas potřebný na vyhodnocení došlých návrhů řešení.
Je-li předmětem plnění dodávka byznysové služby, pak je vhodné na začátek řešení zařadit „nultý sprint“ k rozplánování jednotlivých inkrementů, přičemž scrumové události potvrdí dodatelnost a strukturu jednotlivých přírůstků.

4.2.3. Návrh zadání minitendru

Projektový manažer vypracuje v součinnosti s vlastníkem produktu návrh zadání minitendru. Jedná se o soubor dokumentů, který obsahuje: výzvu k podání návrhu řešení, specifikaci zadání, předvyplněný návrh dílčí smlouvy spolu s předvyplněným návrhem řešení, definici požadavků, produktový backlog a informaci o proběhlé konzultaci k obsahu plnění.

U byznysových služeb vypracují interní UX tým ve spolupráci s vlastníkem produktu user flows, prototypy/obrazovky a další relevantní výstupy prototypování, které následně tvoří součást specifikace zadání minitendru resp. přílohu dílčí realizační smlouvy. Výstupy z prototypování lze poskytnout buď ve formátu offline souboru SW Figma (*.fig) či přístupu do online úložiště s jednotlivými prototypy (obrazovkami) projektu.

Poznámky

Při následné realizaci jednotlivých sprintů interní UX tým spolupracuje s řešitelem minitendru na případném upřesnění a změnách prototypů.
Pro účely pochopení UI kontextu služeb, obrazovek a dialogů mají účastníci rámcové dohody zpřístupněný s právy pro čtení celý Figma projekt označený ve stromové struktuře jako „TA ČR”.
Další podrobnosti upravuje Oddíl 5.5, “Pravidla UX a design systém”.

Vlastník produktu vypracuje návrh produktového backlogu viz tabulka níže. Vypracovaný návrh backlogu může být za účelem upřesnění odhadnuté pracnosti zajištěna Oddíl 4.2.4, “Konzultace k obsahu plnění” či projednání s dodavateli prostřednictvím Oddíl 4.2.5, “Účastnická konzultace k očekávanému řešení”.

Projektový manažer aktivně podporuje vlastníka produktu při vytvoření produktového backlogu. Pomáhá s definicí produktových cílů a sestavení produktového backlogu tak, aby byl maximalizován přínos následné realizace.

Tabulka 3. Základní struktura produktového backlogu
ID	Odhad pracnosti	Priorita	Riziko
01	h	Kritická	Vysoké
02	h	Vysoká	Vysoké
03	h	Střední	Nízké
04	h	Nízká	Střední

Produktový backlog dále obsahuje atributy:

Sprint/inkrement – scrumový tým vyznačí sprint, kdy bude položka dodána. Řazení funkcionalit do sprintů by mělo odpovídat prioritě a rizikům.
Hotovo - zaškrtávací políčko identifikující uzavření požadavku.
Vlastník požadavku - odpovídá za případné zpřesnění v průběhu sprintu a účastní se testování/akceptace. Zapojení vlastníka požadavku předchází sporným situacím zejména u rozvojových minitendrů, které implementují dodatečné úpravy vyvolané okolními službami.
Doplňující poznámky - případné otázky, které je třeba u dodávky funkcionalit vyřešit, případně podrobnosti k novým položkám.

Poznámky

Produktový backlog je součástí výzvy k podání návrhů řešení u minitendrů typu „B” a „C” viz Oddíl 4.1, “Typy minitendrů”.
Produktový backlog je živým artefaktem, pokud existuje produkt, existuje i jeho backlog.

Výsledný produktový backlog je po celou dobu trvání minitendru uložen v adresáři projektové knihovny jako živý dokument s pravidelnou aktualizací při události Oddíl 4.4.4, “Revize sprintu”.
Projektový manažer s vlastníkem produktu vypracují specifikaci zadání minitendru (viz Příloha A, Šablony a formuláře) s následujícími atributy:
- Vlastník produktu (B0) - člen projektového týmu s dostatečnou odborností a vztahem k řešenému tématu;
- Název (B1) - výstižně charakterizuje řešenou potřebu / téma k řešení (název minitendru by neměl být příliš dlouhý);
- Potřebnost (B2) - popisuje potřebnost realizace tématu ve vztahu k rámcovým cílům projektu a již uzavřeným minitendrům (patří sem také východiska, známé limity řešení, příklady a dopady);
- Nejistota (B3) - popisuje očekávané procesní, koncepční, technologické obtíže a nejasnosti, které je třeba analyzovat a na základě zjištění navrhnout, potvrdit nebo naopak vyvrátit správnost možného řešení;
- Cíle minitendru (B4) - popisuje cíle, které mají být realizací minitendru naplněny. Tyto cíle by měly být dostatečně specifické a srozumitelné;
- Povinné otázky (B5) - otázky, na které dodavatel minitendru odpoví, případně stanoví, jak naplní požadavky na provoz služby. Zadání může být ve výzvě rozděleno na otázky, na které dodavatel odpoví již ve svém návrhu a následně otázky, které budou zodpovězeny na konci řešení;
- Minimální výstupy (B6) - množina minimálních výstupů, které budou řešením minitendru dodány spolu s podklady scrumových událostí;
- Součinnost (B7) - očekávaná k úspěšnému řešení minitendru. Dodavatel může ve svém návrhu řešení požadavky na součinnost rozšířit;
- Zdroje (B8) - informace a doposud vypracované výstupy, které jsou sdíleny s dodavateli prostřednictvím Oddíl 3.2.1, “Projektové knihovny”. Dále je doplněn odkaz na rozcestník dokumentace SISTA.
- Rámcový harmonogram (B9) - jedná se o harmonogram realizace celého minitendru, tedy všech zamýšlených sprintů. Mezi jednotlivými sprinty je nutné dodržet alespoň týdenní odstup na realizaci scrumových událostí;
- Pravidla UI (B10) - popisuje základní rámec pravidel pro tvorbu mikroslužeb mající frontend;
- Cena řešení bez DPH (B11) - odhad maximální ceny řešení, který je po konzultaci k obsahu plnění dodavateli upřesněn. Rámcová dohoda dále umožňuje přičíst 10 % paušálních nákladů (viz odst. 9 písm. b) RD2) , pokud tak stanoví výzva. Celková nabídková cena v návrhu řešení nesmí po přičtení paušálních nákladů překročit předpokládanou hodnotu minitendru;
- Počet hodin ke konzultacím (B12) - odhadovaný rozsah hodin, které dodavatel poskytne projektovému týmu především k diskusi nad návrhy řešení;
- Požadavky na řešení v příloze (B13) - informace, zda výzva ve svých přílohách obsahuje další požadavky na řešení minitendru (ANO / NE);
- Přílohy s požadavky na řešení (B14) - bodový seznam příloh, např. struktura požadovaného výstupu, který má být dodán, produktový backlog , pokud byl při specifikaci zadání vytvořen.
Vypracovaný návrh specifikace zadání minitendru je podroben interní recenzi členy projektového týmu a to zejména z pohledu vazeb na okolní agendy/služby.

4.2.4. Konzultace k obsahu plnění

Projektový manažer může v souladu s čl. 5, odst. 2 RD2 rozeslat vypracovaný návrh tématu k recenzi všem dodavatelům za účelem potvrzení srozumitelnosti zadání, reálnosti odhadu doby řešení, finanční alokace a vytipování rozsahu požadavků kladených na MVP případně požadavků vhodných pro další rozvoj služby.
E-mailová zpráva obsahuje definici požadavků a návrh produktového backlogu ve formátu PDF spolu s odkazem na jednoduchý Google formulář (viz Příloha A, Šablony a formuláře) pro zaslání zpětné vazby.
Projektový manažer upozorní zástupce dodavatelů na povinnost zachovávat mlčenlivost a zároveň určí přiměřenou lhůtu pro odpověď.
Každý zástupce dodavatele je oprávněn se vyjádřit v termínu a způsobem určeným projektovým manažerem (čl. 5, odst. 2 RD2).
Projektový manažer s vlastníkem produktu došlé odpovědi vyhodnotí a společně určí způsob vypořádání spočívající například v upřesnění tématu nebo parametrů minitendru.

Projektový manažer vyhotoví dokument „Informace o proběhlé konzultaci k obsahu plnění” (viz Příloha A, Šablony a formuláře), který je následně uložen mezi podklady předané dodavatelům a připojen k výzvě.

Poznámky

Konzultace by měla přispět k nižšímu počtu dotazů při vyhlášení výzvy k podání návrhu řešení.
TA ČR k výstupům konzultace přihlíží při finalizaci výzvy.

4.2.5. Účastnická konzultace k očekávanému řešení

Projektový tým má dále možnost využít konzultací k očekávanému řešení s dodavateli (srov. s čl. 5, odst. 7 RD2) a to:
1. v průběhu přípravy výzvy k podání návrhu řešení,
2. před odesláním výzvy k podání návrhu řešení.
Konzultaci naplánuje projektový manažer tak, aby byla zachována lhůta 7 kalendářních dnů pro podání návrhu řešení ode dne jednání. Pozvánku na konzultaci obdrží dodavatelé min. 7 kalendářních dnů před dnem konáním prostřednictvím e-mailu, NEN nebo ISDS.
Pokud se zástupce dodavatele povinného jednání nezúčastní, není oprávněn podat návrh řešení.
Účastnickou konzultaci k očekávanému řešení organizuje projektový manažer s vlastníkem produktu a koordinátorem projektu, ostatní členové projektového týmu se aktivně zapojují do diskuse k očekávanému řešení.

4.3. Uzavírání dílčích smluv

4.3.1. Výzva k podání návrhu řešení do minitendru

Projektový manažer vypracuje dle typu minitendru koncept výzvy k podání návrhu řešení se všemi uvažovanými přílohami. Vypracované podklady výzvy jsou uloženy v adresáři „02. Výzva k podání a hodnocení návrhů řešení“ příslušného minitendru.
Právník vypracované podklady zkontroluje, zajistí interní schválení a následně vyzve dodavatele k podávání návrhů řešení tak, že jim prostřednictvím NEN zašle písemnou výzvu k podání návrhu řešení do minitendru.
Pro podání návrhu řešení se stanoví lhůta minimálně 7 kalendářních dnů. Další podrobnosti upravuje čl. 5 RD2.

Zástupce dodavatele podává návrh řešení v souladu s pokyny uvedenými ve výzvě k podání návrhu řešení, ve stanovené lhůtě a pouze elektronicky prostřednictvím NEN.

Důležité

Při přípravě návrhu řešení je nutné pracovat se zněním výzvy, neboť TA ČR může upřesnit význam pro přiřazení jednotlivých bodů u subkritérií a to s ohledem na charakter či cíle minitendru (čl. 5, odst. 9 RD2).

Pokud výzva obsahuje povinné otázky, je na ně dodavatel ve svém návrhu povinen reagovat, a to na každou otázku samostatně.
Dodavatel dále ve svém návrhu řešení označí další části, které považuje za obchodní tajemství, a jež nebudou zveřejněny v registru smluv. Obecně platí, že příloha návrhu řešení je obchodním tajemstvím a nebude zveřejněna (čl. 5, odst. 8 RD2).
V průběhu lhůty pro podávání návrhů řešení připraví projektový manažer ve spolupráci s koordinátorem projektu podklady pro jednání hodnotící komise: čestné prohlášení členů hodnotící komise (je-li relevantní), návrh protokolu z hodnocení návrhů řešení s přílohou obsahující bodové hodnocení návrhů řešení.

4.3.2. Hodnocení návrhů řešení

Po ukončení lhůty pro podávání návrhů řešení dodavateli zajistí právník odšifrování, otevření a stažení došlých návrhů v systému NEN. Návrhy jsou zpřístupněny členům hodnotící komise prostřednictvím samostatného adresáře mimo strukturu projektové knihovny.
U postupu bez obnovení soutěže zajistí právník stažení došlého návrhu v systému NEN s následným zpřístupněním dle předchozí věty.
Pokud dojde k ukončení plnění v minitendru, který nedosáhl svého cíle, a TA ČR se rozhodne téma minitendru vyhlásit znovu, aniž podstatně změní zadávací podmínky, nebude hodnocen ani akceptován nový návrh řešení dodavatele, který měl v původním minitendru plnění dosáhnout.
Vlastník produktu řešení si před jednáním hodnotící komise připraví, je-li to s přihlédnutím na charakter minitendru účelné, vodítka, a to pro každý došlý návrh řešení spolu s návrhem bodového hodnocení kritérií a1) až a3).
Hodnotící komise provede vyhodnocení podaných návrhů řešení v souladu s interními pravidly pro poptávková řízení a zadávání veřejných zakázek [SME-19].
Hodnotí se všechny včas podané návrhy řešení, které splňují požadavky stanovené rámcovou dohodou a výzvy k podání návrhů řešení, a to dle hodnotících kritérií uvedených v každé výzvě.
Hodnotící komise seřadí návrhy řešení podle provedeného hodnocení od nejvhodnějšího po nejméně vhodný.
Pokud předloží návrh řešení pouze jeden dodavatel, může být zadavatelem vybrán bez provedení hodnocení.
Projektový manažer na základě dílčích podkladů hodnocení dopracuje protokol z hodnocení návrhů řešení spolu s přílohou obsahující bodové hodnocení.
Členové hodnotící komise opatří oba dokumenty elektronickými podpisy. Výsledné podklady hodnocení předá projektový manažer zpět právníkovi.

4.3.3. Uzavření smlouvy

Právník zajistí vypracování oznámení o výběru návrhu řešení účastníka rámcové dohody v minitendru (dále jen „oznámení o výběru”).
Po podepsání oznámení o výběru ředitelem Kanceláře TA ČR provede právník v systému NEN výběr dodavatele a zároveň jeho prostřednictvím odešle oznámení o výběru všem dodavatelům, kteří podali návrh řešení do daného minitendru.
Před uzavřením dílčí smlouvy je zadavatel oprávněn s vybraným dodavatelem jednat o upřesnění plnění. V případě odmítnutí uzavření smlouvy s vybraným dodavatelem může zadavatel uzavřít smlouvu s dalším v pořadí (srov s. čl. 5, odst. 14 RD2).
Ekonomické oddělení zajistí zveřejnění oznámení o výběru a dílčí smlouvy v registru smluv.
Po zveřejnění v registru smluv právník zaeviduje výsledek zadávacího postupu do systému NEN.

Poznámky

Pro účely zahájení řešení minitendru je uzavřením dílčí smlouvy okamžik zveřejnění dílčí smlouvy v registru smluv.
Po vložení dokumentů do registru smluv je možné přistoupit k formálnímu zahájení řešení minitendru.

4.4. Realizace a monitorování řešení

Přírůstky projektu budou realizovány v souladu s definovanými scrumovými událostmi, které jsou časově ohraničené - každá má určenou svou maximální délku trvání, cíle a účastníky viz následující tabulka. Sprint je sám o sobě jen souhrnem všech ostatních scrumových událostí.

Tabulka 4. Scrumové události
	Plánování sprintu	Denní schůzka	Revize sprintu	Retrospektiva sprintu
Cíl	Určení, proč, co a jak bude dodáno	Kontrola pokroku směrem k cíli sprintu	Předání a akceptace přírůstku/produktu	Zpětná vazba ve prospěch budoucích sprintů
Trvání	max. 8 hodin (pro 4ww sprint)	max. 15 minut	max. 4 hodiny	max. 3 hodiny
Účastníci	Scrumový tým	Vývojáři	Scrumový tým Zainteresované strany	Scrumový tým
Pomáhá organizovat	Scrum Master	Scrum Master	Scrum Master	Scrum Master

4.4.1. Zahájení řešení minitendru

Projektový manažer naplánuje kick off schůzku za účasti vlastníka produktu na straně TA ČR a zástupců dodavatele. Účelem formálního zahájení je představení budoucího scrumového týmu, seznámení dodavatele se základními pravidly organizace práce, organizační záležitosti, dodatečné vysvětlení návrhu řešení či plánování průběhu „nultého sprintu“.

4.4.2. Plánování sprintu

Vlastník produktu se zástupcem dodavatele zajistí aktivity související s naplánováním a výběrem položek do každého sprintu řešeného minitendru.
Vzhledem ke skutečnosti, že sprintový backlog vychází z produktového backlogu, resp. je tvořen cílem sprintu, vybranými položkami pro vytvoření přírůstku a rozplánováním jejich dodání, neurčujeme dodavatelům závaznou strukturu. Akceptujeme přístupy vlastníků produktů do aplikací pro řízení projektů na straně dodavatele minitendru.
Vlastník produktu zajišťuje vysvětlení priorit produktového backlogu dodavateli a jejich vazby na naplnění produktových cílů, dále má právo spoluurčovat priority, které jsou přidělovány podle tří hlavních zásad:
- Nejhodnotnější věci mezi prvními - nejpřínosnějších funkcionality produktu označené v backlogu jako minimální životaschopný produkt mají z pohledu implementace produktového backlogu nejvyšší prioritu.
- Nejrizikovější věci mezi prvními - má-li téma skončit nezdarem (např. pro technologickou obtížnost), je žádoucí tuto skutečnost zjistit co nejdříve, aby bylo zmařené úsilí bylo co možná nejmenší. Je tedy smysluplné odbavovat rizikové položky mezi prvními.
- Nejrychleji dodatelné funkčnosti mezi prvními - vždy dáváme přednost takovým funkčnostem, které lze rychle dodat a mohou začít sloužit uživateli („jsou vidět”).
Při plánování sprintu je respektován dílčí harmonogram minitendru a délka sprintu nepřekročí doporučené mantinely - trvání nad 4ww nebude akceptováno.
Zástupce dodavatele může za účelem efektivního plánování sprintu, konzultací týkajících se tématu produktu a použité technologie přizvat další odborné kapacity.
Plánování sprintu odpovídá na následující otázky:
- Proč je tento sprint cenný? Jaký má celý sprint účel a cíl?
  - Vlastník produktu navrhuje, jak by mohla být prostřednictvím aktuálně plánovaného sprintu zvýšena hodnota a užitečnost produktu.
  - Celý scrumový tým poté spolupracuje při definici cílů sprintu, který vyjadřuje, proč je konkrétní sprint pro zainteresované strany významný.
  - Cíle sprintu musí být určeny před koncem plánování sprintu.
  - Tým jako celek přijímá závazek dosáhnout cílů každého sprintu.
- Co všechno může být tento sprint dodáno?
  - Vývojáři diskusí s vlastníkem produktu vyberou položky produktového backlogu, které budou zahrnuty do dodávky plánovaného sprintu.
  - Scrumový tým může během tohoto procesu jednotlivé položky upřesnit, aby bylo jasné, co se má při řešení sprintu dodat.
  - Počet položek produktového backlogu zařazených do sprintu závisí výhradně na rozhodnutí vývojářů.
  - Jen vývojáři mohou odhadnout, co jsou schopni během následujícího sprintu dokončit.
- Jak bude zvolená práce provedena?
  - Existují-li cíle sprintu a byly vybrány položky produktového backlogu pro nadcházející sprint, vývojáři rozhodnou, jakým způsobem definovaný přírůstek produktu vytvoří;
  - Pro každou vybranou položku produktového backlogu naplánují vývojáři menší pracovní balíčky potřebné pro vytvoření přírůstku produktu. Také tato aktivita je plně v kompetenci vývojářů, nikdo jiný neřekne, jak přeměnit položky z produktového backlogu na vytvoření přírůstku přidané hodnoty.
Dodavatel zajistí plánování zdrojů tak, aby se testeři na straně dodavatele zapojili do práce scrumového týmu již v okamžiku programování aplikace, vytvářeli uživatelské testovací scénáře a kompletovali plán testování. Způsob integrace požadavků na testování do sprintového backlogu je na zkušenostech dodavatele.
Na závěr plánování sprintu se scrumový tým ujistí, že každý člen týmu chápe, proč na daném přírůstku produktu pracuje a je jasné, co se má při řešení sprintu dodat.

4.4.3. Sprint

Organizace denní krátké schůzky (Daily Scrum) vývojářů na straně dodavatele není předmětem těchto pravidel řízení, nicméně komunikace dodavatele s vlastníkem produktu o postupu ve vztahu k cíli sprintu a plánování práce je nevyhnutelná. Za tímto účelem probíhají podle potřeby sprintu Oddíl 2.3.3, “Jednání scrumového týmu”.
Vlastník produktu průběžně informuje o postupu viz Oddíl 2.3.2, “Jednání projektového týmu”.
Během sprintu:
- Neprovádí se žádné změny, které by ohrozily cíle sprintu;
- Nesnižuje se kvalita;
- Produktový backlog je podle potřeby aktualizován (například náměty na další sprint, „…na co jsme při plánování sprintu zapomněli” apod.);
- Může být s vlastníkem produktu znovu projednán a na základě nově získaných znalostí upřesněn rozsah sprintu.
Sprintový backlog je na straně dodavatele dostupný a udržován aktuálním tak, aby celková práce zbývající k dosažení cíle sprintu byla kdykoliv vyčíslitelná.
Projektový manažer skrze souhrnný harmonogram u každého minitendru průběžně kontroluje, jak velkou část práce scrumový tým už „spálil“ a kolik zbývá do konce sprintu viz Oddíl 6.1, “Řízení času” a Oddíl 6.3, “Komunikace a výkazy projektu”.

Každý sprint zaměřený na dodávku služby bez výjimky končí dodáním fungujícího software - otestovaného dle scénářů definovaných v plánu testování, dokumentovaného a připraveného k použití.

Důležité

Nový sprint vždy začíná po ukončení scrumových událostí předchozího sprintu.
Do revize a retrospektivy je vždy započten čas nutný na převzetí přírůstku.

Dodavatel může po předchozí dohodě s vlastníkem produktu nasazovat během jednoho sprintu více přírůstků. Každý přírůstek je doplňkem ke všem předcházejícím přírůstkům a je vždy na straně dodavatele důkladně testován, aby se zajistilo, že všechny přírůstky spolu dohromady fungují. Dále platí požadavek TA ČR na zachování přiměřené lhůty pro účely testování funkcionalit přírůstku.

4.4.4. Revize sprintu

Podstatou revize sprintu je předání/převzetí hotového přírůstku (výsledku sprintu).
Podklady pro revizi sprintu připravuje zástupce dodavatele ve spolupráci s vlastníkem produktu. Šablona prezentace je připojena mezi Příloha A, Šablony a formuláře.
Scrumový tým prezentuje výsledky své práce klíčovým zainteresovaným stranám projektu (sponzor projektu, ředitel sekce interní podpory a ředitel odboru ICT) a vlastník produktu rozhoduje, zda je daná položka akceptována.
Diskutuje se o pokroku směrem k naplnění produktového cíle. Z dosavadního řešení projektu SISTA vyplynula optimální časová dotace na revizi v rozsahu cca 1 hodiny. Zde se očekává flexibilní přizpůsobení časové dotace povaze a rozsahu sprintu.
Vlastník produktu ve spolupráci se zástupcem dodavatele informují, které položky produktového backlogu byly dokončeny a které nikoliv. Scrum nerozlišuje akceptaci s výhradou či podmíněnou akceptaci na základě nějakého dílčího dokončení. Funkčnost je buď hotová, nebo ne.
Scrumový tým zhodnotí čerpání alokovaného času a celá skupina společně navrhne, co bude řešeno dále, čímž poskytne důležitý vstup pro Oddíl 4.4.2, “Plánování sprintu”.
Výsledkem revize sprintu jsou požadavky na revizi produktového backlogu, tyto požadavky mohou také definovat pravděpodobné položky na zařazení do dalšího sprintu. Produktový backlog může být celkově přizpůsoben novým příležitostem.
Revize sprintu má být neformální schůzkou za účelem předvedení přírůstku s cílem získat zpětnou vazbu a podpořit spolupráci scrumového týmu.

4.4.5. Retrospektiva sprintu

Retrospektiva sprintu se provádí vždy po revizi sprintu a před plánováním nového sprintu. Jejím účelem je naplánovat kroky, pomocí kterých dojde během příštího sprintu k zvýšení efektivnosti a kvality.
Podklady pro retrospektivu sprintu připravuje vlastník produktu ve spolupráci se zástupcem dodavatele. Šablona matice retrospektivy sprintu (viz obrázek níže) je připojena mezi Příloha A, Šablony a formuláře.
Tato scrumová událost již probíhá v užším kruhu scrumového týmu, a to před plánováním dalšího sprintu. Z dosavadního řešení projektu SISTA vyplynula optimální časová dotace na retrospektivu v rozsahu cca 30 minut.
Scrumový tým při retrospektivě sprintu:
- Přezkoumá sprint co se týče lidí, vztahů, procesů, použitých nástrojů a definice „kdy je hotovo”;
- Identifikuje, co se během sprintu (ne)povedlo, s jakými problémy se scrumový tým setkal a jak tyto problémy (ne)byly vyřešeny;
- Identifikuje nejužitečnější změny k zvýšení efektivnosti.
Obrázek 8. Matice retrospektivy sprintu
Vypracovaný výstup bude zohledněn při dalším Oddíl 4.4.2, “Plánování sprintu”.
Dílčí výstupy retrospektiv minitendru budou využity při Oddíl 6.4, “Shromáždění poznatků” za účelem maximálního sdílení získaných zkušeností.

4.4.6. Závěrečná prezentace pro ostatní účastníky RD

Závěrečná prezentace pro ostatní účastníky rámcové dohody probíhá až po revizi/retrospektivě posledního implementačního sprintu a potvrzení rozsahu/kvality dodaného plnění (tzn. uzavření backlogu, naplnění plánu testování, nasazení služby na produkční prostředí, apod.).
Dodavatel připraví prezentaci spolu s případnou ukázkou služby (prezentace je vždy připojena formou odkazu rozeslané pozvánky).
Vlastník produktu po dohodě se zástupcem dodavatele požádají koordinátora projektu o naplánování závěrečné prezentace.
Účastníci na straně TA ČR jsou vybráni dle zaměření minitendru, zástupci dodavatelů jsou zváni vždy.
Závěrečná prezentace se již nezapočítává do doby řešení minitendru.

4.4.7. Zrušení sprintu

Zrušení sprintu je v kompetenci pouze vlastníka produktu po předchozí diskuzi s projektovým manažerem (vazba na podmínky dílčí smlouvy řešení minitendru).
Sprint může být zrušen v případě, kdy cíl sprintu již není aktuální. Toto může nastat např. při změně směřování organizace nebo změně technologických podmínek. Obecně by sprint měl být zrušen v případech, kdy za daných okolností již nedává smysl. Díky tomu, že sprint je krátký (maximálně 4 ww), jeho zrušení dává smysl jen výjimečně nebo v případě výpovědi dílčí smlouvy.
Při zrušení sprintu vlastník produktu zreviduje všechny hotové položky produktového backlogu a jsou-li vydatelné, pak je akceptuje. Veškeré nehotové položky znovu projdou procesem odhadování náročnosti a vrátí se zpět do produktového backlogu.
Po zrušení sprintu následuje nové Oddíl 4.4.2, “Plánování sprintu” za předpokladu, že se nejedná o ukončení řešení celého minitendru.

4.5. Akceptace a uzavření minitendru

Projektový manažer organizuje dle harmonogramu dílčí realizační smlouvy průběžné přebírání a akceptaci výstupů minitendru.
Za účelem ověření souladu výstupů minitendru a dalších požadavků kladených na všechny služby SISTA byla vytvořena metodika pro provedení tzv. sanity checku. Šablona ve formě živého dokumentu je dostupná na rozcestníku dokumentace projektu SISTA. Realizaci zadává projektový manažer po dohodě s vlastníkem produktu.
Akceptační testování se provádí výhradně proti STAGING prostředí a dle předem vypracovaných testovacích scénářů popsaných v plánu testování.
Po realizovaném sanity checku minitendru a konstatování scrumového týmu, že je splněna definice „kdy je hotovo“, vyzve projektový manažer zástupce dodavatele k akceptačnímu řízení. Výstupem akceptačního řízení je formálně schválený akceptační protokol a checklist převzetí služby OPS týmem (viz Příloha A, Šablony a formuláře).
Vlastník produktu při uzavírání minitendru zkontroluje položky checklistu, vypořádání nedostatků zjištěných při realizaci sanity checku, rozsah poskytnutých konzultací a zároveň zajistí zadání případných požadavků směřujících k odebrání přístupů poskytnutých dodavateli pro účely řešení.
Akceptační řízení zajišťují následující projektové role:
- Osoba zmocněná k úkonům a vedení projektu na straně dodavatele - provádí výstupní kontrolu kvality a předání všech finálních výstupů konkrétního minitendru k akceptaci;
- Vlastník produktu - ověřuje rozsah a kvalitu všech předložených výstupů ve vztahu k naplnění cílů minitendru;
- Projektový manažer – kontroluje kvalitativní atributy poskytnutého plnění a potvrzuje ukončení akceptačního řízení;
- Ředitel odboru ICT, ředitel sekce interní podpory a ředitel Kanceláře TA ČR - formálně uzavírají akceptaci.
Projektový manažer vypracuje a zašle návrh akceptačního protokolu (spolu s uzavřeným výkazem poskytnutých konzultací a případnými dalšími podklady dle charakteru minitendru) zástupci dodavatele.
Jsou-li předmětem akceptace zdrojové kódy, dokumentace vytvořené služby, pak vlastník produktu odpovídá za závěrečnou kontrolu kompletnosti repozitáře, dostupnosti záznamů o automatickém testování a dostupnosti dokumentace dle pravidel uvedených v kapitole Oddíl 5.6, “Pravidla vedení dokumentace”. Jako vodítko použije checklist převzetí služby OPS týmem.
Zástupce dodavatele zašle e-mailem elektronicky podepsaný akceptační protokol spolu s fakturou za poskytnuté plnění projektovému manažerovi. Fakturační milníky a další podmínky upravuje dílčí realizační smlouva minitendru.
Projektový manažer zajistí elektronické podepsání akceptačního protokolu v pořadí dle bodu 3.
Finální verze výstupů minitendrů (dokumenty a akceptační protokoly) uloží koordinátor projektu do adresáře 04. Akceptační řízení a fakturace příslušného minitendru a do spisové služby.
Projektový manažer odešle akceptační protokol společně s fakturou na adresu: fakturace@tacr.cz.

5. Architektura, vývoj a dokumentace

5.1. Obecně

TA ČR udržuje soubor pravidel projektu SISTA, který je dostupný všem dodavatelům prostřednictvím rozcestníku dokumentace SISTA. Dodavatel, stejně jako jednotliví dodavatelé a poddodavatelé mezi sebou, je povinen v průběhu řešení tato pravidla respektovat (čl. 10 RD2).
Dodavatelé se prostřednictvím DevOps aktivně zapojují do aktualizace pravidel, která jsou rozpracována v samostatně řízených dokumentech: Pravidla architektury, Pravidla platformy, Pravidla vývoje, Pravidla UX a design systém a Pravidla vedení dokumentace.
SISTA je z pohledu regulatorních požadavků významným informačním systémem [ZISVS] a [VYVIS] - těmto požadavkům se budou výše uvedená pravidla přizpůsobovat.
Architektura SISTA vychází z principů mikroservisní SOA. Jednotlivé kontejnery běží na bázi linux s tím, že jejich orchestraci zajišťuje platforma Kubernetes provozovaná v Google Cloud Platform.
Vývoj, sestavení a nasazení probíhá v GitLab. Nástroj je dostupný skrze VPN TA ČR nebo s využitím Google IAP. Dodavatelé přistupují pouze pod „tacr-external.cz” účty.
TA ČR prozatím zcela nevyužívá potenciál mikroservisní architektury (např. výhod „fault isolation"). Prvotní implementace služby je zaměřena na dodávku MVP s tím, že po vyhodnocení poznatků a provozních charakteristik se mohou služby rozvíjet ve směru větší nezávislosti v souladu s principy mikroservisní architektury.
Vývoj softwarového řešení SISTA využívá nástroje, postupy a kulturu DevOps, přičemž Ops část týmu se skládá ze zaměstnanců/dodavatelů TA ČR, kteří nejsou nijak zapojeni do vývoje samotného řešení. Ops tým je v procesech a postupech DevOps označován jako „IDP tým” (srov. s Oddíl 2.2.5, “IDP tým”).
Dev týmy přistupují k repozitářům pouze z poskytnutých účtů „tacr-external.cz”, na kterých je pro přihlášení vynucována dvoufaktorová autentizace. Správu těchto účtů provádí Ops tým.
Katalog služeb - shromažďuje na jedno místo popisy služeb, rozhraní a dokumentace všech služeb. Dodavatelům, kteří mají ve svém repozitáři <nazev_sluzby> správný konfigurační soubor pro Backstage, se služba/api/dokumentace automaticky projeví i do katalogu služeb. Na projektu SISTA je za tímto účelem nasazena otevřená platforma Backstage.

5.2. Pravidla architektury

SISTA je budována a provozována jako cloud native systém. Obecná pravidla pro vývoj takového systému shrnuje manifest 12factor.
Architektura SISTA cílí na vytvoření takových služeb, které jsou:
1. snadno udržovatelné a testovatelné,
2. navzájem v maximální míře nezávislé,
3. nezávisle nasaditelné,
4. organizované podle domén byznysu,
5. vždy v péči jednoho týmu.
Architektura SISTA dále využívá koncept publish/subscribe, případně a/synchronní volání přes dapr.io service invocation.
Platforma - technické řešení zajišťované Ops týmem, který se stará o repozitáře, CI/CD pipelines, deployment, správu prostředí, infrastrukturu, IAM management, zabezpečení komunikačních kanálů mezi službami, monitoring, logging a další.
Platforma SISTA:
1. její infrastruktura je definovaná v kódu (IaC),
2. funguje „as a service“ pro vývojové týmy dodavatelů,
3. její údržbu, vývoj a rozvoj zajišťuje Ops tým,
4. jejíž zdrojový kód připravuje/upravuje výhradně IDP tým s tím, že dodavatelé mají přístup do repozitářů platformy a mohou přispívat nápady,
5. zajišťuje, aby vytvoření nové služby nebylo výrazně složitější než začlenění nového kódu do existující služby,
6. poskytuje katalog služeb.
IDP tým je možné kontaktovat prostřednictvím ops@tacr.cz. E-mailová zpráva automaticky založí tiket v interním servicedesku.
Přístup ke službám může podléhat řízení přístupů viz Oddíl 5.4, “Pravidla vývoje”.
Komunikace mezi službami probíhá synchronně i asynchronně (MQ - Google Pub/Sub s pomocí dapr.io). Preferovanou volbou je právě asynchronní komunikace a to z důvodu nezávislosti služeb. Dále obecně platí, že služby SISTA mezi sebou komunikují s využitím platného API klíče při respektování následujících základních pravidel:
1. pokud služba potřebuje v danou chvíli (př. uživatelský požadavek, údaje s nízkou latencí) data jiné služby, volá ji synchronně. Vždy musí počítat s možností, že jiná služba neběží, a musí použít vhodný přístup k opakování dotazu, prodlužování intervalu, ošetření timeoutu,
2. všechny služby by měly přednostně využívat primární zdroje datových entit a nevytvářet jejich kopie, pokud to není pro fungování služby nutné,
3. pro informování o provedených změnách stavu (př. aktualizace údajů, přesun workflow do kroku XY) služby mají využít MQ – fronty zpráv,
4. služba může obdržet totožnou zprávu vícekrát („at least once delivery“),
5. pokud jedna ze služeb neběží, druhou to přímo neovlivní. Zprávy se drží v messaging službě nezávisle na samotných službách,
6. asynchronní sémantika v komunikaci vede k eventuální konzistenci,
7. asynchronní komunikace je zajištěna messaging službou (dapr.io + Google Pub/Sub). Zprávy jsou seřazené, tedy je zaručeno jejich správné pořadí,
8. čtení/zobrazování dat, která pocházejí či závisí na cizí službě (např. SMS brána, IS datových schránek apod.), by nikdy nemělo být synchronního charakteru.
Git repozitáře jsou ve správě TA ČR. Repozitáře jsou vytvářeny na základě požadavku garanta tématu či prostřednictvím formuláře. Po založení repozitáře IDP tým nahraje potřebné proměnné a soubory.

5.3. Pravidla platformy

TA ČR pro potřeby projektu SISTA udržuje v Google Cloud Platform následující běhová prostředí: TESTING, STAGING a PRODUCTION.
Využití kontejnerizace umožňuje, aby se jednotlivé komponenty spouštěné v různých prostředích lišily pouze konfigurací a dostupnými zdroji – takové uspořádání je považováno za optimální:
- typ PRODUKČNÍ (PRODUCTION) - ostré běhové prostředí pro koncové uživatele SISTA.
- typ NEPRODUKČNÍ - instancí těchto prostředí může být mnoho, např.:
  - subtyp PRE-PRODUKČNÍ nebo INTEGRAČNÍ (STAGING) - prostředí určené pro integrační testy mezi službami a je žádoucí, aby:
    
    obsahovalo skutečná data z produkčního systému, podle potřeby anonymizovaná nebo pseudonymizovaná, a to pravidelně aktualizovaná.
    
    obsahovalo nejnovější stabilní verze služeb a všechny potřebné šablony.
  - subtyp TESTOVACÍ (TESTING) - prostředí určené pro testy nad úrovní jednotkových testů:
    
    může obsahovat pouze testovací data.
Ops tým je zodpovědný za přípravu a údržbu těchto tří typů prostředí. Dev týmy jsou spoluzodpovědné za přípravu a údržbu dat a aplikací ve všech typech prostředí.
Podle specifických potřeb služby může být přidána další instance neprodukčního prostředí (např. IMPORT pro výpočetně náročnou přípravu dat, která se následně přesunou do PRODUCTION prostředí).
DevOps týmy jsou společně zodpovědné za určení podmínek, při jejichž splnění je možné nasazení do každého prostředí. Oba týmy jsou také zodpovědné za kontrolu, že dané podmínky jsou splněny.
DevOps týmy v pravidelných intervalech společně hodnotí naplňování očekávání kladených na platformu SISTA (srov. s Oddíl 2.3.4, “Jednání DevOps SISTA”). Vyhodnocení zahrnuje přezkoumání výkonnosti, používaných nástrojů, incidentů a problémů identifikovaných v průběhu vývoje služeb SISTA. Přezkoumání vede ke konkrétním opatřením na straně DevOps týmů.

5.4. Pravidla vývoje

Vývoj a dodávání služeb probíhá dle požadavků Oddíl 4.4, “Realizace a monitorování řešení”. Součástí návrhu řešení služby je také odhad sizingu a možností škálování vyvíjené služby. Další podrobnosti stanoví výzva konkrétního minitendru.
Služby jsou vyvíjeny v souladu s nejlepší praxí, procesy TA ČR, závěry přijatými DevOps (srov. s Oddíl 2.3.4, “Jednání DevOps SISTA”), ohledem na responzivitu a pravidly přístupnosti.
Zdrojový kód a dokumentace jsou verzovány do TA ČR git repozitáře. Pro kontinuální nasazování se využívá nástroj Argo CD a dále je k dispozici subgroup environments na Gitlab.
Výstupem Dev týmu je Dockerfile, který funguje jako předpis pro vytvoření kontejneru a deployment soubor s konfigurací aplikace (předpis je daný Ops týmem, jedná se např. připojení do databáze a environment variables). Součástí kontejneru musí být kompletní běhové prostředí včetně sestavení výsledné služby. Při spuštění kontejneru musí dojít už jen k samotnému spuštění služby. Dev tým je zodpovědný za správné fungování služby v Dockeru.
Dev týmy jsou při vývoji služby povinni povyšovat na nejnovější verze ostatních služeb za předpokladu, že jsou tyto služby a jejich funkcionality kritické pro funkčnost vyvíjené služby. Cílem je zamezit zpětné nekompatibilitě starší verze služby A s vyvíjenou službou B.
Po akceptaci dodávky jsou další úpravy vyvolané změnami okolních služeb implementovány již jako rozvojové požadavky.
Dev tým je zodpovědný za nasazování služby na development cluster vytvoření pro účely implementace služby SISTA.
Ops tým je zodpovědný za nasazování služeb na STAGING a PRODUCTION prostředí. DevOps tým jsou společně zodpovědné za návrat k předchozí verzi služby, pokud je to z jakýchkoli důvodů nutné.
Testování probíhá po celou dobu vývoje. Vhodná podoba závisí na povaze služby, zvolené technologii a konkrétních požadavcích Ops týmu. Dodavatel ve spolupráci s garantem služby připravuje plán uživatelského testování obsahující jednotlivé testovací scénáře. Šablona plánu testování je připojena mezi Příloha A, Šablony a formuláře.
Dev tým je zodpovědný za dokumentaci způsobu sestavování, nasazování, instalace podpůrných komponent a služeb, jsou-li. DevOps týmy jsou společně zodpovědné za publikování Release notes každé nasazené verze. Release notes mají být součástí gitu pro pozdější referenci. Změny, opravy chyb a nové funkce musí být v release notes navázané na evidované požadavky.
Podporované jazyky pro aplikace jsou JavaScript, Python, Java, C#, Go, Kotlin, včetně open-source dostupných frameworků s kvalitní dokumentací. Rozšíření seznamu podporovaných jazyků podléhá diskusi a schválení DevOps SISTA.

5.5. Pravidla UX a design systém

TA ČR vytvořila design systém (DISTA) odvozený od Material Design.
Design systém využívá soubor upravených komponent v jazyce React, který reflektuje požadavky a specifika SISTA.
Design systém je rozdělen na textovou část (která je součástí pravidel projektu SISTA) a knihovnu sdílených komponent v SW nástroji Storybook.
Pro řízení životního cyklu jednotlivých UI elementů se využívá nástroj Chromatic, do kterého mají přístup všichni dodavatelé zapojení do projektu SISTA.
Tvorba UI se řídí následujícími principy:
1. funkčnost a srozumitelnost,
2. serióznost a transparentnost,
3. jednoduchost a čistota,
4. předvídatelnost a jednotnost.
Dev tým může po předchozí domluvě využít i další existující komponenty přímo z MUI. Použití těchto komponent musí být následně uvedeno v dokumentaci vytvořené služby.
Při přípravě specifikace zadání připravuje interní UX tým pohledy na uvažované fungování služby a to s využitím prototypovacích nástrojů (Figma nebo Penpot) a MUI komponent.
Interní UX tým zajišťuje při přípravě zadání, implementaci a při akceptačním řízení uživatelské testování navrženého UI dodávané služby.
Interní UX tým uvede do specifikace zadání služby očekávaný soupis UI komponent s popisem jejich fungování.
Dev tým s garantem tématu po celou dobu vývoje spolupracují na optimalizaci UX/UI služby s cílem zajistit principy uvedené v bodě 4.
Dev tým při tvorbě uživatelského rozhraní služby respektuje požadavky DISTA a využívá UI komponenty.
Dev tým od plánování prvního implementačního sprintu řeší srozumitelnost a případnou úplnost zadání z pohledu navržených UI komponent.
Dev tým proaktivně řeší (např. požaduje doplnění a konzultuje) návrhy prototypů či požadavků zadání.

5.6. Pravidla vedení dokumentace

Dokumentace projektu SISTA je rozdělena na:
1. sdílenou, která je dostupná z rozcestníku dokumentace při zachování maximální otevřenosti, tj. pouze citlivé údaje (přístupové kódy, bezpečnostní prvky) jsou pro neoprávněné uživatele skryté.
2. specifickou, která je vytvořena Dev týmem dle požadavků uvedených v pravidlech vedení dokumentace.
Sdílená dokumentace obsahuje strukturované informace o:
1. základní architektuře – popis architektonického návrhu služby, základních komponent, komponent a knihoven 3. stran, jsou-li použité, komunikace s dalšími službami,
2. postupech nasazení – jakým způsobem se služba nasazuje v kontejnerovém prostředí,
3. spuštění a zastavení – pořadí, v jakém se na obecné úrovni služba v kontejnerovém prostředí spouští/zastavuje (např. kubectl start XYZ …),
4. ověření běžných scénářů a základní troubleshooting
5. obnově ze zálohy a zálohování – pokud se postup odlišuje od specifického obecného rámce,
6. uživatelské dokumentaci – případně různých typech uživatelské dokumentace (např. příručka pro hodnotitele se může lišit od příručky pro řešitele projektu),
7. knowledge base – údržba, evidence incidentů,
8. FAQ – časté dotazy na Ops tým.
Na udržování sdílené dokumentace spolupracuje DevOps a celý projektový tým SISTA.
Specifická dokumentace služby SISTA obsahuje:
1. provozní informace – např. umístění zdrojů, secrets atd.,
2. specifickou konfiguraci – např. konfigurační parametry pro sdílenou databázi, proměnné operačního systému, nastavení locale apod.,
3. vývojové informace – např. význam vývojových větví v repozitáři, odlišnosti v CI/CD, sémantika logů apod., dalšími implementačními detaily (např. struktura zdroj. kódů, jmenné konvence, datový model, význam zpráv ve frontě apod.),
4. architektonická rozhodnutí – odůvodnění volby konkrétní implementace (např. „zvolili jsme vlastní implementaci SAMP, protože…”, „nepoužili jsme transakce v PgSQL, protože…”),
5. popisem veřejného API – preferovaný je formát OpenAPI (dříve Swagger) nebo AsyncAPI.
Dev tým vypracuje při řešení minitendru soubor specifické dokumentace služby, přičemž:
1. HOWTO-DEVS-OPS existuje vždy ve formátu AsciiDoc. Kontextové diagramy jsou vkládány „as a code“ pro následné vygenerování prostřednictvím PlantUML nebo ve formě Archimate modelů (typicky application structure nebo procesní modely),
2. každá služba obsahuje soubor README.md s popisem základního chování a fungování služby. Tato základní „karta služby“ se vkládá formou odkazu do specifikace zadání minitendrů,
3. šablony pro jednotlivé části dokumentace jsou uloženy v templates git repozitáře.
Dev tým ukládá HOWTO-DEVS-OPS dokumentaci do repozitáře vyvíjené služby a následně prováže jednotlivé části dokumentace s katalogem služeb. Šablona konfigurace pro katalog služeb je uložena v backstage-configuration repozitáře service-template udržovaného IDP týmem.
Veškerá dokumentace (s výjimkou např. příkazů, konfiguračních parametrů atd.) je vedena v českém jazyce viz Oddíl 3.1, “Formální požadavky”.

6. Konvenční procesy

6.1. Řízení času

Souhrnný harmonogram:
1. Specifikace zadání minitendru obsahuje požadavky na rámcový harmonogram (sekce B9) ve struktuře sprintů, milníků, scrumových událostí a aktivit spojených s formálním uzavřením řešení, které se již nezapočítávají do doby řešení. Po uzavření dílčí smlouvy je harmonogram řešení minitendru přenesen do souhrnného harmonogramu.
2. Projektový manažer udržuje souhrnný harmonogram v SW Gantter. Z projektové WBS se automaticky generují přednastavené Tableau reports interpretující základní charakteristiky projektu (čerpání rozpočtu, task burndown, plnění milníků harmonogramu,…).
3. Úkoly jsou vždy plánovány s pevnou dobou trvání tak, aby byla dodržena časová souvztažnost uzavřené dílčí smlouvy s řešením minitendru a zároveň bylo možné provádět časové simulace baseline.
4. Fakturační milníky mají přiděleny zdroje typu „materiál” s celkovou částkou plnění za sprint/etapu. Částky jsou uváděny vždy bez DPH.
5. Sprint může být scrumovým týmem podrobněji rozpracován do samostatného harmonogramu při dodržení nadřazených milníků. Pro tento účel je možné používat freeware GanttProject distribuovaný pod licencí GPL.
6. Vlastník produktu informuje o aktuálním stavu konkrétního sprintu na pravidelném Oddíl 2.3.2, “Jednání projektového týmu”. Informace o celkovém časovém průběhu projektu jsou předkládány na Oddíl 2.3.1, “Jednání řídícího výboru”.
7. Dílčí harmonogramy minitendrů mají v souhrnném harmonogramu pevnou strukturu, kterou je třeba v SW Gantter dodržet, a to pro účely pozdějšího porovnání délky trvání vybraných částí přípravy a řešení minitendrů.

Task Burndown report:
1. Projektový manažer monitoruje odchylky od souhrnného harmonogramu a přijímá odpovídající opatření.
2. Zevrubná kontrola harmonogramu probíhá nejpozději na sklonku pracovního týdne, kdy je proveden odečet úkolů za účelem vypracování status reportu a plánuje se práce celého týmu na další pracovní týden.
3. Projektový manažer dále průběžně monitoruje prostřednictvím reportu „Task Burndown” celkové tempo práce:
  - Zelená šikmá osa - ideální tempo práce. Stav, kdy jsou jednotlivé úkoly uzavírány zcela rovnoměrně. Napravo od této osy pracuje projektový tým pomaleji, než by mohl a naopak vlevo od této osy jsou úkoly uzavírány rychleji.
  - Světle modrá linie - celkový počet úkolů a milníků na projektu SISTA od října 2020 (ke dni aktualizace pravidel řízení projektu obsahoval HMG celkem cca 3 500 uzavřených úkolů a milníků).
  - Oranžová křivka - uzavřené úkoly v čase. Projekt SISTA je velmi specifický, vždy řešíme několik současně realizovaných minitendrů a úkoly se tak neuzavírají ve vlnách na konci sprintů, ale v průběhu sledovaného týdne (30 - 40 úkolů týdně).

Obrázek 9. Burndown chart - ukázka

6.2. Řízení rizik

Projektový manažer udržuje prostřednictvím SW Gantter registr obecných rizik projektu.
Agilní přístup k řízení projektu přináší z pohledu řízení rizik podstatné výhody - rozsah, čas a finanční rámec jsou dány dílčí realizační smlouvou. Rizika je možné řídit již na začátku životního cyklu každého sprintu.
Realizace sprintů je metodikou omezena maximálně na jeden kalendářní měsíc - delší sprinty zvyšují rizika změn definice přírůstku produktu („co má být v rámci sprintu dodáno”). Takto krátké intervaly minimalizují riziko postupu nesprávným směrem a neustálá neformální interakce v rámci týmů TA ČR zajišťuje přidanou hodnotu prováděné práce.
Průběžná přezkoumání a přizpůsobení procesu podstatným způsobem omezují rizika nekontrolovaného nárůstu nákladů na maximálně jeden kalendářní měsíc. Nastavení rámcové dohody a systému minitendrů umožňují korektní narovnání stavu, kdy řešení nevede k naplnění cílů minitendru.
Aktuální stav rizik je projednáván na Oddíl 2.3.1, “Jednání řídícího výboru”.

6.3. Komunikace a výkazy projektu

Pro účely komunikace je udržován komunikační plán projektu (viz přílohy dokumentu), který popisuje informační potřeby zainteresovaných stran a způsoby jejich naplnění. Do komunikačního plánu jsou dále zahrnuty scrumové události.
Projektový manažer zajišťuje, aby byly jednotlivé informace snadno přístupné projektovému týmu a všem zainteresovaným stranám.
Důležitou součástí kontroly stavu a řízení projektu je vhodné výkaznictví vůči zainteresovaným stranám projektu. Cílem monitorováni stavu projektu je zabezpečit pravidelné a standardizované získávání, analyzování a vykazování informací o aktuálním stavu projektu viz základní systém výkaznictví:

Tabulka 5. Systém výkaznictví projektu
Report	Účel
Zpráva o stavu projektu	Poskytování informací o stavu a postupu prací na projektu řídícímu výboru.
Týdenní status report	Informování klíčových zainteresovaných stran o plnění harmonogramu, sprintů a milníků projektu.
Task Burndown report	Průběžná kontrola celkového zdraví projektu z pohledu realizované / zbývající práce.
Retrospektiva sprintu	Sbírání zpětné vazby, zvýšení efektivity budoucích sprintů a eskalování případných problémů k řešení.
Mimořádné zprávy	Mimořádné poskytnutí informací na vyžádání řídícího výboru nebo sponzora projektu.
Lessons learned prezentace	Zhodnocení realizace minitendru a sdílení zkušeností napříč projektovým týmem ve prospěch současných a budoucích minitendrů.

6.4. Shromáždění poznatků

Při řešení každého minitendru shromažďují vlastníci produktů poznatky týkající se technických, manažerských a procesních stránek projektu.
Projektový manažer vyzve co nejdříve po uzavření akceptačního řízení minitendru vlastníka produktu k vypracování lessons learned prezentace v následující struktuře:
- Shrnutí minitendru,
- Hlavní cíle a naše očekávání od minitendru,
- Co se ve vztahu k cílům povedlo,
- Co se ve vztahu k cílům nepovedlo,
- Zpětná vazba od dodavatele (jak se dodavateli s námi spolupracovalo),
- Jak se spolupracovalo s dodavatelem,
- Náměty pro budoucí minitendry,
- Případná doporučení pro ostatní garanty.
Projektový manažer a vlastník produktu plánují termín společné prezentace (sponzor projektu, ředitel sekce interní podpory, ředitel odboru ICT, celý projektový tým a vlastník produktu). Zpětná vazba z lessons learned je promítnuta při plánování dalšího běhu minitendrů.
Lessons learned prezentace je vždy uložena v adresářové struktuře minitendru.
Šablona lessons learned prezentace je připojena v sekci Příloha A, Šablony a formuláře.

7. Historie verzí

Verze: 4.
Datum vydání: 13/02/2024.
Autor: Vítězslav Vlasák, TA ČR, vitezslav.vlasak@tacr.cz.
Poznámka k verzi: Pravidla řízení projektu - únor '24.

Detailní popis změn verze 4:

Doplnění „lessons learned“ z průběhu druhé etapy řešení projektu SISTA za rok 2023.
Doplnění platformního týmu do struktury projektu SISTA viz Oddíl 2.2.5, “IDP tým” a Oddíl 2.3.4, “Jednání DevOps SISTA”.
Doplnění týmu business analytiků do struktury projektu SISTA viz Oddíl 2.2.6, “Business analytici SISTA”.
Doplnění aktuálních poznatků do 3, Administrace a konvence projektu.
Doplnění nové kapitoly Oddíl 4.4.6, “Závěrečná prezentace pro ostatní účastníky RD”.
Přepracování kapitoly 5, Architektura, vývoj a dokumentace v kontextu nových poznatků.
Odstranění nadbytečného zdroje informací v podobě webu SISTA External info. Nově jsou všechny relevantní informace distribuovány skrze Rozcestník dokumentace SISTA.
Oprava indexování všech hesel rejstříku pro generování PDF verze handbooku.

Detailní popis změn verze 3:

Doplnění „lessons learned“ z průběhu druhé etapy řešení projektu SISTA za rok 2022.
Doplnění konceptuálního rámce a rozšíření kapitoly Oddíl 3.4, “Klíčové artefakty projektu”.
Přepracování kapitoly 5, Architektura, vývoj a dokumentace v kontextu nových poznatků.
Sjednocení přístupu k jednotlivým fragmentům pravidel SISTA.
Doplnění checklistu pro akceptační řízení a převzetí služby Ops týmem.
Doplnění šablony PDF formuláře dílčí realizační smlouvy.
Doplnění šablony návrhu řešení ve formátu AsciiDoc.
Aktualizace používaných šablon prezentací a formulářů.
Opravy spojené s novými verzemi Asciidoctor a PlantUML.
Doplnění akceptace proti STAGING prostředí.
Doplnění existence sanity checku vč. odkazu na metodiku.

Závěr

Dokument poskytuje rámec pro řízení projektu „Sdílený Informační Systém Technologické Agentury ČR”, jehož předmětem je vytvoření softwarového řešení s využitím týmové spolupráce mezi projektovým týmem TA ČR a účastníky rámcové dohody.

Popisované procesy jsou zasazeny do kontextu specifických podmínek TA ČR a nemusí mít všeobecnou platnost, mohou však sloužit jako inspirace pro realizaci jiných IT projektů.

Od některých požadavků metodiky Scrum se záměrně odchylujeme (např. „Daily Scrum", sprintový backlog s organizací práce vývojářů na straně dodavatele) a naopak jiné nástroje (konzultace k obsahu plnění minitendru s účastníky rámcové dohody, lessons learned řešení minitendru či vybrané konvenční procesy projektového řízení) jsme pro potřeby efektivního řízení projektu doplnili.

Dokument byl vytvořen s využitím open-source projektů:

Termíny a definice

Agilní přístup k řízení projektu: Agilní přístupy jsou vhodné pro projekty s vysokou mírou neurčitosti a komplexity vazeb, kdy není dost dobře možné spolehlivě definovat rozsah projektu, a proto je obtížné sestavit plán projektu. U těchto projektů je výhodné použít iterativní projektové řízení, které vzešlo z oblasti návrhu a vývoje SW.
Akceptační protokol: Formálně potvrzuje, že převzatý výstup je příjemcem bez vad akceptován, případně akceptován s výčtem výhrad (s lhůtou pro odstranění) nebo neakceptován (s uvedením důvodu).
ArchiMate: Standardizovaný modelovací jazyk, sloužící primárně pro účely popisu, zobrazení a pro následnou analýzu podnikové architektury. Jazyk umožňuje vizualizovat různé pohledy na informační či jiné podnikové systémy.
Architektura orientovaná na služby (SOA): Styl architektury (business a technologické), který je zaměřen na zjednodušení spolupráce různých částí a s důrazem na pružnost v důsledku změn.
AsciiDoc: Značkovací jazyk pro přípravu textů. Zároveň jde o multiplatformní program napsaný v Pythonu. AsciiDoc formát vznikl již v roce 2002 a následně byl v roce 2013 uvolněn klon - AsciiDoctor napsaný v Ruby a používaný mj. na GitHubu.
Gitlab: Webová služba podporující vývoj softwaru při používání verzovacího nástroje git.
Google IAP (Identity-Aware Proxy): Služba od společnosti Google, která slouží k zabezpečení přístupu k aplikacím a virtuálním strojům (VM) na Google Cloud Platform (GCP). IAP používá autentizaci a autorizaci k ověření identity uživatele a k určení, zda má uživatel přístup k danému zdroji.ß
Burndown report: Burndown znázorňuje, jak velkou část práce projektový tým už „spálil“ a kolik zbývá do konce sprintu a/nebo řešení miniprojektu. Burndown report pomáhá projektovému týmu udržet tempo práce a rychlost dodávek na vysoké úrovni.
Cíl sprintu (Sprint goal): Jedná se o cíl definovaný při plánování sprintu, jehož má být dosaženo během sprintu a to prostřednictvím implementace položek produktového backlogu.
Cloud native: Cloud native je moderní přístup k vytváření a provozování softwarových aplikací, který využívá flexibilitu, škálovatelnost a odolnost moderních dynamických prostředích, jako jsou veřejné, soukromé a hybridní cloudy.
Cloud computing: Způsob zajištění provozu informačního systému veřejné správy nebo jeho části prostřednictvím dálkového přístupu k sdílenému technickému nebo programovému prostředku, který je zpřístupněný poskytovatelem cloud computingu a nastavitelný správcem informačního systému veřejné správy.
Dapr (Distributed Application Runtime): Technologie, která si klade za cíl zjednodušit a sjednotit integraci služeb běžících v Kubernetes clusteru. Zdrojový kód je napsán v programovacím jazyce Go.
Definice „kdy je hotovo" (Definition of Done): Pokud jsou položky backlogu nebo přírůstky produktu označeny jako hotové, musí každý člen scrumového týmu rozumět, co to znamená. Scrumové týmy k tomu používají definici „kdy je hotovo”, která se používá k posouzení, zda je práce dokončena nebo ne.
Denní schůzka (Daily Scrum): Každodenní krátká schůzka vývojářů scrumového týmu, která není delší než 15 minut. Je určená pro kontrolu pokroku ve vztahu k cíli sprintu a podle potřeby k úpravám sprintového backlogu.
DevOps: Složenina anglických výrazů Development a Operations. Je to přístup k vývoji software, který zdůrazňuje komunikaci, spolupráci a integraci mezi vývojářem a odborníky na informační technologie z provozu.
DevOps meeting: Exekutivní skupina zodpovědná za kontrolu a údržbu strategické a technologické architektury. Rada by měla reprezentovat všechny klíčové subjekty zainteresované v architektuře (stakeholder) a typicky sestává z členů Ops zodpovědných za dohled a údržbu celkové architektury z úhlu pohledu svých zodpovědností a relevantních členů Dev dodavatelských týmů.
Dev tým: Tým vývojářů, softwarových inženýrů, testerů a dalších potřebných rolí dodavatele.
Dodavatel: Účastník rámcové dohody, který poskytuje zdroje a know-how potřebné k dosažení požadovaného výsledku projektu.
Dynamický nákupní systém (DNS): Představuje speciální, plně elektronický způsob zadávání veřejných zakázek, jejichž předmětem je pořízení běžného, obecně dostupného zboží, služeb či stavebních prací.
Google Cloud Platform: Sada služeb cloud computingu, která běží na stejné infrastruktuře, kterou Google interně používá pro své produkty pro koncové uživatele.
Google Workspace: Sada cloudových nástrojů, groupware a softwaru poskytovaného společností Google formou předplatného.
Harmonogram projektu (HMG): Grafické znázornění plánu WBS s Ganttovým diagramem, který popisuje posloupnost úkolů, společně s přidělením zdrojů, které dohromady tvoří plán.
Internacionalizace a lokalizace: Přizpůsobení počítačového software pro různé jazyky. Internacionalizace je takový zápis zdrojového kódu programu, že může bez jeho změny program pracovat v různých jazykových prostředích. Lokalizace je pak vytváření externích souborů, které obsahují překlady jednotlivých hlášení programu a definic konkrétních jazykových odlišností (například zápis data a času, měny a podobně).
Iterace: Opakování, krok přiblížení se k požadovanému výsledku. Základním principem iterace je opakování určitého procesu v měnícím se kontextu. Scrum využívá iterace zvané „sprinty“ s přesně danou dobou trvání.
Kubernetes: Svobodný systém pro orchestraci virtualizace na úrovni OS. Původně jej vyvinula společnost Google a jako podřízené nástroje podporuje například Docker a rkt. Kubernetes je vyvíjený v jazyce Go a uvolněný pod licencí Apache.
Minitendr: Způsob výběru nejvhodnějšího návrhu řešení na základě rámcové dohody, kdy zadavatel vyzve účastníky k předložení návrhu řešení konkrétní specifikace ve výzvě k podání návrhů řešení, a to jak pro postup s obnovením soutěže, tak pro postup bez obnovení soutěže.
Minimální životaschopný produkt (MVP): Verze produktu obsahující nejmenší množství funkcí, které jsou třeba, aby produkt byl ještě zákazníkem využitelný. Často se využívá k získání zpětné vazby.
Národní elektronický nástroj (NEN): Informační systém pro zadávání veřejných zakázek. Obsahuje postupy pro všechny kategorie zadavatelů včetně sektorových a komplexní funkcionalitu pro centralizované zadávání zakázek.
Návrh řešení: Nabídka účastníka v minitendru, kterou účastník reaguje na výzvu zadavatele v termínech a podmínkách ve výzvě stanovených.
Ops tým: Tým vývojářů, správců, testerů a poučených uživatelů TA ČR.
Open-source software: Otevřený software je počítačový software s otevřeným zdrojovým kódem. Otevřenost zde znamená jak technickou dostupnost kódu, tak legální dostupnost licence software.
Otevřený bod (Issue): Skutečnost, která nastala při řešení projektu, překračující kompetence projektového manažera, nebo která v případě neřešení vyústí v ohrožení cílů sprintu/minitendru/projektu a která je k řešení eskalována na řídící výbor.
PlantUML: Označení doménově specifického jazyka a překladače, které slouží k vytváření diagramů typu UML na základě zdrojového kódu ukládaného jako prostý text.
Plánování sprintu (Sprint planning): Událost, kdy se v součinnosti celého scrumového týmu dohodne práce, která má být vykonána během sprintu. Plánování sprintu odpovídá na následující otázky: Proč je tento sprint cenný? Jaký má celý sprint účel? Co může být tento sprint dodáno? Jak bude zvolená práce provedena?
Poznámky k vydání (Release notes): Poznámky k vydání podrobně popisují opravy, změny nebo vylepšení provedené v softwarovém řešení.
Produkt: Prostředek, který přináší hodnotu. Má jasnou hranici, známé zúčastněné strany, dobře definované uživatele nebo zákazníky. Produktem může být služba, fyzický produkt nebo něco abstraktnějšího.
Produktový backlog (Product backlog): Strukturovaný seznam všeho, o čem se ví, že bude v produktu potřeba. Jedná se o jediný zdroj požadavků práce scrumového týmu. Za obsah, dostupnost a prioritizaci produktového backlogu je plně zodpovědný vlastník produktu.
Produktový cíl (Product target): Popisuje budoucí stav produktu, který slouží scrumovému týmu jako cíl, jehož dosažení se bude plánovat. Produktový cíl je uveden v produktovém backlogu. Zbytek produktového backlogu se soustředí na definici pouze toho, „co“ splní produktový cíl. Produktový cíl je pro scrumový tým dlouhodobým cílem. Než se pustí do dalšího, musí splnit (nebo opustit) jeden cíl.
Proměnná prostředí (Environment variable): Dynamická proměnná, která je v operačním systému vlastností běžícího procesu. Proměnných prostředí je obvykle více, lze je měnit a jejich obsah může ovlivnit práci běžícího procesu.
Přírůstek (Increment): Výčet všech položek z produktového backlogu, které byly dokončeny během skončených sprintů. Každý přírůstek musí být použitelný uživatelem, jinak nepřináší žádnou hodnotu. v průběhu jednoho sprintu může být vytvořeno více přírůstků.
REST API: REST je architektura API, která nám umožňuje přistupovat k datům a provádět nad nimi CRUD (Create, Read, Update, Delete) operace. REST je bezstavový, čímž jednak značně zjednodušuje komunikaci s API a umožňuje paralelní zpracování obsahu.
Retrospektiva sprintu (Sprint Retrospective): Retrospektiva se koná po revizi sprintu, avšak před plánováním dalšího sprintu. Jejím účelem je naplánovat kroky, pomocí kterých dojde během příštího sprintu k zvýšení efektivnosti a kvality.
Revize sprintu (Sprint review): Vyhodnocení prováděné na konci sprintu se zabývá výsledným produktovým přírůstkem a v případě potřeby vede k přizpůsobení produktového backlogu.
Scrum: Nejpoužívanější rámec agilního řízení, který je založen na krátkých iteracích (sprintech), které dodávají hotový přírůstek tvořeného díla. Na každý hotový přírůstek tvořeného díla je sebrána zpětná vazba od zákazníků/uživatelů, podle níž jsou upraveny další kroky řešení.
Scrumový tým (Scrum team): Scrumový tým se skládá z vlastníka produktu, vývojářů a volitelně Scrum Mastera. Scrumové týmy dodávají produkty během opakujících se cyklů (iterativně) a postupně po menších přírůstcích (inkrementálně), zatímco maximálně využívají zpětnou vazbu.
Sdílený informační systém TA ČR: Softwarové řešení, jehož postupný vývoj pokračuje etapou 2 dle rámcové dohody.
Softwarové řešení: Jakákoliv část informačního systému na straně zadavatele nebo orgánu veřejné moci (např. další organizační složky státu, územně samosprávné celky) či další právnické osoby ovládané Českou republikou, která má být dotčena změnou funkcionality, vylepšením, zefektivněním apod.
Sprint: Rozdělení projektu na krátké a zvládnutelné intervaly s přesně danou dobou trvání (1 - 4 ww). Účelem každého sprintu je dodání přírůstku potenciálně uvolnitelné funkčnosti, který je plně v souladu s definicí „kdy je hotovo“ scrumového týmu.
Sprintový backlog (Sprint Backlog): Množina položek vybraných z produktového backlogu do konkrétního sprintu - včetně plánu na dodání produktového přírůstku a splnění cíle sprintu. Po vykonání nebo dokončení práce se aktualizuje odhad zbývající práce.
Technologická agentura České republiky (TA ČR): Zadavatel projektu, kterému budou výsledky projektu sloužit k naplnění strategických cílů.
Third-party service (TRS): Služba Třetí Strany – ve vztahu k řešenému tématu jde o další interní nebo externí služby SISTA.
Vlastník produktu (Product Owner): Klíčová osoba každého SW projektu. Jde o zaměstnance TA ČR, který obvykle nedisponuje znalostmi technologií, avšak ovládá doménu byznysu a zná regulatorní mantinely.
Vývojáři (Developers): Součást scrumového týmu, který se skládá z profesionálů, kteří na konci každého sprintu doručují potenciálně uvolnitelný přírůstek produktu, který musí být hotov do revize sprintu.
Zainteresovaná strana projektu: Osoba, která je aktivně zapojena do projektu nebo jejíž zájmy mohou být pozitivně a/nebo negativně ovlivněny realizací projektu či jeho výsledkem.

Odkazy a zdroje

Vnitřní předpisy

[RAD-07] TA ČR. RAD-07 Spisový řád. In: Technologická agentura ČR [online]. 2020. [cit. 31/01/2024]. Dostupné z: https://drive.google.com/file/d/1eYzN6Ol8iE8fVDIUZi04RtkzgUTIgeh8/.
[SME-01] TA ČR. SME-01 Řízení vnitřních předpisů. In: Technologická agentura ČR [online]. 2022. [cit. 31/01/2024]. Dostupné z: https://drive.google.com/file/d/1hvysYpjH4QJ55v6tFqGSNJZT02G8q4Jw/.
[SME-19] TA ČR. SME-19 Poptávková řízení a zadávání veřejných zakázek. In: Technologická agentura ČR [online]. 2021. [cit. 06/02/2024]. Dostupné z: https://drive.google.com/file/d/1zi5spm4we0xLWGXncRTve3q1rdHXpqRE/
[SME-33] TA ČR. SME-33 Projektové řízení. In: Technologická agentura ČR [online]. 2020. [cit. 06/02/2024]. Dostupné z: https://drive.google.com/file/d/1lkKtH4P9fCgrGUdL2eGDzK8Aq6SRICvn/
[SME-37] TA ČR. SME-37 Management změn. In: Technologická agentura ČR [online]. 2020. [cit. 06/02/2024]. Dostupné z: https://drive.google.com/file/d/1adCJ6dWu97SYBnWzjBitDE00ln_N6P-T/

Regulatorní požadavky

[ZPVV] ČESKO. Zákon č. 130/2002 Sb., o podpoře výzkumu a vývoje z veřejných prostředků a o změně některých souvisejících zákonů (zákon o podpoře výzkumu a vývoje). In: Zákony pro lidi.cz [online]. © AION CS 2010-2022 [cit. 06/02/2024]. Dostupné z: https://www.zakonyprolidi.cz/cs/2002-130
[ZZVZ] ČESKO. Zákon č. 134/2016 Sb., o zadávání veřejných zakázek. In: Zákony pro lidi.cz [online]. © AION CS 2010-2022 [cit. 06/02/2024]. Dostupné z: https://www.zakonyprolidi.cz/cs/2016-134
[ZISVS] ČESKO. Zákon č. 365/2000 Sb., o informačních systémech veřejné správy a o změně některých dalších zákonů. In: Zákony pro lidi.cz [online]. © AION CS 2010-2022 [cit. 06/02/2024]. Dostupné z: https://www.zakonyprolidi.cz/cs/2000-365
[VYVIS] ČESKO. Vyhláška č. 317/2014 Sb., o významných informačních systémech a jejich určujících kritériích. In: Zákony pro lidi.cz [online]. © AION CS 2010-2022 [cit. 06/02/2024]. Dostupné z: https://www.zakonyprolidi.cz/cs/2014-317

Internetové zdroje

[ArMa] The ArchiMate® Enterprise Architecture Modeling Language | The Open Group Website. The Open Group Website | [online]. Copyright © 1995 [cit. 06/02/2024]. Dostupné z: https://www.opengroup.org/archimate-forum/archimate-overview
[IKCR] Informační koncepce ČR | Digitální Česko. Digitální Česko | Digitální Česko [online]. 2022. [cit. 06/02/2024]. Dostupné z: https://digitalnicesko.gov.cz/vize/
[NUKIB] GitHub - NUKIB/bezpecnostni-doporuceni-open-source: Bezpečnostní doporučení pro vývoj otevřeného software ve veřejné správě. GitHub: Where the world builds software · GitHub [online]. 2022. [cit. 06/02/2024]. Dostupné z: https://github.com/NUKIB/bezpecnostni-doporuceni-open-source
[PrIT] GitHub - cesko-digital/derisking-handbook: Průvodce světem řízení IT projektů. GitHub: Where the world builds software · GitHub [online].2022. [cit. 16/11/2022]. Dostupné z: https://github.com/cesko-digital/derisking-handbook
[SQSA] UNIVERSITY OF APPLIED SCIENCES KOBLENZ. 4th study on Benefits and Success factors of agile methods. Status Quo (Scaled) Agile [online]. 2020. [vid. 06/02/2024]. Dostupné z: http://www.status-quo-agile.net/

Rejstřík

Příloha A: Šablony a formuláře

ID	Název přílohy s odkazem na projektovou knihovnu	Verze
01	Organizační struktura projektu	4
02	Zápis z jednání projektu	4
03	Záznamy o jednání s dodavatelem	4
04	Rámcové cíle projektu	4
05	Produktový backlog	4
06	Specifikace zadání minitendru	4
07	Formulář konzultace k obsahu plnění	4
08	Informace o proběhlé konzultaci k obsahu plnění	4
09	Dílčí smlouva ve formátu PDF (soutěžní/soutěžní + 10% paušál/nesoutěžní MT)	4
10	Plán testování	1
11	Návrh řešení ve formátu AsciiDoc	4
12	Revize sprintu	4
13	Retrospektiva sprintu	4
14	Plán testování	1
15	Checklist převzetí služby	4
16	Akceptační protokol minitendru	4
17	Komunikační plán projektu	4
18	Lessons learned prezentace	4

1. Především z důvodů zachování přínosů osobní interakce a řiditelnosti celku.

2. Scrum Master je nepovinná role, která nemusí být obsazena, pokud je tým schopen pracovat samostatně a vlastník produktu plní svou roli.

3. Scrum patří mezi nejpoužívanější metody agilního řízení [SQSA], neboť se jedná o flexibilní metodu produktového vývoje, zvláště přínosnou při inkrementálním a setrvalém dodávání inovací.

4. Používané typy je možné doplnit z knihovny: https://fonts.google.com/, která mj. obsahuje informace s licenčním ujednáním pro použití vybraného typu písma.