Tag: Product Owner

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: 

TDD – czy same testy to wymagania?

3 komentarze

Na nie­daw­no zakoń­czo­nej kon­fe­ren­cji beIT orga­ni­zo­wa­nej na Politechnice Gdańskiej przez Wydział Elektrotechniki, Telekomunikacji i Informatyki, wygło­si­łem refe­rat zaty­tu­ło­wa­ny Filozofia czy­li Aplikacja jako ele­ment biz­ne­so­wej rze­czy­wi­sto­ści (a nie gra kom­pu­te­ro­wa). Przesłanie tej pre­zen­ta­cji to:

Oprogramowanie bar­dzo czę­sto zastę­pu­je kon­struk­cje rze­czy­wi­ste takie jak zega­rek, kar­to­te­ka, biblio­te­ka, księ­gi han­dlo­we, pro­gra­ma­tor pral­ki i wie­le innych rze­czy. Dlatego ana­li­za powin­na pole­gać na zro­zu­mie­niu i udo­ku­men­to­wa­niu mecha­ni­zmu dzia­ła­nia ​„tego cze­goś” a nie jedy­nie na spi­sa­niu zewnętrz­nych oznak tego dzia­ła­nia i zarzą­dza­nie tym spisem. 

Referat miał lek­kie pod­ło­że filozoficzne :).

Ten arty­kuł nie będzie jed­nak powtó­rze­niem refe­ra­tu (wyżej link do pobra­nia). Do jego napi­sa­nia skło­ni­ło mnie jed­no z pytań z sali:

„Stosujemy TDD, czy to nie wystar­czy? Po co więc robić to o czym Pan mówi?”

Otóż odpo­wiedź brzmia­ła: TDD nie zastę­pu­je opi­su mecha­ni­zmu dzia­ła­nia. Innymi sło­wy: sam zestaw testów bar­dzo czę­sto nie sta­no­wi żad­nej infor­ma­cji o tym co ma powstać.

Niedawno pisa­łem:

Mechanizm jed­nak to nie zawsze tyl­ko same regu­ły, bar­dzo czę­sto (prak­tycz­nie zawsze dla nie­try­wial­nych sys­te­mów) powi­nien powstać dia­gram poka­zu­ją­cy wewnętrz­ną budo­wę (archi­tek­tu­rę) sys­te­mu, zestaw kom­po­nen­tów odpo­wie­dzial­nych za logi­kę reali­zo­wa­nia tych reguł (a jed­ną z nich jest np. ?treść doku­men­tów musi być zapa­mię­ty­wa­na z moż­li­wo­ścią przy­wo­ła­nia jej w dowol­nym momen­cie?). Taki dia­gram nazy­wa się Model dzie­dzi­ny. Jak go two­rzyć pisa­łem nap. w arty­ku­le Model dzie­dzi­ny jako wyma­ga­nie. (Źródło: Model To Mechanizm | | Jarosław Żeliński IT-Consulting)

A teraz jako przy­kład przy­to­czę dość zło­żo­ny kom­po­nent wie­lu sys­te­mów (pogru­bie­nie moje):

Jak dzia­ła sco­ring w Banku. Klient zain­te­re­so­wa­ny uzy­ska­niem kre­dy­tu wypeł­nia wnio­sek kre­dy­to­wy dla wybra­ne­go pro­duk­tu kre­dy­to­we­go. Dane z wnio­sku reje­stro­wa­ne są w sys­te­mie infor­ma­tycz­nym, któ­ry wspo­ma­ga pro­ces obsłu­gi wnio­sków kre­dy­to­wych w Banku. Podczas prze­twa­rza­nia wnio­sku nastę­pu­je wery­fi­ka­cja danych oraz zapy­ta­nie o auto­ma­tycz­ną reko­men­da­cję kre­dy­to­wą kie­ro­wa­ną do sil­ni­ka decy­zyj­ne­go. Silnik decy­zyj­ny wyko­nu­je zde­fi­nio­wa­ny w posta­ci reguł prze­twa­rza­nia algo­rytm sco­rin­go­wy: gro­ma­dzi dodat­ko­we infor­ma­cje z dostęp­nych źró­deł (np. Biuro Informacji Kredytowej SA, bazy nie­so­lid­nych klien­tów oraz dowo­dów zastrze­żo­nych ? MIG BR, MIG DZ), wyzna­cza wskaź­ni­ki, okre­śla przy­dział do klas ryzy­ka oraz wyli­cza oce­nę punk­to­wą w opar­ciu o kar­ty sco­rin­go­we. (Źródło: Scoring – meto­da oce­ny wia­ry­god­no­ści kre­dy­to­wej – ERP​-view​.pl – ERP, CRM, MRP, Business Intelligence, MRP)

