Týmy SiTD Četa Alfa Charlie Echo Roger Členové T. Doubrava M. Rosta R. Fačevic T. Římský P. Zlámal J. Zlámal J. Svoboda J. Werner M. Kyral M. Mackovík P. Mlčoch D. Walter M. Grohmannová náhrada za OM Zodpovědnost Podpora uživatelů IS Callcentrum IS ESZUS IS Rothschild Obnova IT IS Věřitel IS Výkupy nemovitostí IS Docházka IS Adresy IS Inventarizace IS RSAS IS Mezixicht/XY sekce Zadavatelé Kdokoliv P. Kuba P. Klapková J. Chlebaňová M. Studeníková M. Fišerová J. Cholinský M. Krejčí O. Telička J. Plášilová M. Zatloukalová M. Zatloukalová S. Talpová M. Seidlová M. Studeníková E.Pařenicová E. Hesounová E. Benková K. Hubáček L. Juráňová T. Vojkůvka P. Říha
LAMPÁRNA 1. Věškeré úkoly na SiTD by měly jít přes Lampárnu. E-malem nebo přímým zadáním (jen zadavatelé) 2. 4 typy úkolů: Podpora: Žádost na oddělení podpory (přesuny smluv; změny ve splátkách, úhradách a jiných datech smlouvy; změny v žádostech atd.). Obecně tedy: změny v uložených informacích Chyba: Hlášení chyby vyskytnuvší se v systému (Hups!!!). Obecně tedy: něco nefunguje jak fungovalo. Požadavek: Návrh nebo žádost o změnu funkčnosti systému (další políčka, vyhledávání, jiné ikony atd). Obecně tedy: vše funguje, ale mohlo by fungovat lépe, kdyby... Zadání požadavku bude přijato pouze od vybraných osob, tzv. zadavatelů. Jejich seznam je níže. Statistika: Žádost o vyhotovení statistiky či přehledu, které se nedají získat uživatelem přímo z IS 3. V Lampárně vidí všichni projekt Obecné, ostatní projekty vidí jen odpovídající zadavatelé. Jiným uživatelů chodí informační emaily o změnách. Časem se to možná upraví, aby mohli ostatní vidět úkoly, které zadali.
Aktuální způsob zpracování úkolů Zadavatel nastavuje prioritu: Okamžitá - znamená přerušit jakoukoliv práci a okamžitě se věnovat tomuto úkolu (stojí pobočka, nefunguje celý systém) Urgentní - znamená že ze všech mnou zadaných úkolů je tenhle nejdůležitější a měl by být vyřešen co nejdříve jak to jen půjde Vysoká - znamená ze všech mých úkolů jsou tyto důležité a rád(a) bych je měl(a) přednostně Normální - znamená běžné zařazení do fronty ke zpracování Nízká - může počkat až bude volněji Pořadí zpracování vybírá SiTD podle nastavené priority a svého uvážení. A podle sympatií k zadavateli nebo jeho nátlaku. Změny se nasazují hned jak jsou hotové. Vzniká riziko každodenních výpadků. DOSTI NEPŘEHLEDNÉ A NEPLÁNOVATELNÉ! Jak z toho ven? Zbavíme se zodpovědnosti za výběr!
Nový postup zpracování úkolů 1. Úkoly se shromažďují v Lampárně (tzv. PRODUCT BACKLOG), navrhnout je může kdokoliv(i tým). 2. Zadavatel(é) je řadí podle důležitosti (libovolný počet priorit) 3. Tým ohodnotí náročnost každého úkolu, popř. si vyžádá podrobnější informace. 4. Tým určí kapacitu (max počet bodů) pro další Sprint (dovolená, nemoc atd.) 5. Zadavatel vybere úkoly pro následující sprint. Suma jejich náročnosti musí být menší než kapacita Sprintu. 6. Vybrané úkoly se změní do stavu Do příštího sprintu (tj.přesunou do Sprint Backlogu) 7. Na začátku Sprintu se všechny úkoly ve stavu Do příštího sprintu změní na V aktuálním sprintu a začnou se zpracovávat. 8. Zpracovaný úkol se uzavře (možno přidat stav k hodnocení ). 9. Během sprintu se zpracovávají jen úkoly ve Sprint Backlogu a žádné jiné! Úkoly v Sprint Backlogu se nemění! Tým tak není vůbec rušen. Podporu, Chyby a Statistiky řeší tým podpory. 10. Na konci Sprintu jsou (ideálně) všechny úkoly uzavřené a OTESTOVANÉ. Lze je prezentovat zadavatelům a nasadit do ostrého provozu. 11. A může začít nový Sprint ( kroky 5-10) Co získá z nového postupu zadavatel? Možnost VÝRAZNĚ ovlivnit co a kdy bude implementováno. Přesné určení data nasazení dané změny. Omezení výpadků za provozu (Součástí Sprintu je i otestování a uniklé chyby by se projevili jen těsně po sprintu/nasazení) Zrychlení vývoje Co tratí? svůj čas, který musí věnovat určení priorit a vybrání úkolů do dalšího Sprintu svůj čas, který musí věnovat domluvě s dalšími zadavateli pro daný tým možnost zavolat konkrétního programátora a chtít něco přidat ihned
Technické podrobnosti Měříme v bodech (story points). Plánovaná delka Sprintu 2 týdny, resp 9+1 pracovní den. První odhad kapacity týmů 160 bodů, ten bude dále upravován podle ukončených Sprintů. Zpočátku velké riziko přecenění/podcenění týmu. Úkol který nebyl v rámci Sprintu uzavřen je vrácen do Product Backlogu (s novým hodnocením náročnosti). Hodnocení náročnosti pouze 1, 4, 10, 20, 40 nebo 80 body. Větší náročnost je potřeba rozložit. Programátorům budou odebrány mobily (omezení rušení během Sprintu), pokud budou potřebovat tak zavolají z pevné linky. Pokud to bude nutné, tak se budem i zamykat. Sprint meeting: schůzka týmu, zadavatele a scrum mastera, kde se hodnotí předchozí Sprint a plánuje nový. Navrhuji středu (většinou se nic nemusí stihnout do večera a nikdo nemá prodloužený víkend). V jedné schůzce by se dalo zvládnout hodnocení předchozího Sprintu i plánování následujícího. Tj. Jen jedna schůzka za 2 týdny. Pro Martu Studeníkovou 2 schůzky (ten samý den). Zadávání/upřesnění úkolů ve formě: Jako ROLE chci mít možnost UDĚLAT NĚCO, abych tím získal BENEFIT. A jasné určení akceptačních podmínek pomocí uživatelského scénáře. Například: Jako backoffice chci mít možnost zaznamenat zesplatnění smlouvy, abych mohl vytisknout dopis pro klienta s platnými údaji a odeslat ho. Scénář: Na detailu smlouvy kliknu na zatržítko zesplatnění a následně vidím, že je smlouva označena jako zesplatněná a já kliknout na dopis o zesplatnění a vytisknout ho. Jiný scénář: Na detailu smlouvy zadám datum k jakému dni zesplatnit, kliknu na tlačítko Zesplatnit a hned se mi zobrazí dopis o zesplatnění který mohu vytisknout.