• 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
  * łączny czas realizacji projektu może być dłuższy niż w modelu kaskadowym
• zmiany w składzie zespołu mogą poważnie zakłócić pracę
• końcowy produkt może znacznie odbiegać od pierwotnych założeń

Scrum //to lekki framework, który pomaga ludziom, zespołom i organizacjom wytwarzać wartość dzięki adaptacyjnym rozwiązaniom złożonych problemów. //
Scrum Guide 2020, https://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
• ramy czasowe (timebox) - sprint i każde zdarzenie mają ograniczony czas trwania
• filary empiryzmu: przejrzystość, inspekcja i adaptacja (zasady proste, ale nie zawsze łatwe do zastosowania)

• Product Owner
  odpowiada za maksymalizację wartości produktu, zarządza backlogiem produktu i kontaktem z klientem
• Developers (w starszych wersjach Scrum Guide: Development Team)
  tworzą w każdym sprincie użyteczny przyrost produktu
  specjaliści o różnych kompetencjach (cały zespół scrumowy liczy zwykle do 10 osób),
  międzyfunkcjonalność i samoorganizacja
• Scrum Master
  odpowiada za wdrożenie Scruma i skuteczność zespołu: wspiera zespół i organizację w stosowaniu zasad Scruma oraz usuwa przeszkody

• Product Backlog - uporządkowany wykaz prac produktu, nakreśla znane i najlepiej rozumiane wymagania. Zmienny i zazwyczaj niekompletny. Zobowiązanie: cel produktu (Product Goal).
• Sprint backlog - plan prac na sprint: cel sprintu (Sprint Goal), wybrane elementy PB i plan ich realizacji
• Sprint - pojedyncza iteracja (maksymalnie miesiąc, zwykle 1-4 tygodnie)
  planowanie → realizacja → przegląd sprintu → retrospektywa
• Przyrost (Increment) - konkretny krok w kierunku celu produktu, spełniający definicję ukończenia (Definition of Done)
• Work Item - jednostka pracy, zgłoszenie, zadanie do wykonania w określonym czasie przez członka zespołu

• Planowanie sprintu - max. 8 h (dla sprintu miesięcznego, krócej dla krótszych); ustalenie celu sprintu (Sprint Goal), wybór elementów z Product Backlogu i plan ich realizacji; zakres można doprecyzowywać w trakcie sprintu, o ile nie zagraża to celowi sprintu
• Codzienny scrum - spotkanie Developers trwające 15 min., codziennie o tej samej porze i w tym samym miejscu; inspekcja postępów w kierunku celu sprintu i dostosowanie planu na kolejne 24 godziny
• Przegląd - max. 4 h (dla sprintu miesięcznego); prezentacja wyników interesariuszom, omawianie postępów w kierunku celu produktu i aktualizacja Product Backlogu
• Retrospektywa sprintu - max. 3 h (dla sprintu miesięcznego); inspekcja przebiegu sprintu (relacje członków, procesy, narzędzia, definicja ukończenia) i plan usprawnień na kolejne sprinty

• Work items - listy zadań przypisanych do Ciebie, obserwowanych i ostatnio przeglądanych
• Boards - karty (work items) przeciągane między kolumnami; praktyki Kanban
• Backlogs - planowanie i porządkowanie pracy; backlog produktu oraz backlogi portfolio (Feature, Epic)
• Sprints - zadania sprintu, Taskboard, planowanie pojemności
• Queries - zapytania, masowe aktualizacje, wykresy dla pulpitów
• Delivery Plans - kalendarz dostarczanych funkcji i zależności między zespołami
• Analytics views - raporty Power BI oparte na danych Azure Boards
• interfejs został odświeżony (wydajność, dostępność, nawigacja klawiaturą); funkcje pozostały bez zmian

Proces wybiera się przy tworzeniu projektu; określa typy zadań i stany. Dalej: przykłady na procesie Scrum.

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

• Rodzaj: task, bug, impediment (w procesie Agile: issue), product backlog item (w procesie Agile: user story), test case, …
• Pola zależą od procesu wytwórczego (Basic, Agile, Scrum lub CMMI) 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, pól i procesów (procesy dziedziczone w interfejsie webowym; XML w instalacjach lokalnych)
• integracja z systemem kontroli wersji (Azure Repos, GitHub), z systemem buildów, testów
• połączenia zadań z różnymi zasobami: strony www, dokumenty, multimedia, załączniki (do 100 na zadanie, do 60 MB każdy), commity, pull requesty i buildy

