02-mentor (15 března 2022) - Review » Historie » Verze 1
Vojtěch Váchal, 2022-03-15 19:34
Přidány poznámky z review
| 1 | 1 | Vojtěch Váchal | h1. 02-mentor (15 března 2022) - Review |
|---|---|---|---|
| 2 | |||
| 3 | h3. Zpětná vazba od P. Píchy na Demo |
||
| 4 | |||
| 5 | h4. Pozitiva |
||
| 6 | |||
| 7 | # dát vědět co je hotovo - proběhlo |
||
| 8 | # otevřené otázky - proběhlo |
||
| 9 | # nastřelit očekávání na příště - proběhlo |
||
| 10 | |||
| 11 | * dobře že s nima komunikujeme všichni (je vidět že na tom dělá více lidí) |
||
| 12 | * bug - dobré nastřelení řešení |
||
| 13 | |||
| 14 | h4. Negativa |
||
| 15 | |||
| 16 | * přesně specifikovat do kdy dostaneme odpověď |
||
| 17 | ** Př. Kdy uděláme další schůzku? - _Já nevím_ - Dobře, tak kdy nám dáte vědět? |
||
| 18 | ** případně že se to opozdí a bude se mezitím pracovat na něčem jiném |
||
| 19 | * co nejkonkrétnější možný výstupu !!! |
||
| 20 | ** potřebujeme další meeting, do kdy to uděláme |
||
| 21 | * dobré by bylo posílat otázky a výstupy předem aby se na to byla možno připravit |
||
| 22 | ** ne vždy je tohle možné |
||
| 23 | |||
| 24 | * *nemáme vizi - potřeba definovat !!* |
||
| 25 | ** vize chytá bussiness case - potřeby zákazníka - mimo IT termíny |
||
| 26 | ** tady trochu něco jiného |
||
| 27 | ** funkční a mimo funkční požadavky (akceptační kritéria, priority, ...) |
||
| 28 | ** není potřeba to mít nějak rozpitvaný do detailů |
||
| 29 | ** rizika, stakeholders, hrubý projektový plán, ... |
||
| 30 | ** všude možně je to popsaný - přednášky, proces, ... (~2 stránky, wiki, ...) |
||
| 31 | ** technologické nebo legislativní požadavky |
||
| 32 | ** nepsat to protože to Pícha chce, ale protože to potřebujeme v podstatě |
||
| 33 | ** to k čemu se obě strany zapisují |
||
| 34 | ** .... |
||
| 35 | |||
| 36 | * architektura, technologický scope, |
||
| 37 | ** jdeme hrozně rychle dopředu - dáváme kočár před koně |
||
| 38 | |||
| 39 | * návrh řešení |
||
| 40 | ** technologický stack a architektura je asi daná |
||
| 41 | ** potřeba naznačit, kde zasáhnout naše úkoly |
||
| 42 | ** ws zasáhnout skoro všude (db, uživatelů, ...) |
||
| 43 | |||
| 44 | * *asi přidat někam seznam požadavků (stačí ty epiky)* |
||
| 45 | * *udělat filtry na EPICy a společné tickety (tag, kategorie, ....)* |
||
| 46 | |||
| 47 | * zmapovat současnou implementaci a dostat se až na úroveň tříd klidně |
||
| 48 | ** potřeba jí mít někde zachycenou, aby se dalo definovat, co např. není potřeba |
||
| 49 | ** kultura kódu - odsazování, komentování, ... (nastavit alespoň vlastní konvence) |
||
| 50 | ** důležitější než wiki stránka architektury je spustitelná architektura |
||
| 51 | *** minimalistický prototyp |
||
| 52 | *** průstřel architekturou, aby jsme věděli, že s ní dokážeme pracovat ? (moc nevím) |
||
| 53 | *** nepřidává žádnou hodnotu |
||
| 54 | *** minimalizace rizik - že třeba nejdou zintegrovat |
||
| 55 | *** u nás to bude specifické |
||
| 56 | ** možná to udělat pro jednotlivé tasky |
||
| 57 | |||
| 58 | * můžeme zkusit projít různé projekty na redmine (news hodnocení) |
||
| 59 | * Microsoft Visio |
||
| 60 | |||
| 61 | * *přidat technologické rizika* |
||
| 62 | ** nezkušenost s Redmine, neznalost program. jazyku, ... |
||
| 63 | *** aktuální rizika jsou fajn |
||
| 64 | *** *strategie odstranění přidat* - jak zajistit aby jejich dopad nezasáhl projekt |
||
| 65 | |||
| 66 | * možná zkusit probrat se zákazníkem odstranění nějakého požadavku a místo toho vytvořit nějaký konvence nebo něco takového |
||
| 67 | ** jelikož projekt bude končit, asi nemá smysl řešit nějaký refaktoring |
||
| 68 | ** pro ně větší priorita funkce |