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

Jeśli mia­łeś oka­zję w jakiej­kol­wiek for­mie przecho­dzić wpro­wa­dza­jąca poję­cie zwin­nego wytwa­rza­nia opro­gra­mo­wa­nia lub wstęp do meto­dyki SCRUM to tytuł tego arty­kułu może przy­wo­ły­wać pewne sko­ja­rze­nia. Dla zacho­wa­nia peł­nej trans­pa­ren­cji i zro­zu­mie­nia dodam tylko że cho­dzi o pewną ana­lo­gię obra­zu­jącą istotę inkre­men­tal­nego podej­ścia do budowy pro­duktu:

Jak naj­pro­ściej zjeść sło­nia?

Po kawałku.

Jedną z dobrych prak­tyk zwią­za­nych z meto­dyką SCRUM jest defi­nio­wa­nie zadań wystar­cza­jąco małych, aby ich pełna reali­za­cja zaj­mo­wała nie wię­cej niż jeden sprint. Pomaga to bar­dzo w zacho­wa­niu pew­nej kaden­cji dostar­cza­nia war­to­ściowych i skoń­czo­nych ele­men­tów w pro­duk­cie. Nie­stety ta sama prak­tyka sta­wia przed pro­duk­tow­cami cza­sami cięż­kie zada­nie podzie­le­nia więk­szego zagad­nie­nia na mniej­sze, ale na­dal war­to­ściowe czę­ści.

Jak więc podzie­lić pozor­nie nie­po­dzielne lub jesz­cze nie­zba­dane zagad­nie­nie na mniej­sze ele­menty? Na szczę­ście z pomocą przy­cho­dzi przy­ja­zny pają­czek, a wła­ści­wie anagram zapro­po­no­wany przez Mike’a Cohn’a – SPIDR. Jest to skrót pro­po­nu­jący pięć moż­li­wych „cięć”, w wyniku któ­rych z jed­nego zbyt dużego zada­nia uzy­skamy mniej­sze ale na­dal war­to­ściowe kawałki do reali­za­cji w ramach sprintu. Poni­żej znaj­dziesz krót­kie roz­wi­nię­cie tego skrótu, a w kolej­nych aka­pi­tach podzielę się z Tobą kil­koma obser­wa­cjami na temat każ­dego spo­sobu podziału.

Spike – polega na pozy­ska­niu więk­szej wie­dzy na temat koniecz­nych kro­ków do reali­za­cji zada­nia poprzez np. stwo­rze­nie bar­dzo pro­stego „proof of con­cept”

Path – podział ze względu na ścieżki użyt­kow­nika (w miej­scu gdzie flow się roz­dziela imple­men­tu­jemy tylko jedną odnogę w jednym zadaniu)

Inter­face – podział ze względu na spo­sób dostępu do danej funk­cji/infor­ma­cji (np. osobne widoki w pro­duk­cie, urzą­dze­nia mobilne vs. desk­top vs. e-mail)

Data – podział ze względu na prze­twa­rzane dane – czę­sto pełny zakres funk­cji wymaga obsługi wielu punk­tów infor­ma­cji, ale pozy­tywny sce­na­riusz można zamknąć z tylko kil­koma pod­sta­wo­wymi

Rules – podział ze względu na obsługę róż­nych i roz­dziel­nych zasad bizne­so­wych lub tech­no­lo­gicznych

Spike.

W mojej dotych­cza­so­wej prak­tyce jest to chyba naj­czę­ściej sto­so­wane podej­ście w przy­padku kiedy naprawdę nie wia­domo co zro­bić. Przy­kładem takiej sytu­acji może być potrzeba wdro­że­nia roz­wią­za­nia, co do któ­rego nikt w zespo­le­/or­ga­ni­za­cji nie ma pew­no­ści lub pew­nej wie­dzy. W odróż­nie­niu od pozo­sta­łych cięć, pro­duk­tem takiego typu zada­nia powinna być dokład­niej­sza wie­dza o tym, jakie kroki należy pod­jąć. Moim zda­niem naj­le­piej jest od razu tą wie­dzę prze­kuć w kolejne zada­nia do pro­duct bac­klogu i zadbać o to aby były one dobrze udo­ku­men­to­wane. Zaletą tego podej­ścia jest moż­li­wość roz­po­zna­nia zbyt cięż­kich lub zbyt zło­żo­nych zagad­nień do rozpracowania na papierze. Man­ka­men­tem zaś jest to, że w jego wyniku nie powstaje jesz­cze żadna war­tość w pro­duk­cie. Dla­tego zale­cał­bym roz­ważne sto­so­wa­nie, bo pamię­tajmy że miarą postępu jest dzia­ła­jące opro­gra­mo­wa­nie, a nie wiedza „na papie­rze”.

Path.

