Mało który deweloper używa UMLa zgodnie ze specyfikacją…

Od cza­su do cza­su wpa­da­ją mi do skrzyn­ki ema­il niu­slet­te­ry”, któ­re gdzieś tam cza­sem zama­wiam, głów­nie z powo­dów poznaw­czych. Oto jeden z nich…

Nie jest tajem­ni­cą, że na ryn­ku mamy róż­ne meto­dy pra­cy i wszyst­kie mają swo­ich zwo­len­ni­ków i prze­ciw­ni­ków czy może raczej kry­ty­ków. Tym razem przed­mio­tem bada­nia” był spo­sób opi­sa­nia pro­ble­mu i wnio­ski jakie autor wyciągnął.

Czytaj dalej… Mało któ­ry dewe­lo­per uży­wa UMLa zgod­nie ze spe­cy­fi­ka­cją…”

Zwinne projektowanie interfejsu użytkownika

W ostat­nim arty­ku­le zwra­ca­łem uwa­gę mię­dzy inny­mi na bar­dzo waż­ny ele­ment ana­li­zy i pro­jek­to­wa­nia jakim jest abs­tra­ho­wa­nie od deta­li, ponieważ: 

…ana­li­tyk musi abs­tra­ho­wać od wszel­kich deta­li, bez tego pro­jekt zosta­nie już na samym począt­ku ?zabi­ty? ich ilo­ścią. [1]

Nieco wcze­śniej (2013 r.) pisa­łem o tym, kie­dy uzgad­niać deta­le, któ­re i gdzie one są: 

Cała logi­ka biz­ne­so­wa jest wyko­ny­wa­na wewnątrz apli­ka­cji (infor­ma­cje o ewen­tu­al­nych błę­dach poja­wią się po zatwier­dze­niu for­mu­la­rza), np. upust może być spraw­dzo­ny (albo nali­czo­ny) dopie­ro po skom­ple­to­wa­niu danych wyma­ga­nych do jego wyli­cze­nia, czy­li będzie to kil­ka róż­nych pól (naj­mniej dwa :)). Bywa, że do wyli­cze­nia cze­goś potrzeb­ne będą dane nie wpro­wa­dza­ne do danej for­mat­ki fak­tu­ry, np. sal­do klien­ta. [2]

Tym razem kil­ka słów o tym jak skom­pli­ko­wać i zabić pro­jekt już pierw­sze­go dnia. Jednym z naj­bar­dziej ryzy­kow­nych spo­so­bów roz­po­czy­na­nia pro­jek­tu jest roz­po­czy­na­nie od kon­sul­ta­cji z użyt­kow­ni­kiem w kwe­stii inter­fej­su użyt­kow­ni­ka. Prowadzi to do sytu­acji, w któ­rej jesz­cze nie mamy żad­ne­go poję­cia o logi­ce biz­ne­so­wej i archi­tek­tu­rze apli­ka­cji, a już dekla­ru­je­my to jak będzie się ona komu­ni­ko­wa­ła z użyt­kow­ni­kiem (cie­ka­we na jakiej podstawie?). 

Do napi­sa­nia tego arty­ku­łu skło­nił mnie ten wpis:

The role of design still puz­zles many agi­le teams I work with. When sho­uld the design acti­vi­ties take pla­ce? Who sho­uld car­ry them out? How are design deci­sions best cap­tu­red? This blog tries to answer the questions by discus­sing a user-cen­tric, ite­ra­ti­ve, and col­la­bo­ra­ti­ve design pro­cess for Scrum and Kanban teams. [3]

Autor poka­zu­je jak wal­czy” ze zło­żo­no­ścią na tym eta­pie, ja pra­gnę zasu­ge­ro­wać by do tej zło­żo­no­ści na tym eta­pie po pro­stu nie dopusz­czać. Powyższy dia­gram poka­zu­je z czym wal­czy ana­li­tyk, któ­ry dopro­wa­dzi do zebra­nia wyrwa­nych z kon­tek­stu (tak, nie ma mode­lu logi­ki więc dys­ku­sje o GUI są ode­rwa­ne od kon­tek­stu) wyma­gań” (histo­ryj­ki użyt­kow­ni­ka, lewa kolum­na tabli­cy Story Area), któ­rych zama­wia­ją­cy może naopo­wia­dać” bar­dzo dużo.

A jak ina­czej? Pomoże nam sto­so­wa­nie wzor­ców archi­tek­to­nicz­nych. Są one od lat dostęp­ne w więk­szo­ści fra­me­wor­ków (szko­da, że bar­dzo czę­sto deve­lo­pe­rzy je igno­ru­ją). Poniżej pro­sty, abs­trak­cyj­ny model kla­sycz­ne­go wzor­ca MVC.

W archi­tek­tu­rze wydzie­la się kom­po­nen­ty (sepa­ro­wa­nie odpo­wie­dzial­no­ści): odpo­wie­dzial­ny za obsłu­gę dia­lo­gu z użyt­kow­ni­kiem (View), odpo­wie­dzial­ny za tech­no­lo­gie, jakość, bez­pie­czeń­stwo, ste­ro­wa­nie itp. (Controler) oraz odpo­wie­dzial­ny za (całą a nie tyl­ko dane!) logi­kę biz­ne­so­wą (Model). 

Zarządzanie zło­żo­no­ścią pole­ga tu na tym, by na począt­ku ana­li­zy i pro­jek­to­wa­nia abs­tra­ho­wać cał­ko­wi­cie od deta­li GUI! (a dokład­nie od całej tech­no­lo­gii czy­li ele­men­tów View i Contoler). Kluczową odpo­wie­dzial­no­ścią apli­ka­cji jest reali­za­cja okre­ślo­nej logi­ki biz­ne­so­wej. Na tym eta­pie powi­nien powstać model przy­pad­ków uży­cia rozu­mia­ny jako pro­sty dia­log pomię­dzy użyt­kow­ni­kiem a apli­ka­cją, tu celem jest uchwy­ce­nie klu­czo­wych wyma­gań jaki­mi są wyma­ga­ne usłu­gi apli­ka­cyj­ne reali­zo­wa­ne przez apli­ka­cję oraz opra­co­wa­nie wewnętrz­nej archi­tek­tu­ry – Modelu, któ­ra te usłu­gi zre­ali­zu­je. Dopiero po prze­te­sto­wa­niu całej logi­ki biz­ne­so­wej na mode­lach, war­to się zabie­rać na kom­pli­ko­wa­nie pro­jek­tu poprzez opra­co­wa­nie deta­li GUI, ste­ro­wa­nia, bez­pie­czeń­stwa itp.. Postępowanie takie umoż­li­wia wzo­rzec archi­tek­to­nicz­ny MVVM opra­co­wa­ny ponad 10 lat temu. Wzorzec ten wpro­wa­dza dodat­ko­wy kom­po­nent pomię­dzy kom­po­nen­ty View i Model: View-Model, któ­ry reali­zu­je logi­kę dia­lo­gu GUI-użyt­kow­nik. Dzięki temu może­my wydzie­lić etap pra­cy nad GUI, jako osob­ny w pro­jek­cie, któ­ry zre­ali­zu­je (póź­niej) tak zwa­ny UX desi­gner”, a deve­lo­per zamie­ni pier­wot­nie abs­trak­cyj­ny kom­po­nent View na imple­men­ta­cje View-View Model”.

