App Rescue & Rebuild: co obejmuje

Co to jest

Zlecenie łączy ocenę kodu i stanu produktu z kontrolowanym planem stabilizacji, naprawy, częściowej lub, w uzasadnionych przypadkach, pełnej przebudowy. Wstępny przegląd może objąć dostępną strukturę aplikacji, bieżące buildy, zależności, dostęp do środowisk, znane błędy, proces wydawania, dokumentację oraz przepływy użytkownika, które produkt ma obsługiwać. Dokładne granice oceny są potwierdzane, gdy dostępny dostęp i materiały są już znane. Ustalenia służą do odróżnienia problemów, które można naprawić w ramach istniejących fundamentów, od problemów, przez które dalsze prace stają się nieefektywne lub niebezpieczne do zaplanowania bez większej zmiany. Zlecenie ratunkowe daje oparty na dowodach obraz tego, czy i w jaki sposób aplikację można odzyskać, wydać i uczynić łatwą w utrzymaniu. Tworzy opartą na dowodach podstawę do wyboru kolejnej ścieżki realizacji, a tam, gdzie można uzgodnić praktyczny zakres, do przeprowadzenia uzgodnionych prac stabilizacyjnych lub przebudowy.

Dla kogo

App Rescue & Rebuild jest odpowiedni dla zespołów, które:

• Mają niedokończoną aplikację lub produkt, który zmienił wykonawcę, utknął lub stał się trudny do dalszego rozwijania
• Obserwują powtarzające się błędy, kruche wydania, problemy z zależnościami lub niejasną odpowiedzialność za istniejącą aplikację
• Muszą zdecydować, czy zachować działające elementy, naprawić konkretne obszary, przebudować wybrane przepływy czy zaplanować nowe fundamenty
• Chcą bardziej zdyscyplinowanej drogi naprzód niż dalsze dodawanie funkcji bez zrozumienia obecnego stanu technicznego i produktowego

Co pomaga wyjaśnić

Ocena ratunkowa pomaga wyjaśnić:

• Co można zaobserwować w obecnym kodzie, buildach, środowiskach, zależnościach i przepływach produktu, a gdzie brakuje dowodów
• Które błędy lub ryzyka związane z wydaniem są problemami lokalnymi, a które wskazują na szersze problemy z architekturą, odpowiedzialnością lub realizacją
• Czym różnią się opcje zachowania, naprawy, częściowej i pełnej przebudowy pod względem zakresu, ryzyka, zależności i momentu decyzji
• Jaki dostęp, decyzje produktowe, zewnętrzni dostawcy i kroki weryfikacji są potrzebne, zanim będzie można potwierdzić wiarygodny zakres realizacji

Co jest zawarte

• Wstępny przegląd uzgodnionego dostępnego kodu, stanu buildów, zależności, środowisk, dokumentacji i kontekstu produktu
• Praktyczna selekcja zaobserwowanych wzorców błędów, problemów architektonicznych, kondycji zależności oraz ryzyka związanego z wydaniem lub wdrożeniem
• Zrozumiała ocena oddzielająca zaobserwowane fakty, założenia, ograniczenia i obszary wymagające dodatkowego dostępu lub analizy
• Rekomendacja najbardziej praktycznej kolejnej ścieżki: zachowanie, ukierunkowana naprawa, częściowa przebudowa lub osobno zdefiniowana pełna przebudowa
• Prace stabilizacyjne lub realizacyjne wyłącznie wtedy, gdy po ocenie można uzgodnić wykonalny zakres, granice dostępu i sposób odbioru
• Podsumowanie przekazania lub decyzji, które zapisuje bieżące priorytety, pytania o odpowiedzialność i kolejne uzgodnione kroki

Co nie jest uwzględnione

• Obietnica, że każdą część istniejącego kodu da się zachować, naprawić lub wydać, zanim ocena zostanie zakończona
• Zapewnienie, że wszystkie błędy, dług techniczny, problemy bezpieczeństwa, problemy z zależnościami lub ryzyka związane z wydaniem zostaną wykryte lub usunięte
• Nieograniczone debugowanie, nieograniczone prace nad funkcjami ani otwarte utrzymanie poza osobno uzgodnionym zakresem realizacji
• Automatyczne odzyskanie niedostępnych poświadczeń, repozytoriów kodu, kont dostawców, usług podmiotów trzecich lub dokumentacji nieprzekazanej na potrzeby zlecenia
• Reagowanie na incydenty w sytuacjach awaryjnych, zapewnienie akceptacji w sklepach ani szerokie prace nad backendem, zgodnością lub infrastrukturą, chyba że zostaną osobno zdefiniowane

Kiedy to wybrać

Warto wybrać App Rescue & Rebuild, gdy kluczowa decyzja nie dotyczy już tego, co zbudować, lecz tego, co można bezpiecznie i rozsądnie przenieść z już wykonanej pracy. Przydaje się, gdy agencja lub poprzedni programista przekazali niekompletny projekt, gdy wydania są zawodne, gdy kod stał się trudny do zmiany lub gdy zespół produktowy stracił zaufanie do obecnego planu. Jest także przydatne przed przeznaczeniem dodatkowego budżetu na projekt, który już wykazuje oznaki przeciążenia zależności lub architektury. W przypadku prostego pomysłu na nowy produkt bez istniejącej aplikacji jaśniejszą drogą jest zwykle zlecenie MVP lub discovery. Ścieżka ratunkowa sprawdza się, gdy firma może udostępnić dostępne repozytoria, informacje o dostępach, kontekst produktu oraz decydenta, który po wstępnej ocenie rozstrzygnie priorytety.

Nasze podejście

Zaczynamy od dostępnych dowodów, a nie od założeń na temat istniejącego produktu. Pierwszy etap zapisuje, jaki dostęp jest dostępny, co można uruchomić lub zbadać, które zależności wydają się aktywne, jak obecnie obsługiwane są wydania i które przepływy użytkownika są najważniejsze. Następnie oddzielamy pilne kwestie stabilizacji od długoterminowych decyzji o przebudowie. Zachowanie komponentu oznacza, że ma on wystarczającą wartość i łatwość utrzymania, by pozostać w określonych granicach. Naprawa oznacza usunięcie ograniczonego problemu, a szersze fundamenty są oceniane osobno, na własnych warunkach. Częściowa przebudowa zastępuje wybrane przepływy lub warstwy, zachowując uzgodnione działające elementy. Pełna przebudowa jest rozważana, gdy istniejące fundamenty nie stanowią praktycznej podstawy do kontrolowanego postępu. Zakres realizacji potwierdzamy, gdy ocena dostarczy wystarczających dowodów, by zrobić to odpowiedzialnie. Jeśli następuje etap stabilizacji lub przebudowy, jego kryteria odbioru, zależności i granice wydania są uzgadniane na piśmie. Efektem jest jaśniejsza, oparta na dowodach ścieżka decyzyjna.

Często zadawane pytania

Artykuły pokrewne