• Product Backlog Item, Tasks - wymagania backlogu projektu i zadania sprintu
• Bug - defekty kodu
• Impediment - przeszkody blokujące pracę zespołu
• Epic, Feature - grupowanie zadań w bardziej pojemne scenariusze

• tablice Kanban: karty przeciągane między kolumnami, wizualizacja przepływu pracy i łatwe śledzenie postępów
• szybkie dodawanie elementów (New item) i zadań podrzędnych bezpośrednio na tablicy; zmiana stanu przez przeciągnięcie karty

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

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

• stany: New → Approved → Committed → Done (oraz Removed)

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

• stany zadania: To do → In progress → Done

• Capacity - ilość czasu, jaką członkowie zespołu przeznaczają dziennie na pracę (godziny na dzień, z uwzględnieniem urlopów i dni wolnych)
• pola zadania: Original Estimate, Remaining Work (zasila capacity i burndown sprintu) oraz Completed Work

• listy zadań filtrowane przez zapytania (edytor zapytań, masowa aktualizacja zadań)
• wykresy statusu i trendu oparte na zapytaniach, import i eksport z Excela oraz CSV

• widgety z informacjami o projekcie (m.in. burndown sprintu, prędkość zespołu)
• raporty Power BI oparte na usłudze Analytics

• utworzenie gałęzi bezpośrednio z zadania (wymagania)
• otwieranie i weryfikowanie pull requestów powiązanych z zadaniami
• powiązanie buildów i wdrożeń z zadaniami oraz śledzenie statusu wdrożenia
• pełna ścieżka zmian: od wymagania do produkcji
• GitHub - powiązanie commitów, pull requestów, gałęzi i zgłoszeń (issues) z zadaniami Azure Boards
• Microsoft Teams i Slack - powiadomienia i praca z zadaniami w komunikatorze
• rozszerzenia z Azure DevOps Marketplace oraz Azure DevOps REST API
• import i eksport zadań z Excela i CSV

• area path - podział pracy według produktu lub obszaru; iteration path - sprinty, wydania i kamienie milowe
• każdy zespół ma własny backlog, tablice i sprinty, wyznaczone przez domyślny area path i iteration path
• hierarchia area path powinna odzwierciedlać potrzeby raportowania (rollupy)
• zespół decyduje, czy błędy (bugs) są widoczne na backlogu razem z elementami PB

• własne procesy, typy zadań, pola i stany tworzy się przez dziedziczenie procesu; zmiany dotyczą wszystkich zespołów, więc wprowadzaj je z umiarem i komunikuj z wyprzedzeniem
• kolumny tablicy wynikają ze stanów zadań; zespół może dodawać własne kolumny i swimlanes oraz dostosować karty
• własne pola: tylko te potrzebne do raportowania lub automatyzacji (do 1024 pól na proces); listy wyboru zamiast wolnego tekstu
• uprawnienia: proces - Project Collection Administrators, obszary i iteracje - Project Administrators, ustawienia zespołu - administratorzy zespołu

• Azure DevOps MCP Server pozwala asystentowi AI (np. GitHub Copilot w trybie agenta) odpytywać dane Boards, tworzyć i aktualizować zadania językiem naturalnym
• przykłady zapytań:
  • Wyświetl tytuł, stan i osobę przypisaną dla zadań #100, #101 i #102 w projekcie Contoso
  • Dodaj do user story #1234 trzy zadania: projekt interfejsu, implementacja API i testy jednostkowe
  • Pokaż wszystkie aktywne błędy w projekcie Contoso z priorytetem, osobą przypisaną i datą utworzenia
• wyniki należy weryfikować: asystent AI proponuje, a decyzje dotyczące planu pracy podejmuje zespół

• utworzenie gałęzi bezpośrednio z zadania oraz powiązanie commitów i pull requestów z zadaniem
• powiązanie w komunikacie commita: git commit -m „Zmiana związana z zadaniem #123”
• zadania można przeglądać i edytować w Web Portal oraz w środowiskach programistycznych (Visual Studio, VS Code)
• starszy widok zadań (legacy) w Visual Studio nie jest rozwijany i ma zostać usunięty w przyszłym wydaniu

• Ken Schwaber, Jeff Sutherland, Scrum Guide (aktualna wersja z 2020 r., dostępna także po polsku)
• Manifest Agile
• What is Azure Boards?
• Plan and track work in Azure Boards
• Configure and customize Azure Boards
• Scrum process in Azure Boards
• Azure DevOps MCP Server