Bardzo czę­sto moż­na spo­tkać w sie­ci i w lite­ra­tu­rze róż­ne podej­ścia do oce­ny skut­ków błę­dów ana­li­zy wyma­gań. Nie mniej wie­le jest spo­so­bów na odkry­wa­nie” wymagań.

Burza mózgów

Bardzo czę­sto spo­ty­kam się z roz­wle­kły­mi opi­sa­mi, wszel­kie­go rodza­ju ankie­ta­mi, wywia­da­mi, burza­mi mózgów, żół­ty­mi kar­tecz­ka­mi itp. Poradników nie bra­ku­je. Dyskusje na tego rodza­ju tema­ty doty­ka­ją zawsze pra­cy gru­po­wej i jej siły”. Niestety psy­cho­lo­gia daw­no dowio­dła, że np. dowol­na licz­ba stu­den­tów nie­po­tra­fią­ca zdać egza­mi­nu nie zda go pra­cu­jąc nad testem razem, i licz­ba tych stu­den­tów nie ma zna­cze­nia. Po pro­tu trze­ba mieć wie­dzę i umie­jęt­ność. (prze­czy­taj wię­cej o pra­cy gru­po­wej)

Można się czę­sto spo­tkać z tłu­ma­cze­niem tego, tak zwa­nym holi­stycz­nym podej­ściem mówią­cym, że całość zna­czy wię­cej niż suma skład­ni­ków. Zapewne tak jest ale to doty­czy raczej uzu­peł­nia­ją­cych się umie­jęt­no­ści: zarów­no spraw­ny fizycz­nie śle­piec jak i pozba­wio­ny nóg widzą­cy kale­ka, w poje­dyn­kę mają nikłe szan­se na samo­dziel­ne prze­ży­cie. Obaj razem mają znacz­nie więk­sze szan­se, sta­no­wią coś znacz­nie wię­cej niż niż każ­dy z nich z osob­na. Jednak jeśli żaden z nich nie potra­fi goto­wać, to razem tak­że nie potra­fią, nie będą potra­fi­li nawet jeśli takich jak oni (nie umie­ją­cych goto­wać) było by w tym zespo­le wię­cej. Burza mózgów tego zespo­łu nie da nic lep­sze­go do zje­dze­nia ponad to co potra­fi naj­lep­szy z nich (a jeże­li prze­pis usta­lą jako kom­pro­mis wła­snych pomy­słów, to chy­ba nie chciał bym tego jeść). A co na to nauka? Poniżej popu­lar­ny mit i efek­ty badań:

Tak więc porów­na­nie burzy mózgów z [[holizm]]em odbie­ram raczej jako nie­zro­zu­mie­niu tego drugiego.

Ciekawe jest to, że meto­da ta jest powszech­nie sto­so­wa­na” i zale­ca­na przez nie­jed­ną fir­mę dorad­czą (zary­zy­ku­ję, że przez więk­szość). Stosowana jest tak­że jako spo­sób na pro­blem” przez fir­my (zespo­ły), któ­re z jakie­goś powo­du, nie mają dostę­pu do potrzeb­ne­go spe­cja­li­sty (na temat tych powo­dów innym razem :))

Klasycznym przy­kła­dem opi­sa­ne­go podej­ścia są ana­li­zy i zbie­ra­nie wyma­gań wła­śnie meto­dą burzy mózgów, ankie­to­wa­nia przy­szłych użyt­kow­ni­ków, sesje JAD i podob­ne meto­dy. Skoro przy­szłe opro­gra­mo­wa­nie ma powstać na bazie wyma­gań (co by to nie mia­ło zna­czyć) to dla­cze­go auto­rzy pomy­słów na zbie­ra­nie wyma­gań meto­dą pra­cy gru­po­wej” nie posa­dzą tej gru­py od razu do napi­sa­nia tego opro­gra­mo­wa­nia? Zgodnie z ich podej­ściem gru­pa potra­fi wię­cej” wiec powin­no im się kie­dyś udać napi­sać dzia­ła­ją­cy pro­gram? Głupie? Nie! Próby są podej­mo­wa­ne, oto etap przejściowy:

Joint Application Development (JAD) ozna­cza współ­two­rze­nie apli­ka­cji. Jest to meto­dy­ka pole­ga­ją­ca na zaan­ga­żo­wa­niu klien­ta lub użyt­kow­ni­ka w pro­ces two­rze­nia opro­gra­mo­wa­nia, poprzez wpro­wa­dze­nie warsz­ta­tów współ­pro­jek­to­wa­nia, zwa­nych sesja­mi JAD. (źr. WIKI).

Prawdę mówiąc, obser­wu­jąc efek­ty tego podej­ścia, skła­niam się nie raz ku tezie, że JAD to prze­rzu­ce­nie znacz­nej czę­ści odpo­wie­dzial­no­ści za poten­cjal­ną poraż­kę na klien­ta: w koń­cu aktyw­nie brał Pan w tym udział wiec to nie tyl­ko nasza wina”. W moich oczach to raczej pró­ba w rodza­ju sko­ro nie umiem tego robić to może razem z klien­tem coś wymy­śli­my (zno­wu burza mózgów).

Proszę sobie kie­dyś w ramach ćwi­czeń poli­czyć kosz­ty sesji JAD (np. 15 osób na sali, kon­sul­tant pro­wa­dzą­cy i jego pomoc­nik notu­ją­cy, koszt opra­co­wa­nia danych z każ­dej sesji, razem raz w tygo­dniu przez rok trwa­nia pro­jek­tu). Drugie ćwi­cze­nie: ankie­ta wypeł­nio­na przez każ­de­go pra­cow­ni­ka szcze­bla śred­nie­go i wyżej. Najpierw czas tych ludzi jaki zaj­mu­je wypeł­nia­nie ankiet, potem koszt ich opra­co­wa­nia przez kon­sul­tan­tów w fir­my doradczej.

Pewna mię­dzy­na­ro­do­wa kor­po­ra­cja, chcąc oszczę­dzić na zatrud­nia­niu spe­cja­li­stów z zewnątrz, zarzą­dzi­ła by każ­dy ich zespół na świe­cie, meto­dą burzy mózgów, zapro­po­no­wał kil­ka spo­so­bów roz­wią­za­nia pew­ne­go pro­ble­mu. Z całe­go świa­ta napły­nę­ło ponad 6 tys. pomy­słów”, ich prze­twa­rza­nie tych danych trwa­ło pra­wie rok, by prze­ko­nać się, że w zasa­dzie pro­ble­mu nie roz­wią­za­no. Koszt cało­ści tej pra­cy (czas pra­cy wła­snych pra­cow­ni­ków odcią­gnię­tych od nor­mal­nych zajęć) wie­lo­krot­nie prze­wyż­szał war­tość odrzu­co­nych ofert ekspertów.

Ostatnio zro­bi­ła się moda na kon­kur­sy foto­gra­ficz­ne, kon­kur­sy na logo, kon­kur­sy na rekla­mę itp. dla ama­to­rów. Regulaminy więk­szo­ści z nich zawie­ra­ją zapi­sy o prze­ję­ciu praw mająt­ko­wych do nade­sła­nych prac. Często sły­szę, że zawo­do­wy foto­graf czy gra­fik chce za dużo” więc ogła­sza się kon­kurs z jakąś nagro­dą, uczest­ni­cy nade­ślą za dar­mo wie­le prac i coś się wybie­rze. Nie raz jed­nak koszt zor­ga­ni­zo­wa­nia, zbie­ra­nia i prze­glą­du prac, czas pra­cow­ni­ków zaan­ga­żo­wa­nych w cały ten pro­ces wie­lo­krot­nie prze­kra­cza to co sobie zaży­czył Pan foto­graf (czy grafik).

Agile

Niestety wie­le pro­jek­tów pro­gra­mi­stycz­nych to odkry­wa­nie wyma­gań w trak­cie” dostar­cza­nia pro­duk­tu. Po dostar­cze­niu jakie­goś frag­men­tu (lub nie raz pro­to­ty­pu cało­ści) bene­fi­cjent stwier­dza: to jest dokład­nie to cze­go chcie­li­śmy ale zupeł­nie nie to co jest nam potrzeb­ne”… Projekty z rodza­ju Agile WIKI defi­niu­je jako:

Programowanie zwin­ne ((ang.) Agile softwa­re deve­lop­ment) ? gru­pa meto­dyk wytwa­rza­nia opro­gra­mo­wa­nia opar­te­go na pro­gra­mo­wa­niu ite­ra­cyj­nym (model przy­ro­sto­wy). Wymagania oraz roz­wią­za­nia ewo­lu­ują przy współ­pra­cy samo­za­rzą­dzal­nych zespo­łów, któ­rych celem jest prze­pro­wa­dza­nie pro­ce­sów wytwa­rza­nia opro­gra­mo­wa­nia (źr. WIKI)

