Tag: SCRUM

Praca grupowa czyli Syndrom Sztokholmski w projekcie

1 komentarz

Od wie­lu lat lat, pro­duk­tem mojej pra­cy są doku­men­ty opi­su­ją­ce w obiek­tyw­ny spo­sób dzia­ła­nie orga­ni­za­cji, zawie­ra­ją­ce reko­men­da­cje zmian do popra­wy sytu­acji, tak­że wyma­ga­nia na sys­te­my infor­ma­cyj­ne. Po opra­co­wa­niu roz­wią­za­nia i pomo­cy w wybo­rze jego dostaw­cy, pro­wa­dzę nad­zór autor­ski nad reali­za­cją opra­co­wa­ne­go roz­wią­za­nia. [1] Po latach pra­cy nasu­wa mi się dość cie­ka­wy wnio­sek z obser­wa­cji: Zamawiający dzia­ła­ją na swo­ją szkodę!

Typowy pro­jekt zwią­za­ny z wdra­ża­niem nowych roz­wią­zań to real­ne potrze­by Zamawiającego. Członkowie zespo­łu Zamawiającego mają nad sobą ter­mi­ny i ​„nie­uchron­ność” kary za nie­po­wo­dze­nie. W efek­cie Dostawca szyb­ko sta­je się ​„Panem pro­jek­tu”, bo to on dostar­cza roz­wią­za­nie, zna się, a bywa że szan­ta­żu­je. Przewaga mery­to­rycz­na Dostawcy nad Zamawiającym jest tak wiel­ka, że ten ostat­ni w zasa­dzie nie jest w sta­nie pano­wać nad pro­jek­tem. Powoli rynek to dostrze­ga i dla­te­go od kil­ku lat nie­mal­że każ­da moja umo­wa na pro­jek­to­wa­nie zawie­ra tak­że nad­zór autor­ski (to for­ma kon­tro­li efek­tów pra­cy dostawcy).

Nadal bar­dzo czę­sto Dostawca two­rzy jed­nak pew­ną atmos­fe­rę: ​„to my reali­zu­je­my Wasz pro­jekt i wszyst­ko – Wy tak­że – od nas zale­ży, nad­zór autor­ski psu­je Wam har­mo­no­gram bo my musi­my te doku­men­ty czy­tać i two­rzyć”. Dwa razy w ostat­nich pię­ciu lat zda­rzy­ło mi się, że fak­tycz­nie Zamawiający zre­zy­gno­wał z nad­zo­ru autor­skie­go, bo człon­ko­wie zespo­łu zaczę­li ​„trzy­mać stro­nę Dostawcy”, mimo infor­ma­cji o szko­dli­wo­ści zmian wpro­wa­dza­nych przez z Dostawcę. Oba pro­jek­ty skoń­czy­ły się nie­ste­ty klę­ską (mam kon­takt z prak­tycz­nie każ­dym byłym klientem).

Projekt wdro­że­nio­wy bez nad­zo­ru mery­to­rycz­ne­go, to bar­dzo czę­sto rów­nia pochy­ła: od pod­pi­sa­nia umo­wy na wdro­że­nie z dostaw­cą jest już tyl­ko coraz gorzej, bo Dostawca uprasz­cza logi­kę sys­te­mu, pomi­ja trud­ne do reali­za­cji wyma­ga­nia, sta­le orga­ni­zu­je spo­tka­nia, na któ­rych legi­ty­mi­zu­je te zmia­ny w pro­sty spo­sób spo­sób: ​„to co macie w doku­men­ta­cji wyma­gań jest złe (nie da się, nikt tak nie robi itp.), nasz sys­tem reali­zu­je to ina­czej, zrób­my to pro­ściej i szyb­ciej a też będzie dobrze”. Zamawiający z regu­ły nie ma po swo­jej stro­nie żad­nych kom­pe­ten­cji by oce­nić skut­ki takich ​„pro­po­zy­cji” i na spo­tka­niach godzi się na to, pod­pi­su­jąc kolej­ne notat­ki pro­jek­to­we z takich ​„warsz­ta­tów”, mały­mi krocz­ka­mi funk­cjo­nal­ność dostar­cza­ne­go pro­duk­tu odda­la się od fak­tycz­nych potrzeb i wyma­gań. Projekt koń­czy się tak, że Zamawiający ​„dostał dokład­nie to co chciał a nie to co jest mu potrzeb­ne”. Statystyki pro­jek­tów IT są bez­li­to­sne: ok. 2/3 pro­jek­tów to nadal pro­jek­ty nie­uda­ne. [2]

Tam gdzie mój pro­jekt był kolej­nym podej­ściem, po poprzed­nim nie­uda­nym, wyżej opi­sa­na sytu­acja była prak­tycz­nie zawsze przy­czy­ną wcze­śniej­szej poraż­ki. Paradoksalnie jest to – poraż­ka – wręcz stan­dar­do­wa sytu­acja, gdy Zamawiający naj­pierw wybie­ra Dostawcę a potem zle­ca mu ana­li­zę wyma­gań i kie­ro­wa­nie projektem.

Zjawisko to zawsze koja­rzy mi się ze zna­nym w psy­cho­lo­gii efek­tem nazy­wa­nym Syndrom Sztokholmski. Jest to sytu­acja, w któ­rej ofia­ra, wbrew zdro­we­mu roz­sąd­ko­wi, zaczy­na sym­pa­ty­zo­wać ze swo­im oprawcą.

[Syndrom Sztokholmski] …ofia­ra porwa­nia czy zakład­nik tra­ci kry­ty­cyzm wobec swo­jej sytu­acji, zaczy­na wie­rzyć, ze jej opraw­ca dzia­ła w słusz­nym celu, i darzyć go sym­pa­tią. Jak twier­dzi ame­ry­kań­ska psy­cho­log, dr Natalie de Fabrique, zaj­mu­ją­ca się bada­niem tego syn­dro­mu, syn­drom sztok­holm­ski poja­wia się u ofiar nie­świa­do­mie, to instynk­tow­ny, psy­cho­lo­gicz­ny mecha­nizm obron­ny, dzię­ki któ­re­mu łatwiej jest im odna­leźć sens tego, co się dzie­je, i unik­nąć zała­ma­nia ner­wo­we­go. [3]

W wie­lu pro­jek­tach wdro­że­nio­wych mamy podob­ną sytu­ację: pra­cow­ni­cy zama­wia­ją­ce­go, zamiast dzia­łać na rzecz sie­bie czy swo­je­go pra­co­daw­cy, zaczy­na­ją trzy­mać stro­nę Dostawcy, któ­ry żali się, że ma pro­blem z ter­mi­na­mi i prze­rzu­ca winę za to na swo­je­go klien­ta. Po pew­nym cza­sie docho­dzi do tego, że zespół Zamawiającego tak się ​„zżył z pra­cow­ni­ka­mi Dostawcy”, że zaczy­na ich bro­nić przed wła­sny­mi prze­ło­żo­ny­mi. Są Dostawcy, któ­rzy celo­wo stwa­rza­ją takie sytu­acje (np. orga­ni­zu­jąc wyjaz­do­we szko­le­nia i warsz­ta­ty z noc­le­ga­mi), ale nie raz dzie­je się ​„samo­ist­nie”. Popatrzmy na poniż­szą listę, czy nie przy­po­mi­na Wam to czegoś?

Objawy i symp­to­my syn­dro­mu sztok­holm­skie­go to:
– pozy­tyw­ne uczu­cia ofia­ry wobec sprawcy;
– zro­zu­mie­nie przez ofia­rę moty­wów i zacho­wań spraw­cy i podzie­la­nie jego poglądów;
– pozy­tyw­ne uczu­cia spraw­cy wzglę­dem ofiary;
– pomoc­ne zacho­wa­nia ofia­ry wobec sprawcy;
– nega­tyw­ne uczu­cia ofia­ry wobec rodzi­ny, przy­ja­ciół, auto­ry­te­tów pró­bu­ją­cych ją ratować;
– nie­zdol­ność zaan­ga­żo­wa­nia się w zacho­wa­nia, któ­re mogły­by dopro­wa­dzić do jej uwol­nie­nia od sprawcy.
Syndrom sztok­holm­ski nie doty­czy wszyst­kich osób dotknię­tych tra­gicz­ny­mi zda­rze­nia­mi. By zaist­niał, muszą wystą­pić okre­ślo­ne warun­ki. Ofiara:
– spo­strze­ga, że jej prze­ży­cie zale­ży od dobrej woli sprawcy;
– nie widzi moż­li­wo­ści ucieczki;
– dostrze­ga drob­ne uprzej­mo­ści ze stro­ny sprawcy;
– jest izo­lo­wa­na od per­spek­tyw odmien­nych od per­spek­ty­wy sprawcy.
[4]

Popatrzmy zatem na pro­jekt wdro­że­nio­wy, w którym:

  1. Zespól Zamawiającego wie­rzy, że ​„być albo nie być” fir­my, zale­ży od powo­dze­nia projektu,
  2. Zespół Zamawiającego nie widzi alter­na­ty­wy dla tego wdrożenia,
  3. Zespół Zamawiającego widzi, że Dostawca od cza­su do cza­su idzie mu na rękę (reali­zo­wa­nie drob­nych zachcia­nek Zamawiającego w zakre­sie projektu),
  4. Zespół Zamawiającego jest izo­lo­wa­ny od innych per­spek­tyw i spoj­rze­nia na reali­zo­wa­ny pro­jekt (sil­ne dąże­nie Dostawcy do wyeli­mi­no­wa­nia zewnętrz­ne­go nad­zo­ru mery­to­rycz­ne­go, audy­tów, nad­zo­ru autorskiego).

