Zarządzanie Work Itemami w TFS

27
lip/09
0

predefinedqueries Jeśli chodzi o Work Itemy, omówiłem już przede wszystkim czym są, jakie nowe mechanizmy, które ich dotyczą, pojawiły się w TFS 2010 oraz opisałem nowe typy Jednostek Roboczych w MSF v5, opublikowanym wraz z TFS2010 beta1. Pomijałem jednak dotychczas temat szerszego zarządzania Work Itemami, ponieważ chciałem poświęcić temu osobny wpis. Oto i on :-)

Wyszukiwanie

Zacznijmy przede wszystkim od przejrzenia dostępnych sposobów wyszukiwania interesujących nas Work Itemów. Tworzenie zapytania o zestaw jednostek roboczych, które spełnią zadane przez nas warunki, jest banalnie proste: Klikamy prawym przyciskiem myszy na pozycji Work Items w drzewie pod team projectem i wybieramy pozycje “Add query”:

 

addquery

 

Pojawia się okno tworzenia zapytania. Moim zdaniem, jest ono maxymalnie intuicyjne. Możemy dodawać kolejne warunki w kolejnych rekordach grida, łącząc je warunkami logicznymi. Co więcej możemy grupować kolejne warunki, przez co zapytanie A and B or C można pogrupować jako (A and B) or C albo jako A and (B or C) – co może mieć istotny wpływ na zwrócone wyniki :) Naturalnie, możemy w ogóle nie grupować i zdać się po prostu na kolejność działań.

 

query1

 

Powyższy screenshot pokazuje, jak wygląda narzędzie do tworzenia warunków naszego zapytania oraz jak “dodać nawiasy”(zaznaczamy odpowiednie warunki, klikamy prawym na jednym z nich, a następnie z kontekstowego menu wybieramy pozycję “Group Clauses”). Po dodaniu odpowiednich warunków wciskamy F5 i otrzymujemy wyniki spełniające nasze kryteria. Naturalne jest, że możemy zechcieć zapisać zapytanie, żeby nie budować go za każdym razem od nowa – klasyczne Ctrl+S i pojawia nam się takie oto skomplikowane, przerażające okienko:)

 

savequery

 

Zacznę od opcji najłatwiejszej, czyli zapis do pliku. Nic nadzwyczajnego, możemy zapisać zapytanie w formacie wiq – jego zawartość do XML.
Znacznie ciekawsze jest jednak zapisanie zapytania na serwerze – możemy wtedy z dowolnego miejsca wykorzystać utworzone wcześniej zapytanie, co może być przydatne np. podczas pracy z TFS Web Access’em. W dalszej części tego wpisu poznamy jeszcze inne zastosowania. Zapytanie możemy zapisać w dwóch miejscach: albo widocznym tylko dla nas, albo dostępnym dla wszystkich członków projektu. Wprawdzie nie jest to jakieś “big wow”, ale naprawdę bardzo przydatna funkcjonalność, pozwalająca na utrzymanie porządku w projekcie(nie wnikam, jak o swoje bieżące Taski dbają poszczególni członkowie zespołu – ważne, żeby potworzyli takie zapytania, które sami rozumieją. A przy tym nie zaśmiecili wspólnego kontenera zapytań).

Co więcej, mamy możliwość skorzystania z predefiniowanych zapytań(ich lista, dostępna w MSF for agile software development v4.2, widoczna na obrazku tuż pod tytułem posta). Jak widać, jest związana z typami Jednostek Roboczych, dostępnymi w ramach procesu – stąd, jak nietrudno się domyślić, lista dla nowego MSF będzie nieco inna. Tak czy siak, mamy tu podstawowe zapytania, które twórcy procesu uznali za potrzebne dla wszystkich i umieścili jako standard. Nie jest to jednak żadna czarna magia – powstały one ma takiej samej zasadzie jak opisana powyżej :-)

Śledzenie

Work itemy śledzić możemy na wiele sposobów: najprostszy to naturalnie działanie z poziomu Visual Studio. Zespół odpowiedzialny za rozwój TFSa dał nam jednak więcej możliwości. Możemy użyć np. TFS Web Accessa(czyli dostęp przez przeglądarkę). Jak widać na poniższym obrazku, możemy korzystać z tych samych zapytań, które sobie skonfigurowaliśmy w Visual Studio.

 

 

