Nová verze Wiki právě nyní.¶

V jednotlivých stránkách iterací 0 a 1 byl doplněn popis.¶

Nově jsou tyto iterace i provázané. Takže se člověk může vrátit o úroveň výš - odkaz je vždy dole na stránce
Iterace 2 bude dodělána v závěsu a iterace 3 již bude tvořena po novu !

Co máme:¶

• Dokumentace vize, frameworky, use-case diagramy, dokumentace architektura (tak napůl, dost formálně)
• Funkční login, začátky implementace, afs přístup

Co jsme probrali:¶

• Ověřovat na redmine dokumentace? (resolved>closed)
  Ne, části dokumentace se uzavřou ihned, pouze výslednou dokumentaci někdo překontroluje a pak uzavře.

• Příprava na zákazníka.
  Ukážeme co máme již implementováno. Musíme se dotázat: Budeme jí to ukazovat nebo si to bude moci testovat sama přes testovací doménu aswi2019medici.zcu.cz? Otázky na slovník a ostatní moduly.

• Následující iterace, co bude, jak bude. Jak budeme řešit další iteraci společně s dovolenou, jak bude probíhat poker planning, kdo předplánuje tasky/enhancementy co budem probírat?
  Tasky enhancementy připraví podle user stories vedoucí týmu podle vlastního uvážení, jak bysme to mohli stihnout. Výsledné hodiny na pokerplanningu. Nesmíme to přepálit jelikož máme jen 2 týdny. Hlavní bude implementovat klíčové funkcionality (login, vyhledávání, základní administrace, minoritní editace).

• Jak to je s tím zču serverem. Jaké jsou ty detaily na databázi/přístupy na zču afs? Zabezpečení přístupů?
  Máme doménu, nemáme přístupy na databázi. Nebo zatim ani nevíme jak se s přistupy dostat na afs server, jak tam nahrávat, upravovat. Filip se do toho horlivě pustí aby to do začátku iterace bylo možno používat.

• Ostatní architektonický modely
  Zeptáme se Šaškové jestli to vyžaduje, podle nás to neni třeba. Stavíme na brownfield projektu, era diagram je ze zkušeností postačující, ostatní modely budou z bývalých zkušeností jen jako přítěž sloužit k nepřehlednosti v dokumentaci.

Průběh a stav projektu *

slušné-skvělé

• Projekt je "on track", dosažen (ale ne plně dokladovatelně) milník LOA, proces odpovídá.

Iterace *

slušné

• Cíl iterace OK vzhledem k průběhu projektu
• Retrospektiva nezaznamenaná
• Burndown -- vysvětlení: přibylo trochu práce na dokumentaci, neodhadnuto na začátku + čekání na odpvědi z CIV zdrželo další práce
• Mají zavedené customer demo přes email, schůzky se zákazníkem on demand

Technická kvalita *

slušné-skvělé

• Doc vize velmi dobře udělaný, na základě zpětné vazby z minulé schůzky, jen drobné nedostatky (kritéria úspěchu nerealistická v kontextu projektu, chybí požadavek na převod stávajících dat) -- kandidát na "vzorový artefakt"
• User stories velmi rozumně zachycené (excel, struktura), existuje jistá vazba mezi US a Vizí a Enhancements, ale není úplně systematická -- dáno genezí
• Doc arch v podstatě neexistuje, jak má arch vypadat mají v hlavách a na některých věcech ještě nejsou domluveni (fasády na modelu), ale task "vytvořit doc arch" je Closed :-/
• Vlastní struktura aplikace je dle Nette konvencí a v pořádku
• Validace arch neudělána, doufají že to bude OK
• Struktura git repo dle konvencí, OK

Postupy a praktiky *

skvělé-slušné

• Snaha odvozovat úkoly z požadavků (trasovatelnost Vize - User stories - Enhancements - Tasks), i když ne vždy systematická a úplná (key reqts ve Vize odvozeny z User stories => chybějící "převod dat" apod.), některé Enhacements jsou technické nikoli uživatelsky zajímavé
• Na vývoji dělají "všichni vše" - Kanban style přiřazování ticketů
• Použit planning poker a verifikace při resolved-closed na ticketech, oboje vnímáno jako užitečné
• Task branches s merge request/commits

Týmová dynamika a různé

• Tým funguje společně; planning poker užitečný pro vyjasnění i technických nuancí řešení. Zúročovány zkušenosti z práce (RT Soft).

Jaká byla dána doporučení

• Burndown jako námět, co řešit v retrospektivě

Průběh a stav projektu¶

