TFS - zarządzanie projektem w metodologii Scrum

Scrum to ramy postępowania (framework), dzięki którym ludzie mogą z powodzeniem rozwiązywać złożone problemy adaptacyjne, by w sposób produktywny i kreatywny wytwarzać produkty o najwyższej możliwej wartości. Scrum Guide, http://www.scrumguides.org/

jedna z najbardziej znanych metodyk zwinnych (Agile) : Manifesto for Agile Software Development
metoda przyrostowa : produkt powstaje w kolejnych krótkich iteracjach (sprintach)
używalny (ale niekompletny) produkt już po pierwszej iteracji
częste kontakty w zespole oraz z klientem
inspekcje i adaptacje projektu sprzyjają wczesnemu wykrywaniu problemów i dopasowaniu do potrzeb
sprawna kontrola nad przebiegiem prac (narzędzia TFS)
zespoły 7+-2, zespół ma charakter samoorganizujący i międzyfunkcjonalny
kontrola czasu - czynność musi być zakończona w określonym czasie
przejrzystość (proste zasady)

Product owner - odpowiada za projekt przed klientem, ustala co ma być wykonane w kolejnych sprintach
Development Team - odpowiada za wykonany w danym sprincie przyrost. Brak podziału na rele (wszyscy są developeramin)
Scrum master - odpowiedzialny za proces wytwarzania, organizację pracy, podział ról, przestrzeganie zasad Scruma

Product Backlog - wykaz prac produktu (np. produkty WBS), nakreśla znane i najlepiej rozumiane wymagania. Zmienny i zazwyczaj niekompletny.
Sprint backlog - lista zadań w sprincie
Sprint - pojedyncza iteracja (7-30 dni): planowanie, realizacja, przegląd sprintu, retrospektywa
- planowanie sprintu - max. 8h, określenie celu sprintu, wybór zadań, czas realizacji zadań z góry ustalony, lista zadań nie powinna się zmieniać w czasie iteracji
- codzienny scrum: spotkanie 15 min. zespołu programistycznego na stojąco prowadzone przez scrum master. Co wykonane zostało i co jest do zrobienia?
- przegląd: max. 4h , podsumowanie osiągniętych celów, modyfikacja listy product becklog
- retrospektywa sprintu: max. 3h, inspekcja działań (relacje członków, procesy i narzędzia) i plany usprawnień do najbliższego sprintu
Work Item - jednostka pracy, zgłoszenie, zadanie do wykonania w określonym czasie przez członka zespołu

Fabrikam Fiber Web Team Home View - projekt demo

, Źródło: http://msdn.microsoft.com/

zgłoszenie (zadania lub błedy) nieprzydzielone do iteracji
ogólny plan prac, user story (życzenia klienta)
zmienia się w czasie prac nad projektem
elementy są zazwyczaj rozbijane na bardziej szczegółowe zadania

nazwa, opis, właściciel, stan: New → Approved → Commited → Done, priorytet
effort (szacowany czas), planning poker

Iteracja (sprint), określona w pewnym okresie czasu
Lista zadań - zazwyczaj rozbite elementy z lisy Product Backlog
Wykresy obrazujące postęp prac

Capacity - określa czasu jaki członkowie mogą poświęcić dziennie na pracę (uwzględniając dni wolne) oraz specjalizację członków zespołu

Rodzaj: task, bug, impediment(issue), user story, test case, …
Assigned to: osoba odpowiedzialna za wykonanie
Stan: To do, In progress, Done, Removed
połączenia między zadaniami: hierarchiczne lub płaskie
każdy typ posiada swój własny cykl życia
możliwość definiowania własnych typów (XML)
integracja z systemem kontroli wersji, z systemem buildów, testów
połączenia zadań z różnymi zasobami: strony www, dokumenty, multimedia,

Typowy cykl życia zgłoszenia:

osoba posiadająca uprawnienia do raportowania wprowadza informację o błędzie
osoba lub system określa osobę, której dotyczy błąd i generowane jest powiadomienie
(alerty, email i inne kanały komunikacji),
osoba, która otrzymała powiadomienie, akceptuje go do poprawy lub deleguje ten błąd do innej osoby,
osoba odpowiedzialna kończy pracę nad błędem na jeden z kilku sposobów – informując, że błąd został poprawiony, odłożony w czasie, nie jest możliwy do poprawy czy, że zgłoszenie błędu było niepoprawne,
jeśli błąd usunięto, osoba odpowiednio uprawiona osoba weryfikuje, czy błąd faktycznie został usunięty i zwykle zgłoszenie błędu jest zamykane.
po ostatecznym rozwiązaniu problemu (np. po opublikowaniu albo instalacji u klienta wersji pozbawionej błędu) błąd jest zamykany.

Żródło: http://trac.edgewall.org/chrome/common/guide/basic-workflow.png

Inne przykłady

effort - wskaźnik postępu ukończenia kolejnych funkcjonalności
każde zadanie ma określony (zaplanowany) czas realizacji
Burndown Chart

Żródło: wikipedia.org

Team Explorer → Work Items - lista zadań projektu
Team Explorer → My Work - lista zadań powiązanych z zalogowanym użytkownikiem
Queries (raporty i zapytania) Team → New query
Dodawanie zgłoszeń Team → Add New Work Item
Powiązanie zgłoszenia (Work Item, asociate, resolve) z wysłaniem kodu (Check In) do repozytorium