czwartek, 30 października 2014

Blogus Dei: strach otwierać II linię metra??

Czytamy:

"II linia metra nie zacznie działać szybko, bo podczas odbiorów wychodzą usterki". [ Aha, znowu testerzy zawinili ;-) ]

"Rektor prof. Jan Szmidt przypomniał, że uczelnia jest związana z tą inwestycją od dziesiątków lat. W prace przy II linii angażują się naukowcy z pięciu wydziałów, m.in. ratowali przed zawaleniem tunel Wisłostrady po osunięciu się ziemi na budowie stacji Powiśle. Powstały już cztery doktoraty dotyczące metra i jedna habilitacja, a druga jest w toku."

Doktoraty, habilitacje, rektorzy: a nikomu do głowy nie przychodzi, to że te "odbiory" (po ludzku: testy) można przeprowadzać w większości zawczasu, równolegle z pracami trwającymi gdzie indziej? Że togo nie musi się, ba - jest kapitalną głupotą! - takie "odbiory" odkładać na sam koniec?

"Stołeczna" dowiaduje się o usterkach podczas odbiorów technicznych kolejnych stacji. - Na przykład znowu zacinały się bramki wejściowe nowego typu, a inspektorzy Metra sprawdzają wszystko dokładnie, bo nie chcą mieć potem problemów, że coś nie działa od razu po otwarciu - mówi nasz informator."

"Tutaj, wśród inżynierów i fachowców, trudno coś powiedzieć o budowie metra mnie, skromnemu prawnikowi - stwierdziła wczoraj prezydent Warszawy".

Oczywiście, inżynierowie i naukowcy, zwłąszcza habilitowani, mają to w nosie, bo to "tylko" sprawa organiacji pracy, doktoratu się na tym nie zrobi. Prawnicy, też mają to w nosie, bo umowy wygodniej pisać tak, żeby owe mityczne "odbiory" były na końcu, oficjalne, poważne i... powodujce opóźnienia.

Czy nigdy sztuka testowania ("the art of testing", nie tylko oprogramowania) nie trafi pod strzechy? Czy w budownictwie naprawdę "odbiory" pozostaną zawsze tymi ponurymi rytuałami, zamiast umiejętności WYKRYCIA ZACINAJĄCYCH SIĘ BRAMEK JUŻ W TRAKCIE ICH MONTAŻU, LUB ZARAZ POTEM?

Czasem narzekam, że branża IT pod pewnymi względami pozostała w epoce manufaktury, że nie ma nawet ambicji doścignięcia innych branży pod względem niezawodności procesu produkcyjnego. Jednak w penwych obszarach - testowania, zamiast "odbiorów", bijemy innych na łeb, na szyję.

wtorek, 28 października 2014

Umowa wdrożeniowa, czy inżynieria oprogramowania?

1.    Nieporozumienia od samego początku

Już samo określenie „umowa wdrożeniowa”, jednoznaczne dla prawnika, wprawia w osłupienie informatyka, bowiem „wdrożenie”, to po informatycznemu, wyłącznie ostatnia faza projektu IT, kiedy to wcześniej zaprojektowany, zbudowany (albo „zaimplementowany”) i przetestowany system uruchamia się w środowisku docelowym (operacyjnym) tak, aby był w pełni gotowy do działania operacyjnego (albo „produkcyjnego”, „na produkcji”). Dla człowieka, znającego tylko terminologię informatyczną, nazywanie umowy na realizację systemu, umową „wdrożeniową”, ma więc tak samo mało sensu, ile miałoby nazwanie kontraktu na budowę statku, kontraktem na jego „wodowanie” :-).

Podobna niezgodność występuje zresztą także w innych językach, nie tylko po polsku. Na przykład po angielsku, często spotykanym określeniem takich umów, jest „implementation contract”, albo „implementation agreement”, a przecież „implementacja”, tak samo jak „wdrożenie”, to w informatycznym języku tylko jedna z wielu faz projektu tworzącego system.

Co ciekawe, ten językowy kłopot występuje głównie dla umów dotyczących systemów informatycznych. Dla domów, nikt nie powie „umowa na wdrożenie domu”, lecz „umowa na budowę domu”, albo na „wykonanie domu” – to słowa o wiele bardziej intuicyjne i zgodne z językiem codziennym. Inne produkty – na przykład filmy, projekty, zadania – „realizuje się”, albo „stwarza”, a nie „wdraża”.

Być może – nie jestem dostatecznie biegły w sprawach prawniczych, aby to rozstrzygnąć – istnieje jakaś subtelna różnica między „umową na stworzenie systemu”, „umową na wdrożenie systemu” i „umową na zbudowanie systemu”; może użycie różnych słów sygnalizuje inny zakres odpowiedzialności wykonawcy? Tak, czy inaczej, mamy tutaj i ryzyko nieporozumień, i kłopotliwe zawiłości interpretacyjne, i wyraźną rozbieżność między technicznym a prawniczym spojrzeniem, czyli te same symptomy, które widać również w wielu innych miejscach, kiedy przyglądamy się problemom z tworzeniem, negocjowaniem i realizacją umów wdrożeniowych.