Psycholodzy co do jed­ne­go są zgod­ni: czło­wiek nie jest w sta­nie bro­nić się przed swo­imi emo­cja­mi, dla­te­go czę­sto jedy­nym spo­so­bem obro­ny przed mani­pu­la­cją jest uni­ka­nie kon­tak­tu z mani­pu­lan­tem. Nie ma tu zna­cze­nia czy to mani­pu­la­cja celo­wa czy nieuświadomiona.

Lekarstwo na sytu­acje, takie jak wyżej opi­sa­na, jest tyl­ko jed­no: zre­zy­gno­wać z warsz­ta­tów gru­po­wych z Dostawcą! Jak to komuś mówię to ma miej­sce prze­ra­że­nie i pada­ją sło­wa ​„Ale prze­cież pra­ca gru­po­wa jest naj­efek­tyw­niej­sza! Tak uczy­li na szko­le­niu i mówi­li na kon­fe­ren­cjach”. W lite­ra­tu­rze nie raz spo­ty­ka­łem się z podej­ściem odra­dza­ją­cym warsz­ta­ty gru­po­we i burze mózgów z uwa­gi a ich duże kosz­ty i nie­efek­tyw­ność. Nie jest jed­nak takich opi­nii zbyt wie­le, bo mit efek­tyw­no­ści pra­cy gru­po­wej jest wiecz­nie żywy (mimo tego, że bada­nia nauko­we poka­zu­ją, że pra­ca gru­po­wa jest mniej efek­tyw­na niż pra­ca samodzielna).

Praca gru­po­wa, mity i fak­ty.

Jednak od cza­su do cza­su spo­ty­kam się książ­ka­mi czy wpi­sa­mi na blo­gach, że odej­ście od idei JAD (ang. Joint Application Development) wydat­nie popra­wi­ło jakość pro­jek­tów (sam IBM pro­po­nu­je w to miej­sce cał­ko­wi­te zastą­pie­nie warsz­ta­tów ana­li­zą doku­men­tów źró­dło­wych a potem pisem­ne for­mu­ło­wa­nie uwag i zarzą­dza­nie zakre­sem pro­jek­tu z uży­ciem ści­słej pro­ce­du­ry, co para­dok­sal­nie trwa kró­cej, jest tań­sze i daje znacz­nie lep­sze efekty).

Co cie­ka­we, idea taka poja­wi­ła się w np. tak zwa­nej zwin­nej meto­dzie zarzą­dza­nia pro­jek­tem SCRUM, w posta­ci roli Product Ownera (PO) jako oso­by prak­tycz­nie cał­ko­wi­cie sepa­ru­ją­cej zespół zama­wia­ją­ce­go od zespo­łu Dostawcy (busi­ness vs. developers):

There are seve­ral aspects abo­ut this role which I think are cri­ti­cal to under­stand: Product owners brid­ge the com­mu­ni­ca­tion betwe­en the team and the­ir sta­ke­hol­ders. As Figure 1 shows, in prac­ti­ce the­re pro­ves to be two cri­ti­cal aspects to this role: first as a sta­ke­hol­der pro­xy within the deve­lop­ment team and second as a pro­ject team repre­sen­ta­ti­ve to the ove­rall sta­ke­hol­der com­mu­ni­ty as a whole.[…]

The role of Product Owner (Scott Ambler, Agile Modeling)

Źródło: The Product Owner Role: A Stakeholder Proxy for Agile Teams

Ciekawe jest to, że więk­szość zna­nych mi zespo­łów dekla­ru­ją­cych pra­cę zgod­ną ze SCRUM, to zespo­ły deve­lo­per­skie, któ­re prak­tycz­nie cał­ko­wi­cie rezy­gnu­ją z praw­dzi­wej roli PO. Jak? Po pro­stu wyzna­cza­ją na PO jed­ne­go z pośród człon­ków zespo­łu deve­lo­per­skie­go, co jest pogwał­ce­niem zasad SCRUM. Skutek jest taki, że oso­ba, któ­rej pod­sta­wo­wą rolą jest zarzą­dza­nie funk­cjo­nal­no­ścią pro­duk­tu i sepa­ro­wa­nie Developera od Zamawiającego, pra­cu­je na rzecz deve­lo­pe­ra i godzi się na każ­dą zmia­nę korzyst­ną dla swo­je­go zespo­łu. Niestety w pro­jek­tach pro­gra­mi­stycz­nych jest to nie­mal­że regu­ła. W pro­jek­tach budow­la­nych (set­ki lat doświad­czeń) dla odmia­ny jest to praw­nie zaka­za­ne: nie wol­no łączyć roli nad­zo­ru autor­skie­go (archi­tekt i pro­jek­tant) ani z rolą wyko­naw­cy ani z rolą inwestora.

Na koniec pole­cam cie­ka­wy arty­kuł na podob­ny temat:

Polacy kupu­ją miesz­ka­nia bez usług i zie­le­ni. Wybierają szczel­nie ogro­dzo­ne beto­no­we pusty­nie bez przed­szko­li, pla­ców zabaw i komu­ni­ka­cji. A obok roz­wią­zań praw­nych to wła­śnie decy­zje kon­su­men­tów ukształ­tu­ją nam prze­strzeń na kolej­ne dzie­się­cio­le­cia. (żr. Ufamy dewe­lo­pe­rom bar­dziej niż leka­rzom. Przypomina to syn­drom sztok­holm­ski).

Bibliografia

[1]
J. Żeliński, ?Moja rola w pro­jek­tach,? IT-Consulting. [Online]. Available: https://it-consulting.pl//metoda-prowadzenia-analiz-i-standardy/
[3]
?Syndrom Sztokholmski,? Newsweek. [Online]. Available: 
[4]
?Syndrom Sztokholmski,? Niebieska linia. [Online]. Available: 

User Story c.d.

2 komentarze

Wokół metod zwin­nych nara­sta wie­le mitów, szcze­gól­nie tych o sku­tecz­no­ści w dużych pro­jek­tach. Dzisiaj kolej­ne kil­ka słów o popu­lar­nym narzę­dziu jakim jest tak zwa­ne ​„user sto­ry” czy­li histo­ryj­ka użyt­kow­ni­ka, o ich ewo­lu­cji i o tym, że mogą być przy­dat­ne i kiedy.

Co praw­da, jako źró­dło infor­ma­cji wolę doku­men­ty, ale bywa, że tym źró­dłem infor­ma­cji są jed­nak użyt­kow­ni­cy, bo doty­czy to pro­jek­to­wa­nia np. nowych por­ta­li biz­ne­so­wych. Tu nie­ste­ty nie ma ani ustaw z wzo­ra­mi doku­men­tów ani ​„dotych­cza­so­we­go papie­ro­we­go obie­gu doku­men­tów”. Bardzo podob­nie wyglą­da­ją start-up’y w obsza­rze ope­ra­cyj­nym. Podobnie wyglą­da ana­li­za i pro­jek­to­wa­nie sys­te­mów wspie­ra­ją­cych obsłu­gę klien­tów (CRM i podob­ne). Dlaczego? Bo tej sfe­ry nie regu­lu­ją ani prze­pi­sy ani żad­ne nor­my. Nie licząc ele­men­tów pra­wa cywil­ne­go, są cał­ko­wi­cie uznaniowe.

User Story

Historyjki użyt­kow­ni­ka, mają swój rodo­wód w EX (pro­gra­mo­wa­nie eks­tre­mal­ne) i są z regu­ły defi­nio­wa­ne tak:

In softwa­re deve­lop­ment and pro­duct mana­ge­ment, a user sto­ry is a descrip­tion con­si­sting of one or more sen­ten­ces in the eve­ry­day or busi­ness lan­gu­age of the end user or user of a sys­tem that cap­tu­res what a user does or needs to do as part of his or her job func­tion (źr. ang. wiki).

Scott Ambler pisze:

User sto­ries are one of the pri­ma­ry deve­lop­ment arti­facts for Scrum and Extreme Programming (XP) pro­ject teams. A user sto­ry is a very high-level defi­ni­tion of a requ­ire­ment, con­ta­ining just eno­ugh infor­ma­tion so that the deve­lo­pers can pro­du­ce a reaso­na­ble esti­ma­te of the effort to imple­ment it. ?1?

Generalnie jest to opis w potocz­nym języ­ku, ten – z uwa­gi na nie­jed­no­znacz­ność – jako wyma­ga­nie, stwa­rza pro­ble­my. Podejmowane są pró­by for­ma­li­zo­wa­nia tych histo­ry­jek. Pisze o tym autor blo­ga QAgile (poda­jąc przy­kła­dy, pole­cam cały artykuł):

W podej­ściu agi­le takim jak Scrum wyma­ga­nia defi­niu­je­my na ogól w posta­ci User Story. Prosta for­ma, któ­ra ma adre­so­wać ocze­ki­wa­nia i potrze­by użyt­kow­ni­ków czę­sto zespo­łom przy­spa­rza dużo pro­ble­mów w imple­men­ta­cji.?2?

Swego cza­su ja tak­że pisa­łem o efek­tach sto­so­wa­nia tej meto­dy z zbyt­nią ufno­ścią w jej skuteczność:

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”.[…]

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 reje­strów.?3?

User sto­ry to opis z per­spek­ty­wy użyt­kow­ni­ka. Najlepszą chy­ba meta­fo­rą będzie tu zna­na aneg­do­ta z opi­sy­wa­niem słonia:

User-Stories

Każdy z tych okrzy­ków to odręb­ne 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 opisów.

I tu wpa­da­my w efekt ?krę­ce­nia fil­mu?. Najczęściej tak zwa­na ana­li­za wyglą­da tak, że pra­cow­ni­cy ana­li­zo­wa­nej fir­my, w toku warsz­ta­tów lub wywia­dów, opo­wia­da­ją z jaki­mi to sytu­acja­mi mają do czy­nie­nia, co robią, kie­dy i jak, opi­su­jąc kon­kret­ne przy­pad­ki z jaki­mi mie­li do czy­nie­nia i to, jak sobie z nimi pora­dzi­li. Do tego docho­dzą przy­pad­ki, w któ­rych sobie sła­bo pora­dzi­li, przy­pad­ki tego jak sobie radzą z tym, że cze­goś nie rozu­mie­ją, a to wszyst­ko jest okra­szo­ne spo­so­ba­mi pra­cy wyni­ka­ją­cy­mi nie raz z nie­wie­dzy, nie­zna­jo­mo­ści pra­wa czy wewnętrz­nych regu­la­cji. Na domiar złe­go, nie raz moż­na się spo­tkać z przy­pad­ka­mi, w któ­rych opo­wia­da­ją­cy o swo­jej pra­cy wpla­ta ele­men­ty pozwa­la­ją­ce mu na dzia­ła­nia nie­po­żą­da­ne takie jak uprasz­cza­nie pro­ce­dur lub wręcz łama­nie pra­wa (np. swe­go cza­su pewien urzęd­nik na moich oczach w trak­cie warsz­ta­tów zgło­sił jako wyma­ga­nie wobec sys­te­mu obie­gu doku­men­tów, moż­li­wość pod­pi­sa­nia orze­cze­nia sędzie­go prze­ter­mi­no­wa­nym pod­pi­sem elek­tro­nicz­nym!).?4?

Historyjki użyt­kow­ni­ka mają sens, jed­nak nie jako ​„kom­plet­ny opis wyma­gań na apli­ka­cję” (wczo­raj usły­sza­łem, że w pew­nej dużej insty­tu­cji zebra­no już ok. tysią­ca (!) takich histo­ry­jek i pro­ces ten nadal trwa). Mają jed­nak sens jako ​„sam­ple” do ana­li­zy. Przekazywanie takich histo­ry­jek bez­po­śred­nio deve­lo­pe­ro­wi jest ogrom­nym ryzy­kiem. Dlaczego? Historyjka, nawet w sfor­ma­li­zo­wa­nej for­mie, nie­sie tyl­ko subiek­tyw­ne ​„spoj­rze­nie z zewnątrz”, a pro­gra­mi­sta zaczy­na domy­ślać się i gdy­bać, nie­jed­no­krot­nie prze­kra­cza­jąc dozwo­lo­ne granice:

…?jako sprze­daw­ca, dosta­ję od klien­tów zamó­wie­nia, na pod­sta­wie któ­rych muszę wysta­wiać fak­tu­ry VAT?, do tego ana­li­tyk doda, np. po ana­li­zie otrzy­ma­nej par­tii doku­men­tów, struk­tu­rę zamó­wie­nia i fak­tu­ry VAT oraz ?algo­rytm? wyli­cze­nia podat­ków. Jeżeli pro­gra­mi­sta zaczy­na ?lepiej wie­dzieć? od zama­wia­ją­ce­go, for­su­jąc np. prost­szą imple­men­ta­cję, to zna­czy, że prze­kro­czył swo­je kom­pe­ten­cje, sam sobie ? jako deve­lo­pe­ro­wi ? robi krzyw­dę psu­jąc to opro­gra­mo­wa­nie bo klient i tak prę­dzej czy póź­niej na tych uprosz­cze­niach ?pole­gnie?.?3? 

Bywa bar­dzo czę­sto, że pro­gra­mi­sta bez żad­ne­go opo­ru przyj­mu­je histo­ryj­kę: ​„ja jako sprze­daw­ca, chcę umie­ścić na fak­tu­rze towar, któ­re­go nie ma jesz­cze w maga­zy­nie, w celu zali­cze­nia sprze­da­ży w danym dniu” … (Komentarz zbędny…)

Czy to zna­czy, że nale­ży odejść cał­ko­wi­cie od tego narzę­dzia? Moim zda­niem nie. Wystarczy uznać , że ​„user sto­ry” to WYŁĄCZNIE opis z per­spek­ty­wy użyt­kow­ni­ka, swo­iste ​„jed­no spoj­rze­nie z setek możliwych”.

Swego cza­su opi­sa­łem tak­so­no­mię pojęć sto­so­wa­nych w ana­li­zie wymagań:

Taksonomia wymagań na system (źr. opracowanie własne Jarosław Żeliński)
Taksonomia wyma­gań na sys­tem (źr. opra­co­wa­nie wła­sne Jarosław Żeliński)

U szczy­tu tej hie­rar­chii mamy wyma­ga­nia biz­ne­so­we. Są to w zasa­dzie owe histo­ryj­ki użyt­kow­ni­ka. To wyra­żo­ne języ­kiem zama­wia­ją­ce­go, ocze­ki­wa­nia w sto­sun­ku do opro­gra­mo­wa­nia. Rolą ana­li­ty­ka jest takie prze­ana­li­zo­wa­nie i prze­two­rze­nie tych opi­sów, by dopro­wa­dzić do powsta­nia sfor­ma­li­zo­wa­ne­go opi­su (np. w posta­ci mode­li UML: przy­pad­ki uży­cia, model dzie­dzi­ny, ogra­ni­cze­nia, inne) czy­li do posta­ci spe­cy­fi­ka­cji usług apli­ka­cji i logi­ki (mecha­ni­zmu) dzia­ła­nia tej aplikacji.

Kolekcjonowanie wyma­gań biz­ne­so­wych w posta­ci np. user sto­ry, ma sens jako zbie­ra­nie ​„sam­pli”, przy­kła­do­wych sytu­acji. Na ich pod­sta­wie, w toku ana­li­zy, moż­na two­rzyć mode­le i testo­wać te histo­ryj­ki (sta­ją się sce­na­riu­sza­mi testo­wy­mi). Tu pole­cam mię­dzy inny­mi blog i książ­ki Scotta Amblera:

In this epi­so­de, Scott Ambler helps us to under­stand the power of using models and how to use models in an agi­le envi­ron­ment.?5?

Wspominałem nie raz o nim i o jego książ­kach na tym blogu:

Co praw­da książ­ka ma 12 lat i trze­ba brać na to lek­ka popraw­kę, jed­nak jest to war­to­ścio­wa, nafa­sze­ro­wa­na dia­gra­ma­mi UML, książ­ka trak­tu­ją­ca o tym, że zwin­ność nie ozna­cza bała­ga­nu i pospo­li­te­go rusze­nia. Scott Ambler to kolej­ny auto­ry­tet w inży­nie­rii opro­gra­mo­wa­nia. I mimo, że niko­go nie ma sen­su mał­po­wać, na pew­no war­to się uczyć? ?6?

Ostatnio popu­lar­ność zdo­by­wa podej­ście sfor­ma­li­zo­wa­ne do histo­ry­jek użyt­kow­ni­ka, bazu­ją­ce na kon­cep­cji Scott’a Amblera (mode­lo­wa­nie) i Rona Jeffries’a, zwo­len­ni­ka porząd­ko­wa­nia, nie tyl­ko tre­ści wywia­dów ;). Tu posłu­żę się ilu­stra­cja­mi z arty­ku­łu na stro­nie Visual Paradigm.

User sto­ry is one of the most impor­tant tool for agi­le deve­lop­ment. They are often used for iden­ti­fy­ing the featu­res of a sys­tem under deve­lo­ped. User sto­ries are well com­pa­ti­ble with the other agi­le softwa­re deve­lop­ment tech­ni­qu­es and methods, such as scrum and extre­me programming. […]

Concept of 3C’s

The 3C’s refer to the three cri­ti­cal aspects of good user sto­ries. The con­cept was sug­ge­sted by Ron Jeffries, the co-inven­tor of the user sto­ries prac­ti­ce. Nowadays, when we talk abo­ut user sto­ries, we usu­al­ly are refer­ring to the kind of user sto­ries that are com­po­sed of the­se three aspects:
Card – User sto­ries are writ­ten as cards. […]
Conversation – Requirements are found and re-fined thro­ugh a con­ti­nu­ous conver­sa­tions betwe­en custo­mers and deve­lop­ment team thro­ugho­ut the who­le softwa­re pro­ject. […]
Confirmation – or also known as Acceptance cri­te­ria of the user sto­ry. […]?7?

W dużym skró­cie: histo­ryj­ki dzie­li­my na jed­nost­ko­we ele­men­tar­ne (nie­po­dziel­ne) opi­sy w posta­ci ​„kart”, zawie­ra­ją­cych opis tego cze­go zama­wia­ją­cy ocze­ku­je od apli­ka­cji, zapis uwag (kon­wer­sa­cja) doty­czą­cych kolej­nych dys­ku­sji z zama­wia­ją­cym na temat danej histo­ryj­ki to histo­ria usta­leń, opis ocze­ki­wa­ne­go uzy­ska­ne­go efek­tu czyn­no­ści opi­sa­nych w danej histo­ryj­ce potwier­dze­nie uzy­ska­nia ocze­ki­wa­ne­go efek­tu. Idąc zaś za wska­zów­ka­mi Amblera, imple­men­ta­cję poprze­dza­my pra­cą nad kon­cep­cją imple­men­ta­cji posłu­gu­jąc się mode­la­mi na dość wyso­kim pozio­mie abstrakcji.

