Redmine

Hodnocení
8,5¶

Doporučení¶

• timeboxing schůzek (interních i jiných) může pomoct bavit se o největších prioritách a omezit admin, zbytek se může dohnat asynchroně (mail, chat, atd.)
• sejít se až za 2 iterace podle nového počítání (tzn. za 2 týdny)

Průběh a stav projektu¶

• + zlepšili komunikaci se zákazníkem, schůzky ubyly, konečně mají test prostředí
• + LCO
• - stále skluz vlivem zákazníka + ostatních předmětů
• + vyřešeny resty z minula
• hodnocení: slušné 2

Iterace¶

• 0 velký podíl adminu, ale řeší se
• + dohnané náslechové schůzky s mentorem, náplň (do jisté míty daná okolnostmi), plán na další, odhad 74/76
• +/- nesplněné věci řešeny v retrospektivě
• hodnocení: slušné 2

Technická kvalita¶

• + Vize
• + pracovní verze specifikace
• + popisy stage prostředí a DB, komentáře logtime, priority, občas description, estimates, hierarchie, párování s commity
• - due date
• + repo
• hodnocení: slušné 2

Postupy a praktiky¶

• + zápisy schůzek
• + retro
  • lepší komunikace se zákazníkem, větší buffer na admin, ne vždy musí být všude všichni, nerozebírat interní věci na hovoru
  • přístupově dobře, cíle, co zlepšit, místy zklouzávalo do technických debat (odchyceno)
  • ? předělat plán nebo mít živo verzi v ticketech (pak ale chce nastavené boardy, atd. na lepší monitorování)?
• + přechod na týdenní iterace s retrospektivou každou druhou
• plánování
  • + vyřešit bottlenecky a neřešit moc (původní) plán
  • + přeplánování ticketů udělané správně
  • - k věci, tzn. jen rámcově co, kdo a kolik to zabere - detaily bokem
• hodnocení: skvělé 2,5

Použitý proces¶

ASWI std (akorát AzD jak tickety, tak repo)

Datum schůzky¶

3.4.2023

hodnocení: 9
datum: 31.3.2023

průběh a stav projektu - dobré 3b

• + LCO dosaženo, zkontrolováno
• + prj naplánován (Redmine roadmap)

iterace - slušné 2b

• 0 cíl v souladu s etapou projektu, ale formulovaný příliš podrobně (odrážky na úrovni úkolů)
• burndown “white cliffs of Dover” (takto issues, přes “hours” lepší) – práce na dokončení iterace přes víkend
• + průběh dobrý
• + retrospektiva vhodně provedená a zaznamenaná (rekapitulace + reflexe), ale není soulad mezi zaznamenanými problémy a “výsledek retrospektivy”

technická kvalita - slabé 1b

• 0 Vize jako artefakt slušně zpracovaná, v některých místech moc stručná (stakeholders - chybí cíle, plán projektu - není výhled za rámec ASWI) resp. naopak jde do nadbytečných detailů (cíle)
• - špatné (neexistující) trasování požadavků z vize do úkolů, zmatečné (nejednoznačná pravidla) použití Enhancement a Feature typů issues
• - chybí vhodná forma specifikace požadavků, ani dokument ani issues-based backlog
• + počáteční koncept úprav architektury vč. diagramu
• + konvence, dokumentované na wiki

postupy a praktiky - dobré 3b

• - odhady výrazně přestřelené (odhad 113h, realita 84h) – důvod: technologie zvládli rychleji než se jevilo předem
• + odhadování: team leader návrh, revize assignee v rámci týmové porady
• 0 odvození úkolů je snaha dělat z bodů Vize a dalších, ok
• + práce s issues: workflow (assignee “resolved”, team lead “closed” nebo “reopen”), použití Definition of Done, osvědčilo se napsat do popisu podrobnější “zadání” při vytvoření -> stručně “řešení” s odkazy na vytvořené artefakty při resolved (příklad)

doporučení

