Reviw 1 iterace¶

Review schůzky se zadavatelkou¶

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ě

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

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ý

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

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