Nie jestem wro­giem Agile jako zwin­no­ści, gdyż sam uwa­żam, że nale­ży się dosto­so­wy­wać, ale zwin­ność postrze­gam raczej jako dosto­so­wa­nie metod pra­cy a nie brak pla­no­wa­nia i pro­jek­to­wa­nia (przy­po­mi­nam, że pla­no­wa­nie nie pole­ga na usta­le­niu pla­nu cyklicz­nych spo­tkań a na usta­le­niu co kie­dy powstanie).

Niestety bar­dzo czę­sto pro­jek­ty Agile przy­po­mi­na­ją powyż­szy rysu­nek z mostem (napis na rysun­ku brzmi: może jed­nak zbu­duj­my łódź zamiast tego?) bo w Agile roz­wią­za­nia ewo­lu­ują”. W efek­cie na począt­ku pro­jek­tu nie wie­my co i jakim kosz­tem powsta­nie… o ile w ogó­le powsta­nie, bo może skoń­czyć się finansowanie.

Na zakończenie

Burze mózgów mają sens, jak naj­bar­dziej, ale w przy­pad­ku zespo­łu spe­cja­li­stów. Jeżeli zacho­dzi ryzy­ko, że jeden spe­cja­li­sta w danej dzie­dzi­nie, będzie pra­co­wał nad uzy­ska­niem roz­wią­za­nia zbyt dłu­go na co nie ma cza­su, zamiast jed­ne­go spe­cja­li­sty sadza­my” kil­ku (słyn­na sce­na w Apollo 13). Jest bar­dzo praw­do­po­dob­ne, że któ­ryś z nich wpad­nie na wła­ści­wy pomysł szyb­kiej niż kole­dzy. Jest nawet meto­da pole­ga­ją­ca na uzu­peł­nia­niu takie­go zespo­łu oso­bą z innej dzie­dzi­ny w celu wpro­wa­dze­niu ele­men­tu nie­sza­blo­no­we­go myśle­nia” (nie ma głu­pich pomy­słów, są tyl­ko w danym przy­pad­ku nie przy­dat­ne). Ale efekt (pomy­słu laika”) i tak będzie wyma­gał wie­dzy spe­cja­li­stów by go wdrożyć.

Jak spe­cy­fi­ko­wać wyma­ga­nia? Cały ten blog trak­tu­je o tym jak, w spo­sób usys­te­ma­ty­zo­wa­ny i nie­ste­ty” trosz­kę nauko­wy. Można to zro­bić, opra­co­wać wyma­ga­nia na opro­gra­mo­wa­nie, dobrze oraz rela­tyw­nie tanio i sku­tecz­nie (ana­li­tyk w zasa­dzie zawsze jest tań­szy niż koszt burza mózgów: jej człon­ko­wie i opra­co­wa­nie wyni­ków). Na jed­nym z forów w toku dys­ku­sji na podob­ny temat napisałem:

… czym innym jest kom­pli­ka­cja [pra­co­chłon­ność] a czym innym trud­ność (umie­jęt­ność zro­bie­nia cze­goś), np. robie­nie dobrych zdjęć nie jest skom­pli­ko­wa­ne (np. jeden guzik w tele­fo­nie) ale jest trud­ne (trud­no jest zro­bić zdję­cie, któ­re zachwy­ci foto­edy­to­ra gaze­ty) zaś ich wywo­ły­wa­nie nie jest trud­ne ale jest skom­pli­ko­wa­ne… dla­te­go dla ludzi, któ­rzy nie rozu­mie­ją swo­jej pra­cy (bo nie zawsze muszą i nie zawsze jest takie ocze­ki­wa­nie) two­rzy się pro­ce­du­ry np. instruk­cja obsłu­gi foto­la­bu eks­pre­so­we­go. Podobnie pro­jek­to­wa­nie: ono nie jest skom­pli­ko­wa­ne ale jest trud­ne, ani pro­ce­du­ry ani licz­ba osób nie przy­bli­żą nas do lep­sze­go projektu…

