Jak zjeść słonia? Pięć pomocnych sposobów na podzielenie tego co pozornie niepodzielne.




Jeśli miałeś okazję w jakiejkolwiek formie przechodzić wprowadzająca pojęcie zwinnego wytwarzania oprogramowania lub wstęp do metodyki SCRUM to tytuł tego artykułu może przywoływać pewne skojarzenia. Dla zachowania pełnej transparencji i zrozumienia dodam tylko że chodzi o pewną analogię obrazującą istotę inkrementalnego podejścia do budowy produktu:
Jak najprościej zjeść słonia?
Po kawałku.
Jedną z dobrych praktyk związanych z metodyką SCRUM jest definiowanie zadań wystarczająco małych, aby ich pełna realizacja zajmowała nie więcej niż jeden sprint. Pomaga to bardzo w zachowaniu pewnej kadencji dostarczania wartościowych i skończonych elementów w produkcie. Niestety ta sama praktyka stawia przed produktowcami czasami ciężkie zadanie podzielenia większego zagadnienia na mniejsze, ale nadal wartościowe części.
Jak więc podzielić pozornie niepodzielne lub jeszcze niezbadane zagadnienie na mniejsze elementy? Na szczęście z pomocą przychodzi przyjazny pajączek, a właściwie anagram zaproponowany przez Mike’a Cohn’a – SPIDR. Jest to skrót proponujący pięć możliwych „cięć”, w wyniku których z jednego zbyt dużego zadania uzyskamy mniejsze ale nadal wartościowe kawałki do realizacji w ramach sprintu. Poniżej znajdziesz krótkie rozwinięcie tego skrótu, a w kolejnych akapitach podzielę się z Tobą kilkoma obserwacjami na temat każdego sposobu podziału.
Spike – polega na pozyskaniu większej wiedzy na temat koniecznych kroków do realizacji zadania poprzez np. stworzenie bardzo prostego „proof of concept”
Path – podział ze względu na ścieżki użytkownika (w miejscu gdzie flow się rozdziela implementujemy tylko jedną odnogę w jednym zadaniu)
Interface – podział ze względu na sposób dostępu do danej funkcji/informacji (np. osobne widoki w produkcie, urządzenia mobilne vs. desktop vs. e-mail)
Data – podział ze względu na przetwarzane dane – często pełny zakres funkcji wymaga obsługi wielu punktów informacji, ale pozytywny scenariusz można zamknąć z tylko kilkoma podstawowymi
Rules – podział ze względu na obsługę różnych i rozdzielnych zasad biznesowych lub technologicznych
Spike.
W mojej dotychczasowej praktyce jest to chyba najczęściej stosowane podejście w przypadku kiedy naprawdę nie wiadomo co zrobić. Przykładem takiej sytuacji może być potrzeba wdrożenia rozwiązania, co do którego nikt w zespole/organizacji nie ma pewności lub pewnej wiedzy. W odróżnieniu od pozostałych cięć, produktem takiego typu zadania powinna być dokładniejsza wiedza o tym, jakie kroki należy podjąć. Moim zdaniem najlepiej jest od razu tą wiedzę przekuć w kolejne zadania do product backlogu i zadbać o to aby były one dobrze udokumentowane. Zaletą tego podejścia jest możliwość rozpoznania zbyt ciężkich lub zbyt złożonych zagadnień do rozpracowania na papierze. Mankamentem zaś jest to, że w jego wyniku nie powstaje jeszcze żadna wartość w produkcie. Dlatego zalecałbym rozważne stosowanie, bo pamiętajmy że miarą postępu jest działające oprogramowanie, a nie wiedza „na papierze”.
Path.
Najbardziej plastycznym przykładem jaki przychodzi mi do głowy dla tego cięcia jest formularz konfiguracji produktu. Rozważmy konfigurator laptopa, gdzie krok po kroku dokonujemy wyborów dotyczących pożądanego przez nas sprzętu. Poza wyborem modelu możemy wybrać np. rodzinę systemu operacyjnego jaki ma zostać zainstalowany. W zależności od wyboru w kolejnym kroku dostaniemy do wyboru konkretną wersję oraz ew. oprogramowanie dodatkowe. Wybierając dysk twardy najpierw wybierzemy typ (HDD/SSD), a później jego rozmiar. Jakiekolwiek procesy z rozgałęzieniami będą wdzięcznym obiektem takiego podziału – w pierwszym kroku możemy dopiąć pełne przejście od startu do końca najprostszą drogą. Zauważ że już wtedy pojawia się jakaś potencjalna wartość w produkcie. Oczywiście funkcja nie jest kompletna i gotowa do finalnego wydania, ale już np. możemy zacząć wewnętrzne testy z użytkownikami żeby sprawdzić jego użyteczność i intuicyjność.
Interface.
Idealnym przykładem tutaj byłaby aplikacja Clubhouse. W pierwszej kolejności została zbudowana aplikacja na iPhone’y, a urządzenia z Androidem znajdują się dopiero w dalszych planach. Dzięki temu podejściu można było mniej więcej o połowę (bez konieczności czekania na ukończenie drugiej aplikacji przez zespół lub wręcz inwestowania w nią) skrócić czas wykonania pierwszych walidacji produktu, zebrania feedbacku od użytkowników. W przypadku Clubhouse cięcie to okazało się tak skuteczne, że aplikacja na Androida w ogóle została przesunięta na dalszy plan, bo gwałtowne tempo wzrostu produktu spowodowało konieczność szybszej pracy nad optymalizacją wydajności i stabilności aplikacji. Sposób ten jest bardzo wdzięczny w użyciu gdy jedna funkcjonalność ma zostać dostarczona w kilku obszarach produktu, albo na różnych platformach.
Data.
Przykładem cięcia według danych może być znany na pewno wszystkim formularz danych dostawy, który praktycznie w każdym sklepie internetowym zawiera niemal identyczne dane. Ponownie – drogę do pierwszego wzrostu wartości w produkcie możemy sobie skrócić np. rezygnując z opcji wysyłki na inny adres niż dane rozliczeniowe. Albo wręcz ograniczając formularz do podstawowych danych adresowych, nie pytając o dane firmy. Oczywiście ponownie -nie będzie to skończona funkcja, ale za to nawet w takiej formie możemy znaleźć użytkowników którym reszta danych nie będzie potrzebna i skorzystają z takiego formularza. Takie podejście może pomóc nam w ograniczeniu koniecznych nakładów pracy gdy mamy do przetworzenia dużą ilość informacji, z których nie wszystkie są krytyczne do wykonania podstawowej operacji.
Rules.
Podział zadań według reguł biznesowych możemy rozważyć także w kontekście sklepu internetowego. Na przykład podstawową formą działania sklepu jest sprzedaż produktu, który jest wprowadzony do niego. Kolejnymi zasadami rozszerzającymi sprzedaż produktu może być np. limit ilości przedmiotów w koszyku, podanie informacji o niedostępności produktu gdy stan magazynowy jest niewystarczający, podanie informacji o przekroczeniu ilości produktu w koszyku względem stanu na magazynie itd. Cięcie to jest użyteczne wszędzie tam, gdzie mamy do obsłużenia kilka różnych zabezpieczeń, których logika jest bardziej skomplikowana i wymaga więcej pracy, lecz nie jest konieczna do sprawdzenia.
Mam nadzieję, że te pięć „cięć” okaże się pomocnych w zjadaniu tytułowego słonia 🙂 Jednocześnie jeśli znasz inne sposoby okiełznania zbyt dużych zadań, to zapraszam serdecznie do podzielenia się nimi w komentarzach: )
Piona!