Gdy inicjatywa PHP zależy od innych zespołów, usług lub decyzji biznesowych, samo podzielenie pracy na zadania nie wystarczy. Zespół może zamknąć wiele zadań — utworzyć tabelę, przygotować API albo skonfigurować kolejkę — a mimo to nikt nie będzie mógł użyć ani ocenić rezultatu. Przydatne pytanie nie brzmi: ile pracy zmieści się w sprincie, lecz: jaka weryfikowalna zmiana będzie dostępna po jego zakończeniu i czego potrzeba, aby działała.
Planowanie małych przyrostów w projektach PHP polega na ograniczaniu niepewności za pomocą przyrostów, które można przeglądać, testować i — w razie potrzeby — udostępniać użytkownikom. Nie oznacza to eliminowania wszystkich zależności ani wymuszania ostatecznej architektury od pierwszego dnia. Chodzi o to, by zależności były widoczne, a każdy wycinek pozwalał zdobyć konkretną wiedzę, bez utożsamiania postępu technicznego z dostarczoną wartością.
Zacznij od przepływu wartości, a nie od listy zadań
Opisz, jaką potrzebę chcecie zaspokoić, kto odniesie korzyść i jak przebiega cała ścieżka od danych wejściowych do rezultatu. W aplikacji PHP może ona obejmować ekran, reguły domenowe, warstwę trwałego zapisu danych, zewnętrzne API i działanie innego zespołu. Prosta mapa powinna pokazywać:
- Kroki wykonywane przez użytkownika lub system rozpoczynający proces.
- Komponenty PHP i usługi, które przekształcają lub przechowują dane.
- Integracje, dane lub uprawnienia dostarczane przez inne zespoły.
- Nierozstrzygnięte decyzje, które mogą zmienić oczekiwane działanie.
Dla każdej zależności zanotuj, kto odpowiada, czego dokładnie potrzeba, kiedy ma to być dostępne i jaka istnieje alternatywa w razie opóźnienia. „Czekamy na zespół danych” jest zbyt nieprecyzyjne; „potrzebujemy identyfikatora i dozwolonego statusu, aby wyszukiwać zgłoszenia” pozwala omówić konkretny kontrakt. Rozróżnij też rzeczywistą zależność od preferencji: być może do sprawdzenia pierwszego przepływu zespół nie potrzebuje jeszcze docelowej usługi.
Wybierz pierwszy wycinek wertykalny, który da się ocenić
Wycinek wertykalny obejmuje niezbędne elementy, by uzyskać obserwowalny rezultat, choć jego zakres może być ograniczony. Może na przykład obsługiwać tylko jeden typ zgłoszenia, stosować ograniczony zestaw reguł i wyświetlać status w wewnętrznym widoku. Nie musi obejmować wszystkich przypadków, ale powinien sprawdzać reprezentatywną ścieżkę od początku do końca, na wystarczająco realistycznych danych i przy odpowiednim zachowaniu systemu.
Porównaj możliwe wycinki, zadając cztery pytania:
- Kto może ocenić rezultat? Wskaż użytkownika, osobę odpowiedzialną za biznes lub system-konsumenta.
- Jaką decyzję pozwoli podjąć? Na przykład potwierdzić regułę, dostosować kontrakt API lub odrzucić hipotezę.
- Które zależności są niezbędne? Oddziel te potrzebne do sprawdzenia zachowania od tych, które są wymagane dopiero przy skalowaniu lub automatyzacji.
- Czy można bezpiecznie przeprowadzić testy? Uwzględnij uprawnienia, dane testowe, efekty zewnętrzne oraz sposób cofnięcia lub ograniczenia operacji.
Jeśli pierwszy przyrost obejmuje tylko przygotowanie bazy danych lub warstwy integracyjnej, może to być uzasadniona praca umożliwiająca dalsze działania, ale nie należy przedstawiać jej jako dostarczonej i zweryfikowanej wartości. Wskaż, jakie ryzyko ogranicza i jakie dowody przyniesie. Etap techniczny może odblokować późniejszy przyrost, ale sam nie dowodzi, że przepływ działa dla osób, które go potrzebują.
Przed rozpoczęciem prac określ dowody i warunki akceptacji
Przyrost można ocenić, gdy uzgodniono, co będzie obserwowane, aby stwierdzić, czy spełnia swój cel. Unikaj kryteriów takich jak „API jest gotowe” lub „proces działa”. Określ zachowanie, kontekst i oczekiwany rezultat: dla prawidłowego typu zgłoszenia po jego wysłaniu zostaje ono zarejestrowane, a jego status można sprawdzić. Dodaj istotne przypadki brzegowe, takie jak niekompletne lub zduplikowane dane albo nieudana odpowiedź zależnej usługi.
Kryteria powinny wskazywać również potwierdzające je dowody. Może to być test automatyczny, demonstracja na kontrolowanych danych, wpis w śladzie audytowym lub potwierdzenie od konsumenta. W przypadku zmiany PHP określ także odpowiednie warunki operacyjne: wymaganą konfigurację, migrację danych, uprawnienia, przydatne metryki lub logi oraz procedurę odzyskiwania. Nie każdy przyrost musi być udostępniony użytkownikom, ale każdy powinien dać się skontrolować w uzgodniony sposób.
Rozróżniaj wdrożenie wersji od wydania lub aktywacji funkcji. Wdrożenie oznacza zainstalowanie wersji w środowisku; wydanie lub aktywacja funkcji oznacza udostępnienie jej odbiorcom lub procesowi. Funkcję można wdrożyć bez jej aktywowania, na przykład w celu sprawdzenia zgodności. Jeśli stosowane jest stopniowe udostępnianie, określ, kto może uzyskać dostęp, jak jest on ograniczany oraz jaki sygnał powoduje zatrzymanie lub wycofanie aktywacji.
Uzgodnij kontrakty i terminy integracji
Zależności między zespołami stają się łatwiejsze do opanowania, gdy istnieją jawne ustalenia dotyczące integracji. W przypadku API określ pola, formaty, błędy, uwierzytelnianie, istotne limity i zgodność. Dla zdarzeń lub plików zdefiniuj schemat, częstotliwość, osobę odpowiedzialną oraz sposób obsługi powtórzonych lub opóźnionych komunikatów. W PHP udokumentuj też wymaganą konfigurację aplikacji i oczekiwane zachowanie, gdy usługa nie odpowiada.
Uzgodnienie interfejsu nie wymaga, aby oba zespoły skończyły pracę w tym samym czasie. Dostawca może udostępnić kontrakt i środowisko testowe, a konsument może pracować z obiektem zastępczym odtwarzającym oczekiwane odpowiedzi. Obiekty zastępcze ułatwiają postępy, ale nie zastępują walidacji z rzeczywistym systemem: zarezerwujcie termin integracji, by sprawdzić uwierzytelnianie, dane, opóźnienia i rzeczywiste błędy.
Ustalcie terminy przeglądu kontraktu i integracji, a nie tylko końcową datę dostarczenia. Jeśli zmieni się schemat, odnotujcie, kto ocenia wpływ zmiany i jak zachowywana jest zgodność. Testy kontraktowe i automatyczne kontrole w ciągłej integracji mogą wcześnie wykrywać rozbieżności, ale nie rozwiązują sporów dotyczących produktu ani problemów zewnętrznego środowiska.
Zarządzaj niepewnością za pomocą opcji i osób odpowiedzialnych
Niepewną zależność należy ująć jako ryzyko z przypisaną osobą odpowiedzialną, terminem przeglądu i powiązaną decyzją. Zapisz, czego nie wiadomo, jakie dowody pozwolą to rozstrzygnąć i co zrobi zespół, jeśli odpowiedź nie nadejdzie na czas. Możliwe działania obejmują ograniczenie zakresu, użycie kontrolowanych danych, tymczasowe symulowanie odpowiedzi lub zmianę kolejności wycinków. Każda alternatywa ma ograniczenia: symulacja pozwala przetestować lokalny przepływ, ale nie weryfikuje integracji produkcyjnej.
Nie ukrywaj pozostałej pracy pod etykietami takimi jak „integracja” czy „koordynacja”. Jeśli przyrostu nie można przetestować, dopóki inny zespół nie dostarczy danych, uwzględnij ten warunek w planie i uzgodnij termin sprawdzenia. Jeśli niepewność dotyczy prywatności, bezpieczeństwa lub skutków finansowych, nie rozstrzygaj jej na podstawie technicznego założenia: przed aktywowaniem danego zachowania uzyskaj decyzję właściwej osoby.
Przykład hipotetyczny: automatyzacja zgłoszenia biznesowego
Załóżmy, że organizacja chce zautomatyzować przyjmowanie i klasyfikowanie zgłoszeń wewnętrznych za pomocą aplikacji PHP. Pierwszy wycinek mógłby przyjmować jedną kategorię, sprawdzać wymagane pola i wyświetlać wynik w kolejce do weryfikacji. Zespół danych nie dostarczył jeszcze ostatecznego katalogu, więc dział produktu uzgadnia kontrolowany zestaw danych do oceny przepływu i odnotowuje, że klasyfikacja nie została zweryfikowana dla wszystkich kategorii.
Kolejny przyrost uwzględnia uzgodniony kontrakt z usługą danych, testuje prawidłowe odpowiedzi i błędy oraz zapisuje wersję użytego katalogu. Następny przyrost może włączyć automatyczne przypisywanie dla ograniczonej grupy, z weryfikacją przez człowieka i możliwością zatrzymania procesu. Każdy krok ma odrębny dowód: działający przepływ, sprawdzoną integrację oraz operacyjne zachowanie w określonych warunkach. Sekwencja ma charakter poglądowy; rzeczywista kolejność zależy od ryzyka i decyzji danej organizacji.
Lista kontrolna przed podjęciem zobowiązania dotyczącego kolejnego przyrostu
- Czy wiadomo, jaka osoba lub proces będzie w stanie ocenić rezultat?
- Czy przyrost obejmuje użyteczny przepływ, czy jego wartość ogranicza się do ukończenia warstwy technicznej?
- Czy zidentyfikowano zależności, osoby za nie odpowiedzialne i najbliższy termin ich przeglądu?
- Czy określono obserwowalne kryteria, dane testowe i sposób weryfikacji przypadków błędów?
- Czy zespoły uzgodniły kontrakty, zgodność i termin integracji?
- Czy określono konfigurację, uprawnienia, logi i procedurę odzyskiwania, gdy mają zastosowanie?
- Czy rozróżniono wdrożenie od aktywacji i czy sposób udostępniania jest kontrolowany?
- Czy wiadomo, jaka decyzja zostanie podjęta, jeśli zawiedzie zależność lub dowody podważą hipotezę?
Jeśli odpowiedź na kilka pytań brzmi „nie”, kolejnym krokiem nie zawsze jest dodanie zadań. Może nim być doprecyzowanie kontraktu, uzyskanie decyzji lub ograniczenie wycinka do ścieżki, którą da się sprawdzić. Przydatne planowanie pokazuje, co będzie można wykorzystać lub czego się dowiedzieć, czego brakuje, by to osiągnąć, i kto zareaguje na każdą niepewność. W ten sposób małe przyrosty ograniczają ryzyko, nie zamieniając wspólnej pracy w mglistą obietnicę.
