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.

Znaczenie ma nie wielkość projektu, a cykl jego życia…

Podczas jed­nej z wie­lu moich dys­ku­sji na forach na tema­ty wyso­kich nakła­dów na ana­li­zę i pro­jek­to­wa­nie” :), padło stwierdzenie:

Mam jed­nak wra­że­nie, że zna­cze­nie może tu mieć ska­la pro­jek­tu o któ­rym ja pisze. Nie jest to jakiś wiel­ki sys­tem. Jest to pro­sta apli­ka­cja webo­wa w php. Myślę, że to w jakiś spo­sób uspra­wie­dli­wia pew­ne uprosz­cze­nia i skró­ty. Czy się mylę?

Obawiam się, że nie­ste­ty tak. Znaczenie ma, nie wiel­kość pro­jek­tu, a cykl jego życia. Jeżeli pla­no­wa­ne jest stwo­rze­nie efe­me­ry­dy, czy­li powsta­nie apli­ka­cja, któ­rą wywa­li­my do kosza po kwar­ta­le uży­wa­nia np. apli­ka­cja obsłu­gu­ją­ca jed­ną kam­pa­nię pro­mo­cyj­ną, po któ­rej potrzeb­ne są potem tyl­ko dane, pro­gram któ­ry je zbie­rał leci do kosza, jest już niepotrzebny.

Jeżeli jed­nak pla­no­wa­na jest apli­ka­cja, któ­ra ma przed sobą kil­ka lat życia, to jed­no jest pew­ne: poja­wią się nowe wyma­ga­nia, o któ­rych dziś nie mamy bla­de­go poję­cia… taka apli­ka­cja musi być maj­stersz­ty­kiem pro­jek­to­wym, bo popra­wia­nie cze­goś nie­po­pra­wial­ne­go” jest bar­dzo kosz­tow­ne… Należy pamię­tać, że nawet
wiel­ka efe­me­ry­da wyma­ga mniej pra­cy ana­li­tycz­no-pro­jek­to­wej niż malut­ka apli­ka­cja na kil­ka lat…

Podstawową rze­czą, jaka nale­ży okre­ślić pod­czas ana­li­zy biz­ne­so­wej, powin­no być jed­no z klu­czo­wych wyma­gań jako­ścio­wych(!) jest nim wła­śnie zapla­no­wa­nie cyklu życia apli­ka­cji (pro­duk­tu). Poniżej pro­sty diagram:

Na osi pio­no­wej mamy kosz­ty, oś pozio­ma to czas życia apli­ka­cji (opr. wła­sne autora).

Czerwona linia cią­gła to pro­jekt ” na żywioł”. Ograniczono do mini­mum ana­li­zę i pro­jek­to­wa­nie apli­ka­cji, wytwo­rze­nie jej nie było więc zbyt kosz­tow­ne a samo admi­ni­stro­wa­nie jest zawsze kosz­tem niskim. Jednak każ­da inge­ren­cja w zmia­nę (w tym roz­bu­do­wę) funk­cjo­nal­no­ści to nie­mal­że kolej­ny pro­jekt o ska­li czę­sto porów­ny­wal­nej z pier­wot­nym wytwo­rze­niem. Linia prze­ry­wa­na obra­zu­je nara­sta­ją­ce w cza­sie kosz­ty pono­szo­ne na utrzy­ma­nie przy życiu” takie­go produktu.

Brak pier­wot­ne­go pro­jek­tu powo­du­je, że wyma­ga­nia są iden­ty­fi­ko­wa­ne poprzez kolej­ne pro­to­ty­py (są nimi kolej­ne wer­sje). Projekty na żywioł” tak­że wiec powsta­je dłu­go”. Wymaga dodat­ko­we­go cza­su na te ite­ra­cje i raczej nigdy nie są odda­wa­ne do użyt­ku apli­ka­cje w pierw­szej wersji.

Linia zie­lo­na, to ana­li­za i pro­jek­to­wa­nie nasta­wio­ne na opty­ma­li­za­cję archi­tek­tu­ry, przy­szłe zmia­ny i roz­wój. Tu koszt wytwo­rze­nia, poprze­dzo­ne­go ana­li­zą i pro­jek­to­wa­niem, jest wyż­szy, bywa, że nawet dwu­krot­nie. Co cie­ka­we jed­nak, z regu­ły nie trwa to dłużej,bo czę­sto opro­gra­mo­wa­nie jest odda­wa­ne do użyt­ku w pierw­szej, góra dru­giej ite­ra­cji. Linia prze­ry­wa­na obra­zu­je, ana­lo­gicz­nie, nara­sta­ją­ce kosz­ty utrzy­ma­nia i roz­wo­ju w cza­sie, tak powsta­łej aplikacji.

Każdy pro­jekt (efe­me­ry­da vs. long life”), porów­nu­jąc dwa powyż­sze sce­na­riu­sze, ma próg ren­tow­no­ści. Najczęściej jest to moment pierw­szej poważ­nej zmia­ny lub roz­sze­rze­nia (sza­ry obszar na dia­gra­mie to czas prze­pła­ca­nia dla wer­sji czer­wo­nej na żywioł”). Niestety, gdy to odkry­je księ­go­wość (kon­tro­ling) jest za póź­no, bo rezy­gna­cja na tym eta­pie jest jako decy­zja bar­dzo trud­na a tak­że kosz­tow­na. Nie zmie­nia to fak­tu, że rezy­gna­cja na tym eta­pie jest naj­czę­ściej naj­roz­sąd­niej­szym wyj­ściem, tu jed­nak działa