Bardzo dobry opis tego podejścia:

W przy­pad­ku war­stwy pre­zen­ta­cji moż­na wyko­rzy­stać m. in. nastę­pu­ją­ce roz­wią­za­nia: MVC, MVP czy Model-View-ViewModel. Ze wzglę­du na mecha­nizm wią­zań (bin­ding), pro­gra­mi­stom WPF oraz Silverlight, pole­ca­ny jest wzo­rzec MVVM ? jest to tech­no­lo­gia umoż­li­wia­ją­ca bar­dzo łatwą imple­men­ta­cję wzor­ca. […] …po co utrud­niać sobie zada­nie poprzez wyko­rzy­sty­wa­nie MVVM, zamiast pisać apli­ka­cję w kla­sycz­ny spo­sób (za pomo­cą code-behind)? W koń­cu wdro­że­nie prak­tycz­nie każ­de­go wzor­ca pro­jek­to­we­go wyma­ga tro­chę więk­szych począt­ko­wych nakła­dów pra­cy.

Podejście Code-Behind (auto­no­mo­us view ? AV) ma poważ­ną wadę ? nie gwa­ran­tu­je ela­stycz­no­ści oraz testo­wal­no­ści. Podsumowując, wpro­wa­dze­nie wzor­ca [MVVM, przy­pis auto­ra] umożliwia:

  • nie­za­leż­ność logi­ki od spo­so­bu wyświe­tla­nia danych,
  • nie­za­leż­ność kodu od tech­no­lo­gii, w któ­rej wyko­na­na jest war­stwa prezentacji,
  • wyko­ny­wa­nie testów ? za pomo­cą MVVM czy MVP moż­li­we jest wyko­na­nie testów zauto­ma­ty­zo­wa­nych (np. jednostkowych),
  • łatwą zamia­nę wido­ków (brak sztyw­nych powią­zań mię­dzy wido­kiem a logi­ką). [4]

(Tak: sto­so­wa­nie wzor­ców pod­no­si począt­ko­wą pra­co­chłon­ność ale zwra­ca się z nawiąz­ką w dal­szych cyklach życia pro­jek­tu.) Strukturę i histo­rię powsta­nia tej archi­tek­tu­ry zain­te­re­so­wa­ni mogą poznać tak­że tu: 

Model View View Model (MVVM) 
In 2005, John Gossman, Architect at Microsoft, unve­iled the Model-View-ViewModel (MVVM) pat­tern on his blog. MVVM is iden­ti­cal to Fowler?s Presentation Model, in that both pat­terns featu­re an abs­trac­tion of a View, which con­ta­ins a View?s sta­te and beha­vior. Fowler intro­du­ced Presentation Model as a means of cre­ating a UI plat­form-inde­pen­dent abs­trac­tion of a View, whe­re­as Gossman intro­du­ced MVVM as a stan­dar­di­zed way to leve­ra­ge core featu­res of WPF and Silverlight to sim­pli­fy the cre­ation of user inter­fa­ces. MVVM is a spe­cia­li­za­tion of the more gene­ral PM pat­tern, tailor-made for the WPF and Silverlight plat­forms to leve­ra­ge core featu­res of WPF such as data bin­ding, com­mands , templates.

This dia­gram take from MSDN depicts MVVM Pattern in action.

image[5]

Tak więc ana­li­zę i pro­jek­to­wa­nie war­to zacząć od logi­ki i szkie­le­tu archi­tek­tu­ry, a ta to przede wszyst­kim Model (dzie­dzi­ny) sys­te­mu czy­li kom­plet­na logi­ka biz­ne­so­wa (utoż­sa­mia­nie mode­lu dzie­dzi­ny z rela­cyj­ną bazą danych to poważ­ny błąd i nie­po­ro­zu­mie­nie). Po upo­ra­niu się z tym eta­pem pro­jek­tu ma sens opra­co­wy­wa­nie deta­li komu­ni­ka­cji z użyt­kow­ni­kiem, bo dopie­ro teraz zna­my wyma­ga­nia i ogra­ni­cze­nia logi­ki biz­ne­so­wej. Odkrywanie ich dopie­ro na eta­pie pro­to­ty­po­wa­nia to sta­now­czo za póź­no, bo gene­ru­je to ogrom­ne kosz­ty cyklicz­ne­go refak­to­rin­gu kodu (albo kod szyb­ko sta­je się bry­łą błota”). 

Bardzo czę­sto sły­szę, że klient chce jak naj­szyb­ciej coś zoba­czyć. Rzecz w tym, że jeże­li się na to zgo­dzi­my, powsta­je i jest akcep­to­wa­na masa tak zwa­nych poboż­nych życzeń”, a klient bar­dzo szyb­ko się przy­wią­zu­je do tego co zoba­czył na pre­zen­ta­cji (i nie chce odpu­ścić). W efek­cie two­rzy się spi­ra­la żądań, testów i popra­wek, któ­re szyb­ko prze­kształ­ca­ją agi­le” w poraż­kę budże­tu i har­mo­no­gra­mu. Praktyka poka­zu­je, że budżet zawsze ma limit, dla­te­go bar­dzo wie­le takich pro­jek­tów koń­czy albo w koszu na śmie­ci albo efek­ty sta­no­wią tyl­ko namiast­kę tego co opi­sy­wa­ła pier­wot­na wizja. Jeżeli zaś zacznie­my od jądra sys­te­mu a na koniec zosta­wi­my sobie maki­jaż” jakim jest GUI, szan­sa na suk­ces będzie znacz­nie więk­sza. Problem pole­ga na tym, że moda na user-cen­tric, ite­ra­ti­ve, and col­la­bo­ra­ti­ve design” jest sil­na mimo tego, że jest przy­czy­ną wie­lu porażek. 

Tak więc odpo­wiedź na pyta­nie jak pora­dzić sobie z życze­nia­mi biz­ne­su, brzmi: nie dopusz­czać do ich wyar­ty­ku­ło­wa­nia :). Projektowanie i two­rze­nie samo­cho­du roz­po­czy­na się od pod­wo­zia i napę­du a nie od deski rozdzielczej…

Bibliografia

[1]
J. Zelinski, ?Model czy abs­trak­cja?, Jarosław Żeliński IT-Consulting, 22-wrz-2017. [Online]. Available: https://it-consulting.pl//2017/09/22/model-czy-abstrakcja/. [Udostępniono: 25-wrz-2017]
[2]
J. Zelinski, ?Gdzie są te cho­ler­ne szcze­gó­ły?, Jarosław Żeliński IT-Consulting, 18-cze-2014. [Online]. Available: https://it-consulting.pl//2014/06/18/gdzie-sa-te-cholerne-szczegoly/. [Udostępniono: 25-wrz-2017]

Agile w PZP

Polecam lek­tu­rę cie­ka­wej Opinii Prawnej kan­ce­la­rii Maruta Wachta sp. j.. (dalej odpo­wied­nio Opinia i Kancelaria) na temat MOŻLIWOŚCI I SPOSOBU WYKORZYSTANIA METODYKI AGILE W PROJEKTACH INFORMATYCZNYCH REALIZOWANYCH Z ZASTOSOWANIEM USTAWY ? PRAWO ZAMÓWIEŃ PUBLICZNYCH.