Karta histo­ryj­ki to pro­sty zapis utrzy­ma­ny w kon­wen­cji ​„ja jako «aktor», chcę «nazwa czyn­no­ści» w celu «ocze­ki­wa­ny efekt». Osobiście w pro­jek­tach dopusz­czam bar­dziej ​„luź­ną” for­mę takiej histo­ryj­ki, jed­nak pil­nu­je co do zasa­dy, by doty­czy­ła wyłącz­nie jed­ne­go ​„uzy­ska­ne­go efek­tu koń­co­we­go”. Każda kar­ta ma uni­kal­ne ozna­cze­nie, jest bowiem uży­wa­na jako jed­no zada­nie, w bac­klo­gu i sprin­tach (kan­ban). W doku­men­ta­cji (wspo­mnia­ne narzę­dzie VP) user sto­ry wyglą­da to tak:

01-user-story-example

Historyjki mają swój cykl życia i dobrą prak­ty­ką jest reje­stro­wa­nie wszel­kich kolej­nych uzgod­nień w toku pracy:

02-conversation

Tak zapi­su­je­my ​„sło­wo­tok” zama­wia­ją­ce­go na temat jego wizji reali­za­cji danej usłu­gi apli­ka­cyj­nej. Analogicznie zapi­su­je­my opis ocze­ki­wa­ne­go efek­tu końcowego:

03-confirmation

Do tego momen­tu mamy ​„kla­sycz­ne” zwin­ne pro­wa­dze­nie pro­jek­tu z jego wada­mi opi­sa­ny­mi powyżej.

Wymagania powinny być ​„spójne, kompletne i niesprzeczne”

Jak to osią­gnąć? Analityk zaczy­na zbie­rać te histo­ryj­ki i zaczy­na skła­dać z nich kom­plet­ny pro­ces biz­ne­so­wy. Stanowi on wery­fi­ka­tor, czy całość (zestaw takich histo­ry­jek) sta­no­wi jakąś spój­ną, kom­plet­ną i nie­sprzecz­ną logi­kę biz­ne­so­wą w ska­li całej fir­my. Zmorą pro­jek­tów są wyma­ga­nia odkry­wa­ne w toku wdro­że­nia, dla­te­go war­to poświę­cić czas na wery­fi­ka­cję pomy­słu na całość sys­te­mu i zwe­ry­fi­ko­wać spój­ność i kom­plet­ność tej cało­ści z pomo­cą utwo­rze­nia mode­lu każ­de­go całe­go procesu:

04-business-process-to-user-story-mapping

Warto mode­lo­wać pro­ces gdyż wte­dy widać, że nie zawsze praw­dą jest, że jed­na (każ­da) histo­ryj­ka jest odręb­nym przy­pad­kiem uży­cia. Przypadki uży­cia wypro­wa­dza się z ele­men­tar­nych aktyw­no­ści jeden do jed­ne­go, co z uza­sad­nie­niem opi­sy­wa­łem w arty­ku­le Transformacja…. Model pro­ce­su biz­ne­so­we­go daje kon­tekst, pozwa­la lepiej zro­zu­mieć ​„sens” cało­ści. Czy powyż­szy model pro­ce­su (nota­cja BPMN) z nanie­sio­ny­mi histo­ryj­ka­mi, nie przy­po­mi­na Wam wyni­ków bada­nia sło­nia? Tu słoń został przez ana­li­ty­ka odkry­ty: to pro­ces biz­ne­so­wy (jego model w nota­cji BPMN). Przypadkami uży­cia będą ele­men­tar­ne aktyw­no­ści w pro­ce­sie. Więcej na temat zwin­ne­go pro­wa­dze­nia pro­jek­tu z uży­ciem user sto­ry moż­na zna­leźć w tuto­ria­lu Agile hand­bo­ok.

Na zakończenie…

(źr. Martin Fowler, Analysis Patterns, 1997)
(źr. Martin Fowler, Analysis Patterns, 1997)

We are cal­led ?ana­ly­sts? for a reason! We don?t mere­ly hear sto­ries and convert them into ?requ­ire­ments?. Our inte­gra­ted value lies in going abo­ve and bey­ond the sto­ry and expan­ding bey­ond engen­de­ring deli­ve­ra­bles. We coale­sce cri­ti­cal thin­king and intel­lec­tu­al curio­si­ty to trans­form sto­ries into abs­tracts and to pro­po­se the needs as well as what the pro­blem real­ly is.?1?

___

  1. 1.
    Alami A. Requirement Elicitation: Stories Are Not Requirements. Modern Analyst. https://​www​.moder​na​na​lyst​.com/​R​e​s​o​u​r​c​e​s​/​A​r​t​i​c​l​e​s​/​t​a​b​i​d​/​1​1​5​/​I​D​/​5​2​3​6​/​R​e​q​u​i​r​e​m​e​n​t​-​E​l​i​c​i​t​a​t​i​o​n​-​S​t​o​r​i​e​s​-​A​r​e​-​N​o​t​-​R​e​q​u​i​r​e​m​e​n​t​s​.​a​spx. Accessed May 9, 2019.
  2. 2.
    Kaczor K. Najczęstsze błę­dy popeł­nia­ne przy pisa­niu User Story. QAgile. https://​www​.qagi​le​.pl/​s​c​r​u​m​/​n​a​j​c​z​e​s​t​s​z​e​-​b​l​e​d​y​-​p​o​p​e​l​n​i​a​n​e​-​p​i​s​a​n​i​u​-​u​s​e​r​-​s​t​o​ry/. Accessed May 9, 2019.
  3. 3.
    Żeliński J. User sto­ry czy­li nic nie popra­wić a może nawet bar­dziej skom­pli­ko­wać. IT-Consulting. https://it-consulting.pl//2013/09/11/user-story-czyli-nic-nie-poprawic-a-moze-bardziej-skomplikowac/. Accessed May 9, 2019.
  4. 4.
    Żeliński J. Warsztaty ana­li­tycz­ne ? czy­li malo­wa­nie tra­wy. IT-Consulting. https://it-consulting.pl//2014/12/21/warsztaty-analityczne-czyli-malowanie-trawy/. Accessed May 9, 2019.
  5. 5.
    Ambler S. MBA084: Agile Modeling with Scott Ambler. Mastering Business Analysis. http://​maste​ring​bu​si​nessa​na​ly​sis​.com/​m​b​a​0​8​4​-​a​g​i​l​e​-​m​o​d​e​l​i​n​g​-​w​i​t​h​-​s​c​o​t​t​-​a​m​b​l​er/. Accessed May 9, 2019.
  6. 6.
    Żeliński J. Agile Modeling. Effective Practices for Modeling and Documentation. IT-Consulting. https://it-consulting.pl//2015/05/27/agile-modeling-effective-practices-for-modeling-and-documentation/. Accessed May 9, 2019.
  7. 7.
    Visual-Paradigm. User Story. Visual_paradigm. https://​www​.visu​al​-para​digm​.com/​l​e​a​r​n​i​n​g​/​h​a​n​d​b​o​o​k​s​/​a​g​i​l​e​-​h​a​n​d​b​o​o​k​/​u​s​e​r​-​s​t​o​r​y​.​jsp. Accessed May 9, 2019.

Kim jest product owner?

2 komentarze

Wczoraj pod­czas spo­tka­nia, mia­łem cie­ka­wą roz­mo­wę z przed­sta­wi­cie­la­mi jed­ne­go z pro­du­cen­tów sys­te­mów ERP. Okazało się, że mają bar­dzo podob­ne do moich doświad­cze­nia i wnio­ski: pod­czas wdro­że­nia sys­te­mu ERP potrzeb­ny im jest ktoś, jeden, kto zna i rozu­mie jak dzia­ła dana fir­ma, a nie set­ki stron doku­men­ta­cji czy ste­no­gra­my z dzie­siąt­ków godzin warsz­ta­tów z przy­szły­mi użyt­kow­ni­ka­mi. Do tego fir­ma ta – nabyw­ca sys­te­mu ERP – powin­na mieć, nie szcze­gó­ło­wo opi­sa­ne dzie­siąt­ki deta­licz­nie opi­sa­nych pro­ce­sów i ich warian­tów, pro­ce­dur czy set­ki i tysią­ce nie raz wyma­gań, a stra­te­gię i tak­ty­kę, z któ­rej wyni­ka (da się wyczy­tać) rola opro­gra­mo­wa­nia ERP w fir­mie: tak­ty­kę czy­li opis reali­za­cji stra­te­gii fir­my z pomo­cą pla­no­wa­ne­go do wdro­że­nia sys­te­mu ERP. Ta tak­ty­ka, to opis tego kie­dy i po co opro­gra­mo­wa­nie ma wspie­rać pra­cow­nikw orga­ni­za­cji. To, jak się to będzie odby­wa­ło w szcze­gó­łach, zosta­nie opra­co­wa­ne przez dostaw­cę (wyko­naw­cę) kon­kret­ne­go pro­duk­tu, to dostaw­ca goto­we­go opro­gra­mo­wa­nia opra­co­wu­je kon­cep­cję wdro­że­nia, na pod­sta­wie doku­men­tu opi­su­ją­ce­go tak­ty­kę uży­cia tego opro­gra­mo­wa­nia i wyma­ga­nia biz­ne­so­we (opro­gra­mo­wa­nie dedy­ko­wa­ne wyma­ga dodat­ko­wo zapro­jek­to­wa­nia i udo­ku­men­to­wa­nia logi­ki biz­ne­so­wej jaką ma ono realizować).

