http://www.modernanalyst.com/Resources/BusinessAnalystHumor/tabid/218/Default.aspx?ArticleType=ArticleView&ArticleID=2471

Zwinna analiza biznesowa to mit czy fakt?

Agile busi­ness ana­lyst has the capa­bi­li­ty to keep the whe­el rol­ling. They?re a trans­for­ma­ti­ve fun­nel thro­ugh which a requ­ire­ment pas­ses down to the deli­ve­ry path towards an expec­ted out­co­me. This SDLC machi­ne needs con­ti­nu­ous fuel in the form of well-defi­ned and infor­med infor­ma­tion which is pro­vi­ded by an agi­le busi­ness ana­lyst. As long as an agi­le busi­ness ana­lyst does the job, this machi­ne will rema­in on its cour­se to deli­ver gre­ater solutions.Coming to our ori­gi­nal question, is an agi­le busi­ness ana­lyst a myth or a reali­ty? There is a cle­ar answer. It is a reali­ty if an orga­ni­za­tion reali­zes the value, but it is a myth for imma­tu­re orga­ni­za­tions who­se pro­ces­ses are ill-defi­ned and are nowhe­re on a path towards best prac­ti­ces. (Is Agile Business Analyst a Myth or a Reality? )

Tak więc (zwin­ny) ana­li­tyk biz­ne­so­wy to model pra­cy pole­ga­ją­cy na sta­łym dostar­cza­niu (na eta­pie imple­men­ta­cji) kolej­nych infor­ma­cji. Projekt two­rze­nia apli­ka­cji zawsze trwa w cza­sie, więc w toku two­rze­nia opro­gra­mo­wa­nia zmie­nia się biznes. 

Developerzy czę­sto mówią, że klient zmie­nia im wyma­ga­nia, a tak na praw­dę ktoś zbyt wcze­śnie zapi­sał zbyt wie­le szcze­gó­łów. Implementacja dedy­ko­wa­ne­go opro­gra­mo­wa­nia to tak na praw­de pętla ite­ra­cyj­no-przy­ro­sto­wa: zbie­ra­my infor­ma­cje potrzeb­ne do wytwo­rze­nia jed­nej usłu­gi apli­ka­cyj­nej i imple­men­tu­je­my ją, wszel­kie szcze­gó­ły odkła­da­my na ostat­ni moment. Wymaga to jed­nak zmia­ny podej­ścia. Trzy lata temu pisa­łem na tym blogu:

Rynek zmie­nia się szyb­ko, więc nie ma sen­su szcze­gó­ło­we pro­jek­to­wa­nie cze­go­kol­wiek z uwa­gi na czas jaki zaj­mie takie pro­jek­to­wa­nie i ryzy­ko, że taki pro­jekt sta­nie się szyb­ko nie­ak­tu­al­ny. Nikt roz­sąd­ny nie nama­wia dzi­siaj do cze­goś o wdzięcz­nej nazwie ??water­fall?. Co więc zro­bić? Dla dużych pro­jek­tów two­rzy­my archi­tek­tu­rę, opi­su­je­my mecha­ni­zmy dzia­ła­nia, poli­ty­kę roz­bu­do­wy i opis cyklu życia. Czyli to co pozwo­li roz­wi­jać roz­wią­za­nie meto­dą ite­­ra­­cy­j­no-przy­­ro­­sto­­wą, w razie potrze­by pozwo­li na prze­pro­jek­to­wa­nie, ale jako całość nadal będzie spój­ne, nie będzie wyma­ga­ło wymia­ny cało­ści gdy zmie­nią się warun­ki na ryn­ku.Można w tym miej­scu zary­zy­ko­wać tezę, że nie ma cze­goś takie­go jak ??inży­nie­ria wyma­gań? bo czym ona jest i co jest jej pro­duk­tem? Uporządkowany spis życzeń? Mamy nato­miast na pew­no ??inży­nie­rię sys­te­mów?.? sys­te­ma­mi są orga­ni­za­cje a tak­że narzę­dzia jakich uży­wa­ją np. opro­gra­mo­wa­nie? (Wymagania umar­ły. Rozwiązaniem jest cykl życia pro­duk­tu | | Jarosław Żeliński IT-Consulting)