Kluczowe pojęcia i definicje

Zanim się odnio­sę do Opinii, naj­pierw kli­ka słów na temat zwin­ne­go reali­zo­wa­nia pro­jek­tów. Jak rzad­ko, posłu­żę się Wikipedią, gdyż poję­cie meto­dy zwin­ne” nie ma ści­słej defi­ni­cji, Manifest Agile zaś jest na tyle ogól­ny, że nie jest moż­li­we uży­cie go jako defi­ni­cji. Po dru­gie Wikipedia jest powszech­nie przy­wo­ły­wa­na jako źró­dło w śro­do­wi­skach zwią­za­nych ze sto­so­wa­niem metod zwin­nych dla­te­go uzna­łem, że defi­ni­cje tam umiesz­cza­ne będą tu naj­bar­dziej ade­kwat­ne. Przypomnę, że oso­bi­ście nie uży­wam poję­cia agi­le” w swo­ich pro­jek­tach, gdyż uwa­żam, że obec­ne słow­nic­two i meto­dy w obsza­rze inży­nie­rii zupeł­nie wystar­czą i są znacz­nie pre­cy­zyj­niej­sze i od lat sto­so­wa­ne z powo­dze­niem. Poniżej pró­ba upo­rząd­ko­wa­nia tych pojęć na potrze­by dal­szych rozważań.

Za Wikipedią (cyta­ty):

Programowanie zwin­ne (ang. agi­le softwa­re deve­lop­ment) ? gru­pa metod wytwa­rza­nia opro­gra­mo­wa­nia opar­te­go na pro­gra­mo­wa­niu ite­ra­cyj­no-przy­ro­sto­wym, powsta­łe jako alter­na­ty­wa do tra­dy­cyj­nych metod typu water­fall. Najważniejszym zało­że­niem meto­dyk zwin­nych jest obser­wa­cja, że wyma­ga­nia odbior­cy (klien­ta) czę­sto ewo­lu­ują pod­czas trwa­nia pro­jek­tu. Oprogramowanie wytwa­rza­ne jest przy współ­pra­cy samo­za­rzą­dzal­nych zespo­łów, któ­rych celem jest prze­pro­wa­dza­nie pro­ce­sów wytwa­rza­nia opro­gra­mo­wa­nia. Pojęcie zwin­ne­go pro­gra­mo­wa­nia zosta­ło zapro­po­no­wa­ne w 2001 w Agile Manifesto.

Komentarz: rynek się zmie­nia w coraz szyb­szym tem­pie, oto­cze­nie ryn­ko­we wpły­wa na orga­ni­za­cje, te zaś pod jego wpły­wem zmie­nia­ją swo­je stra­te­gie i tak­ty­ki. Jeżeli opro­gra­mo­wa­nie jest ich narzę­dziem pra­cy, to zmia­ny te prze­nio­są się wyma­ga­nia wobec tego opro­gra­mo­wa­nia. Jest to nie­unik­nio­ne. Nie jest to ewo­lu­cja wyma­gań” a ich natu­ral­ny cykl życia (pomi­jam tu kwe­stie zmia­ny pomy­słów po stro­nie zama­wia­ją­ce­go, ale to inny temat).

Generalnie gru­pa meto­dyk opar­ta jest na zdy­scy­pli­no­wa­nym zarzą­dza­niu pro­jek­tem, któ­re zakła­da czę­ste inspek­cje wyma­gań i roz­wią­zań wraz z pro­ce­sa­mi adap­ta­cji (zarów­no spe­cy­fi­ka­cji jak i opro­gra­mo­wa­nia). Najczęściej znaj­du­ją zasto­so­wa­nie w małych zespo­łach pro­gra­mi­stycz­nych, w któ­rych nie wystę­pu­je pro­blem komu­ni­ka­cji, przez co nie trze­ba two­rzyć roz­bu­do­wa­nej doku­men­ta­cji kodu. Kolejne eta­py wytwa­rza­nia opro­gra­mo­wa­nia zamknię­te są w ite­ra­cjach, w któ­rych za każ­dym razem prze­pro­wa­dza się testo­wa­nie wytwo­rzo­ne­go kodu, zebra­nie wyma­gań, pla­no­wa­nie roz­wią­zań itd. Nastawiona są na szyb­kie wytwa­rza­nie opro­gra­mo­wa­nia wyso­kiej jakości.

Niestety ten frag­ment opi­su agi­le mówią­cy o dys­cy­pli­nie i czę­stym prze­glą­da­niu sta­nu prac samo­rza­rzą­dzal­nych zespo­łów przy­wo­dzi na myśl sta­ry żart o tym, że her­ba­ta robi się słod­ka nie od cukru a od mie­sza­nia. Tu waż­ne jest sło­wo pla­no­wa­nie” a tak­że zebra­nie wyma­gań”. Minus jest taki, że zbie­ra­nie ite­ra­cyj­ne wyma­gań ozna­cza, że odkry­wa­ne są one dopie­ro w toku reali­za­cji projektu.

Skład zespo­łów jest zazwy­czaj wie­lo­funk­cyj­ny oraz samo­za­rzą­dzal­ny, bez zasto­so­wa­nia jakiej­kol­wiek hie­rar­chii orga­ni­za­cyj­nej. Członkowie zespo­łu bio­rą odpo­wie­dzial­ność za zada­nia posta­wio­ne w każ­dej ite­ra­cji. Sami decy­du­ją jak osią­gnąć posta­wio­ne cele.

Metodyki zwin­ne dużą wagę przy­wią­zu­ją do bez­po­śred­niej komu­ni­ka­cji mię­dzy człon­ka­mi zespo­łu, mini­ma­li­zu­jąc potrze­bę two­rze­nia doku­men­ta­cji. Jeśli człon­ko­wie zespo­łu są w róż­nych loka­li­za­cjach, to pla­nu­je się codzien­ne kon­tak­ty za pośred­nic­twem dostęp­nych kana­łów komu­ni­ka­cji (wide­okon­fe­ren­cja, e‑mail itp.).

Tu powa­ża­ną wadą jest nie­chęć” do two­rze­nia doku­men­tów. Skutkuje to ogrom­ny­mi pro­ble­ma­mi z odtwa­rza­niem usta­leń” histo­rycz­nych (już choć­by cof­nię­cie się o jed­ną ite­ra­cję wstecz bywa pro­ble­mem, bo nie ma śla­du po tre­ści usta­leń, a pamięć ludz­ka jest jed­nak ograniczona).

