Redmine

Hodnocení
12 (za každou iteraci)¶

Malus/Bonus¶

n/a

Doporučení¶

• podnětná diskuze o ASWI procesu, midterm výměně zkušeností a přidané hodnotě předmětu pro tým
• je-li motivace, zkusit si najít a vyzkoušet pokročilejší techniky Agile, Kanban, DevOps, cokoli jiného

Průběh a stav projektu¶

• pozitiva
  • 80% FREQs implementováno
  • nastupuje testování
  • IOC v příští iteraci
  • komunikace, koordinace a řízení skvělé
  • zapracován i minimální feedback z minula
  • lehká úprava požadavků na základě domluvy se zákazníkem (něco není potřeba, CR, atd.)
  • project on track
• hodnocení: skvělé 3

Iterace¶

• pozitiva
  • retrospektivy relevantní a identifikují SPI (viz Postupy a praktiky)
  • cíle splněny, náplň a scope ok
  • iterace 3
    • burndown ok (v rámci možností Redmine)
    • odhad 10/46 podhodnocení, ale řešeno v retrospektivě
  • iterace 4
    • zlepšení odhadů (viz retro)
    • burndown pěkný - tlačený vědomou návazností úkolů
  • plán na iteraci 5 - scope a náplň ok
• hodnocení: skvělé 3

Technická kvalita¶

• negativa
  • drobné chybky ve správě ticketů (progress bar, kategorizace)
• pozitiva
  • speciální branch na úpravu designu
  • úprava konvencí pro exception handling a design branch
  • feature branche
  • trasování commit-ticket
  • iterační + milníkové tagy (zpětně dodělány i minulé)
  • použití priorit, detialních popisů a komentářů ticketů
  • kategorie na rozlišení impl vs. test
  • návaznosti ticketů
  • CI/CD + test coverage (na základě midtermu)
• další komentáře
  • testových úkolů moc nebude, protože unit a integrační testy se dělají v rámci implementačních úkolů
• hodnocení: skvělé 3

Postupy a praktiky¶

• pozitiva
  • na základě retrospektiv (SPI)
    • větší segmentace tasků a příprava předem pro přesnější odhady (zabralo)
    • úprava designu (včetně nastaveného procesu - vlastní branch, přesně definované povolené úpravy, aby nerozbily rozhraní, popsáno v konvencích)
    • sledování návaznosti tasků přes gantt
    • společné code review asigneeho a reviewera na callu místo předávání výstupů tam a zpět (u významných feature, reviewer v description)
  • SPI i v zápisech standupů
  • verifikace klíčové funkčnosti zadavatelem
  • scope/priority diskuze se zadavatelem s konkrétními výstupy (tým identifikoval správně, co zákazník vlastně nevyužije, nepotřebuje)
  • Change Request přad 3 dny -> změnové řízení, bude zanešen do DSP, správně olabelován v Redmine
  • evoluce designu na základě implementace ve 3. iteraci
  • iterační poznámky zachycují evoluci produktu a jednotlivá rozhodnutí + návaznost na FREQs
  • update risk listu
  • změna DSP (a Vize) podle vývoje požadavků - pro udržení konzistence trasování
  • update plánu na základě změn scopu po dohodě se zadavatelem
  • pěkné/užitečné zápisy z demo a standupů (včetně předepsaných šablon, stejně jako retro)
• hodnocení: skvělé 3

Použitý proces¶

ASWI std+ (vylepšení o code review cally, šablony zápisů, test coverage v CI/CD, návaznosti úkolů a další droná vylepšení)

Datum schůzky¶

26.4.2021, 3.+4. iterace

Hodnocení¶

7 bodů

20.4.2021

Doporučení¶

• -

Průběh a stav projektu¶

• práce na refactor paralelně s úpravami a rozšiřováním => ukončení refactoru se posunuje na budoucno
• demo na konci iterace, zadavatel na základě předvedeného návrhy “co změnit”
• odchod kolegy Pizúra neovlivnil projekt, jen nebudou dělat fčnost navíc
• chystají na 4.it testovací protokol a doc arch