• zvážit, zda do Vize zahrnout i cíle projektu nad rámec ASWI (pro ukotvení TSP2 prj)

hodnocení: 9
datum: 29.3.2023

průběh a stav projektu - hodnocení slušné 2b

• + rychlý nástup prací projektu po úvodním čekání na rozjezd
• + dobře funguje komunikace, s hospicem v mezích možností
• 0 “LCO milník dosažen” ale ještě nejasnosti u stakeholderů (Daněk - podoba řešení, hospic - nekonzistence v požadavcích)
• 0 vytvořený plán projektu ale už neodpovídá předpokládané skutečnosti a nesedí dokument s Redmine roadmap

iterace - dobré 3b

• + cíl a obsah odpovídá fázi prj
• 0 burndown (camel hump) i neúplný seznam tasks odráží to, že se zapomnělo něco na začátku do plánu zadat protože potřebovali rovnou skočit na práci
• - výrazně nadhodnocené odhady, částečně způsobené rozhodnutím o změně technologie v průběhu iterace (probráno v retrospektivě)
• 0 retrospektiva provedena, na to že tým je 2-členný a že poprvé to vypadá na slušný pokus (mentor nebyl přítomen, z vlastního rozhodnutí), v záznamu chybí indikace typu glad/sad/mad a z retrospektivy nevyplynuly zřetelné “actionable points”

technická kvalita - slabé 1b

• - roztříštěné zaznamenávání informací (redmine wiki, tasks, google drive)
• - chybí zřetelně vymezené a řízeně upravované hlavní artefakty; obsah jim odpovídající ale +- existuje (vize v rámci “plán projektu” a záznamu schůzky se zákazníkem – cíl “stanovit si prioritu požadavků a minimální akceptační kritéria”, přehled požadavků tj. backlog v pracovním textovém souboru)
• 0 vývojové prostředí inicializováno ale zatím nepoužité resp. v řešení (součást cílové platformy)
• + tickety popsané kde potřeba, workflow ok; úložiště zatím n/a

postupy a praktiky - dobré 3b

• + dobře řízená komunikace se zákazníkem, přípravy a záznamy
• + (nakolik umím posoudit) vhodně změněná strategie co se týče technologie pro výsledné řešení a tedy cílové provozní platformy (z “desktop app + server backend” na “google suite se scriptováním”)
• 0 zápasí s vybalancováním programátorský přístup vs. sw projektový management, s pracností “administrativy”, a s řízením zákazníka

doporučení

• s aktuální znalostí zákazníka a kontextu: revidovat rizika a opatření, plánovat podle toho, věnovat víc péče definici požadavků+rozsahu a jejich doloženému odsouhlasení
• zamyslet se a odstranit duplicity ve vykazování a zaznamenávání informací (=> šetřit čas), vzít pragmaticky, co je opravdu třeba mít a v jaké formě

použitý proces

• ASWI std

Hodnocení
7¶

Malus/Bonus¶

• potenciál za prokopnutí Azure DevOps, pokud se tam vytvoří něco pěkného
• možný bonus za plán (TBD)

Doporučení¶

• "zlomit" nějak rovnováhu při schůzkách - být více asertivní, posílat agendu a otázky k řešení předem, přemýšlet o dalších možnostech
• podobné problémy hlásit okamžitě mentorovi
• zamyslet se na základě diskuze s mentorem, čemu interně říkat iterace (jednomu týdnu nebo dvoum) - uvážit, popř. konzultovat dopady
• zřídit na Teams wiki rozcestník
• zkusti pro mentora vyjednat práva na a) nastavení vlastního dashboardu, b) vidění do repository
• nastavit si dashboardy/reporty pro snadný monitoring postupu projektu i současné iterace
• násleh mentora na retrospektivě a plánování dohnat při další příležitosti

Průběh a stav projektu¶

• - přiznaně za plánem
  • vlivy: rozkoukání v Azure DevOps, chaos a nerespektování domluv zákazníkem, neustálé interapty, nutnost rozjet proces, zákazník nedostatečně nainitován mentorem