Dlatego temat ten nie jest wyłącznie lingwistyczną ciekawostką, a istotnym wyzwaniem: odmienność terminologii, i wzajemna niedostateczna znajomość realiów powoduje, że umowy wdrożeniowe często nie są tak dobre, jak mogłyby być, gdyby te przeszkody usunąć. Mam nadzieję, że ten artykuł może stać się pierwszym krokiem na drodze ich likwidowania.

2.    Legenda odmienności agile

Wielu prawników jest zdania, że umowy na realizację projektów metodami agile powinny być zupełnie inne od umów tradycyjnych, a samo agile cieszy się sławą czegoś niezmiernie dziwnego i trochę nawet podejrzanego: cóż to bowiem za metodyka, która nie pozwala – jak sądzą prawnicy - określić z góry zakresu planowanej pracy, czyli – można ulec takiemu wrażeniu – wyklucza możliwość zapisania przedmiotu umowy, co z punktu widzenia prawa jest zasadniczym mankamentem?

Znaczną część winy za ten stan rzeczy ponoszą metodyki agile, świadomie bardzo mocno akcentujące swoją odmienność i wyjątkowość, zarówno tę prawdziwą, jak i tę pozorną, ideologicznie wyolbrzymianą. Bardzo wielu propagatorów podejścia agile posługuje się stylem pompatycznym, niemal uduchowionym, co nie sprzyja znajdowaniu punktów stycznych ze światem nie-agile, w tym prawniczym, a niewtajemniczonym utrudnia zrozumienie, o co tak naprawdę w tej metodyce chodzi. Piszę o tym dość obszernie w mojej książce „Agile – szansa na skokowy wzrost produktywności” (wydawnictwo „Wiedza i Praktyka” 2014).

Drugi problem, to celowo odmienna od tradycyjnej terminologia agile. Nie ma w niej żadnej mistyki – doskonale daję się ją przełożyć na terminologię tradycyjną, tylko trzeba to umieć zrobić.

Miłośnicy historii IT mogą dociec, że jedną z przyczyn skłonności niektórych praktyków agile do niejakiej niefrasobliwości wobec wymogów umów wdrożeniowych, jest współudział tak zwanej ideologii „programowania ekstremalnego” (XP) w tworzeniu zasad agile. XP ma zaś swoje korzenie w drugiej połowie lat dziewięćdziesiątych, w latach ogromnego wzrostu biznesu internetowego, kiedy chodziło o to, aby, cytuję: „wydajnie realizować małe i średnie projekty wysokiego ryzyka, czyli takie, w których nie wiadomo do końca, co się tak naprawdę robi i jak to prawidłowo zrobić” (pl.wikipedia.org/wiki/Programowanie_ekstremalne). Czym takie podejście się skończyło, można przeczytać w innym artykule Wikipedii, na temat „bańki internetowej”.

Ze strony metody agile, zarówno niejaka ideologizacja metodyki, jak i posługiwanie się własną, zamkniętą terminologią, mają jednak nie tylko prestiżowe, ale też najzupełniej merytoryczne uzasadnienie. Trzeba bowiem zdać sobie sprawę, że możliwe wielkie korzyści zastosowania agile (w tym tytułowy, dramatyczny wzrost wydajności) wymagają naprawdę radykalnego porzucenia wielu starych praktyk i mocno utrwalonych, złych przyzwyczajeń, co nie jest łatwe – więc pewien radykalizm może być w tym pomocny.

Aby zlikwidować otaczające agile fałszywe mity, wystarczy tę metodą opisać prostymi słowami, a nieporozumienia – wyjaśnić. Myślę, że prawnikom i innym interesariuszom projektów spoza świata IT bardzo pomocny byłby jednodniowy kurs „agile dla prawników”. Poniżej, próbnie, dokonam paru takich demistyfikacji. Podobnie, do szkoleń dla uczestników, a zwłaszcza dla kierowników projektów agile, warto by dorzucić garść wiedzy o uwarunkowaniach prawnych.

Agile to metoda budowania systemów bez określonych wymagań? Jest wręcz przeciwnie, projekt agile nie może się toczyć bez wymagań na tyle dokładnych, aby jednoznacznie określały, co mają zrealizować programiści.

Prawdą jest natomiast, że agile zakłada możliwość nawet znacznych zmian wymagań niskopoziomowych równolegle z tworzeniem kodu (implementacją), oraz że dopuszcza, wręcz zaleca rozpoczęcie prac nad implementacją gdy tylko choć część wymagań jest dostatecznie doprecyzowana, nie czekając na szczegółowe określenie wszystkich. Z punktu widzenia umowy wdrożeniowej jest to bez znaczenia – wymagania tak szczegółowe nie wchodzą w jej skład, ani nawet w skład załącznika do umowy, zwanego często dokumentem analizy lub specyfikacją funkcjonalną.

  • Kolejne terminologiczne dziwadło – dlaczego specyfikacja wymagań nazywana jest specyfikacją funkcjonalną? A co z kluczowymi wymaganiami poza-funkcjonalnymi (niefunkcjonalnymi): użytecznością, doświadczeniem klienta, wydajnością, zabezpieczeniami – czyżby były nieważne?
Po prostu niejakiej rewizji musi ulec tradycyjny model, wedle którego etap analizy poprzedza etap realizacji. W podejściu agile (i w ogóle w każdym podejściu tak zwanym iteracyjnym, którego agile jest tylko jednym z wielu przedstawicieli) analiza i realizacja do pewnego stopnia toczą się równolegle, naprzemiennie. Nie powinno być to żadną trudnością do zdefiniowania w umowie wdrożeniowej.