Z cze­go nale­ży więc od razu zre­zy­gno­wać? Z opra­co­wa­nia rela­cyj­ne­go mode­lu (bazy) danych dla całej apli­ka­cji, i prze­sta­wić sie na idee mikro-ser­wi­sów, czy­li uzna­nia, że apli­ka­cja nie jest mono­li­tem a zesta­wem kom­po­nen­tów reali­zu­ją­cych usłu­gi apli­ka­cyj­ne. Usługi apli­ka­cyj­ne mode­lu­je­my jako Przypadki Użycia (nota­cja UML) i to sta­no­wi kon­takt z dostaw­cą. Jednak czar­na skrzyn­ka” (opis nie zawie­ra­ją­cy mecha­ni­zmu dzia­ła­nia) jest bar­dzo ryzy­kow­ny, dla­te­go sku­tecz­ne meto­dy doku­men­to­wa­nia wyma­gań, to meto­dy zorien­to­wa­nie na mode­le (MDA) opi­su­ją­ce logi­kę dzia­ła­nia sys­te­mu (model jako wyma­ga­nie), a zamiast two­rze­nia kor­po­ra­cyj­ne­go rela­cyj­ne­go mode­lu danych, zamy­ka­my się w doku­men­tach jako ele­men­tar­nych nośni­kach danych (i nie boimy sie redun­dan­cji danych w całym sys­te­mie). Ogromne i szcze­gó­ło­we doku­men­ty i mode­le są wyłącz­nie stra­tą cza­su i pieniędzy:

(Designing Object Systems: Object-Oriented Modelling with Syntropy Textbook Binding ? November 18, 1994 by Steve Cook (Author), John Daniels (Author))
(Designing Object Systems: Object-Oriented Modelling with Syntropy Textbook Binding ? November 18, 1994 by Steve Cook (Author), John Daniels (Author))

Dlatego od lat fascy­nu­je mnie nie­kon­se­kwen­cja wie­lu deve­lo­pe­rów: naj­pierw wie­sza­ją psy na meto­dach nazy­wa­nych water­fall”, a już chwi­lę potem zaczy­na­ją pro­jek­to­wa­nie jed­ne­go rela­cyj­ne­go mode­lu danych dla całe­go projektu! 

Zwinny Analityk Biznesowy utrzy­mu­je pętlę ite­ra­cji przy­ro­stu zakre­su pro­jek­tu: mając opra­co­wa­ną archi­tek­tu­rę cało­ści i para­dyg­mat (poli­ty­kę) pro­jek­to­wa­nia (np. obiek­to­wy), dostar­cza cyklicz­nie i zawsze na ostat­ni moment, kolej­ne szcze­gó­ły, bo wte­dy ma naj­więk­szą wie­dzę, i ryzy­ko zmia­ny zakre­su jest naj­mniej­sze. To się nazy­wa «nad­zór autorski».

Tak więc klu­czem do suk­ce­su, w dzi­siej­szych warun­kach, jest model opar­ty na kom­po­nen­to­wej archi­tek­tu­rze i ite­ra­cyj­nym dostar­cza­niu kolej­nych usług apli­ka­cyj­nych . Jak? Analiza, pro­jek­to­wa­nie i implementacja:

  • Analiza biz­ne­so­wa (pro­ce­sy biz­ne­so­we) i sys­te­mu infor­ma­cji w orga­ni­za­cji, i decy­zja o ewen­tu­al­nej stan­da­ry­za­cji doku­men­tów i pro­ce­sów. (nota­cje BMM, SBVR, BPMN, UML)
  • Opracowanie mode­lu infor­ma­cyj­ne­go czy­li sza­blo­nów doku­men­tów, ich wza­jem­nych powią­zań i słow­ni­ka pojęć. (nota­cja UML, SBVR)
  • Opracowaniu archi­tek­tu­ry cało­ści i opi­sa­nie cyklu życia pro­jek­tu (nota­cja UML).
  • Przejścia do fazy imple­men­ta­cji z nad­zo­rem autor­skim auto­ra pro­jek­tu (zarzą­dza­nie zmia­ną, sta­ła aktu­ali­za­cja doku­men­ta­cji systemu).

Pierwsze przy punk­ty, ich reali­za­cja, nie powin­ny nigdy trwać dużej niż kwar­tał, a doku­men­ta­cja pier­wot­na raczej nie powin­na prze­kro­czyć nigdy 100 stron, bez wzglę­dy na wiel­kość pro­jek­tu! Im więk­szy pro­jekt tym bar­dziej doku­men­ta­cja począt­ko­wa powin­na być abs­trak­cyj­nym mode­lem. Innymi sło­wy: im więk­szy i dłu­żej trwa­ją­cy pro­jekt, tym bar­dziej jego opis powi­nien być stra­te­gią jego reali­za­cji, a nie taktyką. 

Czy zwin­ny ana­li­tyk biz­ne­so­wy jest mitem czy rze­czy­wi­sto­ścią? Istnieje jasna odpo­wiedź: to rze­czy­wi­stość, jeśli orga­ni­za­cja zda­je sobie spra­wę z war­to­ści takiej pra­cy, ale jest mitem dla nie­doj­rza­łych orga­ni­za­cji, któ­rych pro­ce­sy są źle zdefiniowane.

Źródła