pozitiva

• hladké pokračování prací i přes zmenšený tým
• první viditelné výsledky, zákazník viděl

negativa

• stále oficiálně neuzavřen LCA milník, přestože už dávno běží implementační práce v plném rozsahu - diskutováno, dosažení LCA není podmíněno komplet refactoringem
• čím veden refactor: analýza kódu a následně snaha upravit aby odpovídal OO a nějakému “rozškatulkování” (dekomozici), cílový stav nebyl ale dopředu specifikován (odpovídalo by LCA v tomto projektu)

další komentáře

• dosud strávený čas: 151 hodin (30-40h času čistě na refactorování)

Hodnocení: slušné (2b)

Iterace¶

• 2 týdny, průběh standardní vč. demo a retrospektivy
• cíl iterace dobrý, dosažen
• burndown tvar “collective procrastination”, diskutovány příčiny -- zadávání stráveného času až na konci při uzavírání ticketu, a uzavírání ticketů až na konci iterace, nicméně práce průběžné (viz např. commity v průběhu); změna plánování ticketů (viz retrospektiva) by se měla projevit i na burndown

pozitiva

• práce dokončeny a iterace uzavřena
• retrospektiva užitečná (mj. “lepší rozvržení tasků do subtasků”)

negativa

• uzavření iterace není vidět v git; udělán merge commit během review
• úkoly - je jich málo (7ks) a příliš hrubá granularita a obtížně odhadovatelná pracnost (bugfixing, refactoring) => nesedí odhady na úkolech a iteraci (35h est vs 43h spent), řešili na retrospektivě

Hodnocení: slušné (2b)

Technická kvalita¶

• hlavní artefakty víceméně beze změn - Vize souhlasí (zadavatel nic nového nechce), Architektura neřešena (viz výše) a dokument chybí
• kód bude ještě revidován J.Vańkem tech konzultantem

pozitiva

• konvence domluveny před 3.it , zapsány a používány
• zřetelný git pattern “iteration branch, merge na main branch”
• iterační backlog vcelku ok (priority, struktura)

negativa

• žádná specifikace požadavků a návrhová/technická dokumentace
• žádné testy na provedené úpravy
• granularita úkolů viz výše + nepoužívány Enhancement/Feature typy úkolů -- diskutováno
• pořád není propojení ticket-commit, z commit msg není poznat, k jakému úkolu se práce váží

Hodnocení: slabé (1b)

Postupy a praktiky¶

• zčásti intuitivně ale zlepšuje se (viz konvence, retrospektiva)
• demo na konci iterace -> návrhy úprav od zákazníka -> odhad pracnosti nedělali, nejsou to velké věci
• odhad času zadává Zhanel podle své úvahy, někdy ostatní dávají podklady v diskusi; ostatní mohou zadané modifikovat -- použitelné byť ne nutně ideální, diskutováno v souvislosti se závěrem z retrospektivy

pozitiva

• retrospektiva start/stop/continue s pomocí Retrotool, slušně provedená (viděl jsem) nicméně příště diskutovat nad náměty, kde není shoda
• použit github pull req pro práce na iteraci, s integrací (merge) do main branch - vcelku přehledné, akorát merge po 3.it nebyl proveden včas
• zápisy schůzek se zákazníkem: během schůzky discord, na konci rekapitulace a odsouhlasení Johnem, pak zápis na wiki pro tým (neposíláno zákazníkovi), funkční

negativa

• branches “po lidech” -- diskutováno, přepnou na “feature/task branch” na základě přednášky
• konvence “Vedoucí tymu na konci každé iteraci nastaví statusy z RESOLVED na CLOSED.” jen formálně odklikáváno (po notifikaci o dokončení úkolu přes discord), zčásti vynuceno nastaveným Redmine workflow -- diskutováno
• stále žádné stopy po QA aktivitách

