Řízení softwarových projektů – materiály k 3.lekci

V úterý 1.11. se za stále vysoké účasti uskutečnila třetí lekce kurzu, která se věnovala tradičnímu projektovému řízení s pomocí TFS.

Pokud vám utekla první lekce, kompletní materiály jsou zde.
Pokud vám utekla druhá lekce, kompletní materiály jsou zde.

Materiály a záznam

Prezentace ke stažení – včetně prezentace s detaily ohledně rozesílky knihy.

Záznam ke stažení nebo shlédnutí

Odpovědi na položené otázky

Otázky, stejně jako svoje odpovědi, jsem si dovolil jazykově a stylisticky upravit, případně spojit dohromady.

Organizace

Při přihlašování jsem omylem použil jiný email než při registraci. Mohu s tím ještě něco dělat?
Pošlete mi e-mail na mjurek@microsoft.com, opravím to ručně.

Budete mít nějaký kurz, který bude pojednávat více o buildech, automatických testech atd.?
Pětidílný kurz testování probíhal v lednu 2011, materiály naleznete zde. Další kurzy zatím neplánujeme.

Řízení projektů

Jakým způsobem nejlépe pro daný Work Item říci, zda potřebuje či nepotřebuje vytvořit uživatelskou dokumentaci?
Žádné standardní pole k tomu v dodávaných šablonách není. Vytvořte si vlastní pole s povolenými hodnotami Yes/No

Pokud je Task uzavřen, ale vývojář si dodatečně uvědomí, že by bylo něco v tom předchozím úkolu potřeba udělat jinak, jak to má udělat? Musí někoho žádat?
Obvyklý postup je navrácení work itemu do stavu Active s krátkým komentářem v historii, proč se tak děje. Poté je ho možné znovu zavřít. Tomuto procesu se říká reaktivace a měl by být pouze výjimečný. Jeho častější výskyt je známkou nekvalitní práce a uspěchaného postupu. Workflow ve standardních šablonách toto umožňuje, pokud si sám nenastavíte nějaká restriktivnější práva na přechody mezi stavy.

Posledně jste preferoval nedělat víceúrovňovou strukturu Tasků, nyní zmiňujete možnost do hloubky dělit - jak volit vhodnou variantu?
Je vidět, že dáváte pozor :-) Posledně jsme se bavili o agilních přístupech, kde primárně předpokládám práci ve VS a Excelu – v nich jsou sice hierarchie podporovány, ale práce s nimi není moc komfortní, je tedy lépe držet věci co nejjednodušší. Pokud jako nástroj používáte MS Project, tam jsou hierarchie výborně podporovány. Hierarchie má ještě jednu nevýhodu – hůře se dělají reporty z relační databáze (z OLAPu OK), ale to si musíte vybrat, co je pro vás důležitější

Jaké je doporučení ohledně vytváření User Story? Je dobré dělit složitější User Story na další User Story a teprve až ty jednodušší User Story na jednotlivé Tasky nebo mít jednu User Story a do ní rovnou ty tasky? Jde mi o to, jestli ty složitější do TFS vůbec zadávat a nebo tam zadávat až ty jednodušší, které se nemusí dále dělit do stromové struktury.
Proti dělení User Story na menší asi nelze nic namítnout, pokud to nebudete přehánět s hloubkou dělení. Nicméně i zadávání pouze menších User Story bude velmi dobře fungovat. Záleží, co vám více vyhovuje.

Jakým způsobem nejlépe pro daný Work Item říci, zda potřebuje či nepotřebuje vytvořit uživatelskou dokumentaci?
Žádné standardní pole k tomu v dodávaných šablonách není. Vytvořte si vlastní pole s povolenými hodnotami Yes/No.

