Rozpocznij nowy produkt w Taiga

Przygotuj jeden jasny wynik

Scenariusz używa fikcyjnej usługi zgłoszeń sprzętowych. Menedżer zapisuje wniosek pracownika o sprzęt i decyzję. Samoobsługa pracowników jest późniejszym rozszerzeniem. Podczas nauki używaj rekordów syntetycznych. Scenariusz nie upoważnia do użycia rzeczywistych danych kadrowych.

Przed utworzeniem produktu potwierdź konfigurację organizacji i odpowiedniego wspólnego kontekstu. Wskaż osobę odpowiedzialną za wynik usługi i zespół odpowiedzialny za środowisko operacyjne.

Zapisz początkową granicę: pierwsza wersja rejestruje wnioski i decyzje. Nie zamawia sprzętu, nie zatwierdza automatycznie wydatków ani nie zmienia danych płacowych.

Wybierz sposób rozpoczęcia produktu

Wybierz Start from scratch dla nowej usługi. Użyj Import codebase, gdy punktem wyjścia ma być istniejące repozytorium. Import wybiera się podczas tworzenia produktu, więc podejmij tę decyzję świadomie.

Tworzenie pyta też, czy Taiga pisze Infrastructure code i CI/CD pipelines. To osobne odpowiedzialności. Jeśli zespół platformowy już zapewnia dany element, wyłącz jego generowanie i opisz obecny sposób pracy.

Na przykład: „Nasza platforma wdraża obrazy kontenerów po review przez istniejący pipeline repozytorium. Użyj jego tożsamości workloadu i konfiguracji środowiska”. Potwierdź prawdziwość opisu, zanim na nim oprzesz pracę.

Dodaj kontekst przed rozmową

Discovery zaczyna się od Context. Przed rozmową dodaj istotne materiały referencyjne produktu i stałe instrukcje. Reguły wspólne dla kilku produktów umieść na poziomie organizacji lub fabryki.

Dla usługi sprzętowej przydatny kontekst obejmuje sposób identyfikacji pracowników, zatwierdzone usługi danych i regułę dostępu menedżera. Jawnie oznacz nierozwiązane pytania. Nie wymyślaj okresu retencji, aby wypełnić formularz.

Następnie opisz usługę w rozmowie. Wyjaśnij użytkowników, pożądany wynik, ograniczenia i elementy poza zakresem. Podczas pracy specyfikacja zapisuje się jako szkic.

Przejrzyj i opublikuj intencję

Przeczytaj specyfikację, szukając założeń zmieniających implementację. W tym scenariuszu sprawdź, czy menedżer widzi wszystkie wnioski pracowników czy tylko swojego zespołu. Różnica wpływa na uprawnienia, przepływ danych i testy.

Opublikuj specyfikację, gdy jej treść nadaje się do dalszej pracy. Zmiany szkicu nie zastępują opublikowanej wersji do ponownej publikacji. Przejdź przez wymagane dokumenty i sprawdź ich założenia. Lekcja Discovery wyjaśnia zależności i nieaktualne dokumenty.

Po opublikowaniu wszystkich ośmiu wymaganych dokumentów zakończ Discovery i zaplanuj inicjatywy. Wygenerowana kolejność jest propozycją, którą możesz sprawdzić i zmienić.

Podłącz rzeczywisty cel dostarczania

Podłącz repozytorium przed szczegółowym planowaniem inicjatyw. Jednocześnie określ docelowe środowiska, choć środowisko nie jest wymagane do rozpoczęcia planowania.

Opis środowiska nie przyznaje dostępu do chmury. Wdrożenie wykonuje pipeline. Sprawdź z odpowiedzialnym zespołem branch repozytorium, tożsamość, własność infrastruktury i wymagane zadania konfiguracyjne.

Użytecznym wynikiem scenariusza jest określony produkt i praca możliwa do review, oparta na rzeczywistym środowisku dostarczania. Przećwicz kolejność decyzji w symulacji procesu Taiga.