B/CZ/Úkol
- Pro svůj projekt z druhého modulu si vytvořte své vlastní úkolové workflow tak, aby odpovídalo potřebám projektu a bylo transparentně čitelné. Sepište jednotlivé stavy a – pokud je to potřeba – pravidla pro zacházení s úkoly napříč jednotlivými stavy.
Řešení:
Jednotlivé stavy úkolového workflow pro můj projekt:
- Koncept
- Připraveno (obdoba to-do)
- Zpracováváno (hotový prototyp)
- Kontrola
- Přepracováváno
- Čeká k testu
- Testováno
- Implementováno
- Reklamace
- Evaluace
…přičemž bod 1. je obdoba Vašeho Estimation. Přišlo mi to dobré jako označení pro, v mém kontextu teoretické, části a návrhy, které jsou ve fázi konceptualizování a čekají na „posvěcení“. 2. bod připraveno, je vlastně to-do, jen mi přijde výraz vhodnější a méně naléhavější. K udělání je vlastně připravený k udělání. Zpracováváno je in progress. Kontrola je stav po zpracování určen ke kontrole vedením – manažerem, popř. odborným pracovníkem. Přepracováváno je zvláštní kategorie pro úkoly, které již byly provedeny, ale je třeba je přepracovat. Tj. nezačíná se tam od píky. Čeká k testu je výstup k uživatelskému či technickému testování. Testováno je pro právě testované. Implementováno je pro úspěšně testované a nasazené naostro. Reklamace je pro nalezené závady a bugy. Evaluace je pro ostatní úkoly, a neúspěšně otestované.
Pravidla bych si nadefinoval následující.
- Projektový manažer je jediný kdo rozhoduje o přesunutí z evaluace do připraveno.
- Projektový manažer je jediný kdo Přesouvá z kategorie reklamace.
- Projektový manažer přesunuje z kategorie Koncept do připraveno jen po dohodě s Radoslavem Kratochvílem, jenž je zástupce FI a odborník přes ICT, technické věci.
- Z kategorie připraveno do zpracováváno mají povolení vytahovat členové týmu.
- Z kategorie kontrola mohou vytahovat pouza projektový manažer, a pověřený vrchní vývojář.
- Do kategorie Implementováno může zasazovat pouze pověřený vrchní vývojář.
* * *
- Zamyslete se nad otázkou tzv. testovacího prostředí (tedy prostředí, ve kterém můžete nanečisto zkoušet a testovat své výstupy). Zkuste odpovědět na tyto otázky:
- Potřebuje podle vás každý projekt testovací prostředí nebo něco analogicky podobného (např. otestování malého vzorku před vyrobením většího množství výrobku)?
Pokud ano, proč?
Pokud ne, popište stručně projekt, který podle vás testovací prostředí nepotřebuje, aby z popisu bylo zřejmé, proč jej nepotřebuje.
Řešení:
Příčí se mi kategoricky říct, že ne, nemůžeme najít žádný projekt pro který by [x] a [y]. V případě projektů bych se přiklonil spíše k obecnému tvrzení, že vždy je dobré výsledek nějak otestovat. Testování je vlastně forma kontroly. Kontrolu vyžaduje cokoliv, co jsme vytvořili a chceme to pustit tam ven. Kontrolovat je třeba i jen prostý e-mail. Gramatické chyby udělají špatný dojem, v některých případech rovnou urazí.
Věřím, že testovací prostředí je vždy lepší mít než nemít. Je mi tímto jasné, že se v rámci úkolu jedná o otázky mířené na opodstatnění prostředků pro zaopatření takového prostředí – vyplatí se časově, finančně, máme na to prostředky, poradíme si s údržbou? Přesto si pamatuju z jednoho z předchozích modulů, že funkční produkt prostě musíme dodat a kvalita je natolik důležitá, že si její nekontrolu nemůžeme dovolit.
V případě finanční či časové náročnosti by znova nebyla od věci otázka ohledně outsourcingu. Můžeme pro testovací prostředí využít někoho mimo, popř. nějakou službu?
Nepotřebnost testovacího prostředí si umím představit u projektu, jehož výstup by měl teoretický charakter. Např. Vývoj modelu, provedení studie, apod. Taktéž si umím představit výstup projektu ve své proveditelnosti tak jednoduchý, že můžeme využít primitivní a spolehlivý nástroj. Např. Google Sites. Předpokládám zde ovšem velmi malý rozsah projektu.
- Jak by mělo být podle vás testovací prostředí (nebo jeho analogicky podobná alternativa) nastaveno? Co by mělo mít? Čím by se mělo lišit od produkčního (ostrého) prostředí? Na co by se při nastavování testovacího prostředí mělo myslet? Neváhejte se rozepsat do detailu.
Řešení:
V první řadě bych se dotknul netechnických elementů. Nesmí nám v rámci takového prostředí chybět veškeré informační artefakty kolem; tj. dokumentace pro záznam testů, testovací scénáře, instalační manuály, poznámky apod. To znamená vše to, co z testovacího prostředí udělá zdroj cenných zpětnovazebních dat a ne jen prostor pro hraní.
Z technických aspektů by mělo být takové prostředí rozhodně správně vybrané vzhledem k cílům, ale i technické infrastruktuře firmy. Samozřejmostí je kompatibilita a up-to-dateness, tzn. aktuální verze. V závislosti na typu produktu pak relevantní data. Bavíme-li se v tomto modulu o přístupu, určitě by měl být i tento správně nastaven pro relevantní členy týmu.
Měly by být v pořádku ošetřeny právní aspekty, tedy license.
A v neposlední řadě školení – a to se týká jak proškolení školitelů, tak aby mohli školit, stejně tak testerů, kteří budou těmito školiteli školeni.
Rozdíl mezi ostrým prostředím by měla být možnost zachycovat detailně aktivitu testera, stejně jako např. možnost vzdáleného přístupu pro případnou asistenci.
Portfolio 