Rozpoczęcie współpracy z zewnętrznym zespołem deweloperskim bywa momentem dużych oczekiwań biznesowych, które często zderzają się z rzeczywistością techniczno-organizacyjną pierwszych dni projektu. Aby uniknąć frustracji, przestojów i sytuacji, w której sprint mija na poszukiwaniu dostępu do kodu, niezbędne jest staranne przygotowanie środowiska, kompetencji oraz zasad działania jeszcze przed wystartowaniem prac.
Dlaczego pierwszy sprint często zaczyna się od onboardingu?
Pierwszy sprint z zewnętrznym zespołem nie powinien zaczynać się od szukania dostępów. A jednak często tak wygląda początek współpracy. Zespół jest gotowy. Scope został omówiony. Umowa podpisana. Po stronie klienta jest oczekiwanie, że prace ruszą od razu. Po kilku dniach okazuje się jednak, że brakuje dostępu do repozytorium, środowisko developerskie nie jest opisane, pipeline nie działa lokalnie, backlog wymaga doprecyzowania, a decyzje techniczne są rozproszone między kilkoma osobami.
Formalnie sprint się rozpoczął. Praktycznie trwa onboarding. To nie musi być problem, jeżeli wszyscy wiedzą, że pierwszy etap współpracy obejmuje przygotowanie techniczne. Problem pojawia się wtedy, gdy firma oczekuje delivery od pierwszego dnia, ale nie przygotowała warunków, które pozwalają zespołowi realnie pracować. Przed pierwszym sprintem trzeba ustalić kilka rzeczy.
Jaki zakres musi być gotowy przed startem?
Pierwsza to zakres. Zewnętrzny zespół powinien wiedzieć, za co odpowiada. Czy ma przejąć konkretny moduł? Fragment backlogu? Maintenance? Refactoring? Integrację? Nową funkcję? Support po release? Im bardziej ogólny zakres, tym większe ryzyko, że sprint zacznie się od doprecyzowywania zamiast od pracy. Dobre pytanie brzmi: „Co zespół może dowieźć bez codziennego wracania po decyzje?”.
Jak przygotować dostęp do kodu i środowisk?
Druga rzecz to dostęp do kodu i środowisk. Minimum to repozytoria, dokumentacja techniczna, konfiguracja środowiska lokalnego, dostęp do środowisk testowych, narzędzia projektowe, logi, monitoring i pipeline’y CI/CD. Jeżeli system jest starszy, część tych elementów może być niepełna. To normalne. Ważne, żeby nazwać to przed startem, a nie odkrywać w trakcie sprintu.
Jak ustalić standard pracy i punkt kontaktu?
Trzecia rzecz to standard pracy. Zespół zewnętrzny powinien znać zasady code review, branching strategy, definicję gotowości, wymagania testowe, sposób opisywania zadań, reguły bezpieczeństwa i proces release’u. Bez tego łatwo o sytuację, w której kod powstaje, ale nie przechodzi płynnie przez proces klienta.
Czwarta rzecz to punkt kontaktu. Nie chodzi o tworzenie dodatkowych spotkań. Chodzi o jasną odpowiedzialność. Zespół powinien wiedzieć, kto odpowiada na pytania techniczne, kto akceptuje decyzje, kto nadaje priorytety i kto może odblokować temat, jeżeli pojawi się zależność po stronie klienta.
Bez takiej osoby zewnętrzny zespół zaczyna szukać odpowiedzi u kilku osób jednocześnie. To spowalnia pracę i zwiększa koszt koordynacji.
Jak dobrać pierwsze zadania i oczekiwany rezultat?
Piąta rzecz to pierwsze zadania. Dobry pierwszy sprint nie powinien zaczynać się od najbardziej ryzykownej zmiany w systemie. Lepiej rozpocząć od zakresu, który pozwala zespołowi poznać architekturę, proces review, jakość dokumentacji, zależności i sposób wdrażania zmian.
Pierwsze zadania powinny być wystarczająco konkretne, żeby dało się je dowieźć, ale jednocześnie na tyle reprezentatywne, żeby pokazały realny sposób pracy z systemem.
Szósta rzecz to oczekiwany rezultat sprintu. Czy celem pierwszego sprintu jest:
- Dostarczenie funkcji?
- Uruchomienie środowiska?
- Przejęcie wiedzy?
- Analiza techniczna?
- Pierwszy release?
- Uporządkowanie backlogu?
To trzeba powiedzieć wprost. Inaczej klient może oczekiwać pełnego delivery, a zespół będzie w praktyce wykonywał discovery techniczne.
Jak Prognetics ustawia pierwszy etap współpracy?
W Prognetics przygotowanie współpracy zaczyna się przed pierwszym sprintem. Ustalamy wtedy stack, zakres, dostęp do środowiska, ownership i główne ograniczenia po stronie projektu. Dzięki temu zespół nie wchodzi do sprintu po to, żeby dopiero szukać kontekstu, decyzji i zasad pracy. Na tym etapie określamy też, czy lepszym modelem będzie team extension, w którym nasi specjaliści pracują w procesie klienta, czy managed delivery, w którym przejmujemy odpowiedzialność za konkretny zakres.
Pierwszy sprint nie powinien być testem cierpliwości po obu stronach. Powinien być dobrze przygotowanym startem pracy. Jeżeli zewnętrzny zespół ma skracać backlog, musi wejść do projektu z jasnym zakresem, dostępem do środowiska, ustalonym ownershipem i wiedzą, co może przesuwać samodzielnie. Bez tego dodatkowa capacity szybko zmienia się w dodatkową koordynację.
