Extreme Programming jako “układ odpornościowy”: wdrażanie praktyk XP w E-commerce

Kiedy zmieniają się reguły gry

Wyobraźcie sobie: w projekcie jednocześnie rotują się zespoły, dochodzą nowi vendorzy, a platforma obsługuje kilka sklepów w różnych regionach. Każdy z własnymi zasadami podatkowymi, walutami i dostawcami płatności. Do tego dziesiątki integracji: PIM, ERP, WMS, CRM, narzędzia marketingowe i SEO.

Dokładnie w takiej sytuacji się znaleźliśmy. Onboarding nowego programisty zajmował do czterech tygodni. W kodzie narastały „strefy strachu”, moduły, do których nikt nie chciał zaglądać, bo nikt do końca nie rozumiał, jak działają. Błędy z jednego regionu przenikały do drugiego. Każdy release przypominał loterię.

Potrzebowaliśmy czegoś więcej niż nowego procesu. Potrzebowaliśmy czegoś w rodzaju układu odpornościowego: mechanizmu, który nie leczy chorób po fakcie, ale rozpoznaje zagrożenia z wyprzedzeniem i wytwarza na nie „przeciwciała”. Takim systemem stały się dla nas praktyki Extreme Programming (XP).

XP opiera się na czterech grupach praktyk: informacja zwrotna (Feedback), proces ciągły (Continual Process), zrozumienie kodu (Code Understanding) i warunki pracy (Work Conditions). Poniżej opisujemy, jak każda z nich działa w naszym projekcie i jakie konkretne rezultaty przynosi.

1. Feedback: projektowanie jako kontrakt

W klasycznym XP pierwszą linią obrony są testy. Rozwój opiera się na testach (Test-Driven Development), które natychmiast sygnalizują problemy. Przy braku stuprocentowego pokrycia autotestami rolę takiego „wczesnego sygnału” w naszym projekcie przejął brief techniczny (Technical Brief).

Brief techniczny zamiast ślepego kodowania. Przed pierwszą linijką kodu zespół przygotowuje szczegółowy dokument: scenariusze pozytywne i negatywne, decyzje architektoniczne, punkty integracji. W istocie jest to kontrakt między analitykiem biznesowym a programistą. Kontrakt, który daje pewność jeszcze przed rozpoczęciem pracy i eliminuje kategorię błędów typu „nie wiedziałem, że tak też może być”. Jeśli TDD zapewnia wczesną informację zwrotną poprzez testy, to brief techniczny zapewnia ją na poziomie projektowania zmian i logiki biznesowej.

Programowanie w parach (Pair Programming) dla złożonych obszarów. Sesje w parach stosujemy punktowo: przy zadaniach o wysokiej złożoności lub „historycznie splątanych” modułach. Na przykład przy zmianie logiki naliczania podatków dla różnych regionów nowy programista siada z doświadczonym team leadem i razem przechodzą przez legacy code. Nowy członek zespołu zdobywa kontekst, a lead zyskuje świeże spojrzenie i natychmiastowe review. Takie podejście zmniejszyło liczbę błędów wykrywanych na etapie code review o 1,5 raza.

On-site Customer i Planning Game. Współpraca z firmą produktową daje nam bezpośredni dostęp do biznesu. Zadania są oceniane na podstawie rzeczywistej złożoności i zależności, a nie w abstrakcyjnych jednostkach. Interesariusze widzą pełny obraz: „Funkcjonalność na froncie jest prosta, ale prace nad integracją z ERP czynią ją kosztowną”. Pozwala to eliminować konflikty na etapie priorytetyzacji, a nie w trakcie release’u.

2. Proces ciągły (Continual Process): refaktoryzacja z wyprzedzeniem

Jeśli informacja zwrotna to zdolność organizmu do rozpoznawania zagrożeń, to proces ciągły to zdolność do regeneracji. Kod, który nie jest aktualizowany, staje się kruchy. Ale refaktoryzacja dla samej refaktoryzacji to marnotrawstwo zasobów. Dlatego u nas jest ona powiązana z celami biznesowymi.

Case study: dostawcy płatności. Na początku każdego kwartału analizujemy Roadmap. Załóżmy, że za trzy miesiące trzeba podłączyć pięciu nowych dostawców płatności, a obecna architektura nie jest przystosowana do takiego skalowania. Zamiast heroicznie upychać nowy kod w starą strukturę na tydzień przed deadline’em, zadania dotyczące przygotowania infrastruktury tworzymy z wyprzedzeniem.

Przygotowanie infrastruktury (Infrastructure Enablers). Interfejsy są modyfikowane, wspólna logika wynoszona do osobnych modułów, a kod trafia do głównej gałęzi na długo przed rozpoczęciem prac nad konkretnym dostawcą. W momencie startu prac biznesowych platforma jest już gotowa do rozszerzenia. Programista nie walczy z architekturą, a po prostu implementuje logikę biznesową.

