Tytułowe User Story i Story Mapping mia­ły (mają) być reme­dium na pro­ble­my z wyma­ga­nia­mi. Czy są nim? Słownik Języka polskiego: 

roz­wią­za­nie: ?pro­jekt i reali­za­cja zało­żeń archi­tek­to­nicz­nych, kon­struk­cyj­nych, pla­stycz­nych itp.?

Innymi sło­wy roz­wią­za­nie to okre­ślo­ne narzę­dzia pra­cy. W tym przy­pad­ku narzę­dziem jest apli­ka­cja (opro­gra­mo­wa­nie).

Nadal popu­lar­ne wśród deve­lo­pe­rów user sto­ry, jako narzę­dzie opi­su wyma­gań poka­za­ło swo­je wady, lekar­stwem na nie ma (mia­ło) być sto­ry mapping. 

Kluczową wadą tego (użyt­kow­nik opi­su­je apli­ka­cję) podej­ścia jest zało­że­nie, że użyt­kow­nik ma racje (wie cze­go chce). Problem w tym, że nawet jeże­li użyt­kow­ni­ka wie co robi, to mało real­ne jest by wie­dział cze­go (jakie roz­wią­za­nie) potrze­bu­je. Zauważają to nawet entu­zja­ści metod zwinnych:

Do cze­go User Story się nada­ją? Mówiąc krót­ko, do krót­ko­ter­mi­no­we­go prze­cho­wy­wa­nia wyma­gań ze zwró­ce­niem szcze­gól­nej uwa­gi na dostar­cza­ną war­tość. Ponadto słu­żą jako wstęp do dal­szej dys­ku­sji mają­cej na celu wypra­co­wa­nie wspól­ne­go zro­zu­mie­nia zagad­nie­nia i dal­sze pra­ce nad mode­lo­wa­niem roz­wią­za­nia. (źr.: User Story – choć przy­dat­ne, nie zawsze opty­mal­ne)

Niewątpliwie są wstę­pem i chy­ba na tyle. Co do wspól­ne­go zro­zu­mie­nia oso­bi­ście mam wąt­pli­wo­ści, by przy­szły użyt­kow­nik miał kom­pe­ten­cje do bycia pro­jek­tan­tem roz­wią­zań. Gdyby je miał, po pro­stu by to roz­wią­za­nie zaprojektował. 

Swego cza­su (2016) pisa­łem o user story:

Wszelkie meto­dy zakła­da­ją­ce, że użyt­kow­nik wie cze­go chce i jest naj­lep­szym źró­dłem ??wyma­gań? bazu­ją na zaufa­niu dla tych opi­sów (źr. : User Story c.d. – Jarosław Żeliński IT-Consulting).

Z tym zaufa­niem jest jed­nak pro­blem, bo użyt­kow­nik bar­dzo czę­sto ma kon­flikt inte­re­su ze spon­so­rem pro­jek­tu: nikt roz­sąd­ny nie budu­je wię­zie­nia na pod­sta­wie pomy­słów i zale­ceń przy­szłych więź­niów. Czy to krzyw­dzą­ca ana­lo­gia? Nie sądzę: sklep inter­ne­to­wy nie chce być oszu­ka­ny przez kupu­ją­cych, sys­tem reje­stra­cji cza­su pra­cy też nie powi­nien dać się oszu­kać, sys­tem zarzą­dza­nia prze­pły­wem pra­cy nie powi­nien być podat­ny na symu­la­cję pra­cy, itp. itd. 

Jako inży­nie­ro­wi, przy­świe­ca mi raczej myśl przy­pi­sy­wa­nia Henry’emu Fordowi (pro­du­cent samo­cho­dów mar­ki Ford):

Gdybym na począt­ku swo­jej karie­ry, jako przed­się­bior­ca, zapy­tał klien­tów, cze­go chcą, wszy­scy byli­by zgod­ni: chce­my szyb­szych koni. Więc ich nie pytałem.”

