Work items, czyli jednostki robocze

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!

No Comments

Post a Comment

Time limit is exhausted. Please reload CAPTCHA.