• + plán to zohledňuje a počítá se s větším nasazením v dalším průběhu
• + interně fungují a jeví známky zájmu a pochopení procesu
• hodnocení: slušné 1,5

Iterace¶

• - malá (částečně díky interuptům)
• + splěnné cíle, náplň
• - násleh mentora na retrospektivě a plánování neproběhl (částečně díky rozvrhům)
• hodnocení: slušné 1,5

Technická kvalita¶

• + knowledge base na gDrive
• + zápisy schůzek, GSM retrospektiva, prezentace pro zákazníka
• +/- konvence dobře chycené pro Git, pak se to zvrhává na obecný TODO list
• + dost detailní plán včetně odhadů, verze pro zákazníka
• - Vize má jen business case, cíle a časový rámec, který je na rozdíl od plánu pro TSP1+2, chybí všechny ostatní části
• + zanesení i aktivit z 0. iterace do AzD
• + vyrovnávání se s AzD obecně
• hodnocení: slušné 2

Postupy a praktiky¶

• demo
  • + schůzky konečně usazeny na jednou týdně
  • + snaha o rízení
  • + na konci ujasnění/rekapitulace domluvy
  • - sdílení brát jako default
  • 0 zákazník je hodně asertivní/agresivní - řídí schůzky
• + retrospektiva, standupy
• hodnocení: slušné 2

Použitý proces¶

ASWI std (akorát AzD jak tickety, tak repo)

Datum schůzky¶

24.3.2023

Hodnocení
7¶

Doporučení¶

• nahradit náslech retrospektivy a plánování spolu s dalším review (cca 4.4.)

Průběh a stav projektu¶

• 0 rozložení práce nevyrovnané - předpoklad, že se časem srovná
• + se zákazníkem a interně tým funguje zdánlivě dobře, rozběhnutí projektu, tvorba základních artefaktů, infrastruktura
• 0 návaznost na předchozí práce (BP 2 členů týmu)
• hodnocení: skvělé 2,5

Iterace¶

• - neproběhl náslech mentora na retru a plánování (na demu netřeba z rozhodnutí mentora)
• + odhad, náplň
• hodnocení: slušné 2

Technická kvalita¶

• + komentévání stráveného času, popisy ticketů, hierarchie ticketů
• - neuzavřený úkol dlouho po skončení iterace, iterace mají stejné Start Date a Due Date
• 0 repo s Redmine nejde propojit, repo zákazníka je privátní
  • + přesto snaha o vyznačování issues v commit message
• - commit message obvykle velmi stručná
• + branche a tag v repository
• + struktura Wiki, plán projektu
• - chybí zápisy schůzek, včetně retrospektivy
• + ale na zápisy existují konvence
• - konvence obecné zmíněné, ale nedohledatelné
• hodnocení: slušné 1,25

Postupy a praktiky¶

• + Vize
  • - chybí cílový uživatelé, rozsah projektu v člověko-hodinách
• + vstupní dokumenty v gDrive, příprava na plán testů a nasazení, specifikace požadavků, rizika
• - po retrospektivě není památka, ale podhle rozhovoru proběhla
• hodnocení: slušné 1,25

Použitý proces¶

ASWI std

Datum schůzky¶

21.3.2023

Hodnocení
11+11¶

Malus/Bonus¶

• potenciál na bonus - důsledná analýza

Doporučení¶

• další review až po 4. iteraci
• nevkládat moc úsilí do prototypů - zákazník tvrdí, že specifika jsou na týmu, ale může začít reagovat negativně, až něco uvidí

Průběh a stav projektu¶

• + nastartování projektu a hluboká analýza problému
• + v podstatě bezchybné díky zkušenosti 3/4 týmu z ASWI procesem
• 0 lehce více sekvenční přístup, ale opodstatnělý
• + výborná komunikace
• + LCO deklarované a dosažené
• hodnocení: skvělé 3