I uwa­żam, że jest w tym wie­le racji. Idea powyż­sze­go cyta­tu zasa­dza sie na tym, że ludzie chcą szyb­kiej i wygod­niej podró­żo­wać, i to powin­no być ich wyma­ga­niem”. pozwo­lić im powie­dzieć Jako kow­boj, chcę szyb­sze­go i wygod­niej­sze­go konia, bym mógł lepiej wypa­sać sta­do”, to nic inne­go jak pozwo­lić mu (use­ro­wi) pro­jek­to­wać roz­wią­za­nie. I dokład­nie na to nie przy­stał H.Ford. Z per­spek­ty­wy cza­su widać, że miał rację.

User sto­ry po pol­sku” brzmi: ?Jako <kto?> chcę <co?>, po to aby <po co?>?

I tu poja­wia się idea podej­ścia inży­nier­skie­go MBSE (Model Based System Engineering): nie pozwa­la­my użyt­kow­ni­ko­wi powie­dzieć <co> chce. Bo to jest nie jest jego kom­pe­ten­cja (zapew­ne będzie chciał szyb­sze­go konia). Projekty opar­te na user sto­ry są czę­sto komen­to­wa­ne: Dostaliśmy dokład­nie to co chcie­li­śmy, a nie to co jest nam potrzeb­ne”. Inżynierskie user sto­ry” to raczej: Jako <kto?> chce uzy­skać <po co>”, czy­li pozwo­li­my powie­dzieć: Jako kow­boj, chcę lepiej wypa­sać stado”.

Lekarstwem na user sto­ry ma być sto­ry map­ping. Jeden z auto­rów blo­ga na ten temat poda­je przykład:

W wiel­kim skró­cie jest to mapo­wa­nie User Stories (lub opcjo­nal­nie wyma­gań w innej for­mie) na kro­ki pro­ce­su. Musimy zatem okre­ślić pro­ces, jego poszcze­gól­ne kro­ki i przy­pi­sać im okre­ślo­ne Historyjki Użytkownika.

Schemat Story Map (źr.: Story map­ping – nie­co szer­sze spoj­rze­nie – Analiza Biznesowa, dostęp 2020.12.14)

Zamawianie Produktu to pro­ces biz­ne­so­wy, nad tą linią jest opis pro­ce­su, pod nią histo­ryj­ki użyt­kow­ni­ka, usze­re­go­wa­ne wg. kolej­no­ści wdrożenia.

W tym momen­cie przy­to­czę dia­gram z art­ku­łu jaki napi­sa­łem trzy lata temu:

(źr. https://it-consulting.pl//2017/06/04/ile-przypadkow-uzycia/)

Po lewej stro­ny są kon­tek­sty użyt­kow­ni­ka (namiast­ka user sto­ry), po pra­wej roz­wią­za­nie. Czy widać pro­blem? User sto­ry to kon­tekst i per­spek­ty­wa użyt­kow­ni­ka, jego intu­icja („wie” co chce mieć). Oddany spra­wie i klien­to­wi deve­lo­per” jest w sta­nie przy­go­to­wać sześć narzę­dzi pra­cy (opcji w apli­ka­cji) i to na koszt zama­wia­ją­ce­go! Dobry ana­li­tyk pro­jek­tant poświę­ci czas na zro­zu­mie­nie i zapro­jek­tu­je mło­tek (to dla­te­go kod apli­ka­cji wyko­na­nych zwin­nie potra­fi być o rząd wiel­ko­ści bar­dziej zło­żo­ny niż pro­jek­ty apli­ka­cji zbu­do­wa­ne w opar­ciu o ana­li­zę i mode­le, a to zna­czy, że zwin­ne meto­dy tu dadzą pro­dukt 10-ktot­nie droż­szy po dzie­się­cio­krot­nie dłuż­szym czasie!).

Jak ina­czej? Posłużę się przy­kła­dem cyto­wa­ne­go wyżej auto­ra piszą­ce­go o sto­ry map­pin­g’u.

Proces biz­ne­so­wy, zgod­nie z defi­ni­cją, to aktyw­ność wień­czo­na pro­duk­tem. Tym pro­duk­tem jest okre­ślo­ny, mają­cy war­tość biz­ne­so­wą, doku­ment (zestaw danych, for­mu­larz). Tak więc ana­li­tycz­na” wer­sja wyżej pre­zen­to­wa­ne­go dia­gra­mu Schemat sto­ry map, wyglą­da­ła by tak:

Proces biz­ne­so­wy i struk­tu­ra doku­men­tu Koszyk. 

Operujemy doku­men­tem Oferta (lista pro­duk­tów, w tym opi­sy i ceny), Koszyk (kolek­cja wybra­nych pro­duk­tów, osob­ny doku­ment), Zamówienie (kolek­cja pro­duk­tów uzu­peł­nio­na dany­mi nabyw­cy, adre­sem dosta­wy, for­mą płat­no­ści), Zlecenie prze­le­wu (zawie­ra dane dla ban­ku, do wyko­na­nia ręcz­nie lub poprzez inte­gra­cję z usłu­gą płat­no­ści), List prze­wo­zo­wy (dane dla kurie­ra). Diagram zawie­ra przy­kła­do­wą struk­tu­rę jed­ne­go z tych dokumentów. 

Dla wygo­dy czy­ta­nia powtó­rzę tu dia­gram zawie­ra­ją­ce user story:

Obrazek posiada pusty atrybut alt; plik o nazwie StoryMapping2-1.png
  • Wyszukiwanie pro­duk­tu, to pra­ca z doku­men­tem Oferta (wyszu­ki­wa­nie poza MVP?),
  • Zarządzanie koszy­kiem, to kom­ple­to­wa­nie listy wybo­ru z ofer­ty, doda­nie nowej pozy­cji to klik­nię­cie na ofer­cie zaś usu­nię­cie pozy­cji to klik­nię­cie «usuń” w koszy­ku, to ta sama praca,
  • Konfiguracja dosta­wy to po pro­stu wypeł­nie­nie Zamówienia (ten for­mu­larz zawie­ra wszel­kie dane i do opłat­no­ści i dostawy),
  • Płatność to for­mu­larz przelewu,
  • Potwierdzenie zamó­wie­nia? Nie wiem co autor ma tu na myśli (moż­na roz­wi­jać ten pro­ces o komu­ni­ka­cję ema­il z zama­wia­ją­cym, nie ma jed­nak takiej potrze­by), jeże­li ktoś doko­na prze­le­wu to de fac­to auto­ry­zu­je to zamó­wie­nie, owszem moż­na wysłać mailem dane do prze­le­wu i link do aktyw­ne­go for­mu­la­rza Zamówienia (będzie zachowany).

A teraz user story:

  • wyświe­tla­nie pro­duk­tów to pre­zen­ta­cja Oferty,
  • nie wiem czym się róż­ni wyszu­ki­wa­nie od fil­tro­wa­nia, jed­nak warian­to­wa pre­zen­ta­cja Oferty to cały czas pra­ca z Ofertą, sor­to­wa­nie także,
  • zarzą­dza­nie koszy­kiem to try­wial­na pra­ca z for­mu­la­rzem Koszyk, nie rozu­miem sen­su tego podzia­łu (patrz przy­kład z młotkiem),
  • kon­fi­gu­ra­cja dosta­wy to dane na for­mu­la­rzu Zamówienie, czy na praw­dę ma on powsta­wać w kawał­kach? I tak do nicze­go nie posłu­ży jeże­li nie bez­ie kompletny, 
  • płat­no­ści są albo na stro­nie, albo poza stro­ną, czy­li samodzielnie,
  • nie wiem jak i po co moż­na roz­dzie­lić wypeł­nia­nie Zamówienia od pre­zen­ta­cji wypeł­nio­ne­go zamówienia. 

Moje wra­że­nia:

  • każ­dy pro­ces to pra­ca i jej efekt w posta­ci popraw­nie wypeł­nio­ne­go formularza
  • roz­bi­ja­nie opi­su na user sto­ry, któ­re tak na praw­de jest albo kolej­nym kon­tek­stem użyt­kow­ni­ka, albo wręcz wypeł­nia­niem kon­kret­nej czę­ści for­mu­la­rza (np. wpro­wa­dza­nie adres, a może be tego???) nie ma więk­sze­go sensu. 

Co obser­wu­ję na ryn­ku? Nie tak daw­no mia­łem w ręku wyce­nę pew­nej apli­ka­cji opra­co­wa­ną przez pew­ne­go deve­lo­pe­ra: naj­pierw sto­ry map” (ok. 60 user sto­ry!) potem wyce­na na ok. 300 tys. zł. pro­blem w tym, że apli­ka­cja (dosta­li pro­jekt ode mnie) mia­ła 6 (sześć!) for­mu­la­rzy po maks. 20 pól każ­dy, na moje pyta­nie skąd u nich tyle user sto­ry (bo w wyce­nie poda­li koszt za user sto­ry) nie ode­zwa­li się do do dzisiaj.

Tak więc user sto­ry, zasto­so­wa­ne w opi­sa­ny wyżej spo­sób, nie wno­szą żad­nej war­to­ści do pro­jek­tu a kom­pli­ku­ją postrze­ga­nie zakre­su. Analiza i opra­co­wa­nie sfor­ma­li­zo­wa­ne­go mode­lu pro­ce­su będą zawsze prost­sze jako dia­gram. Specyfikacja apli­ka­cji opar­ta na for­mu­la­rzach i ich logi­ce jest znacz­nie wygod­niej­sza, bo zama­wia­ją­cy wie co dosta­nie, a deve­lo­per ma pre­cy­zyj­ną infor­ma­cję i nie ma moż­li­wo­ści zawy­ża­nia ceny. Pomijam, że user sto­ry to nie­ste­ty tyl­ko wyobra­że­nia zama­wia­ją­ce­go, któ­re potrak­to­wa­ne bez­kry­tycz­nie jako wyma­ga­nia, zaowo­cu­ją jedy­nie szyb­szy­mi koń­mi” a nie samo­cho­dem. Dlatego User Story to dobry pomysł na zebra­nie potrzeb języ­kiem zama­wia­ją­ce­go i bar­dzo zły jako bez­po­śred­nia meto­da spe­cy­fi­ko­wa­nia wyma­gań wobec sys­te­mu. (Patrz: https://​it​-con​sul​ting​.pl/​c​z​y​m​-​p​r​a​c​u​j​e​-​c​z​y​l​i​-​v​i​s​u​a​l​-​p​a​r​a​d​i​g​m​/​#​S​p​e​c​y​f​i​k​a​c​j​a​-​p​o​t​r​zeb – User-Story)

Na koniec na popra­wę humo­ru sys­tem ocza­mi zama­wia­ją­ce­go (po lewej) i ocza­mi pro­jek­tan­ta ( po prawej):

Abstraction focuses upon the essential characteristics of some object, relative to the perspective of the viewer. [Abstrakcja skupia się na istotnych cechach jakiegoś obiektu w odniesieniu do perspektywy widza.]
Booch, G. (1994). Object-orien­ted Analysis and Design with Applications. 2nd Edition, the Benjamin/Cummings Publishing Company, Inc.

Jarosław Żeliński

BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.

Ten post ma 4 komentarzy

  1. GOL

    Dzień dobry,

    Na począ­tek zazna­czę, że nie jestem fanem histo­ry­jek” (zwłasz­cza w posta­ci nagmin­nie spo­ty­ka­nej, bo tu musiał bym prze­rwać zga­dza­jąc się ze stwier­dze­niem Tak więc user sto­ry nie wno­szą żad­nej war­to­ści do pro­jek­tu a kom­pli­ku­ją postrze­ga­nie zakre­su”) i nie zamie­rzam ich bronić??.to tak aby nie wywią­za­ła się dys­ku­sja ide­olo­gicz­na o wyż­szo­ści Świąt Wielkanocnych nad Bożym Narodzeniem”. Raczej spi­szę kil­ka spostrzeżeń?..myśli nie uczesanych .

    W arty­ku­le zakła­da się, że to użyt­kow­nik” pisze histo­ryj­ki (cyt. „?nie pozwa­la­my użyt­kow­ni­ko­wi powie­dzieć chce. Bo to jest nie jest jego kom­pe­ten­cja” – przy okazji?.za dużo o jed­no jest”)?i wte­dy fak­tycz­nie jest pro­blem. Ten sam błąd da się jed­nak popeł­nić i bez histo­ry­jek” pozwa­la­jąc użyt­kow­ni­ko­wi mówić cze­go chce. Zdaje się jed­nak, że (teo­re­tycz­nie) za histo­ryj­ki” nie odpo­wia­da użyt­kow­nik a Product Owner”, czy­li przed­sta­wi­ciel zama­wia­ją­ce­go a to nie to samo (dyrek­tor wię­zie­nia a nie więzień)??

    Przykład z koniem: Jako kow­boj, chcę szyb­sze­go i wygod­niej­sze­go konia, bym mógł lepiej wypa­sać sta­do”. Tak by powie­dział Użytkownik” kow­boj, ale Świadomy Product Owner” wła­ści­ciel sta­da mógł­by powie­dzieć Jako wła­ści­ciel sta­da, chcę aby moi kow­bo­je mie­li szyb­szy i wygod­niej­szy śro­dek trans­por­tu, by mogli lepiej wypa­sać moje sta­do”. Samo ?Jako kow­boj, chcę lepiej wypa­sać sta­do? czy też Jako wła­ści­ciel sta­da, chcę aby moi kow­bo­je lepiej wypa­sa­li moje sta­do” może być zbyt ogól­ni­ko­we i pro­wa­dzić do stwier­dzeń Jako , chcę żeby BYŁO LEPIEJ” (coś w sty­lu Jako Miss World chcia­ła bym , żeby był pokój na świe­cie” 🙂 ) i w ten spo­sób moż­na udo­wod­nić, że histo­ryj­ki” nic nie wnoszą?..tak, źle napi­sa­ne histo­ryj­ki z pew­no­ścią nic nie wnoszą?.tak samo jak źle wyar­ty­ku­ło­wa­ne wyma­ga­nia biz­ne­so­we, czy źle zamo­de­lo­wa­ny pro­ces biz­ne­so­wy i kro­ki w tym pro­ce­sie (kro­ków w pro­ce­sie też moż­na namno­żyć ponad miarę.….albo nawet samych procesów).

    Źle napi­sa­na histo­ryj­ka” nie­wie­le się róż­ni od źle spi­sa­ne­go wyma­ga­nia biz­ne­so­we­go czy źle zamo­de­lo­wa­ne­go pro­ce­su biz­ne­so­we­go ?po pro­stu jest źle.
    Kluczowe może być nie to czy pisze się histo­ryj­ki” czy wyma­ga­nia biz­ne­so­we, mode­lu­je pro­ces itd.. tyl­ko kto to robi, po co to robi i jak to robi (np. skąd czer­pie informacje).

    To, że histo­ryj­ka­mi łatwo posłu­żyć się do nadmu­cha­nia kosz­tów to fakt?..ale spraw­ni nadmu­chi­wa­cze” radzi­li sobie dosko­na­le i przed edżaj­lem”, skra­mem” i histo­ryj­ka­mi”.

    Problemem mogą nie być histo­ryj­ki” same w sobie tyl­ko ich zde­gra­do­wa­nie do nic nie wno­szą­cych sfor­mu­ło­wań w sty­lu Ja jako fir­ma, chcę ergo­no­micz­ny sys­tem, żeby pra­co­wa­ło się lepiej” albo prze­gię­cie w dru­ga stro­nę i roz­mno­że­nie ich celem nadmu­cha­nia kosz­tów oraz trak­to­wa­nie histo­ry­jek” jako mate­riał dla dewe­lo­pe­ra bez wyko­na­nia wła­ści­wej analizy?..i tu wła­ści­wy wyda­je się cytat. z przy­to­czo­ne­go arty­ku­łu („User Story ? choć przy­dat­ne, nie zawsze opty­mal­ne”) : Do cze­go User Story się nada­ją? Mówiąc krót­ko, do krót­ko­ter­mi­no­we­go prze­cho­wy­wa­nia wyma­gań ze zwró­ce­niem szcze­gól­nej uwa­gi na dostar­cza­ną war­tość. Ponadto słu­żą jako wstęp do dal­szej dys­ku­sji mają­cej na celu wypra­co­wa­nie wspól­ne­go zro­zu­mie­nia zagad­nie­nia i dal­sze pra­ce nad mode­lo­wa­niem rozwiązania.”

    Narzędzia nada­ją się do tego do cze­go się nada­ją a źle uży­te mogą spo­ro namieszać?.tak jak mło­tek nada­je się do moco­wa­nia nóg sto­łu” pod warun­kiem, że to nie stół typu by IKEA”, gdzie nogi się przykręca ;).

    Pozdrawiam,

    1. Jarosław Żeliński

      1. na mój stan wie­dzy i doświad­cze­nie z audy­tów, histo­ryj­ki użyt­kow­ni­ka” to w prak­ty­ce jest jed­nak pro­dukt użyt­kow­ni­ka, zresz­tą tak to wyglą­da w cyto­wa­nym diagramie,
      2. pro­duct owner (PO) nie jest oso­bą mówią­cą biz­ne­so­wi jak ma żyć”, PO two­rzy zakres pro­jek­tu, jeże­li jed­nak jest człon­kiem zespo­łu deve­lo­pe­ra, to ma potęż­nych kon­flikt inte­re­su (tak: powi­nien repre­zen­to­wać zamawiającego),
      3. owszem PO to nie użytkownik,
      4. myślę, że PO powi­nien być jed­nak ana­li­ty­kiem pro­jek­tan­tem, trze­cią stro­ną (tak to wyglą­da to w meto­dach MDE/MBSE)
      5. nawet jeże­li tu i teraz usta­li­my coś, to prak­ty­ka poka­zu­je, że user sto­ry nie działa” ;).

      Od lat obser­wu­ję efek­ty prac deve­lo­pe­rów, w 100% tam, gdzie pomi­nię­to ana­li­zy pro­ce­sów, lub wyko­na­no je nie­po­praw­nie, był dra­mat. Dobrze wyko­na­na ana­li­za pro­ce­sów to w 100% peł­ny opis orga­ni­za­cji i w 100% kom­plet­ny kon­tekst każ­dej pra­cy, wystar­czy już tyl­ko poka­zać (zakres pro­jek­tu), któ­re aktyw­no­ści w pro­ce­sach mają być wspie­ra­ne usłu­ga­mi apli­ka­cji. Dlatego uwa­żam, że albo ktoś wie (odkry­je), że zwrot książ­ki to tyl­ko doda­nie daty zwro­tu do Karty Wypożyczenia, albo ten pro­jekt będzie dra­ma­tem kosz­to­wym. Zwracam uwa­gę, że popraw­nie wyko­na­ny model pro­ce­so­wy orga­ni­za­cji to kil­ka do kil­ku­na­stu dia­gra­mów na kart­kach A4, a nie set­ki stron nie­przy­dat­nych deta­licz­nych PSEUDO-algorytmów” 😉

  2. Robert Pieksza

    Artykuł war­to­ścio­wy, jed­nak nie moż­na go odno­sić do wszyst­kich user sto­ries, a jedy­nie do tych złych. Uważam, że wła­śnie pra­cą ana­li­ty­ka jest dotar­cie do isto­ty potrzeby/problemu (np. 5 WHY) i wła­ści­we spi­sa­nie user stories. 

    I zgod­nie z przy­to­czo­nym zda­niem, US z zało­że­nia są wła­śnie pod­sta­wą do wypra­co­wa­nia roz­wią­za­nia z zespo­łem dewe­lo­per­skim, bo ani klient ani ana­li­tyk biz­ne­so­wy, nie mają zazwy­czaj dość wie­dzy technicznej.

    Przy oka­zji odnio­sę się do wybra­nych stwierdzeń 🙂

    1. doda­nie nowej pozy­cji to klik­nię­cie na ofer­cie zaś usu­nię­cie pozy­cji to klik­nię­cie «usuń” w koszy­ku, to ta sama pra­ca” – w dużym uprosz­cze­niu oczy­wi­ście tak, ale w prak­ty­ce jest to pra­ca fron­ten­dow­ca nad dwo­ma róż­ny­mi pod­stro­na­mi (wido­ka­mi), a bac­ken­dow­ca – na dwóch róż­nych modu­łach aplikacji.

    2. nie wiem czym się róż­ni wyszu­ki­wa­nie od fil­tro­wa­nia” – sto­ją za tym dwa zupeł­nie róż­ne mecha­ni­zmy pre­zen­ta­cji danych. Filtrowanie to naj­czę­ściej dal­sze zawę­ża­nie jakiejś ogra­ni­czo­nej listy (np. kate­go­rii) pro­duk­tu. Wyszukiwarka słu­ży wła­śnie do tego wstęp­ne­go zawę­że­nia (przed fil­tro­wa­niem) i może mieć dodat­ko­we regu­ły – np. po wpi­sa­niu sło­wa buty” wyświe­tlać pro­duk­ty, któ­re w nazwie mają też szpil­ki” lub moka­sy­ny”.

    3. nie wiem jak i po co moż­na roz­dzie­lić wypeł­nia­nie Zamówienia od pre­zen­ta­cji wypeł­nio­ne­go zamó­wie­nia” – tu zno­wu mamy 2 oddziel­ne wido­ki – wpro­wa­dza­nia jakichś danych i pod­su­mo­wa­nia. Czyli 2 pro­jek­ty UI i moż­li­wość roz­bi­cia tego na 2 mniej­sze zada­nia dla frontendowców.

    Wydaje mi się, że mimo opi­sa­nia tego mode­lem i tak po przy­stą­pie­niu do reali­za­cji deve­lo­pe­rzy mogą roz­bić przy­go­to­wa­nie zamó­wie­nia” na kil­ka mniej­szych zadań, żeby opty­ma­li­zo­wać pra­cę zespo­łu np. robić je równolegle.

    Może jakimś roz­wią­za­niem jest podej­ście hybry­do­we – dobre user sto­ries poprze­dzo­ne ana­li­zą pro­ce­su. Spotkałem się z tym w prak­ty­ce i cał­kiem dobrze to działało.

    1. I zgod­nie z przy­to­czo­nym zda­niem, US z zało­że­nia są wła­śnie pod­sta­wą do wypra­co­wa­nia roz­wią­za­nia z zespo­łem dewe­lo­per­skim, bo ani klient ani ana­li­tyk biz­ne­so­wy, nie mają zazwy­czaj dość wie­dzy technicznej.”

      Analityk Biznesowy to oso­ba któ­ra ma prze­ka­zać wyma­ga­nia. Pozostaje okre­śle­nie ich for­my: potra­fi lub nie potra­fi prze­ka­zać wyma­ga­nia w posta­ci pro­jek­tu (MDD/MBSE/MDA-PIM), bo pisarz pro­zą już coraz rza­dziej się akceptuje. 

      W kwe­stii uwag:
      1. nie rozu­miem koniecz­no­ści uży­cia dwóch pod­stron i dwóch apli­ka­cji by dodać lub usu­nąć pozy­cję z koszy­ka zakupów.
      2. zapew­ne zno­wu mamy nie­po­ro­zu­mie­nie, fil­tro­wa­nie i wyszu­ki­wa­nie to wybór pod­zbio­ru danych, czyż nie?
      3. nie widzę powo­du robie­nia dwóch wido­ków do Zamówienia na eta­pie wpro­wa­dza­nia i potwietdzenia.

      Obserwacja pra­cy deve­lo­pe­rów pozwa­la mi dostrzec, że wie­lu z nich https://​it​-con​sul​ting​.pl/​w​p​-​a​d​m​i​n​/​p​o​s​t​.​p​h​p​?​p​o​s​t​=​2​5​7​2​3​&​a​c​t​i​o​n​=​e​d​i​t​s​t​o​s​uje kurio­zal­ne obiek­to­we” archi­tek­tu­ry rodem z C/C++: głów­nie nad­miar dzie­dzi­cze­nia, skom­pli­ko­wa­ne maszy­ny sta­no­we i reli­gij­ne przy­wią­za­nie z zapi­su danych w bazach SQL/„3 postać nor­mal­na”, co mega kom­pli­ku­je całość. 

      User sto­ry to tyl­ko kon­tekt akto­ra, mój ulu­bio­ny przy­kład: jako stu­dent chcę zna­leźć auto­ra książ­ki” czy­li nawet w pro­stym e‑sklepie z książ­ka­mi nie wyma­ga to abso­lut­nie żad­nej pra­cy, ale jed­nak wie­lu dopi­su­je takie US do kosz­tów. Młotek to pro­ste narzę­dzie mają­ce jed­ną usłu­gą: ude­rza, ale zapew­niam, że jestem w sta­nie napi­sać set­ki User Story do nie­go… co ABSOLUTNIE nie ma pra­wa pod­nieść kosz­tu jego wytworzenia.

      I zgo­da co do tego: user sto­ry to mate­riał dla analityka/projektanta, nigdy dla developera.

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.