Rozwój i utrzymanie oprogramowania

Tak. Na początku ustalamy, jakie materiały i dostępy masz oraz czy dotychczasowy zespół może przekazać wiedzę. Uzgadniamy zakres przeglądu kodu, integracji, środowisk i sposobu wdrażania. Sprawdzamy, czego brakuje do uruchomienia i przetestowania aplikacji. Dopiero wtedy planujemy przejęcie odpowiedzialności i pierwsze zmiany.

Nie. Wiele aplikacji można rozwijać w obecnej architekturze. Jeżeli znajdziemy ograniczenia wymagające modernizacji, opisujemy je i proponujemy osobny zakres zmian. Decyzję podejmujemy z uwzględnieniem kosztów, potrzeb i ryzyka dla bieżącej pracy.

Wspólnie ustalamy zakres dostępności zespołu, budżet oraz kolejność zadań. Oddzielamy zgłoszenia wymagające reakcji od zaplanowanego rozwoju. Regularne przeglądy pozwalają zmieniać priorytety ze świadomością wpływu na terminy i pozostałe prace.

Godziny obsługi, kanały zgłoszeń i oczekiwane czasy reakcji uzgadniamy przed rozpoczęciem współpracy. Nie zakładamy automatycznie dyżurów całodobowych. Wymagania dotyczące dostępności i incydentów są podstawą do ustalenia odpowiedniego zakresu umowy.

Poznajemy krytyczne ścieżki i obejmujemy je testami adekwatnymi do systemu. Sprawdzamy zmiany w środowisku testowym, przeglądamy kod i planujemy wdrożenie wraz ze sposobem wycofania wersji. Zakres weryfikacji zależy od wpływu zmiany.

Tak. Uzgadniamy podział odpowiedzialności, pracę w repozytorium, przeglądy kodu i wydawanie wersji. Wiedzę o aplikacji dokumentujemy, aby współpraca nie opierała się wyłącznie na pojedynczych osobach.

Ustalamy przekazanie kodu, dokumentacji, listy zależności i instrukcji wdrażania. Porządkujemy dostępy oraz otwarte zadania. Możemy zaplanować sesje przekazania wiedzy zespołowi, który będzie dalej opiekował się aplikacją.