Work itemy w TFS 2010 część 2 – MSF v5.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 🙂

No Comments

Post a Comment

Time limit is exhausted. Please reload CAPTCHA.