Projekt

Obecné

Profil

Novinky

Hodnocení projektu

Přidáno uživatelem Petr Pícha před téměř 5 roky(ů)

Tým a komunikace

  • ne zcela responsivní zákazník -> snaha týmu, ale bez eskalace -> nedorozumnění se projevili později
  • uvnitř týmu z většiny ok
  • aktivita v hledání řešení u mentora
  • přínosné diskuze nad procesem a praktikami
  • podíly práce 7:8:8:9
  • slušné

Projekt

  • ztížená situace nekomunikativním zástupcem zákazníka, nedorozuměním v požadavcích, které zákazník odsouhlasil a neznámými technologiemi
  • přesto výsledek funkční a uspokojivý, ač rozsahově menší než měl být
  • slušné

Postupy a praktiky

  • code review, staundupy, retrospektivy
  • test driven vývoj
  • dobrý krizový management (odříznutí administrace a ceremonie ve prospěch produktu)
  • změny rolí v krizovém stavu
  • pozdní vykazování času
  • dynamické přeplánování
  • ze začátku nedorozumění o vztahu fáze-milník
  • slušné

Technická kvalita

  • retro, dokumentace API, procesní diagramy požadavků, GUI návrhy, logický a ERA model, UC diagramy, UC ID pro trasovatelnost, Architektura, dokumentace, sekundární wiki pro zadavatele, DSP, Vize, Plán
  • feature branche, trasovatelnost, kategorie issues
  • ze začátku učení se s Redmine, později kompetentní použití, na konci menší zaměření na Redmine, atd. kvůli snaze dohnat produkt
  • excelentní

Hodnocení
9

Hodnocení 4.-6. iterace

Přidáno uživatelem Petr Pícha před téměř 5 roky(ů)

Průběh a stav projektu

  • + zdárné vyřešení předchozích problémů se scopem, nedorozuměními a technologiemi, IOC (5. it.), REL
  • 0 soustředění na dotažení projektu více než na proces, negativní vliv i pozdního předání podkladů od zadavatele
  • - funkcionalita kvůli problémům menší
  • hodnocení: slušné

Iterace

  • + retrospektivy, náplň patřičná situaci, bugfixing, odhady dobré na průměru, obsahově velké iterace
  • 0 mimo deklarovaná data ale burndown 5. iterace jinak není špatný
  • - burndown trpí po pochopitelném zaměření na funkčnost, posuny deadlinů
  • hodnocení: slušné+

Technická kvalita

  • + implementace, testy, dokumentace, protokol, FRQS přes ID trasovatelné napříč dokumentací, ERA model, feature branche a jejich merge do develop, wiki na GitHubu
  • 0 dořešení nejasností v terminologii kolem fází a milníků, uzpůsobení plánu, backlog jako vlastní verze by šlo i přes filtr "není v iteraci"
  • - zmatek v hraničních datech iterací
  • hodnocení: skvělé

Postupy a praktiky

  • + v krizi focus na projekt na úkor procesu, změny rolí, změny plánování a rozdělování úkolů, častější a detailnější komunikace se zákazníkem
  • 0 ke konci častější konzultace s mentorem, proces víc lean
  • - chaos v rozhození do iterací nebo možná pozdní vykazování díky zaměření se na produkt
  • hodnocení: skvělé-

Jaká byla dána doporučení

- podnětná diskuze nad celkovou retrospektivou, procesy a náměty na změny do budoucna

Hodnocení
10

Hodnocení 3. iterace

Přidáno uživatelem Petr Pícha před asi 5 roky(ů)

Průběh a stav projektu

  • + pokrok v implementaci, LCA, věcně on track, rozmyšlený plán do konce projektu (ač nestabilní délka iterací)
  • - formální stránka pokulhává
  • hodnocení: slušné +

Iterace

  • + retrospektiva ok, plán, cíle a jejich splnění zdá se v pořádku, mnohem vyrovnanější rozložení času mezi lidi
  • 0 2. iterace trvala přes 4 týdny (vysvětluje odhad, byly tam velikonoce)
  • - přepálené odhady
  • hodnocení: skvělé -

Technická kvalita

  • + feature branches, dobře identifikovaná rizika
  • - rizika bez strategií řešení
  • hodnocení: slušné

Postupy a praktiky

  • + praktik obecně pochopené, ač ne adekvátně aplikované (diskuze), změna přístupu k odhadům
  • - pozdní tvorba dokumentů a vykazování času (nevedlo k problémům, ale je to zbytečný risk), neřešené iterační tagy
  • hodnocení: slušné -

Týmová dynamika a různé

  • + ok

Jaká byla dána doporučení

  • rozdíl mezi milníkem a fází
  • sekce o nástrojích v retrospektivě není o tom, jaké se používají, ale o zhodnocení práce a problémů s nimy
  • diskuze různých praktik, jejich náročnosti a nutnosti
  • když už se jednoun použijí ID UC, měly by sloužit k jejich trasovatelnosti napříč různými artefakty - jinak hezké, ale zbytečné
  • schůzka až za 2 iterace

Hodnocení
9

Hodnocení 2. (první a začátku druhé) iterace

Přidáno uživatelem Petr Pícha před asi 5 roky(ů)

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

Hodnocení 1. ("nulté" a začátku první) iterace

Přidáno uživatelem Petr Pícha před asi 5 roky(ů)

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

    (1-5/5)

    Také k dispozici: Atom