I co teraz? Teraz potrzeb­ne jest źró­dło spój­nej wie­dzy o orga­ni­za­cji, jej stra­te­gii i tak­ty­ce w któ­rą ma się wpa­so­wać opro­gra­mo­wa­nie ERP. Któż jest tym źró­dłem? [[Product owner]].

Pytane teraz brzmi: kim jest i człon­kiem czy­je­go zespo­łu jest (powi­nien być) ​„pro­duct owner”? Tu zacy­tu­ję osta­ni aka­pit mojej cie­płej jesz­cze recen­zji książki:

…na ile wizja pro­duk­tu upraw­nia jej posia­da­cza do aktyw­ne­go kie­ro­wa­nia pro­jek­tem wraz z kie­row­ni­kiem pro­jek­tu (Scrum Master), ale to pozo­sta­wiam czy­tel­ni­kom i prak­ty­kom. Jedno moim zda­niem jest pew­ne: nie ma sen­su by zespół deve­lo­pe­ra kon­tak­to­wał się, z tabu­nem przy­szłych ?use­rów?, ma sens by dosta­wał spój­ną wie­dzę o tym co tak na praw­dę ma powstać.

Źródło: Agile Product Management with Scrum | Jarosław Żeliński IT-Consulting

Autor powyż­szej książ­ki nie daje wprost odpo­wie­dzi na to pyta­nie, jed­nak mil­czą­co zakła­da też, że to zespół dostaw­cy ​„wal­czy” ze zja­wi­skiem i pro­duct owner jest człon­kiem tego zespo­łu, nie zmie­nia to fak­tu, że wyma­ga­na od nie­go wie­dza i zro­zu­mie­nie tego, do cze­go user będzie uży­wał opro­gra­mo­wa­nia, powin­na być taka jak opi­sa­łem wyżej.

Co usły­sza­łem po raz kolej­ny (podob­ne roz­mo­wy z dostaw­ca­mi opro­gra­mo­wa­nia nie raz już pro­wa­dzi­łem) od przed­sta­wi­cie­li dostaw­cy sys­te­mu ERP? Potrzebują bar­dzo zwię­złej i spój­nej doku­men­ta­cji (ale raczej 50-ciu stron niż setek, że nie wspo­mnę o kil­ku tysią­cach (tak – widy­wa­łem takie) i po stro­nie klien­ta (jed­nej) oso­by, któ­ra ten doku­ment zna, rozu­mie, ma dostęp do klu­czo­wych osób w orga­ni­za­cji. Najchętniej do auto­ra tego doku­men­tu… Dostawcy opro­gra­mo­wa­nia jak dosta­ją listę setek pozy­cji wyma­gań podzie­lo­nych w mało zro­zu­mia­ły spo­sób na funk­cjo­nal­ne i poza funk­cjo­nal­ne (i inne) raczej sobie z tych spe­cy­fi­ka­cji dwo­ru­ją niż cie­szą się z ich otrzy­ma­nia (pomi­jam, ze nie czy­ta­ją w cało­ści). Po co są więc robio­ne? Bo zama­wia­ją­cy postrze­ga swo­ją pra­cę przez pry­zmat jej zło­żo­no­ści, warian­to­wo­ści, nie patrzy z per­spek­ty­wy narzę­dzia a tym wła­śnie jest opro­gra­mo­wa­nie. To tak jak by cie­śla lub sto­larz opi­sał wyma­ga­nia na mło­tek cie­siel­ski w posta­ci setek stron ​„user sto­ry” o tym jak, do cze­go i kie­dy używa(łby) młot­ka.. dla ana­li­ty­ka pro­jek­tan­ta taki opis (a kon­kret­nie jego ską­pa część) ma sens, dla kon­struk­to­ra – żad­ne­go, ten raczej ocze­ku­je rysun­ku tech­nicz­ne­go wykonawczego.

The role of Product Owner (Scott Ambler, Agile Modeling)
The role of Product Owner (Scott Ambler, Agile Modeling)

Powyższy dia­gram to poglą­do­wy model roli pro­duct owne­ra (PO) autor­stwa jed­ne­go z moich ulu­bio­nych ​„zwin­nych ana­li­ty­ków”: Scott’a Amblera (Scott Ambler). Niewątpliwie moż­na dywa­go­wać czy PO to ​„pra­cow­nik” dosa­tw­cy czy kupu­ją­ce­go ale tu chy­ba część wąt­pli­wo­ści roz­wie­ją sło­wa jed­ne­go z moich klien­tów, postrze­gam go jako jed­ne­go z lepiej zarzą­dza­ją­cych ryzy­kiem biz­ne­so­wym, zna­nych mi, pre­ze­sów firm: ​„Panie Jarku nie wiem czy jest Pan lep­szym czy gor­szym spe­cja­li­stą od ludzi dostaw­cy, zatrud­ni­łem Pana bo prze­ło­żo­nym tam­tych jest Prezes tam­tej firmy”.

Where Do Product Owners Come From? The goods news is that the­re are seve­ral via­ble options for whe­re Product Owners may come from: Business ana­lyst. Although a tra­di­tio­nal busi­ness ana­lyst could fill the role of pro­duct owner, the­re is a risk that they will fall into the­ir old habits of com­mu­ni­ca­ting via docu­men­ta­tion. Keep in mind that what agi­le teams real­ly need are people with agi­le ana­ly­sis skills who are empo­we­red to make deci­sions. So, a bet­ter option is an empo­we­red agi­le busi­ness ana­lyst. (za The Product Owner Role: A Stakeholder Proxy for Agile Teams).

Tak więc nasu­wa się wnio­sek, że rolę PO powi­nien peł­nić ten czło­wiek, któ­ry wła­śnie skoń­czył ana­li­zę biz­ne­so­wą i napi­sał raport z niej. Raport, któ­ry zawie­ra spe­cy­fi­ka­cją wyma­gań (naj­le­piej w for­mie jak opi­sa­na powy­żej). W zasa­dzie nad­zór autor­ski nad reali­za­cją tak­ty­ki wdro­że­nia sys­te­mu ERP (opro­gra­mo­wa­nia w ogó­le) to nic inne­go jak ​„bycie pro­duct owne­rem” w pro­jek­cie na eta­pie jego reali­za­cji a SCRUM fak­tycz­nie, na dzi­siej­sze cza­sy, wyda­je się być naj­lep­szą meto­dą zarzą­dza­nia taki­mi pro­jek­ta­mi a utrzy­my­wa­nie aktu­al­no­ści doku­men­tu ana­li­zy biz­ne­so­wej i wyma­gań w toku pro­jek­tu pro­wa­dzi do tego, że po zakoń­cze­niu pro­jek­tu mamy ​„nie­chcą­cy” kom­plet­ną i aktu­al­ną doku­men­ta­cje sta­nu uzy­ska­ne­go w toku wdrożenia.

(książ­ki Scotta Amblera cze­ka­ją na recenzję ;))

Agile Product Management with Scrum

1 komentarz

Cóż, kolej­ny raz odkry­wam, że jestem zwinny :).

A tak poważ­nie, obser­wu­ję sty­gnię­cie ide­olo­gii zwin­nych metod i prze­cho­dze­nie od dogma­tów do prak­ty­ki. Niewątpliwie oto­cze­nie ryn­ko­we zmie­nia się szyb­ko i meto­dy struk­tu­ral­ne, tak, te z lat 80’tych pole­ga­ją­ce na wni­kli­wej i cza­so­chłon­nej ana­li­zie i budo­wie cało­ścio­we­go rela­cyj­ne­go mode­lu danych dla sys­te­mu i pro­jek­to­wa­niu listy jego funk­cji, to fak­tycz­nie ​„wodo­spa­do­we” złe podej­ście. Tego nikt roz­sąd­ny nie negu­je. Zwinność jed­nak, to nie ​„rezy­gna­cja z pra­co­chłon­nej doku­men­ta­cji” (czę­sto to wła­śnie sły­szę), a uzna­nie, że opro­gra­mo­wa­nie powin­no powsta­wać rela­tyw­nie mały­mi kro­ka­mi, przy­ro­sto­wo. I tyle, nie zna­czy to, ze rezy­gnu­je­my z pla­no­wa­nia. Tak, ana­li­za i mode­lo­wa­nie to pla­no­wa­nie tego co ma powstać. To się nazy­wa ite­ra­cyj­no-przy­ro­sto­we two­rze­nie sys­te­mu. Ok, jed­no z głowy.

A kto ma wie­dzę o orga­ni­za­cji i o tym jaki pro­dukt w danym pro­jek­cie roz­wią­że okre­ślo­ne pro­ble­my? Ten kto tę orga­ni­za­cję prze­ana­li­zo­wał, opra­co­wał wyma­ga­nia na pro­dukt (tu opro­gra­mo­wa­nie) i jed­no­oso­bo­wo ma wizję tego produktu.

Tak, np. taką oso­ba jest Analityk Biznesowy. Na eta­pie Analizy Biznesowej jest tym, kto opra­cu­je opis pro­duk­tu czy­li wyma­ga­nia jakie ma speł­niać. Od momen­tu pod­pi­sa­nia umo­wy na dostar­cze­nie (wytwo­rze­nie) tego pro­duk­tu… peł­ni (może to robić) role Product Ownera, roli w meto­dy­ce SCRUM odpo­wie­dzial­nej wła­śnie za rozu­mie­nie tego czym ma być to opro­gra­mo­wa­nie. Gorąco pole­cam książ­kę: Agile Product Management with Scrum: Creating Products that Customers Love, któ­ra tak na praw­dę – nie­co wbrew tytu­ło­wi – trak­tu­je o roli Product Ownera. 