Dla żadnej ze stron umowy nie jest celem, aby zniszczyć drugą stronę umowy karami umownymi, przygwoździć, zmusić do poniesienia strat, tylko celem jest, aby powstał dobry system informatyczny, przynoszący zleceniodawcy biznesową korzyść, a wykonawcy godziwą zapłatę. Strategia na oszukanie i wykorzystanie drugiej strony jest oczywiście bardzo krótkowzroczna, ale… przez to niekiedy kusząca.

Umowy, zakładające realizację metodą agile, szczególnie wymagają oparcia się tej pokusie. Aby projekt naprawdę zakończył się sukcesem, konieczna jest intensywna, partnerska współpraca zamawiającego i wykonawcy. Agile wymaga, aby warunki tej współpracy były szczegółowo opisane w umowie. Pokusa zamawiającego, aby porzucić wykonawcę z niedoskonałymi wymaganiami (załącznikami do umowy) i – licząc na skuteczność sankcji kryteriów odbioru oraz wpisanych do umowy kar – przyjść po gotowy system po, dajmy na to, pół roku, ta pokusa musi być przezwyciężona.

Dlatego umowy pisane pod kątem agile muszą więcej miejsca, niż umowy tradycyjne, poświęcić dość szczegółowym opisom procedur współpracy, oraz sankcji za ich nieprzestrzeganie, łącznie z prawem do odstąpienia od umowy.

Nie jest to jednak żadna radykalna odmienność – artykuł 630 Kodeksu cywilnego przewiduje konieczność odpowiedniej współpracy zamawiającego z wykonawcą, oraz sankcje nie wywiązywania się z niej. Miło pomyśleć, że ustawodawca aż tak uwzględnił potrzeby metodyki agile :-)

W projekcie agile nie ma kierownika projektu? Z powodu odmiennej terminologii, o której już mówiliśmy, nie ma wprawdzie osoby o takim tytule, ale z perspektywy sponsorów projektu, a więc osób będących stroną umowy, funkcję kierownika projektu pełni tak zwany właściciel produktu (ang. Product Owner). W żadnym razie nie jest kierownikiem projektu osoba mająca tytuł „scrum master” – jej funkcja jest zupełnie inna.

Ponadto, nic nie stoi na przeszkodzie, żeby całością projektu, realizowanego w ramach metodyki agile, zarządzał także tradycyjny kierownik projektu. Jego uprawnienia do wewnątrz projektu będą mniejsze, niż zwykle w projektach nie-agile, ale to nas nie interesuje na poziomie umowy.

Agile, to nieustanna i niemożliwa do nadzorowania zmienność? Nieprawda – zmienność w agile można i należy kontrolować. Nie pojawi się ona w ogóle, jeśli zamawiający zna od początku, z góry swoje potrzeby i wymagania tak dobrze, że jest je w stanie bezbłędnie określić. Jeśli ten warunek nie jest spełniony, a prawie nigdy nie jest, bo to poznawcza niemożliwość, wówczas na pewno lepsza jest zmienność planowana i przewidywana przez procedury agile, niż zmienność wprowadzana cichaczem, poprzez tak zwane „wrzutki”, albo „cichociemne CR-y” (autentyczne nazewnictwo!), przy zachowaniu pozorów nienaruszonych założeń, co nagminnie dzieje się w projektach tradycyjnych.

We wszystkich umowach wdrożeniowych, także tych zupełnie nie-agile, przewiduje się możliwość późniejszych zmian, zarówno wymagań, jak ich priorytetów, czy harmonogramu. Do tego celu umowy określają odpowiednie narzędzia i procedury do radzenia sobie z propozycjami zmian (CR). Umowy dla agile tym różnią się od tradycyjnych, że przewidują więcej takich zmian i precyzyjniej regulują tryb zarządzania nimi, podczas trwania całego projektu.

3.    Osierocone załączniki merytoryczne

Prawniczy punkt widzenia podkreśla wagę odpowiedniego zdefiniowania przedmiotu umowy, czyli produktu IT, który ma być zrealizowany. Niemniej, zadaniem prawa jest przede wszystkim dbałość o zgodny z jego regułami tryb zawierania umów, nie zaś o ich biznesową sensowność ani nie o techniczną poprawność. Prawnik domaga się, aby do umowy istniały odpowiednie załączniki merytoryczne, określające jej przedmiot, ale nie wnika w ich poprawność, kompletność ani jakość ich uzasadnienia biznesowego. Niemniej, prawnicy bystrze dostrzegają pewne częste błędy, na przykład, kiedy załącznikiem merytorycznym staje zapytanie ofertowe (lub – pośrednio - SIWZ, dla przedsięwzięć objętych prawem o zamówieniach publicznych), albo oferta, bowiem te dokumenty nie stanowią dostatecznej podstawy, są zbyt ogólnikowe, czasem sprzeczne.

Ryzyko podpisywania umowy, której przedmiot jest niedostatecznie określony, jest oczywiste i dotyczy zarówno wykonawcy, jak i zamawiającego. W interesie obu stron jest umowa możliwie prosta i przejrzysta, nie przesadnie szczegółowa, pozwalająca na skuteczną egzekucję jej ustaleń. Aby to osiągnąć, jej załączniki merytoryczne również muszą spełniać te same kryteria.

