Ú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 a integrační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 projektu SISTA. Věříme, že dodavatelé svými zkušenostmi přispějí k návrhu nových funkcionalit a vytvoření inovovaného softwarového řešení.

Nový informační systém 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:

  1. ověření použitelnosti rozhraní stávajících softwarových řešení ISTA a IS BETA 2;

  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;

  3. provedení analýz možného řešení a postupu;

  4. rozhodnutí TA ČR o zvolené technologii;

  5. dosažení kapacity dodavatelů RD1 pro zvolenou technologii;

  6. 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ů:

  1. seznámení dodavatelů s dosavadními výstupy projektu SISTA formou řízeného onboardingu;

  2. zavedení GCP jako technologického základu SISTA a REST API jako komunikačního rozhraní;

  3. provádění analýz funkcionalit za účelem zlepšení jejich efektivity a navrhování nových funkcionalit při dodržení technologického rámce;

  4. analyzování s návrhem řešení provozu funkčních vzorků a prototypů;

  5. ověření předpokladů pro zavedení nových funkcionalit a nových technologií;

  6. vyvíjení nových funkcionalit a zlepšení na nových technologiích;

  7. uvádění technologií v produkční provoz a řešení souvisejících otázek.

Projekt SISTA v období trvání rámcové dohody č.2 dosáhl následujících výsledků:

  1. dokončení mapování architektury, byznysových procesů (konceptuálních rámců s detailními flow diagramy) a struktur aplikací SISTA v modelovacím jazyce Archimate;

  2. finalizace základních předpokladů/postupů/technik pro zapojení více dodavatelů do vývoje služeb SISTA. Soubor pravidel je veřejně dostupný na Rozcestníku dokumentace SISTA;

  3. implementace technologické platformy GCP včetně CI/CD pipelines s důrazem na maximální využívání managed komponent Google viz pravidla platformy SISTA;

  4. vytvoření či rozvoj průřezových služeb tvořících základní kostru každé byznysové služby. Jedná se především o následující služby a komponenty: Knihovna React UI komponent, IdM, Rejstřík, Správa vazeb, Workflow, Formuláře, Notifikační služba, Číselníková služba, Správa šablon, PDF Generátor, Vzkazník, Poznámky, FiSto;

  5. vytvoření služeb, které podporují byznysovou doménu TA ČR: Správa programů, Registrace organizace, Vyhlášení veřejné soutěže, Podání návrhu programového projektu/nabídky, Formální kontroly, Správa expertů, Jednání, Uzavření smlouvy o poskytnutí podpory;

  6. uvedení technologií/vytvořených průřezových a byznysových služeb v pilotní (předprodukční) provoz a řešení otázek s tímto souvisejících;

  7. realizace 56 minitendrů zaměřených na dodávku nových/rozvoje existujících průřezových a byznysových služeb SISTA.

TA ČR přistoupila k obnovení rámcového vztahu s ohledem na dosažené výsledky projektu, které umožňují podpořit směr řešení od hledání způsobu jak, přes ověření k jeho funkčním dílčím realizacím v rutinním provozu nebo poloprovozu. TA ČR dále předpokládá, že dosavadní výsledky projektu umožňují jeho dílčí, a z pohledu autorských či licenčních plateb, bezplatné využití i u jiných veřejných zadavatelů.

Hlavním cílem etapy 3 projektu SISTA je tvorba rutinních řešení postavených na již hotových službách, s důrazem na jednotné technologické prostředí a efektivní výměnu dat mezi službami.

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, aplikací DevOps přístupu mezi IDP týmem/dodavateli a udržováním dalších potřebných prerekvizit (GCP, GitLab, CI/CD pipelines, pravidel architektury, platformy, vývoje, vedení dokumentace, design systému, knihovny UI komponent, katalogu služeb a datového katalogu) pro další pokračování projektu. Na následujícím obrázku je znázorněn konceptuální rámec SISTA:

Konceptuální rámec projektu SISTA
Figure 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.