Dá se udělat, aby Original Estimate u User Story byl definován jako součet Original Estimate všech jeho dětí?
Snadný postup na to není, na straně TFS není žádná business logika pro agregace. Můžete ovšem reagovat na události v aplikační vrstvě a něco podobného si udělat sami nebo se podívejte na tento projekt https://tfsaggregator.codeplex.com/. Otázka je, do jaké míry je to účelné, protože při sčítání přes celý strom v nástrojích jako je MS Project anebo OLAP reporty v Excelu (nad dimenzí Work Item Tree) pak bude docházet k vícenásobnému započítávání této práce.

Jak by se měla řešit situace, kdy odpracovaná doba překračuje odhadovanou dobu, ale zároveň ještě práce není hotová.
Technicky to nijak řešené není, závisí na vašich potřebách. Průběžná aktualizace obecně nefunguje dobře a nedá se na ni spoléhat, ale v tomto zvláštním případě by právě průběžná aktualizace hodin na tasku mohla sloužit jako onen zdvižený praporek (coby zvláštní událost). Samozřejmě není problém udělat si třeba dotaz „aktivní úlohy s překročenou pracností“.

Existuje plugin do VS, který by fungoval jako jakési "stopky"? Uměl by zapínat a vypínat práci na work itemu a celkový čas ukládal do příslušné položky. Tím by se zajistila aktualizace a zároveň se vědělo, kdo co dělal.
Zkuste se podívat na https://tfsworkingon.codeplex.com/, i když to nemá formu VS plug-inu. Dostal jsem též odezvu od posluchačů „takovéto stopky plánujeme pro náš office timer - www.officetimer.cz“.

Objeví se v MS Projectu i mnou definované pole z WI? Jsou i tato pole read-only atd.?
Pole se objeví pouze pokud ho uvedete v mapovacím souboru, viz https://msdn.microsoft.com/en-us/library/ms404686.aspx. Pravidla nastavená na polích ve WI se do uživatelského rozhraní Projectu nepřenáší, nicméně jsou poté validována při ukládání v okamžiku, kdy zvolíte možnost Publish.

Kde a jak je možné nastavení událostí TFS? Project Alerts se dají rozšířit?
Typ alertů může být buď e-mail anebo SOAP volání, je možné nastavovat různé filtrovací podmínky. Nastavit lze buď s příkazové řádky (bisubscribe.exe) anebo pomocí Alerts Exploreru, který je součástí TFS Power Tools.

Jde přidat i Title4 (atd.) v editaci WI v Excelu?
Ano, jde přidávat další úrovně (i když obecně nedoporučuji si to moc komplikovat).

Funkčnost a uživatelské rozhraní TFS mi z hlediska bug trackingu připadají poměrně chudé, plánují se nějaké zásadní změny do dalších verzí VS/TFS?
Ano, ve verzi 2012 se připravují podstatné změny v uživatelském rozhraní, zejména v TFS Web Accessu. Odpověděl bych konkrétněji, pokud byste se zeptal konkrétněji :-)

Potřebujeme mít před stavem "Active" ještě stav "New", teprve až když vývojář zahájí práci, tak z New udělá Active. V tu chvíli bychom chtěli automaticky vyplnit StartTime, při přechodu do Close pak EndTime. Co doporučujete - když jen přidáme stav "New" do agile šablony, tak se nám rozhodí reporty?
Podobné workflow pro úlohu bude v příští verzi šablon, která přijde s TFS 2012, předpokládám, že adekvátně budou upraveny též reporty a vše ostatní. Napadlo mne nechat stavy Active/Closed a zařadit stav InProgress mezi ně, tím se vám reporty rozhodí výrazně méně.

Mám projekt, do kterého mohou zaměstnanci hlásit chyby. Pokud chci, aby žádali též novou práci – měli by používat "Task" nebo "User story". Používám MSF Agile.
Jednoznačně typ work itemu pro požadavek, tedy User Story/Product Backlog Item/Requirement – v závislosti na použité šabloně. Pro tyto scénáře doporučuji mít ve workflow „představ“ před Active, typicky se nazývá Proposed.