Istnieje nauka, mogąca nam znakomicie pomóc w tworzeniu dobrych załączników merytorycznych do umów wdrożeniowych – to inżynieria wymagań. Inżynieria wymagań określa zasady, które obowiązują podczas następujących działań:
  • Pozyskiwanie i konsolidacja wymagań – określenie celu biznesowego przedsięwzięcia, identyfikacja zakresu oraz kontekstu systemu, jego interesariuszy, w tym użytkowników, i zdobywanie od nich informacji na temat systemu.
  • Analiza wymagań – badanie, czy znalezione / zdobyte wymagania są zrozumiałe, spójne, dostatecznie szczegółowe, nie zawierają zbędnej redundancji.
  • Specyfikacja wymagań – opisywanie wymagań, w języku naturalnym lub w formie różnych modeli (modelowanie wymagań), tak, aby były jednoznaczne.
  • Walidacja i negocjowanie wymagań – sprawdzanie, czy wymagania spełniają kryteria jakości oraz uzgadnianie wymagań z różnymi interesariuszami lub grupami interesariuszy.
  • Utrzymanie wymagań (także: zarządzanie wymaganiami) – archiwizowanie, wersjonowanie, zarządzanie zmianami wymagań.
Proces inżynierii wymagań częściowo poprzedza proces negocjacji umowy wdrożeniowej (np. określenie celu biznesowego), częściowo wpisuje się w niego (np. negocjowanie wspólnego stanowiska różnych interesariuszy), a w dużej części odbywa się także już po podpisaniu umowy, zwłaszcza w podejściu agile.

Dla prawników, korzystna byłaby znajomość podstaw i centralnych pojęć inżynierii wymagań. Podobnie, osoby pełniące role analityków (rzadsza, choć merytorycznie trafniejsza, nazwa tej funkcji to inżynierowie wymagań), często mają niedostateczną wiedzę w zakresie prawnych uwarunkowań procesu i dokumentacji wymagań. Zapraszam Czytelników do udziału w cyklu darmowych warsztatów on-line na temat inżynierii wymagań: http://cts.com.pl/Aktualnosci/Inzynieria-wymagan---jak-skutecznie-i-sprawnie-zarzadzac-projektami-IT-.

Inne ważne zagadnienie, ale spoza zakresu tego artykułu, to sytuacja, gdy względy prawne dotyczą nie tylko umowy, także do samego produktu IT. Wówczas prawnicy są istotnymi interesariuszami, których zalecenia wchodzą w skład wymagań.

4.    Odbiory, kryteria i testowanie

Podstawowym komponentem umowy wdrożeniowej jest opis kryteriów, procedury i metod odbioru produktu IT. Zwłaszcza, jeśli załącznik merytoryczny opisany w poprzednim akapicie, czyli dokument analizy, specyfikacja wymagań, czy jakkolwiek go nazwiemy, jest niedostateczny, opis kryteriów odbioru staje się jego uzupełnieniem, rozstrzygającym dla prób stwierdzenia, czy i na ile dostarczony produkt spełnia warunki umowy. Rozważamy tutaj przede wszystkim tak zwany odbiór jakościowy; odbiór ilościowy jest prostszy i niczym nie różni się od zasad odbioru innych produktów, niż informatyczne.

W praktyce, umowy wdrożeniowe, jako główne kryterium i zarazem metodę odbioru jakościowego przewidują testy: załącznikiem merytorycznym do umowy jest więc często zestaw scenariuszy testowych, których wykonanie z wynikiem pozytywnym traktuje się potem jako dowód zgodności dostarczonego systemu z wymogami umowy.

W rzeczywistości, pojawia się tutaj mnóstwo wątpliwości, trudności i nieporozumień, które komplikują proces odbioru, w najgorszym razie mogą doprowadzić do kosztownych sporów w sądzie, a w każdym razie, powodują chaos i marnotrawstwo środków zarówno po stronie zamawiającego, jak i dostawcy. Podstawową przeszkodą jest z jednej strony niemal zupełna nieznajomość metod „testologii”, czyli istniejącej obszernej nauki o testowaniu, wśród prawników, a z drugiej strony, zupełne pomijanie potrzeb i realiów umów wdrożeniowych w licznych książkach i szkoleniach dla specjalistów testowania, w tym w popularnej serii certyfikatów ISTQB (istqb.org). Słowo „odbiór” jest niemal nieznane wśród specjalistów testowania, zastępuje je pojęcie „testów akceptacyjnych”.

Tematy, ważne z punktu widzenia umów wdrożeniowych, takie jak sposoby weryfikacji (nie tylko testy!), weryfikacja a walidacja, moment rozpoczęcia korzystania produkcyjnego a odbiór, możliwość odbioru warunkowego, jednostronny odbiór, podział testów między zamawiającego a wykonawcę, wreszcie wymagana staranność testów odbiorczych, wszystko to można by interesująco naświetlić z punktu widzenia zasad testowania, ale minimum, to nie artykuł, lecz jednodniowe szkolenie „testowanie dla prawników”, które może uda mi się kiedyś zrealizować. Tutaj ograniczę się do jednego przykładu, mam nadzieję, że przekonywującego, pokazującego korzyści łącznia prawa umów wdrożeniowych i zasad testowania.

