Prawie trzy lata temu pisa­łem o wadach metod zbie­ra­nia i doku­men­to­wa­nia wyma­gań w posta­ci wywia­dów i pisa­nia tak zwa­nych user sto­ry”. Byli i zapew­ne nadal są obroń­cy tej metody:

User sto­ry to świet­ne narzę­dzie do komu­ni­ka­cji pomię­dzy użyt­kow­ni­kiem a ana­li­ty­kiem (archi­tek­tem) (uwa­gi do tre­ści arty­ku­łu: User sto­ry – kło­po­ty).

Niedawno po raz kolej­ny widzia­łem nega­tyw­ne skut­ki tego podej­ścia, tym razem był to wdra­ża­ny i zakoń­czo­ny poraż­ką (pro­jekt prze­rwa­no) obieg doku­men­tów, nie tyl­ko kosz­to­wych, więc posta­no­wi­łem do tam­te­go arty­ku­łu dodać coś jesz­cze: wyma­ga­nia zbie­ra­no tu z w posta­ci user story”.

User sto­ry to per­spek­ty­wa użyt­kow­ni­ka i to ska­żo­na jego ogra­ni­czo­ną wie­dzą lub jej bra­kiem oraz ogra­ni­czo­nym doświad­cze­niem lub jego bra­kiem. Duże, zdo­by­te w jed­nym miej­scu, doświad­cze­nie pra­cow­ni­ka, bez głęb­szej i szer­szej ana­li­zy, też nie popra­wia sytu­acji, czę­ściej ją jesz­cze pogar­sza (bo nikt nie podej­mu­je dys­ku­sji z tym dużym doświad­cze­niem”). Popatrzmy na poniż­szy rysunek:

analiza uklad geocentryczny

Jak zapew­ne już Państwo wie­dzą, jest to model” geo­cen­trycz­ny ukła­du sło­necz­ne­go (na rysun­ku jedy­nie orbi­ta jed­nej pla­ne­ty z tak zwa­ny­mi epi­cy­kla­mi), stwo­rzo­ny na bazie obser­wa­cji z Ziemi. Złożoność tego co widzi­my jako miesz­kań­cy tej pla­ne­ty to efekt tego, że obser­wa­tor stoi na zie­mi czy­li krą­żą­ce­go wokół Słońca obiek­tu. Innymi sło­wy, obser­wa­tor jest we wnę­trzu tego co opi­su­je (ana­li­zu­je) i widzi jedy­nie frag­ment tego co sta­ra się opi­sać i zrozumieć.

Poniżej praw­dzi­wy obraz ukła­du słonecznego:

Jak widać, praw­da jest znacz­nie prost­sza, jed­nak by ją odkryć nale­ży zupeł­nie ina­czej podejść do ana­li­zy i opi­su ota­cza­ją­cej nas rze­czy­wi­sto­ści. Należy zre­zy­gno­wać z uży­cia zapi­su subiek­tyw­nych obser­wa­cji jako final­ne­go opi­su zja­wi­ska, zapis taki może być testem teo­rii ale nie nią samą. Kopernikański model to efekt głę­bo­kiej i for­mal­nej (pra­wa fizy­ki) ana­li­zy i badań. Model geo­cen­trycz­ny, zna­ny w śre­dnio­wie­czu, to nic inne­go jak user story”.

Podaję ten przy­kład, mam nadzie­ję, że obra­zo­wy, gdyż moja prak­ty­ka poka­zu­je, że pró­by two­rze­nia opro­gra­mo­wa­nia bazu­ją­ce na rela­cjach (życze­niach, wywia­dach, burze mózgów, itp.) prze­cięt­ne­go obec­ne­go lub przy­szłe­go użyt­kow­ni­ka, to bazu­ją­ce na dobrych chę­ciach i nie­ste­ty na zupeł­nym bra­ku zro­zu­mie­nia kon­tek­stu, pro­jek­ty o zło­żo­no­ści sztucz­nie zwięk­szo­nej nie raz naście razy, niż fak­tycz­na. Użytkownik z drob­nych, sta­ty­stycz­nych odstępstw (tyl­ko takie zwra­ca­ją jego uwa­gę) robi zasa­dy, nie potra­fi wychwy­cić nad­rzęd­nych uogól­nień i praw­dzi­wych reguł.

User-Stories

