TFS - zarządzanie projektem w metodologii Scrum

Cykle życia oprogramowania

Metodyki zwinne - Agile

podejście przyrostowe
zakłada, że wymagania odbiorcy (klienta) często ewoluują podczas trwania projektu → regularna adaptacja do zmieniających się wymagań
późne zmiany w specyfikacji nie mają destrukcyjnego wpływu na proces wytwarzania oprogramowania,
szybkie wytwarzanie oprogramowania wysokiej jakości, działające oprogramowanie jest dostarczane okresowo (tygodniowo), każda iteracja dostarcza działające, przetestowane funkcje
bezpośredni kontakt, jako najlepsza forma komunikacji w zespole i poza nim (zazwyczaj małe zespoły)
samozarządzalność zespołów
końcowy produkt może znaczenie odbiegać od pierwotnych zależeń

Metodologia 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)

Scrum - role

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

Artefakty i zdarzenia

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

Przykładowy projekt

Fabrikam Fiber Web Team Home View - projekt demo

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

Product Backlog

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

Product Backlog Item

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

Kanban Board

Cykl życia Backlog Item

Iteration backlog

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

Pojemność sprintu

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

Work Item - Jednostka pracy

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,

Cykl życia zgłoszenia

Cykl życia zgłoszenia - ogólnie

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.

Typowy cykl życia

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

Inne przykłady

Board

Effort

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

Raporty i zapytania

Scrum w Visual Studio 2013

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