Otóż testy odbiorcze („akceptacyjne” w terminologii testowej) można znacznie skrócić i przyśpieszyć, a także istotnie zmniejszyć ich dramatyczność, spowodowaną wielką liczbą wykrywanych przez nie w ostatniej chwili błędów, gdyby wykorzystać, powszechnie znaną analitykom testowym, zasadę znacznego udziału testowania wcześniejszego w procesie odbioru. Ze strony zamawiającego, wymagałoby to współudziału w projekcie. Metoda agile, zakładająca przyrostowe (po kawałku) dostawy produktu, może być dobry sposobem na realizację tego postulatu.

5.    Co dalej?

Myślę, że temat warto drążyć dalej i (1) zapraszam do dyskusji – bogdan.bereza@victo.eu; (2) myślę, że nie od rzeczy byłoby jakieś przedsięwzięcie o takim profilu, wspólnie zorganizowane przez prawników oraz informatyków. Spróbujemy!

poniedziałek, 27 października 2014

Symulacyjne gry szkoleniowe w IT

1.    Gracze rozstawiają figury

Nauczam rozmaitych przedmiotów od dawna. Zacząłem, jeszcze jako nastolatek, ale nigdy nie robiłem tego w tradycyjnej szkole, a więc zawsze moim celem było rzeczywiście nauczyć, a nie wzmóc swój prestiż, okazać władzę, popisać się erudycją czy też zaimponować uczniom, mówiąc, jak to dana dziedzina jest rzekomo strasznie trudna i skomplikowana. Stąd bierze się moje zainteresowanie skutecznością. Napisałem już na ten temat kilka tekstów:
  • „Kupując wiedzę: przewodnik po szkoleniach” (2001)
  • “This Is Simply Not True! Test Teacher’s Confessions” (2004)
  • „Jak sprzedawać nietypowe szkolenia? Podręcznik cynicznego sprzedawcy” 2006
  • „Nareszcie kryzys” 2008
  • „Open Accreditation for Better Certification” (2011).
Dość wygodne jest nauczanie wąskich, praktycznych umiejętności: na przykład języków, zarówno tych naturalnych, jak i języków programowania, obsługi narzędzi, zarówno IT jak i tradycyjnych, systemów operacyjnych, czytania mapy i orientacji w terenie, gotowania, standardu PRINCE2, albo procedury obsługi pralki. Przy stosunkowo niewielkim wysiłku cel zostaje osiągnięty, a korzyść dla uczniów jest oczywista i nieulegająca wątpliwości: automatycznie dobrze oceniają oni nauczyciela, lub trenera, dzięki któremu potrafią zrobić lub nazwać to, co ledwo kilka dni czy nawet kilka godzin wcześniej było nieznane, albo sprawiało trudności.

Sam przebieg takiego szkolenia też zwykle nie przynosi niespodzianek. Zakres tematyczny jest dokładnie określony, potrzeby uczestników – jednoznaczne i dobrze przez nich uświadomione, więc o ile tylko prowadzący jako-tako zna zagadnienie, nie musi spodziewać się ani nieoczekiwanej konieczności modyfikacji zakresu, ani zbyt trudnych pytań, ani zaskakujących zwrotów akcji. Zbędne, a w każdym razie niekonieczne są też wszelkie aktywizujące, motywujące i angażujące sztuki dydaktyczne – konkretna i świadoma potrzeba uczestników jest ich najlepszym stymulatorem. Dzięki temu, takie szkolenie może poprowadzić każdy, kto choć trochę zna temat. Z pomocą gotowych slajdów prezentacji, na które prowadzący może sobie dyskretnie zerkać, jest to jeszcze łatwiejsze.

Trudniejsze, znacznie trudniejsze jest nauczanie umiejętności szerszych, takich jak – między innymi - większość obszarów inżynierii oprogramowania. Wprawdzie niektórzy dostawcy szkoleń IT pod nazwą „inżynieria oprogramowania” umieszczają zwyczajne szkolenia narzędziowe i językowe (na przykład [ocenzurowano] - nie jest to przykład odosobniony), ale wynika to z niezrozumienia, niestety dość powszechnego, czym naprawdę jest inżynieria oprogramowania. W innych branżach takie pomyłki są rzadsze, nikt raczej pod nagłówkiem „architektura”, „budownictwo” czy „inżynieria budowlana” nie umieści szkoleń z zakresu posługiwania się młotkiem, pędzlem, śrubokrętem czy koparką. Pozostawiwszy jednak na boku te kłopoty z nazwami, można stwierdzić, że nauczanie inżynierii oprogramowania, tak samo, jak innych szerokich, otwartych tematów, jest wyzwaniem. To wyzwanie ma wiele wymiarów, skoncentruję się tutaj na dwóch najważniejszych:
  • Zdobycie przez uczestników umiejętności łączenia teorii z praktyką, czyli wyboru i zastosowania odpowiednich modeli rozwiązań do rzeczywistych sytuacji;
  • Uświadomienie sobie przez uczestników swoich rzeczywistych potrzeb oraz zrozumienie, jak do nich stosuje się tematyka szkolenia; to jest koniecznym warunkiem powstania zainteresowania i utrzymania się motywacji podczas trwania szkolenia, zadowolenia uczestników oraz uzyskania przez nich - po szkoleniu - długoterminowych korzyści.
