Rozwój aplikacji mobilnych
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ć
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: aplikacja mobilna, API i panel do obsługi
Połączyliśmy aplikację React Native na iOS i Androida z backendem Laravel i panelem administracyjnym. Kalendarz, treści, ogłoszenia i powiadomienia pokazują, jak funkcje aplikacji współpracują z jej zapleczem.
Blog o stronach, sklepach i CRM
Przejdź do bloga
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.
Taką możliwość oceniamy po zapoznaniu się z technologią, kodem, dostępami i usługami obsługującymi dane oraz wydania. Musimy potwierdzić, że projekt da się uruchomić. Punktem odniesienia są aplikacje React Native i uzgodnione prace przy backendzie. Taką architekturę wykorzystaliśmy w JutroDrop z zapleczem w Laravelu. Inne technologie wymagają osobnego ustalenia; sam opis nowej funkcji nie wystarcza do potwierdzenia przejęcia prac.
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.
Od stanu i możliwości uruchomienia projektu, jakości kodu, funkcji, zależności oraz testów. Rozpoznanie aplikacji może być osobnym etapem przed wyceną wdrożenia. Można ograniczyć zakres do jednego modułu, jeśli architektura na to pozwala, ale nawet niewielka funkcja może wymagać zmian w API, danych i interfejsie. W wycenie uwzględniamy przygotowanie wydania i sprawdzenie działania po publikacji.