Hodnocení: slušné (2b)

Hodnocení
8¶

Malus/Bonus¶

n/a

Doporučení¶

• retrospektivě dát řád/proces, využít tool (RetroTool, Google Doc - průběžné shromažďování individuálních poznámek) + inspirovat se nějakou ze šablon:
  • Start, Stop, Continue | Glad, Sad, Mad | Sailboat | The 4 L’s = Liked, Learned, Lacked, and Longed for | Good, Bad, Ideas, Actions
• zvážit použití Excel tabulky (aut. sumy) popř. Word jako odrážky (lze vyjádřit priority, due date, návaznosti úkolů) oproti tabulce pouze s odhady a assignee
• v tuhle chvíli plán teoreticky stačí na budoucí iterace (3)
• konvence jsou pěkné, ale nebrat jako neměné - dodržovat -> monitorovat, jestli pomáhají, kdyžtak změnit
• obecně je nyní třeba větší zaměření na produkt - některé administrativní věci mohou jít stranou, nebo být víc lightweight, ale úvaženě!!!, aby byl projekt stále řiditelný

Průběh a stav projektu¶

• negativa
  • není plán - nejde úplně posoudit, že projekt je tak, kde by měl být
• pozitiva
  • tah na LCA
  • komunikace ok
  • reakce na připomínky z minula - zlepšení v praktikách atd.
  • obecně ještě vládne trochu chaos z hlediska opravdového řízení projektu, ale vše se zlepšuje a instinkty fungují dobře
  • naplánované LCOA demo
  • postupné dohánění restů a velký scope iterací -> zamezuje snowball efektu, od 4. iterace se předpokládá už "normální stav"
• hodnocení: slušné 2

Iterace¶

• negativa
  • retrospektivě chybí "big picture" a řídící proces
  • na wiki chybí zápis ze včerejší retrospektivy
• pozitiva
  • retrospektiva (procházení issues) odhalila problémy - navržené SPI
    • víckrát si zavolat
    • restrukturalizace wiki + zápisy rozhodnutí
  • odhady na průměru výborné (po odečtení nedodělků)
  • dělba práce
  • burndown (navzdory všemu) ucházející
  • náplň ok
  • plán na další iteraci - 65h (díky přeplánovaným), náplň odpovídá
• další komentáře
  • velký scope (80+h) -> 4 úkoly přeplánovány
• hodnocení: slušné 1,5

Technická kvalita¶

• negativa
  • iterační tag (plánovaný, v konvencích, čeká se na merge)
• pozitiva
  • ex-post dobře technicky zvládnuté přeplánování úkolů
  • trasovatelnost v repository + branche
  • od 3. iterace používání priorit
  • hierarchie ticketů
  • konvence
  • úprava Vize
  • zápisy schůzek
  • načatá Architektura - top level pohled (server), class diagram, datový model, interfaces, parrser
    • TBD - klient + komunikace
• hodnocení: slušné 2

Postupy a praktiky¶

• negativa
  • plánování formou Word tabulky se zdá nejméně efektivní možnost
• pozitiva
  • CI/CD analysis
  • (zatím stručný) popis minimal viable product
  • poptávka na pomoc s Azure/Unity CI/CD
  • plánování už zohledňuje součty
  • domluvený speciální meeting na probrání způsobů testování
  • tématické meeting (0 assignee)
  • konvence - workflow, priority, tracker, kategorizace logtime, repo, code, wiki
• hodnocení: skvělé 2,5

Použitý proces¶

ASWI std + vlastní business case

Datum schůzky¶

20.4.2021

Hodnocení
9¶

Malus/Bonus¶

n/a

Doporučení¶

• při rozhodování, co ještě zahrnout do Architektury se nechat vést 1) kostrou implementace, 2) potřebami (co je třeba domluvit, aby to šlo kvalitně realizovat), 3) inspirací ze seznamu UML diagramů, apod.
• rozspecifikovat požadavky
• zvážit, jestli nemá smysl rozdělovat implementační a testovací tasky