• - PRI, do LCO chybí rizika, chybí celkový plán
• 0 šéf zatím větší vytížení, protože přítomný na všech schůzkách a vyřizuje admin. (mělo by se dorovnat implementací), hodnotící schůzky působí asynchronně vůči iteracím (možná díky nejasnému plánu, možná díky nepochopení principu)
• + načaté LCA, oprava většiny výtek z minula, usazené požadavky
• hodnocení: slušné -

Iterace¶

• - na příští iteraci vysoký estimate (riziko dalších přesunů - snowball effect), cíle nemožné posoudit, nejsou známy
• 0 zátěž nerovnoměrná, viz výše
• + retrospektiva odpovídá, solidní burndown, dobré odhady, přeplánování nestihnutého, náplň ok, časově rozložené
• hodnocení: skvělé -

Technická kvalita¶

• - iterace nemají cíle a due date, artefakty označené jako Vize (ani na GitHub, ani na DMS) ve skutečnosti moc Vizí nejsou (dá se poskládat z jiných dalších artefaktů)
• 0 release zatím nemá smysl (jeden commit), zadavatel požaduje dokumenty v angličtině (riziko další časové ztráty překladem)
• + rozpracované DSP, doménový model, rozpracovaná Vize (chybí rizika), (E)FREQs a tech. reqs, retrospektiva, kostra projektu, trasovatelnost, opravené vykazování času, prioritizace, přeplánování, komentování změn když třeba, heirarchie, GUI prototypy, z vynucení zadavatele vedení 2x wiki (Redmine - pro mentora, GitHub - veřejná) DMS, tagy, UC diagramy
• hodnocení: slušné +

Postupy a praktiky¶

• - plánování, přehled o fázích/milnících
• + retrospektiva, standupy, přeplánování, identifikace nutnosti lépe popisovat úkoly, demo a důsledná komunikace návrhu řešení (GUI) zadavatelům
• hodnocení: slušné

Týmová dynamika a různé¶

• + zdá se ok

Jaká byla dána doporučení¶

• v retrospektivě nebo přímo deklarovat dosažení milníku
• doplnit rizika (do Vize nebo zvlášť)
• vytvořit plán aspoň pro zbytek projektu (technické problémy a rizika ho značně ohrožují, je potřeba vědět jak moc se to projevuje; v podstatě stačí iterace s cíly a deadliny)
• prioritizovat požadavky a domluvit minimální tolerovatelnou funkčnost při dodání se zákazníkem
• pokud zadavatel nechce dokumenty dvojjazyčně, klidně psát všechny budoucí jen anglicky

Hodnocení
7¶

Průběh a stav projektu¶

• + projekt on track, časové rozložení prací, prakticky LCA (ač nedeklarováno), vyřešení/dohnání prakticky všech nedostatků z minula
• hodnocení: skvělé

Iterace¶

• 0 solidní burndown
• + adekvátní cíle, náplň, rozsah, rozložení, počet ticketů, vše dokončeno, dobré odhady
• hodnocení: skvělé

Technická kvalita¶

• - fyzicky neexistuje plán projektu (ale myšlený je dodržován), release tag
• 0 chybí prioritizace (zatím nebylo extra třeba), gapps, základ wiki
• + Vize (chybí rizika), DSP, pěkná Architektura, UC diagram, 2 arch. diagram, GUI prototyp, baseline architektury, tracebility, komentování změn, retrospektiva adekvátní (i za minulou iteraci), stručné zápisky ze schůzek, start/due date, hierarchie ticketů
• hodnocení: slušné +

Postupy a praktiky¶

• - release tag
• + standupy, zápisy ze schůzek, code review, kontroly splnění úkolu (Resolved-Closed), dodržování konvencí, beaseline architektury, odkaz na tickety v komentářích kódu
• hodnocení: skvělé -

Týmová dynamika a různé¶

• + OK

Jaká byla dána doporučení¶

• zamyslet se nad riziky (po diskuzi se zjistilo, že některé jsou roztroušené v dokumentaci, tak jen dotáhnout a někde centralizovat)
• přemýšlet o fázích/milnících
• prioritizace a vyfiltrovatelnost implementace/testování
• release tag na konci iterace
• doplnit beztak dodržované konvence Redmine

Hodnocení
10¶

Průběh a stav projektu¶

• 0 blízko PRI, lehké rozkoukávání a learning curve na Redmine, ale jinak solidní
• + v dobrém kontaktu se zákazníkem, rozjetá další iterace, plán promyšlený
• hodnocení: slušné+

Iterace¶

• - burndown schodovitý a značně overdue (možná díky pozdnímu reportování času)
• 0 ze špatné interpretace materiálů odhad dimenzován na 80h
• + retro stručná, ale odpovídá, solidní odhady, dobrá náplň a segmentace tasků
• hodnocení: slušné+

