niedziela, 18 maja 2014

Modne bzdury kontratakują!

Modne bzdury kontratakują!
(http://blog.testowka.pl/2014/02/26/komentarz-do-blad-arystotelesa-w-it/)

[Na marginesie: projekty agile prowadziłem wielokrotnie, szkolenia agile od kilku lat, w tym ponad rok w Szwecji. Wkrótce opublikuję w http://fabrykawiedzy.com/ książkę pt. "Zwinny przewodnik po świecie agile". Ale tym bardziej rażą mnie modne bzdury na temat agile ;-)]

http://blog.testowka.pl/2014/02/26/komentarz-do-blad-arystotelesa-w-it/:
W ostatnim wydaniu Computerworld pojawił się artykuł autorstwa Bogdana Berezy zatytułowany "Błąd Arystotelesa w IT", który wręcz domagał się komentarza. Nie chodzi tyle o jakieś rażące błędy merytoryczne ale raczej o niedomówienia i drobne naginanie faktów, które troszeczkę zaciemniają prawdziwy obraz. Komentarz jednak trochę urósł więc zrobiła się z tego też notka na blogu - poniżej... zapraszam do dyskusji
 
"Rażące błędy merytoryczne" - nie, nie ma ich... ale ich sugerowanie (są nie-rażące?) jest niestety ostrym naginaniem faktów :-(

Wygląda na to, że autor pisząc o testowaniu w Agile jako o czymś co jest w 85% takie samo jak „zwykłe” testowanie chyba nie do końca zdaje sobie sprawę z tego czym faktycznie testowanie w Agile różni się od testowania w procesach „tradycyjnych”.

Autor chyba sobie zdaje sprawę, bo doskonale to zagadnienie zna, z praktyki i z teorii. Autor komentarza nie zadaje sobie natomiast trudu, żeby swoje twierdzenia, że jest inaczej, uzasadnić :-(

Pamiętam jak kilka dobrych lat temu zmieniłem pracę przenosząc się z organizacji pracującej wg tzw. Modelu Kaskadowego opatrzonego normami ISO i certyfikatami CMMI do prawdziwie zwinnego zespołu pracującego w Scrum… Różnica była zasadnicza!


Tak, "zasadnicza różnica" jest także, kiedy zmienia się kraj, branżę, język, firmę oraz proces wg jednego wzorca na inny wzorzec. Ale to nie jest żadna "zasadnicza różnica" w testowaniu, no chyba że ktoś ma tak małe i wąskie doświadczenie, że mu jakakolwiek zmiana wydaje się ogromna, bo brakuje mu ram odniesienia. MIAŁEŚ WRAŻENIE RÓŻNICY, to możliwe, ale jej tak naprawdę nie było. Ot, inna stylistyka.


Oczywiście zgadzam się, że samo testowanie to testowanie i nie różni się niczym w obydwu podejściach… Smutny jest fakt, że wielu „testerów” w tym obszarze ma nadal poważne, podstawowe braki dotyczące technik testowania i projektowania testów, pomimo nawet uczestnictwa w wielu certyfikowanych szkoleniach, które częściej bardziej uczą jak zdać egzamin, niż jak faktycznie coś dobrze przetestować (oczywiście zdarzają się wyjątki)...

No właśnie - NIE RÓŻNI SIĘ :-)

Wracając do różnic pomiędzy Agile a nie-Agile… Już na przykład: rola testera, jego miejsce w zespole i organizacji, wartość i sposoby komunikacji, zasadnicza przewaga bezpośredniej współpracy wewnątrz zespołu wskroś-funkcjonalnego ponad przerzucanie się zgłoszeniami bugów pomiędzy działem testów i działem programowania, częstotliwość testowania, feedback dla programistów, proporcje pomiędzy testami regresyjnymi a testami akceptacyjnymi zupełnie nowych funkcjonalności, rola automatyzacji testów i jej wsparcie w procesie testowym i procesie zapewniania jakości oprogramowania, ciągła integracja i ciągłość testowania to tylko niektóre z różnic, o który autor zdaje się zapominać…
 
Tak, to takie trala-lalala, które osoby propagujące rzekomą nadzwyczajną odmienność agile, chętnie nagłaśniają. Inna duchowość, przyjaźń między ludźmi, bara-bara. Oczywiście, są jakieś systematyczne różnice między testowaniem w agile i nie-agile, ale znacznie mniejsze, niż między złymi i dobrymi projektami, między testowaniem systemów bezpiecznych a takich, gdzie niezawodność jest mniej istotna, itd. WSZYSTKIE te zjawiska, które autor komentarza wymienia jako rzekomo specjalne w agile, występują też często poza agile.

Jest tego trochę więcej niż by mogło się, a przynajmniej na tyle więcej że potrafimy nad tym pracować przez ponad 80% czasu na naszych warsztatach z Testowania w Agile na które serdecznie autora zapraszam.


Na warsztatach - wierzę, w końcu autorom warsztatów ta bardzo opłaca się udawać, że uczą czegoś niezwykłego i wartościowego, aż w końcu sami w to wierzą. W rzeczywistości, nie na "warsztatach"- jest inaczej. Te 80% zresztą po prostu uczycie testowania, udając, że jest to jakieś specjalne "testowanie agile" (bo trochę więcej regresji itp).

Wobec tego - zapraszam na moje warsztaty, tam tę fikcję wyjaśniam dokładniej. I do moich innych artykułów, licznych.

Agile nie jest już żadną nowością – 13 lat praktyki od Manifestu Agile popartych wieloma sukcesami to przy obecnym tempie naszego życia i rozwoju chyba już całkiem sporo. A początków Agile można się doszukiwać w okolicach 1991 roku, a jak twierdzą niektórzy (np. Tom Gilb) jeszcze jakieś 20 lat wcześniej…

Dokładnie - AGILE NIE JEST ŻADNĄ NOWOŚCIĄ. Tom Gilb niczego nie "twierdzi", tylko po prostu metodykę podobną na 90% do agile stosował od 1970 roku. Opublikowałem z nim o tym wywiad ;-)

Co do samej terminologii stosowanej w Agile to… „Jeśli chcesz coś zmienić to musisz coś zmienić” – terminologia i używany język są dobrym punktem startu. Ma to głębokie uzasadnienie zwłaszcza, gdy potrzebujemy zmienić istniejącą organizację.

Żal tego słuchać - zbędne zmienianie nazw świadczy dobitnie o braku zmian istotnych, które trzeba symulować. Taki bolszewizm. Ale tę zmianę nazw można agile akurat wybaczyć, bo służy dobrej sprawie, czyli autentycznie świetnym metodom agile.

Podsumowując – nie rozumiem co autor miał na myśli krytykując realnie działające (przynajmniej na podstawie moich kilkuletnich doświadczeń) metody jakoby były one zupełnie nienaukowymi „modnymi bzdurami”. 


Toś Kolego niewiele z mojego artykułu zrozumiał... Przecież oczywiście NIE krytykuję tam agile, bo uważam (co tam piszę), że autentyczne agile jest świetną metodą. To chyba w artykule jest jasne:
  
Żeby było jasne – jestem gorącym zwolennikiem paradygmatu (zrębu – ang. framework) agile, zwłaszcza agile Scrum. Ten sposób realizowania projektów jako pierwszy i jedyny dotąd na świecie zdołał – przynajmniej częściowo – zlikwidować szereg chronicznych od lat słabości projektów IT [...]

Krytykuję, a raczej ostrzegam przez BEZMYŚLNĄ MODĄ NA AGILE, bez zrozumienia, co naprawdę jest w agile dobre, fascynowanie się jego rzekomymi odmiennościami, zamiast istotnych zalet. Tak, jak w cytowanym tekście "Błąd Arystotelesa" jego autor też nie krytykuje np. języków obiektowych, tylko bezmyślną modę na nazwę "obiektowy", która znaczyła cokolwiek.


Tym bardziej, że metody te również mają podstawy w nauce – może bardziej w psychologii i naukach humanistycznych niż inżynierii ale jednak…


Jak się już do "naukowych nauk humanistycznych" musisz odwoływać, to uprawiasz kult cargo na całego :-) ale agile PO PROSTU jest dobrą metodą, co nie czyni jednak z niej metody zupełnie innej, niesamowitej, humanistycznej - takie tezy to są właśnie modne bzdury.

Przypominam, że „Waterfall” również kiedyś był modną bzdurą, która z siłą wodospadu miała popychać projekty IT do przodu.

No, brawo! O tym właśnie piszę - o tym, że metody różne, dobre w PEWNYM ZAKRESIE, stają się niestety, i dawniej, i dzisiaj, formą kultu, bez zrozumienia, co w nich naprawdę jest dobre, i dlaczego. Ofiarą takiego kultu pada agile - często. Nie zawsze.

Zmieniła się jednak rzeczywistość i mechanizmy współczesnego wytwarzania oprogramowania przez co dawne metody przestały działać.

Zupełna bzdura. Metody sekwencyjne (np. kaskada i wiele innych) i iteracyjne (np. agile i wiele innych) pasuję - niezależnie od epoki - do RÓŻNYCH RODZAJÓW PROJEKTÓW. Bezmyślne stosowanie kaskady tam, gdzie jest nie na miejscu, jest równie niemądre, jak bezsensowne stosowanie agile, tam gdzie ono nie pasuje.

Już widać, że Scrum powoli przestaje być wystarczający na współczesnym rynku, a wydania raz na dwa tygodnie wywołują uśmiech na twarzach praktyków Continuous Delivery pracujących w organizacjach tworzących produkty według zasad Lean Startup

O, to doskonałe przykłady MODNYCH BZDUR. Autor tych powyższych słów nawet, zdaje się nie słyszał o "daily build" (początek lat 90-ych), ani XP (ten sam okres), ani "cleanroom software engineering"), bo mu WIARA w wielkość i nadzwyczajność agile wystarcza? Wydania kilka razy na dzień nie są więc żadną nowością, lecz ("daily build"!) ćwierćwieczną staruszką. Oto do czego prowadzi bezmyślny kut wszelkiej nowości. Jeśli "wydania raz na dwa tygodnie wywołują uśmiech", to jest typowy przykład "agile jako śmieszna moda", bo nie jest zaletą mieć wydania jak najczęściej, tylko tak często, jak trzeba. Amen. Uczcie się ludzie, i nie ulegajcie histerii mody i rzekomych pseudo-nowości.