Jeśli coś jest skom­pli­ko­wa­ne, zło­żo­ne, moż­li­wym roz­wią­za­niem jest doda­nie zaso­bów i wła­ści­wych pro­ce­dur. Jednak jeśli coś jest trud­ne, potrzeb­ny jest po pro­tu ktoś, kto potrafi.

Czemu o tym piszę? A bo wła­śnie mam przed sobą kolej­ny doku­ment o nazwie SIWZ, wyko­na­ny tech­ni­ką burzy mózgów i ankie­to­wa­nia (w obsza­rze spe­cy­fi­ka­cja wyma­gań), jakimś kosz­tem (czas pra­cow­ni­ków albo koszt kon­sul­tan­ta pra­cu­ją­ce­go tą wła­śnie meto­dą) opra­co­wa­no tę spe­cy­fi­ka­cję wyma­gań a teraz zama­wia­ją­cy sam przy­zna­je (po roz­strzy­gnię­ciu prze­tar­gu), że ana­li­za wyma­gań (teraz) jest potrzeb­na bo ów SIWZ jest nie­spój­ny, ma bra­ki i wyma­ga korek­ty i uzu­peł­nień”. Z tego powo­du tak­że nie ma pew­no­ści, że w ogó­le dobrze opi­sa­no Przedmiot Zamówienia!.

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Ten post ma 14 komentarzy

  1. jacek2v

    TRUE 🙂
    A pro­pos SIWZ: Potwierdzam z autop­sji. Dlatego tak cenię meto­dy­ki Agile – po co się oszukiwać 😛

    1. Jarek Żeliński

      Metodyki Agile nie są pana­ceum, są dobre w ogra­ni­czo­nym cza­sie na pro­jekt, któ­ry ma sła­bo spre­cy­zo­wa­ne wyma­ga­nia i przy akcep­ta­cji ich dość duże­go ryzy­ka. Dotyczy to czę­sto pro­jek­tów zwią­za­nych z inter­ne­tem (głów­nie dla tego typu pro­jek­tów powsta­ły te meto­dy­ki). Jednak w pro­jek­tach biz­ne­so­wych, wyma­ga­ją­cych pla­no­wa­nia skut­ków, meto­dy zwin­ne postrze­ga­ne jako odkry­wa­nie wyma­gań” uwa­żam za bar­dzo złe podej­ście co potwier­dza­ją zna­ne mi pro­jek­ty biz­ne­so­we reali­zo­wa­ne przez fir­my z gru­py agen­cje inte­rak­tyw­ne” i zespo­ły pro­gra­mi­stów, któ­re dosta­wa­ły ter­min ale nie pro­jekt (wie­le prze­tar­gów nie­ste­ty tak wygląda).

    2. jacek2v

      Nie wyda­je mi się, że meto­dy­ki agi­le powsta­ły szcze­gól­nie dla pro­jek­tów zwią­za­nych z inter­ne­tem. Raczej powsta­ły, gdy inne meto­dy­ki zawio­dły, a współ­pra­ca mię­dzy klien­tem a dostaw­cą jest na pozio­mie WIN-WIN. Mocna sfor­ma­li­zo­wa­ne podej­ścia w takich sytu­acjach tyl­ko dener­wu­ją” i prze­waż­nie nie­for­mal­nie odcho­dzi się od nich. Głównym błę­dem przy wdra­ża­niu i uży­wa­niu meto­dyk zwin­nych jest myśle­nie, że w nich się nie pla­nu­je, nie ana­li­zu­je ryzy­ka i idzie się w ciem­no”:). To wszyst­ko nie tyl­ko nie jest wyklu­czo­ne w pro­jek­tach typu agi­le, a cza­sa­mi jest wręcz nie­zbęd­ne np. ana­li­za ryzy­ka, wcze­sne stu­dium wykonalności.
      Dla mnie naj­bar­dziej istot­ne ele­men­ty pro­jek­tów agi­le to:
      1.Partnerska współ­pra­ca z klientem.
      2.Usługa/produkt jest dosto­so­wy­wa­na i two­rzo­na na pozio­mie zro­zu­mia­łym dla klien­ta. Nie musi­my go moc­no edu­ko­wać, aby zro­zu­miał np. pro­duk­ty ana­li­zy, jeśli tego nie ocze­ku­je, nie wyma­ga. Dzięki temu klient widzi bar­dzo wcze­śnie zro­zu­mia­łe dla nie­go efek­ty. Możemy iść na skró­ty” jedy­nie w sytu­acji, gdy widzi­my, że nie będzie to ze szko­dą dla klien­ta i/lub pro­jek­tu, ina­czej pozo­sta­je moc­niej­sze sfor­ma­li­zo­wa­nie. Krótko mówiąc ela­stycz­ność zależ­nie od sytuacji.
      3.Ciągła kon­tro­la cza­su i budże­tu po kątem przy­dat­no­ści dla pro­jek­tu. Np. po co robić dogłęb­ną ana­li­zę, jeśli jest robio­na na siłę”. Klient wymy­śla na kola­nie” wyma­ga­nia, a gdy zoba­czy kawa­łek sys­te­mu to i tak zmie­ni zdanie :).
      Namacalna
      4.Cały zespół jest bar­dzo bli­sko” produktu/usługi końcowego.
      5.Efektywność i co jest para­dok­sal­ne auten­tycz­ne dotrzy­my­wa­nie ter­mi­nów 😀 (nie do koń­ca rozu­miem ten mechanizm)
      Minusy :
      1.Mniej for­mal­nych dupo­chro­nów” 🙂 – zwięk­szo­ne ryzy­ko wyłga­nia się” klien­ta z pod­ję­tych zobowiązań.
      2.Większe obcią­że­nie dla PM – spo­wo­do­wa­ne dużą zmiena.
      3.w pro­jek­cie muszą być indywidualności/liderzy – cią­gła potrze­ba wizji na każ­dym etapie.

    3. Jarek Żeliński

      Wydaje mi się, że nie­po­ro­zu­mie­nia mają swo­je źró­dło w bra­ku for­ma­li­zmu”. Na praw­dę war­to defi­nio­wać sobie poję­cia na począt­ku wywo­du. Jeżeli agi­le to: Wymagania oraz roz­wią­za­nia ewo­lu­ują przy współ­pra­cy samo­za­rzą­dzal­nych zespo­łów” to zna­czy, że pro­jekt star­tu­je bez spe­cy­fi­ka­cji wyma­gań i tyle. Wskazane pięć punk­tów tego” Agile nie zawie­ra tego co ma powstać” a tyl­ko to jak być może coś powsta­nie”. Proponuję do każ­de­go punk­tu dodać pyta­nie Co to zna­czy”. Czyli:
      1. Co to zna­czy part­ner­ska współ­pra­ca z klientem”
      i.t.d.
      Jeżeli np. ktoś dopusz­cza w pro­jek­cie to, że Klient wymy­śla ?na kola­nie? wyma­ga­nia, a gdy zoba­czy kawa­łek sys­te­mu to i tak zmie­ni zda­nie” to zna­czy, ze nie panu­je nad projektem. 

      Bardzo podo­ba­ją mi się owe minu­sy Agile. One są po pro­tu tym co trze­ba umieć w pro­jek­cie a cze­go nie raz bra­ku­je, z powo­du… każ­dy sam sobie odpo­wie dlaczego…

    4. jacek2v

      Moim zda­niem, na Agile” nie da się napi­sać defi­ni­cji 🙂 Pojęcia z zarzą­dza­nia pro­jek­ta­mi są bar­dzo czę­sto wypa­cza­ne i nad­uży­wa­ne. Nawet ter­mi­ny PRINCE2 i PMBook widzia­łem” nad­uży­wa­ne :), a co mówić tak kuszą­cy Agile.
      Twoja defi­ni­cja mi nie pasuje 🙂
      Ad.1. To ozna­cza, że obie stro­ny zna­ją swo­je ogra­ni­cze­nia i sza­nu­ją się wza­jem­nie. Nie ma tek­stów małym drucz­kiem. Najważniejszy jest suk­ces obu stron.
      Ad.2 i 3. Wydaje mi się, że wystar­cza­ją­co to opisałem
      Ad.4.„Blisko” tzn., że nie patrzy tyl­ko na swój kawa­łek, np. ana­li­tyk widzi tyl­ko ana­li­zę, ale już go nie obcho­dzi efekt pra­cy programistów.
      Ad.5.Jak naj­wię­cej efek­tu w jak naj­krót­szym cza­sie i budże­cie – oczy­wi­ście z zacho­wa­niem wyma­gań nie­funk­cjo­nal­nych. Stosowanie zasa­dy Pareto (80/20).

    5. Jarek Żeliński

      Cały czas jest pro­blem: sko­ro coś nie ma defi­ni­cji to zna­czy, że nie wie­my czym napraw­dę jest (defi­ni­cja, któ­ra przy­to­czy­łem nie jest moja, pocho­dzi z WIKI), jeże­li nie wia­do­mo czym jest coś” to zna­czy, że nie wie­my nawet czy to osią­gnę­li­śmy… nie da się powie­dzieć ile cze­goś osią­gnię­to sko­ro nie okre­ślo­no ile tego jest… (wyma­ga­nia).

  2. Tomasz Tomaszewski

    Sporo jest praw­dy w tym co piszesz. Burze mózgów i pra­ca gru­po­wa sta­ły reme­dium na wszyst­kie pro­ble­my – i czę­sto są nadużywane. 

    Ja bym jed­nak ich nie depre­cjo­no­wał. Wszystko zale­ży od oso­by. Np. mnie się dużo lepiej pra­cu­je w gru­pie. Gdy sam mogę rzu­cać pomy­sła­mi, a kom­pa­ni odbi­ją te bez­sen­sow­ne (bo wie­dzą coś cze­go ja nie wiem). I w dru­gą stro­nę – gdy inni pod­sy­ła­ją pomy­sły a ja, dzię­ki wie­dzy i doświad­cze­niu, szyb­ko odrzu­cam bądź roz­wi­jam. Świetnie mi się tak pra­cu­je w pierw­szym sta­dium pro­jek­tu, roz­wią­zy­wa­ne­go problemu.

    Co jed­nak oczy­wi­ście nie ozna­cza, że prze­cho­dząc do szcze­gó­łów wolę się w to już zagłę­bić i prze­ana­li­zo­wać sam 🙂

    1. jacek2v

      Dorzucę, że burze mózgów w trak­cie pro­jek­tu są bar­dzo pomoc­ne np. w sytu­acji, gdy tra­fi­my na pro­blem od któ­re­go się odbi­ja­my już dru­gi dzień :). Jednak z punk­tu widze­nia psy­cho­lo­gicz­ne­go, czę­sto trud­no jest się podzie­lić z zespo­łem pro­ble­mem – po pro­stu duma nam nie pozwala :).

  3. jacek2v

    Kontynuując – skoń­czy­ły się moż­li­wo­ści odpo­wia­da­nia w wąt­ku :). Wydaje mi się, że tro­chę nie­ja­sno napi­sa­łem co do defi­ni­cji Agile. Definicja jak naj­bar­dziej ist­nie­je w Manifesto for Agile, ja mia­łem na myśli coś na kształt defi­ni­cji meto­dyk for­mal­nych np. PRINCE2. Agile w każ­dym zespo­le jest inne ponie­waż dosto­so­wu­je się do zespo­łu a nie zespół do meto­dy­ki. Ludzie się w nim(niej?:)) naj­waż­niej­si, bo to oni nio­są war­tość, a nie pro­ce­du­ry, zasa­dy, for­ma­li­zmy. Przytoczona defi­ni­cja z wiki­pe­dii jest nie­naj­lep­sza, nie mówi o duchu Agile i na pew­no nie defi­niu­je Agile – po pro­stu nie jest defi­ni­cją :P. To tak jak­by powie­dzieć, że PRINCE2 to spo­tka­nia komi­te­tu ste­ru­ją­ce­go – wyję­te z kontekstu.

  4. @Tomasz: Małe ćwi­cze­nie myślo­we: czy­ta­my to Po co w ogó­le robić ana­li­zę, pro­du­ko­wać doku­men­ty i dia­gra­my? Ich efek­tem będzie zamie­sza­nie. Lepiej wyzna­czyć cele i napi­sać dzia­ła­ją­cy kod.” i wyobra­ża­my sobie teraz tę meto­dę pra­cy pod­czas remon­tu miesz­ka­nia i to, że na remont łazien­ki mamy okre­ślo­ne pie­nią­dze i skoń­czo­ny czas (no bo ileż moż­na żyć bez łazien­ki…) mam uczu­cie, że więk­szość fachow­ców” remon­tu­ją­cych miesz­ka­nia pra­cu­je zwin­nie”…

  5. Piotr Sowa

    Bardzo faj­nie sie to czy­ta Jarku ;-). Dzieki!

Dodaj komentarz

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