Ú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:
-
ověření použitelnosti rozhraní stávajících softwarových řešení ISTA a IS BETA 2;
-
dosažení předpokládaného ročního období pro podrobné seznámení dodavatelů s použitými technologiemi, principy a postupy spojenými se stávajícími softwarovými řešeními tak, aby byli schopni účelně naplnit cíle RD1;
-
provedení analýz možného řešení a postupu;
-
rozhodnutí TA ČR o zvolené technologii;
-
dosažení kapacity dodavatelů RD1 pro zvolenou technologii;
-
zavedení agilního procesního rámce řízení a způsobu vývoje na straně TA ČR.
TA ČR se s ohledem na další zájem resortů o sdílení funkcionalit softwarových řešení, existenci jiných informačních systémů a potřeby datové výměny mezi nimi, požadavky na konsolidaci existujících softwarových řešení, návrh nových funkcionalit a vylepšení stávajících softwarových řešení, rozhodla pokračovat v řešení projektu SISTA.
TA ČR uzavřela dne 31. 1. 2022 s 15 dodavateli rámcovou dohodu etapy 2 (dále jen „RD2") a to na základě veřejné zakázky VZ0125322: Sdílený informační systém TA ČR - etapa 2. Vytvoření softwarového řešení SISTA bude pokračovat v intencích následujících bodů:
-
seznámení dodavatelů s dosavadními výstupy projektu SISTA formou řízeného onboardingu;
-
zavedení GCP jako technologického základu SISTA a REST API jako komunikačního rozhraní;
-
provádění analýz funkcionalit za účelem zlepšení jejich efektivity a navrhování nových funkcionalit při dodržení technologického rámce;
-
analyzování s návrhem řešení provozu funkčních vzorků a prototypů;
-
ověření předpokladů pro zavedení nových funkcionalit a nových technologií;
-
vyvíjení nových funkcionalit a zlepšení na nových technologiích;
-
uvádění technologií v produkční provoz a řešení souvisejících otázek.
Projekt SISTA v období trvání rámcové dohody č.2 dosáhl následujících výsledků:
-
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;
-
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;
-
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;
-
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;
-
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;
-
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;
-
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:
Dokument popisuje jednotlivé aspekty řízení projektu v souladu s výše uvedeným konceptuálním rámcem a je hlavním informačním zdrojem pro projektový tým SISTA/dodavatele minitendrů. Dále jsou zohledněny principy, procesy, doporučení popsaná v následujících dokumentech a standardech:
-
Informační koncepce České republiky [IKCR],
-
Průvodce světem řízení IT projektů [PrIT],
-
Bezpečnostní doporučení pro vývoj otevřeného software [NUKIB],
-
The Definitive Guide to Scrum: The Rules of the Game (November 2020) [Scrum],
-
Vybrané konvenční procesy managementu projektu dle ISO 21502:2020 promítnuté do kapitoly 6, Konvenční procesy.
|
Poznámky
|
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
-
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:
Figure 2. Organizační struktura projektu SISTA -
V organizační struktuře projektu jsou vyznačeny role vycházející z procesního rámce Scrum.
-
Scrumové týmy vznikají dynamicky dle potřeb sprintu (srov. s Section 2.2.4, “Scrumový tým”).
-
V rámci scrumového týmu již nejsou žádné dílčí týmy ani hierarchie. Jedná se o skupinu spolupracujících profesionálů zaměřenou na dosažení konkrétního cíle.
|
Řešení témat 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
-
TA ČR ustavila pro potřeby směřování projektu řídící výbor složený z těchto rolí: zástupci předsednictva, ředitele Kanceláře TA ČR, ředitelů sekcí, ředitele odboru ICT, IDP týmu, projektového manažera, koordinátora projektu a vlastníků aktuálně řešených témat.
-
Řídící výbor je vrcholným řídícím orgánem projektu, který průběžně vytváří vhodné podmínky pro úspěšnou realizaci projektu.
-
Řídící výbor při realizaci projektu:
-
schvaluje věcný a finanční rámec témat minitendrů,
-
bere na vědomí měsíční zprávu o stavu projektu ve formě prezentace,
-
rozhoduje o záležitostech, jejichž rozhodnutí není možné učinit na úrovni řízení projektu,
-
kontroluje realizaci a postup plnění minitendrů,
-
schvaluje dokumenty projektu dle Section 3.5, “Schvalování klíčových dokumentů”,
-
vyjadřuje své stanovisko k výsledku akceptačního řízení,
-
ukládá svým členům úkoly, které mohou podpořit realizaci projektu,
-
-
Pravidla jednání upravuje Section 2.3.1, “Jednání řídícího výboru”.
2.2.2. Sponzor projektu
-
Sponzorem projektu je ředitel Kanceláře TA ČR.
-
Sponzor projektu rozhoduje o klíčových aspektech projektu, neboť odpovídá za přínos pro organizaci.
-
Sponzor projektu při realizaci projektu:
-
na základě týdenních status reportů a operativních schůzek rozhoduje o směřování projektu,
-
ř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,
-
vytváří odpovídající prostředí a podporuje uplatňování dobré praxe (nejen agilního) řízení.
-
-
Je statutárním zástupcem pro smluvní záležitosti.
2.2.3. Projektový tým
-
Základní výkonný orgán projektu SISTA ustanovený interním pokynem ředitele Kanceláře TA ČR, který zajišťuje:
-
aktivní plnění projektových úkolů a dodržování dílčího harmonogramu sprintu,
-
aktivní plnění úkolů uložených sponzorem projektu nebo řídícím výborem,
-
řízení identifikovaných rizik (posuzování dopadů, návrhu odezvy apod.),
-
návaznosti na existující nastavené postupy maticového řízení. Jedná se o:
-
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),
-
metodické řízení (diskuse nad věcným zadáním řešeného tématu s metodiky),
-
programové týmy (prostřednictvím vedoucích programových týmů).
-
-
sdělování inovací a vylepšených postupů, kterých projekt dosáhl či mohl by dosáhnout, členům řídícího výboru.
-
-
Projektový tým přijímá rozhodnutí v rozsahu, který nevyžaduje rozhodnutí řídícího výboru.
-
Pravidla jednání upravuje Section 2.3.2, “Jednání projektového týmu”.
2.2.4. Scrumový tým
-
Scrumový tým (řešitelský tým):
-
jedná se vždy o menší tým[1] utvářený dle potřeb minitendru/konkrétního sprintu,
-
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,
-
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,
-
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,
-
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”.
-
-
Pravidla jednání upravuje Section 2.3.3, “Jednání scrumového týmu”.
2.2.5. IDP tým
-
IDP tým poskytuje Dev týmům Internal Developer Platform (IDP) zahrnující správu vrstev kompletního provozu technologické platformy včetně CI/CD pipelines.
-
IDP tým je 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.
-
Organizačně je IDP tvořen členy Oddělení vývoje informačních systémů Odboru ICT TA ČR.
-
IDP tým odpovídá zejména za zajištění:
-
běhových prostředí TESTING, STAGING a PRODUCTION v Google Cloud Platform,
-
šablon předpisů kontejnerů a konzultací DEV týmům při prvotních nasazeních,
-
nástrojů pro deploy do prostředí GCP a to prostřednictvím služby GitLab Pipelines,
-
pravidelných koordinací DevOps, kterých se účastní zástupci dodavatelů (Dev) a IDP týmu (Ops),
-
rozvoje platformy SISTA a souvisejících pravidel viz kapitola 5, Architektura, vývoj a dokumentace.
-
-
Pravidla jednání DevOps SISTA upravuje Section 2.3.4, “Jednání DevOps SISTA”.
2.2.6. Business analytici SISTA
-
Vytvoření týmu business analytiků SISTA vyplynulo z řešení byznysových/průřezových služeb SISTA a postupného nahrazování stávajících softwarových řešení.
-
Z pohledu řízení projektu jsou business analytici SISTA podřízeni projektovému manažerovi.
-
Tým business analytiků SISTA odpovídá zejména za zajištění:
-
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,
-
UX/UI podpůrných aktivit (interview s uživateli, prototypování v SW Figma a Balsamiq, ergonomie služeb, které mají UI),
-
spolupráce při přípravě definice funkčních/nefunkčních požadavků na připravovanou službu,
-
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í,
-
přípravu a realizaci tematických workshopů (ve spolupráci s projektovým manažerem) např. k modelování v SW Archi, AsciiDoc formátu, procesnímu rámci Scrum, PlantUML a další.
-
2.2.7. Projektový manažer
-
Pracovník jmenovaný interním pokynem ředitele Kanceláře TA ČR, který odpovídá za řízení projektového týmu a řádné plnění projektu.
-
Projektový manažer odpovídá zejména za zajištění:
-
realizace projektu v souladu s celkovou vizí a rámcovými cíli projektu,
-
komunikace vůči dodavatelům tak, aby bylo zajištěno pochopení požadavků zákazníka projektu,
-
součinnosti členů projektového týmu při realizaci sprintů a dalších projektových aktivit,
-
dodržování harmonogramu projektu/minitendrů a termínů vyplývajících z evidence úkolů,
-
konzistentní a očekávané kvality všech dodávek s navazujícími akceptacemi viz Section 4.5, “Akceptace a uzavření minitendru”.
-
-
Projektový manažer je členem řídícího výboru s hlasem poradním.
-
V kontextu agilního rámce řízení může plnit roli Scrum Mastera [2]:
-
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é,
-
zajišťuje, aby vlastník produktu věděl, jak uspořádat produktový backlog, aby maximalizoval získaný přínos,
-
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ě,
-
odpovídá za realizaci scrumových procesů – facilituje jednání, dbá na dodržování termínů a konání scrumových událostí,
-
odstraňuje překážky a rušivé vlivy, aby se scrumový tým mohl soustředit na dodání výstupů sprintu/minitendru.
-
2.2.8. Koordinátor projektu
-
Koordinátor projektu spolupracuje s projektovým manažerem a dále zajišťuje:
-
aktivní organizační podporu manažera projektu po celý životní cyklus realizace projektu/sprintů minitendru,
-
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í,
-
distribuci a vypořádání zápisu z jednání projektového týmu,
-
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ů,
-
udržování adresářové struktury projektových knihoven: Interní projektová knihovna a Projektová knihovna pro dodavatele viz Section 3.2.1, “Projektové knihovny”,
-
udržování spisů projektu SISTA v elektronické spisové službě,
-
udržování registru minitendrů uloženého v interní projektové knihovně.
-
2.2.9. Focus group SISTA
-
Focus group SISTA je složena z vybraných členů předsednictva, výzkumné rady TA ČR a společně tvoří expertní poradní orgán projektu.
-
Jednání s Focus group SISTA plánuje sponzor projektu. Projektový manažer připraví potřebné podklady pro vlastní jednání.
-
Vstupem pro jednání je prezentace témat pro Focus group SISTA s informacemi o postupu realizace či směřování projektu.
2.3. Pravidla jednání
2.3.1. Jednání řídícího výboru
-
Jednání řídícího výboru se konají pravidelně jednou měsíčně (zpravidla druhé pondělí v měsíci) bezprostředně po poradě sekčních ředitelů.
-
V naléhavých případech je možná změna termínu jednání - tato změna musí být oznámena členům řídícího výboru nejméně 2 pracovní dny předem.
-
Koordinátor projektu rozesílá odkaz na prezentaci nejpozději 1 pracovní den před termínem jednání.
-
Agenda jednání řídícího výboru:
-
odečet evidence úkolů uložených na předchozím jednání řídícího výboru,
-
celkové shrnutí hodnoceného období (objem a tempo práce, histogramy výsledků,…),
-
čerpání rozpočtu projektu za hodnocené období,
-
shrnutí jednotlivých minitendrů - aktuální stav, akceptace a případné překážky řešení,
-
eskalace otevřených bodů z řízení projektu,
-
výhled témat s odhadem finanční alokace,
-
případné návrhy rozhodnutí řídícího výboru k jednotlivým otázkám,
-
stav přípravy nových témat,
-
diskuse.
-
-
Případné další návrhy bodů pro konkrétní jednání musí být oznámeny předem, aby se členové řídícího výboru mohli připravit na rozhodnutí.
-
Jednání nebo části jednání řídícího výboru se mohou zúčastnit i další osoby. Takové osoby se však nepodílí na rozhodování řídícího výboru a musí být známy před jednáním.
-
Řídící výbor přijímá rozhodnutí konsensuálně, tj. shodou všech přítomných členů. V odůvodněných případech je možné přijmout rozhodnutí per-rollam s dodatečným potvrzením rozhodnutí.
-
Zápis z jednání řídícího výboru je do 2 pracovních dnů následujících po jednání rozeslán k připomínkám a do 5. pracovního dne následujícího po jednání uzavřen.
-
Finální zápis je uložen v adresáři příslušného jednání řídícího výboru a ve spisové službě.
Šablona zápisu je připojena v přehledu Appendix A, Šablony a formuláře.
2.3.2. Jednání projektového týmu
-
Jednání projektového týmu probíhá pravidelně každé pondělí od 9:00 hod.
-
Projektový manažer připravuje jednotlivé body jednání k projednání projektovým týmem:
-
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ů,
-
zpětná vazba z koordinace projektu SISTA se zástupci dodavatelů,
-
odečet postupu řešení sprintů (minitendrů),
-
kontrola evidence úkolů projektu nad rámec běžících sprintů,
-
ostatní operativní témata k řízení projektu a podněty projektového týmu.
-
-
Koordinátor projektu bezprostředně po jednání rozesílá odkaz na zápis k připomínkám. Členové projektového týmu jej do 2 pracovních dnů připomínkují.
-
Finální zápisy jsou uloženy v adresáři: 02. Projektový tým SISTA projektové knihovny.
-
Koordinátor projektu uloží kopii zápisu ve formátu PDF do adresáře: „PDF verze pro tisk” a příslušného spisu v elektronické spisové službě.
Šablona zápisu je připojena v přehledu Appendix A, Šablony a formuláře.
2.3.3. Jednání scrumového týmu
-
Jednání scrumového týmu probíhají podle potřeb každého sprintu a jsou organizována vlastníkem produktu.
-
Požadavek na každodenní koordinaci scrumového týmu (Daily Scrum) je aplikován přiměřeně.
-
Dodavatelé aktuálně běžících minitendrů mají k dispozici pravidelné koordinace na konci týdne (max. 15 minut na minitendr) s projektovým manažerem.
-
Z úrovně řízení projektu jsou akceptovány jakékoliv flexibilní nástroje komunikace, které nebudou omezovat dodávku přírůstku sprintu. Vycházíme z předpokladu, že je v zájmu obou stran dodat přírůstek v požadované kvalitě a dle harmonogramu.
-
Vlastník produktu je povinen zaznamenat realizované konzultace prostřednictvím strukturované tabulky Google pro záznam jednání, která je po celou dobu trvání řešení minitendru sdílena s „tacr-external” účtem dodavatele.
-
Projektový manažer může dle aktuálního stavu řešení minitendru pravidla vedení dokumentace scrumového týmu upravit.
|
Dobrou praxí pro týmovou komunikaci v rámci scrumového týmu je používání Spaces v prostředí Google Chat, které kromě klasického chatu podporují připojení souborů a jednoduchou správu úkolů. |
2.3.4. Jednání DevOps SISTA
-
Jednání DevOps SISTA probíhá pravidelně v intervalu 1x14 dní za účasti zástupců IDP týmu a dodavatelů s tím, že věcnou náplní těchto jednání jsou výhradně otázky týkající se technické stránky řešení SISTA s vyloučením jakýchkoliv zásahů do byznys části služeb.
-
Jednání DevOps SISTA organizuje a řídí vedoucí oddělení vývoje IS.
-
DevOps SISTA přijímá rozhodnutí konsensuálně s cílem dosažení nejlepšího možného řešení ve prospěch DevOps/projektu SISTA.
-
DevOps SISTA z pohledu přínosů zajišťuje:
-
řešení identifikovaných incidentů napříč službami SISTA,
-
koordinaci nasazení služeb na STAGING a PRODUCTION prostředí,
-
diskuzi a výběr nejvhodnějších variant řešení napříč všemi dodavateli,
-
rozvíjení služeb platformy, pravidel architektury, vývoje a vedení dokumentace.
-
-
Vedoucí oddělení vývoje IS vypracuje a rozešle z jednání DevOps SISTA zápis, který je připojen k události.
-
Vedoucí oddělení vývoje IS má pravomoc po dohodě s Dev týmy a projektovým manažerem upravovat termíny/četnost jednání DevOps SISTA dle aktuálních potřeb řešení projektu.
2.3.5. Jednání Architektonické rady
-
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.
-
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í.
-
Jednání Architektonické rady SISTA organizuje a řídí ředitel Odboru ICT.
-
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.
-
Architektonická rada SISTA z pohledu přínosů zajišťuje:
-
návrhy na implementaci technologických změn architektury,
-
řízení architektury SISTA týmem IDP (platformou SISTA),
-
diskuzi a výběr nejvhodnějších variant řešení napříč všemi dodavateli,
-
ř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.
-
Ředitel Odboru ICT vypracuje z jednání Architektonické rady SISTA zápis, který je připojen k události.
-
Ř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.
|
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.
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.
|
Poznámky
|
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ě.
|
|
3.1. Formální požadavky
-
V souladu s podmínkami zadávací dokumentace nadlimitní veřejné zakázky je veškerá komunikace k řešení minitendrů mezi zadavatelem a dodavateli vedena v českém jazyce.
-
Při vytváření dokumentů používají týmy takové typy fontů, které zajistí korektní zobrazení napříč běžně používanými operačními systémy (Titillium Web[4], Open Sans, Roboto a naopak zcela nevhodné jsou fonty: Calibri, Cambria či další proprietární fonty).
-
Scrumové týmy sdílí dokumentované výstupy projektu - pokud to jejich charakter umožňuje - prostřednictvím Google Workspace. Klíčové výstupy budou na titulní straně opatřeny jednoduchou tabulkou obsahující informace o historii posledních dvou verzí viz příklad:
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.
-
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” (
). -
Názvy souborů v projektové knihovně vystihují jejich obsah, nepřípustné jsou výchozí názvy typu „Tabulka bez názvu” nebo „Dokument bez názvu”. Doporučujeme do názvu souboru doplnit jako prefix číslo řešeného minitendru.
-
Výstupy minitendru vytvářené ve formátu AsciiDoc mají ze strany projektového týmu TA ČR vždy předem určenou strukturu, kterou dodavatel respektuje a nadbytečně nerozšiřuje.
-
Pokud je nutné zaslat soubory e-mailem, uživatel doplní do názvu souboru datum poslední úpravy (např.
handbook-SISTA-2024-12-05.zip
,MT090-definice-pozadavku-2024-12-05.pdf
,…). -
Finální dokumenty (hodnocení návrhů řešení, akceptační protokoly, akceptované výstupy a další dokumenty) jsou v souladu s interními pravidly [RAD-07] ukládány do elektronické spisové služby.
Dokumenty ve formátu AsciiDoc budou vždy obsahovat hlavičku v minimální struktuře:
-
Základní a uživatelské atributy:
// Hlavicka dokumentu
= MTXYZ Nazev minitendru : specifikace dokumentu :author: Jméno a příjmení autora, Název dodavatele :email: e-mail autora dokumentu :revnumber: 1 :revdate: dd/mm/yyyy :revremark: Stručná charakteristika verze. :pdf-themesdir: resources/themes :pdf-fontsdir: resources/themes/fonts :pdf-theme: brand-tacr :pdf-page-layout: portrait :doctype: book/article
:encoding: utf-8 :lang: cs include::locale/attributes.adoc[] :toc-title: {toc-title} :toc: left :toclevels: 4 :sectnums: :xrefstyle: full :table-stripes: even :experimental: :chapter-signifier: :chapter-refsig: {chapter-signifier} // Uživatelské atributy :templateID: T-XYZ :document-classification: Neveřejný :discarding-symbol: :retention-period: :Custom_1: TACR/XX-YY/2024 :Custom_2: {doctitle} :Custom_3: {output-generated} : {docdatetime} :keywords:
-
Historie změn:
// Na konci dokumentu == Historie změn[%hardbreaks] Verze: {revnumber} Datum aktualizace: {revdate} Autor: {author}, {email} Poznámka k verzi: {revremark} '''' [underline]#Popis hlavních změn verze 1:# * Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
-
Minimální atributy hlavičky AsciiDoc dokumentu.
-
Typ dokumentu - rozdíly popisuje uživatelská dokumentace AsciiDoc.
-
Historie změn uvedená jako samostatná kapitola nebo prostřednictvím funkce include vložený
adoc
.
|
|
3.2. Ukládání dokumentů projektu
3.2.1. Projektové knihovny
-
Za účelem ukládání dokumentů souvisejících s realizací projektu byly zřízeny dva sdílené disky Google a GitLab repozitáře pro jednotlivé služby SISTA:
-
Interní projektová knihovna - strukturované úložiště pro potřeby projektového týmu.
-
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ů.
-
GitLab repozitář projektu SISTA - strukturované úložiště zdrojových kódů a související dokumentace viz kapitola: 5, Architektura, vývoj a dokumentace.
-
-
Koordinátor projektu spravuje strukturovaný Přehled předané dokumentace, který je uložen v projektové knihovně pro dodavatele.
-
Primárním úložištěm dokumentů souvisejících s řešením minitendru je interní projektová knihovna spravovaná koordinátorem projektu a projektovým manažerem.
-
Vlastníci produktů si sami organizují obsah adresáře projektové knihovny každého sprintu a odpovídají za dodržování pravidel administrace projektu.
-
Řešitelé minitendrů mají do adresářů projektové knihovny přidělena přístupová práva. Sdílení souborů se zástupci dodavatelů mimo účty domény „tacr-external.cz” je zakázáno.
-
Při uzavření minitendru provedou koordinátor projektu ve spolupráci s vlastníkem produktu revizi přístupových práv a dle potřeby ponechá/odebere přístupy z domény „tacr-external.cz”.
-
Pro každou vyvíjenou službu existuje vždy samostatný GitLab repozitář a řešitel je povinen vyvíjet proti tomuto repozitáři. Další požadavky upravují Section 5.4, “Pravidla vývoje” a Section 5.6, “Pravidla vedení dokumentace”.
3.2.2. Adresářová struktura MT
-
Koordinátor projektu odpovídá za vytvoření adresářové struktury nového tématu v interní projektové knihovně. Závazná struktura je uvedena na následujícím obrázku:
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ů
-
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
.
-
-
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 jePDF
,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:
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 |
Elektronická |
Proj. knihovna Spisová služba |
4. Realizace minitendrů
4.1. Typy minitendrů
-
TA ČR za účelem efektivního řešení projektu SISTA vymezila níže uvedené typy minitendrů (čl. 1, odst. 1 RD3):
-
analytické a konzultační - zaměřené na získání jednoho výstupu, tj. analýz či pořízení služby konzultací,
-
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;
-
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;
-
ostatní.
-
|
Poznámky
|
4.2. Příprava zadání minitendru
4.2.1. Určení vlastníka produktu
-
Uvažovaná témata minitendrů jsou řídícím výborem projednána, schválena a stávají se pro projektový tým závazná.
-
Projektový tým témata postupně odebírá dle kapacitních možností a s přihlédnutím k aktuální situaci na projektu.
-
Projektový manažer po diskusi se sponzorem projektu a projektovým týmem určí vlastníka produktu spolu se závazným termínem pro vypracování zadání.
-
Vlastník produktu:
-
Definuje a následně také srozumitelně sděluje produktové cíle („kam se chceme prostřednictvím přírůstků SISTA posunout”);
-
Má jasnou vizi a představu o budoucím směru řešeného tématu;
-
Zodpovídá za maximalizaci hodnoty produktu, který bude vytvářen;
-
Zpravidla nedisponuje znalostmi technologií, avšak ovládá doménu byznysu agentury;
-
Zná regulatorní mantinely, ve kterých se zvolené řešení musí pohybovat;
-
Rozumí současné implementaci tématu v ISTA nebo IS BETA 2;
-
Zná požadavky zainteresovaných stran.
-
|
Tipy
|
4.2.2. Analýza a definice požadavků
-
Vlastník produktu před vypracováním věcného zadání minitendru analyzuje současný stav řešené agendy za účelem návrhu nových funkcionalit či zefektivnění stávajících funkcionalit. Z analýzy současného stavu vzniká jako součást výzvy k podání návrhu řešení tzv. „definice požadavků“ na budoucí službu.
-
Vlastník produktu doplní k definici požadavků hledisko spolupráce obchodních procesů (Business Process Cooperation) a hledisko struktury aplikace (Application structure). Jedná se o specifické archimate modely vytvořené prostřednictvím open-source Archi.
-
Hledisko obchodních procesů obsahuje:
-
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.
-