Przekształć wynik w inicjatywę

Opisz wynik przed krokami

Fikcyjna usługa sprzętowa potrzebuje samoobsługi pracowników. Przydatne zgłoszenie określa wynik: „Uwierzytelniony pracownik może utworzyć wniosek i widzieć wyłącznie własne wnioski”.

Wyjaśnij znaczenie: obecnie menedżerowie wprowadzają wnioski za pracowników. Określ zakres: tworzenie wniosku, wyświetlanie statusu, kontrole dostępu i dowody tych zachowań. Wyklucz automatyczne zakupy i zmianę reguły akceptacji przez menedżera.

Nie narzucaj edycji plików przed zbadaniem repozytorium. Inicjatywa zapisuje intencję; szczegółowe planowanie przekształca ją w kroki implementacji.

Sprawdź wynik zgłoszenia

Taiga używa zgłoszenia i kontekstu produktu do stworzenia inicjatywy lub uporządkowanego zestawu inicjatyw. Nowa praca trafia do Backlog. Większe zgłoszenie może wymagać kilku zmian możliwych do niezależnego review.

Przeczytaj wygenerowany stan końcowy, Why i Scope. Sprawdź zachowanie wymaganego działania i wykluczeń. Jeśli istniejąca inicjatywa już obejmuje zgłoszenie, Taiga może ją wskazać zamiast tworzyć duplikat.

Zgłoszenie zablokowane przez opublikowaną politykę wymaga określonej w niej ścieżki decyzji. Przeczytaj wyjaśnienie i rozwiąż konflikt tą ścieżką. Nie przepisuj zgłoszenia tylko po to, aby ukryć zabronione działanie.

Traktuj tablicę jako kolejność wykonania

Taiga pracuje nad jedną inicjatywą naraz na produkt, włącznie z planowaniem. Rozpoczyna następną z kolejki po zmergowaniu bieżącego pull requesta. Nie przenosi automatycznie elementów z Backlog ani Todo do Queue.

Umieszczenie w Queue ma znaczenie. Zastępuje oczekiwanie na nieukończone zależności. Przed dodaniem samoobsługi pracowników potwierdź istnienie podstaw tożsamości lub to, że wybrany zakres tworzy je poprawnie.

Sprawdź szczegółowy plan

Planista czyta repozytorium, dokumenty produktu, polityki, instrukcje i kontekst wdrożenia. Porównaj plan z rzeczywistym wynikiem użytkownika i środowiskiem.

Dla usługi sprzętowej sprawdź trzy przypadki dostępu. Pracownik widzi swój wniosek. Inny pracownik go nie widzi. Menedżer zachowuje zamierzony dostęp do review. Uwzględnij migrację danych i skutki operacyjne, jeśli implementacja je zmienia.

Jeśli Build on its own by default jest wyłączone, ukończony plan czeka na decyzję. Approve rozpoczyna wykonanie jako osoba zatwierdzająca, w granicach jej uprawnień. Reject używa informacji zwrotnej do ponownego planowania. Inicjatywa może mieć własne ustawienie.

Użyj właściwego zapisu do następnej decyzji

Plany są wersjonowane. Wykonanie zapisuje, który plan realizowało. Jeśli zamierzone podejście się zmienia, sprawdź inicjatywę i właściwe działanie ponownego planowania. Użyj zapisu wykonania do analizy poprzedniej próby.

Build, zmergowany pull request i wydanie produkcyjne to różne stany. Zachowaj widoczność dowodów akceptacji i odpowiedzialności za wdrożenie w miarę postępu. Przejdź do ustawień autonomii.