Iterace¶

• + první (3 týdny) init, druhá (2 týdny) analýza
• + dobré burndowny, celkově on track, zátěž nevyrovnaná ale zdůvodněná, odhady sedí, dobrá náplň
• hodnocení: skvělé 3

Technická kvalita¶

• - některé úkoly 2. iterace neuzavřené
• + hierarchie ticketů, popisy, komentáře
• + plán, Vize, rizika, MVP, milníky, konvence, wiki obecně
• + logický rámec
  • pro jiný předmět, effort nezapočítaný, ale pěkný výstup
• + kostra (HelloWorld) na repo
• hodnocení: skvělé 2,5

Postupy a praktiky¶

• + sběrné, osobní, iterační úkoly na admin
• + konvence věcně, zápisy schůzek
• 0 MVP je dost obecné
  • zákazník to nechává na týmu, ale je to dvojsečná zbraň
• 0 náslechové schůzky na popud mentora vynechány, stejně jako review po první iteraci
• + proaktivní přístup k nevyhraněným potřebám zákazníka a k "zaškolování" méně zkušeného člena více zkušeným
• - cíle iterací jsou ale v retro se neřeší jejich splnění
• + řešení testovacího prostředí
• hodnocení: skvělé 2,5

Použitý proces¶

ASWI std

Datum schůzky¶

23.3.2023

Hodnocení
10¶

Malus/Bonus¶

• pontenciální bonus za "prokopnutí" Jiry (TBD)

Doporučení¶

• úcast mentora na dalším demu (při dosažení LCA) není třeba
• príští review až za 2 iterace (konec tretí)
• rozhodnout, do které iterace spadá víkend (nemůže bý v žádné)

Průběh a stav projektu¶

• + komunikace a interní fungování týmu, velké usilí vložené do setupu Jiry, projekt on-track
• + návaznost na SAR tým a DP, aktivní komunikace s nimi i ostatními stakeholdery
• + vykomunikované a zřízení dev a prod prostředí
• + deklarované LCO - věcně dosažené, jen zjištěné široké info nechyceno ve Vizi nebo ekvivalentu
• 0 rozložení práce 50% šéf, 50% zbylý 2 členové má momentálně smysl (nastavení Jiry)
• hodnocení: skvělé 3

Iterace¶

• + v zásadě bez velkého problému, jen pamatovat na kontrolu scopu a nastavování a plnění cílů
• hodnocení: slušné 2

Technická kvalita¶

• + TeX dokumentace podle šablon
• + Jira, add-ony, approval process, využití Teams wiki v momentě, kdy nebylo rozhodnuto o ALM
• + zákaznické repo pro kód a výstupy k němu, pro interní ASWI repo
• + důsledné konvence včetně nastavení Jira workflow podmínek
• + propojení mezi ALM, branche
• 0 lehké nedostatky ticketů se momentálně dají přehlédnout kvůli nutnosti si Jiru celou nasetupovat
• skvělé 3

Postupy a praktiky¶

• demo
  • + předvedení plánu, přístup, řešeno co se stane dál, approvnutá specifikace, code reviews
• 0 překlop z temp poznámek z Wiki na ASWI repo na popud mentora
• 0 otázka trasovatelnosti commit-ticekt se prozkoumá
• plánování
  • + on the spot se zákazníkem, v podstatě super, jen hlídat odhady a kapacity
• retro
  • + příprava, diskuze
  • - "budeme se snažit to minimalizovat" (zpoždení díky mnohostranné komunikaci) - nutné zodpovědět jak?
  • - neřešilo se splnění cílů, popř. máme milníků, lehké nepochopení šablony pro retro
• - specifikace existuje před Vizí
• + specifikace, konvence, plán
• + velká úroveň agility - na meetingu call vedoucí na potenciální přeplánování (nakonec ne, ale diskuze o závažnosti)
  • pro agilní vývoj vlastne velmi vhodné