Note
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 Section 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

  1. 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:

    Organizační struktura projektu SISTA
    Figure 2. Organizační struktura projektu SISTA

  2. V organizační struktuře projektu jsou vyznačeny role vycházející z procesního rámce Scrum.

  3. Scrumové týmy vznikají dynamicky dle potřeb sprintu (srov. s Section 2.2.4, “Scrumový tým”).

  4. 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.

Note

Řešení témat může vyvolat 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í. Konkrétní podobu a způsob fungování stanoví jednání projektového týmu SISTA.

2.2. Role a odpovědnosti

2.2.1. Řídící výbor

  1. 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.

  2. Ří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.

  3. Ří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 Section 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,

  4. Pravidla jednání upravuje Section 2.3.1, “Jednání řídícího výboru”.

2.2.2. Sponzor projektu

  1. Sponzorem projektu je ředitel Kanceláře TA ČR.

  2. Sponzor projektu rozhoduje o klíčových aspektech projektu, neboť odpovídá za přínos pro organizaci.

  3. 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í.

  4. Je statutárním zástupcem pro smluvní záležitosti.

2.2.3. Projektový tým

  1. 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.

  2. Projektový tým přijímá rozhodnutí v rozsahu, který nevyžaduje rozhodnutí řídícího výboru.

  3. Pravidla jednání upravuje Section 2.3.2, “Jednání projektového týmu”.

2.2.4. Scrumový tým

  1. 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 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 Section 4.4.2, “Plánování sprintu”.

  2. Pravidla jednání upravuje Section 2.3.3, “Jednání scrumového týmu”.

2.2.5. IDP tým

  1. 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.

  2. IDP tým je z pohledu projektu SISTA podřízen sponzorovi projektu a to z důvodů oddělení odpovědností za dodávku a následného provozu služeb SISTA.

  3. Organizačně je IDP tvořen členy Oddělení vývoje informačních systémů Odboru ICT TA ČR.

  4. 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.

  5. Pravidla jednání DevOps SISTA upravuje Section 2.3.4, “Jednání DevOps SISTA”.

2.2.6. Business analytici SISTA

  1. 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í.

  2. Z pohledu řízení projektu jsou business analytici SISTA podřízeni projektovému manažerovi.

  3. 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 a Balsamiq, 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

  1. 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.

  2. 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 Section 4.5, “Akceptace a uzavření minitendru”.

  3. Projektový manažer je členem řídícího výboru s hlasem poradním.

  4. 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

  1. 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 Section 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

  1. 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.

  2. Jednání s Focus group SISTA plánuje sponzor projektu. Projektový manažer připraví potřebné podklady pro vlastní jednání.

  3. 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

  1. 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ů.

  2. 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.

  3. Koordinátor projektu rozesílá odkaz na prezentaci nejpozději 1 pracovní den před termínem jednání.

  4. 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.

  5. 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í.

  6. 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.

  7. Ří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í.

  8. 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.

  9. 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ě.

    Tip Šablona zápisu je připojena v přehledu Appendix A, Šablony a formuláře.

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

  1. Jednání projektového týmu probíhá pravidelně každé pondělí od 9:00 hod.

  2. 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. zpětná vazba z koordinace projektu SISTA se zástupci dodavatelů,

    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.

  3. 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í.

  4. Finální zápisy jsou uloženy v adresáři: 02. Projektový tým SISTA projektové knihovny.

  5. 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ě.

    Tip Šablona zápisu je připojena v přehledu Appendix A, Šablony a formuláře.

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

  1. Jednání scrumového týmu probíhají podle potřeb každého sprintu a jsou organizována vlastníkem produktu.

  2. Požadavek na každodenní koordinaci scrumového týmu (Daily Scrum) je aplikován přiměřeně.

  3. 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.

  4. 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.

  5. 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.

  6. Projektový manažer může dle aktuálního stavu řešení minitendru pravidla vedení dokumentace scrumového týmu upravit.