Co więcej, możemy sobie stworzyć nowe zapytanie(lub wyedytować istniejące) w sposób bardzo zbliżony do tego, który prezentowałem powyżej, w Visual Studio.

 

webacc_qeditor

 

Web Access jest jednak najrzadziej używanym przeze mnie dostępem, chociaż nie ukrywam, że dla osób spoza zespołu developerskiego w firmie, ten sposób jest bardzo wygodny(no bo dać im Visual Studio to jak zainstalować szyberdach do malucha… ;) ).

Najczęściej natomiast używam MS Projecta. Wybieramy sobie zapytanie, którym chcemy pobrać Work Itemy, po zwróceniu wyników wybieramy, które pozycje konkretnie nas interesują i wuala: możemy sobie dziergać :)

 

 

Po skończonej pracy, korzystając z opcji Publish wysyłamy zmiany do Servera. Naprawdę praca jest bardzo wygodna, a gdy teraz, w nowej wersji, dodano możliwość tworzenia hierarchii zadań, to powinien być już w ogóle total wypas :)

Przedostatnim sposobem, który chciałbym omówić jest dostęp z Excela – wiadomo, narzędzie jest niezwykle popularne, a przy tym doskonale się tutaj nadaje, więc nie można było go pominąć. Dla mnie wszystko, czego potrzebuje ma Project + Visual Studio, ale czasem zdarza się, że nie chce odpalać VS i z poziomu Excela ciułam sobie coś na TFS ;) Nie będę już wklejał screenshota, bo nic wielkiego się tu nie dzieje. Ponownie, po skończonej pracy możemy zapisać zmiany jednym szybkim kliknięciem w “Publish”.

Na koniec zostawiłem furtkę, jaką dla nas, developerów zostawiono. Mianowicie – TFS wystawia cały zestaw Web Service’ów, za pośrednictwem których możemy sobie na nim pracować. Przygotowano oczywiście kilka WebMethod, z których można skorzystać, żeby dobrać się do Work Itemów. Tak więc możemy napisać sobie dowolny własny tool, służący np. do operacji na Jednostkach Roboczych. Postaram się poświęcić temu tematowi osobny wpis(albo nawet całą serię, bo to duży obszar :) ).

Co tam Panie w nowej wersji?

Na koniec naturalnie zaglądniemy do TFS 2010, żeby sprawdzić, co tam nowego słychać w temacie wyszukiwania i śledzenia Work Itemów. Sam mechanizm Team Queries/My Queries pozostał ten sam. Sposób wyszukiwania – ten sam. Co więc jest nowego? Sposób wyświetlania. Z uwagi na możliwość tworzenia hierarchii Tasków, możemy je wyświetlić w strukturze drzewiastej. Jak widać, wielkie zmiany nie zaszły… Ale generalnie – czy powinny zajść?

 



Work itemy w TFS 2010 część 2 – MSF v5.0

21
lip/09
0

Zgodnie ze wstępem do części pierwszej, w tym odcinku spojrzymy na nowe typy jednostek roboczych, jakie pojawiły się w MSF for agile software development v5. Przede wszystkim jednak dwa zdania wyjaśnienia, czemu tak uparcie wszędzie wypisuję pełną nazwę(“…for agile software development”) – otóż Microsoft Solutions Framework ma dwa nurty: “zwinny”, czyli ten, na którym się koncentruję oraz bardziej sformalizowany, MSF for CMMI Process Improvement.
Na codzień pracuję z wersją agile, dlatego ten wpis będzie opisywał właśnie tą “zwinniejszą” wersję. MSF for CMMI Process Improvement jest zbudowany na jej bazie, ale z uwagi na większą formalizację i większą porcję informacji, którymi należy zarządzać, mamy tam więcej typów Work Itemów.
Zainteresowanych różnicą w filozofii obu nurtów odsyłam do tego wpisu bloga agilemanagement.net.

No ale w końcu co tam mamy nowego?

Shared Step