Metody, wystarczające przy realizacji szkoleń wąskich, praktycznych umiejętności, zawodzą wobec nauczania tematów ogólniejszych, złożonych, takich jak – między innymi - zarządzanie (w tym – zarządzanie projektami), inżynieria wymagań, analiza biznesowa, zapewnienie jakości oprogramowania, testowanie.

2.    Analiza finansowa

W sumie, każdemu opłacają się bardziej umiejętności, które powyżej nazwałem szerszymi, czyli na nieco wyższym poziomie abstrakcji. Wiedzę szczegółową daje się zastosować tylko w jednej sytuacji, tylko w określonych okolicznościach, podczas gdy wiedzę ogólniejszą – we wszystkich podobnych sytuacjach. Najcenniejsza jest zgeneralizowana umiejętność uczenia się, pozwalająca radzić sobie lepiej niż inni w każdej nowej sytuacji, co - zwłaszcza w branży IT, gdzie nowości pojawiają się bez przerwy - przekłada się na decydującą przewagę konkurencyjną.

Podsumowując: najbardziej opłaca się wiedza szeroka, czyli… teoretyczna! Jak to? Przecież na co dzień, dla trenera nie ma gorszej opinii, niż ta, że jego wykłady są zbyt „teoretyczne”, a dla konferencji czy szkolenia najwyższą pochwałą jest, że jest „praktyczna”. Skąd ten rozdźwięk?

Popatrzmy na poniższą tabelę:

Potrzeba:             Teoria  A      B      C      Suma kosztów
Koszt szkolenia 1:    0       6.000  8.000  6.000  20.000
Koszt szkolenia 2:    10.000  3.000  4.000  2.000  19.000


