piątek, 26 września 2014

Gra losowa - kiedy opłaca się agile?


Podczas warsztatu na konferencji "Agile w biznesie" badaliśmy zagadnienie z rysunku powyżej.

W formie prezentacji, i w formie gry:








Graliśmy na takich fajnych planszach:



Było ciekawie! Wnioski z ankiet podam wkrótce.

Zagubiony w szkoleniach i certyfikacjach agile? WYJAŚNIENIE na 2 obrazkach!


Jakość wymagań a wymagania jakości


Poradnik dobrych praktyk zarządzania projektami IT

Jest do pobrania z blogomotion.com/Download

Agile Management 2014 - Tomek opubllikował zdjęcia



sobota, 20 września 2014

Druga inspiracja z Agile Management

Krzywa Greinera:

Ciekawie byłoby ją odnieść pod kątem zakresu i odpowiedniości stosowania metod zwinnych  na różnych etapach życia organizacji.

Poszukiwania inżynierii wymagań - ciąg dalszy

Inspiracje poszukiwawcze z Agile Management:

1. Ktoś powiedział: "nie chciałem przyjść na ten okrągły stół" [inżynieria wymagań w agile], bo myślałem, że to będą jakieś diagramy, ale przyszedłem, bo zobaczyłem w tym dużo psychologii" :)

2. Ktoś opisał projekt IT tak: w zarządzanie projektem wchodzi ANALIZA PRZEDPROJEKTOWA - ANALIZA BIZNESOWA - ANALIZA WYKONAWCZA. Słowo "inżynieria wymagań" nie padło.

3. Świetny wykład na temat architektury IT w świecie agile, zainspirował mnie do zrobienia tego rysunku:

poniedziałek, 15 września 2014

Akademia Managerów IT - poradnik kierownika projektu

Poradnik kierownika projektu

http://www.computerworld.pl/konferencja/akademiaIT

 

1.  Mity i legendy zarządzania projektami – jak nie dać się im omamić

Zarządzanie, a jeszcze bardziej jego angielski odpowiednik management, to bardzo modne określenie. Wygląda wręcz, jeśli spojrzeć na rzeczywistość pod odpowiednim kątem, że nikt nie chce robić, a wszyscy chcą kierować, nadzorować, zarządzać.


Więcej na ten temat? Cały artykuł pojawi się w październiku 2015 w http://req.wymagania.org.pl :-)

wtorek, 2 września 2014

HiVAT - polemika

Ostatni (te słowa są pisane w sierpniu-wrześniu 2014) numer SDJ zawiera wielki artykuł na temat "HiVAT". Oj! - poczułem od razu, że tak arogancka i jawnie marketingowa nazwa podejścia "High Volume Automated Testing" nie może kryć w sobie nic uczciwego.

Nie wiem, czy Cem Kaner i autor artykułu celowo stwarzają fikcję "nowej" metodyki, opisując kilka dobrych, ale zupełnie zwykłych i zupełnie nienowych technik, nic zresztą nie mających ze sobą wspólnego? Żeby się wywyższyć? Ej, przesadzam chyba. Bo nie wiedzą, jaka jest prawda, i wydaje im się, że odkryli koło? Na pewno nie. Więc pewnie dlatego, żeby w ogóle ktoś w naszym świecie, pełnym fejsbukowego zgiełku, w ogóle ich słuchał? Jeśli tak, to wybaczam, tylko proponuję zmianę tytułów: "Parę fajnych, starych pomysłów testowych, przemyconych pod pozerskim pseudonimem HiVAT, żeby kompulsywnych wielbicieli nowości zadowolić". I wtedy jest OK!

Nazwisko Cema Kanera, jako autora tej "nowej" metodyki, zwieksza moją podejrzliwość. Ten gość, skądinąd niezwykle zdolny, jest bardziej mistrzem marketingu, niż testowania. Te jego książki i artykuły, które poznałem (nie wszysktkie, nie osądzam człowieka, lecz kilka miałkich, a popularnych idei), nie wnoszą właściwie nic niego, poza plejadą nowych nazw na stare fenomeny, i chaosu.