Pruběh a stav projektu¶

• negativa
  • iterace rozplánované ale bez cílů
• pozitiva
  • komunikace, spolupráce
  • PRI (Vize jen neschválená zákazníkem) + dobře nakročeno na LCOA
  • přípravy na věcnou stránku skvělé
  • aktivní repository
  • rozdělení kompetencí - řízeno (kompetentně) šéfem z ASWI
• další komentáře
  • plán do jisté míry není možný/vhodný, protože jde o částečně průzkumný projekt a věci se mohou dost měnit
  • plán bude přesto vytvořen v další iteraci
• hodnocení: skvělé 2,5

Iterace¶

• negativa
  • přepálený odhad
  • několik věcí se nestihlo
• pozitiva
  • retrospektiva pěkná (identifikuje jednotlivé problémy a navrhuje konkrétní řešení)
  • náplň, splnění cílů, rozsah (estimate) ok
  • dobrý plán na další iteraci (zapůjčení VR)
  • burndown není nejlepší, ale je to díky Redmine (historie vykazování času to prokazuje), bez toho by byl výrazně lepší
  • "nedotažené" úkoly uspokojivě vysvětleny
• hodnocení: slušné 2

Technická kvalita¶

• negativa
  • chybí release tag
• pozitiva
  • správný postup přeplánování úkolů
  • wiki stručná, ale pokrývá potřeby a odpovídá kontextu projektu
  • tracker jen task/bug, další kategorizace přes tagy
  • feature branche, trasování ticket-commit
  • celkový digram architektury (zatím na gapps, mimo Redmine) + návrh komunikačního protokolu + analýza vykreslování křivek jako začátek popisu návrhu
• hodnocení: skvělé 2,5

Postupy a praktiky¶

• negativa
  • požadavky se nezdají příliš specifikované
• pozitiva
  • víc lightweight verze praktik (ne přímo procesu) vzhledem k velikosti, složení týmu a nátuře projektu
  • konvence Git (včetně zacházení s větvemi a mergi), Redmine (kategorizace, workflow)
  • vnitřní rozhodnutí nechávat zápisy/výstupy i jako přílohy ticketů (není standard, ale zdůvodněno a prospívá)
  • weekly standupy
• další komentáře
  • o věcech se obecně přemýšlí, občas chybí "rozhodnost", instinktivně se jedou věci, které mají smysl
• hodnocení: slušné 2

Použitý proces¶

ASWI std

Datum schuzky¶

13.4.2021

Hodnocení
10¶

Malus/Bonus¶

n/a

Doporučení¶

• je možné (ne nutné) navrhnout vlastní návrhy na další požadavky/vylepšení produktu -> jednání se zákazníkem o prioritách a případné změně scopu
• rozmyslet a přidat do konvencí schéma kategorizace úkolů alespoň na vývoj, test, bugfix vs. zbytek

Průběh a stav projektu¶

• pozitiva
  • našlápnuto na LCOA
  • tým funguje, komunikace ok, dělba práce
  • žádné výrazné problémy, vše podle plánu
  • reagováno na většinu feedbacku/výtek z minula
• hodnocení: skvělé 2,5

Iterace¶

• pozitiva
  • cíle dosaženy, retrospektiva to reflektuje
  • plán další iterace -> LCOA + část implementace
  • náplň, rozsah, odhady přesné
  • vykázání času včas
• další komentáře
  • burndown neodpovídá včasnému vykazování díky
    • Redmine odečítá v grafu až při zavření úkolu a
    • podle konvencí se zavírá na retro a
    • retro bylo až po demu, několik dní po konci iterace
• hodnocení: skvělé 3

Technická kvalita¶

• negativa
  • ve Vizi nejsou rizika a koncoví uživatelé
  • chybí release tag