9 stycznia 2015: zmieniłem dane, poprzednie były błędne :-(
Dziękuję http://www.goldenline.pl/jakub-wojt za wskazanie błędu! 

Tabela 1. Koszty szkoleń praktycznych i teoretycznych

Dane w tabeli ilustrują zależność kosztów zdobywania wiedzy , potrzebnej w nowej sytuacji (kolumny A – C w tabeli) od tego, czy ma się w danym obszarze podstawy teoretyczne. Dane są oczywiście uogólnione, mają za zadanie tylko ilustrować ogólną zasadę. Przy takich założeniach, kosztowne i na pierwszy rzut oka nieopłacalne szkolenie teoretyczne, amortyzuje się z nawiązką już po kilku (w naszym przykładzie – trzech) kolejnych sytuacjach, gdzie niezbędna okazała nowa wiedza.

Modny dziś, jednostronny nacisk na korzyści umiejętności praktycznych, na praktyczne doświadczenia, jest poważną przeszkodą dla kreatywności, dla długofalowych inwestycji, dla rozwoju; to recepta na dreptanie w miejscu i podążenie za modą, którą stworzyli inni.

Słyszę głosy protestu? Oczywiście, macie rację! - powyższe wyliczenie jest trafne tylko pod warunkiem, że posiadana wiedza teoretyczna rzeczywiście przekłada się na obniżenie kosztów zdobywania kolejnych umiejętności praktycznych, co przecież nie zawsze się sprawdza.

Podobnie, wyciągnąwszy z zanadrza kolejny mocny argument na rzecz opłacalności umiejętności teoretycznych: że dzięki nim możliwe są nie tylko działania reaktywne, radzenie sobie z nieuniknionymi kłopotami, ale także działania proaktywne – zapobiegania kłopotom, ulepszania sposobu pracy, tworzenia nowych technologii, spotkałbym się ze słusznym zastrzeżeniem, że nie każda wiedza teoretyczna przekłada się na takie pożądane ulepszenia, że równie często,  może nawet częściej staje się jałowym i nieprzydatnym teoretyzowaniem.

Wiedza teoretyczna jest jak laska dynamitu: odpowiednio zastosowana, wysadza skały i usuwa przeszkody, źle użyta nie służy do niczego, albo wręcz może wysadzić domy.

Jak więc zapewnić sobie korzyści, jednocześnie unikając zagrożeń?

3.    Wykłady, warsztaty, seminaria, coaching i doradztwo

Wykład jest najprostszym sposobem nauczania: to w zasadzie mówiona książka, bez ćwiczeń. Doskonale nadaje się do tego, aby wysyłać wiedzę do innych, ale  jego skuteczność dla odbiorców jest już znacznie mniejsza. Wykłady od biedy mają sens wówczas, gdy – jak na studiach – najpierw dostaje się, podczas wykładów, obfity blok wiedzy teoretycznej, a potem – jest okazja, by tę wiedzę próbować zastosować w praktyce. Ponadto, wykłady – ale tylko krótkie! – mogą być wygodnym narzędziem do motywowania, inspirowania, szybką – szybszą niż tekst pisany – odpowiedzią na potrzebę chwili.

Nie bardzo jednak widzę miejsce dla tej formy nauczania w szkoleniach komercyjnych, bo wykład, to dopiero początek nauki, pierwszy krok. Nieskuteczne jest więc, porzucić uczniów i zostawiać ich samym sobie zaraz po pierwszym kroku.

Niedostatkom wykładów – w tym ich usypiającemu działaniu, nawet wobec uczestników rzeczywiście zainteresowanych – usiłuje się przeciwstawiać rozmaite formy przedsięwzięć szkoleniowych takie, gdzie uczestnicy biorą aktywny udział. Rzeczywiście, warsztaty, dyskusje, prace w grupach są zwykle znacznie ciekawsze i bardziej inspirujące od wykładów, ale czy naprawdę lepiej uczą, skuteczniej przekazują wiedzę i umiejętności?

Osobiście mam także sceptyczny stosunek do rozmaitych tak zwanych warsztatów. Są one manną z nieba dla przepracowanych nauczycieli, ale czy naprawdę są równie dobre dla uczestników? Najpierw pokazuje się kilka przeźroczy z teoretycznymi podstawami, potem stawia zagadnienie albo zadaje pytanie, po czym następuje pół godziny pracy w grupach, pięciominutowa prezentacja każdej z grup i voilá! – nauczyciel nie przemęczony wędruje do domu z dobrymi ocenami warsztatu na ankietach. Uczestnicy też czują się dobrze, pogadawszy z pełnymi zrozumienia partnerami niedoli przez kilka godzin. Pozostaje jednak pytanie, czy ktokolwiek czegokolwiek naprawdę nowego się nauczył?

Kurs szkoleniowy nie powinien przypominać spotkania anonimowych alkoholików, gdzie uczestnicy wspólnie roztrząsają swoje poczucie nieadekwatności, wyznają swoje winy i potknięcia, żalą się na bezduszny świat i w końcu wędrują do domu z uczuciem ulgi i pogodzenia ze sobą!” [requirementsjournal.com/PL/Wiedza/kupujac_wiedze.pdf]

Coaching i doradztwo w konkretnych sytuacjach, nie są wprawdzie zaliczane do szkoleń, ale służą temu samemu: kierowaniu rozwojem wiedzy i umiejętności. Jak wykład jest wygodny dla nadawcy, ale niedobry dla odbiorcy, tak doradztwo jest wprawdzie znakomite dla odbiorcy, ale skuteczne jest jedynie pod warunkiem ogromnego zaangażowania czasu i środków, z obu stron. Jednak świat, gdzie każdy będzie miał swojego indywidualnego coacha – doradcę – mentora, chyba nie nadejdzie nigdy, o ile takiego rozrzutnego szaleństwa nie sfinansują nam jacyś Marsjanie.

Żarty na bok – jest droga pośrednia. Symulacyjne gry szkoleniowe łączą w sobie zalety tych trzech form nauczania: wykładu, warsztatu oraz doradztwa. Co więcej, pozwalają sprawnie łączyć teorię z praktyką, uczyć się sposobów elastycznego dobierania metod, poznanych w teorii, do wyzwań, spotykanych w rzeczywistości. Ich prowadzenie wymaga od trenerów najwyższych kwalifikacji, zarówno merytorycznych, jak i metodycznych, oraz dużego doświadczenia, co pośrednio może stać się korzystnym czynnikiem hamującym wielką inflację kwalifikacji, wymaganych do prowadzenia szkoleń, jakiej doświadczamy od kilkunastu lat.

4.    Szkoleniowe gry symulacyjne dzisiaj

Można je zrobić na zamówienie, w różnych formach, od gier planszowych, poprzez rozmaite układanki  i łamigłówki, gry typu znanego „monopolu”, albo projektowanie (np. oferta firm „Pracownia gier”, pracowniagier.pl oraz „MindLab”, mindlab.pl). Dominuje oferta gier menedżerskich: symulacje finansowe, tworzenie strategii, zarządzanie zasobami ludzkimi, sprzedaż (np. trenerzy.pl). Przeszukując zasoby Internetu pod hasłem „szkoleniowe gry symulacyjne” (po angielsku najbliższy znaczeniowo termin to „simulation based training games”), można wręcz ulec wrażeniu, że to podejście dominuje, ale to złudzenie: nadal symulacyjne gry szkoleniowe są raczej rzadkością, a firmy, które je realizują, liczą za swoje usługi znacznie więcej, niż za szkolenia tradycyjne.

5.    Nowość – szkoleniowe gry symulacyjne w nauczaniu IT

Symulacyjne gry szkoleniowe powoli wchodzą także w nauczanie inżynierii oprogramowania, tej prawdziwej, a nie przemycanych pod tą nazwą kursów narzędzi, systemów operacyjnych czy języków programowania. Mają w sobie potencjał, by skutecznie odmienić krajobraz szkoleń IT. Dla zilustrowania, że metoda sprawdza się nawet w odniesieniu do zagadnień uważanych za techniczne, posłużę się przykładem z bliskiej memu sercu dziedziny testowania oprogramowania, a dokładniej – kwestii dotyczących automatyzacji wykonywania testów.

Od wielu lat szerzy się w tym obszarze mnóstwo nieporozumień, pogłębianych mylącymi próbami klasyfikacji typów narzędzi , oraz tym, że promocję nowych narzędzi o wiele skuteczniej prowadzić dziwacznymi nazwami („selen”, „sprawność”, „ogórek” – poznajecie :-) te narzędzia?) i gołosłownymi hasłami („zwinne narzędzia”, „intuicyjne narzędzia”), niż odwołaniem się do uciążliwej systematyki:
Na tych nieporozumieniach wszyscy tracimy wiele czasu i pieniędzy. Ze wstydem przyznam się, że wiele razu sam wpadłem w pułapkę mozolnego i namolnego opowiadania o systematyce narzędzi testowych, usypiając tym uczestników szkoleń. A jak to zrobić grą symulacyjną? Na ilustracji poniżej, stosowny fragment planszy do gry:


