Przeczytaj wersję webową.

✂ 5 technik podziału funkcjonalności na mniejsze

Cześć!

Niezależnie czy w zespole jesteś osobą techniczną czy produktową - natrafiłeś/aś na problem wdrażania zbyt dużej funkcjonalności. Zadania się ciągną. Zakres się zmienia. Nie wiadomo kiedy powiedzieć dosyć.

Dlatego w dzisiejszym newsletterze przedstawiam jak dzielić funkcjonalności na mniejsze - dlaczego to robić, oraz 5 technik.

A więc w dzisiaj mam dla Ciebie:

Miłego czytania 😀

Dlaczego dzielić wdrażane funkcjonalności na mniejsze części

Małe jest piękne, jak to mówi klasyk 😉 Ale to nie przekona co niektórych, że warto dostarczać małymi partiami.

Dlatego warto sięgnąć do twardszej argumentacji. Donald Reinertsen napisał ksiażkę The Principles of Product Development Flow. Jest to kompedium wiedzy jak dostarczać efektywnie produkty cyfrowe.

Donald poświęcił cały rozdział tylko i jedynie na temat dostarczania mniejszych funkcjonalności. Dostarczanie w mniejszych partiach:

• zmniejsza całościowy czas dostarczenia,
• zmniejsza zmienność zadań,
• przyśpiesza feedback,
• zmniejsza potencjalne ryzyka,
• zwiększa motywację zespołu,
• pozwala skupić się najpierw na najbardziej zyskownych zadaniach.

Prawda, że warto? 😎

Techniki podziału

Poniżej 5 technik, które możesz wykorzystać wspólnie, bądź zamiennie, aby dzielić funkcjonalności na mniejsze.

💪 Empowered - 4 założenia funkcjonalności

Nie wiem czy czytałeś/aś książkę Empowered Martiego Cagana. Świetnie podsumowuje główne zasady pracy zespołów produktowych.

Pośród wielu informacji z tej książki jest ukryty sposób na dzielenie funkcjonalności na mniejsze. A są nim 4 założenia funkcjonalności.

Wg. Martiego dana funkcjonalność przy wdrożeniu powinna być:

• Wartościowa - Czy klienci będą chcieli z tego korzystać?
• Użyteczna - Czy będzie wiadomo jak z tego korzystać?
• Wykonalna - Czy to jest dostarczalne technicznie?
• Spójna biznesowo - Czy powinniśmy to robić?

W jaki sposób możesz to wykorzystać?

Pracując nad daną funkcjonalnością możesz ją podzielić na mniejsze w ten sposób, aby najpierw zwalidować powyższe pytania. Każde rozwiązanie, które przybliża Ciebie do odpowiedzi na te pytania jest sposobem podziału funkcjonalności.

W ramach potwierdzenia zmniejszenia funkcjonalności możesz wykorzystać np.

• Wartościowa - Prototypowanie z klientem.
• Użyteczna - Walking Skeleton by sprawdzić przepływ pracy.
• Wykonalna - Proof of Concept możliwości technicznych.
• Spójna biznesowo - Określenie głównego wyróżnika biznesowego, aby skupić się na najważniejszym aspekcie.

Każda z tych technik zabierze część odpowiedzialności z głównej funkcjonalności. Dzięki temu finalnie będziesz mieć mniej do dostarczania.

👣 Praca iteracyjna i przyrostowa

W artykule Incremental vs Iterative Development David Daniel przedstawia następujący podział pracy zwinnej:

• Podejście iteracyjne - dostarcza niedokończoną pracę jako całość. Szersza obszar dostał dostarczony, ale nie jest jeszcze kompletny.
• Podejście przyrostowe - dostarczanie jednego kompletnego elementu na raz jest podstawą podejścia przyrostowego. Może to oznaczać dostarczanie zestawu niezależnych funkcji w każdym sprincie.

Dlaczego to jest istotne?

• Podejście wyłącznie iteracyjne sprawdza się dobrze, gdy masz bazowe zrozumienie dokąd chcesz dążyć. Chcesz rozwijać swoją wizję, zmieniać kierunek w ramach kolejnych iteracji.
• Podejście wyłącznie przyrostowe jest najlepsze, gdy masz bardzo jasną wizję tego, co tworzysz. Dokładnie wiesz, że chcesz 1-2-3 i w ten sposób budujesz rozwiązanie.

Oba te podejścia możesz zastosować, aby zmniejszyć zakres tworzonej funkcjonalności. Możesz sobie zadać pytania:

• Podejście iteracyjne: Jak obniżyć głębokość danej funkcjonalności? Jaki szkielet mogę dostarczyć? Jak bazowo przejść A->Z?
• Podejście przyrostowe: Jaki jest najmniejszy krok, jaki mogę wykonać? Jak domknąć dany obszar, bez dotykania kolejnych?

Te pytania, połączone z kolejnymi technikami, mają ogromną moc dzielenia na mniejsze części 🗻

🪜 Praca w pionowych częściach

Jeśli jesteś głodny/a to spodoba Ci się to podejście 😀

Często mamy zwyczaj do koncentrowania się na aspektach technicznych. Myślimy, że funkcjonalność wymaga olbrzymiej pracy na całej warstwie np. bazy danych.

Jednak, aby zmniejszyć funkcjonalność dobrze się skupić na realizacji pojedynczej potrzeby biznesowej. To jednak wymaga pracy pomiędzy różnymi obszarami technicznymi.

Dlatego trzeba zmienić sposób myślenia. Tutaj są do wykorzystania dwie metafory:

• Tortu - z artukułu Delta Matrix:

• Hamburgera - z artykułu Gojko Adzica:

Każda z tych metafor skupia się mniej więcej na tym samym. Koncentrujemy się na pionowym wycinku danej funkcjonalności. Łączymy ze sobą różne warstwy techniczne (tortu, hamburgera), aby ostatecznie dostać jeden “gryz”.

Dzięki czemu dostarczamy spójną funkcjonalność biznesową. Mamy różne mniejsze zadania techniczne, które skupiają się na realizacji małego celu biznesowego.

📝 Event Storming - polityki i alternatywne ścieżki

Bardzo dobrze do dzielenia funkcjonalności na mniejsze sprawdza się Event Storming.

W ogóle Event Storming sprawdza się świetnie 😀 Nie znasz tej techniki? Rozpocznij od poradnika!

Na samym początku Event Storming Process Level rozpoczynamy od podziału funkcjonalności na poszczególne zdarzenia. Następnie dodajemy kolejne elementy notacji - modele odczytu, komendy, reakcje.

Proces dodawania produktu może wyglądać następująco:

Mamy:

• Główne dodawanie produktu.
• Reakcję w postaci definicji cennika.
• Reakcję w postaci powiadamiania działu logistyki.

Chyba już wiesz dokąd zmierzam 😎

Wykorzystujemy reakcje (reguły, polityki), aby oddzielać główną funkcjonalność, od tej dodatkowej. Każda fioletowa karteczka to dla nas wskazówka. Możemy zrealizować główną funkcję, a następnie przejść do kontynuacji procesu w kolejnej iteracji.

W ramach Event Stormingu wypracujemy również alternatywne ścieżki. Są one rzadziej wykorzystywane przez naszych klientów. Przez co też świetnie sprawdzą się w kolejnej iteracji.

📕 Rodzaje reguł

Na koniec zostawiłem bombę (wiedzy). W ramach swojej prezentacji Logiczne podejście do logiki Sławek Sobótka przedstawił taki podział logiki biznesowej w systemie:

Jest to świetna baza, by zastanowić się jakie reguły biznesowe musimy spełniać najpierw. Opisujemy dla danej funkcjonalności:

• walidacje syntaktyczne,
• logikę aplikacyjną,
• walidacje biznesowe,
• reguły spójności zmiany,
• reguły spójności danych,
• reguły transformacji danych na potrzeby widoków,
• reguły kolejnych kroków procesu.

Następnie określamy, czy na pewno potrzebujemy wszystkich reguł naraz. Rzadko kiedy tak będzie. Zwykle część z nich można przenieść na kolejne wdrożenie.

Dzięki czemu okrajamy funkcjonalność ze wszystkich opcjonalnych reguł. Na końcu może się okazać, że wcale nie potrzebujesz ich wdrażać.

A jak to wygląda u Ciebie?

Za pomocą jakich technik radzisz sobie z dzieleniem funkcjonalności na mniejsze części?

Daj znać w odpowiedzi na tego e-maila. Z chęcią poznam kolejne techniki 😀

📧 Prześlij dalej

Dzięki, że doczytałeś(aś) do końca. 😊

Wszystkie poprzednie wydania newslettera są dostępne tutaj.

Jeśli spodobał Ci się mój newsletter, prześlij go proszę osobom, którym też mógłby się spodobać. Z góry dziękuję.

A jeśli nie jesteś jeszcze w newsletterze, to zachęcam do zapisania się.

Polecam się na przyszłość!
Radek Maziarka

P.S. Co myślisz o tym newsletterze? Odpisz :)