Technická kvalita¶

• - používání nadřazeného úkolu jako iterace místo verze, občas chybějící log time, zavřený úkol na 0%, přidávání výstupů úkolů jako jejich přílohy nebo poznámky, linkování commit-ticket existuje jen někde a jednostranně, neustálené používání trackeru, občas reportování "za někoho" nebo na špatný ticket
• 0 Slack, občas nekonzistentní komentování a popisy ticketů (ale aspoň něco), , použití wiki by se dalo vylepšit
• + první verze Vize (cíle, FREQs, částečně rizika, stakeholdři mimo), konvence vývoje a Gitu, tagy, kategorie, větev v Gitu, plán projektu (chybí data iterací), priority, hierarchie úkolů, related issues
• hodnocení: slušné+

Postupy a praktiky¶

• - záznamy ze schůzek (aspoň neinterních, ze standupů ve Slacku), nejednotné úložiště výstupů
• 0 retrospektiva až po review s mentorem (nezvyklé, ale opodstatnělé)
• + standupy (fyzické na přelomech iterací a když je třeba, jinak přes Slack), retrospektiva, srozumitelné konvence, timeboxing, plánování, občas plán na schůzky v popisu úkolu, rozdělení rolí
• hodnocení: skvělé-

Týmová dynamika a různé¶

• + proaktivní přístup, dotazování i mimo schůzky, vnitřní fungování, úměrnost praktik potřebám

Jaká byla dána doporučení¶

• dělat zápisy aspoň z toho, co není dohledatelné ve slacku
• retrospektiva jako vlastní artefakt (repo/DMS/wiki/wiki attachment)
• doplnit Vizi, doplnit Redmine konvence a trasovatelnost do Git
• používat verze v Redmine, významy trackeru a stavů
• diskutovány možnosti používání due date (pokud jiné než iterační) a assignee (u např. párových úkolů)
• zvážit plán nasazení - mohou z něj plynout rizika

Hodnocení
9¶

Průběh a stav projektu¶

• + 2 schůzky se zákazníkem kvůli ujasnění práce a převzetí materiálů, vyřešení problému s nástroji
• 0 kombinovaný tým se ZSWI, lehce mění nutnosti ohledně artefaktů (DSP)
• - z ASWI pohledu trochu předbíhání (návrhy před Vizí), neexistuje celkový plán
• hodnocení: slušné

Iterace¶

• + splnění všeho až na jeden přeplánovaný úkol
• 0 náplň ovlivněná smíšeným týmem
• - burndown trochu schodovitý, poměrně málo hodinové zátěžě
• hodnocení: slušné

Technická kvalita¶

• + rozdělení ticketů podle trackeru, využívání popisů ticketů a komentování změn, specifikace požadavků schválená, návrh datového modelu
• - reportování času jedním člověkem místo každý sám, neexistence retrospektivy a ani náznaku Vize, existující artefakty nezkontrolovatelné díky nedostupnosti
• hodnocení: slušné-

Postupy a praktiky¶

• + standupy (i když bez zápisů), komentování změn, přeplánování, třídění úkolů (tracker)
• - artefakty nejsou dosažitelné z Redmine (buď fyzické nebo lokálně uložené), retrospektiva, nárazová činnost ve dvou bodech iterace (viz burndown), celkové schéma fází (milníků a artefaktů)
• hodnocení: slušné-

Týmová dynamika a různé¶

• + tým zdá se funguje a dobře komunikuje

Jaká byla dána doporučení¶

• strávený čas reportovat každý sám za sebe
• ustanovit a dodržovat konvence (zvlášť kvůli smíšenosti týmu)
• zapracovat na Vizi a dělat retrospektivy
• mít artefakty dostupné z Redmine (klidně odkazem)
• používat due date (např. ale nejen pro schůzky)

Hodnocení
5¶

Průběh a stav projektu¶

• + 2 schůzky se zadavatelem
• 0 probíhá vyjednávání požadavků, kde dostali dost volnou ruku
• - celkový plán není nikde zachycen, do LCO (možná i PRI) chybí poměrně dost
• hodnocení: slušné -

Iterace¶

• + retrospektiva odpovídá, práce odpovídá situaci s nejasnými požadavky zadavatele
• 0 v "nulté" (hotové) iteraci bylo málo náplně, plán na oficiální první vypadá dobře, odhady "přefouklé" díky nejasnosti v operacích s hierarchií, schůzka je vlastně na začátku první pořádné iterace, takže burndown se nedá hodnotit
• hodnocení: skvělé -

Technická kvalita¶

