Microsoft AZ-400: Planowanie zwinne i zarządzanie pracą — Przewodnik do nauki

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

Część Microsoft DevOps Engineer Expert AZ-400 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Microsoft, albo rozwiąż testy na czas na ExamRoll.io.

Przegląd

Zwinne planowanie i zarządzanie pracą w Azure DevOps opierają się na przejrzystym modelu danych, zdyscyplinowanych praktykach dotyczących przepływu i iteracji oraz widoczności między zespołami. Azure Boards zapewnia solidną hierarchię typów elementów pracy i elastyczne konfiguracje dla każdego zespołu, podczas gdy GitHub Projects oferuje nowoczesne, zautomatyzowane planowanie, ściśle zintegrowane z Issues i Pull Requests. Skuteczne wdrożenie zależy od rygorystycznych definicji (Definition of Done, kryteria akceptacji), spójnego szacowania (story pointy i szacowanie względne) oraz praktycznych wniosków (zapytania, plany dostarczania i metryki, w tym DORA). Poniższe sekcje szczegółowo opisują, jak projektować, wdrażać i stosować te praktyki na dużą skalę.

Model danych, szablony procesów i konfiguracja zespołu w Azure Boards

Typy elementów pracy i ich hierarchia stanowią trzon planowania. W domyślnym procesie Agile hierarchia portfolio to Epic > Feature > User Story, a Task i Bug są elementami na poziomie wykonawczym. Powiązania podrzędne (child links) odzwierciedlają dekompozycję (User Story → Task), a błędy (Bugs) mogą być zarządzane na tym samym poziomie backlogu co User Stories lub analizowane niezależnie, zgodnie z polityką zespołu. Typy powiązań są kluczowe:

Parent/Child: odzwierciedla hierarchię dekompozycji i umożliwia agregację postępu i nakładu pracy.
Predecessor/Successor: wyraża relacje harmonogramowania i zależności między elementami pracy; pojawiają się one w Planach dostarczania (Delivery Plans) jako linie zależności.
Related/Duplicate/Blocked by: modeluje relacje niehierarchiczne i przeszkody.
Artifact links: łączy elementy pracy z kodem (commitami, gałęziami, PR-ami), kompilacjami i wydaniami, zapewniając pełną identyfikowalność (end-to-end traceability).

Szablony procesów w Azure DevOps definiują stany, pola i nazewnictwo typów elementów pracy (WIT):

Agile: Elementem na poziomie wymagań jest User Story; często wybierany przez szybko działające zespoły.
Scrum: Elementem na poziomie wymagań jest Product Backlog Item (PBI); sprinty i artefakty Scrum są traktowane priorytetowo, a błędy (Bugs) można skonfigurować tak, aby zachowywały się jak PBI.
CMMI: Elementem na poziomie wymagań jest Requirement i zawiera on typy WIT dla Change Request, Risk i Review — wybierz ten szablon, gdy musisz śledzić ryzyka i formalne przeglądy.
Procesy niestandardowe (dziedziczone): W Azure DevOps Services rozszerz proces systemowy poprzez dziedziczenie (Inheritance), aby dodać niestandardowe typy WIT, stany, reguły i pola, zachowując zgodność z usługą. Użyj kategorii, aby umieścić niestandardowy typ WIT na odpowiednim poziomie backlogu. Unikaj nadmiernej personalizacji, która utrudnia raportowanie; standaryzuj pola takie jak Story Points i Remaining Work.

Zespoły to lekkie partycje konfigurowane za pomocą:

Ścieżki obszaru (Area paths): określają zakres odpowiedzialności i filtrowanie backlogu; zespoły wybierają jedną lub więcej ścieżek obszaru (opcjonalnie z obszarami podrzędnymi), aby zdefiniować „swoją” pracę.
Ścieżki iteracji (Iteration paths): reprezentują cykl wydań i sprinty; zespół wybiera domyślne i bieżące iteracje do celów planowania.
Backlogi i tablice zespołu: każdy zespół wybiera, które poziomy portfolio (Epic, Feature) mają być widoczne, style kart i mapowania kolumn, bez wpływu na inne zespoły.
Pulpity nawigacyjne zespołu: umożliwiają organizację współdzielonej widoczności za pomocą widżetów dla Velocity, wykresów spalania (Burndown/Burnup), skumulowanego diagramu przepływu (CFD), wykresów Lead/Cycle Time oraz niestandardowych widoków Analytics.

Dostarczanie oparte na przepływie z Kanbanem i nadzorem

