Zarządzanie projektem w Azure Boards

<fs xx-small>Źródło: wikipedia.org</fs>

• Model kaskadowy (waterfall), wodospadowy, liniowy
  Kolejne etapy następują po sobie bezpośrednio

Zalety:

• klient wie dokładnie czego się spodziewać. Precyzyjnie określenie tego co program będzie realizował w ostatecznej wersji.
• możliwe całościowe oszacowanie kosztów i czasu trwania projektu.
• projekt dobrze udokumentowany na każdym etapie
• stabilność i bezpieczeństwo, np. dzięki bogatej dokumentacji nowa osoba może być szybko wdrożona do projektu
• łatwy nadzór

Wady:

• brak możliwości powrotu do wcześniejszych etapów
• początkowe założenia są bardzo istotne, projekt musi być w całości zaplanowany i wszystkie wymagania muszą być rozpoznane od początku projektu
• błąd popełniony w początkowej fazie może mieć drastyczny wpływ na całość projektu
• produkt jest testowany wyłącznie na końcowym etapie. Późne wykrywanie błędów podnosi koszty.
• brak uwzględnienia zmian w zapotrzebowaniu klienta, rynku, zmian w technologiach

• podejście przyrostowe: produkt rozwijany w iteracjach, każda iteracja dostarcza działające i przetestowane funkcje
  * szybkie wytwarzanie oprogramowania wysokiej jakości
• regularna adaptacja do zmieniających się wymagań (np. zmiana wymagań klienta)
• późne zmiany w specyfikacji nie mają destrukcyjnego wpływu na proces wytwarzania oprogramowania
• bezpośredni kontakt, jako najlepsza forma komunikacji w zespole i poza nim (zazwyczaj małe zespoły) → mniej dokumentacji
• bardzo ważny jest odpowiedni nadzór nad procesem wytwórczym → Scrum

Wady:

• trudności z oszacowaniem czasu realizacji oraz budżetu projektu
• wymagana duża aktywność i współpraca członków zespołu, bezpośredni kontakt nie zawsze możliwy w projektach np. open source
  * sumaryczny czas wykonania projektu zazwyczaj będzie dłuższy niż w modelu kaskadowym
• zmiany personalne w zespole mogą mieć katastrofalne skutki
• końcowy produkt może znaczenie odbiegać od pierwotnych założeń

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)
• 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
• kontrola czasu - czynność musi być zakończona w określonym czasie
• przejrzystość (proste zasady) … jednak nie takie proste do zastosowania

• Product owner
  odpowiada za projekt przed klientem, zarządza backlogiem produktu
• Development Team
  odpowiada za wykonany w danym sprincie przyrost
  od 3 do 9 specjalistów o rożnych kompetencjach,
  międzyfunkcjonalność i samoorganizacja
• Scrum master
  odpowiedzialny za proces wytwarzania, organizację pracy, podział ról, przestrzeganie zasad Scruma

• Product Backlog - uporządkowany wykaz prac produktu, nakreśla znane i najlepiej rozumiane wymagania. Zmienny i zazwyczaj niekompletny.
• Sprint backlog - lista zadań w sprincie, których celem jest realizacja wymagania z PB
• Sprint - pojedyncza iteracja (7-30 dni)
  planowanie → realizacja → przegląd sprintu → retrospektywa
• Work Item - jednostka pracy, zgłoszenie, zadanie do wykonania w określonym czasie przez członka zespołu

• 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 zostało wykonane 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

• przegląd listy zadań
• filtrowanie zadań względem różnych kryteriów

• definicja elementu pracy: tytuł, opis, itd.

• Rodzaj: task, bug, impediment (issue), user story, test case, …
• Pola zależą od procesu wytwórczego (Scrum, Agile) oraz typu zgłoszenia
• Assigned to: osoba odpowiedzialna za wykonanie
• Stan, np. To do, In progress, Done
• cykl życia - możliwe przejścia między stanami
• połączenia między zadaniami: hierarchiczne lub płaskie
• 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,

• Product Backlog Item, Tasks - wymagania backlogu projektu i zadania sprintu
• Bug - defekty kodu
• Epic, Feature - grupowanie zadań w bardziej pojemne scenariusze

• tablice Kanban, łatwy sposób śledzenia postępów

• lista elementów Product Backlog
• ogólny plan prac, user story, zgłoszenie (zadania lub błędy)
• elementy PB są rozbijane na zadania sprintu

• nazwa, opis, właściciel, stan, priorytet
• effort (szacowany czas, story points), planning poker
• acceptance criteria - warunki osiągnięcia celu

• stany: New → Approved → Commited → Done

• zarządzenie zadaniami w sprincie (tablica Kanban, backlog sprintu)
• planowanie pojemności (capacity), burndown chart
• zakres czasowy sprintu

• stany zadania: To do → In progress → Done

• Capacity - ilość czasu jaką członkowie przeznaczają dziennie na pracę

• listy zadań filtrowane przez zapytania

• widgety z informacjami na temat projektu

• Team Explorer → Work Items - lista zadań
• Tworzenie zadań Team → Add New Work Item
• Tworzenie gałęzi kodu powiązanych z zadaniami
• Queries (raporty i zapytania) Team → New query
• Powiązanie zadania ze zmianami kodu w git

• Assigned to me: twoja lista zadań
• Following: śledzone zadania
• Mentioned: zadania, w których zostałeś wspomniany
• My activity: ostatnio przeglądane zadania

• Assign to me: przydziel mi to zadanie
• New Branch: nowa gałąź automatycznie połączona z zadaniem
• Complete work item: zmiana stanu zadania na Completed, Done lub Closed
• Relate to changes: powiąż ostatnie zmiany kodu z zadaniem

• możliwe także powiązanie w treści wiadomości
  git commit -m „Zmiana związana z zadaniem #123”

<fs x-small>Źródło: https://msdnshared.blob.core.windows.net</fs>

• W VS2019 domyślnie zapytania i zadania obsługiwane przez Web Portal
• Przywrócenie funkcjonalności dostępnych w poprzednich wersjach VS
  Tools → Options → Work Items → Legacy experience

• dodawanie nowych elementów pracy
• edytor zapytań i raporty zadań

• Ken Schwaber, Jeff Sutherland, Scrum Guide wersja polska
• Agile Project Management using TFS by Suliman Battat
• Vsual Studio – jak zorganizować pracę używając Scrum i GIT?
• https://agilemanifesto.org/iso/pl/manifesto.html
• Deep dive into Azure Boards