• + správné první použití vazby commit-ticket, vlastní větev ve VCS, příprava struktury projektu, use case diagram, zápis retrospektivy, návrhy GUI, popisy ticketů (program schůzek), využití kategorií, hierarchie ticketů
• 0 základní wiki bez odkazů (na další stránky i ven)
• - dost práce není evidováno, změny ticketů nekomentovány, chybí i náznak Vize, artefakty nejsou pohromadě a dohledatelné, jsou na gDrive, ale bez odkazu, v Redmine není ticket na schůzku s mentorem, ukládání výstupů jako přílohy úkolů
• hodnocení: slušné

Postupy a praktiky¶

• + retrospektiva, standupy, příprava materiálů na schůzku se zákazníkem, use case, návrhy UI, trasovatelnost
• - celkový přehled o fázích, milnících a hlavních artefaktech, roztříštěnost úložiště artefatků a jejich nedosažitelnost, komentování změn, důsledné reportování času
• hodnocení: slušné

Týmová dynamika a různé¶

• + zdá se dobré
• 0 stížená situace nejasnými požadavky nutí k větší snaze a komunikaci se zákazníkem

Jaká byla dána doporučení¶

• urgovat ustálení požadavků (více verzí návrhů/častější komunikace/doptávání se na "co chybí"/atd.) a směřovat k LCO (Vizi)
• reportovat čas důsledněji, komentovat změny
• vytvořit jeden bod odkud budou dosažitelné artefakty (DMS/wiki/repo/gDrive s odkazem v Redmine)

Hodnocení
7¶

Průběh a stav projektu *

(slušné)

• správně se identifikují uprostřed fáze Elaboration
• činnosti prováděné během iterace ale neodpovídají fázi projektu, viz další bod

Iterace *

• diskrepance mezi deklarovaným cílem "Pochopení cíle projektu a potřeb zákazníka" a provedenými činnostmi (analýza konverze DB, technologií pro impl.)
• výběr backend frameworku předčasný resp bez možnosti zohlednit info z analýzy stakeholders a zpřesnění zadání, které běží až v následující iteraci
• burndown typický "collective procrastination", důvod = měli hotovo v průběhu ale úkoly uzavřeny až na konci

Technická kvalita *

• dobrá analýza front- a back-end frameworků, ale nezohledněn aspekt dlouhodobé udržovatelnosti, viz předchozí bod
• artefakty typu SQL DDL a prototyp web UI jsou udělané, ne všechny jsou v úložišti
• popisy ticketů velmi stručné ale ještě použitelné, odhady atd. vedeny v pořádku
• DMS nešikovně strukturováno podle iterací

Postupy a praktiky *

• artefakty dělají v Overleaf, proto nejsou na wiki ale v DMS - trochu overkill a kostrbatě přístupné, ale dobře udělané i po formální stránce, takže ok
• vzniklé artefakty jsou odkazovány v příslušných ticketech, správně
• plánování a odhady dělal team leader, nadhodnocené; zohlední v dalším plánování
• mají task branches + oddělené role a autorizaci pro git branches, výborně

Týmová dynamika a různé

• iterace začínají vždy další den po skončení předchozí
• jsou domluveni, že na třetí iteraci zkusí planning poker

Jaká byla dána doporučení

• tým si má vyjasnit, zda plánování N+1 iterace je činnost "v mezidobí mezi iteracemi, nebo v N-té iteraci, nebo v N+1 iteraci"

Co máme:¶

• Datový model, prototyp UI, soupis požadavků v prezentaci, funkční nástroje

Co jsme probrali:¶

• Poupravit dokumentaci projektu, nepsat tam žádné zbytečnosti (zapsaná analýza do samostatných částí a na DMS)
• Domluvení na konvenci zápisu kódu, pushování a mergování na gitlab
• Domluvení na konvenci práce s redmine issues.

Volné Tasky > developer si dá assign -> po zhotovení resolved -> jiný developer vezme k otestování
> (prošlo testováním) closed
-> (neprošlo testováním) assign zpět developerovi s popisem bugů

• Databáze a její funkcionalita - Paleček tomu porozumí a sepíše to do privátní dokumentace (nebo DMS)
• Pojedeme na dovolenou ve 3. iteraci -> přesuneme některé části implementace už do 2. iterace
• Na další schůzi se zákazníkem je potřeba si upřesnit, jestli budem přesouvat pouze konkrétní aplikaci nebo všechny na které jsou na webu odkazy (1 projekt nebo všech 5 = db peklo)
• Tuto iteraci to chce dělat hodně dokumentace (use case, specifikace, business case, atd.)
• TDD style? ne
• Dořešit poslední části v první iteraci, přeplánovat zbylé