• pozitiva
  • Vize jinak v pořádku
  • detailní a dobře čitelné zápisy schůzek včetně odkazů na úkoly
  • feature branche, trasování commit-ticket
  • Návrh systému (architektura) - celkový pohled a data - jednoduché, ale vzhledem k charakteru projektu zřejmě stačí
  • description, komentáře ticketů (i ostatní atributy používány kompetentně - s výjikou kategorizace)
• hodnocení: slušné 2

Postupy a praktiky¶

• negativa
  • k myšlence Code review chybí v konvencích, jak se rozliší dokončené úkoly od zkontrolovaných
• pozitiva
  • pěkné konvence na Redmine, Git, komunikaci i vývoj
  • nastavený systém na Code Review
  • weekly standupy
  • zlepšené vykazování
  • propojení wiki (např. proklik z plánu projektu na detaily iterací)
• další komentáře
  • akceptační kritéria = všechny požadavky -> prostor pro change requesty
• hodnocení: skvělé 2,5

Použitý proces¶

ASWI std

Datum schůzky¶

13.4.2021

Hodnocení
5¶

Malus/Bonus¶

n/a

Doporučení¶

• feedback mentora na průběh retrospektivy a plánování doženeme příště
• zvážit wiki stránku jako výstup retrospektivy a plánování (popř. u druhého rovnou tvořit do ticketů) - lépe upravitelná forma, menší režie
• při demu promítat a řídit schůzku

Průběh a stav projektu¶

• negativa
  • dlouhá nultá iterace (výběr open dat a formování business casu)
  • chybí plán projektu
• pozitiva
  • PRI (- plán)
  • místy vlastní poučení ze zkušeností a dobré reakce na dílčí prolémy
  • komunikačně ok
• hodnocení: slabé 1

Iterace¶

• negativa
  • retrospektiva a plánování - prezentace výstupů místo přítomnosti mentora u tvorby
  • retrospektiva nevyjadřuje splnění cílů iterace a postrádá řešení problémů
  • v plánu další iterace chybí součet hodin (uvažování scopu) a schůzky
  • dosud neuzavřené úkoly v iteraci menší scope, odhady o 25% mimo
• pozitiva
  • demo obsahově ok
  • retrospektiva pokrývá popis proběhlé iterace a problémy (ač rozptýleně)
  • uvažování priorit a návazností úkolů při plánování
  • cíle relevantní a splněny
  • plán na 2 iteraci větší ve snaze dohnat ztráty a relevantní
• další komentáre
  • nedokončené úkoly iterace přeplánovat dál, dodržovat timeboxing iterací
• hodnocení: slušné 1,5

Technická kvalita¶

• negativa
  • funkční, nefunkční požadavky a akceptační kritéria se ve Vizi různě mísí a není finální soupis (není až takový problém, pokud bude oddělená specifikace)
  • stakeholders ve Vizi příliš nespecifikováni
  • chybí trasovatelnost commit-ticket a iterační tag
• pozitiva
  • wiki - zápisy schůzek a knowledge base (výběr open dat, analýzy, ...)
  • rozšířený business case ve Vizi zde dává smysl
  • rizika ve Vizi
  • branche
  • používání komentářů a description
  • používání vazeb mezi tickety
• další komentáre
  • projektový plán může být klidně samostatný artefakt, nemusí být součástí Vize
• hodnocení: slušné 1,5

Postupy a praktiky¶

• negativa
  • některé konvence dodržované, žádné sepsané
  • viz retro a plánování
• pozitiva
  • plánuje se detailní specifikace požadavků
  • změna vlastní zkušeností
    • schůzky původně jako ticket per osoba, nyní už společný
    • násobení odhadu počtem lidí (schůzky)
• hodnocení: slabé 1

Použitý proces¶

ASWI std + vlastní business case

Datum schůzky¶

12.4.2021, 0. a 1. iterace

Hodnocení
10¶

Malus/Bonus¶

n/a

Doporučení¶

