Rozwijaj działającą aplikację na podstawie jej kodu i potrzeb użytkowników
Nowa funkcja w istniejącej aplikacji może wymagać zmian w interfejsie, API i sposobie wydawania produktu. Zaczynamy od rozpoznania obecnego rozwiązania oraz tego, co chcesz poprawić. Na tej podstawie ustalamy zakres prac, ryzyka i testy kolejnego wydania. Dla aplikacji React Native możemy zaplanować rozwój części mobilnej oraz współpracującego zaplecza.
Firmy, z którymi pracowaliśmy nad produktami cyfrowymi
Klienci uwielbiają z nami pracować
Co sprawdzamy przed kolejnym wydaniem aplikacji
Stan projektu i dostępów
Ustalamy, gdzie znajduje się kod, jak uruchomić projekt i kto zarządza środowiskami oraz kontami wydawniczymi. Brak dostępów i dokumentacji może wpływać na zakres pierwszego etapu.
Problem wymagający zmiany
Rozdzielamy błąd, trudność w obsłudze i potrzebę nowej funkcji. Korzystamy z konkretnych scenariuszy, zgłoszeń lub danych, aby prace odpowiadały rzeczywistemu problemowi użytkownika.
Wpływ zmian na API i dane
Nowy ekran nie zawsze jest tylko zmianą wyglądu. Sprawdzamy zależności z backendem, model danych i zgodność z wersją aplikacji, której nadal używa część użytkowników.
Aktualizacje technologii
Oceniamy wersje bibliotek i wymagania wspieranych platform. Dopiero po tej ocenie ustalamy, które aktualizacje są konieczne dla planowanej zmiany i czy trzeba je wykonać w osobnym etapie.
Testy przed wydaniem
Sprawdzamy nowy scenariusz oraz powiązane funkcje, które mogły zostać naruszone. Zakres obejmuje uzgodnione urządzenia, stany aplikacji i integracje ważne dla działania produktu.
Wydanie i dalsze priorytety
Ustalamy sposób wdrożenia, odpowiedzialność za publikację i sprawdzenie działania po uruchomieniu. Kolejne prace układamy według wpływu na użytkownika, zależności i kosztu, zamiast dopisywać funkcje bez kolejności.
Dlaczego rozwój aplikacji trzeba planować razem z zapleczem
JutroDrop łączy aplikację, API i panel administracyjny
W JutroDrop przygotowaliśmy aplikację React Native na iOS i Androida, backend w Laravelu i panel administracyjny. Kalendarz premier, treści, ogłoszenia i powiadomienia współpracują w jednym produkcie. Ten zakres pokazuje, dlaczego dodanie funkcji trzeba ocenić po stronie aplikacji i zaplecza. Realizacja dokumentuje budowę produktu i jego zależności; nie opisuje przejęcia kodu po innym zespole.
Co chcesz poprawić lub dodać w działającej aplikacji?
Napisz, w jakiej technologii działa produkt, jaki problem chcesz rozwiązać i czy masz dostęp do kodu. Wskaż najważniejszy scenariusz zmiany. Materiały techniczne i sposób ich udostępnienia ustalimy w kolejnym kroku.
Pytania o rozwój działającej aplikacji
Zakres kolejnego wydania zależy od obecnego kodu, zaplecza i potrzeb użytkowników. Rozpoznanie projektu poprzedza decyzję o implementacji.
Masz konkretną zmianę do omówienia? Porozmawiajmy o zakresie.
Możliwość podjęcia prac ustalamy po zapoznaniu się z technologią, kodem i dostępami. Potrzebujemy wiedzieć, czy projekt można uruchomić oraz jakie usługi obsługują jego dane i wydania. Sam opis oczekiwanej funkcji nie wystarcza do potwierdzenia przejęcia projektu.
Punktem odniesienia są aplikacje React Native oraz uzgodnione prace przy współpracującym backendzie. Taką architekturę wykorzystaliśmy w JutroDrop, z zapleczem w Laravelu. Dla innych technologii możliwość współpracy wymaga osobnego ustalenia.
Decyzja wymaga oceny jakości kodu, zależności, kosztu zmian i ryzyka dla użytkowników. Część problemów można rozwiązać przez ograniczoną rozbudowę, inne uzasadniają przebudowę wybranych elementów. Jeśli analiza prowadzi do większego zakresu, porównujemy go z budową nowej aplikacji mobilnej.
Kod i instrukcja uruchomienia pozwalają ocenić zmianę, a dokumentacja API wyjaśnia jej zależności z zapleczem. Środowisko testowe służy sprawdzeniu działania przed wdrożeniem, a opis problemu ustala cel prac. Na początku wystarczy wskazać dostępność tych materiałów; sposób udostępnienia repozytorium i dostępów uzgodnimy osobno.
Ustalamy kryteria odbioru nowej funkcji i scenariusze powiązane z nią w obecnym produkcie. Testy powinny uwzględniać także API, logowanie i wersje aplikacji nadal używane przez odbiorców. Zakres kontroli wynika z wpływu zmiany i nie oznacza gwarancji całkowitego braku błędów.
Można rozpatrzyć ograniczoną zmianę, jeśli architektura produktu pozwala wydzielić potrzebne prace. Najpierw sprawdzamy powiązania z danymi, API i interfejsem mobilnym. Nawet pojedynczy moduł może wymagać aktualizacji więcej niż jednej części systemu.
Od możliwości uruchomienia projektu, jakości kodu, zakresu funkcji, zależności i testów. Osobną częścią może być rozpoznanie stanu aplikacji przed wyceną implementacji. Ustalamy również przygotowanie wydania i odpowiedzialność za sprawdzenie działania po wdrożeniu.
Klienci uwielbiają z nami pracować