Rysunek 1. Fragment planszy do 3-dniowej symulacyjnej gry szkoleniowej „Testowanie oprogramowania”

Gra toczy się na specjalnej planszy, uczestnicy (zespoły) rzucają kolejno kostką i przesuwają swoje piony na wyznaczone liczbą oczek kostki pola. Jest wiele pól decyzyjnych – tam zespoły muszą podjąć decyzję, którą odnogę wybrać. Do wielu pól przywiązane są rozmaite wydarzenia, korzystne dla zespołu lub niekorzystne, czasem wymagające dodatkowej pracy, albo obliczeń, albo dalszych decyzji.

Kiedy uczestnik, lub zespół, rzucając kostką, dojdzie do pola „76”, musi podjąć decyzję „D14”: automatyzacja wykonywania testów, lub rezygnacja z niej. W tym miejscu może też pojawić się, zależnie od przewidzianej czasochłonności partii tego testowego brydża, praca w grupach, prezentacja stanowisk oraz mini-wykład dotyczący (1) innych opcji automatyzacji; (2) argumentów za i przeciw automatyzacji.

Wybrawszy rezygnację, zespół będzie prowadził swój pionek dalej trasą 77, 78…, na której oczywiście czeka wiele niespodzianek, natomiast wybrawszy automatyzację, zespół rusza polami 90, 91, 92… Kto ma pecha, i stanie pionkiem na polu 91, przeczyta: „analiza i porównywanie dostępnych na rynku narzędzi zajęła trzy osoby przez dwa tygodnie, tracisz kolejkę i cofasz się z powrotem na pole 76” :-). Ale pech!

Pole „93” wymusza podjęcie kolejnej decyzji, „D15”: czy będziemy tworzyć skrypty (programy) automatycznych testów metodą zarejestruj-odtwórz (dalszy kierunek 100, 101…), czy też sposobami bardziej zaawansowanymi (kierunek 94, 95…)? Na planszy droga w kierunku 100, 101… jest kusząco znacznie krótsza, niż kierunek alternatywny, ale najeżona pułapkami. Możecie się domyśleć, że zaraz za granicą tego kawałka planszy, może już na polu 102 albo 103, kryje się straszna bomba: „uruchomienie nagranych skryptów tylko siłami testerów akceptacyjnych okazało się zbyt trudne i czasochłonne: rezygnujesz z automatyzacji, wracasz na pole 75 i tracisz dwie kolejki na zmianę harmonogramu testów oraz szukanie winnych i kozła ofiarnego”.

Czytelnikom, nieobeznanym z tajnikami i dość szczególną terminologią automatycznych testów, powiem, że tę metodę można stosować do mnóstwa innych zagadnień: zmieniwszy tło planszy :-), można decyzję „D14” przedstawić na przykład jako wybór między opisem wymagań w języku naturalnym, a ich opisem w postaci diagramów wybranego modelu UML; wówczas decyzja „D15” może być miejscem trudnego wyboru między ręcznym rysowaniem takich modeli, a konstruowaniem ich przy pomocy narzędzia, i tak dalej.

Niezależnie od tematyki, kształtu i treści każdej gry, daje ona uczestnikom następujące korzyści:
  • Uczymy się podejmować decyzje w różnych sytuacjach i obszarach projektu;
  • Poznajemy w praktyce sposoby myślenia dla budowania najlepszej strategii;
  • Motywuje nas rywalizacyjna między zespołami, i walka z losem;
  • Spotykamy się z ryzykiem, prawdopodobieństwem i nieprzewidzianymi zmianami sytuacji, jak w życiu;
  • Dostajemy informację od trenera wtedy, gdy jest nam potrzebna, co wybitnie ułatwia zapamiętywanie;
  • Uczestnicy są bardzo zaangażowani, dobrze się bawią i nie męczą intensywną pracą.
  • Uczestnicy w naturalny, a nie wymuszony sposób, pracują i podejmują decyzje zespołowo, wymieniając się doświadczeniami z własnej praktyki zawodowej.
6.    Zapraszam do gry!

Opisy szkoleń, realizowanych metodą gry symulacyjnej, zaczniemy prezentować już wkrótce na victo.eu/uczenie.html, ale już dziś możemy dla Was stworzyć i zorganizować taką grę związaną z każdym z tematów naszych szkoleń, lub z innym tematem, zadanym przez Was: bogdan.bereza@victo.eu.

Dla CTS, prowadzę grę pt. "Wyprawa statkiem „Fram” – symulacja biznesowa Agile".

Ponadto, 20 listopada (czwartek) podczas kolejnego spotkania WarszawQA, o godzinie 18:00 w Warszawie, będę miał przyjemność zaprezentować kawałek takiej gry na temat testowania.

W dniach 26-27 listopada poprwadzę w tej formule warsztaty testowania w metodykach agile, dla IDG: computerworld.pl/warsztaty.