Zaczniemy od pierwszego typu Jednostki roboczej, którego wcześniej nie było: Shared Step. Kiedy i dlaczego chcielibyśmy tworzyć taki work item? Wyobraźmy sobie, że mamy wiele różnych scenariuszy testowych, które mają jakiś wspólny krok, lub zestaw kroków. Generalnie nikt rozsądny nie chciałby ich ręcznie kopiować do tych scenariuszy, nie mówiąc już o zarządzaniu zmianami… W takiej sytuacji tworzymy sobie Shared Step i, jak się za chwilę przekonamy, możemy go swobodnie wykorzystywać w innych Work Itemach. W ramach jednostki tego typu możemy dodawać cały zespół akcji wraz z oczekiwanym rezultatem każdej z nich.

 

 

Shared Step przyjmuje dwa stany: Active i Closed. Z tego co sprawdziłem, przełączenie w stan Closed nie powoduje usunięcia(ani wyróżnienia) z miejsc, gdzie “wspólne kroki” były wykorzystywane. Być może będzie to miało wpływ np. na zautomatyzowane testy(Zamknięty Shared Step nie będzie wykonywany? ale to by nie było za mądre).

Przy okazji tego pierwszego work itema muszę zwrócić uwagę na jedna drobną niedogodność: nie ma jeszcze dokumentacji do MSF v5 :] Istnieje pre-release, zawierający często tylko tekst:

[This topic is pre-release documentation and is subject to change in future releases. Blank topics are included as placeholders.]

This topic represents content that might ship in a future release.


Test Case

Skoro mamy już stworzone kroki, z których możemy budować scenariusze testowe – to je zbudujmy! :-)

 

 

Jak widać na powyższym screenshocie(żeby rzeczywiście było “widać”, warto w niego kliknąć – taki tip of the day ;) ), stworzyłem sobie scenariusz testowy dla dokonywania zakupu, zawierający dwa zestawy “wspólnych kroków”: Sprawdzenie ceny produktu oraz Dokonania zakupu produktu.

Dla parametrów, jakie zostały zaproponowane przy projektowaniu tych kroków można podać kilka zestawów wartości, które powinny zostać przetestowane i jak się domyślam, podczas uczenia automatu, możemy te wartości wykorzystać. Piękne!
Ponadto, możemy w 3 zakładce określić, które zadania (Work Itemy typu Task) są testowane za pomocą aktualnie edytowanego Scenariusza Testowego.

Stany, jakie przyjmuje Test Case to Design, Ready, Closed. Zakładam, że Closed to standardowy stan wspólny dla wszystkich work itemów służący do KKnD(Krush, Kill 'n' Destroy) jednostki roboczej. Design to coś na zasadzie “draftu”, Ready to stan, w którym scenariusz jest opublikowany i wykorzystywany.

Task

Task to Work Item dobrze znany z poprzednich wersji MSF. Niezwykle istotną nowością jest możliwość tworzenia hierarchii zadań(pisałem o tym w poprzednim odcinku). Swoją drogą nie wyobrażam sobie, żeby Task zniknął z listy dostępnych jednostek roboczych(można mu oczywiście zmienić nazwę na jakąś fikuśną).

User Story

Jest to jedyna jednostka robocza, która została opisana w dokumentacji na MSDN do momentu pisania tego posta :) Postaram się nie robić tłumaczenia z angielskiego na polski, tylko po swojemu opisać czym jest User Story. Dla mnie to trochę następca Scenario z poprzedniej wersji MSF.

Opisujemy tutaj m.in. co użytkownik powinien być w stanie osiągnąć w naszym systemie, jakie będą kryteria odbioru danej funkcjonalności itp. Z punktu widzenia osoby prowadzącej projekt niezwykle przydatna jest funkcja przypisywania Tasków do danego Scenariusza(dla mnie pomimo zmiany angielskiej nazwy, po polsku “scenariusz” to właściwy odpowiednik) – dzięki temu możemy łatwo podejrzeć, na jakim etapie są zadania realizujące daną funkcjonalność.

Dodatkowo mamy możliwość przypięcia Test Case’ów, co pozwala na sprecyzowanie, że dana funkcjonalność jest testowana przez dane scenariusze testowe:

 

 

Issue

Najbardziej tajemniczy dla mnie Work Item. Z dostępnych pól ciężko wnioskować, co dokładnie ma się tutaj dziać, nie wiem też czy jest to inna nazwa dla release’u, czy chodzi raczej o określenie jakiegoś problemu albo innej zagwozdki. Jakieś pomysły?