Tu poja­wia się pro­blem: na ile wizja pro­duk­tu upraw­nia jej posia­da­cza do aktyw­ne­go kie­ro­wa­nia pro­jek­tem wraz z kie­row­ni­kiem pro­jek­tu (Scrum Master), ale to pozo­sta­wiam czy­tel­ni­kom i prak­ty­kom. Jedno moim zda­niem jest pew­ne: nie ma sen­su by zespół deve­lo­pe­ra kon­tak­to­wał się, z tabu­nem przy­szłych ​„use­rów”, ma sens by dosta­wał spój­ną wie­dzę o tym co tak na praw­dę ma powstać. 

Polecam tę książkę.

P.S.
Jak się to ma do moich pro­jek­tów? A tak 🙂 Analityk Biznesowy w pro­jek­cie.

Słabości tradycyjnych metod wytwarzania IT – czy na pewno słabości?

38 komentarzy
SCRUM

Nie jestem zwo­len­ni­kiem kla­sycz­ne­go, kaska­do­we­go pro­ce­su pro­jek­to­wa­nia i wytwa­rza­nia opro­gra­mo­wa­nia. Preferuje pro­ces podob­ny do kaska­do­we­go, z pro­to­ty­pa­mi odrzu­ca­ny­mi, jed­nak pro­to­ty­pem jest u model (pro­jekt) a nie żywy kod. Proces taki opi­su­je np. meto­dy­ka MDA (wię­cej na stro­nie OMG, przyj­dzie pora i na nie­go tu). Jednak pro­pa­gan­da mówi, że jak ​„powszech­nie wiadomo”…

…model kaska­do­wy ska­zu­je klien­ta na dłu­gi czas ocze­ki­wa­nia na efekt koń­co­wy. Bardzo dużo cza­su pochła­nia­ją ana­li­zy przed­wdro­że­nio­we i szcze­gó­ło­we pro­jek­ty, a ich wynik jest widocz­ny wyłącz­nie ?na papie­rze?. (za Scrum eli­mi­nu­je sła­bo­ści tra­dy­cyj­nych metod wytwa­rza­nia IT).

I od razu do rze­czy. Powyższe nie jest praw­dą. Badania pro­jek­tów poka­zu­ją coś zupeł­nie odwrotnego:

Statystyka pracochłonności projektów IT

Jak widać, popraw­na (o takiej tu mowa) ana­li­za wyma­gań, skra­ca czas imple­men­ta­cji (pro­jek­to­wa­nie i wyko­na­nie) o ponad poło­wę. Po dru­gie owe zwin­ne ite­ra­cje to nic inne­go jak odkry­wa­nie wyma­gań meto­dą prób i błę­dów, co jest cza­so­chłon­ne i kosz­tow­ne, co widać na powyż­szym dia­gra­mie (poka­zu­je on sta­ty­sty­ki ukoń­czo­nych projektów).

A co jest prawdą?

To, że ów czas trwa­nia pro­jek­tu jest dłu­gi, to naj­czę­ściej efekt zbyt duże­go zakre­su tego pro­jek­tu a nie tej czy innej meto­dy­ki. Po pro­stu sys­tem mają­cy 200 pla­no­wa­nych cech funk­cjo­nal­nych będzie budo­wa­ny dłu­go nie dla­te­go, że wybra­no ​„kaska­do­wą meto­dy­kę” tyl­ko dla­te­go, że ​„jest duży”.

Cytowany arty­kuł (zachwa­la­ją­cy meto­dy­kę SCRUM) wska­zu­je na kil­ka ​„wad” ana­li­zy i pro­jek­to­wa­nia, zobacz­my co tu jest wadą…

Ryzyko uzy­ska­nia nie­ade­kwat­ne­go roz­wią­za­nia ? model kaska­do­wy ska­zu­je klien­ta na dłu­gi czas ocze­ki­wa­nia na efekt koń­co­wy. Bardzo dużo cza­su pochła­nia­ją ana­li­zy przed­wdro­że­nio­we i szcze­gó­ło­we pro­jek­ty, a ich wynik jest widocz­ny wyłącz­nie ?na papierze?.

  • Z punk­tu widze­nia klien­ta, ana­li­zy to bar­dzo istot­ny koszt, któ­ry dłu­go się zwra­ca ? klient pła­ci za doradz­two, czę­sto nie widząc żad­ne­go real­ne­go rezul­ta­tu poza doku­men­ta­mi. Skomplikowane i zło­żo­ne pro­jek­ty to dla orga­ni­za­cji wiel­ka odpo­wie­dzial­ność, tym­cza­sem w podej­ściu kaska­do­wym im bar­dziej zło­żo­ne pro­jek­ty, tym moc­niej rośnie ryzy­ko zwią­za­ne z rezul­ta­tem końcowym.
  • Przy zasto­so­wa­niu Scrum takie ryzy­ko prak­tycz­nie nie ist­nie­je. Obie stro­ny wie­dzą, że w okre­sie współ­pra­cy mogą wypra­co­wać roz­wią­za­nie, któ­re­go nie moż­na było prze­wi­dzieć na począt­ku pro­jek­tu. Przy tym zwin­nym podej­ściu coś takie­go jak osta­tecz­na defi­ni­cja final­nej wer­sji pro­duk­tu na począt­ku pro­jek­tu nie ist­nie­je.

I to jest ten moment, gdy ja pytam: na co zawar­to umo­wę i z cze­go jest roz­li­cza­ny dostaw­ca? Tak więc dostaw­ca jest prak­tycz­nie bez­kar­ny, bo może dostar­czyć cokol­wiek… jak nazwać to ryzy­ko? Po dru­gie kry­ty­ka pro­ce­su ana­li­zy jako zbęd­ne­go poże­ra­cza cza­su i środ­ków wyma­gań nijak się ma do prak­ty­ki, co poka­zu­je przy­to­czo­ny na począt­ku wynik badań.

I dalej:

Opóźniony rezul­tat ? celem IT bar­dziej niż kie­dy­kol­wiek wcze­śniej jest dziś wspie­ra­nie biz­ne­su w jego codzien­nych dzia­ła­niach i szyb­kie reago­wa­nie na dyna­micz­ne zmia­ny w oto­cze­niu biz­ne­so­wym. W mode­lu kaska­do­wym na rezul­tat pro­jek­tu cze­ka się dłu­go, ponie­waż okre­śla go peł­na, final­na wer­sja produktu.

Dobry pro­jekt ma wizję i eta­py. Każdy etap to ogra­ni­czo­na licz­ba funk­cjo­nal­no­ści, moż­li­wych do dostar­cze­nia w cza­sie wyma­ga­nym przez biz­nes. Nie widzę powo­dów, by dzia­ła­ją­ce pod­sys­te­my dostar­czać np. kwar­tal­nie, i tak się dzieje.

Bardzo mała ela­stycz­ność pod­czas pro­jek­tu ? biz­nes ule­ga cią­głym zmia­nom, co w oczy­wi­sty spo­sób pocią­ga za sobą zmia­ny ocze­ki­wań doty­czą­cych funk­cjo­nal­no­ści zama­wia­ne­go opro­gra­mo­wa­nia. Model kaska­do­wy kon­trak­tu­je pro­jekt na eta­pie ana­liz (lub nawet wcze­śniej), po czym obu stro­nom trud­no jest bez ryzy­ka wno­sić istot­ne zmia­ny do zapla­no­wa­nych prac.

