Modernizacja Manifestu Agile

Dostałem maila :):

Innovation isn?t easy, but it?s less pain­ful when the tools you need to build com­plex pro­ducts are fami­liar and acces­si­ble. In that light, small star­tups have it pret­ty good. But for lar­ge, disper­sed and matu­re orga­ni­za­tions, put­ting Agile pro­ces­ses into prac­ti­ce can feel like an unsca­la­ble ideal.

The Agile Manifesto debu­ted in 2001. Your com­pa­ny, and the ways you help it move for­ward have evo­lved. Work methods sho­uld keep up with you, not the other way aro­und. Here?s how to mer­ge the Manifesto?s aims with the ways you work, so that you keep gro­wing, thri­ving and profiting.

Czyli jest czas by wycią­gnąć wnio­ski. Mail odsy­ła do pobra­nia cie­ka­we­go opracowania:

http://​go​.jama​so​ftwa​re​.com/​r​s​/​j​a​m​a​s​o​f​t​w​a​r​e​/​i​m​a​g​e​s​/​j​a​m​a​-​a​-​m​o​d​e​r​n​-​t​a​k​e​-​o​n​-​t​h​e​-​a​g​i​l​e​-​m​a​n​i​f​e​s​t​o​-​E​D​U​.​pdf

Nieudane wdrożenie wielkiego systemu informatycznego w USA – a co u nas?

Jakiś czas temu pisa­łem o swo­ich prze­my­śle­niach po roz­mo­wie z pew­nym dyrek­to­rem finan­so­wym jed­ne­go z moich klien­tów. Powiedział mię­dzy inny­mi, że albo pro­jekt zosta­nie zre­ali­zo­wa­ny w roku jed­nym budże­to­wym, albo on nie wyda na zgo­dy na jego roz­po­czę­cie. W czym pro­blem? Ano w tym, że przy obec­nym tem­pie zmian na ryn­ku, pro­gno­za wykra­cza­ją­ca w przy­szłość dalej niż rok to wró­że­nie z fusów… Skutek? Jak oce­nić sto­pę zwro­tu z inwe­sty­cji w coś, co jest naj­bar­dziej płyn­nym, podat­nym na zmia­ny wyma­gań, zaso­bem w orga­ni­za­cji, czy­li sys­tem wspo­ma­ga­ją­cy zarzą­dza­nie nią?

Rynek sta­le się roz­wi­ja i doj­rze­wa. Praktycznie każ­da więk­sza fir­ma doświad­czy­ła w jakiejś for­mie wdro­że­nia goto­we­go, dosto­so­wy­wa­ne­go do potrzeb, opro­gra­mo­wa­nia ERP. Warto jed­nak pod­kre­ślić, że idea jed­ne­go ?super sys­te­mu? ERP II, odcho­dzi powo­li do lamu­sa. Moim zda­niem to kwe­stia roku, dwóch. Pierwsze symp­to­my to zale­ce­nia pro­du­cen­tów dużych sys­te­mów: wdra­żać goto­we opro­gra­mo­wa­nie w posta­ci ?goto­wej? tyl­ko tam gdzie pasu­je, obsza­ry spe­cy­ficz­ne dla fir­my opi­sać i zapro­jek­to­wać dla nich dedy­ko­wa­ne roz­wią­za­nie i zin­te­gro­wać. (czy­taj Biznes wycho­dzi z objęć sys­te­mu ? mono­li­tycz­ne­go ERP).

Co z tym zro­bić? Dzielić, jak to mawia­ją nie­któ­rzy kie­row­ni­cy pro­jek­tów: czło­wiek może zjeść nawet sło­nia, jak? Kęs po kęsie. Tak więc duży pro­jekt nale­ży podzie­lić na samo­dziel­ne” pod­sys­te­my, jed­nak ta samo­dziel­ność ma dwa aspek­ty: każ­dy pod­sys­tem musi sam z sie­bie do cze­goś słu­żyć, powi­nien wno­sić war­tość doda­ną. Drugi: każ­dy pro­jek­to­wa­ny pod­sys­tem powi­nien być zapla­no­wa­ny jako poten­cjal­nie samo­dziel­ne narzę­dzie (inwe­sty­cja) na wypa­dek gdy­by pozo­sta­łe nie zosta­ły nigdy wytwo­rzo­ne np. z powo­du zmian na rynku.