Ale do rzeczy, nie będę sie kierował złymi doświadczeniami i uprzedzeniami, niechaj mówia fakty, czy HiVAT nas wykiwat?

Ups... jak widzę w artykule liczne zrzuty ekranu... ups, jeszcze popularniutkiego SoapUI, to pytam się, co autor chciał nam przekazać. No, ale wróćmy do HiVAT.

1. Akapit pierwszy. Techniki projektowania testów (autor pisze - chronicznie popełniany błąd - "techniki testowania", mając na myśli techniki projektowania testów, ale domyślamy się intencji) mają za zadanie zredukować liczbę testów z niskończoności do czegoś ogarnialnego. I czasem, w trakcie tej redukcji, pomijamy te testy, które jednak należałoby wykonać, bo wykryłyby błędy. Jasne, podstawowy dylemat testowania, ile testować, mniej czy więcej, i co. Autor obiecuje: "Pomóc w tym może HiVAT". OK! Na razie poziom nowości = 0, ale obietnica - cenna.

2. Akapit drugi: HiVAT zaleca automatyczne generowanie testów oraz ich automatyczne wykonywanie (dwie niezależne od siebie możliwości, tutaj w pakiecie), co umożliwia zwiększenie ich liczby. OK, jest taka możliwość. Poziom nowości = 0.

3. Akapit 3: się skupili na... Floryda Tech... Pcim Dolny Tech... (Floryda brzmi lepiej). Nie wiemy, o co chodzi, i po co tam "Rysunek 1. Skanowanie luk bezpieczeństwa...". Jest! "Proces generowania, przeprowadzania i oceny testów możemy powierzyć narzędziu". Czyli, aha, może MTB, a może automatyczne generowanie testów w inny sposób. Znane, choć zapomniane, w związku z ogólną niewiedzą i fejsbukizacją wiedzy. Ważny temat, tylko po co przezwisko HiVAT (25% VAT na putinowskich Węgrzech, to jest dopiero High VAT!)? Po co udawanie, że to jakaś nowość? Jak to zachwyca, skoro nie zachwyca? Poziom nowości = 0.

4. Jak mamy dużo danych wejściowych = dużo testów, to jest dużo wyników do sprawdzenia, co jest czasochłonne, i wtedy można - dla oszczędzenia czasu - nie sprawdzać dokładnie każdego elementu wyniku każdego testu, tylko częściowo: "czy testowany system nie zaraportował błędu lub nie uległ awarii". No, można. Uczy tego kurs podstawowy ISTQB. Poziom nowości = 0.

[kontynuuję temat jutro]

Dzień dobry :-) ponownie.

5. Aha, takie masowe ataki przydają się do testów bezpieczeństwa. Tak, to się nazywa testy penetracyjne, nie HiVAT. Ważne, nie nowe.

6. Data Driven Testing = prosty skrypt, dane z pliku. Nooo, znana od wielu lat metoda, opisywana w książkach i stosowana w praktyce. Dobra metoda, ale czemu HiVAT?? Wow, really groovy!

7. LSRT - długodystanswe testy regresji, zmiennymi sekwencjami testów. Tak, nic ciekawego, kolejny bezużyteczny skrótowiec - ten Cem Kaner to naprawde mistrz! Jak to zrealizować przy pomocy JUnit i TestNG - no, dobrze, że autor poprzestał na odwołaniu do dwóch tylko narzędzi testerskich, w końcu są ich setki.

8. "Rozwijany system, bazujący na" - lubię tę specyficzną polszczyznę ;-)

9. Fascynująca ilustracja nr 3 "Budowa Functional Equivalence Tester". Tak, sensowny diagram, rozsądna procedura. Ale nowość? Chyba w 1970 roku to była nowość?

PODSUMOWANIE: nie istnieją żadne "techniki HiVAT", to tylko bajerancka nazwa na zlepek starych (dobrych) pomysłów. Przedstawione w artykule i jego źródłach sposoby pracy sa znane od lat, dość oczywiste i nic nowgo nie wnoszą. Nie jest to krytyka tych technik, bardzo sensownych, tylko próby przedstawiania ich jako rzekomych nowości. Naprawdę, nie ma tam ani jednej nowej myśli.