Odpowiadając na pyta­nie o TDD powiem tak: nie da się ​„jed­no­znacz­nie zamó­wić” Systemu sco­rin­go­we­go, poda­jąc jedy­nie par­tię danych wej­ścio­wych i spo­dzie­wa­nych danych wyj­ścio­wych. Testy moż­na opra­co­wać zna­jąc mecha­nizm dzia­ła­nia tego sys­te­mu, two­rzy­my wte­dy repre­zen­ta­tyw­ny zestaw testów ​„pokry­wa­ją­cy cały kod”, o ile zna­my struk­tu­rę tego kodu (pro­jekt). Sam kod nie musi ist­nieć w momen­cie pro­jek­to­wa­nia tych testów, ale opra­co­wa­ny mecha­nizm tak, bo jak już pisa­łem ​„model dzie­dzi­ny to struk­tu­ra kodu reali­zu­ją­ce­go logi­kę biz­ne­so­wą wraz z metodami”.

Można tu powie­dzieć, że nie każ­dy sys­tem to zło­żo­ność sys­te­mu sco­rin­go­we­go. To praw­da, ale to co nazy­wa­my biz­ne­sem to regu­ły biz­ne­so­we, mecha­nizm dzia­ła­nia orga­ni­za­cji, a ten nigdy nie jest try­wial­ny. Reguły udzie­la­nia upu­stów, regu­ły przy­dzie­la­nia kre­dy­tów kupiec­kich, regu­ły nagra­dza­nia w sys­te­mach lojal­no­ścio­wych, regu­ły roz­li­cza­nia kosz­tów i wie­le, wie­le innych w pra­wie każ­dej fir­mie, orga­ni­za­cji czy insty­tu­cji publicznej.

Prawdopodobieństwo tego, że powsta­nie ​„popraw­ne” opro­gra­mo­wa­nie tyl­ko na pod­sta­wie zapi­su sze­re­gu ​„zewnętrz­nych obser­wa­cji” (bo czym są wyma­ga­nia jako zapis burz mózgów, ankiet, wywia­dów, itp.?) jest tym bar­dziej bli­skie zeru im bar­dziej orga­ni­za­cja ma zło­żo­ny mecha­nizm dzia­ła­nia (czy­li większość).

Zjawisko to jest zna­ne już od dzie­siąt­ków lat:

Problemy, w któ­rych roz­wią­za­niu mają pomóc budo­wa­ne zło­żo­ne sys­te­my są zwy­kle ?pro­ble­ma­mi zło­śli­wy­mi? (Rittel i Webber, 1973). ?Problem zło­śli­wy? to taki skom­pli­ko­wa­ny pro­blem, w któ­rym jest tak wie­le powią­za­nych ze sobą bytów, że nie ist­nie­je jego osta­tecz­na spe­cy­fi­ka­cja. Prawdziwy cha­rak­ter pro­ble­mu obja­wia się dopie­ro w mia­rę opra­co­wy­wa­nia rozwiązania.

Dlatego roz­wią­za­nie nie­try­wial­ne­go pro­ble­mu nie pole­ga na spe­cy­fi­ko­wa­niu tego co zna­my, a na pod­ję­ciu pró­by zapro­jek­to­wa­nia roz­wią­za­nia. Tym pro­jek­tem nie jest jed­nak ​„opis reak­cji syst­se­mu na bodź­ce” (czar­na skrzyn­ka). Projektem jest opi­sa­ny (jed­no­znacz­nie udo­ku­men­to­wa­ny) mecha­nizm dzia­ła­nia roz­wią­za­nia (bia­ła skrzynka).