Note 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

  1. 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.

  2. Jednání DevOps SISTA organizuje a řídí vedoucí oddělení vývoje IS.

  3. 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.

  4. 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.

  5. Vedoucí oddělení vývoje IS vypracuje a rozešle z jednání DevOps SISTA zápis, který je připojen k události.

  6. 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.

2.3.5. Jednání Architektonické rady

  1. Jednání Architektonické rady SISTA (Archy) probíhá pravidelně v intervalu 1x14 dní za účasti zástupců IDP týmu, přizvaných osob a dodavatelů, kteří vyvíjí nebo drží podporu nad produkčními službami.

  2. Věcnou náplní těchto jednání jsou výhradně otázky týkající se technologické architektury SISTA, její změny, úpravy či vylepšení.

  3. Jednání Architektonické rady SISTA organizuje a řídí ředitel Odboru ICT.

  4. Architektonická rada SISTA přijímá rozhodnutí konsensuálně s cílem dosažení nejlepšího možného řešení ve prospěch projektu SISTA, přičemž nesmí dojít k rozhodnutí, které by ve svém důsledku znamenalo technologickou diskriminaci některého člena rady.

  5. Architektonická rada SISTA z pohledu přínosů zajišťuje:

  6. návrhy na implementaci technologických změn architektury,

  7. řízení architektury SISTA týmem IDP (platformou SISTA),

  8. diskuzi a výběr nejvhodnějších variant řešení napříč všemi dodavateli,

  9. řešení sporných otázek týkajících se stavby jednotlivých služeb tak, aby zapadaly do architektonického rámce SISTA.

  10. Ředitel Odboru ICT vypracuje z jednání Architektonické rady SISTA zápis, který je připojen k události.

  11. Ředitel Odboru ICT má pravomoc po dohodě s Dev týmy a projektovým manažerem upravovat termíny, četnost a přizvané členy (typicky byznys architekt, byznys analytici, …) jednání Architektonické rady SISTA dle aktuálních potřeb řešení projektu.

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.

Note

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.

Scrum
Figure 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.

Note
Poznámky

  • 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.

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ě.

Note

3.1. Formální požadavky

  1. 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.

  2. 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).

  3. 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:

    Table 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.

  4. 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).

  5. 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.

  6. 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.

  7. Pokud je nutné zaslat soubory e-mailem, uživatel doplní do názvu souboru datum poslední úpravy (např. handbook-SISTA-2024-12-05.zip, MT090-definice-pozadavku-2024-12-05.pdf,…​).

  8. 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:

  1. Základní a uživatelské atributy:

    // Hlavicka dokumentu 1
= 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  2
: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/2024
:Custom_2: {doctitle}
:Custom_3: {output-generated} : {docdatetime}
:keywords:

  2. Historie změn:

// Na konci dokumentu
== Historie změn 3

[%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.

  1. Minimální atributy hlavičky AsciiDoc dokumentu.

  2. Typ dokumentu - rozdíly popisuje uživatelská dokumentace AsciiDoc.

  3. Historie změn uvedená jako samostatná kapitola nebo prostřednictvím funkce include vložený adoc.

Tip

  • 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

  1. 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.

  2. Koordinátor projektu spravuje strukturovaný Přehled předané dokumentace, který je uložen v projektové knihovně pro dodavatele.

  3. 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.

  4. 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.

  5. Ř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.

  6. 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”.

  7. 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í Section 5.4, “Pravidla vývoje” a Section 5.6, “Pravidla vedení dokumentace”.

3.2.2. Adresářová struktura MT

  1. 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:

    Adresářová struktura minitendru v projektové knihovně
    Figure 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 Section 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 Section 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 Section 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.

    • 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 Section 4.5, “Akceptace a uzavření minitendru”.

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

  1. 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),

    • Inkscape: .svg (SVG Inkscape),

    • Figma: .fig nebo Penpot: .penpot`či Balsamiq: `.pdf, .png, .html.

  2. Výčet používaných SW nástrojů může být po vzájemné dohodě rozšířen - platí však zásada, že jednotlivé týmy v maximální míře využívají takové 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 Section 1.2, “Účel dokumentu”.

    • Archimate modely – HTML export obsahující pohledy na procesy, byznysové - průřezové - integrační služby, platformu SISTA a další kontextové informace o 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, 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 Section 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.Ze SW Balsamiq jsou poskytovány ve formátu jako je PDF, PNG nebo jako interaktivní HTML prototyp.

  • 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 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 Section 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:

Table 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í projektu

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ů

  1. TA ČR za účelem efektivního řešení projektu SISTA vymezila níže uvedené typy minitendrů (čl. 1, odst. 1 RD3):

    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í. Zadavatel předpokládá, že 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 a z těchto řešení bude určena výsledná technologie, produkt či jeho vlastnosti. Detaily vždy stanoví výzva;

    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 modulů/částí/služeb apod. 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;

    4. ostatní.

Note
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, přičemž za jedno zadání se považuje zadání i více účastníkům rámcové dohody najednou.

    • pro tento typ zadání se nepoužijí hodnotící kritéria dle RD3 (čl. 7, odst. 2).

  • U inovativně vývojových minitendrů typu „B” mohou být pro řešení, které obsahuje etapy řešení (určené výzvou) vybráni až tři účastníci, kteří budou odděleně řešit své návrhy řešení. Zadavatel může po jednotlivých etapách jednotlivá řešení ukončit (čl. 5, odst. 12 RD3).

  • Pro dosažení účelu plnění cíle minitendru © - programátorské a vývojářské činnosti, je v případě nedostatku kapacit na straně účastníků rámcové smlouvy zadána zakázka v rámci DNS dle článku II. odst. 4. této rámcové dohody (čl. 4, odst. 3 RD3).

4.2. Příprava zadání minitendru

4.2.1. Určení vlastníka produktu

  1. 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á.

  2. 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.

  3. 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í.

  4. 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.

Tip
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ů

  1. 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.

  2. 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.

  3. 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.

      K helicopter view je vždy připojen samostatný model označený jako „Dokumenty procesu IDXY“, který obsahuje procesně významné výstupy (mohou existovat ve formě AsciiDoc šablon pro pozdější generování PDF, jsou významné pro uložení ve spisové službě apod.) ve formě byznysových objektů a reprezentací s vazbou typu realizuje.

      Uzavření smlouvy o poskytnutí podpory - helicopter view
      Figure 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í.

      Flow diagram slouží k pozdější konfiguraci definice průběhu procesu v průřezové službě Workflow, a to i pro jiné poskytovatele.

    Jednání kolektivního orgánu - detailní flow
    Figure 6. Jednání kolektivního orgánu - detailní flow

  4. Hledisko struktury aplikace - popisuje, se kterými dalšími službami bude připravovaná služba komunikovat či spolupracovat. Diagram poskytuje kontext mj. pro potřeby pozdějších řízení změn.

    Byznysová služba Jednání - struktura aplikace
    Figure 7. Byznysová služba Jednání - struktura aplikace

  5. 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.

  6. 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 RD3) či postupem bez obnovení soutěže (čl. 6 RD3). 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 Section 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 RD3 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 RD3 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 RD3. 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.