Ale o tym pisa­łem wię­cej już wcze­śniej. Kolejnym pro­ble­mem jest nie­ste­ty jakość projektowania:

Według fir­my ana­li­tycz­nej Gartner oko­ło 60 proc. wdro­żeń wiel­kich sys­te­mów infor­ma­tycz­nych koń­czy się klę­ską. Przyczyną jest m.in. nie­umie­jęt­ność prze­ło­że­nia pro­ce­sów dzia­ła­ją­cych w fir­mie na dzia­ła­nie sys­te­mu infor­ma­tycz­ne­go, brak dosta­tecz­ne­go wspar­cia ze stro­ny pra­cow­ni­ków i kie­row­nic­twa fir­my (cza­sem nawet jaw­ny opór), złe przy­go­to­wa­nie wdro­że­nia lub jego pro­wa­dze­nie. (za Serwis Nauka w Polsce – PAP SA).

Jak widać, jakość pro­jek­to­wa­nia jest klu­czem, zresz­tą nie tyl­ko w przy­pad­ków dużych sys­te­mów ale w każ­dym przy­pad­ku. Różnica jest taka, że jeże­li nie­jed­na fir­ma świa­do­mie ryzy­ku­je kil­ka­set tysię­cy rezy­gnu­jąc z eta­pu nie­za­leż­nej ana­li­zy i pro­jek­to­wa­nia war­tej ok. 10 – 20% tej kwo­ty, to podob­ne podej­ście pro­jek­ty war­te milio­nów jest już raczej nieracjonalne…

Po raz kolej­ny już spraw­dza się teza, że wdra­ża­nie jed­ne­go wiel­kie­go ERP inte­gru­ją­ce­go wszyst­ko” jest mrzon­ką… prak­ty­ka poka­zu­je, że kil­ka sys­te­mów dzie­dzi­no­wych, zin­te­gro­wa­nych ze sobą jest po pierw­sze mniej ryzy­kow­ne a po dru­gie, para­dok­sal­nie, tańsze.

Tak więc: jak dostaw­ca duże­go ERP mówi, że duży ERP jest naj­lep­szy to nale­ży to trak­to­wać tak samo jak ofer­tę dostaw­cy duże­go zesta­wu garn­ków ze sta­li nie­rdzew­nej, z któ­rych i tak na co dzień uży­wa­my jed­ne­go a nale­śni­ki i tak robi­my z pomo­cą kupio­nej wcze­śniej dobrej teflo­no­wej patel­ni bo do nale­śni­ków lep­sza a zamia­na jej na nową z nie­rdzew­ki tyl­ko dla­te­go, że ?z kom­ple­tu? prze­czy zdro­we­mu roz­sąd­ko­wi i uży­wa się jej mimo, że pokryw­ka z zesta­wu lek­ko wysta­je ? ale przy­kry­wa bo taki jest jej głów­ny cel (w zasa­dzie tyl­ko nie powin­na być mniej­sza ani zbyt duża). (Nigdy wię­cej ERP w jed­nym kawał­ku!).

Raport z Badania polskich projektów informatycznych 2010

Na stro­nie PMResearch​.pl poja­wi­ło się cie­ka­we bada­nie Raport zawie­ra rezul­ta­ty ana­li­zy 80 sta­ran­nie wyse­lek­cjo­no­wa­nych pro­jek­tów IT. Wyniki pre­zen­tu­je w zwię­zły, syn­te­tycz­ny spo­sób. Pobierz raport (za Informacje o wyni­kach bada­nia pol­skich pro­jek­tów infor­ma­tycz­nych).

Wyniki bada­nia bar­dzo pole­cam, uczą poko­ry. Pytanie moje do auto­rów: jak zde­fi­nio­wa­no meto­dy­kę Agile? Pobieżna nawet bada­nie” zaso­bów w Internecie poka­zu­je, że nie ist­nie­je jed­na defi­ni­cja tego podej­ścia”. Na stro­nie agi​le​ma​ni​fe​sto​.org czytamy:

Wytwarzając opro­gra­mo­wa­nie i poma­ga­jąc innym w tym zakresie,