Nie wiem, czy Cem Kaner i autor artykułu celowo stwarzają fikcję "nowej" metodyki, opisując kilka dobrych, ale zupełnie zwykłych i zupełnie nienowych technik, nic zresztą nie mających ze sobą wspólnego? Żeby się wywyższyć? Ej, przesadzam chyba. Bo nie wiedzą, jaka jest prawda, i wydaje im się, że odkryli koło? Na pewno nie. Więc pewnie dlatego, żeby w ogóle ktoś w naszym świecie, pełnym fejsbukowego zgiełku, w ogóle ich słuchał? Jeśli tak, to wybaczam, tylko proponuję zmianę tytułów: "Parę fajnych pomysłów testowych, przemyconych pod pozerskim pseudonimem HiVAT, żeby kompulsywnych wielbicieli nowości zadowolić". I wtedy jest OK!

Rynkowa Inżynieria Wymagań

Drugi na dzisiaj artykuł gotowy "Rynkowa inżynieria wymagań". Pojawi się w październiku w nowo powstałym piśmie inzynierii wymagań,  na req.wymagania.org.pl.
Fragment, dla smaku:

Wymagania, które znajduje marketing

Pamiętacie, jak kilkanaście lat temu część Ericssona, produkująca telefony komórkowe, połączyła się z firmą Sony? Nieważne, że później ten związek się rozpadł, ale jego początek był wyraźnym symptomem zasady, że tradycyjna inżynieria wymagań (Ericsson), wielce przywiązana do swego inżynierskiego, informatycznego rodowodu, w praktyce nie umiała nawet dostrzec, a co dopiero zagospodarować wielu atrybutów jakości / typów wymagań (Sony). Dziś ten rodzaj atrybutów jakości często nazywa się modnie „doświadczeniem klienta”(user experience, UX) i docenia jego wagę w odniesieniu do pewnych typów produktów. Inna nazwa wobec tych niejasnych wymagań, to „charyzma” (ang. charisma, James Bach).


Podstawowa rzecz, którą dobrze, coraz lepiej rozumie marketing, a która wciąż słabo dociera do świadomości działów badawczo-rozwojowych oraz produkcji, w tym do działów IT, to fakt, że doświadczenie klienta zależy w przeważającym stopniu nie od cech produktu, a od szeregu innych czynników, leżących poza samym produktem.


[...] Rozwiązanie tego pozornego paradoksu leży w znacznie ściślejszej, niż dzisiaj, współpracy marketingu oraz inżynierii wymagań. Marketing dba, a przynajmniej powinien zadbać o tak zwane zarządzanie doświadczeniem klienta (customer experience management, CEM). Według zasad CEM, na opinię klienta o produkcie, wpływ większy niż sądziliśmy, wywierają nie cechy samego produktu, ale następujące czynniki:
•    [...]
Te zależności doskonale opisuje tak zwany model Kano, bardzo słabo znany w IT. Dzieli on wymagania na trzy grupy: na (1) wymagania zwykłe, na (2) „zachwycacze” i na (3) „rozwściekacze”.


Poziom zadowolenia klienta jest z grubsza liniowo zależny z poziomem spełnienia wymagań zwykłych. Im lepiej produkt je realizuje, tym wyższe jest zadowolenie klienta.


Zachwycacze to te, których niespełnienie nikomu specjalnie nie doskwiera, ale kiedy choć w części są zrealizowane, wywołują efekt wielkiego WOW. Te wymagania są ważne dla takich produktów IT, których zawodność i zwykłe bugi są do zaakceptowania, ale atrybut trafnie nazwany przez Jamesa Bacha „charyzmą”, choćby dostępny tylko trochę, zaraz wywołuje lawinę lajków. Do nich zaliczają się gadżety, telefony, gry, wszelkie fejsbuki, twitery oraz instagramy, a nawet zupełnie normalne aplikacje internetowe: sklepy, portale informacyjne i plotkarskie, i te pokazujące pogodę.