sta­ra zasa­da mani­pu­la­cji, tak zwa­na niska pił­ka: łatwo (małym kosz­tem) roz­po­czę­ty pro­jekt o szyb­ko rosną­cych kosz­tach w cza­sie jest men­tal­nie trud­ny do zarzu­ce­nia a rosną­ce kosz­ty są uspra­wie­dli­wia­ne i racjo­nal­ne myśle­nie jest odkła­da­ne. Dostawcy opro­gra­mo­wa­nia sto­su­ją nie raz tę meto­dę mani­pu­la­cji z peł­ną pre­me­dy­ta­cją,

nie raz jed­nak to nabyw­ca sam się mani­pu­lu­je” wie­rząc na począt­ku, że moż­na bar­dzo tanio i bar­dzo dobrze. Potem ma już miej­sce tyl­ko obro­na wła­sne­go hono­ru”, co z racjo­nal­nym zarzą­dza­niem kosz­ta­mi nie ma nic wspól­ne­go. Tu win­ny jestem uwagę:

pro­jek­ty na żywioł znacz­nie czę­ściej mają prze­kra­cza­ne ter­mi­ny i budże­ty (bada­nia mówią, że 75% pro­jek­tów ma prze­kro­czo­ny budżet śred­nio o 60% z winy źle okre­ślo­nych wyma­gań) niż pro­jek­ty pro­wa­dzo­ne meto­dycz­nie”.

Jak więc zaradzić dużym kosztom utrzymania oprogramowania?

Jest tyl­ko jeden spo­sób: pla­no­wać ren­tow­ność i czas życia każ­de­go pro­jek­tu i jego pro­duk­tu. Warto zwró­cić uwa­gę, że poja­wia się tu [[róż­ni­ca pomię­dzy pro­jek­tem a programem]]).

Aplikacje zapla­no­wa­ne jako efe­me­ry­dy, to pro­duk­ty pro­jek­tów, nale­ży bez lito­ści i sen­ty­men­tów wyrzu­cać je jak zro­bią swo­je”. Zmiana pla­nów z ich wyrzu­ce­nia na dal­szy roz­wój to naj­czę­ściej krach finan­so­wy pro­jek­tu. W takich wypad­kach, na bazie doświad­czeń z eks­plo­ata­cji efe­me­ry­dy, naj­le­piej zapro­jek­to­wać nowy sys­tem z pla­nem na kil­ka lat eksploatacji.

Aplikacje pla­no­wa­ne jako narzę­dzia pra­cy na lata, bez­względ­nie dobrze pro­jek­to­wać i poprze­dzać ana­li­zą biz­ne­so­wą przed ich wytwa­rza­niem, bo wte­dy mamy już do czy­nie­nia nie z pro­jek­tem a wła­śnie z programem.

Podstawowym błę­dem, moim zda­niem, jest trak­to­wa­nie zaku­pu lub wytwo­rze­nia opro­gra­mo­wa­nia pla­no­wa­ne­go na dłu­gie uży­wa­nie” jako pro­jek­tu pro­gra­mi­stycz­ne­go. To nie pro­jekt, to pro­gram! Projektem jest wytwo­rze­nie pier­wot­nej wer­sji, potem pro­jek­ta­mi są kolej­no wpro­wa­dza­ne nowe funk­cjo­nal­no­ści lub zmia­ny. Całość to program.

A teraz pro­szę sobie wyobra­zić, że więk­szość opro­gra­mo­wa­nia ERP czy CRM na naszym ryn­ku, to pro­duk­ty, któ­re pier­wot­nie powsta­ły na potrze­by jed­ne­go kon­kret­ne­go zama­wia­ją­ce­go a potem, jak się uda­ło wdro­żyć w jed­nej fir­mie, ktoś docho­dził do wnio­sku: to może sprze­da­waj­my to kolej­nym klien­tom”… resz­tę sami Państwo sobie dopowiedzcie.

Powyższe nasu­wa od razu kolej­ny wnio­sek: zama­wia­ją­cy naj­czę­ściej for­mu­łu­ją zapy­ta­nia w spo­sób pozwa­la­ją­cy dostaw­com skła­dać ofer­ty na pierw­szy etap, pole­ga­ją­cy tyl­ko na dostar­cze­niu i wdro­że­niu. Jak widać z zasa­dy wygry­wa­ją tu pro­jek­ty na żywioł”. Żądanie od dostaw­ców uję­cia kosz­tów utrzy­ma­nia (tak zwa­ny main­te­nan­ce”) nicze­go nie zmie­nia bo to tyl­ko sta­ła opla­ta admi­ni­stra­cyj­na. Jedynym spo­so­bem na rze­tel­ne porów­na­nie ofert jest ope­ro­wa­nie kosz­tem cyklu życia dostar­czo­ne­go produktu.

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

SCRUM

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

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

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

Statystyka pracochłonności projektów IT

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

A co jest prawdą?

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

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

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

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

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

I dalej:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

A co mówią statystyki?

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

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

Na zakończenie

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

Dilbert wymagania na oprogramowanie