odkry­wa­my lep­sze spo­so­by wyko­ny­wa­nia tej pracy.

W wyni­ku tych doświad­czeń przedkładamy:

Ludzi i inte­rak­cje ponad pro­ce­sy i narzę­dzia.

Działające opro­gra­mo­wa­nie ponad obszer­ną doku­men­ta­cję.

Współpracę z klien­tem ponad for­mal­ne usta­le­nia.

Reagowanie na zmia­ny ponad podą­ża­nie za pla­nem.

Doceniamy to, co wymie­nio­no po pra­wej stronie,

jed­nak bar­dziej ceni­my to, co po lewej.

Można by odnieść wra­że­nie, że igno­ro­wa­ne jest wszyst­ko co naka­zu­je roz­są­dek (pogru­bie­nie moje). Paradoksalnie, obser­wu­jąc pro­jek­ty, mam wra­że­nie, że zwin­ność jest jed­nak czę­sto ina­czej rozu­mia­na, nie jako igno­ro­wa­nie zło­te­go trój­ką­ta” pro­jek­to­we­go (zakres, ter­min, budżet). Ja w każ­dym razie zawsze pytam: czym jest tu Agile. Niestety sły­szę nie raz, ze tego się nie defi­niu­je”… co wywo­łu­je u mnie odruch nie defi­niu­je się zakre­su pro­jek­tu” a to pro­wa­dzi do wnio­sku, że suk­ce­sem jest sam fakt roz­po­czę­cia projektu…

jak to niektórzy robią w Ameryce”">

IIBA czyli jak to niektórzy robią w Ameryce”

O szkoleniu

Ameryka przy­je­cha­ła do nas, [[Darryl Booker]], któ­ry 20 lat (poza pra­cą na uczel­ni) pra­cu­je jako kon­sul­tant, ana­li­tyk biz­ne­so­wy był tre­ne­rem na szko­le­niu, któ­re mam wła­śnie za sobą.

Z jed­nej stro­ny trzy dni pozna­wa­łem coś do cze­go sam docho­dzi­łem, co w zasa­dzie znam i potra­fię, jed­nak z dru­giej stro­ny szko­le­nia pro­wa­dzo­ne przez ludzi z dużym doświad­cze­niem zawsze mają dwa aspek­ty: po pierw­sze począt­ku­ją­cy dowie­dzą się jak nale­ży pra­co­wać i co powin­no pod­czas tej pra­cy powsta­wać po dru­gie dla mnie (dla każ­de­go z dużym doświad­cze­niem) bar­dzo cen­ne są kon­tak­ty z inny­mi ludź­mi z bran­ży, bo porów­na­nie wie­dzy, wymia­na doświad­czeń oraz dys­ku­sje pozwa­la­ją porów­nać swo­je doko­na­nia z cudzy­mi. W wie­lu pro­jek­tach i na kon­fe­ren­cjach sły­szę, że wymy­ślam jakieś nie­stwo­rzo­ne rze­czy bo nikt tak nie robi (mode­lo­wa­nie, testo­wa­nie wyma­gań, pro­of-of-con­cept, itp.). Otóż nie praw­da, po pro­tu bar­dzo wie­lu ludzi (w bar­dzo wie­lu pro­jek­tach) nie zarzą­dza ryzy­kiem przyj­mu­jąc gene­ral­nie opty­mi­stycz­ne wer­sje wydarzeń.

Czego się nauczy­łem na tym szko­le­niu? Że war­to pla­no­wać, pro­jek­to­wać i ana­li­zo­wać bo wte­dy pro­jek­ty są prze­wi­dy­wal­ne zamiast być loterią.

Jak to się robi? Od kil­ku lat pro­mu­ję ideę nauko­wej ana­li­zy sys­te­mo­wej: opis celu, opis pro­ble­mu, sta­wia­nie hipo­tez, mode­le i sce­na­riu­sze, reko­men­da­cje i pro­jekt. Nie musi to być i nie jest żaden tak zwa­ny wodo­spad” pro­jek­to­wy ([[wat­ter fall model IT]]), zwin­ność tu pole­ga na reago­wa­niu na każ­dym eta­pie pro­jek­tu na pro­ble­my i wpro­wa­dza­nie zmian, pro­dukt pro­jek­tu jest zawsze mode­lo­wa­ny i testo­wa­ny na każ­dym eta­pie. W efek­cie spe­cy­fi­ka­cja tego co ma powstać jest kom­plet­na, nie wyma­ga pro­to­ty­po­wa­nia” na żywym cie­le (powsta­je kod dla klien­ta, któ­ry zgła­sza uwa­gi do tego co zoba­czy) a zama­wia­ją­cy wie co dosta­nie w dniu zamó­wie­nia i wie ile to będzie kosztowało.

