Nutno zrekapitulovat, co se tuto iteraci nestihlo a proč? Přesunutí na další iteraci¶

Odložené aktivity na iteraci 04¶

• 1. Studium a nasazení kontraktových testů

• V rámci vytváření autentizační aplikace a zprovoznění komunikace muselo být odloženo nasazení a studium kontraktových testů.
• Důvod: Jako vedoucí týmu jsem rozhodl, že není důležité mít nasazení kontraktových testů za cenu nedodělání registrování, přihlášení a autentizaci requestů.

• 2. Mírné narušení Definition of Done pro uzavření aktivit

• U autentizační služby nebyly napsány jednotkové testy z důvodu časového presu. Služba byla zatím testována ručně a na vytvoření testů byla vytvořena aktivita, která bude přidělena na iteraci 04
• Toto narušení není nikterak kritické vzhledem k tomu, že jsme jako tým prolomili velice složitou problematiku, kterou jsme ještě využili na jiné úrovni využití než je základní (autentizaci pomocí jiné služby).

Co se naopak stihlo a jsme na to pyšní? :)¶

• 1. Prolomili jsme poměrně složitou problematiku (bezpečnostní) na prvotní naučení a správné použití. Jako tým jsme vytvořili funkční autentizaci, kterou je sice nutné doladit, ale je funkční! Zbytek už by měl být snažší.
• 2. Vedli jsme širokou diskusi na téma bezpečnosti v síťovích aplikacích (nejen na úrovni aplikační vrstvy, ale i částečně na nižších vrstvách - servery samotné).
• 3. Vytvořili jsme základní strukturu webového rozhraní (SPAWn - reactJS), u které umíme již do systému registrovat uživatele, přihlásit je a je připraveno ze strany SPADe -> Auth. i odhlášení uživatele (zneplatnění JWT tokenu).
• 4. Petr Š. dokázal najít způsob, jak využít ve SPADe aplikaci více databází najednou. MS SQL Server se bude využívat zatím pouze pro SPAWn aplikaci a její správu, MySQL zatím zůstane na SPADe jakožto datová pumpa pro anti patterny apod.
• 5. !!!! Možná i dosažení LCA milníku? Nadefinování infrastruktury a architektury
• 6. Máme spustitelné demo s ukázkou autentizace. Všechny tři aplikace komunikují mezi sebou (SPAWn -> SPADe -> Auth) <=> (Auth -> SPADe -> SPAWn)
• 7. Máme poměrně robustní a udržovanou wiki.
• 8. !!! ODDĚLENÍ PROJEKTŮ DO SAMOSTATNÝCH REPOZITÁŘŮ !!!

Problematické úkoly v iteraci¶

• Autentizace -> velice těžká činnost vzhledem k subjektivnímu pohledu na náš projekt. Museli jsme studovat spousty návodů a konvencí, jak takovou problematiku řešit a to postupně experimentálně zkoušet na našem projektu. Museli jsme z tohoto důvodu i odložit méně důležité aktivity na další iteraci. Poprali jsme se s tím ale dobře.

Pocity členů týmů¶

• GLAD

• ALL: Hodně jsme programovali a naučili jsme se spoustu nových věcí ohledně bezpečnosti u síťových aplikací na aplikační vrstvě.

• SAD

• ALL: Přístup javy na bezpečnost je pro začátečníky velice složitý a návody jsou nejednoznačné. Návody nekompletní a ani jeden z nich neřešil naší konkrétní situaci z 95 %. Museli jsme na pomoc využít chat GTP a experimentovat.

• MAD

• ALL: Velikonoce jsme si neužili. Naše odměna byla Java. Za těch pár dní jsme vykázali každý přes 30 hodin (: (: A máme pytle pod očima.

Výsledek retrospektivy. Co zlepšit do dalších iterací?¶

• 1) Administrativně u vedení projektu není nic, co bychom z našeho výsledku mohli změnit. Zásek na aktivitě byl způsoben z důvodu neznalosti a potřeby robustního samostudia pro prokopnutí technologie. Zabránit by se tomu úplně nedalo, pokud bychom si na pomoc nepřivzali odborníka ze Spring Boot Security oblasti.

• 2) Uměli jsme se dynamicky rozhodnout na scopu projektu pro tuto iteraci a odložili jsme méně prioritní věci za více prioritní.

• 3) Nestihla se ale úprava technické dokumentace. Možná by bylo fajn to dokumentovat průběžně a nedohánět to pak na poslední chvíli.