ASWI - Pokročilé softwarové inženýrství » ASWI 2022 » Zpracování geografických údajů v novoasyrských textech (KBS FF) - Code of Duty

h1. Reviw 1 iterace

h2. Review schůzky se zadavatelkou

h3. Positiva:

* Návrh dobrý, ujasnit si věci než začít kódit

* Prozkoumat nástroje pro skenování náčrtů

* Ujasňování nad GUI dobrý nápad

* Pozor na mimofunkční požadavky - složité dotazy apod.

* Řekli jsme co se má očekávat příště 

h3. Negativa a připomínky:

* Ideálně posílat vstupy do schůzky předem - aby měl čas se zamyslet a říct nám více připomínek

* Sdílet naše poznámky ze schůzek - minimalizuje komunikační problémy, ale není nutno

* Sdělit vizi - seřazené podle priority, co si můžeme dovolit vynechat a na co se soustředit (hlavně akceptační kritéria - nejdůležitější)

* Projít si práva - zda takhle nebo udělat role

* Pozor na CIV, kdyby neodpovídali, tak urgovat přes mentora; vyžádat si kontaktní osobu, kdyby se něco dělo, až projekt skončí; začít řešit deploy; verifikovat to, co jsme našli

* Pokud bude chtít zadavatelka beta verzi a předat skupině na testování - domluvit to s ní (aby byl feedback)

* Zeptat se na teamsech, zda mají ostatní také problém s commitama/redmine

h2. Review retrospektivy

* Měl by být někdo, kdo bude schůzky vést

* Plán schůzky dobrý nápad

* Na retrospektivě by měl někdo promítat Redmine - všichni stejný pohled

* Na všechny schůzky (standup, retro, plánování,…) je dobrý timeboxing - stanovit si čas na schůzku (pomáhá efektivitě)

* Chce retro uzavřít do procesu - dotknout se všech bodů, každý měl prostor se vyjádřit, mít užitečný výstup

* Na konci retra je fajn promítnout redminu a uzavřít issues

* Zda je rozdíl mezi issue branch a feature branch, každý bude mít svoji branch

* Visibilita pro plánování (promítání), aby to bylo sledovatelný

h3. review Plánování 2. iterace

* Filtr dobrý nápad

* Schůzky moc dlouhé

    - Připravit si co nejvíc dopředu - úkoly, příprava iterací apod

    - Na plánování řešit jen to podstatné - kolik co zabere, co dát do iterace a kdo to bude dělat

    - Due date jen když to bude nutné (vybočovat z iterace)

* Zvážit jaké používáme stavy

* Colaborators nepoužívat - místo toho hvězdička (sledovat)

* Body do poznámek ne - při vytváření by měli jít do popisu

* Moc letíme do implementace

* Zrevidovat milníky, nemáme vize, vysokoúrovňové požadavky se zákazníkem, priority, mimofunkční požadavky, ucelený dokument vize

* Podívat se co mají pokrývat první dva milníky 

h3. review 1. iterace

* Pozor na čas

    - Více času než bychom měli

    - Lehké přepálení reality vůči odhadu

* Due date nemusíme nutně řešit - jen pokud když má něco končit dřív než iterace

* Konzistentně bud notes (v komentářích) nebo komentář

* Pozor na rozložení času na celý tým

* Chybí vize - vysokour. požadavky, priority a akceptaci kritéria (co potřebujeme udělat aby nám projekt vůbec vzal) - je třeba to projít se zákazníkem

* Vysokourovnové cíle iterace

* Hrubý plán vylepšit

* Plán rizik - chce strategii odstranění rizik

* O projektu - místo zadavatelky „kontakt na zákazníka“, chce to kontakt na lidi z CIVu, koncoví uživatelé - chce je identifikovat, jde i o to okolí projektu

    - zadání: business case - co je cal

        - Mise: už jak se to provede - že webová aplikace atd.

    - Timeline - jak je projekt dlouhý (deadline), vymezení skopu (240-320 čh)

    - Rizika - zadavatelka je musí znát

* 1. milník - seznam požadavků - podívat se na asi proces co tam má být

* UI se blíží specifikaci požadavků, je to funkční, its ok

* Konvence

    - Tracker chybí testování a deploy, psaní konfiguráků apod. - kam

    - Assigned zda není zbytečné, closed víc popsat - že to kontrolujeme včetně konvencí

    - Commity a úkoly - zaznamenat že jsou propojeny commit a Redmine

* Na konci iterace další review