Mity dostawców oprogramowania

Dostawcy goto­we­go opro­gra­mo­wa­nia szer­mu­ją tezą, że oszczę­dzą Wam kosz­tów ana­li­zy bo mają wie­dzę i doświad­cze­nie zawar­te” w swo­im pro­duk­cie. Ryzyko, że wyma­ga­nia biz­ne­so­we zosta­ną źle zde­fi­nio­wa­ne i ryzy­ko, że dostar­czo­ny pro­dukt nie speł­nia tych wyma­gań jest igno­ro­wa­ne (klient zamó­wił to klient dosta­nie, czy to będzie mu potem potrzeb­ne to nie nasz problem).

Developerzy ofe­ru­ją­cy wyko­na­nie dedy­ko­wa­ne­go opro­gra­mo­wa­nia bez ana­li­zy wyma­gań a np. tyl­ko z pomo­cą tak zwa­nych sesji JAD (ang. [[Joint appli­ca­tion design]]) i kolej­nych pro­to­ty­pów, w ogó­le nie bio­rą pod uwa­gę ryzy­ka nie­kom­plet­no­ści tak okre­ślo­nych wyma­gań ani bra­ku ich spój­no­ści (zna­ny pro­blem odkry­wa­nia wyma­gań w trak­cie wdro­że­nia). Klient powie co chce i będzie OK a opro­gra­mo­wa­nie i tak ma być bo każ­dy ma.

A ryzy­ko, że ana­li­za potrzeb i pro­jekt tego co ma powstać, wyko­na­na przez przy­szłe­go wyko­naw­cę, będzie tak na praw­dę tyl­ko spe­cy­fi­ka­cję tyl­ko tego co dostaw­ca potra­fi wykonać?

Dlaczego tak często projekty łamią zasady rozsądku i zarządzania ryzykiem?

Wczoraj na sali i w kulu­arach padły mię­dzy inny­mi takie odpowiedzi:

  1. dostaw­cy opro­gra­mo­wa­nia bar­dzo czę­sto nie potra­fią takiej ana­li­zy wyko­nać bo nie mają wyma­ga­nych kom­pe­ten­cji, ale potra­fią pro­gra­mo­wać i tyl­ko na to się godzą.

  2. dostaw­cy opro­gra­mo­wa­nia dosko­na­le wie­dzą, że ist­nie­je ryzy­ko że ich pro­dukt nie speł­nia wyma­gań więc bar­dzo czę­sto nie dopusz­cza­ją do takich ana­liz for­su­jąc od razu wdro­że­nie (wręcz tępią w pro­jek­tach zewnętrz­nych analityków!).

  3. klien­ci mają sta­le do czy­nie­nia z dostaw­ca­mi a bar­dzo rzad­ko z nie­za­leż­ny­mi ana­li­ty­ka­mi i bar­dzo czę­sto przyj­mu­ją wia­rę w to co mówią dostawcy.

  4. nie ist­nie­ją nie­za­leż­ni analitycy.

Na ostat­nie odpo­wiem tak: jest ich (nas) mało… ale to łatwo spraw­dzić: popro­sić o refe­ren­cje i zapy­tać co reko­men­do­wa­li. Dobry ana­li­tyk nigdy nie reko­men­du­je imple­men­ta­cji a tyl­ko two­rzy spe­cy­fi­ka­cję biz­ne­so­wą. Po trze­cie, war­to anga­żo­wać ludzi zna­nych w bran­ży z tego, że nie są na pro­wi­zjach u producentów.

Agile…