Dlatego wyma­ga­nia spe­cy­fi­ku­je­my sku­tecz­nie poprzez pro­jekt pro­duk­tu a nie poprzez listę cech pro­duk­tu. Zamówienie dla deve­lo­pe­ra powin­no zawie­rać pro­jekt a nie wizu­ali­za­cję efek­tu koń­co­we­go, dokład­nie tak jak w bran­ży budow­la­nej, elek­tro­nicz­nej czy nawet mecha­nicz­nej (nawet wyko­naw­ca wału kor­bo­we­go dosta­je rysun­ki tech­nicz­ne a nie roz­wle­kłą proś­bę o faj­ny wał do samochodu).

Zilustrować to moż­na tak:

Wymagania

  1. Wymagania biz­ne­so­we zgła­sza biz­nes, są one for­mą opi­su i kon­se­kwen­cją pro­ble­mu biz­ne­so­we­go, wyma­ga­nia wobec roz­wią­za­nia to usta­lo­ny zakres projektu.
  2. Jeżeli jest to pro­jekt z obsza­ru inży­nie­rii opro­gra­mo­wa­nia, ma powstać opro­gra­mo­wa­nie opi­sa­ne z uży­ciem Przypadków uży­cia i Modelu dziedziny.
  3. Jak przejść od wyma­gań biz­ne­so­wych do Przypadków uży­cia i mode­lu dzie­dzi­ny i kto ma tego dokonać?

Kto ma opra­co­wać to ostat­nie? Programista? A na jakiej pod­sta­wie, sko­ro ​„nie zna tego biz­ne­su” (to pro­gra­mi­sta a nie ana­li­tyk biz­ne­so­wy)? Czy same przy­pad­ki uży­cia opi­su­ją regu­ły (mecha­nizm dzia­ła­nia) dzia­ła­nia syst­se­mu sco­rin­go­we­go czy sys­te­mu upu­stów w pro­mo­cji (to jed­na licz­ba, war­tość upu­stu, na fak­tu­rze)? Nie. Czy da się na bazie par­tii testów (czy­li skoń­czo­nej, ale z regu­ły nie­zu­peł­nej liście bodziec-odpo­wiedź) stwo­rzyć cokol­wiek? Mało kie­dy. Oznacza to, że wyma­ga­nia zebra­ne tyl­ko jako przy­pad­ki uży­cia ​„mało kie­dy” dają szan­sę na powsta­nie opro­gra­mo­wa­nia ​„za pierw­szym razem”, tu pro­to­ty­pów nie jest nigdy prze­wi­dy­wal­na. To dla­te­go meto­dy zwa­ne zwin­ny­mi, bazu­ją­ce wyłącz­nie na user sto­ry i pro­to­ty­pach, nada­ją się do pro­ble­mów pro­stych. Kompletnie nie spraw­dza­ją się w przy­pad­kach zło­żo­nych sys­te­mów, rozu­mia­nych jako zło­żo­ne mecha­ni­zmy. Te ostat­nie trze­ba nie raz ​„od zera” odkryć i opisać.

Paradygmat i metody obiektowe

Kluczem metod obiek­to­wych (i para­dyg­ma­tu obiek­to­we­go) jest her­me­ty­za­cja. Oznacza to, że zło­żo­ność obiek­tu ​„z zewnątrz” nie jest zna­na nigdy, nie ma zna­cze­nia wiel­kość obiek­tu (mała kla­sa czy mega-kom­po­nent), na zewnątrz postrze­ga­ny jest wyłącz­nie jako inter­fejs. Rozważania na począt­ku poka­za­ły, że odpo­wie­dzi na bodź­ce to ocze­ki­wa­ne (wyma­ga­ne) cechy roz­wią­za­nia, któ­re jed­nak nie deter­mi­nu­ją jego mechanizmu.

