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. 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łowy 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żytkownika. Wąski wycinek, 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 wycinek, ale każdy z nich stanowi rzeczywisty, gotowy do wdrożenia element. Lista zmian się zapełnia, użytkownicy dostrzegają postępy, a zespół może korygować kierunek działań w oparciu o rzeczywiste wykorzystanie, a nie o przewidywania.

Kiedy konieczne wydaje się dzielenie poziome

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 zbudować 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: podstawowa praca na platformie

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, zmiana zaplecza kolejki, wymiana 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 traktować jako projekt, poinformować o harmonogramie i zaakceptować fakt, że tempo pracy zespołu będzie odzwierciedlać nakład pracy. 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?

Podejście oparte na pionowym podziale polega na rozbiciu projektu na części w oparciu o wyniki dla użytkownika, tak aby każdy fragment stanowił niewielki 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 cięciem poziomym a pionowym?

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 przynosi rezultatu, z którego mógłby skorzystać użytkownik. Podział wertykalny opiera się na oczekiwanych rezultatach dla użytkownika, dzięki czemu każdy fragment zapewnia działającą ścieżkę od początku do końca. Fragmenty wertykalne dostarczają wartość; fragmenty horyzontalne dostarczają obietnice.

Dlaczego podział pionowy jest lepszy?

Ponieważ każdy fragment stanowi rzeczywisty, gotowy do wdrożenia element. Lista zmian się wydłuża, użytkownicy dostrzegają postępy, a zespół może korygować kierunek działań w oparciu o rzeczywiste wykorzystanie, a nie o prognozy. Podział horyzontalny pozwala zwiększyć wskaźniki prędkości realizacji, podczas gdy produkt widoczny dla użytkowników pozostaje niezmieniony przez cały czas trwania poszczególnych sprintów.

Kiedy dopuszczalne jest dzielenie poziome?

Gdy zadanie ma charakter prac nad podstawową platformą i nie obejmuje żadnego elementu widocznego dla użytkownika przed zakończeniem – na przykład migracja dostawców uwierzytelniania, wymiana zaplecza kolejki lub zastąpienie potoku wdrażania – należy je traktować jako projekty, a nie zadania: należy je odpowiednio oszacować i podawać harmonogram, zamiast udawać, że można je podzielić.

Materiały powiązane

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