Natomiast dla systemów wbudowanych / krytycznych dominują rozwściekacze: cechy, których płynnego działania wręcz nie zauważamy, ale najmniejsze potknięcie ciężko przeżywamy, albo i nie przeżywamy, jeśli zawiedzie na przykład ABS w hamulcach, czy system sterowania ruchem kolejowym, czy rozrusznik serca. One są jak powietrze, dlatego ci, którzy je testują, są cisi, solidni, mało mówią i dobrze pracują, i mało mają czasu na uleganie mistycznym modom typu XP, TDD, eksploracja i inne. Kto się nie lansuje, tego nie ma?


Elastyczni, piękni, młodzi!

Zapraszam na konferencję "Agile w biznesie":


Aby zachęcić, zamieszczam tutaj poniżej fragement artykułu, który w całości pojawi się w materiałach promocyjnych do konferencji.

Elastyczni, piękni, młodzi

Ananke

W znakomitym opowiadaniu Stanisława Lema pod tytułem „Ananke”, dochodzi do katastrofy rakiety, zawinionej przez system informatyczny, którego tryb działania odzwierciedlał zaburzenia neurotyczne jednego ze swoich twórców. „W tę niezawodność wkroczył człowiek ciepiący na lęk przed nieznanym i zwalczający go rytuałami natręctw. […] Uważał, że tempo sprawdzania agregatów ma być skorelowane z wagą procedury. […] Każdy z tych komputerów cierpiał na syndrom anankastyczny: przymusowe powtarzanie operacji, komplikowanie czynności prostych, manieryzm, obrządkowość, uwzględnianie wszystkiego naraz.”

Ciekawym byłoby rozważanie, w jaki sposób nasze lęki wpływają na sposób działania wielu programów, ale tutaj zajmiemy się sprawą prostszą i bardziej podstawową: jak nasze lęki wpływają na nasz sposób pracy.

Lęk przed nieznanym odczuwamy wszyscy. Aby go okiełznać, chcemy mieć poczucie, że tę groźną, nieznaną przyszłość umiemy przewidzieć i kontrolować. U steru wielkich korporacji, zamawiających, lub dostarczających, systemy IT, najczęściej stoją ludzie, którzy unikają niepewności i podejmowania ryzyka, woląc bezpieczeństwo, nadzór i kontrolę. W przeciwnym razie, raczej założyliby własną firmę, może IT, może „adventure travel”, a nie wybrali karierę w hierarchicznej organizacji. Stąd ogromne w pewnych kręgach biznesu i zarządzania zamiłowanie do ciężkich, zawiłych metod zarządzania, do nadmiernie szczegółowego planowania, do utrzymywania fikcji, że już dzisiaj możemy precyzyjnie zaprojektować system, który uruchomimy dopiero za rok. Nawet doświadczenie, że to nieskuteczne, nie pomaga zwolennikom takiego podejścia: cóż z tego, że plany okażą się nietrafne, a dostarczony system nieadekwatny do potrzeb? Ważniejsze są dla nich własne lęki społeczne: skoro postępuję według PRINCE2®, PMBOK lub ITIL, nikt mi nie zarzuci niekompetencji ani nieprawidłowości.

Agile a nerwica natręctw

Myślę, że powyższy akapit sprawił nieco radości zwolennikom podejścia zwinnego, w krzywym zwierciadle pokazując preferowanie metod sekwencyjnych, planowych, jako skutek skrywanych lęków kadry zarządzającej. Ruch agile powstał przecież w pewnym stopniu, jako ruch protestu przeciwko ciemnogrodowi tradycyjnych szefów, traktujących produkcję oprogramowania tak samo, jak produkcję hutniczą czy budowanie mostów.

Nie cieszmy się jednak zanadto, bo lęk, a w szczególności jego ostre objawy w postaci nerwicy natręctw, wyraża się w każdym nadmiernym przywiązaniu do jednej, jedynej, dającej ukojenie metody, zwalniającej nas ze strachu przed nieznanym i z poczucia odpowiedzialności. W szczególności, wiele ceremoniałów / rytuałów agile i stosowany przez proroków tego podejścia pół-religijny, obrzędowy język uzasadnień, budzi obawy, że ma on nie tylko rzeczowe, ale także kojące uzasadnienia.