Bug

Last but not least :) Drugi z Work Itemów(obok Taska), który przedarł się z wersji 4.2 do 5.0. W nowej wersji znalazło się jednak trochę udogodnień: po pierwsze możemy umieścić informacje o systemie, w którym doprowadzono do błędu. Poza tym coś, do czego już się zdążyliśmy przyzwyczaić przy wcześniejszych Work Itemach, czyli podpinanie innych typów Jednostek roboczych. W tym wypadku możemy wskazać Scenariusze testowe, które sprawdzają występowanie danego błędu.

 

Podsumowanie

Czy zmiany w MSF zasługują aż na podbicie wersji? Moim zdaniem tak. Na pewno są teraz mocniej powiązane ze sobą. Co jednak dziwi, to brak work itemów takich jak Risk, czy też QoS Requirement. Czyżby zarządzanie ryzykiem przestało być istotne, z punktu widzenia twórców MSF? A może po prostu stwierdzono, że zarządzanie ryzykiem powinno odbywać się poza TFS?

Kończąc jeszcze raz chciałbym podkreślić, że z uwagi na brak oficjalnej dokumentacji, opis nowych Jednostek Roboczych to w dużej mierze moje przypuszczenia co do ich zastosowania i zarządzania nimi. Zapraszam do dyskusji, może ktoś mnie oświeci przynajmniej w zakresie zagadkowego dla mnie Issue :-)



Ograniczenia nazw w Team Foundation Serverze

18
lip/09
0

Znalazłem na MSDNie ciekawy artykuł, opisujący ograniczenia i zasady nazewnictwa różnych obiektów w TFSie. Można się tu dowiedzieć nie tylko jak długa może być np. nazwa Team Projectu, czy też nazwa grupy, ale też jaka jest maksymalna wielkość Szablonu projektu(2GB). Najciekawsze jednak dla mnie są ograniczenia dotyczące wielkości załączników do Work Itemów(aż wstyd że nie wiedziałem dotychczas, ale w sumie dodając głównie screenshoty ciężko przekroczyć limit :P). Domyślna granica to ~4 MB, ale można ją zwiększyć aż do 2 GB.

Doskonałe źródło informacji, pozwalające rozwiązać głupie problemy(np. użycie niedozwolonego znaku w nazwie projektu), które jeśli nie są dobrze opisane przez pojawiający się błąd, to można stracić na nich sporo czasu.

Polecam :)



Work itemy w TFS 2010 – część 1

15
lip/09
0

head_part1

Po poprzedniej publikacji, gdzie opisałem czym są Work Itemy, czas na post dla wszystkich, którzy troszkę już pracowali z Work/ Itemami i zastanawiają się czy rzeczy, które ich denerwowały zostały usprawnione, czy to co uwielbiali nadal jest tak dobre oraz co pojawiło się nowego, co można znienawidzić albo polubić (-:

Wpis ten(obie części razem wzięte) będzie dotyczył dwóch spraw: przede wszystkim co się zmieniło, pojawiło nowego oraz co zostało usprawnione jeśli chodzi o zarządzanie work itemami w Team Foundation Serverze 2010. Druga część to omówienie MSF for agile software development v5.0. Każda nowa wersja TFS wiąże się z wypuszczeniem nowej wersji MSF. Podbicie numeru wersji Microsoft Solutions Framework z 4.2 do 5.0 może zwiastować, że nie mamy do czynienia ze zmianami kosmetycznymi. Ale o tym w drugiej części wpisu :)

 

Klasyczne “co nowego” :)

Pierwszy, a zarazem najbardziej rzucający się w oczy punkt programu to rich text editor służący do wprowadzania textu w polu History. Wprawdzie w poprzedniej wersji dało się wkleić(np. z worda) jakiś fragment, ale tutaj mamy normalny, prawdziwy, elegancki rich text editor :)

Ciekawe jest to, że w wersji 2008 można było wkleić rich text w pole description(nie było rich text editora), ale i tak zapisywało się jako zwykły text. Tutaj nadal nie mamy rich text editora, ale możemy wkleić “bogaty” text i co więcej – zapisze się w równie “bogatej” wersji ;) Ciekawe, dlaczego w takiej sytuacji pole nie posiada odpowiedniego edytora.