Jak ważne jest to powiązanie z roadmapą, dobrze pokazuje nasz case z dekompozycją monolitycznego komponentu Angular. Refaktoryzacja została wykonana technicznie czysto i w terminie, ale wkrótce po jej zakończeniu klient zrewidował koncepcję ekranu i branch trzeba było zarchiwizować. Doświadczenie inżynierskie nie przepadło: podejścia do podziału odpowiedzialności i budowania API komponentów są stosowane w innych zadaniach. Ale sam case stał się dla zespołu wymownym argumentem: planową refaktoryzację trzeba synchronizować nie tylko ze stanem technicznym kodu, ale również z kierunkiem rozwoju produktu.

Kontrola jakości przez ludzi (Human-driven CI). Pipeline’y CI/CD wyłapują błędy składniowe i padające testy. Ale na platformie wieloregionalnej ważniejsze jest co innego: czy zmiana dla jednego regionu nie zepsuje czegoś w drugim? Tę weryfikację przeprowadzają tech leadzi poprzez ręczne review każdego Merge Requesta.

Małe releasy (Small Releases). Po każdej refaktoryzacji przeprowadzane jest rozbudowane testowanie: zmiany dla regionu „A” nie mogą wpłynąć na logikę biznesową w regionie „B”. Dopiero po takiej weryfikacji kod trafia na produkcję małymi, bezpiecznymi porcjami. Częstotliwość releasów wzrosła, a liczba „niespodzianek” na produkcji spadła.

3. Zrozumienie kodu (Code Understanding): jednolity regulamin dla wszystkich zespołów

Układ odpornościowy działa, ponieważ potrafi odróżnić „swoje” od „obcego”. W kodzie obowiązuje ta sama logika: kiedy nad projektem pracuje kilka zespołów i vendorów, Collective Code Ownership bez ścisłych reguł zamienia się w zbiorową nieodpowiedzialność.

Standardy kodowania (Coding Standards). Udokumentowane jest wszystko: od zasad nazewnictwa zmiennych po wzorce obsługi błędów w punktach integracji. To nie dokument doradczy, to prawo projektu. Każdy nowy programista zapoznaje się z nim przed pierwszym commitem. Kod niespełniający standardów nie przechodzi review. Bez wyjątków.

Współwłasność kodu (Collective Code Ownership). Dzięki jednolitym standardom i briefom technicznym każdy programista może spokojnie wejść w „cudzy” moduł i wprowadzić zmiany. Odeszliśmy od sytuacji „niezastąpionych ludzi” i strachu przed starym kodem. Pozwala to szybko przerzucać zasoby na pilne kierunki bez długiego wdrażania się.

Prostota rozwiązań (Simple Design). Toczymy osobną walkę z overengineeringiem. Zadaniem programisty jest zrealizować scenariusze z briefu w maksymalnie prosty i łatwy w utrzymaniu sposób. Abstrakcje na trzy poziomy w głąb „na przyszłość” nie są mile widziane. Przyszłe zadania obsługuje refaktoryzacja z wyprzedzeniem, a nie spekulacyjna architektura.

4. Warunki pracy (Work Conditions): zrównoważone tempo

Ostatni element układu odpornościowego to ogólne zdrowie organizmu. Zmęczony programista popełnia błędy, których nie wyłapie ani brief, ani review.

Kiedy zasady są przejrzyste, a zadania szczegółowo opisane, development staje się przewidywalnym procesem. Onboarding przebiega bez „pożarów”. Nadgodziny przestają być normą.

40-godzinny tydzień pracy w naszym przypadku to nie benefit i nie idealizm, a inwestycja w jakość. Koszt błędu w kodzie, od którego zależą produkty e-commerce w kilku regionach, jest zbyt wysoki, żeby dopuszczać do niego z powodu zmęczenia.

Co to dało projektowi

Przed wdrożeniem praktyk XP projekt działał, ale każdy release i każda rotacja zespołu były stresujące. Po wdrożeniu proces stał się sterowalny.

• Przewidywalność i strategiczne planowanie rozwoju. Kod jest przygotowywany na zmiany z wyprzedzeniem, na podstawie planowania kwartalnego i celów biznesowych.
• Bezpieczne skalowanie zespołu. Nowe zespoły i vendorzy szybko wchodzą w projekt dzięki jednolitym standardom. Nowi członkowie zespołu zaczynają wnosić wartość w drugim tygodniu, a nie po miesiącu.
• Zbiorowa odpowiedzialność i wsparcie. Każdy moduł jest dostępny dla każdego programisty, ponieważ jest napisany we „wspólnym języku” projektu, a programowanie w parach stało się najlepszym sposobem dla nowych osób na przyswojenie kontekstu od doświadczonych kolegów i natychmiastowe przeprowadzenie review kodu.