Note
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 RD3) 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

  1. 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í.

  2. 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.

    Ze SW Balsamiq jsou poskytovány ve formátu jako je PDF, PNG nebo jako interaktivní HTML prototyp.

    Note
    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 Section 5.5, “Pravidla UX a design systém”.

  3. 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 Section 4.2.4, “Konzultace k obsahu plnění” či projednání s dodavateli prostřednictvím Section 4.2.5, “Účastnická konzultace k očekávanému řešení”.

  4. 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.

    Table 3. Základní struktura produktového backlogu
    ID Produktový cíl 1: Znění produktového cíle Informace k produktovému cíli/definice „kdy je hotovo"] Odhad pracnosti Priorita Riziko

    01

    h

    Kritická

    Vysoké

    02

    h

    Vysoká

    Vysoké

    03

    h

    Střední

    Nízké

    04

    h

    Nízká

    Střední

  5. 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.

    Note
    Poznámky

    • Produktový backlog je součástí výzvy k podání návrhů řešení u minitendrů typu „B” a „C” viz Section 4.1, “Typy minitendrů”.

    • Produktový backlog je živým artefaktem, pokud existuje produkt, existuje i jeho backlog.

  6. 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 Section 4.4.4, “Revize sprintu”.

  7. Projektový manažer s vlastníkem produktu vypracují specifikaci zadání minitendru (viz Appendix 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 Section 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) RD3) , 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.

  8. 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í

  1. Projektový manažer může v souladu s čl. 5, odst. 2 RD3 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.

  2. 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 Appendix A, Šablony a formuláře) pro zaslání zpětné vazby.

  3. Projektový manažer upozorní zástupce dodavatelů na povinnost zachovávat mlčenlivost a zároveň určí přiměřenou lhůtu pro odpověď.

  4. 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 RD3).

  5. 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.

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

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

  1. 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 RD3) 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í.

  2. 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í prostřednictvím e-mailu, NEN nebo ISDS.

  3. Pokud se zástupce dodavatele povinného jednání nezúčastní, není oprávněn podat návrh řešení.

  4. Úč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

  1. 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.

  2. 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.

  3. Pro podání návrhu řešení se stanoví lhůta minimálně 7 kalendářních dnů. Další podrobnosti upravuje čl. 5 RD3.

  4. 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.

    Important
    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 RD3).

  5. 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ě.

  6. 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 RD3).

  7. 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í

  1. 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.

  2. 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.

  3. 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.

  4. 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).

  5. 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].

  6. 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ě.

  7. Hodnotící komise seřadí návrhy řešení podle provedeného hodnocení od nejvhodnějšího po nejméně vhodný.

  8. Pokud předloží návrh řešení pouze jeden dodavatel, může být zadavatelem vybrán bez provedení hodnocení.

  9. 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í.

  10. Č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

  1. 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”).

  2. 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.

  3. 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 RD3).

  4. Ekonomické oddělení zajistí zveřejnění oznámení o výběru a dílčí smlouvy v registru smluv.

  5. Po zveřejnění v registru smluv právník zaeviduje výsledek zadávacího postupu do systému NEN.

Note
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í.

Table 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

  1. 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

  1. 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.

  2. 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.

  3. 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ší 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í 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”).

  4. 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.

  5. 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.

  6. 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.

  7. 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.

  8. 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

  1. 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 Section 2.3.3, “Jednání scrumového týmu”.

  2. Vlastník produktu průběžně informuje o postupu viz Section 2.3.2, “Jednání projektového týmu”.

  3. 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.

  4. 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á.

  5. 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 Section 6.1, “Řízení času” a Section 6.3, “Komunikace a výkazy projektu”.

  6. 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í.

    Important
    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.

  7. 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

  1. Podstatou revize sprintu je předání/převzetí hotového přírůstku (výsledku sprintu).

  2. Podklady pro revizi sprintu připravuje zástupce dodavatele ve spolupráci s vlastníkem produktu. Šablona prezentace je připojena mezi Appendix A, Šablony a formuláře.

  3. 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.

  4. 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.

  5. 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.

  6. 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 Section 4.4.2, “Plánování sprintu”.

  7. 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.

  8. 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

  1. 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.

  2. 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 Appendix A, Šablony a formuláře.

  3. 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.

  4. 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.

    Matice retrospektivy sprintu
    Figure 8. Matice retrospektivy sprintu

  5. Vypracovaný výstup bude zohledněn při dalším Section 4.4.2, “Plánování sprintu”.

  6. Dílčí výstupy retrospektiv minitendru budou využity při Section 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

  1. 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.).

  2. Dodavatel připraví prezentaci spolu s případnou ukázkou služby (prezentace je vždy připojena formou odkazu rozeslané pozvánky).

  3. Vlastník produktu po dohodě se zástupcem dodavatele požádají koordinátora projektu o naplánování závěrečné prezentace.

  4. Účastníci na straně TA ČR jsou vybráni dle zaměření minitendru, zástupci dodavatelů jsou zváni vždy.

  5. Závěrečná prezentace se již nezapočítává do doby řešení minitendru.