• mentor se pokusí angažovat v postrčení zákazníka, který blokuje postup (čeká se dokonce i na jeho implementaci, na kterou má tým navázat)

Průběh a stav projektu¶

• pozitiva
  • drtivá většina feedbacku z minula zakomponována
  • z pohledu týmu uděláno, co šlo
  • nástroje nyní používány velmi kompetentně
• další komentáře
  • "skoro" LCA - zbývá dotažení spustitelné architektury
  • blockery ze strany zákazníka, nutnost podrobných callů (zvětšují zátěž) i čekání na implementaci z jeho strany (nejde pořádně naplánovat další iteraci)
• hodnocení: skvělé 2,5

Iterace¶

• pozitiva
  • náplň ok, vzhledem ke scopu, odhadování dobré
  • cíle splněny, retrospektiva relevantní
• další komentáře
  • 2 úkoly přeplánovány
  • hodně stráveného času díky nutnosti velkých domluv se zákazníkem
  • na příští iteraci málo naplánováno díky čekání na vstupy od zákazníka
  • burndown ovlivněn čekáním na zákazníka
• hodnocení: skvělé 2,5

Technická kvalita¶

• negativa
  • chybí iterační tag
• pozitiva
  • dodělán plán projektu
  • přeplánování úkolů
  • práce s úkoly obecně
  • Technická specifikace (architektura) - ERA, celkový návrh, technologie
  • napravené trasování ticket-commit
• hodnocení: slušné 2

Postupy a praktiky¶

• pozitiva
  • detailní konvence
  • z většiny dolazeny na základě feedbacku z minula
• hodnocení: skvělé 3

Použitý proces¶

ASWI std

Datum schůzky¶

12.4.2021

Hodnocení¶

2.it 9 bodů / 3.it 7 bodů

12.4.2021 (do konce 3.iterace zbývají 2 dny, implementační práce už hotovy)

Doporučení¶

• zrevidovat si, co je třeba pro LCA, a zařídit se podle toho
• naučit se a použít postup pro retrospektivu vč. volby sady otázek
• doladit plánování iterací a dokončit naplánování projektu

Průběh a stav projektu¶

• merge databází dokončen, dělá se na aplikaci (styl, zobraz položky, ...)
• komunikace se zadavateli dobrá, reakce na průběžný feedback na základě předváděné implementace
• implementační práce běží bez potíží
• požadavek na sjednocení dat řešen, včetně zkontrolování výsledných dat
• LCA stále nemají ve svém seznamu jako "dosažený", i když reálně už tam skoro jsou (práce na finálním db modelu, impl technologie rozhodnuté a použitelné, konvence zčásti usazené) nicméně dokumentace/specifikace klíčových věcí neřešena -- na konci 2.iterace to je mrzuté ale na konci 3.iterace už vskutku špatné

pozitiva

• steady progress, komunikace se zadavateli
• podrobné zápisy

negativa

• chybí plán do konce projektu, přehled o zbývajících požadavcích
• nejasnost ohledně dosažených milníků
• nedokončené/neřešené klíčové LCA charakteristiky ani po třech iteracích

další komentáře

• dosud strávený čas: 2.it 48 hodin (vs 40 estim), 3.it 38 hodin (vs 46 estim), celkem 133h

Hodnocení: 2.it slušné (2) / 3.it slabé (1)

Iterace¶

• 2.it cíl ~ok ale není k LCA ač mohlo být, burndown přetaženo přes termín ukončení
• 3.it cíl ok odpovídá construction, burndown "předčasný konec"

pozitiva

• podrobný rozpis úkolů a činností iterací (wiki stránky)

negativa

• 2.it drobnost: dva úkoly se nedaly dodělat z "vis maior" důvodu, diskuse, jeden to bylo chtělo rozdělit na dva tasky a přeplánovat do další it.
• 3.it burndown a iteration backlog zjevně nezahrnuje ještě očekávané aktivity WRT iteration wrap-up (v iteraci nejde jen o implementaci)
• 3.it hodně implementačních prací ale žádné zjevné testy