Oprogramowanie poma­ga­ją­ce w nauce tablicz­ki mno­że­nia do 100, może zawie­rać sta­tycz­ną tabli­cę zna­ną z ostat­nich stron sta­rych zeszy­tów, a może to być mecha­nizm będą­cy imple­men­ta­cją algo­ryt­mu mno­że­nia. Po pierw­sze zestaw testów, jak widać, nie deter­mi­nu­je żad­nej z tych metod imple­men­ta­cji. Po dru­gie spe­cy­fi­ka­cja w pierw­szym wypad­ku będzie ​„duża” (kosz­tow­na), w dru­gim bar­dzo pro­sta. Po trze­cie roz­wi­ja­nie (tablicz­ka mno­że­nia do 1000) opro­gra­mo­wa­nia w wer­sji z tabli­cą sta­tycz­ną będzie znacz­nie droż­sze niż pier­wot­ne wytwo­rze­nie wer­sji z mno­że­niem do 100. W dru­gim przy­pad­ku będzie pole­ga­ło wyłącz­nie na zdję­ciu blo­ka­dy mno­że­nia liczb więk­szych niż 10.

Tak więc co z tym TDD? Popatrzmy na to jak jest definiowane:

Co to jest Test Driven Development

Test Driven Development, czy­li TDD, to tech­ni­ka two­rze­nia opro­gra­mo­wa­nia ste­ro­wa­na przez testy. Tworzenie kodu skła­da się z wie­lo­krot­nie wyko­ny­wa­nych trzech głów­nych kroków:

  1. Stworzenie testu jed­nost­ko­we­go, któ­ry powi­nien być moż­li­wie naj­prost­szy, aby unik­nąć moż­li­wo­ści popeł­nie­nia błę­du w samym teście. Test ma spraw­dzać funk­cjo­nal­ność, któ­ra będzie imple­men­to­wa­na w kro­ku 2.
  2. Implementacja funk­cjo­nal­no­ści ? two­rzy­my funk­cjo­nal­ność, któ­rą chce­my zaim­ple­men­to­wać. Funkcjonalność ta powin­na speł­niać zało­że­nia testu jed­nost­ko­we­go, a wyko­na­nie testu jed­nost­ko­we­go powin­no koń­czyć się sukcesem.
  3. Refaktoryzacja, czy­li porząd­ki w stwo­rzo­nej funk­cjo­nal­no­ści. Ma to na celu upo­rząd­ko­wa­nie kodu, tak aby speł­nio­ne były stan­dar­dy. Czynności wyko­ny­wa­ne w tym kro­ku nie mogą zmie­nić wyni­ku testów.

Źródło: Test Driven Development

Pod poję­ciem funk­cjo­nal­ność tu rozu­mia­ny jest ​„ocze­ki­wa­ny efekt”, bo test nie jest niczym innym. Czy testy to są (zastę­pu­ją) pro­jekt wewnętrz­nej logi­ki? W przy­pad­kach try­wial­nych pew­nie tak, tam gdzie logi­ka jest pro­sta lub nie wystę­pu­je (przy­pad­ki uży­cia typu CRUD), albo tam gdzie ​„logi­ka” jest ​„powszech­nie zna­na” zna ją tak­że pro­gra­mi­sta (np. spo­sób dzia­ła­nia zegara).

Jednak sys­tem o nie­try­wial­nej logi­ce dzia­ła­nia, nie da się wyspe­cy­fi­ko­wać w posta­ci skoń­czo­nej (lub roz­sąd­nie krót­kiej) listy bodziec-efekt (np. przy­kła­do­wych par­tii gry w sza­chy). W jed­nej ze swo­ich ksią­żek Martin Fowler napi­sał, że żad­na ilość godzin fil­mu znad sto­łu bilar­do­we­go, jako wyma­ga­nie, nie da w efek­cie nawet namiast­ki dobrej gry w bilar­da. Ale sche­mat sto­łu, wymia­ry kul, kija oraz pra­wa fizy­ki rzą­dzą­ce ruchem kul, pozwo­lą na napi­sa­nie wręcz dosko­na­łej symu­la­cyj­nej gry. Taki opis to wła­śnie model dzie­dzi­ny gry w sza­chy, dokład­ny opis mecha­ni­zmu tego co dzie­je się na sto­le bilardowym.