Vytvořím User Story, navážu Task. Po dokončení uzavřu User Story. V případě, že tester najde chybu a User Story je již uzavřena, jak založit chybu?
Pokud se pohybujeme v rámci jedné iteraci, považuji výše popsanou situaci za procesně chybnou. Vývojář by měl převést User Story do stavu Resolved. Tester ji poté otestovat a zalogovat k ní bugy. Až vývojář všechny bugy opraví a tester otestuje, že jsou opravené správně, tester převede User Story do stavu Closed. Samozřejmě se může stát, že chyba se pro již uzavřenou User Story objeví až dodatečně, pak bych znovu User Story vrátil do stavu Resolved (nebo dokonce Active), ale to by měla být výjimečná situace, nikoliv typický postup.

V Iteraci 1 je uzavřena User Story, ale tester najde chybu v Iteraci 2. Jak toto řešit? Změnit Iteration Path u UserStory a provést reaktivaci?
Zřejmě bych iteraci 1 pokládal za historii a už se k ní nevracel. Nejjednodušší mi přijde založit nový bug (Iteration Path = Iterace 2) a navázal jej na původní User Story (Iteration Path = Iterace 1) – technicky to vůbec ničemu nevadí. Zpětné změny obsahu minulých iterací by vám způsobily chaos v reportech.

Pokud pracuje po sobě více lidí na work itemu a každý tam přidá nějaký odpracovaný čas, kdo je potom vlastníkem toho času. Oba podíl nebo ten poslední?
Vlastníkem času napsaného na work itemu je osoba vyplněná v poli AssignedTo, tedy ten poslední. I proto by měly být Tasky vytvářeny vždy pouze pro 1 osobu a měly by mít trvání v délce jednotek hodin

Kdy by se měl Requirement nebo Use Story (což je v podstatě vlastnost systému) nastavovat na Closed? Poté, co je implementovaný nebo pokud existuje v aplikaci? Myslím na případy, kdy se po čase nějaká funkčnost z aplikace odstraní. Jde mi o to, jak lze pak získat aktuální seznam funkčností aplikace? Z neuzavřených požadavků to pak může být problém.
Požadavek by měl na Closed převádět tester, případně někdo v podobné roli – tím v podstatě říkáte, že již s ním není spojená další práce, ne to, že je v produktu. Pokud chcete sledovat odstranění funkčnosti z aplikace, buď si můžete do workflow požadavku přidat další stav (např. Removed) anebo si do jeho definice přidat políčko s hodnotou Yes/No (např. IsRemoved).

Jistě je mnoho variant práce s nastavováním pracnosti na nadřízených a podřízených položkách, zvláště při postupném dělení prací - jak se k tomu postavit efektivně a co předpokládají plánovací nástroje?
Nástroje nepředpokládají celkem nic, pouze sčítají přes celý strom. Můžete si to udělat, jak chcete. Osobně preferuji nastavování pracnosti pouze na „leaf“ položkách, tedy těch, které nemají již vlastní podřízené položky. Pokud tedy např. na úloze je 6 hodin a máte potřebu ji rozdělit mezi více lidí, vytvořil bych např. tři podřízené položky po 2 hodinách a pracnost na nadřazené položce bych vymazal. Případně můžete na nadřazené položce ponechat Original Estimate a na podřízených manipulovat s Completed/Remaining. Důležité je, aby byl vždy korektní součet přes strom.

Work item typicky přechází přes více lidí, např. vývojář - > tester -> vývojář. Jakým způsobem se pak v případě Project Serveru řeší vykazování pracnosti? Konkrétně vykazování odpracovaného času přímo v TFS a ne v PS.
To co píšete typicky nastává pro požadavky (User Story, Requirement). Právě k tomu účelu slouží tasky, na které požadavky rozpadnete. Čas jednotlivých lidí se pak vykazuje prostřednictvím těchto podřízených tasků, které mají vždy právě jednoho nositele.

