Abstraction focuses upon the essential characteristics of some object, relative to the perspective of the viewer. [Abstrakcja skupia się na istotnych cechach jakiegoś obiektu w odniesieniu do perspektywy widza.]

Wymagania biznesowe – jak zbierać i dokumentować

Wprowadzenie

Ronald Ross, współ­au­tor stan­dar­du mode­lo­wa­nia reguł biz­ne­so­wych i biz­ne­so­we­go słow­ni­ka pojęć napi­sał nie­daw­no na swo­im pro­fi­lu LinkedIn:

People love sto­ries. Are user sto­ries help­ful in engi­ne­ering busi­ness solu­tions? Absolutely. Are you done with requ­ire­ments and solu­tion engi­ne­ering when you’ve wor­ked thro­ugh a set of user sto­ries? No. Not even clo­se!” [„Ludzie kocha­ją histo­rie. Czy histo­rie użyt­kow­ni­ków są pomoc­ne w two­rze­niu roz­wią­zań biz­ne­so­wych? Zdecydowanie tak. Czy skoń­czy­łeś z wyma­ga­nia­mi i inży­nie­rią roz­wią­za­nia, gdy już opra­co­wa­łeś zestaw histo­ry­jek użyt­kow­ni­ka? Nie. Nawet nie zbli­ży­łeś się do nich!”.]