4.4.7. Zrušení sprintu

  1. 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).

  2. 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.

  3. 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.

  4. Po zrušení sprintu následuje nové Section 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

  1. Projektový manažer organizuje dle harmonogramu dílčí realizační smlouvy průběžné přebírání a akceptaci výstupů minitendru.

  2. 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.

  3. 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í.

  4. 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 Appendix A, Šablony a formuláře).

  5. 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í.

  6. 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.

  7. 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.

  8. 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 Section 5.6, “Pravidla vedení dokumentace”. Jako vodítko použije checklist převzetí služby OPS týmem.

  9. 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.

  10. Projektový manažer zajistí elektronické podepsání akceptačního protokolu v pořadí dle bodu 3.

  11. 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.

  12. Projektový manažer odešle akceptační protokol společně s fakturou na adresu: [email protected].

5. Architektura, vývoj a dokumentace

5.1. Obecně

  1. 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 RD3).

  2. 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.

  3. 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.

  4. Architektura SISTA vychází z principů mikroservisní varianty SOA. Jednotlivé kontejnery běží na bázi linux s tím, že jejich orchestraci zajišťuje platforma Kubernetes provozovaná v Google Cloud Platform.

  5. 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.

  6. 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.

  7. 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 Section 2.2.5, “IDP tým”).

  8. 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.

  9. 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

  1. SISTA je budována a provozována jako cloud native systém. Obecná pravidla pro vývoj takového systému shrnuje manifest 12factor.

  2. 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.

  3. Architektura SISTA dále využívá koncept publish/subscribe, případně a/synchronní volání přes dapr.io service invocation.

  4. 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ší.

  5. Platforma SISTA:

    1. její infrastruktura je definovaná jako kód (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.

  6. IDP tým je možné kontaktovat prostřednictvím [email protected]. E-mailová zpráva automaticky založí tiket v interním servicedesku.

  7. Přístup ke službám může podléhat řízení přístupů viz Section 5.4, “Pravidla vývoje”.

  8. 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.

  9. 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

  1. TA ČR pro potřeby projektu SISTA udržuje v Google Cloud Platform následující běhová prostředí: TESTING, STAGING a PRODUCTION.

  2. 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.

  3. 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í.

  4. 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í).

  5. 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.

  6. DevOps týmy v pravidelných intervalech společně hodnotí naplňování očekávání kladených na platformu SISTA (srov. s Section 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

  1. Vývoj a dodávání služeb probíhá dle požadavků Section 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.

  2. Služby jsou vyvíjeny v souladu s nejlepší praxí, procesy TA ČR, závěry přijatými DevOps (srov. s Section 2.3.4, “Jednání DevOps SISTA”), ohledem na responzivitu a pravidly přístupnosti.

  3. 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.

  4. 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.

  5. 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.

  6. Po akceptaci dodávky jsou další úpravy vyvolané změnami okolních služeb implementovány již jako rozvojové požadavky.

  7. Dev tým je zodpovědný za nasazování služby na development cluster vytvoření pro účely implementace služby SISTA.

  8. 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é.

  9. 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 Appendix A, Šablony a formuláře.

  10. 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.

  11. 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

  1. TA ČR vytvořila design systém (DISTA) odvozený od Material Design.

  2. Design systém využívá soubor upravených komponent v jazyce React, který reflektuje požadavky a specifika SISTA.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

  7. 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, Penpot či Balsamiq a MUI komponent.

  8. Výběr prototypovacího nástroje závisí na účelu jeho použití. UX tým s garanty služeb při prototypování používají:

    1. SW Figma - je určen především k vytváření high-fidelity návrhů. Vzhledem ke komplexnosti nástroje a časové náročnosti vytvoření výstupů využíváme SW Figma především při mapování user flows nové/zásadně přepracované byznysové služby, definici nových/úpravě existujících DISTA komponent či prezentaci uživatelského rozhraní/chování aplikace ostatním poskytovatelům.

    2. SW Balsamiq - vzhledem k celkové jednoduchosti a nenáročnosti lze tento nástroj využívat pro rychlé vytváření low-fidelity návrhů obrazovek služby zejména pro potřeby dalšího rozvoje služby, která již disponuje UI. Výstupy prototypování lze využívat také jako podklady pro dodavatele do zadání minitendrů.

  9. 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.

  10. Interní UX tým uvede do specifikace zadání služby očekávaný soupis UI komponent s popisem jejich fungování.

  11. 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.

  12. Dev tým při tvorbě uživatelského rozhraní služby respektuje požadavky DISTA a využívá UI komponenty.

  13. 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.

  14. 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

  1. 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.

  2. 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.

  3. Na udržování sdílené dokumentace spolupracuje DevOps a celý projektový tým SISTA.

  4. 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.

  5. 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.

  6. 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.

  7. Uživatelskou dokumentaci vytváří garant služby dle definované struktury a ve spolupráci s dodavatelem minitendru. Výchozím formátem uživatelské dokumentace je .adoc, ze kterého jsou následně generovány HTML verze dokumentace pro různé poskytovatele.

  8. Veškerá dokumentace (s výjimkou např. příkazů, konfiguračních parametrů atd.) je vedena v českém jazyce viz Section 3.1, “Formální požadavky”.

6. Konvenční procesy

6.1. Řízení času

  1. 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 Section 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 Section 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ů.

  1. 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ě).