Po pierw­sze nie wiem skąd autor wziął tezę o tym, że ​„Model kaska­do­wy kon­trak­tu­je pro­jekt na eta­pie ana­liz (lub nawet wcze­śniej”. Model kaska­do­wy nie ma tu nic do rze­czy. Dobra umo­wa zawie­ra zakres pro­jek­tu, a pro­jekt ma cel biz­ne­so­wy, i nie powin­no nim być zatrud­nie­nie pro­gra­mi­stów na kwar­tał po jakiejś staw­ce, a wytwo­rze­nie cze­goś kon­kret­ne­go i nazwa­ne­go w kon­kret­nym czasie.

System, w któ­rym imple­men­ta­cję poprze­dza ana­li­za i pro­jek­to­wa­nie dzie­li się na eta­py jak każ­dy inny. Po dru­gie nie praw­dą jest, że kon­trak­tu­je się od razu całość. Dobry pro­jekt ma oddzie­lo­ny etap pro­jek­to­wa­nia od wyko­na­nia, klu­czem jest raczej to na jaki zakres ​„rzu­ca się”, zamawiający.

Potencjalnie więk­sze kosz­ty ? w pro­jek­tach IT liczy się nie tyl­ko zwrot z inwe­sty­cji (ROI), ale też czas, w jakim ponie­sio­ne inwe­sty­cje zaczy­na­ją się zwracać.

Tu odno­szę wra­że­nie, że autor nie rozu­mie co napi­sał albo jest to błąd redak­cyj­ny… zwrot z inwe­sty­cji to zysk w cza­sie, więc nie ma zna­cze­nia nic poza cał­ko­wi­tym kosz­tem i cza­sem w jakim go liczymy.

Biznes jest dziś tak dyna­micz­ny, że dużą korzy­ścią jest dla nie­go względ­nie szyb­ki dostęp do dosta­tecz­nie dobrych roz­wią­zań. W podej­ściu kaska­do­wym czas ocze­ki­wa­nia na final­ny pro­dukt jest bar­dzo długi.

Kolejna nie­praw­da, czas ocze­ki­wa­nia jest dokład­nie taki jaki zapla­no­wa­no… moż­na pla­no­wać podział duże­go pro­jek­tu na pod­sys­te­my (jak wyżej).

Duże ryzy­ko złych rela­cji ? model kaska­do­wy z zało­że­nia dzie­li obie stro­ny kon­trak­tu na dwa obo­zy: dostaw­cy i odbior­cy rozwiązania.

To cie­ka­wost­ka, nie wiem skąd autor wysnuł taki wniosek.…

Marnotrawstwo cza­su i pie­nię­dzy przez biu­ro­kra­cję ? pra­ca opar­ta na czę­stych ite­ra­cjach i powta­rzal­nym pro­ce­sie (sprin­tach) pozwa­la bar­dzo szyb­ko iden­ty­fi­ko­wać nie­do­sko­na­ło­ści spe­cy­fi­ka­cji i luki w pier­wot­nej kon­cep­cji. Strony mogą szyb­ko zorien­to­wać się, że na eta­pie przy­go­to­waw­czym np. nie wzię­to pod uwa­gę istot­nych kom­po­nen­tów lub inter­fej­sów. W mode­lu wodo­spa­do­wym wno­sze­nie zmian wią­że się naj­czę­ściej z pisa­niem anek­sów i rene­go­cjo­wa­niem kontraktu.

Kolejna nie­praw­da. czę­ste ite­ra­cje to czę­ste popraw­ki pro­jek­tu w poszu­ki­wa­niu ​„wła­ści­we­go roz­wią­za­nia”. Takie same ite­ra­cje robi ana­li­tyk na eta­pie ana­li­zy i pro­jek­to­wa­nia, two­rząc pro­jekt ​„na papie­rze”, rzecz w tym, że ana­li­tyk na papie­rze robi to sam w cią­gu poje­dyn­czych godzin a zespół pro­gra­mi­stów robi to kil­ka dni kosz­tem kil­ku­na­stu ​„oso­bod­nió­wek” tego zespo­łu. Koszty i czas łatwo sobie porównać…

W Scrum wszyst­kie nie­do­pa­trze­nia moż­na natych­miast uwzględ­nić na każ­dym eta­pie reali­za­cji pro­jek­tu, bez koniecz­no­ści uru­cha­mia­nia nie­wy­god­nej dla obu stron, i czę­sto burzą­cej rela­cje biz­ne­so­we, pro­ce­du­ry obsłu­gi zmian (Change Requests). Jeśli podej­ście słu­ży pro­jek­to­wi, a tak jest w przy­pad­ku Scrum, dostaw­ca i odbior­ca ela­stycz­nie dopa­so­wu­ją się do sie­bie nie­za­leż­nie od tego, jak dale­ce zmie­nia­ją się ocze­ki­wa­nia i potrze­by biznesowe.

Jeżeli autor uwa­ża, że wpro­wa­dza­nie ad-hoc nie­for­mal­nych zmian w zakre­sie pro­jek­tu czy­ni pro­jekt lep­szym, to pozo­sta­wiam go z tym przeświadczeniem.

Scrum pole­ga na wspól­nym widze­niu celu, jakim jest roz­wią­za­nie kon­kret­ne­go pro­ble­mu biz­ne­so­we­go. Jest to czę­sto dale­kie odej­ście od sztyw­nej inter­pre­ta­cji zapi­sów kon­trak­to­wej spe­cy­fi­ka­cji wyma­gań, któ­re same w sobie narzu­ca­ją zespo­łom pro­jek­to­wym ogra­ni­cze­nia reali­za­cyj­ne (tech­nicz­ne) nie­za­leż­nie od pro­ble­mu jaki jest rze­czy­wi­ście do roz­wią­za­nia. Zaletą Scrum jest przej­rzy­stość i wyso­ka ela­stycz­ność projektu.

Tu przy­to­czę sło­wa moje­go kole­gi prawnika:

Największym pro­ble­mem spo­rów przed sądem, w spo­rach z fir­ma­mi pro­gra­mi­stycz­ny­mi jest to, że wie­le tych firm nicze­go nie doku­men­tu­je i tak na praw­dę nie wia­do­mo o co toczy się spór. Większość takich spraw zakła­da­ją pokrzyw­dzo­ne fir­my, nabyw­cy usług pro­gra­mi­stycz­nych. W zasa­dzie więk­szość tych spraw, te fir­my wła­śnie prze­gry­wa­ją, bo nie wia­do­mo co mia­ło powstać a wia­do­mo ile mia­ło kosz­to­wać. Tu sądy są bez­sil­ne… wygry­wa­ją pro­gra­mi­ści, mając pie­nią­dze mimo, że nie osią­gnię­to celu zama­wia­jąc. Ale win­ni są sobie wyłącz­nie zama­wia­ją­cy, godzą­cy się na taką treść tych umów…

A co mówią statystyki?

Analysts report that as many as 71 per­cent of softwa­re pro­jects that fail do so becau­se of poor requ­ire­ments mana­ge­ment, making it the sin­gle big­gest reason for pro­ject failure?bigger than bad tech­no­lo­gy, mis­sed deadli­nes or chan­ge mana­ge­ment fia­sco­es. ( źr. Fixing the Software Requirements Mess CIO​.com).

Parząc na powyż­sze (wytłusz­cze­nie: w więk­szo­ści z ponad 71% złych pro­jek­tów pro­gra­mi­stycz­nych, powo­dem kło­po­tów było złe zarzą­dza­nie wyma­ga­nia­mi, co czy­ni­ło więk­sze szko­dy niż pozo­sta­łe powo­dy, takie jak tech­no­lo­gie, napię­te ter­mi­ny czy zarzą­dza­nie zmia­na­mi, razem wzię­te). I niech nikt mi nie mówi, że 29% to same SCRUM’y a pozo­sta­łe 71% to ​„kaska­do­we” pro­jek­ty bo to nieprawda.

Na zakończenie

Tak więc zasta­nów­my się czy aby na pew­no brak pro­jek­tu i spe­cy­fi­ka­cji wyma­gań to dobry spo­sób na pro­jekt IT. Czy meto­dy wytwa­rza­nia bazu­ją­ce na bra­ku pier­wot­ne­go pro­jek­tu, fak­tycz­nie są zba­wie­niem pro­jek­tów pro­gra­mi­stycz­nych… Państwo sami muszą wybrać… Dodam na koniec, że powyż­sze doty­czy w takim samym stop­niu sys­te­mów dedy­ko­wa­nych jak i goto­wych a wyma­ga­ją­cych ​„kasto­mi­za­cji” bo to (nowe funk­cjo­nal­no­ści sys­te­mu) tak­że pro­jekt dedykowany.

Dilbert wymagania na oprogramowanie

Czego moglibyśmy się nauczyć od naukowców?

4 komentarze

Nie jest tu, na moim blo­gu, tajem­ni­cą, że pre­fe­ru­ję nauko­we meto­dy ana­li­zy. Nie cho­dzi o ​„gma­twa­nie świa­ta” a o pro­ste a sku­tecz­ne podej­ście. Codzienna lek­tu­ra blo­gów zapro­wa­dzi­ła mnie dziś na stro­ny pro­gra­mi­sty, któ­ry napisał:

Czego mogli­by­śmy się nauczyć od naukow­ców? A być może tego jak waż­ną rolę i jak bar­dzo cza­so- i kosz­to­chłon­ne jest samo pla­no­wa­nie eks­pe­ry­men­tu, jak waż­ne jest zro­zu­mie­nie czyn­ni­ków zewnętrz­nych któ­re mogą mieć wpływ na prze­bieg eks­pe­ry­men­tu. Być może war­to się zanu­rzyć w ten świat i spróbować.

Zapowiada się nie­źle. oso­bi­ście uwa­żam, że eks­pe­ry­ment jest gene­ral­nie tań­szy i bez­piecz­niej­szy od ćwi­czeń na żywym cie­le, te ostat­nie są zresz­tą nie raz wręcz zabro­nio­ne. Zanurzanie się w ​„świat rze­czy­wi­sty” wiec nie raz jest moż­li­we tyl­ko raz: odda­ją goto­we roz­wią­za­nie (w zasa­dzie jak samo­lot, goto­wy jest obla­ty­wa­ny już z czło­wie­kiem na pokładzie).

Bardzo podo­ba mi się oso­bi­ście idea eks­pe­ry­men­tu. W moim, tak uwiel­bia­nym wąt­ku archi­tek­tu­ry, ana­li­zy biz­ne­so­wej i zarzą­dza­nia pro­jek­ta­mi cza­sa­mi zbyt czę­sto zawie­rza­my teo­riom, mani­fe­stom, wzo­rom i skom­pli­ko­wa­nym mecha­ni­zmom wyli­cza­nia popraw­no­ści zło­żo­no­ści wszech­świa­ta. Naukowcy w sytu­acji gdy zło­żo­ność pro­ble­mu unie­moż­li­wia jego roz­wią­za­nia meto­da­mi ana­li­tycz­ny­mi zwra­ca­ją się ku ​„eks­pe­ry­men­to­wi”. Dlatego bła­gam was archi­tek­ci i ana­li­ty­cy, następ­nym razem gdy będzie­cie pró­bo­wa­li zapro­jek­to­wać zło­żo­ny sys­tem wyko­rzy­staj­cie siłę jaką daje eks­pe­ry­ment. Wszelkiej maści ​„pro­to­ty­py”, ​„testy” czy też Agile’owe ​„spi­ke” są lep­sze niż UML’e, dia­gra­my, work­flo­w’y i rysu­necz­ki z pro­ce­sa­mi biz­ne­so­wy­mi. Programiści was polu­bią za cie­ka­we zada­nia, a wy będzie­cie się mogli pochwa­lić dzia­ła­ją­cy­mi systemami.

I tu zaczy­na­ją się scho­dy. Bo jeże­li rozu­miem pro­gra­mi­stów, że lubią się bawić na koszt klien­ta, to nie rozu­miem dla­cze­go od razu chcą latać na pro­to­ty­pach samo­lo­tów, gorzej, nie chcą cze­kać na pro­jekt i te śmiesz­ne rysun­ki tech­nicz­ne. Dlaczego inży­nier mecha­nik chce zaj­mo­wać się pro­jek­to­wa­niem tego jak ma wyglą­dać i latać samo­lot sko­ro jego rola i kom­pe­ten­cje to kon­stru­owa­nie a nie np. bada­nie satys­fak­cji klien­ta z lotu na wygod­nym fotelu…

Jak mam sobie wyobra­zić two­rze­nie samo­lo­tu w posta­ci pod­sta­wia­nych na lot­ni­sko pasa­żer­skie kolej­nych pro­to­ty­pów? Czy każ­dy pro­jekt IT to samo­lo­ty? Tak! Tam pra­cu­ją ludzie, pła­cą za to i cier­pi ich biz­nes jak opro­gra­mo­wa­nie nie zadzia­ła od razu jak trzeba!

Czy pro­to­ty­py kodu są lep­sze o niż mode­le pro­ce­sów i pro­jek­tu UML? Ja zapy­tam: opra­co­wa­nie i prze­te­sto­wa­nie mapy pro­ste­go pro­ce­su, potem przy­pad­ku uży­cia, kawał­ka mode­lu dzie­dzi­ny i testo­wa­nie tego dia­gra­mem sekwen­cji to pra­ca dla mnie, jed­nej oso­by, na kart­ce papie­ru, koszt to jakieś np. 1000zł. Oddaje pro­dukt (pro­jekt) nie wyma­ga­ją­cy nicze­go poza imple­men­ta­cją. Czy za 1000zł ktoś posa­dzi czło­wie­ka lub ludzi, napi­sze i prze­te­stu­je kod kil­ku­na­stu klas plus dzie­siąt­ków tech­nicz­nych, mając do dys­po­zy­cji jakąś plat­for­mę by to uru­cho­mić? I klient odbie­rze i uży­je to za pierw­szym razem?

Naukowe meto­dy, szcze­gól­nie te zda­rze­nio­we, pole­ga­ją­ce na sta­wia­niu tezy i pró­bie jej fal­sy­fi­ka­cji, to po pierw­sze sku­tecz­ne meto­dy, po dru­gie nie­in­wa­zyj­ne, po trze­cie rela­tyw­nie tanie (w rela­cji do pra­cy na żywym ciele/kodzie). Po co work­flow? Po to by prze­te­sto­wać, czy to co opo­wia­da nie­udol­nie i mozol­nie klient jest logicz­ne, jest praw­dą (tak!). Przetestowany pro­ces biz­ne­so­wy to nic inne­go jak makie­ta, dobry plan mia­sta do pla­no­wa­nia wyciecz­ki. UML? Cóż, moż­na wpu­ścić tabun mura­rzy na budo­wę bez pro­jek­tu archi­tek­to­nicz­ne­go, i meto­dą ​„pro­to­ty­py”, ​„testy” czy też Agile’owe ​„spi­ke” posta­wią wie­żo­wiec ale nie jestem pewien czy to będzie tanio i nie wiem czy odwa­żył bym bym się w tym czymś zamiesz­kać. Po dru­gie zapy­tam: sko­ro te UML’e głu­pie to dla­cze­go książ­ki o wzor­cach pro­jek­to­wych i archi­tek­tu­rze sys­te­mów są nimi nafaszerowane?

Czego jesz­cze może­my się nauczyć od naukow­ców? A to że ​„Dobry eks­pe­ry­ment musi być jak naj­prost­szy w wyko­na­niu i jed­no­cze­śnie dawać jak naj­bar­dziej jed­no­znacz­ną odpo­wiedź potwier­dza­ją­cą lub fal­sy­fi­ku­ją­cą daną teo­rię” (Wikipedia). Czyli Keep Your Tests Simple. (źr. cyta­tów: pri​mi​ti​ve​.jog​ger​.pl.)

A tu pro­szę, same roz­sąd­ne rze­czy (może dla­te­go że prze­pi­sa­ne z WIKI). Oczywiście: model pro­ce­su dobry, to pro­sty model, jego testo­wa­nie tak­że nie jest skom­pli­ko­wa­ne, a odpo­wiedź zero­je­dyn­ko­wa: dzia­ła albo nie działa.

Autor pisze na poczat­ku swo­je­go arty­ku­łu, że stwo­rze­nie pro­gra­mu to teza:

  1. przy zało­żo­nym cza­sie (t) oraz zało­żo­nym budże­cie (b) dostar­czy­my sys­tem (S)
  2. któ­ry dane wej­ścio­we (i) prze­kształ­ci w dane wyj­ścio­we (o)

Haczyk tu tkwi, w tym, że więk­szość pro­gra­mi­stów rzu­ca się na takie coś mimo, że nie dys­po­nu­je opi­sem ​„czym jest (S). Bo nie są nim ani przy­pad­ki uży­cia ani user sto­ry anie notat­ki z sesji JAD. Po dru­gie czym jest ten­że ​„sys­tem”? Bez jego pro­jek­tu nie da się okre­ślić ani ter­mi­nu ani budże­tu ani cza­su wyko­na­nia. To tak jak by ktoś napi­sał, że ​„przy zało­żo­nym cza­sie i budże­cie zbu­du­je hotel wie­dząc jedy­nie ilu gości będzie musiał przy­jąć w cią­gu doby”.

Podejrzewam, że autor po pro­stu miał tego pecha, że dosta­wał jakieś kiep­skie ana­li­zy i pro­jek­ty, beł­kot, któ­re­go nie­ste­ty jest masa. Wtedy jak naj­bar­dziej ma pra­wo mieć rację (tro­chę). ale co dalej znaj­du­je­my na tym blogu:

Estymaty pro­jek­tów przy zasto­so­wa­niu zasa­dy 200% bufo­ru bez­pie­czeń­stwa nadal roz­pa­da­ją się jak zam­ki z pia­sku. Jak to kole­ga ujął pró­bu­jąc zamknąć defi­ni­cję Agile w jed­nym zda­niu ​„klient nadal nie wie co chce, a my dostar­czy­my co mamy” (źr. Slow coding).

Proponuje mu albo jego kie­row­ni­kom pro­jek­tów (w sumie to nie wiem kogo tu oce­niać…) więc poczytać:

  1. opis ana­li­zy meto­dą nauko­wą: Analiza sys­te­mo­wa – ana­li­za biz­ne­so­wa i pro­jek­to­wa­nie systemów
  2. oraz IIBA czy­li jak to robią…

oraz: książ­ki Fowlera, Yourdona, Evansa czy tak zwa­ne­go Gangu Czworga.

Nie są to może jakieś wypa­sio­ne pro­jek­ty ale co do zasa­dy są to owe work­flow­ły i jueme­le do zapo­zna­nia się…:

Na zakończenie

Co mogę po tym powie­dzieć? Państwo sami zde­cy­duj­cie co woli­cie w swo­ich pro­jek­tach: 200% narzu­tu na swo­bod­ne podej­ście dostaw­ców opro­ga­ra­mo­wa­nia czy 20% na dobre­go ana­li­ty­ka pro­jek­tan­ta i dru­gie 20% jakie uczci­wy dostaw­ca doda mając dobry projekt …

Autor napi­sał swo­ją odpo­wiedź i dobrze, bo pole­mi­ka kształci:

http://​pri​mi​ti​ve​.jog​ger​.pl/​2​0​1​1​/​0​5​/​2​3​/​p​o​r​z​a​d​n​i​e​-​m​i​-​s​i​e​-​o​b​e​r​w​a​lo/

Autor napi­sał: ​„Po dogłęb­nym zapo­zna­niu się z pra­ca­mi auto­ra dzie­lę się moimi prze­my­śle­nia­mi i cze­kam na rów­nie cię­tą ripo­stę „, któ­rą napi­sa­łem i nie­zbyt cię­tą (nie to było celem) szko­da jed­nak, że ten­że autor nie tyl­ko sto­su­je tanie ery­stycz­ne chwy­ty w swo­ich wypo­wie­dziach (np. przy­rów­ny­wa­nie praw­dzi­wo­ści swo­ich tez do pew­no­ści odkry­cia Kopernika: ​„posta­no­wi­łem trwać przy mej teo­rii iż to jed­nak Ziemia krą­ży wokół Słońca” co jest dość duża zaro­zu­mia­ło­ścią, bo jeśli w kwe­stii ukła­du sło­necz­ne­go fak­tycz­nie nie mamy wąt­pli­wo­ści to moż­na je mieć w kwe­stii wywo­dów tegoż auto­ra), a w koń­cu usu­nął ze swo­jej stro­ny (dla­cze­go?) po pew­nym cza­sie moją krót­ką odpo­wiedź i link do jej peł­nej wer­sji na tym blogu:

https://it-consulting.pl//index.php/2011/05/24/polemika/