Najbar­dziej pla­stycz­nym przy­kładem jaki przy­cho­dzi mi do głowy dla tego cię­cia jest for­mu­larz kon­fi­gu­ra­cji pro­duktu. Rozważmy kon­fi­gu­ra­tor lap­topa, gdzie krok po kroku doko­nu­jemy wybo­rów doty­czą­cych pożą­da­nego przez nas sprzętu. Poza wybo­rem modelu możemy wybrać np. rodzinę sys­temu ope­ra­cyj­nego jaki ma zostać zain­sta­lo­wany. W zależ­no­ści od wyboru w kolej­nym kroku dosta­niemy do wyboru kon­kretną wer­sję oraz ew. opro­gra­mo­wa­nie dodat­kowe. Wybie­ra­jąc dysk twardy naj­pierw wybie­rzemy typ (HDD/SSD), a póź­niej jego roz­miar. Jakie­kol­wiek pro­cesy z roz­ga­łę­zie­niami będą wdzięcz­nym obiek­tem takiego podziału – w pierw­szym kroku możemy dopiąć pełne przej­ście od startu do końca naj­prost­szą drogą. Zau­waż że już wtedy poja­wia się jakaś poten­cjalna war­tość w pro­duk­cie. Oczy­wi­ście funk­cja nie jest kom­pletna i gotowa do final­nego wyda­nia, ale już np. możemy zacząć wewnętrzne testy z użyt­kow­ni­kami żeby spraw­dzić jego uży­tecz­ność i intu­icyj­ność.

Inter­face.

Ide­al­nym przy­kładem tutaj byłaby apli­ka­cja Clu­bho­use. W pierw­szej kolej­no­ści została zbu­do­wana apli­ka­cja na iPhone’y, a urzą­dze­nia z Andro­idem znaj­dują się dopiero w dal­szych pla­nach. Dzięki temu podej­ściu można było mniej wię­cej o połowę (bez koniecz­no­ści cze­ka­nia na ukoń­cze­nie dru­giej apli­ka­cji przez zespół lub wręcz inwe­sto­wa­nia w nią) skró­cić czas wyko­na­nia pierw­szych wali­da­cji pro­duktu, zebra­nia feed­backu od użyt­kow­ni­ków. W przy­padku Clu­bho­use cię­cie to oka­zało się tak sku­teczne, że apli­ka­cja na Andro­ida w ogóle została prze­su­nięta na dal­szy plan, bo gwał­towne tempo wzro­stu pro­duktu spo­wo­do­wało koniecz­ność szyb­szej pracy nad opty­ma­li­za­cją wydaj­no­ści i sta­bil­no­ści apli­ka­cji. Spo­sób ten jest bar­dzo wdzięczny w uży­ciu gdy jedna funk­cjo­nal­ność ma zostać dostar­czona w kilku obsza­rach pro­duktu, albo na róż­nych plat­for­mach.

Data.

Przy­kładem cię­cia według danych może być znany na pewno wszyst­kim for­mu­larz danych dostawy, który prak­tycz­nie w każ­dym skle­pie inter­ne­to­wym zawiera nie­mal iden­tyczne dane. Ponow­nie – drogę do pierw­szego wzro­stu war­to­ści w pro­duk­cie możemy sobie skró­cić np. rezy­gnu­jąc z opcji wysyłki na inny adres niż dane roz­li­cze­niowe. Albo wręcz ogra­ni­cza­jąc for­mu­larz do pod­sta­wo­wych danych adre­so­wych, nie pyta­jąc o dane firmy. Oczy­wi­ście ponownie -nie będzie to skoń­czona funk­cja, ale za to nawet w takiej for­mie możemy zna­leźć użyt­kow­ni­ków któ­rym reszta danych nie będzie potrzebna i sko­rzy­stają z takiego for­mu­la­rza. Takie podej­ście może pomóc nam w ogra­ni­cze­niu koniecz­nych nakła­dów pracy gdy mamy do prze­two­rze­nia dużą ilość infor­ma­cji, z któ­rych nie wszyst­kie są kry­tyczne do wyko­na­nia pod­sta­wo­wej ope­ra­cji.

Rules.

Podział zadań według reguł bizne­so­wych możemy roz­wa­żyć także w kon­tek­ście sklepu inter­ne­to­wego. Na przy­kład pod­sta­wową formą dzia­ła­nia sklepu jest sprze­daż pro­duktu, który jest wpro­wa­dzony do niego. Kolej­nymi zasa­dami roz­sze­rza­ją­cymi sprze­daż pro­duktu może być np. limit ilo­ści przedmio­tów w koszyku, poda­nie infor­ma­cji o nie­do­stęp­no­ści pro­duktu gdy stan maga­zy­nowy jest nie­wy­star­cza­jący, poda­nie infor­ma­cji o prze­kro­cze­niu ilo­ści pro­duktu w koszyku wzglę­dem stanu na maga­zy­nie itd. Cię­cie to jest uży­teczne wszę­dzie tam, gdzie mamy do obsłu­że­nia kilka róż­nych zabez­pie­czeń, któ­rych logika jest bar­dziej skom­pli­ko­wana i wymaga wię­cej pracy, lecz nie jest konieczna do spraw­dze­nia.

Mam nadzieję, że te pięć „cięć” okaże się pomoc­nych w zja­da­niu tytu­ło­wego sło­nia 🙂 Jed­no­cze­śnie jeśli znasz inne spo­soby okieł­zna­nia zbyt dużych zadań, to zapra­szam ser­decz­nie do podzie­le­nia się nimi w komen­ta­rzach: )

Piona!

Link do oryginalnego posta na LinkedIn