Burndown chart
Figure 9. Burndown chart - ukázka

6.2. Řízení rizik

  1. Projektový manažer udržuje prostřednictvím SW Gantter registr obecných rizik projektu.

  2. 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.

  3. 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.

  4. 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.

  5. Aktuální stav rizik je projednáván na Section 2.3.1, “Jednání řídícího výboru”.

6.3. Komunikace a výkazy projektu

  1. 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.

  2. Projektový manažer zajišťuje, aby byly jednotlivé informace snadno přístupné projektovému týmu a všem zainteresovaným stranám.

  3. 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í:

Table 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ů

  1. 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.

  2. 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.

  3. 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ů.

  4. Lessons learned prezentace je vždy uložena v adresářové struktuře minitendru.

  5. Šablona lessons learned prezentace je připojena v sekci Appendix A, Šablony a formuláře.

7. Historie verzí

Verze: 5.
Datum vydání: 09/12/2024.
Autor: Vítězslav Vlasák, TA ČR, [email protected].
Poznámka k verzi: Pravidla řízení projektu - prosinec '24.

Detailní popis změn verze 5:

  • Doplnění „lessons learned“ z průběhu druhé etapy řešení projektu SISTA za rok 2024.

  • Doplnění Archa rady a pravidel pro jednání viz Section 2.3.5, “Jednání Architektonické rady”.

  • Doplnění Archimate nezi analytické podklady pro zadání služby SISTA. Jedná se především o modelování procesů (hledisko spolupráce byznysových procesů) a struktur průřezových / byznysových služeb (hledisko struktury aplikace).

  • Aktualizace vybraných příloh handbooku SISTA.

Detailní popis změn verze 4:

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ů.

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
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

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

5

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)

5

10

Návrh řešení ve formátu AsciiDoc

4

11

Revize sprintu

4

12

Retrospektiva sprintu

4

13

Plán testování

1

14

Checklist převzetí služby

5

15

Akceptační protokol minitendru

4

16

Komunikační plán projektu

4

17

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.