Prawdziwa perełka jednak to łączenie work itemów. Poniżej zamieszczam kilka screenshotów(kliknięcie na każdy powoduje otwarcie wersji powiększonej). Na pierwszy ogień przypinanie do jednostki roboczej typu “bug” jednostek roboczych typu “Test Case”(zgodnie z opisem na formularzu, jest to wskazanie work itemów, testujących dany błąd). Jest to jednak podpięcie charakterystyczne dla work itema typu Bug(np. dla work itema typu Task, nie mamy możliwości podpięcia Test Case’a)

 

 

Drugi przykład zaprezentuję ponownie wykorzystując Buga, jest to jednak już mechanizm dołączania informacji do jednostek roboczych wspólny dla ich wszystkich typów:

 

 

Co ciekawe, do każdego work itema możemy przypiąć np. konkretny plik z source controla, konkretny changeset, hiperłącze, pokrewny work item itp. Narzędzie daje nam możliwość naprawdę elastycznego uzupełnienia doprecyzowania jednostek roboczych.

Na koniec jednak, zgodnie z zasadą najstarszych Indian(“najlepsze na koniec”), zostawiłem sobie wisienkę na torcie:

Z Work Itemów typu Task nareszcie można tworzyć hierarchię!!

Jest to coś, czego mi chyba brakowało najbardziej w wersji 2008. Zarządzając zadaniami z poziomu Projecta, podczas tworzenia zadania, na które składało się kilka innych, musiałem pamiętać o tym, żeby opublikować tylko te najbardziej “atomowe”(czyli te najniżej w hierarchii), bo inaczej na TFS robił się śmietnik, a hierarchia nie była odzwierciedlana(btw. może ktoś znalazł jakieś inne ciekawe obejście tego problemu? Do produkcyjnej migracji na TFS 2010 jeszcze pewnie trochę czasu upłynie, więc każdy hint może ułatwić życie:) ).

Poniżej screenshot jak łączenie tasków będzie wyglądało w najświeższym TFSie:

 

 

W tym przykładzie podpiąłem podzadanie do nowo tworzonego zadania. Mógłbym na tym etapie wskazać więcej niż jeden Task, ale dla czytelności przykładu wybrałem tylko jeden, o szczęśliwym ID 13 :-)

Po pobraniu tych Work Itemów do Projecta, od razu pobierają sie w formie ustrukturyzowanej, a dodatkowo oba mają ustawione Publish and Refresh na Yes:

 

 

A co starego, ale dobrego?

Jedną z moich ulubionych możliwości, związanych z Work Itemami jest przypinanie do nich check-inów. W TFS 2010 opcja ta oczywiście pozostała. Z tego co zauważyłem, nie została szczególnie rozwinięta, ale w sumie nie mam pomysłu co tam by można usprawnić. Jest czytelnie, sprawnie i przejrzyście. Jako że podobno lepsze jest wrogiem dobrego, trzymam kciuki, żeby taka forma tej funkcjonalności przetrwała już do oficjalnego release'u ;)

Druga sprawa to edycja zapytań do work itemów. Znowu – jest ok, sprawdza się w codziennych zastosowaniach. Nie psuć! :-)

Podsumowanie + Coming next…

Udało mi się przedstawić zaledwie kilka nowości, związanych z work itemami, wprowadzonych w Team Foundation Serverze 2010. Należy pamiętać, że nie jest to jeszcze ostateczny release i coś się może zmienić. W każdym bądź razie zapowiada się ciekawie, a samo łączenie Tasków w hierarchię to już prawdziwe święto lasu :)

Między wierszami przemyciłem troszkę informacji o nowych typach Work Itemów(udało mi się jednak zachować tajemnicę, bo wspomniałem tylko o jednostkach typu Test Case). W następnym wpisie dokładniej przyjrzę się nowym Work Itemom, jakie zostały zaproponowane w MSF for agile software development w wersji 5. Podsycając ciekawość dodam, że ze starej wersji zostały tylko Bug i Task :)



Work items, czyli jednostki robocze

07
lip/09
0