Pokud se mi propagují zdroje z podřazených úkolů do PS k souhrnnému úkolu (user story), co se stane pokud na tento souhrnný task přidám další zdroj?
Pokud jej přidáte dodatečně v Projectu, není způsob, jak by se přenesl do TFS, kde může být na každém work itemu pouze jeden jediný zdroj. Myšlenka TFS-PS konektoru je spíše taková, že požadavek je v PS definován a přiřazení zdrojů je již věcí mikro-řízení v TFS, nikoliv věcí „velkého“ projektového plánu.

Ostatní dotazy

Lze modifikovat vzhled TFS Web Accessu? Použít jiný skin?
Modifikace aplikace není podporovaná. Pokud vám uživatelské rozhraní nevyhovuje, můžete si vytvořit vlastní uživatelské rozhraní – TFS má zdokumentovaný objektový model.

Proč TFS a Project Server není spojen do jednoho produktu? Vždyť tam budoucnost spěje.
Netroufnu si dávat soudy, kam spěje budoucnost :-) Je třeba si uvědomit, že zaměření je přece jenom odlišné. Projektové nástroje jsou postaveny více na ekonomickou stránku projektů a zdaleka nejsou jenom pro SW vývoj. TFS je naopak orientován více na technologickou stránku vývoje. Překryv samozřejmě nějaký je, ale odlišností je víc.

Dají se schovat některé položky v TFS Web Access, např. Test Case?
Obecně TFS je postaveno na myšlence transparence napříč celým vývojovým cyklem, v oblasti schovávání a utajování dat tudíž není zrovna výkonné. Něco lze řešit přístupovými právy, např. k určité oblasti produktu (Area), ale to není pro popsaný případ moc vhodné. Dále můžete nastavit práva pro příslušnou work item query do WI, čímž ji uživatel nebude moci použít – nic mu ale nezabrání vytvořit si vlastní query.

Zabýváme se vývojem webových stránek a zavádíme TFS. Je vhodná varianta založit jeden Team Project např. Websites a do něj vkládat Solutions pro jednotlivé zákazníky, respektive weby?
Obecné pravidlo je – cokoliv se vyvíjí, verzuje a vydává jako jeden celek, patří do jednoho týmového projektu. Pokud jsou weby zákazníku jiné (pro jednoho e-shop, pro druhého intranet), tak určitě založit pro každý takový web jeden týmový projekt. Pokud naopak máte nějaký opakovatelný produkt a pro jednotlivé zákazníky ho jenom různě konfigurujete a nastavujete, mějte ho v jednom týmovém projektu pro všechny zákazníky.

V organizaci používáme Mantis pro zadávání připomínek a chyb uživateli, přiřazení vývojářům, evidenci, co v jakých verzích bylo opraveno atd. Nemáte nějakou zkušenost s propojením Mantisu na TFS - ideálně kdyby např. bylo možné propojit ChangeSet s bugem apod., případně propojení TFS/VS2010 s nějakým jiným bug tracking systémem.
Jednotlivé části TFS nelze snadno nahradit. Samozřejmě můžete používat na některé části životního cyklu TFS a na jiné části jiné nástroje, ale přijdete tak o základní synergické výhody integrace a též o jednotné úložiště dat. Je možné data z jiného systému replikovat (viz https://tfsintegration.codeplex.com/). Je však třeba zvážit, zda náklady spojené s vyšší pracností za to stojí, zda není lepší přejít na TFS jako na integrovaný systém pro celý životní cyklus. Zkuste to např. pro nějaký menší projekt a uvidíte, jak vám to bude vyhovovat.

Během tohoto týdne očekávejte závěrečný mail s případnými instrukcemi týkajícími se knihy. Zároveň jeho odeslání pro kontrolu oznámím na tomto blogu.

Michael