Częstym błę­dem wystę­pu­ją­cym u osób i zespo­łów sto­su­ją­cych meto­dy­kę agi­le jest nad­in­ter­pre­ta­cja jej zało­żeń i cał­ko­wi­cie błęd­ne pomi­ja­nie bar­dzo waż­nych eta­pów pro­jek­tu tj. zbie­ra­nia wyma­gań”, a następ­nie na ich pod­sta­wie ana­li­zy” oraz pla­no­wa­nia”. (Źródło: Programowanie zwin­ne ? Wikipedia, wol­na ency­klo­pe­dia

Tu, mam nadzie­ję, auto­rzy mie­li jed­nak na myśli jakieś dokumenty.….

Tak więc są pod­sta­wy by uznać, że obec­nie meto­dy zwinne:

  1. znaj­du­ją zasto­so­wa­nie w małych zespo­łach programistycznych.
  2. człon­ko­wie zespo­łu sami decy­du­ją o spo­so­bie reali­za­cji projektu.
  3. są eta­py zbie­ra­nia wyma­gań, ana­li­zy, pla­no­wa­nia jed­nak nie spre­cy­zo­wa­no co i w jakiej posta­ci zawie­ra­ją te doku­men­ty”.
  4. opro­gra­mo­wa­nie powsta­je meto­dą iteracyjno-przyrostową.
  5. nadal raczej”, poza kodem, nie powsta­je żad­na dokumentacja.

Kolejny waż­ny ter­min to SCRUM:

Scrumite­ra­cyj­ne i przy­ro­sto­we ramy postę­po­wa­nia zgod­ne z mani­fe­stem Agile. W ramach tego postę­po­wa­nia roz­wój pro­duk­tu podzie­lo­ny jest na mniej­sze, trwa­ją­ce mak­sy­mal­nie jeden mie­siąc kalen­da­rzo­wy ite­ra­cje, zwa­ne sprin­ta­mi nastę­pu­ją­cy­mi bez­po­śred­nio po sobie. Po każ­dym sprin­cie zespół pra­cu­ją­cy nad roz­wo­jem pro­duk­tu jest w sta­nie dostar­czyć dzia­ła­ją­cą jego wer­sję. Scrum jest czę­sto sto­so­wa­ny pod­czas two­rze­nia i roz­wi­ja­nia opro­gra­mo­wa­nia, nie jest jed­nak ogra­ni­czo­ny tyl­ko do tej dzie­dzi­ny. Ogólne zało­że­nia podej­ścia zosta­ły zapre­zen­to­wa­ne przez Hirotakę Takeuchiego i Ikujiro Nonakę w arty­ku­le The New Product Development Game, opu­bli­ko­wa­nym w Harvard Business Review w stycz­niu 1986 roku. Definicja Scruma w zasto­so­wa­niu do pro­duk­cji opro­gra­mo­wa­nia zosta­ła sfor­ma­li­zo­wa­na przez Kena Schwabera w 1995. Scrum czę­sto omył­ko­wo nazy­wa­ny jest meto­dy­ką. (Źródło: Scrum ? Wikipedia, wol­na ency­klo­pe­dia).

SCRUM to ramy postę­po­wa­nia”, nie jest to meto­dy­ka” (meto­dy­ka to zbiór zasad doty­czą­cych spo­so­bów wyko­ny­wa­nia jakiejś pra­cy lub try­bu postę­po­wa­nia pro­wa­dzą­ce­go do okre­ślo­ne­go celu”), jed­nak sta­no­wi sobą opis zarzą­dza­nia reali­za­cją projektu.

Popatrzmy na inży­nie­rię opro­gra­mo­wa­nia jak na inży­nie­rię w ogó­le. Generalnie coś co ma kon­struk­cję, archi­tek­tu­rę, mecha­nizm dzia­ła­nia i funk­cjo­nal­ność jest pro­duk­tem inży­nie­rii”. Słownik j.. pol­skie­go mówi, że:

inży­nie­ria: pro­jek­to­wa­nie i kon­stru­owa­nie obiek­tów oraz urzą­dzeń technicznych

Tak więc mamy dwa klu­czo­we eta­py pro­ce­su two­rze­nia: pro­jek­to­wa­nie i kon­stru­owa­nie. Podsumowując mamy pra­wo uznać, że two­rze­nie opro­gra­mo­wa­nia, jeże­li uzna­my ten pro­ces za inży­nie­rię opro­gra­mo­wa­nia, skła­da się z pro­jek­to­wa­nia i kon­stru­owa­nia (kodo­wa­nia).

W 2013 roku pisałem:

Pamiętajmy, że zarzą­dza­nie zakre­sem pro­jek­tu jest tym kosz­tow­niej­sze im wię­cej szcze­gó­łów ten zakres posia­da. Projekt o 30 wyma­ga­niach vs. pro­jekt o 300 wyma­ga­niach to nie pro­jekt o 10-krot­nie więk­szym kosz­cie, ta róż­ni­ca będzie znacz­nie więk­sza (pomi­jam to, jak w ogó­le zde­fi­niu­je­my wyma­ga­nie) (Źródło: Mega pro­jek­ty czy­li jak zjeść sło­nia | | Jarosław Żeliński IT-Consulting).

Artykuł ten zawie­ra tak­że dwa dia­gra­my: tak zwa­ny wodo­spa­do­wy oraz ite­ra­cyj­no-przy­ro­sto­wy, spo­sób zarzą­dza­nia zakre­sem projektu.

Projekt mają­cy jeden etap ana­li­zy i projektowania.
Projekt w któ­rym na począt­ku pro­jek­tu­je się archi­tek­tu­rę a szcze­gó­ły dopre­cy­zo­wu­je się w toku kolej­nych eta­pów (ite­ra­cji).

Drugi dia­gram to wła­śnie w inży­nie­rii ite­ra­cyj­no-przy­ro­sto­we wytwa­rza­nie (tak­że opro­gra­mo­wa­nia). Jeżeli pro­dukt jaki ma powstać jest mały” spro­wa­dzi się prak­tycz­nie do pierw­szych dwóch czę­ści: ana­li­za i opra­co­wa­nie archi­tek­tu­ry oraz pro­jek­to­wa­nie i reali­za­cja. Jeżeli pro­jekt (zakres) jest na tyle duży, że ryzy­ko pro­jek­to­wa­nia cało­ści jest zbyt duże (patrz pierw­szy dia­gram), nale­ży wybrać meto­dę ite­ra­cyj­no-przy­ro­sto­wą, jed­nak wyma­ga to na począt­ku zawsze opra­co­wa­nia (zapro­jek­to­wa­nia) wizji cało­ści, jaką jest archi­tek­tu­ra kom­po­nen­to­wa całe­go roz­wią­za­nia a przy naj­mniej stra­te­gia two­rze­nia apli­ka­cji. Co tu jest opi­sem przed­mio­tu zamó­wie­nia (OPZ)? OPZ – dla doko­na­nia wyce­ny – musi mieć skoń­czo­ny zakres, musi sta­no­wić coś co pozwo­li na odbiór pro­duk­tu”. Dlatego dla dużych pro­jek­tów wygod­nie jest opra­co­wać w ramach OPZ:

  1. biz­ne­so­wy kon­tekst pro­jek­tu zawie­ra­ją­cy mode­le pro­ce­sów biznesowych,
  2. na bazie mode­li pro­ce­sów, skoń­czo­ną licz­bę przy­pad­ków uży­cia apli­ka­cji (czy­li Przedmiotu Zamówienia),
  3. archi­tek­tu­rę i stra­te­gię budo­wy aplikacji,
  4. uni­kać deta­li implementacyjnych.

Z taką doku­men­ta­cją mamy: zakres pro­jek­tu oraz narzę­dzie do zarzą­dza­nia ite­ra­cja­mi: każ­dy kolej­ny etap to jeden przy­pa­dek uży­cia. Powinno więc być moż­li­we stwo­rze­nie doku­men­tu OPZ mają­ce­go zamknię­ty zakres, meto­dę roz­li­cze­nia (odbiór jako testy przy­pad­ków uży­cia) i otwar­tą dro­gę dla pra­cy zwin­ne­go” zespo­łu, czy­li miej­sce na kolej­ne ite­ra­cje pro­jek­to­wa­nia deta­li implementacji.

Uwagi na temat Opinii Prawnej … 

Na tym tle teraz popa­trz­my na doku­ment OPINIA PRAWNA SPORZĄDZONA NA ZLECENIE SKARBU PAŃSTWA W IMIENIU KTÓREGO DZIAŁA CENTRUM PROJEKTÓW POLSKA CYFROWA, opra­co­wa­ny przez kan­ce­la­rię Maruta Wachta sp. j. (do pobra­nia https://​cppc​.gov​.pl/​w​p​-​c​o​n​t​e​n​t​/​u​p​l​o​a​d​s​/​A​g​i​l​e​-​w​-​P​Z​P​_​f​i​n​a​l​_​c​z​y​s​t​a​.​pdf).

Dokument ma dla wygo­dy ponu­me­ro­wa­ne aka­pi­ty, odnio­sę do wybra­nych z nich (sek­cja Wnioski):

(1) Kancelaria odno­si się bar­dzo ogól­nie do agi­le, potwier­dza­jąc brak ści­słej defi­ni­cji, nie­ste­ty nie two­rzy wła­snej na uży­tek Opinii.

(2) Kancelaria wyra­ża opi­nię, że meto­dy te są coraz powszech­niej wyko­rzy­sty­wa­ne, z powo­dze­niem, na kon­ty­nen­cie ame­ry­kań­skim oraz w Europie Zachodniej”, nie­ste­ty brak ści­słej defi­ni­cji agi­le oraz brak kry­te­riów powo­dze­nia pro­jek­tu” (z jed­naj stro­ny powo­dze­niem jest pro­jekt ukoń­czo­ny przy zgo­dzie obu stron umo­wy, z dru­giej pro­jekt w któ­rym w ter­mi­nie i budże­cie wyko­na­no dekla­ro­wa­ny zakres) nie pozwa­la oce­nić tego wnio­sku, jest to nie­ste­ty spe­ku­la­cja auto­rów Opinii.

(5) Kancelaria pisze, że ” Zasadnicze zna­cze­nie ma w szcze­gól­no­ści świa­do­ma akcep­ta­cja przez zespół zama­wia­ją­ce­go decy­zji o reali­za­cji dane­go pro­jek­tu w oma­wia­nej for­mu­le [mój przyp.: nie zde­fi­nio­wa­no tej for­mu­ły”] oraz kon­se­kwen­cji z tego pły­ną­cych”, jed­nak moja uwa­ga: inte­res Zamawiającego to mak­si­mum korzy­ści osią­gnię­ty naj­niż­szym kosz­tem, ryn­ko­wy inte­res Wykonawcy jest dokład­nie prze­ciw­staw­ny, z tego powo­du nie wyobra­żam sobie takie­go pro­jek­tu bez doku­men­ta­cji, któ­ra na począt­ku opi­su­je Przedmiot Zamówienia”, nie może nim być jed­nak edżaj­lo­wa usłu­ga pod­ję­cia starań”…

(6) tu Kancelaria zwra­ca jed­nak uwa­gę, że zwin­ne meto­dy moż­na sto­so­wać do pro­jek­tów takich, któ­rych war­tość jest niż­sza niż tzw. pro­gi unij­ne lub takich, w któ­rych zasto­so­wa­nie znaj­du­je okre­ślo­ne wyłą­cze­nie sto­so­wa­nia prze­pi­sów Prawa zamó­wień publicznych”.

(7) ochro­na praw­na (Krajowa Izba Odwoławcza, sądy) moim zda­niem nie jest tu pro­ble­mem, pro­ble­mem jest jakość doku­men­ta­cji tech­nicz­nej, bo poja­wie­nie się spo­ru w pierw­szym rzę­dzie zaowo­cu­je żąda­nia­mi opi­nii rze­czo­znaw­ców a nie praw­ni­ków. Niestety z moje­go doświad­cze­nia wyni­ka, że rze­czo­znaw­cy w tej bran­ży rzad­ko mają kom­pe­ten­cje z zakre­su inży­nie­rii oprogramowania.

Opinia zawie­ra bar­dzo cen­ną część: Podstawa praw­na, któ­ra nie­ste­ty jed­nak nie zawie­ra bar­dzo waż­ne­go w moich oczach odnie­sie­nie do ochro­ny know-how (Dz.U. 1993 Nr 47 poz. 211 USTAWA z dnia 16 kwiet­nia 1993 r. o zwal­cza­niu nie­uczci­wej kon­ku­ren­cji), choć­by z uwa­gi na to, że spół­ki skar­bu pań­stwa pod­le­ga­ją pod PZP i są pod­mio­ta­mi ryn­ko­wy­mi chro­nią­cy­mi swo­je tajem­ni­ce (wię­cej o tym napi­sa­łem w arty­ku­le Ochrona Know-how Zamawiającego).

Porównanie meto­dy kaska­do­wej i Agile

(1) Jestem tu zasko­czo­ny przy­ję­tą przez Kancelarię defi­ni­cją «kaska­do­wy” (tu auto­rom Opinii i czy­tel­ni­kom tego tek­stu gorą­co pole­cam tę uzna­ną już na świe­cie pozy­cję: SYSTEM ANALYSIS AND DESIGN Fifth Edition). To co nazy­wa­my water­fall” to nie kaska­do­wy pro­ces a pro­ces dwu­eta­po­wy: ana­li­za i szcze­gó­ło­we pro­jek­to­wa­nie oraz imple­men­ta­cja pro­jek­tu. Zacytuję powyż­szą pozy­cję lite­ra­tu­ry przedmiotu:

Waterfall deve­lop­ment metho­do­lo­gies have the advan­ta­ges of iden­ti­fy­ing requ­ire­ments long befo­re pro­gram­ming begins and limi­ting chan­ges to the requ­ire­ments as the pro­ject pro­ce­eds. The key disa­dvan­ta­ges are that the design must be com­ple­te­ly spe­ci­fied befo­re pro­gram­ming begins, a long time elap­ses betwe­en the com­ple­tion of the sys­tem pro­po­sal in the ana­ly­sis pha­se and the deli­ve­ry of sys­tem, and testing is tre­ated almost as an after­tho­ught in the imple­men­ta­tion phase.

Polecam tu tak­że Kancelarii lek­tu­rę np. moje­go arty­ku­łu na ten temat: Cykl życia pro­jek­tu two­rze­nia opro­gra­mo­wa­nia .

(13) powo­ła­nie się na uży­cie Agile w Alegro nie do koń­ca jest tu rze­tel­ne. Na jed­nej z kon­fe­ren­cji (Quality of IT, 7 – 8 2015 r.) refe­rat Szefa IT Allegro nie potwier­dza tego. Owszem ode­szli od kla­sycz­ne­go water­fall” z powo­dów jak wyżej, jed­nak wdro­że­nie agi­le dopro­wa­dzi­ło ich na skraj kata­stro­fy i wdro­żo­no meto­dy ite­ra­cyj­no-przy­ro­sto­we w tym pla­no­wa­nie, doku­men­to­wa­nie i zarzą­dza­nie zmianą.

(17) Kancelaria pisze: Zgodnie z zasa­da­mi meto­dy­ki Agile, pro­duk­ty w pro­jek­cie były dostar­cza­ne mały­mi
czę­ścia­mi, po krót­kich ite­ra­cjach (co do zasa­dy trwa­ją­cych 3 tygo­dnie).” Problem w tym, że każ­dy doświad­czo­ny inży­nier powie, że nie jest moż­li­we spro­wa­dze­nie każ­dej dużej kon­struk­cji inży­nier­skiej do kom­po­nen­tów, któ­rych wytwo­rze­nie zmie­ści się w trzy­ty­go­dnio­wym odcin­ku cza­su. Ta zasa­da (3 tyg. sprin­ty) nie tyl­ko mnie wpra­wa w zakło­po­ta­nie bo np. zapew­ne moż­na w trzy tygo­dnie stwo­rzyć stro­nę któ­ra posłu­ży to wypeł­nia­nia wnio­sków o poli­sę czy kre­dyt, ale stwo­rze­nie w 3 tyg. kom­po­nen­tu sco­rin­go­we­go, przy­dat­ne­go do oce­ny zdol­no­ści kre­dy­to­wej wnio­sko­daw­cy jest nie­moż­li­we a odda­nie do użyt­ku, po 3 tyg. nie­kom­plet­ne­go” takie­go modu­łu raczej przy­nie­sie szko­dy niż korzy­ści dla klien­ta” (ta uwa­ga doty­czy tak­że następ­nej sek­cji Możliwość podzia­łu pro­duk­tu na krót­kie fazy, (3) str. 30).

Nie pod­wa­żam tego, że uży­cie agi­le” pro­wa­dzi­ło gdzieś do suk­ce­sów, jed­nak bez zde­fi­nio­wa­nia poję­cia suk­ces” pro­jek­tu, taka oce­na jest bez­war­to­ścio­wa, bo sam fakt, że pro­jekt w koń­cu został dopro­wa­dzo­ny do koń­ca nic tu nie zna­czy, liczy się to jak się miał pier­wot­ny plan do uzy­ska­ne­go efek­tu a tego tu nie napisano.

Nie była tu moim celem oce­na tego opra­co­wa­nia. Celem jest kon­fron­ta­cja opi­sa­ne­go prze­ze mnie ite­ra­cyj­no-przy­ro­sto­we pro­ce­su inży­nie­rii z opi­nia­mi auto­rów Opinii. Autorzy w ramach pod­su­mo­wa­nia na str. 83, umie­ści­li tabe­lę zawie­ra­ją­ce listę czyn­ni­ków zwin­no­ści” i moż­li­wo­ści ich zasto­so­wa­nia w pro­jek­tach dla admi­ni­stra­cji. Wygląda na to, że jest to moż­li­we, co praw­da ja powy­żej sku­pi­łem się na opi­sie meto­dy ite­ra­cyj­no-przy­ro­sto­wej, tak­że uzna­wa­nej za zwin­ną”, ale takich uznań” mamy wie­le w lite­ra­tu­rze łącz­nie z tak zwa­nym pro­gra­mo­wa­niem ekstremalnym”.

Sama opi­nia praw­na zawar­ta w Opinii jest bar­dzo cen­na i war­to­ścio­wa. Moim zda­niem jed­nak nie ma potrze­by budo­wa­nia skom­pli­ko­wa­nych mecha­ni­zmów praw­nych do prze­pro­wa­dze­nia zwin­ne­go” pro­jek­tu na bazie PZP. Uważam, że klu­czem jest opi­sa­ne prze­ze mnie kla­sycz­ne inży­nier­skie podej­ście (eta­py i podział na kom­po­nen­ty – przy­pad­ki uży­cia) i dys­cy­pli­na w pro­jek­cie. Tu nale­ży zgo­dzić się, że – za SCRUM – klu­czo­wą jest rola Product Ownera, któ­ry – nie tyl­ko moim zda­niem – powi­nien być bez­względ­nie rolą po stro­nie Zamawiającego, oraz rola Kierownika Projektu po stro­nie Wykonawcy, któ­ry powi­nien utrzy­my­wać bar­dzo dużą dys­cy­pli­nę, mając w umo­wie bar­dzo dobrą pro­ce­du­rę komu­ni­ka­cji, zarzą­dza­nia zmia­ną i doku­men­ta­cją. Największym ryzy­kiem jest, w moim mnie­ma­niu, zało­że­nie wyma­ga­ne­go zgod­ne­go dzia­ła­nia stron” (wiem, ze takie sfor­mu­ło­wa­nie jest w Kodeksie Cywilnym). Każdy kto spo­tkał się w sądzie ze spo­rem pomię­dzy Zamawiającym opro­gra­mo­wa­nie a jego Dostawcą wie, że naj­więk­szym pro­blem jest brak rze­tel­nej doku­men­ta­cji pro­jek­to­wej, w szcze­gól­no­ści pre­cy­zu­ją­cej to co mia­ło powstać”.

(infor­ma­cja o arty­ku­le zosta­ła wysła­na 16.02.2017 na adres Kancelarii biuro@maruta.pl, nie otrzy­ma­łem żad­nych uwag z Kancelarii)

P.S.

jako ciąg dal­szy pole­cam wpis Wzorcowe klau­zu­le w umo­wach IT.

User Story c.d.

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.
  2. 2.
  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. . 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.

Produkt analizy jako twierdzenie naukowe

Znakomita więk­szość pro­gra­mów zawie­ra ponad 10 krot­nie wię­cej kodu niż mogła by mieć, bo pro­gra­mi­ści czę­sto imple­men­tu­ją warian­ty zacho­wań a nie ich mecha­ni­zmy (co powo­du­je, że sys­te­my te są tyleż razy droż­sze niż mogły by być).

Prawie za każ­dym razem, gdy mówię (ale nie robię tego jed­nak zbyt czę­sto 😉 ), że sto­su­ję meto­dy nauko­we w ana­li­zie, spo­ty­kam się z zarzu­tem, że prze­sa­dzam. Zapewne nie ma sen­su epa­to­wa­nie w pro­jek­tach biz­ne­so­wych aka­de­mic­kim słow­nic­twem, nie ma zna­cze­nia dobór słow­nic­twa w nazwa­niu meto­dy pra­cy, bo zna­cze­nie ma skuteczność.

Twierdzenie naukowe

Poniżej defi­ni­cja tego czym jest twier­dze­nie naukowe:

Twierdzenie nauko­we ? zda­nie oznaj­mia­ją­ce speł­nia­ją­ce nastę­pu­ją­ce warun­ki :

  1. moż­na wobec nie­go sfor­mu­ło­wać kry­te­ria pozwa­la­ją­ce na eks­pe­ry­men­tal­ne, obser­wa­cyj­ne lub logicz­ne ich oba­le­nie (fal­sy­fi­ko­wal­ne według zasad Karla R. Poppera),
  2. ist­nie­ją regu­ły jego odczy­ta­nia, któ­re ogra­ni­cza­ją do skoń­czo­no­ści licz­bę ich inter­pre­ta­cji (kry­te­rium pre­cy­zji Józefa Bocheńskiego),
  3. odno­si się do empi­rycz­nie doświad­czal­nej lub logicz­nie defi­nio­wa­nej rze­czy­wi­sto­ści (tzw. widły Hume?a),
  4. jest ele­men­tem zbio­ru twier­dzeń para­dyg­ma­tu wyja­śnia­ją­ce­go rze­czy­wi­stość i pozwa­la­ją­ce­go na prze­wi­dy­wa­nie jej przy­szłych sta­nów (kon­cep­cja nauki nor­mal­nej T. S. Kuhna),
  5. twier­dze­nie będą­ce naj­prost­szym z moż­li­wych opi­sów świa­ta (tzw. Brzytwa Ockhama).

Graficznie sam pro­ces odkry­cia nauko­we­go moż­na poka­zać tak :

Budgen, D. (2003). Software design (2nd ed). Addison-Wesley.
Budgen, D. (2003). Software design (2nd ed). Addison-Wesley. 

Celowo cytu­ję tu lite­ra­tu­rę z obsza­ru inży­nie­rii opro­gra­mo­wa­nia, by poka­zać, że nie jestem odosob­nio­ny w tym podej­ściu. Dla porząd­ku poda­je tak­że defi­ni­cje poję­cia model:

model: sys­tem zało­żeń, pojęć i zależ­no­ści mię­dzy nimi pozwa­la­ją­cy opi­sać (mode­lo­wać) w przy­bli­żo­ny spo­sób jakiś aspekt rzeczywistości

Więcej o mode­lach w nauce: .

Inżynieria oprogramowania

Jeżeli uzna­my, że wynik zarów­no ana­li­zy jak i pro­jek­to­wa­nia, to tak­że mode­le (przyj­mu­je­my meto­dę pra­cy opar­tą na two­rze­niu mode­li: MDD/MDA czy­li model dri­ven deve­lop­ment”, MDA czy­li model dri­ven archi­tec­tu­re”, itp.), to w związ­ku z tym 

model, jako wynik ana­li­zy, moż­na potrak­to­wać jako twier­dze­nie nauko­we opi­su­ją­ce bada­ną (ana­li­zo­wa­ną) orga­ni­za­cję, jest on zara­zem wyma­ga­niem wobec opro­gra­mo­wa­nia (ma zostać zaimplementowany).

Wyjaśnienie: odnio­sę się do powyż­szej defi­ni­cji twier­dze­nia nauko­we­go (zgod­nie z powyż­szym pod poję­ciem model rozu­mie­my kom­plet doku­men­ta­cji zawie­ra­ją­cej mode­le, powsta­łej jako pro­dukt analizy):

  1. kry­te­rium fal­sy­fi­ka­cji: dopie­ro wska­za­nie w bada­nej orga­ni­za­cji fak­tu, któ­re­go nie opi­su­je opra­co­wa­ny model, pozwa­la uznać model (wynik ana­li­zy) za zły,
  2. ist­nie­ją regu­ły jego (mode­lu) odczy­ta­nia, czy­li do stwo­rze­nia mode­lu uży­to sfor­ma­li­zo­wa­nych nota­cji i sys­te­mów poję­cio­wych (np. BPMN, UML, BMM, SBVR itp),
  3. model powstał na bazie, i odno­si się wyłącz­nie do, zebra­nych w toku ana­li­zy fak­tów (w szcze­gól­no­ści doku­men­tów, któ­re powsta­ją w toku pra­cy ana­li­zo­wa­nej orga­ni­za­cji – doku­men­ty opi­su­ją fak­ty np. fak­tu­ra to opis fak­tu doko­na­nia sprzedaży),
  4. model pozwa­la na prze­wi­dy­wa­nie tego co zaj­dzie w odpo­wie­dzi na okre­ślo­ne bodź­ce (para­dyg­mat pro­ce­so­wy opi­su­ją­cy zacho­wa­nia i para­dyg­mat obiek­to­wy opi­su­ją­cy struk­tu­ry), mając model pro­ce­sów biz­ne­so­wych moż­na prze­wi­dzieć pro­dukt pro­ce­su, mając model apli­ka­cji moż­na prze­wi­dzieć pro­dukt każ­de­go przy­pad­ku użycia,
  5. opra­co­wa­ny model jest naj­prost­szy (mini­mal­ny) z moż­li­wych, czy­li nie da się już z nie­go usu­nąć nic bez spo­wo­do­wa­nia jego znisz­cze­nia (uczy­nie­nia nieprawdziwym).

Tu, dla dopeł­nie­nia, war­to dodać powszech­nie uzna­wa­ną w świe­cie nauki defi­ni­cję praw­dy (A.Tarski): twier­dze­nie praw­dzi­we to twier­dze­nie kore­spon­du­ją­ce z faktami.

Tak więc mamy to co chce­my czy­li kry­te­rium odbio­ru doku­men­ta­cji ana­li­tycz­nej i pro­jek­to­wej: nie jest to licz­ba stron a to, że mówi prawdę”. 

Z dru­giej stro­ny, nie­ste­ty nie ist­nie­je moż­li­wość wyka­za­nia popraw­no­ści doku­men­ta­cji powsta­łej w wyni­ku ankiet, wywia­dów czy burzy mózgów spi­sa­nej języ­kiem natu­ral­nym … .

cięż­ką arty­le­rię”, jak ta tu opi­sa­na, wyta­cza­my głów­nie dla pro­jek­tów ryzy­kow­nych i kosz­tow­nych… 😉 oraz wszę­dzie tam gdzie waż­na jest ochro­na know-how.

Dodatek

(dwa dni po publikacji)

Właśnie pode­sła­no mi link do cie­ka­we­go tekstu:

One of the most impor­tant ele­ments of eve­ry Business Analyst?s tool­kit is pro­cess mode­ling, which is also signi­fi­cant acti­vi­ty for Business Process Management pro­fes­sio­nals. For BPM mar­ket B? (Źródło: BPMN for Business Analysts ? why, when and how)

Przejrzałem treśc i wszyst­kie wypo­wie­dzi one krę­cą się” wokół doku­men­to­wa­nia, pre­zen­ta­cji w celu zatwier­dze­nia lub zgła­sza­nia uwag oraz nie­któ­rzy wska­zu­ją na moż­li­wość ryso­wa­nia zamiast kodo­wa­nia w celu wyko­na­nia”, albo prze­oczy­łem albo nikt nie zwró­cił uwa­gi na bar­dzo – mim zda­niem waż­ny ele­ment – two­rze­nie mode­lu orga­ni­za­cji czy­li two­rze­nie hipo­te­zy tak dzia­ła­cie” jako orga­ni­za­cja.

Problem w tym, że chy­ba więk­szość użyt­kow­ni­ków” tej (BPMN) – i nie tyl­ko – nota­cji, sto­su­je induk­cyj­ne meto­dy uwia­ry­gad­nia­nia tych mode­li, rozu­mia­nych raczej jako sche­ma­ty blo­ko­we. Podejście bazu­ją­ce na dowo­dzie z ilo­ści” (induk­cja): model pro­ce­sów jest dobry bo bar­dzo dużo osób (osób akcep­tu­ją­cych, recen­zen­tów) tak uzna­ło, jest chy­ba najgorsze.

To błąd logicz­ny: nie da się wyka­zać popraw­no­ści meto­dą induk­cyj­ną. Model owszem powi­nien być jako dia­gram zro­zu­mia­ły dla czy­tel­ni­ka, to nie ule­ga wąt­pli­wo­ści, jed­nak jego testy powin­ny pole­gać na wska­zy­wa­niu (szu­ka­niu) ewen­tu­al­nych fak­tów typu a tu mówi nie­praw­dę”. Innymi sło­wy model pro­ce­su nie jest dobry” (odzwier­cie­dla praw­dzi­wy mecha­nizm dzia­ła­nia orga­ni­za­cji) dla­te­go, że wszy­scy go zaak­cep­to­wa­li, jest dobry dla­te­go, że nikt nie zna­lazł (nie wska­zał) jego wady (nie pod­wa­żo­no go).

Projektów zakoń­czo­nych klę­ską, w któ­rych wszy­scy zaak­cep­to­wa­li doku­men­ta­cję” zna­my chy­ba wszy­scy masę.…

Tak więc ana­li­tyk, któ­ry pod­cho­dzi sys­te­mo­wo do ana­li­zy powi­nien two­rzyć hipo­te­zy tak to dzia­ła” i nie dowo­dzić ich popraw­no­ści, a cze­kać na wska­za­nie wad. Notacje (BPMN, UML, BMM, …) oraz mode­le two­rzo­ne z ich pomo­cą, są dosko­na­łym narzę­dziem do doku­men­to­wa­nia tych teorii.

Na zakoń­cze­nie pole­cam to 🙂

Źródła

Kitchenham, B., Pearl Brereton, O., Budgen, D., Turner, M., Bailey, J., & Linkman, S. (2009). Systematic lite­ra­tu­re reviews in softwa­re engi­ne­ering – A sys­te­ma­tic lite­ra­tu­re review. Information and Software Technology, 51(1), 7 – 15. https://​doi​.org/​1​0​.​1​0​1​6​/​j​.​i​n​f​s​o​f​.​2​0​0​8​.​0​9​.​009
Budgen, D. (2003). Software design (2nd ed). Addison-Wesley.
Popper, K. R. (2002). Logika odkry­cia nauko­we­go (U. Niklas, Trans.). Fundacja Aletheia.
Šenkýř, D., & Kroha, P. (2019). Problem of Incompleteness in Textual Requirements Specification: Proceedings of the 14th International Conference on Software Technologies, 323 – 330. https://​doi​.org/​1​0​.​5​2​2​0​/​0​0​0​7​9​7​8​0​0​3​2​3​0​330
Kitchenham, B. A., Budgen, D., & Brereton, P. (2016). Evidence-based softwa­re engi­ne­ering and sys­te­ma­tic reviews. CRC Press.

New in Visual Paradigm 13.1…

Od 17-go kwiet­nia mamy wer­sje 13.1 pakie­tu Visual-Paradigm (i peł­nej wer­sji dla ana­li­ty­ków i pro­jek­tan­tów: ArchiMetric). Twórcy pakie­tu bar­dzo sil­nie współ­pra­cu­ją z ana­li­ty­ka­mi w wie­lu kra­jach (nale­żę do nich 😉 ) , zbie­ra­ją suge­stie ale też fil­tru­ją je. Cieszy mnie to, że w prze­ci­wień­stwie do (jak obser­wu­ję) fir­my SPARX (pro­du­cent Enterprise Architekta), nie wycho­dzą poza stan­dar­dy. W VP odrzu­ca­ją wszel­kie for­my nie­stan­dar­do­wych pomy­słów (np. aktor czas” w Enterprise Architect to kurio­zal­na, nie­stan­dar­do­wa kon­struk­cja) ale za to imple­men­tu­ją spraw­dzo­ne pomy­sły na ergo­no­mie pra­cy oraz zarzą­dza­nie spój­no­ścią pro­jek­tu. Jeżeli to tego dodać zdro­we podej­ście do agi­le otrzy­mu­je­my kolej­ną odsło­nę opro­gra­mo­wa­nia CASE, któ­re z jed­nej stro­ny wręcz dosko­na­le wspie­ra stan­dar­dy OMG, nie nagi­na ich, daje swo­bo­dę pra­cy z nimi (SPARX poszedł w masę goto­wych wzor­ców, z któ­ry­mi się wal­czy two­rząc dia­gra­my i jest wyjąt­ko­wo mało intuicyjny).

Ta odsło­na zaowo­co­wa­ła jesz­cze więk­szą inte­gra­cją metod zwin­nych z for­ma­li­zmem nota­cji, mam wra­że­nie, że ludzie w Visual-Paradigm mają przy­bi­tą na ścia­nie całą biblio­tecz­kę Scott’a Amblera :). Poniżej przy­kłąd połą­cze­nia twar­de­go mode­lo­wa­nia pro­ce­sów w BPMN z User Story, sztan­da­ro­wym” narzę­dziem w meto­dy­kach zwin­nych. Po co? Ano po to, by pano­wać nas spój­no­ścią, kom­plet­no­ścią i nie­sprzecz­no­ścią”. To narzę­dzie pozwa­la­ją­ce połą­czyć zale­ty wymu­sze­nia spój­no­ści, jaką daje uży­cia nota­cji BPMN i ana­li­zy sys­te­mo­wej z kwie­ci­sto­ścią” ludz­kich pro­duk­cji słow­no-muzycz­nych” 😉 . Robię tak od lat ale teraz narzę­dzie daje peł­ne wspar­cie tej meto­dzie pracy.

Adhere User Stories to Any Diagrams User sto­ries can now be writ­ten in any dia­gram, such as BPD. This allows you to rela­te users? con­cern and / or requ­ire­ments in the form of a sto­ry card. Presented along with the sys­tem desi­gns. In par­ti­cu­lar, the visu­al map­ping betwe­en user sto­ries and BPMN acti­vi­ties. Which will help to iden­ti­fy user sto­ries based on a busi­ness pro­cess (dia­gram). Źródło: What’s New in Visual Paradigm 13.1?

Dla pury­stów (ja też nim jestem): nadal jest to zgod­ne z nota­cją BPMN, bo ta dopusz­cza defi­nio­wa­nie wła­snych sym­bo­li z ich skład­nią i uży­cie ich na diagramach.

Cieszy mnie, że to narzę­dzie współ­two­rzą prak­ty­cy dla prak­ty­ków, bez imple­men­to­wa­nia nie­uza­sad­nio­nych pseu­do­te­orii i wymu­sza­nia na użyt­kow­ni­kach jakich­kol­wiek słusz­nych poglądów”.