Wielu z deve­lo­pe­rów idzie dalej: nie trze­ba ana­li­zy, trze­ba od razu zacząć two­rzyć roz­wią­za­nie, [[Agile Manifesto]] – hasło prze­wod­nie tej meto­dy jasno mówi, że cho­dzi o to by pro­gra­mo­wać a nie o to by coś doku­men­to­wać, szko­da cza­su na głu­po­ty (zawsze tak okre­ślo­ne meto­dy zwin­ne koja­rzy­ły mi się z home­opa­tią: dostaw­cy obie­cu­ją coś nie wie­dząc co na praw­dę boli i nie bio­rą żad­nej odpo­wie­dzial­no­ści za skut­ki, co cie­ka­we żad­ne dane nie potwier­dza­ją sku­tecz­no­ści tych metod).

Inna cie­ka­wost­ką metod Agile jest to, że pro­jekt koń­czy się nie wte­dy gdy powsta­nie to co zamó­wił (a raczej wyobra­żał sobie klient bo nic nie zamó­wił, w koń­cu nie powsta­ła żad­na spe­cy­fi­ka­cja) tyl­ko to co powsta­nie dopó­ki nie skoń­czy się budżet. Co powsta­nie? Zobaczymy jak skończymy.

IIBA czyli czym jest ta Analiza Biznesowa

Od pew­ne­go cza­su IIBA pro­mu­je idee Analizy Biznesowej, któ­ra jest poważ­nym zagro­że­niem dla opi­sa­nych wyżej dostaw­ców. Dlaczego? Bo pro­mu­je two­rze­nie doku­men­tów pozwa­la­ją­cych naj­pierw dokład­nie wyspe­cy­fi­ko­wać to co jest potrzeb­ne (czy­taj pomo­że w biz­ne­sie!), potem dopie­ro zosta­je to zamó­wio­ne i dostar­czo­ne lub wykonane.

Nie da się tak? A wła­śnie, że się da. Czy to kosz­tow­ne? Zapytam tak? Co lep­sze nie­przy­dat­ny pro­dukt za 100tys. zł czy przy­dat­ny za 120tys.? Co lep­sze, pro­jekt pla­no­wa­ny na pól roku za 100tys. i wyko­na­ny w ter­mi­nie czy obie­ca­ny za 50tys. w kwar­tał a dostar­czo­ny za 250 tys, po dwóch latach?

To się nazy­wa RYZYKO a ana­li­za i pro­jek­to­wa­nie to zarzą­dza­nie tym ryzykiem!

Co oferuję jako analityk a IIBA zaleca

Porządny pro­jekt analityczny:

[sin­gle­pic id=119 w=533 h=533 float=center]

Kończący się spe­cy­fi­ka­cją wyma­gań (IIBA nazy­wa to Dokument Wymagań Biznesowych):

[sin­gle­pic id=122 w=533 h=533 float=center]

A teraz to co mogę pole­cić: szko­le­nie Analiza Biznesowa w MT&DC. Dostawców nauczy pra­cy a klien­tów wia­ry, że moż­na lepiej. Dlaczego tak pole­cam to szko­le­nie? Bo jego koszt to nic w porów­na­niu do strat jakie gene­ru­je źle zapla­no­wa­ny pro­jekt a któ­rych moż­na unik­nąć lub znacz­nie zmi­ni­ma­li­zo­wać. Nawet jeśli ktoś po szko­le­niu nie będzie potra­fił sam od razu takiej ana­li­zy wyko­nać (bo raczej po trzech dnia nie) to na pew­no będzie w sta­nie oce­nić to co pro­po­nu­ją dostaw­cy a potem zarzą­dzać takim pro­jek­tem. Potem z cza­sem sam (lub na kolej­nych szko­le­niach) nauczy się dobrej ana­li­zy biznesowej.

Na koniec naj­waż­niej­sze, para­fra­zu­jąc stwier­dze­nie Daryll’a: ana­li­ty­kom, któ­rych jedy­nym narzę­dziem pra­cy jest pakiet MS Office, w szcze­gól­no­ści Excel i PowerPoint, z góry dzię­ku­je­my (on uży­wa pro­fe­sjo­nal­nych narzę­dzi CASE i pakie­tów do zarzą­dza­nia projektami).

Inny bar­dzo cie­ka­wy arty­kuł o wyma­ga­niach: Jak zawa­lić pro­jekt infor­ma­tycz­ny. Analiza wymagań.