wi_menu W poprzednim wpisie wspomniałem o work itemach. Polskie (oficjalne?) tłumaczenie to “jednostki robocze”. Ręka w górę, kto jest w stanie intuicyjnie wywnioskować z angielskiej, lub z polskiej nazwy, o co w ogóle chodzi :) Być może brzmi znajomo dla kilku osób, związanych z project managementem. Wg słownika serwisu 4pm.pl, Work item to część projektu, która może zostać jednoznacznie wydzielona i zidentyfikowana. Ok, fajna definicja, ale nadal może brzmieć obco ;)




Work item w kontekście TFS

Dlaczego w ogóle poruszam ten temat? Team Foundation Server wykorzystuje Jednostki robocze do przedstawiania jakiegoś fragmentu informacji o projekcie. Dla przykładu, metodyka MSF for agile software development v4.2 , której template otrzymujemy razem z instalacją TFS 2008, zaleca wykorzystywanie następujących jednostek roboczych: Scenariusz(Scenario), Wymagania dot. jakości – coś na kształt wymagań niefunkcjonalnych(Quality of service requirement), Zadanie(Task), Ryzyko(Risk) oraz Błąd(Bug). Możemy więc np. kontrolować postępy prac za pomocą zadań, testerzy mają możliwość zgłaszania błędów za pomocą jednostki typu błąd, czy też w łatwy sposób powinniśmy wyszukać scenariusze, których jeszcze nie zbudowano. Ponadto jesteśmy w stanie wygenerować sobie raport prezentujący np. liczbę(albo przyrost) błędów w czasie trwania projektu. Niesłychanie przydatną funkcjonalnością jest również powiązanie check-ina(czyli wrzucenia kodu do repozytorium) z jakąś jednostką roboczą, dzięki czemu możemy wyciągnąć później wszystkie zmiany w kodzie, związane z danym, albo rozwiązujące błąd.

 

Wymieniłem powyżej 5 różnych typów(kategorii) work itemów. Co jednak odróżnia jeden typ od drugiego, po co wprowadzono w ogóle taki podział? Zalet jest kilka:

  • przede wszystkim uporządkowanie w celu zarządzania nimi
  • każdy typ posiada swój własny workflow(jakie może przyjmować stany i przejścia pomiędzy stanami) – poniżej opiszę na przykładzie Błędu
  • każdy typ posiada swoje parametry. Dla buga zdefiniujemy więc np. priorytet, a dla zadania czas jego trwania
  • aż wreszcie – możemy rozszerzać definicję procesu, tworząc własne typy work itemów(postaram się poświęcić temu osobny wpis)

Definicja dla programisty :)

To tak naprawdę mała dygresja, ale może komuś będzie łatwiej przyswoić temat Work Itemów. Jeśli ktoś już czuje sie ok z work itemami i nie robi dużych oczu przy tej nazwie, może śmiało ten akapit pominąć :-)

Możnaby powiedzieć, że Work Item to abstrakcyjna klasa, z której dziedziczą takie klasy jak: Bug, Task, Risk etc. Nie możemy stworzyć instancji Work itema – tworzymy instancje “klas potomnych”. Mamy jednak pewien zestaw cech i funkcjonalności wspólnych, które są dziedziczone z tej “abstrakcyjnej klasy”.

Bug – opis

Spójrzmy sobie teraz bliżej na jeden z work itemów, czyli bug.

Przede wszystkim może znaleźć się w następujących stanach:

  • Active. Np. został właśnie założony przez testera.
  • Resolved. Np. rozwiązany przez developera.
  • Closed. Np. przetestowany ponownie, zweryfikowany przez testera.

 

 

Przy przejściach widnieje powód dla którego następuje zmiana stanu. Zgodnie z podstawowym przepływem, programista naprawia błąd i przestawia go w stan “Resolved” z uzasadnieniem “Fixed”. Tester weryfikuje i jeśli jednak nadal jest kiepsko przestawia w stan “Active”(np. z uzasadnieniem “Wrong Fix”), a jeśli błąd faktycznie został wyeliminowany – bug wędruje do stanu “Closed”. Może się jednak zdarzyć, że błąd wystąpi kiedyś ponownie – stąd możliwe przejście z powrotem do stanu “Active”.

 

W następnym odcinku…

Esmeralda dowie się, że jednak mieszka w Ekwadorze. Poza tym odkryje, co ciekawego pojawiło się w TFS 2010, jeśli chodzi o Work itemy :-) Stay tuned!