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 przypomina sposób, w jaki nóż rozcina ciasto — 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 efektów widocznych dla użytkowników. 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. 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 dostrzegają 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 zbudować w kolejnym etapie”. Dyskomfort związany z dostarczeniem fałszywego backendu jest realny — jednak jest on 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 — dotyczy to migracji do nowego dostawcy usług uwierzytelniania, wymiany zaplecza kolejki czy zastąpienia 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ć poziom zaangażowania. 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ł niewielki wycinek obejmujący wszystkie warstwy — interfejs użytkownika, logikę i dane — i dostarczał coś, z czego użytkownik może faktycznie skorzystać, nawet jeśli obsługuje on 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 zajmujemy się frontendem, w następnym backendem — więc żaden pojedynczy sprint nie przynosi efektów, z których mógłby skorzystać użytkownik. Podział wertykalny opiera się na rezultatach dla użytkownika, więc 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 praca dotyczy podstawowych elementów platformy i nie ma gotowego do wdrożenia modułu przeznaczonego dla użytkowników — 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 traktować jako takie i informować o harmonogramie, 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ęć rzetelnych cięć pionowych.
• Szacowanie w metodologii agile: kompletny przewodnik — tutaj znajdą Państwo wszystkie niezbędne informacje.