Hodnocení: 2.it slušné (2) / 3.it slušné (2)

Technická kvalita¶

• src dobré
• dokumenty / specifikace slabé (neexistující)

pozitiva

• systematické použití wiki, přehledné

negativa

• neexistuje soupis user reqts (jen relativně obecná Vize, která obsahuje jim i zadavatelům původně nejasné formulace bez oprav) a tudíž mj.není osnova, podle které vyjasňovat jednotlivé požadavky se zadavateli a plánovat celý projekt
• žádná dokumentace architektonických rozhodnutí
• nejsou priority na issues, není záměrem, krátce diskutováno

neutrální

• do "issues" zaznamenávají jen věci nutné k řešení v týmu, ne na úrovni jednotlivců interně; enhancements jako self-proposed věci x features jako user reqts (použitelné schema, jen není dokumentováno)

Hodnocení: 2.it slušné (2) / 3.it slabé (1)

Postupy a praktiky¶

• vývojářsky dobře prováděno

pozitiva

• effort estimation prováděno systematicky, vcelku sedí s realitou (návrh od assignee, na discordu řeší společně, do redmine dává O.Anděl)
• funkční rozdělení prací front/back-end, vč. knowledge sharing
• v rámci merge na master nezávislé testování a provedení merge (=> neformální code review) někým jiným (kromě commitů od O.Anděla)
• systematicky používány feature branches, konfliktů je málo protože se brání aktivně vhodným zadáváním úkolů a rozdělením front/back-end, používají git fast-forward/rebase aby se historie nezanášela množstvím branches

negativa

• retrospektiva není retrospektivou, krátce diskutováno
• issues v commit msg odkazují ale nepropojuje se do issues (syntax referencí, oprava bude snadná)
• jen neformálně domluvené konvence "by example"

Hodnocení: 2.it dobré (3) / 3.it dobré (3)

Hodnocení¶

6 bodů

datum: 6.4.2021

Doporučení¶

• používat znalosti získané na přednáškách a v předchozích předmětech
• zejména (v tuto chvíli) ohledně práce s odhady issues, retrospektivy a testování
• promyslet, na základě prostudování ASWI procesu, jakou metodiku použít pro tento projekt

Průběh a stav projektu¶

• provedena analýza stávající implementace
• probíhá reorganizace src a částečný refactoring kódu
• pravidelné schůzky se zákazníkem
• J.Pizúr oznámil, že končí studium => na projektu budou pokračovat zbylí 3 členové týmu

pozitiva

• práce aktivně běží, tým funguje
• vytvořen plán v podobě Redmine "roadmap"
• existuje prioritizovaný product backlog

negativa

• product backlog je vydáván za plán projektu
• rozplánovaný postup prací odpovídá "naivnímu vodopádovému modelu", nikoli iterativnímu vývoji
• tým nemá jasno, jakého milníku v rámci ASWI procesu již dosahli, zda tento proces/metodika vyhovuje charakteru projektu, zda se na něj dokáží "namapovat" nebo zda potřebují vlastní upravený proces

další komentáře

• dosud strávený čas: 78 hodin (ale některé práce pravděpodobně nereportovány)

Hodnocení: slušné (2b)

Iterace¶

• 2 týdny, formálně uzavřena a v pořádku

pozitiva

• definovaný cíl, zhruba odpovídající fázi projektu
• issues burndown slušný ale na malém objemu issues
• wiki stránka se souhrnem iterace

negativa

• hours burndown "collective procrastination"
• není zřejmé, zda bylo nějaké "customer demo"
• nejsou uzavřena všechna issues
• retrospektiva provedena, ale dle zápisu nesplnila účel - jen shrnutí historie iterace (nulová přidaná info oproti issues + commits)

Hodnocení: slabé (1b)

Technická kvalita¶

• celkově na slušné úrovni, aspoň po formální stránce

