Cięcie poziome a cięcie pionowe

Podział pionowy dzieli opowieść według wyników dla użytkownika; podział poziomy dzieli ją według warstw technicznych. To właśnie ten jeden wybór decyduje o tym, czy każdy fragment dostarcza coś, czy nic. Fragmenty pionowe dostarczają wartość. Fragmenty poziome dostarczają obietnice.

Cięcie w poziomie polega na rozdzielaniu ciasta tak, jak robi to nóż: otrzymuje się dwie połówki niczego.

Różnica

Podział horyzontalny odbywa się wzdłuż warstw architektury: w bieżącym sprincie zajmujemy się interfejsem użytkownika, w następnym – zapleczem, a w kolejnym – bazą danych. Prace mieszczą się w ramach sprintów, jednak żaden pojedynczy sprint nie przynosi rezultatów, z których mogliby skorzystać użytkownicy. Wskaźniki wydajności zespołu rosną, natomiast lista zmian widoczna dla użytkowników pozostaje pusta.

Podział pionowy opiera się na wynikach dla użytkowników. Niewielki fragment, który obejmuje każdą warstwę: pojedynczy przycisk, który faktycznie działa od początku do końca, nawet jeśli obsługuje tylko jeden przypadek wprowadzenia danych. Zespół dostarcza mniej na każdy fragment, ale każdy fragment jest rzeczywistym, gotowym do wdrożenia elementem. Lista zmian się zapełnia, użytkownicy widzą postępy, a zespół może korygować kierunek działań w oparciu o rzeczywiste wykorzystanie, a nie o przewidywania.

Gdy konieczne wydaje się dzielenie w płaszczyźnie poziomej

Zazwyczaj tak nie jest. „Potrzebujemy schematu bazy danych, zanim będziemy mogli stworzyć interfejs użytkownika” – to klasyczne uzasadnienie, które niemal zawsze ustępuje miejsca podejściu: „możemy zakodować odpowiedź na stałe, wydać interfejs użytkownika, a bazę danych stworzyć w kolejnym etapie”. Dyskomfort związany z dostarczeniem fałszywego backendu jest realny, ale mniejszy niż dyskomfort wynikający z braku jakichkolwiek wyników przez trzy sprinty.

Wyjątek: praca na platformach o charakterze podstawowym

Niektóre elementy infrastruktury nie mają części widocznej dla użytkownika, dopóki nie zostaną w pełni ukończone: migracja do nowego dostawcy usług uwierzytelniających, wymiana zaplecza kolejki, zastąpienie potoku wdrażania. Są to projekty, a nie zadania. Należy traktować je odpowiednio: nie należy dzielić ich horyzontalnie i udawać, że są czymś innym. Należy je zakwalifikować jako projekt, poinformować o harmonogramie i zaakceptować fakt, że tempo pracy zespołu będzie odzwierciedlać nakład środków. Przedstawianie migracji trwającej trzy sprinty jako trzech „zadań” wprowadza w błąd jedynie wykres burndown.

Jeśli fragment nie zawiera niczego, z czego użytkownik mógłby skorzystać, nie jest to fragment.

Najczęściej zadawane pytania

Czym jest podział pionowy w metodologii agile?

Metoda pionowego podziału polega na rozbiciu funkcji na części odpowiadające konkretnym rezultatom dla użytkownika, tak aby każdy fragment stanowił wąski przekrój przez wszystkie warstwy (interfejs użytkownika, logikę i dane), dostarczający coś, z czego użytkownik może faktycznie skorzystać, nawet jeśli obsługuje to tylko jeden przypadek. Każdy fragment można wydać osobno.

Jaka jest różnica między podziałem horyzontalnym a wertykalnym?

Podział horyzontalny opiera się na warstwach technicznych – w jednym sprincie realizowana jest część front-endowa, a w następnym – część back-endowa, w związku z czym żaden pojedynczy sprint nie dostarcza użytkownikowi gotowego rozwiązania. Podział wertykalny opiera się na rezultatach dla użytkownika, dzięki czemu każdy etap dostarcza działającą ścieżkę od początku do końca. Etapy wertykalne dostarczają wartość; etapy horyzontalne dostarczają obietnice.

Dlaczego podział pionowy jest lepszy?

Ponieważ każdy fragment stanowi rzeczywisty, gotowy do wdrożenia element. Lista zmian stopniowo się zapełnia, użytkownicy dostrzegają postępy, a zespół może korygować kierunek działań w oparciu o rzeczywiste wykorzystanie, a nie o prognozy. Podział poziomy pozwala zwiększyć tempo realizacji, podczas gdy produkt dostępny dla użytkowników pozostaje niezmieniony przez cały czas trwania poszczególnych sprintów.

W jakich przypadkach dopuszczalne jest dzielenie poziome?

Gdy zadanie dotyczy prac nad podstawową platformą i nie obejmuje żadnego elementu widocznego dla użytkownika przed zakończeniem realizacji — np. migracja dostawców usług uwierzytelniania, wymiana zaplecza kolejki lub zastąpienie potoku wdrażania — są to projekty, a nie zadania: należy je odpowiednio sklasyfikować i przedstawiać harmonogram ich realizacji, zamiast udawać, że można je podzielić.

Warto przeczytać

• Podział opowieści użytkownika: kompletny zestaw narzędzi oraz wskazówki, jak odróżnić prawdziwy podział od pozornego.
• Podział historii SPIDR: pięć sprawdzonych metod podziału pionowego.
• Szacowanie w metodologii agile: kompletny przewodnik: tutaj znajdą Państwo wszystkie niezbędne informacje.