Oprogramowanie powsta­ją­ce z uży­ciem zwin­nych metod, tych bazu­ją­cych na bie­żą­cej obser­wa­cji i czę­stych popraw­kach, trak­to­wa­niu odosob­nio­nych przy­pad­ków jako wyma­ga­nych sce­na­riu­szy, pro­wa­dzi do bar­dzo zło­żo­nych two­rów, któ­rych zło­żo­ność nie raz prze­ra­sta pro­jekt. Brak logi­ki takie­go opi­su powo­du­je, że powsta­łe sys­te­my wyma­ga­ją ręcz­nej pra­cy przy każ­dej zmia­nie zasad panu­ją­cych w firmie.

Tu nie­ste­ty muszę napi­sać jed­ną waż­ną rzecz: winę za to pono­szą czę­sto spon­so­rzy pro­jek­tów gdyż po pierw­sze dopusz­cza­ją do tego, po dru­gie, nie raz jako człon­ko­wie zarzą­dów i dyrek­to­rzy, nie dopusz­cza­ją do sie­bie myśli o upo­rząd­ko­wa­niu orga­ni­za­cji jako pierw­szym kro­ku projektu.

Typowym, czę­sto spo­ty­ka­nym przy­kła­dem, są popu­lar­ne ostat­nio wdro­że­nia elek­tro­nicz­ne­go obie­gu doku­men­tów, w tym fak­tur kosz­to­wych. W więk­szo­ści chy­ba firm, z powo­dów histo­rycz­nych, nie­mal­że każ­dy kie­row­nik i dyrek­tor ma nie­co inny próg kwo­to­wy samo­dziel­nej akcep­ta­cji ponie­sio­ne­go koszu. Zapisanie w posta­ci wyma­gań a potem imple­men­ta­cja, takie­go sta­nu rze­czy, bywa kosz­ma­rem. Koszmar ten jest bar­dzo kosz­tow­ny z uwa­gi na swo­ją zło­żo­ność i brak ogól­nych zasad. Powoduje to, że zamiast uzy­ska­nia auto­ma­ty­za­cji i znacz­ne­go wzro­stu efek­tyw­no­ści uzy­sku­je się bar­dzo zło­żo­ny i pra­co­chłon­ny (kosz­tow­ny) sys­tem zamra­ża­ją­cy zasta­ny stan rze­czy. Jedyną korzy­ścią cza­sa­mi bywa to, że z rapor­tów wie­my: to na praw­dę dłu­go trwa. A to tyl­ko jeden aspekt opi­su orga­ni­za­cji i wyma­gań na oprogramowanie.

Nie twier­dzę, że każ­dy pro­jekt zwią­za­ny z ana­li­zą wyma­gań, nale­ży pro­wa­dzić kosz­tow­ny­mi, for­mal­ny­mi meto­da­mi, jed­nak zanim z tych metod zre­zy­gnu­je­my oceń­my jakie ryzy­ko podej­mu­je­my, bo czę­sto jest ono bar­dzo duże. Dlatego przed decy­zją o tym czy i jakie opro­gra­mo­wa­nie wdro­żyć, war­to zba­dać fir­mę i upew­nić się czy nie wyma­ga upo­rząd­ko­wa­nia, kom­pu­te­ry­zo­wa­nie bała­ga­nu jest zawsze bar­dzo kosz­tow­ne i ryzykowne.

Warto tu zwró­cić uwa­gę na cie­ka­wy trend. Otóż opi­sa­ne wady user sto­ry (rozu­mia­ne­go jako mniej lub bar­dziej swo­bod­ny opis użyt­kow­ni­ka) dostrze­ga­ją nawet zwo­len­ni­cy zwin­nych metod i zaczy­na­ją je powo­li for­ma­li­zo­wać, np. tak:

Jako [oso­ba odgry­wa­ją­ca daną rolę] chcę [wyko­nać jakąś czyn­ność] aby [osią­gnąć jakiś cel].

W ten sam spo­sób moż­na pisać sce­na­riu­sze przy­pad­ków uży­cia, przy któ­rych nale­ży uwzględ­nić, że sce­na­riusz może obej­mo­wać kil­ka user sto­ry. (Pisanie user sto­ry i sce­na­riu­szy przy­pad­ków uży­cia | Michał Wolski).