pozitiva

• vytvořen doc Vize, dobře zachycené cíle projektu a požadavky
• priority na issues
• dobře strukturovaná wiki

negativa

• doc Vize nepopisuje přínos projektu, řeší i nepříslušné věci (detaily vývojové infrastruktury, obsah předání)
• nevhodně (málo) strukturované/členěné issues, odhady pracnosti neodpovídají doporučením; viz poznámky k burndown
• v iteračním backlogu nejsou zachyceny činnosti pro práci s požadavky, QA => nelze určit objem prací na nich
• není propojení ticket-commit

Hodnocení: slušné (2b)

Postupy a praktiky¶

• pokud prováděny, tak povětšinou intuitivně nikoli vědomě/záměrně

pozitiva

• použit github pull req pro práce na iteraci, s integrací (merge) do main branch

negativa

• zřejmě intuitivně řešeny různé drobné úpravy postupu, např. způsob evidování schůzek v Redmine, ale není nikde zaznamenáno
• žádné stopy po QA aktivitách, byť zřejmě nějaké základní byly provedeny => pochybnosti o "potentially shippable" pro výsledek iterace
• žádné stopy po aktivitách z disciplíny "environment", byť určitě existovaly

Hodnocení: slabé (1b)

Hodnocení
8¶

Malus/Bonus¶

n/a

Doporučení¶

• rozjet wiki
• DSP není povinná forma, ale specifikace požadavků musí někde existovat
• schůzky (úkoly) patří do iterace, ve které se provedou, ne kam se tématicky vztahují

Průběh a stav projektu¶

• negativa
  • neexistuje projektový plán
  • sžívání s požadavky procesu
• pozitiva
  • PRI deklarováno a dosaženo
  • komunikace a fungování týmu
  • rozdělení prací
  • získání HW (Raspberry) a rozchození infrastuktury pro vývoj (Unit, Qt, atd.)
  • vyrovnávání se se specifiky PoT-based projektu
• hodnocení: slušné 2

Iterace¶

• negativa
  • nadstřelení odhadů
• pozitiva
  • obsah, scope, cíle dosaženy
  • plán na další iteraci
• další komentáře
  • burndown hraničí s ColProc, ale vysvětleno čekáním na reakci zákazníka
• hodnocení: slušné 2

Technická kvalita¶

• negativa
  • wiki zatím prázdná, existuje gDrive, ale ani na něj není odkaz a je na něm jen Vize, načnuté DSP a záznam schůzky
  • výstupy přímo v ticketech
  • nepoužívání priorit
• pozitiva
  • Vize v prvním draftu, ale obsahuje vše podstatné krom strategií odstranění rizik
  • postup přeplánování rozdělaného úkolu
  • trasování ticket-commit
  • praktický průzkum realizačních technologií
  • používání komentářů a někdy i description úkolů
  • kategorizace přes tagy
• hodnocení: slušné 2

Postupy a praktiky¶

• negativa
  • nedohledatelné zápisy schůzek, nabyté vědomosti o projektu/technologiích, konvence a další průběžné výstupy (risk při rozdílech v paměti členů)
  • materiály na demo neposlány předem
• pozitiva
  • obecně víc lightweight, protože menší tým s jistou hierarchií
  • ač nejsou nikde zachycené hodně praktik/konvencí se používá intuitivně a díky správě Redmine kompletně v kompetenci vedoucího týmu
  • postup při retrospektivě, identifikace a reakce na problémy
  • postup při plánování - co, kdo, za kolik
  • postup a témata při demu
  • úprava hranice iterací (z neděle na pondělí)
  • obecně dobré instinktivní reakce na nesrovnalosti a chápání účelu věcí
  • sledování scopu při plánování iterace
  • akceptační kritéria - duplikace funkcí současného řešení na nové technologii
• hodnocení: slušné 2

Použitý proces¶

ASWI std

Datum schůzky¶

30.3.2021