Ostatnie pyta­nie brzmia­ło: Jak przejść od wyma­gań biz­ne­so­wych do Przypadków uży­cia i mode­lu dzie­dzi­ny i kto ma tego dokonać?

Odpowiedź na to pyta­nie zawie­ra pewien arty­kuł, napi­sa­ny w 2014 roku na nie­co inny temat:

…rolą ana­li­ty­ka biz­ne­so­we­go nie jest spi­sa­nie prze­bie­gu dzie­sią­tek wywia­dów i setek indy­wi­du­al­nych wyma­gań. Nie mają więk­sze­go sen­su doku­men­ty na dwa, trzy tysią­ce stron (nikt ich nie czy­ta!). Rolą ana­li­ty­ka biz­ne­so­we­go jest prze­ana­li­zo­wa­nie dostęp­nych doku­men­tów, infor­ma­cji, i stwo­rze­nie opi­su mecha­ni­zmu dzia­ła­nia orga­ni­za­cji oraz opi­su roz­wią­za­nia, narzę­dzia mogą­ce­go uspraw­nić dzia­ła­nie orga­ni­za­cji. Opisu zawie­ra­ją­ce­go regu­ły biz­ne­so­we, prze­twa­rza­ne infor­ma­cje (wzo­ry doku­men­tów) oraz listą usług jakie ma świad­czyć pla­no­wa­na do wdro­że­nia apli­ka­cja wraz z opi­sem tego, jak te usłu­gi mają być reali­zo­wa­ne (umie­jęt­no­ści, któ­re moż­na zauto­ma­ty­zo­wać). Sens mają więc zwię­złe opi­sy i mode­le mecha­ni­zmów dzia­ła­nia orga­ni­za­cji oraz opi­sy tego jakie infor­ma­cje i jak mają być prze­twa­rza­ne z uwzględ­nie­niem tego, że część tych prac nadal będą wyko­ny­wa­li ludzie. Takie jak regu­ły gry w sza­chy: waż­ne są dwie stro­ny opi­su reguł gry a nie set­ki stron opi­sów przy­kła­do­wych par­tii. (Źródło: Warsztaty Analityczne ? Czyli Malowanie Trawy | | Jarosław Żeliński IT-Consulting)

Tak więc robi­my to tak, jak w innych dzie­dzi­nach inży­nie­rii: ana­li­zu­je­my, pro­jek­tu­je­my i zle­ca­my wyko­na­nie (imple­men­ta­cję).

Na zakończenie

Kim jest, człon­kiem któ­re­go zespo­łu jest (powi­nien być) pro­jek­tant? Przewrotnie odpo­wiem, że prak­ty­ka poka­zu­je, że – z powo­du ryzy­ka pro­jek­to­we­go – wyko­naw­ca nie powi­nien sam sobie sta­wiać wyma­gań. To dla­te­go zło­żo­ne i ryzy­kow­ne pro­jek­ty mają wydzie­lo­ną rolę ana­li­ty­ka pro­jek­tan­ta, nie jest to czło­nek zespo­łu biz­ne­su ani deve­lo­pe­ra bo obie te stro­ny mają sprzecz­ne inte­re­sy (zakres i koszt). W bran­ży budow­la­nej jest to Biuro Projektowe (tu archi­tekt), trze­ci nie­za­leż­na rola, poza inwe­sto­rem i wyko­naw­cą (z uwa­gi na ryzy­ko, pra­wo budow­la­ne zabra­nia łącze­nia jakiej­kol­wiek z tych trzech ról). W meto­dy­kach takich jak SCRUM, jest to Product Owner, i z powyż­sze­go powo­du nie jest dobrze gdy jest to ​„czło­wiek developera”.