Wzorzec ten, co cie­ka­we, jest bli­ski defi­ni­cji pro­ce­su biz­ne­so­we­go: czyn­ność lub łań­cuch czyn­no­ści w celu osią­gnię­cia usta­lo­ne­go rezul­ta­tu. Jest to jed­nak sta­now­czo za mało wie­dzy. Powyższe podej­ście komen­tu­je inny autor:

Przykładowe poje­dyn­cze user sto­ry może brzmieć:

?Jako użyt­kow­nik pre­mium kupu­jąc towa­ry powy­żej 1000zł ccę dostać rabat 10% do koń­ca mie­sią­ca tak aby zachę­cić mnie do kolej­nych zakupów.?

Taki zapis user sto­ry ma wie­le zalet. Pozwala określić:

1.kto będzie uży­wał danej funkcjonalności,

2.czego ten użyt­kow­nik będzie wyma­gał od systemu,

3.kontekst dla wymagania.

Powyższy zapis ma też jed­ną wadę. Jest dość dłu­gi, a lista wyma­gań przed­sta­wio­nych w tej for­mie jest nie­przej­rzy­sta. (Jak ugryźć user sto­ry | agi​le​.pl).

Właśnie pro­blem w tym, że jest nie­przej­rzy­sta oraz nie wie­my jaka logi­ka wią­że war­tość towa­ru z wiel­ko­ścią raba­tu, któ­ry może być jeden, może być ele­men­tem tabe­li raba­to­wej, może być wyli­cza­ny wg. okre­ślo­ne­go wzo­ru, może… Takie zapi­sy, zakła­da­jąc, że dłuż­sze user sto­ry to lep­szy opis, zbli­ża­ją nas do pró­by zapi­sa­nia wyma­gań na grę w sza­chy poprzez nakrę­ce­nie kame­rą kil­ku par­tii. Mając dzie­siąt­ki takich user sto­ry nie mamy żad­ne­go narzę­dzia pozwa­la­ją­ce­go spraw­dzić ich spój­ność, nie­sprzecz­ność i kom­plet­ność. Idąc zaś kro­kiem for­ma­li­za­cji user sto­ry i porząd­ko­wa­nia przy­pad­ków uży­cia, powyż­szy wzo­rzec ja jako użyt­kow­nik zro­bię to a to by osią­gnąć to a to” szyb­ko nas dopro­wa­dzi do defi­ni­cji pro­ce­su biz­ne­so­we­go, któ­ry jest niczym innym jak wła­śnie pra­cą mają­cą okre­ślo­ny cel. Po co więc odkry­wać Amerykę i wal­czyć z nie­jed­no­znacz­no­ścią sko­ro pro­blem ten daw­no roz­wią­za­no: zamiast pisać user sto­ry wystar­czy w toku ana­li­zy opra­co­wać mode­le pro­ce­sów biz­ne­so­wych i w ramach zakre­su pro­jek­tu trans­po­no­wać je na przy­pad­ki uży­cia.