(https://​www​.lin​ke​din​.com/​p​o​s​t​s​/​r​o​s​s​r​o​n​a​l​d​_​p​e​o​p​l​e​-​l​o​v​e​-​s​t​o​r​i​e​s​-​a​r​e​-​u​s​e​r​-​s​t​o​r​i​e​s​-​h​e​l​p​f​u​l​-​a​c​t​i​v​i​t​y​-​6​9​3​5​6​2​7​0​0​8​2​6​5​6​3​3​7​9​3​-​B​p​zb/)

Świat od dekad bory­ka się z jako­ścią i sku­tecz­no­ścią spe­cy­fi­ko­wa­nia wyma­gań na opro­gra­mo­wa­nie. OMG​.org opu­bli­ko­wa­ło stan­dard o nazwie MDA (ang. Model Driven Architecture ), któ­ry tak opi­su­je pro­ces two­rze­nia oprogramowania:

CIM -> PIM -> PSM

Są to odpo­wied­nio mode­le: Model Biznesowy (CIM: Computation Independent Model), Model Mechanizmu dzia­ła­nia (PIM: Platform-Independent Model, jest to model dzie­dzi­ny sys­te­mu wg. MVC) oraz Model Implementacji (PSM: Platform-Specific Model). Swego cza­su sze­rzej opi­sa­łem zależ­no­ści mię­dzy tymi mode­la­mi (czy­taj wię­cej o MDA).

CIM to model dzia­ła­nia orga­ni­za­cji: pro­ce­sy biz­ne­so­we i ich pro­duk­ty. Z uwa­gi na to, że obec­nie już nie rodzą się pro­jek­ty jed­no­ra­zo­wej infor­ma­ty­za­cji cało­ści orga­ni­za­cji, poja­wia się potrze­ba okre­śle­nia zakre­su pro­jek­tu, bo nie jest już nim cała orga­ni­za­cja. Model PIM to udo­ku­men­to­wa­ny mecha­nizm dzia­ła­nia sys­te­mu (opro­gra­mo­wa­nia), logi­ka jego dzia­ła­nia. Nie ma tu mowy o tym w jakiej tech­no­lo­gii powsta­nie, bo z zasa­dy mamy ich wie­le do wybo­ru, a wybór tech­no­lo­gii zale­ży od wie­lu poza-funk­cjo­nal­nych ogra­ni­czeń i wyma­gań. Technologia jest (powin­na być) kon­se­kwen­cją wybo­ru wyko­naw­cy i ten dopie­ro opra­cu­je model PSM, któ­ry w prak­ty­ce jest tak zwa­ną Koncepcją Wdrożenia, moż­na ją tak­że udo­ku­men­to­wać w nota­cji UML, ale na tym eta­pie powszech­na prak­ty­ką jest jedy­nie zapro­jek­to­wa­nie śro­do­wi­ska, zesta­wie­nie go i pra­ca od razu w kodzie.

Kluczowym pro­ble­mem jest przej­ście z CIM na PIM, czy­li jak udo­ku­men­to­wać zakres pro­jek­tu dostar­cze­nia opro­gra­mo­wa­nia i prze­kształ­cić go na wyma­ga­nia wobec tego oprogramowania?

CIM -> [zakres pro­jek­tu] -> PIM -> PSM

W meto­dach zwa­nych zwin­ny­mi, mode­le CIM i PIM są pomi­ja­ne. Typowym zaś narzę­dziem zbie­ra­nia wyma­gań” są tak zwa­ne histo­ryj­ki użyt­kow­ni­ka (user sto­ry). Problem w tym, że są one klu­czo­wym ryzy­kiem pro­jek­tów gdyż z regu­ły są nie­spój­ne i nie­kom­plet­ne jako wyma­ga­nia. Specyfikacja wyma­gań powin­na być: spój­na, kom­plet­na i nie­sprzecz­na. Opisanie zakre­su pro­jek­tu histo­ryj­ka­mi użyt­kow­ni­ka, nie mając mode­lu pro­ce­sów biz­ne­so­wych cało­ści (model CIM), jest pozba­wie­niem się narzę­dzia do wery­fi­ka­cji kom­plet­no­ści, spój­no­ści i nie­sprzecz­no­ści takiej spe­cy­fi­ka­cji. Wszystkie wady (nie­kom­plet­ność, nie­spój­ność, sprzecz­no­ści) odkry­wa­ne są i usu­wa­ne (uzu­peł­nia­ne) dopie­ro na eta­pie wdra­ża­nia. Jest to pro­ces odkry­wa­nia wyma­gań w toku wdrożenia”. 

Historyjki użyt­kow­ni­ka jako lista potrzeb biz­ne­so­wych? Owszem! Historyjki użyt­kow­ni­ka jako wyma­ga­nia dla deve­lo­pe­ra? NIE! To tyl­ko mate­riał dla pro­jek­tan­ta, ponie­waż bar­dzo czę­sto jed­na i ta sama funk­cja sys­te­mu reali­zu­je wie­le róż­nych histo­rii użyt­kow­ni­ka. Implementacja per user sto­ry” pro­wa­dzi do bar­dzo kosz­tow­nych i nie­efek­tyw­nych roz­wią­zań (Opisywałem to na blo­gu: wpis pro­jekt Biblioteka, dwie histo­ryj­ki użyt­kow­ni­ka: chciał­bym wypo­ży­czyć książ­kę oraz chciał­bym zwró­cić książ­kę są reali­zo­wa­ne jed­ną usłu­gą apli­ka­cji: Karta Wypożyczenia, któ­ra zawie­ra rów­nież pole Data zwro­tu. Nadal spo­ty­kam pro­gra­mi­stów prze­ko­nu­ją­cych, że powin­ny to być dwa osob­ne ekra­ny – dwa przy­pad­ki uży­cia, czy­taj dwa razy wię­cej pra­cy kode­ra i dwa razy więk­szy koszt).

Czy można sformalizować proces zbierania historyjek użytkownika?

User Story to jed­no z naj­bar­dziej pro­ble­ma­tycz­nych narzę­dzi w meto­dach zwin­nych. Najczęściej zale­ca­na struk­tu­ra tych histo­ry­jek”, wraz z przykładami:

Jako 〈typ użyt­kow­ni­ka〉 chcę osią­gnąć 〈cel〉, aby 〈jakiś powód〉”. 

Na przy­kład:

Jako Administrator chcę otrzy­my­wać wia­do­mość e‑mail, gdy zosta­nie prze­sła­ny for­mu­larz kon­tak­to­wy, abym mógł na nie­go odpowiedzieć”

albo

Jako użyt­kow­nik mam moż­li­wość klik­nię­cia okre­ślo­nej loka­li­za­cji na mapie”;

Tak spi­sy­wa­ne wyma­ga­nia sta­no­wią ogrom­ny pro­blem z powo­du nie­rów­nej gra­da­cji, spro­wa­dza­nie ich do pozio­mu tak zwa­nych ato­mo­wych user sto­ry (dru­gi z powyż­szych przy­kła­dów) pro­wa­dzi do bar­dzo dużych liczb tych histo­ry­jek. Próba ich wery­fi­ka­cji (wali­da­cja user sto­ry) sta­je się co naj­mniej trud­nym zada­niem. Jakakolwiek wyce­na opro­gra­mo­wa­nia na bazie takich histo­ry­jek to wró­że­nie z fusów (więc deve­lo­pe­rzy moc­no zawy­ża­ją wyce­ny z uwa­gi na ryzy­ko utra­ty ren­tow­no­ści). Autorzy inne­go opra­co­wa­nia zauważają:

Rzeczywiście, przy oko­ło 800 US [User Story], hie­rar­chia była raczej trud­na do okre­śle­nia, a obraz sys­te­mu pod­czas pla­no­wa­nia był bar­dzo duży. Skalowalność jest więc zde­cy­do­wa­nie pro­ble­mem w pro­jek­tach zwin­nych, w któ­rych US są sła­by­mi arte­fak­ta­mi inży­nie­rii wyma­gań. Zdecydował się on [autor] na wpro­wa­dze­nie wzor­ca US: Jako [Użytkownik], chcę [Zadanie], aby [Cel]”, aby zde­fi­nio­wać hie­rar­chię w posta­ci Celu, Zadania i Użytkownika, ale bez powią­za­nia semantycznego.

Znam pro­jekt, w któ­rym licz­ba przy­pad­ków uży­cia, w pew­nym śred­niej tyl­ko wiel­ko­ści pro­jek­cie, szyb­ko się­gnę­ła czte­ry­stu. Wycena na ich pod­sta­wie poka­za­ła, że pla­no­wa­ny koszt wie­lo­krot­nie prze­kra­cza pla­no­wa­ny budżet. Ten pro­jekt zarzu­co­no, jed­nak wie­le tak wyce­nio­nych pro­jek­tów jest reali­zo­wa­nych, co daje obraz ska­li strat jakie przy­no­szą (zawy­żo­ny koszt to stra­ta). Powyżsi auto­rzy piszą na zakończenie:

Przyszłe pra­ce obej­mu­ją iden­ty­fi­ka­cję luk repre­zen­ta­cyj­nych, któ­re napo­ty­ka­ją prak­ty­cy w mode­lo­wa­niu US, oraz prze­gląd spo­so­bów, w jakie nasze ramy i [meto­da] GORE w ogó­le mogły­by roz­wią­zać te pro­ble­my. Równolegle oce­nia­na będzie rów­nież zdol­ność prak­ty­ków do sto­so­wa­nia pro­po­no­wa­nych ram zamiast zwy­kłych sza­blo­nów. Obecnie trwa­ją pra­ce nad narzę­dziem CASE (Computer Aided Software Engineering), któ­re zosta­nie wyko­rzy­sta­ne do wspar­cia eksperymentów.

Nie zna­la­złem wyni­ków dal­szych prac, więc podzie­lę się wyni­ka­mi swoich.

Gradacja User Story

Podstawowym pro­ble­mem z user sto­ry jest, moim zda­niem, brak stan­dar­du pozwa­la­ją­ce­go na zde­fi­nio­wa­nie ato­mo­wej histo­ryj­ki użyt­kow­ni­ka” czy­li pozio­mu, poni­żej któ­re­go nie dzie­li­my ich na mniej­sze. Jako audy­tor wie­lu doku­men­ta­cji (czę­sto w roli bie­głe­go) zauwa­ży­łem, że histo­ryj­ki użyt­kow­ni­ka są dopro­wa­dza­ne do pozio­mu poje­dyn­czych kro­ków sce­na­riu­szy przy­pad­ków uży­cia. Często też histo­ryj­ki użyt­kow­ni­ka utoż­sa­mia­ne są z przy­pad­ka­mi uży­cia (UML) i tak mode­lo­wa­ne, co jest poważ­nym błę­dem. Np. powyższe: 

Jako użyt­kow­nik mam moż­li­wość klik­nię­cia okre­ślo­nej loka­li­za­cji na mapie”

Mogło by to być czę­ścią sce­na­riu­sza usłu­gi (przy­pa­dek uży­cia UML), któ­rej celem jest Pokazanie Określonego Miejsca:

  1. AKTOR ini­cju­je usłu­gę Cel podróży
  2. SYSTEM wyświe­tla for­mu­larz Adres
  3. AKTOR wpro­wa­dza dane i naci­ska OK
  4. SYSTEM wyświe­tla mapę z nanie­sio­ną lokalizacją
  5. AKTOR kli­ka okre­ślo­ny punkt na mapie 
  6. SYSTEM powięk­sza obraz poka­zu­jąc deta­le lokalizacji

Powyższa histo­ryj­ka to jedy­nie punkt 5. tego sce­na­riu­sza. Nie trud­no dojść do wnio­sku, że samo klik­nię­cie na mapie to pozba­wio­na kon­tek­stu i celu, wyrwa­na pro­sta czyn­ność, i jej samo­dziel­ne ist­nie­nie w spe­cy­fi­ka­cji jako osob­ny byt, pozba­wio­ne jest sen­su. Z per­spek­ty­wy opro­gra­mo­wa­nia powsta­ją­ce­go w okre­ślo­nym celu, uzna­nie tej histo­ryj­ki za samo­dziel­ne wyma­ga­nie nie ma uza­sad­nie­nia. Uznanie jed­nak, że apli­ka­cja słu­ży mię­dzy inny­mi do zapo­zna­wa­nia się okre­ślo­ny­mi miej­sca­mi w prze­strze­ni, a usłu­gą tej apli­ka­cji jest Pokazanie Określonego Miejsca jak naj­bar­dziej ma sens. Idąc za suge­stią by histo­ryj­ka użyt­kow­ni­ka mia­ła strukturę: 

Jako [Użytkownik], chcę [Zadanie], aby [Cel]”

zmu­sza do zasta­no­wie­nia się czy kli­ka­nie na mapie jest celem, czy może jed­nak tym celem jest Pokazanie Określonego Miejsca, a kli­ka­nie jest ele­men­tem sce­na­riu­sza (pro­ce­du­ry) reali­za­cji tego celu (pamię­ta­my, że przy­pad­ki uży­cia mają sce­na­riu­sze, a te zło­żo­ne są z sekwen­cji kolej­nych kroków!).

Formalizacja User Story

Pojęcia Użytkownik, Zadanie, Cel, jako spój­ny zestaw pojęć odpo­wia­da­ją defi­ni­cji ato­mo­we­go (ele­men­tar­ne­go) pro­ce­su w nota­cji BPMN (doda­tek C, Słownik , ): Aktywność jest sko­ja­rzo­na z jej wyko­naw­cą (pula, tor), two­rzy pro­dukt (data object). Biorąc pod uwa­gę fakt, że pro­dukt ma tu okre­ślo­ne­go adre­sa­ta i musi on sta­no­wić sobą war­tość dla tego adre­sa­ta, mamy punkt wyzna­cza­ją­cy gra­ni­cę dzie­le­nia na czę­ści” tych histo­ry­jek. Nie będzie to moż­li­wość wsta­wie­nia z listy nume­ru NIP nabyw­cy” a utwo­rze­nie fak­tu­ry” (bo war­tość ma dopie­ro popraw­nie wysta­wio­na fak­tu­ra, a nie klik­nię­cie np. w pole NIP by wybrać kontrahenta). 

Jak sfor­ma­li­zo­wać histo­ryj­kę użyt­kow­ni­ka? Podstawą for­ma­li­za­cji (i celem) jest opra­co­wa­nie meto­dy kon­tro­li popraw­no­ści (wali­da­cja). Popatrzmy jesz­cze raz na szablon:

Jako 〈typ użyt­kow­ni­ka〉 chcę osią­gnąć 〈cel〉, aby 〈jakiś powód〉”. 

Typ użyt­kow­ni­ka to rola, celem jest pro­dukt pra­cy, a powo­dem? Powodem jest zawsze to, że okre­ślo­na oso­ba ocze­ku­je na efekt tej pra­cy (bez tego pra­ca ta była­by po pro­stu zbęd­na). Można więc wyobra­zić sobie taki zapis:

Jako sprze­daw­ca, chcę wysta­wić fak­tu­rę, klientowi. 

Mamy tu:

  1. rola: sprze­daw­ca
  2. cel: fak­tu­ra
  3. powód: ocze­ku­je tego klient. 

W tym miej­scu widać peł­ną zgod­ność tej defi­ni­cji z kon­struk­cją: aktyw­ność, jej pro­dukt, jego odbior­ca. Innymi sło­wy ana­li­tycz­ny model pro­ce­sów biz­ne­so­wych wyko­na­ny w nota­cji BPMN, to nic inne­go jak połą­czo­ne w logicz­ne cią­gi histo­ryj­ki użytkownika. 

Wyobraźmy sobie taką listę histo­ry­jek użyt­kow­ni­ka, wyko­na­ną wg. powyż­sze­go opisu:

Specyfikacja histo­ry­jek użytkownika

Niektóre narzę­dzia CASE, pozwa­la­ją­ce na ich pro­fi­lo­wa­nie, pozwa­la­ją przed­sta­wić to tak­że na mode­lu wyma­gań (co póź­niej umoż­li­wia śla­do­wa­nie, czy­li kon­tro­lę kom­plet­no­ści, spój­no­ści i niesprzeczności):

Diagram wyma­gań (nota­cja SysML)

Powyższe mogło­by być kon­se­kwen­cją takie­go mode­lu procesów:

Diagram pro­ce­su reali­za­cji zamó­wie­nia (nota­cja BPMN).

Jak widać, model pro­ce­su daje peł­ny kon­tekst dla aktyw­no­ści. Fakt, że pro­ces to logicz­ny prze­pływ pra­cy, powo­du­je, że two­rze­nie mode­li BPMN gwa­ran­tu­je spój­ność, kom­plet­ność i nie­sprzecz­ność listy aktyw­no­ści, ich pro­duk­tów i ról. 

Podsumowanie

Stosowanie typo­wych histo­ry­jek użyt­kow­ni­ka ma dwie klu­czo­we wady: 1. nie ma jed­nej meto­dy zarzą­dza­nia ich gra­da­cją i struk­tu­rą, wie­lu auto­rów przy­wo­łu­je wła­sne, nie­co się róż­nią­ce meto­dy stan­da­ry­za­cji, 2. ich dro­bia­zgo­wość oraz brak meto­dy kon­tro­li spój­no­ści, pro­wa­dzą do szyb­ko rosną­cej ich licz­by, w kon­se­kwen­cji cha­osu, szcze­gól­nie w śred­nich i więk­szych projektach.

Powyżej widać, że mode­lo­wa­nie pro­ce­sów biz­ne­so­wych na pod­sta­wie zebra­nych przy­kła­do­wych doku­men­tów (pro­duk­ty pra­cy ludzi: doku­men­ty) i opra­co­wa­nie na ich pod­sta­wie dia­gra­mu przy­pad­ków uży­cia, daje znacz­nie lep­sze wyni­ki niż zbie­ra­ne na warsz­ta­tach histo­ryj­ki użyt­kow­ni­ka. Same wyma­ga­nia wyra­żo­ne jako histo­ryj­ki użyt­kow­ni­ka, nie dają żad­nej szan­sy (brak meto­dy) na kon­tro­lę ich spój­no­ści, kom­plet­no­ści i nie­sprzecz­no­ści. Wymagania, jako kon­se­kwen­cja popraw­nie wyko­na­nych mode­li pro­ce­sów biz­ne­so­wych, z zasa­dy są spój­ne, kom­plet­ne i niesprzeczne.

W przy­to­czo­nym tu przy­kła­dzie widać, że dwie aktyw­no­ści (reje­stra­cja zamó­wie­nia i kon­tro­la jego sta­tu­su) reali­zo­wa­ne są jako dostęp do zapi­sa­ne­go w sys­te­mie Zamówienia. Daje to jasną prze­słan­kę do tego, że dwie histo­ryj­ki użyt­kow­ni­ka (dwie aktyw­no­ści na mode­lu pro­ce­sów) to dwa róż­ne kon­tek­sty uży­cia tej samej usłu­gi apli­ka­cji: Zamówienia (czy­li dostęp do ich two­rze­nia, aktu­ali­za­cji i pod­glą­du, to typo­wy przy­pa­dek uży­cia typu CRUD). Prawa dostę­pu do tego doku­men­tu mode­lu­je się zaś regu­ła­mi biz­ne­so­wy­mi (nie poka­za­no ich na dia­gra­mach), np. Klient ma wgląd tyl­ko w Zamówienia, któ­re sam złożył”. 

Można uznać, że małe pro­jek­ty, o małym ryzy­ku cha­osu wywo­ła­ne­go bra­kiem mode­li pro­ce­sów, moż­na reali­zo­wac na skró­ty” czy­li histo­ryj­ki użyt­kow­ni­ka i od razu model PSM (imple­men­ta­cja) z pomi­nię­ciem CIM i PIM, jed­nak jest to poważ­ne ryzy­ko już przy śred­nich pro­jek­tach. Dlatego pro­ces MDA:

{CIM -> [zakres pro­jek­tu] -> PIM} -> PSM

wyda­je się być znacz­nie efek­tyw­niej­szy co poka­zu­je prak­ty­ka (w nawia­sach klam­ro­wych {} zakres pra­cy analityka-projektanta).

Zakres pro­jek­tu to albo całe pro­ce­sy biz­ne­so­we albo świa­do­mie wybra­ne ich okre­ślo­ne aktyw­no­ści. Nie jest to tak­że żaden wodo­spad” (water­fall), bo ana­li­tycz­ny model pro­ce­sów biz­ne­so­wych powsta­nie szyb­ciej i taniej niż lista setek histo­ry­jek z pomo­cą wie­lo­dnio­wych warsz­ta­tów anga­żu­ją­cych całe zespo­ły ludzi. Wygenerowane z mode­lu pro­ce­sów biz­ne­so­wych przy­pad­ki uży­cia, są z zasa­dy spój­ne i kom­plet­ne, więc ich ite­ra­cyj­ne (kolej­ne) spe­cy­fi­ko­wa­nie (każ­dy pro­jek­tu­je­my jako samo­dziel­ny mikro­ser­wis) pozwa­la bez ryzy­ka odda­wać je kolej­no do imple­men­ta­cji, i jed­no­cze­śnie doku­men­to­wać (uszcze­gó­ła­wiać) kolejne. 

To spraw­dzo­na w prak­ty­ce meto­da wspie­ra­na przez wie­le narzę­dzi CASE (wszyst­kie dia­gra­my i ich prze­kształ­ce­nia poka­za­ne w tym arty­ku­le powsta­ły z uży­ciem Visual-Paradigm). Diagram przy­pad­ków uży­cia UML jest tu auto­ma­tycz­nie gene­ro­wa­ny z mode­li BPMN, wg poniż­szych zasad:

BPMNtoUseCase (źr. http://​www​.visu​al​-para​digm​.com/​t​u​t​o​r​i​a​l​s​/​f​r​o​m​-​b​u​s​i​n​e​s​s​-​p​r​o​c​e​s​s​-​t​o​-​u​s​e​-​c​a​s​e​s​.​jsp)

Po tej ope­ra­cji wystar­czy spraw­dzić kon­tek­sty doku­men­tow i skon­so­li­do­wać w jeden ewen­tu­al­ne nad­mia­ro­we przy­pad­ki uży­cia. I na koniec:

Jeśli nie masz mode­li poję­cio­wych, bra­ku­je Ci waż­ne­go ele­men­tu ukła­dan­ki w pro­jek­to­wa­niu roz­wią­zań, któ­ry jest nie­zwy­kle pomoc­ny w dostrze­ga­niu i prze­ka­zy­wa­niu ogól­ne­go obra­zu tych historyjek.”

Ronald Ross (Business Rules)

Źródła

Lucassen, G., Dalpiaz, F., van der Werf, J. M. E. M., & Brinkkemper, S. (2016). Improving agi­le requ­ire­ments: the Quality User Story fra­me­work and tool. Requirements Engineering, 21(3), 383 – 403. https://doi.org/10.1007/s00766-016‑0250‑x
OMG​.org. (2014, January). Business Process Model and Notation (BPMN). https://​www​.omg​.org/​s​p​e​c​/​B​P​MN/
OMG​.org. (2014, June 18). Model Driven Architecture (MDA). https://​www​.omg​.org/​m​da/
OMG​.org. (2019). Semantics of Business Vocabulary and Business Rules (SBVR). 334. https://​www​.omg​.org/​s​p​e​c​/​S​B​VR/
Ronald G. Ross. (2020). Business Knowledge Blueprints Enabling Your Data to Speak the Language of the Business (2nd Edition). Business Ruless Solution LLC.
Ross, R. G., & Fisher, L. (2020). Business Rules: Management and Execution.
Wautelet, Y., Heng, S., Kolp, M., & Mirbel, I. (2014). Unifying and Extending User Story Models. In M. Jarke, J. Mylopoulos, C. Quix, C. Rolland, Y. Manolopoulos, H. Mouratidis, & J. Horkoff (Eds.), Advanced Information Systems Engineering (Vol. 8484, pp. 211 – 225). Springer International Publishing. https://​doi​.org/​1​0​.​1​0​0​7​/​978 – 3‑319 – 07881-6_15
Zelinski, J. (2020). Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns. In Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities (pp. 78 – 89). IGI Global. https://​www​.igi​-glo​bal​.com/​b​o​o​k​/​a​p​p​l​i​c​a​t​i​o​n​s​-​a​p​p​r​o​a​c​h​e​s​-​o​b​j​e​c​t​-​o​r​i​e​n​t​e​d​-​s​o​f​t​w​a​r​e​/​2​3​5​699

Pełna Specyfikacja

Poniżej przy­kła­do­wy doku­ment wyge­ne­ro­wa­ny bez­po­śred­nio z Visual Paradigm, zawie­ra tak­że śladowanie. 

1. Procesy Business Process Diagram

Procesy Business Process Diagram

2. User Story

Historyjki użyt­kow­ni­ka jako wyma­ga­nia biznesowe.

ID

Nazwa

Rola

Produkt

Adresat

Opis

REQ001

Sprzedaż

Sprzedawca

Faktura

Klient

jako sprze­daw­ca chcę wysta­wić fak­tu­rę klientowi

REQ002

Wydanie towa­ru

Magazynier

Dokument WZ

Klient

jako maga­zy­nier chce wysta­wić Dokument WZ klientowi

REQ003

Rejestracja Zamówień

Pracownik BOK

Zamówienie zaku­pu

Sprzedawca

jako pra­cow­nik BOK chce zare­je­stro­wać zamó­wie­nie zaku­pu dla Sprzedawcy

REQ004

Śledzenie Zamówień

Klient

Zamówienie zaku­pu

Klient

Jako Klient chciał bym śle­dzić sta­tu­sy moich Zamówień zakupu

3. Diagram Przypadków Użycia

Diagram Przypadków Użycia

4. Specyfikacja

 

Nazwa

ID

 

Główni akto­rzy 

Pula zadań

!!

Sprzedaż

UC02

Sprzedawca

Magazyny

UC03

Magazynier

Zamówienia

UC01

Klient, Pracownik BOK

4.1. Sprzedaż

ID: UC02

Usługa pozwa­la wysta­wiać faktury.

4.1.1. Główni aktorzy 

Sprzedawca

4.1.2. Szczegóły

Complexity

śred­nia

Use Case Status

tyl­ko nazwa

Implementation Status

zapla­no­wa­na

Author

Jarosław Żeliński

Assumptions

Sprzedaż będzie doku­men­to­wa­na fak­tu­ra­mi w reje­strze sprzedaży

4.1.3. Wymagania 

4.1.3.1. Sprzedaż

ID: REQ001

jako sprze­daw­ca chcę wysta­wić fak­tu­rę klientowi

4.1.4. Relacje

Relacja

Z

Do

unnamed

Sprzedawca

Sprzedaż

4.1.5. Diagramy Podległe 

4.1.5.1. Faktura

Faktura

4.1.6. Śladowanie 

Typ

Wartość

Przekształcony z 

Procesy Business Process Diagram.Sprzedaż

4.2. Magazyny

ID: UC03

Usługa doku­men­tu­je wyda­wa­nie towa­ru na pod­sta­wie opła­co­nych faktur.

4.2.1. Główni aktorzy 

Magazynier

4.2.2. Szczegóły

Complexity

śred­nia

Use Case Status

tyl­ko nazwa

Implementation Status

zapla­no­wa­na

Author

Jarosław Żeliński

Assumptions

Operacje maga­zy­no­we doku­men­to­wa­ne są stan­dar­do­wy­mi doku­men­ta­mi księgowymi

4.2.3. Wymagania 

4.2.3.1. Wydanie towaru

ID: REQ002

jako maga­zy­nier chce wysta­wić Dokument WZ klientowi

4.2.4. Relacje

Relacja

Z

Do

unnamed

Magazynier

Magazyny

4.2.5. Diagramy Podległe 

4.2.5.1. Dokument WZ

Dokument WZ

4.2.6. Śladowanie 

Typ

Wartość

Przekształcony z 

Procesy Business Process Diagram.Wydanie z magazynu

4.3. Zamówienia

ID: UC01

Rejestr zamó­wień pozwa­la reje­stro­wać zamó­wie­nia, śle­dzić ich status.

4.3.1. Główni aktorzy 

Klient,  Pracownik BOK

4.3.2. Szczegóły

Complexity

śred­nia

Use Case Status

tyl­ko nazwa

Implementation Status

zapla­no­wa­na

Author

Jarosław Żeliński

Assumptions

Zamówienia od klien­tów są reje­stro­wa­ne jako Zamówienia zaku­pu w Rejestrze zamówień

4.3.3. Wymagania 

4.3.3.1. Rejestracja Zamówień

ID: REQ003

jako pra­cow­nik BOK chce zare­je­stro­wać zamó­wie­nie zaku­pu dla Sprzedawcy

4.3.3.2. Śledzenie Zamówień

ID: REQ004

Jako Klient chciał bym śle­dzić sta­tu­sy moich Zamówień zakupu

4.3.4. Relacje

Relacja

Z

Do

unnamed

Pracownik BOK

Zamówienia

unnamed

Klient

Zamówienia

4.3.5. Diagramy Podległe 

4.3.5.1. Zamówienia Zakupu

Zamówienia Zakupu

4.3.6. Śladowanie 

Typ

Wartość

Przekształcony z 

Procesy Business Process Diagram.Rejestracja zamó­wie­nia

Opis wymagań z użyciem Gherkin – czyli duuużo korniszonów…

Wstęp

Zostałem nie­daw­no zapy­ta­ny czy pomo­gę bo mamy już ponad 150 przy­pad­ków uży­cia w doku­men­ta­cji…”. Myślę sobie, to nie­moż­li­we, nie ma tak wiel­kich sys­te­mów (wyce­na oka­za­ła się w efek­cie pię­cio­krot­nie zawy­żo­na tyl­ko dla­te­go, że uży­to meto­dy zorien­to­wa­nej na user story”). 

Czytaj dalej… Opis wyma­gań z uży­ciem Gherkin – czy­li duuużo kor­ni­szo­nów…”

User Story i Story Mapping czyli jak podnieść koszty

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

A teraz user story:

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

Moje wra­że­nia:

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

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

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

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

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

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

Procedura – co to za zwierzę

Jednym z zabój­ców pro­jek­tów zwią­za­nych z mode­lo­wa­niem pro­ce­sów biz­ne­so­wych, jest ich nad­mier­na szcze­gó­ło­wość. Ktoś może powie­dzieć, że o te szcze­gó­ły wła­śnie cho­dzi”. Jeżeli tak mówi, to nie rozu­mie czym jest model pro­ce­sów biz­ne­so­wych, bo taki model to nie miej­sce na takie szcze­gó­ły w ana­li­zie. Jeżeli jed­nak prze­for­so­wa­na zosta­nie w pro­jek­cie teza mówią­ca, że mode­le pro­ce­sów mają zawie­rać wszyst­kie szcze­gó­ły”, otrzy­mu­je­my ster­ty nie­czy­tel­nych dia­gra­mów, nie pod­da­ją­cych się jakiej­kol­wiek dal­szej obróbce.

W arty­ku­le Poziomy mode­lo­wa­nia… opi­sa­łem hie­rar­chię szcze­gó­ło­wo­ści mode­li pro­ce­sów. Tu sku­pi­łem się na wal­ce z nad­mia­rem szcze­gó­łów na nich.

Diabeł tkwi w szczegółach

To czę­sty argu­ment za tym, by te szcze­gó­ły umiesz­czać na dia­gra­mach. Czym są te szczegóły?

Pojęcie pro­ce­du­ry. W popu­lar­nym pol­skim WIKI nie ma nie­ste­ty roz­wi­nię­tej defi­ni­cji poję­cia pro­ce­du­ra (stan na 24.09.2013):
proceduraWIKI

Pozostaje mi więc przy­jąć nie­co ści­ślej­szą niż powyż­sza, defi­ni­cję ze sł. j. pol­skie­go PWN jako bazę do dal­szych dywa­ga­cji (waż­na uwa­ga: słow­nik pojęć w doku­men­ta­cji pro­jek­to­wej pisa­nej po pol­sku, nie może być nie­zgod­ny ze słow­ni­kiem języ­ka pol­skie­go, może być co naj­wy­żej uszczegółowieniem):

Procedura: 1. okre­ślo­ne regu­ły postę­po­wa­nia w jakiejś spra­wie, zwy­kle o cha­rak­te­rze urzę­do­wym lub praw­nym, 2. w języ­kach pro­gra­mo­wa­nia: wydzie­lo­ny frag­ment algorytmu.

ISO_procedureWażne jest tu to, że pro­ce­du­ra to gene­ral­nie okre­ślo­ne regu­ły postę­po­wa­nia (przy­po­mi­nam, że regu­łą postę­po­wa­nia jest tak­że lista czyn­no­ści i sama kolej­ność ich wyko­na­nia). Wskazówką by tę defi­ni­cję dopre­cy­zo­wać jest tak­że nawią­za­nie (2. zna­cze­nie) to pro­gra­mo­wa­nia: wydzie­lo­ny frag­ment algo­ryt­mu. Powyższe pozwa­la uznać, że kon­kret­na pro­ce­du­ra to postę­po­wa­nie w jed­nej spra­wie (jed­nym celu). Czy postę­po­wa­nie w spra­wie (albo wydzie­lo­ny frag­ment algo­ryt­mu) da ocze­ki­wa­ny rezul­tat jeże­li je prze­rwie­my? Nie. Tak więc defi­ni­cja pro­ce­du­ry, któ­ra się tu sama wręcz narzu­ca (i taką przyj­mu­ję w pro­jek­tach) brzmi:

pro­ce­du­ra – ciąg czyn­no­ści (kro­ków postę­po­wa­nia), któ­re­go prze­rwa­nie pro­wa­dzi do utra­ty celo­wo­ści wyko­ny­wa­nia tych czynności

Popatrzmy też jak pro­ce­du­rę defi­niu­ję nor­ma tech­no­lo­gicz­na ISO9000:

pro­ce­du­ra: okre­ślo­ny spo­sób reali­za­cji dzia­łań lub procesów

Definicja ta nie koli­du­je z moją, ma jed­nak pew­ną wadę: nie pre­cy­zu­je pozio­mu abs­trak­cji (lub szcze­gó­ło­wo­ści). Innymi sło­wy, czy obsłu­ga zamó­wie­nia opi­sa­na jako zare­je­stro­wa­nie doku­men­tu zamó­wie­nia, wysta­wie­nie listu prze­wo­zo­we­go wg. wzo­ru i zgod­nie z tre­ścią zamó­wie­nia oraz wysta­wie­nie fak­tu­ry sprze­da­ży” to pro­ce­du­ra czy sekwen­cja pro­ce­sów mają­cych dopie­ro swo­je pro­ce­du­ry (np. jak prze­bie­ga reje­stra­cja Zamówienia)? Moja defi­ni­cja jaw­nie wska­zu­je, że pro­ce­du­ra opi­su­je naj­niż­szy poziom szcze­gó­ło­wo­ści: ato­mo­wych pro­ce­sów biz­ne­so­wych. tak więc mamy to łań­cuch pro­ce­sów i wyma­ga­ny bra­ku­ją­cy opis pro­ce­du­ry reje­stra­cji Zamówienia”. 

Model procesów biznesowych

Czy przy­pad­kiem nie dzie­lę wło­sa na czwo­ro? Moim zda­niem nie. Dzięki powyż­sze­mu moż­li­we jest zapa­no­wa­nie nad szcze­gó­ło­wo­ścią pro­jek­tu ana­li­zy pro­ce­sów biz­ne­so­wych. Mając defi­ni­cję pojęć pro­ces biz­ne­so­wy, pod­pro­ces (dekom­po­zy­cja pro­ce­su) oraz pro­ce­du­ra mam dosko­na­łe narzę­dzie do kwa­li­fi­ko­wa­nia ele­men­tów wie­dzy o tym co się dzie­je” jako pro­ce­sy, pod-pro­ce­sy czy wła­snie procedury.

Zwróćmy uwa­gę, pro­ces biz­ne­so­wy naj­wyż­sze­go pozio­mu to tak zwa­ny pro­ces end-to-end. Jego dekom­po­zy­cja (kolej­ne dekom­po­zy­cje) dopro­wa­dzą nas do ele­men­tar­nych (ato­mo­wych) pro­ce­sów biz­ne­so­wych. Atomowy pro­ces biz­ne­so­wy jest doku­men­to­wa­ny (to jak prze­bie­ga) jako pro­ce­du­ra. Procedury, z regu­ły, nie są już dia­gra­ma­mi a wypunk­to­wa­ny­mi lista­mi, recep­ta­mi” dzia­ła­nia. Wszystkie szcze­gó­ły wyko­ny­wa­nych czyn­no­ści są zawar­te, nie na dia­gra­mie pro­ce­su, a wła­śnie w tre­ści pro­ce­du­ry (tu pole­cam arty­kuł: Co to jest pro­ces biz­ne­so­wy).

Mając więc powyż­szą defi­ni­cję pro­ce­du­ry, łatwiej nam teraz jest zakwa­li­fi­ko­wać infor­ma­cję to tym, że nale­ży zeska­no­wać przy­cho­dzą­cy doku­ment, jako ele­ment (krok) pro­ce­du­ry a nie jako pro­ces biz­ne­so­wy. Samo ska­no­wa­nie, bez nastę­pu­ją­cych po nim dal­szych kro­ków postę­po­wa­nia z doku­men­tem, do nicze­go nie słu­ży, więc nie może być (w myśl powyż­szych defi­ni­cji) pro­ce­sem biz­ne­so­wym. Jest zapi­sem w tre­ści pro­ce­du­ry opi­su­ją­cej spo­sób reali­za­cji pro­ce­su przy­ję­cia dokumentu.

Bez tej for­ma­li­za­cji (ści­słe sto­so­wa­nie zde­fi­nio­wa­nych pojęć, tak­że tych z uży­tej nota­cji) pró­by mode­lo­wa­nia pro­ce­sów pro­wa­dzą naj­czę­ściej do powsta­wa­nia mon­stru­al­nych ilo­ści nie­czy­tel­nych dia­gra­mów (widy­wa­łem doku­men­ta­cje, gdzie było dla jed­nej fir­my powsta­łe bli­sko tysiąc stron! Masakra). To kom­plet­nie nie­przy­dat­ne dokumenty.

Co jesz­cze nam daje sto­so­wa­nie powyż­szych defi­ni­cji? Możliwość jed­no­znacz­ne­go przej­ścia” (śla­do­wa­nie) z mode­li pro­ce­sów biz­ne­so­wych na mode­le przy­pad­ków uży­cia bo ato­mo­wy pro­ces, zakwa­li­fi­ko­wa­ny do zakre­su pro­jek­tu jako wyma­ga­na usłu­ga opro­gra­mo­wa­nia, to przy­pa­dek uży­cia nowe­go opro­gra­mo­wa­nia, zaś pro­ce­du­ra tego pro­ce­su to nic inne­go jak sce­na­riusz tego przy­pad­ku uży­cia lub jak ktoś woli: user sto­ry. Z innej stro­ny: jeże­li mamy wdro­żo­ną pro­ce­so­wą nor­mę np. ISO9000, to mode­lu­jąc pro­ce­sy biz­ne­so­we i pod­pi­na­jąc” do nich pro­ce­du­ry z księ­gi jako­ści, szyb­ko się prze­ko­na­my, czy nasze ISO to nie jest przy­pad­kiem fikcją.

User story czyli nic nie poprawić a może nawet bardziej skomplikować

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

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

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

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

analiza uklad geocentryczny

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

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

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

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

User-Stories

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

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

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

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

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

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

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

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

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

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

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

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

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

3.kontekst dla wymagania.

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

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

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