Steve Burbeck (2012) How to use Model-View-Controller (MVC). Available at: https://web.archive.org/web/20120729161926/http://st-www.cs.illinois.edu/users/smarch/st-docs/mvc.html (Accessed: 5 January 2020).
Jenney, J. et al. (2010) Modern methods of sys­tems engi­ne­ering: with an intro­duc­tion to pat­tern and model based methods. Erscheinungsort nicht ermit­tel­bar: Joe Jenney.
Awaysheh, F.M. et al. (2019) Next-Generation Big Data Federation Access Control: A Reference Model’, arXiv:1912.11588 [cs] [Preprint]. Available at: http://​arxiv​.org/​a​b​s​/​1​9​1​2​.​1​1​588 (Accessed: 4 January 2020).
Garland, J. and Anthony, R. (2003) Large-sca­le softwa­re archi­tec­tu­re: a prac­ti­cal guide using UML. Chichester ; New York: J. Wiley.
Kumar, R.N.P. and Patil, S. (2019) A System and Method for impro­ving the Model Based Systems Engineering Environment capa­bi­li­ty’, INCOSE International Symposium, 29(S1), pp. 277 – 290. Available at: https://​doi​.org/​1​0​.​1​0​0​2​/​j​.​2​334 – 5837.2019.00685.x.

Inne artykuły na podobny temat

Komentarze

  1. Anna 11 lutego 2020 at 11:55

    Biorę udział w dużym pro­jek­cie 1 – 2 lata. Brak archi­tek­tu­ry dla cało­ści, zaczę­łam ana­li­zo­wać dla poszcze­gól­nych modu­łów, ale cross archi­tek­tu­rę całej orga­ni­za­cji. Udało się na szczę­ście zor­ga­ni­zo­wać warsz­ta­ty pro­ce­so­we, na któ­rych mam zamiar uzgod­nić głów­ne pro­ce­sy z wejściem/wyjściem infor­ma­cji i wewnętrz­ny­mi regu­la­cja­mi. Z nich wyj­dzie powią­za­nia poszcze­gól­nych modu­łów, któ­re będzie­my już odda­wać stop­nio­wo. Czy wg Pana to ok?

    • Jarosław Żeliński 11 lutego 2020 at 12:26

      Wygląda dobrze 🙂 dla uporządkowania:
      1. pro­sty dia­gram poka­zu­ją­cy jakie pod­mio­ty (inne fir­my itp.) bio­rą w tym udział, cho­dzi o wszel­kie poten­cjal­ne integracje
      2. pro­ce­sy biz­ne­so­we ale UWAGA! Nie algo­ryt­mi­zu­je­my orga­ni­za­cji!, to powin­no być kil­ka, maks. kil­ka­na­ście dia­gra­mów (pole­cam BPMN) aktyw­no­ści (task w BPMN) z dokład­no­ścią do two­rze­nia doku­men­tu lub zmia­ny statusu
      3. inwen­ta­ry­za­cja apli­ka­cji (nazwa, któ­re doku­men­ty two­rzy, któ­rych wyma­ga itp., integracje)

      Czym tu jest moduł”?

  2. Jerzy Wickowski 9 marca 2020 at 07:45

    Cześć,
    Bardzo spodo­ba­ło mi się stwier­dze­nie, że ana­li­tyk powi­nien dostar­czać wyma­ga­nia na ostat­ni moment, bo wte­dy ma naj­więk­szą wiedzę.
    Patrzę na to z per­spek­ty­wy pro­gra­mi­stycz­no-archi­tek­to­nicz­nej i dobra archi­tek­tu­ra pozwa­la odło­że­nie wią­żą­cych decy­zji w czasie.
    Te dwa podej­ścia skle­ją się doskonale 🙂

    • Jarosław Żeliński 9 marca 2020 at 08:24

      Podstawowym celem two­rze­nia archi­tek­tu­ry w pro­jek­cie, jest zro­zu­mie­nie funk­cji sys­te­mu i usta­le­nie poli­ty­ki jego budo­wy, zasad uzu­peł­nia­nia jej szcze­gó­ła­mi. Innymi sło­wy archi­tek­tu­ra sys­te­mu to poli­ty­ka jego two­rze­nia i roz­wo­ju. Na począt­ku pro­jek­tu nie ma żad­ne­go zna­cze­nia z ilu pól skła­da sie fak­tu­ra, zna­cze­nie ma to, do cze­go ona słu­ży w całym sys­te­mie. To dla­te­go pro­jek­ty bazu­ją­ce na roz­po­czy­na­niu od mode­lu danych (rela­cyj­ne­go, czy­li od deta­li) coraz czę­ściej koń­czą na śmiet­ni­ku. Publikacje z tą tezą poja­wia­ły się już w latach 90-tych.

Dodaj komentarz

Twój adres email nie zostanie opublikowany

Komentuj i zadawaj pytania autorowi.

Identyfikator *
E-mail *
Witryna internetowa

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