• + promýšlení testovacích a ostatních serverů
• + angličtina
• hodnocení: skvelé 2

Použitý proces¶

ASWI std (vyjma nástrojů - Jira + 2xGitLab)

Datum schuzky¶

21.3.2023

Hodnocení
6¶

Doporučení¶

• CICD materiály (CW predmetu, Teams - Tools and howtos)
• využít zájmu jednoho člena z ASWI strany o plánovací a řídící praktiky a dát mu zodpovědnost za (většinu) Redmine a organizace
• dostat mentora do repository (stačí read-only)

Průběh a stav projektu¶

• + projekt rozběhnutý, první sprint 2týdenní, další týdenní, hlubší zkoumání zadání + ucení se s technologiemi, DoD, komunikcase zdá se bez problémů
• - ani poblíž LCO (v podstatě chybí i aktivity, které by na jeho dosažení vedly)
• - nevidí se prospěch v (ASWI) "ceremoniích" (nedočkavost na vývoj bez usazeného základu)
  • schůzky žerou čas (to je ale přirozené na startu), "místo programování schuzkujeme"
  • schůzky konsolidovat/dělit mezi členy, pokud se nenajde průsečík mezi mentory
• hodnocení: slušné 1,5

Iterace¶

• + retro a plánování proběhlo, odhady
• 0 náplň +/-
• hodnocení: slušné 2

Technická kvalita¶

• - nepoužití Version pro iterace (místo toho tagem), tickety jsou jen na schůzky
• + branchování, hierarchie ticketů
• - ticketům často chybí popis, natož komentáře změn, z názvu samotného je ne vždy jasný účel
• - některé tickety zavřené až 5 dní po konci iterace
• - 2 lidi jsou z ASWI a studenti tam byli opakovaně nabádáni na zkoumání Redmine před zahájením projektů, používání cvičného projektu a dotazování se na nejasnosti - přesto stav "my nevíme, jak se to dělá"
• hodnocení: slabé 1

Postupy a praktiky¶

• - vynechání účasti mentora na demu
• retro
  • - chybělo vyjádření k cílům, milníkům, netvořil se zápis
    • dobrá (ale ne nutná) praxe je zavírat úkoly na retrospektivě
  • + plán na konvence na Redmine, Glad/Sad/Mad
• plánování
  • + prioritizace (ale ujasnit si význam jednotlivých levelů), myšlenka vytvořit plán
  • - mišmaš jazyků
• - neexistuje/není dostupná Vize (nebo její ekvivalent), plán, konvence, zápisky ze schůzek ani jiné artefakty
• 0 zákazník tvrdí, že požadavky jsou z jeho strany dostatečně specifické v zadání samotném
  • dobrá, ale jsou dostatečné i ze strany týmu? a co další údaje o projektu (mimofunkční požadavky, stakeholders, business case, rizika, atd.)?
  • navíc zadání není dostupné z Redmine
• + domluvení konvencí Gitu
• hodnocení: slabé 1,5

Použitý proces¶

ASWI light (jen půl týmu je na ASWI)

Datum schůzky¶

16.3.2023

17.3.2023

8 bodů

Doporučení¶

• Vylepšit formulaci cílů iterací
• Actionable items do výsledků retrospektivy

Průběh a stav projektu¶

• projekt nastartován a naplánován
• LCO dosažen, víceméně

pozitiva

• tým dobře komunikuje

negativa

• Na wiki plán prj ale lépe funguje Redmine roadmap (navzájem duplikované informace)

další komentáře

• dobrý je cíl přiřazení rolí v rámci týmu, aby se naučili nové technologie
• dosud strávený čas: 60.25 hours

Hodnocení: dobré (2)

Iterace¶

• plánována až v průběhu
• cíl a provedení odpovídá začátku projektu

pozitiva

• Retrospektiva provedená a zaznamenaná slušně (ale ztrácí se actionable items)

negativa