Kanban w Azure Boards modeluje ciągły przepływ od momentu podjęcia zobowiązania do ukończenia. Skonfiguruj kolumny, aby mapowały się na stany przepływu pracy, i opcjonalnie podziel krytyczne stany na podkolumny W trakcie/Ukończone (Doing/Done), aby poprawić rozliczanie przepustowości i zredukować ukryte kolejki. Ustaw jawne limity WIP (Work In Progress) dla każdej kolumny i każdego toru (swimlane); egzekwuj je operacyjnie — przekroczenie limitu powinno wywołać rozmowę na temat usprawnień, a nie prowadzić do cichego wzrostu backlogu. Używaj dedykowanych torów (swimlanes), na przykład dla zadań pilnych (Expedite), aby wizualnie oddzielić elementy o wysokim priorytecie i ustawić dla nich niższe limity WIP.

Definicja ukończenia (Definition of Done, DoD) stanowi podstawę jakości i przewidywalności; zapisz ją w postaci polityk tablicy, wymaganych pól lub list kontrolnych przy określonych przejściach oraz powiązań z testami akceptacyjnymi. Na przykład, wymagaj powiązania „Przetestowane przez” (Tested By) z przypadkiem testowym (Test Case), który zakończył się powodzeniem, przed przeniesieniem zadania do stanu Ukończone (Done), i uwzględnij kroki weryfikacji wdrożenia podczas przechodzenia do stanu Wydane (Released).

Użyj analityki do zarządzania kondycją przepływu:

Skumulowany diagram przepływu (Cumulative Flow Diagram) weryfikuje równowagę WIP i wykrywa wąskie gardła, gdy pasma na wykresie się rozszerzają.
Lead Time mierzy czas, który upłynął od utworzenia do ukończenia zadania; Cycle Time koncentruje się na czasie od przejścia do stanu Aktywny (Active) do ukończenia. Widżet wykresu Cycle Time raportuje czas, jaki upłynął po przejściu elementu pracy do stanu Aktywny, co jest zgodne z analizą wąskich gardeł.
Wykresy przepustowości (Throughput) śledzą liczbę ukończonych elementów w danym okresie; monitoruj stabilność i trendy.

Planowanie iteracji, doskonalenie backlogu i prognozowanie oparte na prędkości (velocity)

Planowanie sprintu przekształca priorytet w ograniczone czasowo zobowiązanie. Backlog sprintu zawiera elementy PBI lub historyjki użytkownika (User Stories) pobrane do iteracji, podzielone na zadania (Tasks) z pozostałą pracą (Remaining Work) w godzinach. Użyj pojemności sprintu (Sprint Capacity), aby modelować dostępność osób:

Pojemność na osobę w godzinach/dzień według aktywności (rozwój oprogramowania, testowanie, UX).
Indywidualne i zespołowe dni wolne odzwierciedlające święta i urlopy.
Równoważenie obciążenia na poziomie aktywności poprzez przypisywanie zadań do aktywności i przeglądanie pojemności w stosunku do zaplanowanej pracy.

Prędkość (velocity) podsumowuje dostarczone story pointy na sprint. Użyj wykresu prędkości (Velocity chart), aby ustalić stabilny przedział; unikaj „inflacji punktów”. W backlogach produktu włącz prognozowanie (Forecasting), aby przewidzieć, ile nadchodzących iteracji będzie potrzebnych do ukończenia backlogu przy historycznej średniej prędkości zespołu (opartej na kilku ostatnich sprintach) i długości iteracji. Utrzymuj rzetelność prognozowania, wykluczając częściowo ukończoną pracę i przestrzegając rygorystycznej definicji ukończenia (DoD).

Doskonalenie backlogu (refinement) wymusza przejrzystość i względne szacowanie rozmiaru:

Kryteria akceptacji: zapisuj jasne, testowalne stwierdzenia w polu Acceptance Criteria elementu pracy; preferuj format Given-When-Then, aby zmniejszyć niejednoznaczność i przyspieszyć projektowanie testów.
Story pointy: szacuj względną złożoność i niepewność na poziomie wymagania; nie przeliczaj punktów na godziny — zadania (tasks) mają określoną pozostałą pracę (Remaining Work).
Estymacja względna (poker planistyczny - Planning Poker): użyj wspólnego punktu odniesienia i sekwencji (ciąg Fibonacciego lub zmodyfikowany ciąg Fibonacciego), aby szybko osiągnąć zbieżność. Zespoły mogą używać rozszerzeń z Marketplace do przeprowadzania sesji Planning Poker w Azure Boards, zapisując oszacowania w polach Story Points/Effort w celu zapewnienia spójnego raportowania.

Błędy (bugs) powinny być poddawane weryfikacji (triage) i traktowane jak wymagania (szacowane w punktach i planowane w backlogu) lub obsługiwane jako zadania w ramach sprintu; wybierz jedną politykę dla zespołu, aby utrzymać spójną prędkość (velocity).

Planowanie międzyzespołowe, zapytania, raportowanie, GitHub Projects i metryki DevOps

Duże programy wymagają wglądu w pracę wielu zespołów i repozytoriów:

Plany dostarczania (Delivery Plans): twórz osie czasu dla wielu zespołów, filtrowane według ścieżek obszaru/iteracji. Wizualizuj pracę według iteracji za pomocą linii zależności (z linków typu Poprzednik/Następca) i znaczników kamieni milowych (daty wydań, zobowiązania zewnętrzne). Pokazuj zbiorczy postęp dla elementów typu Feature i Epic oraz udostępniaj pola niestandardowe (np. Ryzyko) na potrzeby przeglądów zarządczych.
Zapytania i raportowanie: buduj zapytania typu płaska lista (Flat list), aby odpowiedzieć na pytanie „które elementy pasują do tych filtrów”, drzewo elementów pracy (Tree of work items), aby nawigować po hierarchii z widokiem zbiorczym (rollup), oraz zapytania o linki bezpośrednie (Direct links), aby analizować pojedyncze połączenia (np. Feature → Stories lub Bug → commity). Zapisuj i udostępniaj zapytania, dodawaj wykresy (kołowe, słupkowe, trendu) i przypinaj je do dashboardów. Do raportowania klasy analitycznej użyj usługi Azure DevOps Analytics i OData z Power BI, aby tworzyć wykresy spalania (burndown) dla portfolio, mapy cieplne ryzyka zależności i wizualizacje DORA. Wbudowane raporty obejmują Velocity, Burndown/Burnup, CFD, Lead Time, Cycle Time oraz wykorzystanie pojemności sprintu (Sprint Capacity).

GitHub Projects integruje planowanie z Issues i PR-ami:

Tablice projektowe (Project boards): twórz widoki Kanban lub tabelaryczne na poziomie organizacji lub repozytorium, definiuj pola niestandardowe (Status, Iteracja, Priorytet) i filtruj według zespołu.
Reguły automatyzacji: konfiguruj wbudowane przepływy pracy, aby ustawiać Status, gdy Issue lub PR jest otwierany, scalany lub zamykany; automatycznie archiwizuj ukończone elementy; przypisuj lub etykietuj na podstawie zmian w polach; i przenoś elementy między widokami. Połącz z GitHub Actions, aby uzyskać zaawansowane automatyzacje.
Integracja z Issues i PR-ami: Issues i PR-y są pełnoprawnymi elementami w Projects. Używaj słów kluczowych w opisach PR (np. Fixes #123), aby linkować i automatycznie zamykać Issues. Status i recenzenci są widoczni na tablicy, co umożliwia śledzenie od kodu do planu.

Metryki DevOps muszą łączyć kod, wdrożenia i wyniki:

Metryki DORA:
- Częstotliwość wdrożeń (Deployment frequency): liczba wdrożeń produkcyjnych na dzień/tydzień; źródłem są zdarzenia wydań z pipeline’ów.
- Czas realizacji zmian (Lead time for changes): mierzony od commita kodu (lub scalenia PR) do wdrożenia produkcyjnego; upewnij się, że pipeline’y emitują znaczniki czasu wdrożenia i korelują je z commitami.
- Wskaźnik nieudanych zmian (Change failure rate): stosunek wdrożeń produkcyjnych, które skutkują incydentem mającym wpływ na klienta lub wycofaniem zmiany; zintegruj z tagami zarządzania incydentami i wynikami pipeline’ów.
- Średni czas do przywrócenia usługi (MTTR): czas, jaki upłynął od rozpoczęcia incydentu do przywrócenia usługi; opieraj się na alertach z monitoringu i czasach zamknięcia incydentów. Skoreluj metryki DORA z analityką tablicy (Lead/Cycle time), aby wykryć, czy ograniczeniem jest planowanie, czy dostarczanie. Używaj dashboardów, aby prezentować oba zestawy metryk tej samej grupie odbiorców w celu ciągłego doskonalenia.

Praktyczny scenariusz problemowy

Dział Advertising w firmie Microsoft koordynuje pracę ośmiu zespołów wielofunkcyjnych dostarczających wspólną platformę do zarządzania kampaniami. Baza kodu znajduje się w GitHub; organizacja potrzebuje wiarygodnych zobowiązań kwartalnych, jasnej widoczności zależności oraz użytecznych metryk przepływu i DORA bez zwiększania rozrostu narzędzi.

Wybierz proces Agile w Azure DevOps i skonfiguruj zespoły

Dlaczego: Proces Agile zapewnia hierarchię Epic > Feature > User Story, która równoważy prostotę ze zbiorczymi raportami na poziomie portfolio. Utwórz osiem zespołów, każdy z własną ścieżką obszaru oraz bieżącymi/przyszłymi ścieżkami iteracji, co umożliwia autonomię w tablicach i dashboardach, zachowując jednocześnie możliwość raportowania dla całej organizacji.

Zdefiniuj zarządzanie Kanban i konfigurację tablicy

Dlaczego: Ciągły przepływ między sprintami skraca czas oczekiwania. Skonfiguruj kolumny zmapowane na stany z podziałem na Doing/Done (W toku/Zrobione) dla statusów In Progress i Code Review. Ustaw limity WIP dla każdej kolumny i dodaj tor (swimlane) typu Expedite z niższym limitem WIP. Dodaj polityki tablicy określające Definicję Ukończenia (Definition of Done) (testy jednostkowe przechodzą, PR zatwierdzony, lista weryfikacyjna wdrożenia ukończona), aby kontrolować przejście do stanu Done.

Wdróż dyscyplinę doskonalenia backlogu i estymacji

Dlaczego: Przewidywalne zobowiązania wymagają spójnej wyceny i jasności. Zapisuj kryteria akceptacji przy użyciu składni Given-When-Then w User Stories. Standaryzuj Story Points za pomocą Planning Pokera (ciąg Fibonacciego 1–13) przy użyciu rozszerzenia Azure Boards i utrzymuj estymacje zadań w godzinach Pozostałej Pracy (Remaining Work), aby wspierać Pojemność Sprintu (Sprint Capacity).

Planuj sprinty z prognozowaniem opartym na pojemności i velocity

Dlaczego: Planowanie pojemności zmniejsza ryzyko nadmiernych zobowiązań. Wprowadź indywidualną pojemność według aktywności i dni wolnych. Użyj wykresu Velocity z ostatnich sześciu sprintów, aby ustalić realistyczny cel sprintu. Włącz prognozowanie backlogu (Forecasting), aby przewidzieć, ile sprintów potrzeba do osiągnięcia kwartalnych celów na poziomie Epic, dostosowując oczekiwania interesariuszy.

Ustanów Plany dostarczania (Delivery Plans) dla wglądu międzyzespołowego

Dlaczego: Zależności i kamienie milowe muszą być widoczne na jednej osi czasu. Utwórz Plan dostarczania obejmujący wszystkie osiem zespołów i poziomy portfolio. Dodaj znaczniki kamieni milowych dla dat wydań kwartalnych i wydarzeń rynkowych. Użyj linków typu Poprzednik/Następca, aby pokazać linie zależności i uwidocznić ryzyko tam, gdzie elementy pracy obejmują wiele iteracji.

Zintegruj GitHub Projects, aby uzyskać widoki wykonawcze skoncentrowane na repozytorium

Dlaczego: Deweloperzy żyją w GitHub; Projects utrzymuje kontekst wykonawczy blisko kodu. Utwórz GitHub Project na poziomie organizacji z widokami tablicy i tabeli. Dodaj reguły automatyzacji, aby ustawiać Status na In Progress po otwarciu PR, na Done po scaleniu PR i automatycznie archiwizować zamknięte Issues. Używaj „Fixes #<id>” w PR-ach, aby zamykać powiązane Issues i odzwierciedlać status na tablicy.

Połącz kod i pracę w celu zapewnienia identyfikowalności

Dlaczego: Pełna identyfikowalność (end-to-end) umożliwia dokładne raportowanie i audyty. Wymuś odwoływanie się do ID elementu pracy z Azure Boards w komunikatach commitów i opisach PR; używaj linków do artefaktów w elementach pracy, aby Plany dostarczania i analityka mogły agregować postęp na podstawie aktywności w kodzie.

Zaimplementuj metryki przepływu i DORA na dashboardach

Dlaczego: Współdzielone, zautomatyzowane metryki napędzają doskonalenie. Na dashboardach zespołowych przypnij wykresy CFD, Lead Time i Cycle Time, aby zarządzać przepływem. Na dashboardzie programu umieść podsumowanie Velocity, Planu dostarczania oraz metryki DORA: obliczaj częstotliwość wdrożeń i czas realizacji, korzystając ze zdarzeń wdrożeń z etapów produkcyjnych pipeline’ów; wyliczaj wskaźnik nieudanych zmian i MTTR, tagując incydenty i korelując je z wdrożeniami. Ten ujednolicony widok pokazuje, czy ograniczenia leżą w planowaniu (lead/cycle time na tablicy), czy w dostarczaniu (DORA).

Takie podejście równoważy autonomię zespołu (tablice, pojemność i dashboardy specyficzne dla zespołu) z zarządzaniem programem (Plany dostarczania, zależności i kamienie milowe). Azure Boards zapewnia hierarchiczne planowanie i analitykę, GitHub Projects usprawnia codzienne śledzenie pracy deweloperów dzięki automatyzacji powiązanej z Issues i PR-ami, a metryki DORA łączą planowanie z wynikami operacyjnymi, zapewniając wiarygodne, oparte na danych zobowiązania.

← Zarządzanie pakietami i artefaktami · Wszystkie domeny

Przećwicz te pytania → · Testy na czas na ExamRoll.io →