(gdzie nikt nie wspomina nawet o rzeczach z ich perspektywy tak archaicznych jak inżynieria wymagań

No, to trzeba być niemądrym do kwadratu, żeby nie zdawać sobie sprawy, że inżynieria wymagań po prostu JEST, jak tlen, nawet (zwłaszcza!), gdy jej nie widać. Siłą agile jest właśnie bardzo dobra i zdyscyplinowana inżynieria wymagań, której najlepsze zasady przemyca się pod pseudo-nowoczesną terminologią (żeby nie straszyć młodych gniewnych). Jeśli ktoś uważa, że inżynieria wymagań jest archaiczna czy zbędna, to nawet nie wie, jak sam pracuje, i myśli, że inżynierii wymagań nie uprawia, bo jest "zwinny" i inaczej jej artefakty ponazywał.

Taka moda na niby-nowoczesność jest znana od wieków, archaiczna i przed nią w moim artykule przestrzegam. Jak widać, słusznie :-(

3 komentarze:

  1. Ten komentarz został usunięty przez autora.

    OdpowiedzUsuń
  2. Ciekawa dyskusja i ciekawe argumenty. Obawiam się, że musimy taki stan rzeczy zaakceptować, bo ttacy właśnie jesteśmy. Lubimy nowe etykiety, nowe nazwy, nowe opakowanie - bo to się najlepiej sprzedaje. Z drugiej strony nie na darmo powstało powiedzenie historia kołem się toczy. Niestety w takim świecie trzeba zachować swój własny rozum i własne myślenie.

    OdpowiedzUsuń