• ze záznamů průběhu iterace nejsou poznat aktivity související s její uzávěrkou
• hodinový odhad silně podstřelen (19 odhad vs 39.5 reportováno), dáno nečekanou délkou schůzek

Hodnocení: slušné (1)

Technická kvalita¶

• artefakty (dokumenty) odpovídají fázi prj výčtem, obsahem i kvalitou

pozitiva

• Vize, konzultovaná se zákazníkem
• dokumentované konvence
• interní dokumentace (v rámci UJP/AEP6) pro postupné upravování v průběhu prj

negativa

• Vize nefinalizovaná (vs deklarované dosažení LCO) -- tým doladí podle informací z přednášek
• Zmatek v tom, kde je jaká informace/dokument (wiki, DMS)
• Definition of Done ale zatím není popsaná

Hodnocení: dobré (2)

Postupy a praktiky¶

• použito, co bylo potřeba
• upřesňovali jsme, zda/jak byla snaha o “stakeholder concurrence” na vizi; good
• glad/sad/mad retrospektiva

Hodnocení: dobré (3)

26.5.

Iterace¶

obsah a průběh 5., 6. iterace v pořádku, nadhodnocená pracnost (o 1/4)
7. iterace (předání) ještě last minute úpravy a bugfixy

doplněny formality u artefaktů SRS, Arch + README per project
v rámci 5. a 6.iterace v Redmine uzavřeny feature issues vázané na SRS požadavky, slušně udělaná trasovatelnost reqts - features - tasks - commits
důkladné testování v závěru projektu, nějaké chyby nalezeny a evidovány

5.it 12b, 6.it 12b, 7.it 10b

Projekt celkově¶

cca 40h navíc kvůli last minute reqt finalizace + dolaďování
na začátku míň efektivní, např. účast všech na schůzce spálila hodně člověko-hodin i když se neřešily věci pro celý tým
cílili na cca 400h ale trochu podcenili náročnost (hlavně design+impl vyznačování anotací) + schůzky delší (domlouvání po schůzce) + last minute reqt
citace: "výhoda je, že čas nestojí peníze jako ve firmě" :-)

provedeny dílčí úpravy procesu (zejm. customer demo), dobré ale uděláno spíše intuitivně než plánovaně - např. není zachyceno v retrospektivách
tým v průběhu laboroval s délkou iterací; negativem je (zvnějšku pozorováno) až moc intuitivní způsob tohoto laborování, pozitivem je schopnost rychle zjistit problém a opravit kurs (nesetrvat v nevhodném procesu)

udělán doc zhodnocení prj, vůči vizi a kritériím úspěchu; dobré
získali (ve Vizi plánovanou) zpětnou vazbu od uživatelů

zákazník spokojen nad míru/očekávání, reflektuje že zkomplikoval situaci opomenutým požadavkem

Reflexe - "příště případně jinak":

• upravit ticket workflow tak, aby closed bylo udělané hned po review a merge na dev; původní myšlenka zavírat to společně se ukázala jako ne potřebná resp. jen u několika málo případů
• ne úplně se osvědčilo reportování chyb napřed do discord channel a pak do RM, protože v discordu toho bylo hodně a v šumu se vcelku dost info ztratilo nebo byly duplikované, otázka je co by se hodilo použít pro prvotní reporting chyb (trello, diskuse s vlákny) aby bylo lightweight ale přehledné; ale bylo to v poslední iteraci a už nemělo cenu řešit
• na konci se ukázalo, že 2-týdenní iterace byly dlouhé kvůli potřebě zaplánovávat zpětnou vazbu, dělali 1-týdenní, ty by se možná byly hodily i dřív kvůli zaplánování hodin co se kdy stane (“oslava u babičky” apod.) – a přitom v průběhu prj měli v úmyslu udělat 3-týdenní implementační iterace ;)

Hodnocení¶

10b

Průběh a stav projektu -- dobré
Iterace -- výborné
Technická kvalita -- slušné až dobré
Postupy a praktiky -- výborné