Tak więc opi­so­we user sto­ry może być wyma­ga­niem biz­ne­so­wym, testem ale raczej nie spe­cy­fi­ka­cją tego co ma powstać. Bez ana­li­zy pozwa­la­ją­cej wyspe­cy­fi­ko­wać wyma­ga­nia dzie­dzi­no­we (logi­kę wewnętrz­ną) nie mamy szans na spraw­ne stwo­rze­nie opro­gra­mo­wa­nia wykra­cza­ją­ce­go poza pro­sty zestaw kar­to­tek i rejestrów. 

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 11 komentarzy

  1. Sławomir Niemiec

    … jako komen­tarz tyl­ko jed­no zda­nie, a dokład­nie sta­re przy­sło­wie chiń­skie: jeśli nie wesp­niesz się na górę, nie ujrzysz dali”.

  2. Sławomir Sobótka

    User Story dobrze napi­sa­ny z uży­ciem reto­ry­ki nasta­wio­nej na kro­ki biz­ne­so­we a nie na klik­nię­cia w but­to­ny jest dobrą tech­ni­ką dla sys­te­mów, w któ­rych logi­ka jest płyt­ka” – w sen­sie: to co widzi­my na ekra­nie jest zapi­sy­wa­ne do bazy. Czyli tak zwa­ne prze­glą­dar­ki bazy danych, apli­ka­cje kla­sy CRUD.

    Natomiast gdy logi­ka jest głęb­sza” (UI jest pro­ste, bo user ma nie mieć świa­do­mo­ści o tym co sys­tem robi pod maską”) wów­czas User Story jest po pro­stu sła­be i wręcz mylą­ce. O tak sys­te­mach zapew­ne piszesz w domyśle.

    W DDD mamy na to spo­sób: nie User Stroy a Domain Story. Źródłem wie­dzy nie jest User a Ekspert Domenowy.

    Pojawia się jesz­cze kwe­stia mięk­ka: lep­szą są bar­dziej abs­trak­cyj­ne UC czy popar­te przy­kła­do­wy­mi sce­na­riu­sza­mi US? Z moje­go doświad­cze­nia: to zale­ży – od tego z kim roz­ma­wiasz (w sen­sie jakie pre­fe­ren­cje kogni­tyw­ne ma Twój eks­pert domenowy).

    1. Jarek Żeliński

      Dokładnie to obser­wu­ję w pro­jek­tach. Bardzo wie­le firm i pro­gra­mi­stów, mają­cych duże doświad­cze­nie w two­rze­niu nawet zło­żo­nych por­ta­li prze­no­si te prak­ty­ki na two­rze­nie sys­te­mów biz­ne­so­wych o zło­żo­nej wewnętrz­nej logi­ce a to się kom­plet­nie nie sprawdza.

      Klasyczny przy­kład głę­bo­kiej” logi­ki i płyt­kie­go UI to np. logi­ka nali­cza­nia raba­tów (ekran zamó­wie­nia bar­dzo pro­sty, logi­ka nali­cze­nia ceny sprze­da­ży zło­żo­na) czy sys­tem wspo­ma­ga­ją­cy zawie­ra­nie umów ubez­pie­cze­nio­wych (pła­ski for­mu­larz ubez­pie­czo­ne­go i bar­dzo wyra­fi­no­wa­na logi­ka oce­ny ryzy­ka i nali­cza­nia rezerw na wypła­tę odszko­do­wa­nia). W zasa­dzie wszyst­kie poważ­niej­sze sys­te­my biz­ne­so­we to znacz­nie wię­cej niż zwy­kłe prze­glą­dar­ki danych czy­li CRUD’y (po pro­tu rejestry).

      Gdyby porów­nać UI do wierz­choł­ka góry lodo­wej, to DDD plus dia­gra­my sekwen­cji to wszyst­ko to co pod wodą i cze­go nie zawie­ra nie­ste­ty zna­ko­mi­ta więk­szość zna­nych mi doku­men­tów wyma­gań. Często piszę o wyma­ga­niach dzie­dzi­no­wych”, to wła­śnie ta pod­wod­na część góry. Wspominałem o tym przy oka­zji arty­ku­łu o tym, że pro­to­typ nie nie­sie żad­nej infor­ma­cji o logice.

      Poruszyłeś w ostat­nim aka­pi­cie bar­dzo waż­ną rzecz: umie­jęt­no­ści kogni­tyw­ne eks­per­ta dzie­dzi­no­we­go, a te nie­ste­ty naj­czę­ściej są sła­be (ale z regu­ły nie jest to ocze­ki­wa­na kom­pe­ten­cja w biz­ne­sie). Dlatego od pew­ne­go cza­su (od nie­daw­na) prak­ty­ku­ję (testu­ję ;)) etap pośred­ni pomię­dzy mode­la­mi pro­ce­sów i/lub przy­pad­ka­mi uży­cia a mode­lem dome­no­wym DDD. Jest to moje­go pomy­słu model bra­ma-umie­jęt­ność-wie­dza” albo jak kto woli gate-skill-know­led­ge 😉 (takie bar­dziej obiek­to­we BCE: boun­da­ry-con­troll-enti­ty), przy­kład takie­go dia­gra­mu tu: Struktura…).

      Biznes nie­oswo­jo­ny z wzor­ca­mi tech­nicz­ny­mi (a DDD raczej jest już wzor­cem archi­tek­to­nicz­nym) znacz­nie łatwiej ope­ru­je poję­cia­mi z jego obsza­ru doświad­cze­nia czy­li poję­cia­mi dostęp do dzia­łu, umie­jęt­no­ści ludzi i zapi­sa­na wie­dza”. Na te trzy poję­cia roz­ło­żę każ­dą dzia­łal­ność biz­ne­so­wą. Dopiero kolej­ny krok to przej­ście z tego mode­lu na przy­pad­ki uży­cia (umie­jęt­no­ści przy­po­rząd­ko­wa­ne akto­ro­wi nie są imple­men­to­wa­ne w opro­gra­mo­wa­niu) a potem dopie­ro archi­tek­tu­rę DDD. Korzyść jest taka, że pra­wie każ­dy eks­pert dome­no­wy bez pro­ble­mu spraw­dzi popraw­ność mode­lu trzy­po­ję­cio­we­go­opi­su­ją­ce­go jego obszar biz­ne­so­wy. Moje doświad­cze­nie poka­zu­je, że jeże­li jesz­cze dobrzy pro­gra­mi­ści bez pro­ble­mu odbie­ra­ją struk­tu­ry DDD, tak biz­nes już niekoniecznie.

  3. Sławomir Niemiec

    Jak słusz­nie zauwa­ży­łeś, efek­tem pra­cy ana­li­ty­ka przede wszyst­kim i po pierw­sze ma być zro­zu­mie­nie zagadnień/problemów. Na tym eta­pie nie istot­ne jest to, co ma robić przy­szłe narzę­dzie, ale przy­czy­ny dla któ­rych pod­ję­to decy­zję o jego zamówieniu/wdrożeniu. Przesłanki te są z kolei osa­dzo­ne w biz­ne­sie, czy­li w pro­ce­sach. Rzeczywiście (i potwier­dza to moje doświad­cze­nie, a szcze­gól­nie nie­uda­ne pro­jek­ty), kie­dy już zro­zu­mie­my, wów­czas może­my przy­stą­pić do dopre­cy­zo­wy­wa­nia sto­sow­nych wama­gań (rózne doku­men­ty – w zależ­no­ści od sto­sow­nej meto­dy­ki). Co wię­cej, dopie­ro po fazie zro­zu­mie­nia” może­my być part­ne­ra­mi do dal­szych roz­mów i drą­że­nia tematów”.

    1. Jarek Żeliński

      Mam takie same doświad­cze­nia i wnio­ski, a ludzie sta­le się upie­ra­ją przy tych set­kach wyma­gań na samym początku…:(

  4. Kamil Jackiewicz

    Jedna pod­sta­wo­wa zale­ta w przy­pad­ku podej­ścia zwin­ne­go jest taka, że wła­ści­wie zasto­so­wa­ne sprzy­ja ono inte­rak­cji i roz­mo­wie pomię­dzy Klientem, ana­li­ty­kiem, pro­gra­mi­stą, teste­rem i wszyst­ki­mi zain­te­re­so­wa­ny­mi oso­ba­mi, co z natu­ry rze­czy było nie­co pomi­ja­ne w podej­ściu tra­dy­cyj­nym. Co wię­cej, zwin­ność nie tyl­ko sprzy­ja komu­ni­ka­cji, ale jej wyma­ga. I to jest naj­waż­niej­sze w zwin­nym podej­ściu do wyma­gań, jak i do całe­go pro­jek­tu. To, czy tech­nicz­nie wyma­ga­nia będą zebra­ne w posta­ci dokład­ne­go doku­men­tu, czy mode­lu, czy user sto­ries, jest kwe­stią nie­co wtór­ną, jeśli zabrak­nie komu­ni­ka­cji. Agile, to nie koniecz­ne uży­cie US, czy innych tech­nik, ale zwrot w kie­run­ku komu­ni­ka­cji i jak naj­lep­szym WSPÓLNYM zro­zu­mie­niu potrze­by, celu, ale też środ­ków do jej/jego zaspokojenia/zrealizowania.

    1. Jaroslaw Zelinski

      Samo ist­nie­nie nawet naj­lep­szej komu­ni­ka­cji nie da nam wie­dzy o tym jak roz­wią­zać pro­blem klien­ta. Po dru­gie rela­cje pomię­dzy np. leka­rzem ma pacjen­tem nie pole­ga­ją tyl­ko na dobrej komu­ni­ka­cji a na tym, że lekarz potra­fi posta­wić dia­gno­zę przed poda­niem leków a nie dopie­ro po (meto­da pro­to­ty­po­wa­nia to nie raz zgon klien­ta) … To, że klient potra­fi swo­im języ­kiem opi­sać swo­je potrze­by nie zna­czy, ze nale­ży to brać za dobra mone­tę (sły­szy­my jed­nak że klient nie wie cze­go chce, klient zmie­nia wyma­ga­nia co chwi­lę.…). Nie tyl­ko jest to moje zna­nie: pra­ca pole­ga­ją­ca na wsłu­chi­wa­niu się w życze­nia klien­ta i reali­zo­wa­nie to prze­rzu­ca­nie 100% odpo­wie­dzial­no­ści za efek­ty pra­cy pro­gra­mi­stów na klien­ta (jaka rolę peł­ni tu deve­lo­per poza bier­nym słu­cha­niem???), żaden nor­mal­ny lekarz by tak nie postąpił…

  5. Łukasz Pasek

    Problemy poja­wia­ją się gdy User Storie’s trak­tu­je się jako wyma­ga­nia. Pracowałem w takim pro­jek­cie daw­no temu i aby kom­pen­so­wać nie­do­stat­ki User Stories musia­łem dopi­sy­wać do nich całą masę testów akcep­ta­cyj­nych. Czyli uzu­peł­niać User Storie’s o infor­ma­cje potrzeb­ne na temat dzia­ła­nia danej funk­cjo­nal­no­ści. Brakowało w tym pro­jek­cie wyma­gań cze­go skut­ka­mi byly poważ­ne błę­dy wykry­wa­ne dopie­ro przez klienta.
    Jest jed­nak jed­na sytu­acja kie­dy User Stories się przy­da­ją i jest to wów­czas bar­dzo dobre i natu­ral­ne podej­ście. Chodzi o sytu­ację kie­dy nie zna się zagad­nia­nia, nad któ­rym dopie­ro zaczy­na się pra­co­wać i na roz­grzew­kę przed mode­lo­wa­niem funk­cjo­nal­no­ści innym spo­so­bem (np. use case­’a­mi) trze­ba pogłę­bić temat i dowie­dzieć się wię­cej o celach użyt­kow­ni­ków i danej dome­nie. Wówczas User Stories słó­żą nam do zdo­by­wa­nia wie­dzy. Natomiast nie moż­na na tym poprze­stać i trak­to­wać ich jako spe­cy­fi­ka­cję wymagań.

    1. Jaroslaw Zelinski

      To praw­da, jed­nak pro­blem w tym, ze user sto­ry to nie­ste­ty per­spek­ty­wa użyt­kow­ni­ka” z wada­mi w rodza­ju tak to postrze­ga” i taki biz­nes chce ukrę­cić w tym wdro­że­niu”. Wtedy powsta­je opro­gra­mo­wa­nie dla użyt­kow­ni­ka a nie dla fir­my co czę­sto nie jest tożsame ;).

  6. Wolsky

    Dlatego user sto­ry przy­da­ją się przy defi­nio­wa­niu sys­te­mu, struk­tu­ry i pew­nych funk­cji. Przy zro­zu­mie­niu funk­cjo­no­wa­nia pro­duk­tu. Natomiast przy wrzu­ca­niu zadań do bac­klo­gu nie zawsze mają swo­je zasto­so­wa­nie. Najlepiej uży­wać takich narzę­dzi, żeby reali­zo­wać posta­wio­ne sobie cele, nie­za­leż­nie czy będzie to user sto­ry, czy jaki­kol­wiek inny zapis.

    1. Jaroslaw Zelinski

      User sto­ry są bar­dzo dobre jako testy odbior­cze ale jako wyma­ga­nia już nie koniecz­nie (chy­ba, że uzna­my testy za wyma­ga­nia jak w TDD). Obawiam się, że opo­wie­ści tak­sów­ka­rza o tym jak korzy­sta z samo­cho­du nie przy­bli­ża nas do kon­struk­cji (samo­cho­du) jaka ma powstać… Co do ostat­nie­go zda­nia, co do metod zapi­su: opro­gra­mo­wa­nie na koń­cu pod­da­wa­ne jest kom­pi­la­cji a to ści­śle for­mal­ny etap (ści­słe inter­pre­to­wa­nie kodu), im więc wcze­śniej zacznie­my for­ma­li­zo­wać zapis doku­men­ta­cji tym mniej błę­dów popełnimy..

Dodaj komentarz

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