Architektura… najpierw a nie na końcu

Dodaj komentarz

Szperałem w sie­ci szu­ka­jąc infor­ma­cji o archi­tek­tu­rze i micro­se­rvi­sach, a wpa­dłem na to:

… com­mu­ni­ca­tion betwe­en two dif­fe­rent softwa­re modu­les is pro­por­tio­nal to the com­mu­ni­ca­tion betwe­en the desi­gners and deve­lo­pers of the­se modu­les. Conway?s law expo­ses the vul­ne­ra­bi­li­ty in mono­li­ths as they grow in size. Micro-servi­ces may not be the best, but bet­ter than mono­li­ths for the con­tem­po­ra­ry web based appli­ca­tions. (Źródło: Micro-Services: A com­pa­ri­son with Monoliths | My Blog)

To ​„pra­wo” wyja­śnia dla­cze­go powsta­ją złe inter­fej­sy a nawet zła archi­tek­tu­ra: z regu­ły dla­te­go, że to – archi­tek­tu­ra – jest lep­szym lub gor­szym kom­pro­mi­sem pomię­dzy zespo­ła­mi pro­gra­mi­stów, ich obcią­że­nia, krót­kich ter­mi­nów itp. Obserwuję to dość czę­sto w orga­ni­za­cji pra­cy deve­lo­pe­rów. O pro­jek­to­wa­niu inter­fej­sów a tak­że o tym, jak ​„roz­dzie­lać” odpo­wie­dzial­no­ści pomię­dzy kom­po­nen­ty, dobrych prak­ty­kach, dość cie­ka­we pisał Fowler w swo­im artykule:

Tell-Don?t‑Ask is a prin­ci­ple that helps people remem­ber that object-orien­ta­tion is abo­ut bun­dling data with the func­tions that ope­ra­te on that data. It reminds us that rather than asking an object for data and acting on that data, we sho­uld inste­ad tell an object what to do. This enco­ura­ges to move beha­vior into an object to go with the data. (źr. TellDontAsk).

Jednak, żeby powsta­ła taka ​„dobra archi­tek­tu­ra”, ktoś ​„ponad zespo­łem deve­lo­pe­rów” powi­nien zapro­jek­to­wać archi­tek­tu­rę: kom­po­nen­ty z ich odpo­wie­dzial­no­ścia­mi i inter­fej­sy mię­dzy nimi.

Typowym pro­ble­mem jaki napo­ty­kam, nie tyl­ko w dużych pro­jek­tach dla ​„budże­tów­ki”, jest archi­tek­tu­ra będą­ca efek­tem prze­py­cha­nek, poli­ty­ki, wal­ki o ​„men­dej­sy”, czy­li o to któ­ry dostaw­ca (albo wewnętrz­ny zespół) dosta­nie więk­szy budżet. To naj­gor­sze i nie­ste­ty nie raz spo­ty­ka­ne meto­dy budo­wy architektury.

Jak to robić dobrze? Idąc za Fowlerem, pod­sta­wą budo­wy (usta­la­nia) gra­ni­cy odpo­wie­dzial­no­ści kom­po­nen­tu jest ​„gra­ni­ca kon­tek­stu”. Można to przed­sta­wić tak:

Powyżej poka­za­no wynik ana­li­zy, mamy tu model poję­cio­wy. Widać, że pew­ne poję­cia (doce­lo­wo kla­sy, ich ope­ra­cje i atry­bu­ty) są dość gęsto powią­za­ne, inne luź­no. Granice pomię­dzy kom­po­nen­ta­mi powin­no budo­wać się tak, by sil­nie powią­za­ne ele­men­ty były w jed­nym kom­po­nen­cie (nigdy nie roz­dzie­laj rodzi­ny) a inter­fej­sy mię­dzy nimi były jak naj­prost­sze. Zasada ​„tell don’t ask” (mów co chcesz dostać a nie dopy­tuj się o szcze­gó­ły) ozna­cza, że kom­po­nent powi­nien żądać całe­go ele­men­tu i same­mu sko­rzy­stać, nawet tyl­ko z czę­ści, tego co dostał, zamiast deta­licz­nie pro­sić o dro­bia­zgi. Innymi sło­wy nie­za­leż­nie od tego czy w danym momen­cie potrze­bu­je­my tyl­ko war­to­ści kon­kret­nej fak­tu­ry, danych nabyw­cy czy fak­tycz­nie całej jej zawar­to­ści, zawsze żąda­my całej fak­tu­ry. Dzięki temu inter­fejs (API) jest prost­sze, licz­ba wywo­łań API jest zawsze mała. Powyższy przy­pa­dek zaowo­cu­je poniż­szym podzia­łem na komponenty:

ModelDziedzinyGraniceKontekstuKomponentu

Metoda ta i podej­ście (jako dobra prak­ty­ka), i u Fowlera (cyto­wa­ny na począt­ku autor arty­ku­łu Tell don’t ask) i u Evansa (autor wzor­ca Domain Driven Design) nazy­wa­na jest ​„boun­ded con­text” (gra­ni­ca kon­tek­stu, rodzi­na zawsze razem i tyl­ko jed­na rodzi­na w jed­nym miesz­ka­niu). Dzięki temu uzy­sku­je­my bar­dzo dobry, przy oka­zji zgod­ny z zasa­dą „[[Open Close Pryncypia]]”, model archi­tek­tu­ry, któ­ry pozwa­la zle­cić kom­po­nen­ty do wyko­na­nia, defi­niu­jąc wyłącz­nie opra­co­wa­ne już inter­fej­sy, kolej­ność ich (kom­po­nen­tów) wyko­na­nia nie ma zna­cze­nia dla całości.

Przy oka­zji ujaw­nia się ​„zło” jakie wyrzą­dza budo­wa­nie zło­żo­ne­go opro­gra­mo­wa­nia na bazie inte­gra­cji poprzez współ­dzie­le­nie danych:

ModelDziedzinyIntegracjaPrzezWspoldzielnieDanych

Komponenty są sil­nie od sie­bie uza­leż­nio­ne (współ­dzie­lo­na baza danych w mode­lu rela­cyj­nym), nie da się two­rzyć (kodo­wać) tych kom­po­nen­tów nie­za­leż­nie od sie­bie, bo trze­ba uzgad­niać a potem uznać, wspól­ny model danych. Ingerencja w jaki­kol­wiek kom­po­nent z regu­ły ozna­cza inge­ren­cję w całą aplikację.

Dzieląc sys­tem na nie­za­leż­ne kom­po­nen­ty (każ­dy kom­po­nent sam zarzą­dza swo­imi dany­mi) , usta­la­my inte­gra­cję z uży­ciem inter­fej­sów a nie współ­dzie­ląc dane, z cze­go cał­ko­wi­cie rezygnujemy:

ModelDziedzinyWspolpracaKomponentowDziedzinowych
To jest powód dla któ­re­go, w dobrych fir­mach deve­lo­per­skich klu­czo­wą rolę peł­ni archi­tekt. Na pozio­mie logi­ki biz­ne­so­wej, w zasa­dzie jest nim – takim archi­tek­tem – ana­li­tyk biz­ne­so­wy-pro­jek­tant, któ­ry po zakoń­cze­niu eta­pu ana­li­zy i pro­jek­to­wa­nia, peł­ni rolę „[[pro­duct owne­ra]]”, pro­wa­dzą­ce­go nad­zór autor­ski i zarzą­dza­nie zmia­ną wymagań.

Tak więc archi­tek­tu­ra powin­na być efek­tem głę­bo­kiej ana­li­zy i pro­jek­to­wa­nia z testa­mi, dopie­ro potem powin­na się stać – być może każ­dy kom­po­nent osob­no – mate­ria­łem do zle­ce­nia dla deve­lo­pe­rów. Najgorszy wariant to podział na kom­po­nen­ty z pomo­cą nego­cja­cji, poli­ty­ki i wal­ki o budżet. 

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.