blog.testowka.pl

“Ludzie i interakcje ponad procedury i narzędzia” – łatwo powiedzieć – trudniej zrobić.

Pierwsza myśl, która pojawia się, gdy zostajemy managerami w firmie IT, w której panuje chaos:
- “Trzeba ten chaos posprzątać”
- no dobrze, ale jak?
- “Wprowadźmy procedury, które uporządkują chaotyczne procesy…”
To nie działa! – wiem, bo sprawdziłem. Procedury są fajne, ale…

Po wprowadzeniu procedury mającej usystematyzować proces wdrażania aplikacji na serwery produkcyjne, bardzo szybko okazuje się, że rzeczy tak oczywiste jak wydawanie tylko ze stabilnego brancha, czy w ogóle posiadanie czegoś takiego jak stabilny branch nie dla wszystkich są oczywiste, a skoro nie ma tego szczegółowo opisanego w procedurze to kto by się tym przejmował. Ponadto dosłownie od razu pojawia się spychologia typu: “MY zakodowaliśmy już swoje teraz ONI niech się martwią jak to wydać”.

Aby poradzić sobie z codzienną “bieżączką” wynikającą z nadmiaru zadań krytycznych do zrobienia “na już” wprowadzamy proste kryteria oceny krytyczności i nadawania priorytetu zgłoszonym ticketom. Po chwili okazuje się, że zapis w stylu: “Jeśli błąd powoduje znaczące straty finansowe to można nadać mu priorytet krytyczny” jest podstawą do wielu nadużyć i 80% zgłaszanych ticketów ma priorytet krytyczny, a autorzy powołują się na “znaczące” wg nich straty finansowe, chociaż nie są w stanie, czy też nie mogą podać żadnych kwot.

Narzędzia, które wprowadzamy w dobrej wierze, po to by uporządkować pewne elementy procesu bardzo szybko obracają się przeciwko nam. Wprowadzane procesy powodują zanik i rozproszenie odpowiedzialności za wykonywane zadania. Niby posiadanie procedury daje większy komfort pracownikom bo pozwala w każdym momencie się na tą procedurę powołać ale z drugiej strony okazuje się, że jej nadinterpretacja szybko zwalnia co niektórych z myślenia.

A gdyby tak spróbować usiąść razem z innymi i po prostu robić te wydania w sposób, który pozwoli na opanowanie chaosu, robić je wspólnie aż do momentu, gdy wszyscy nauczą się robić to dobrze, zrozumieją po co robić to dobrze, zrozumieją, że sami mogą mieć wpływ na to by robić to jeszcze lepiej…

A gdyby tak spróbować uświadomić zgłaszających tickety, po co te priorytety wprowadzamy i że jeśli sami nie dojdą do tego jak sortować zadania według priorytetu to wiele ważnych rzeczy po prostu umknie… A gdyby tak w ogóle zlikwidować priorytety i robić zadania według uznania…

Czasami wdrażając Agile zapominamy o podstawowych zasadach właśnie takich jak ta z manifestu mówiąca o ludziach i interakcjach. Czasami zdarza się, że tak bardzo jesteśmy zapracowani tworzeniem nowych procedur, pisaniem dokumentacji i samym wdrożeniem, że nie zauważamy, iż ludzie nie są gotowi na wymyślane przez nas procedury. Czasami, a nawet często bywa tak, że procedury są tylko łatą nalepioną na problemie, gdy źródło problemu jest zupełnie gdzie indziej – gdzieś głębiej, a zgodnie z Lean problemy należy rozwiązywać a nie szukać drogi na około, rozwiązywać poprzez eliminowanie przyczyny powstania problemu.

Coraz częściej zauważam wzrost aktywności wielu firm IT na rynku pracy. Zauważam także więcej ogłoszeń dla testerów i QAów. Pojawia się też coraz więcej firm zajmujących się rekrutacją pracowników dla IT. Powodów może być wiele – czasem jest to spowodowane dynamicznym rozwojem firmy, a czasem jak to zwykle w przypadku testerów bywa próbą ratowania zbugowanego systemu.

Oglądałem kiedyś ciekawą prezentację Ken’a Schwabera wprowadzającą do Scrum. Oprócz samej tematyki Scrum poruszony został tam jeden bardzo ciekawy problem – Ken przedstawił przykładowy (sprawdzający się w większości przypadków) cykl życia start-up’ów. Wygląda to mniej więcej tak:

Kilku pomysłowych gości wpada na świetną, rewolucyjną idee i rozpoczyna pracę w swoim garażu/pokoju w akademiku/wynajętym mieszkaniu etc. Po jakimś czasie pojawia się pierwsza wersja live oferowanego systemu/aplikacji która powoli zaczyna zarabiać – na początku walczymy o to by zwróciły się koszty. Po jakimś czasie, przeważnie w wyniku niesamowitego zbiegu okoliczności start-up staje się bardzo popularny i zaczyna nagle zarabiać coraz więcej pieniędzy, co powoduje że firma się rozwija i zatrudnia więcej pracowników, którzy jak najszybciej produkują coraz to nowsze ficzery by jeszcze bardziej powiększyć zyski. Przeważnie wszyscy będąc na tej fali ciągłego powiększania przychodów nie przejmują się jakością. Po pewnym czasie projekt dociera do punktu w którym dodanie nowego ficzera staje się droższe niż zyski z niego płynące, niemniej jednak są one cały czas dodawane z różnych powodów – często czysto marketingowych nieprzekładających się na wymierne korzyści materialne. Mija jeszcze trochę czasu, po którym ktoś nagle stwierdza, że przepisanie całej aplikacji od nowa zajmie mniej czasu niż dodanie nowego ficzera. W międzyczasie zarząd/właściciele firmy zaczynają się zastanawiać nad tym jak rozwiązać problem zbyt drogich ficzerów. Jednym z rozwiązań jest pozbycie się problemu poprzez sprzedanie go innym – na rynku jest wiele firm typu venture capital, które masowo skupują start-up’y, po to by niektóre z nich przekształcić w prężnie działające przedsiębiorstwa. Zdarza się też tak, że zarząd postanawia wreszcie przenieść nacisk z wyłącznie zarabiania na polepszanie jakości (czasem też na przepisanie systemu od zera). W obydwu tych przypadkach (nieważne czy firmę kupi ktoś nowy, kto będzie chciał polepszyć jakość, czy zarząd sam zdecyduje się to zrobić) potrzebne jest zapewnienie specjalistów. Właśnie wtedy firmy decydują się na zatrudnienie zespołu QAów, którzy ogarną cały ten bałagan i zaproponują rozwiązania problemów. Czasem jest już za późno, niemniej jednak, jeśli tylko nakład na jakość jest wystarczająco duży często udaje się to osiągnąć.

W życiu każdego testera przychodzi czas na zmiany… Czasem bywa tak, że jest to zmiana pracy… Jeśli taki czas nadszedł właśnie dla Ciebie to mam dla Ciebie świetną propozycję! Szukamy testerów/inżynierów testów/QAów do naszego zespołu we Wrocławiu.

Jeśli jesteś zainteresowany/zainteresowana możliwościami dalszego rozwoju w dziedzinie automatyzacji testów, testowania, szeroko rozumianego QA etc. to zapraszam do kontaktu (jeśli napiszecie, że dowiedzieliście się o ofercie pracy z mojego bloga macie +10 do charyzmy ) . Więcej informacji możecie znaleźć tutaj.

Szukamy też programistów PHP i Python.

Przeglądając ostatnio oferty pracy zauważyłem, że większość firm szuka QAów a nie testerów. Co jest grane? Czyżby nagle wszyscy zaczęli zapewniać jakość zamiast testować oprogramowanie? Było by cudownie… Niestety, jak przyglądam się bliżej tym ogłoszeniom, to jasne staje się, że owe firmy nie szukają Quality Asurance Engineer’ów tylko zwykłych testerów, w najlepszym wypadku inżynierów testów. Nadużywanie tytułu Quality Assurance Engineer albo Specialist prawdopodobnie wynika, z tego iż mało kto tak naprawdę wie co się pod tą nazwą kryje, jednocześnie wszyscy chcą być trendy i przyciągnąć większą uwagę potencjalnych kandydatów. Wcale się nie dziwię – samemu mi było trudno znaleźć wartościowe informacje na temat QA. Często te informacje są sprzeczne lub niekompletne.

Problematyczne może być także przetłumaczenie tego terminu z języka angielskiego na polski – próby typu “Inżynier Jakości”, “Inżynier Zapewniania Jakości” nie brzmią zbyt dobrze, dlatego osobiście wolę pozostać przy QA.

W takim razie czym jest Quality Assurance? Na pewno Quality Assurance nie jest tożsame z testowaniem oprogramowania. W najlepszym wypadku proces testowy może być zaliczany jako część procesu Quality Assurance. Głównym celem QA jest zapobieganie powstawaniu błędów, w przeciwieństwie do testowania oprogramowania, którego głównym zadaniem jest detekcja błędów – weryfikowanie jakości. QA wykorzystuje wiele narzędzi w celach prewencyjnych, między innymi zajmuje się organizacją i kontrolą procesu wytwarzania oprogramowania, buduje środowiska oraz narzędzia wspierające testowanie i kontrole jakości, poszukuje i wprowadza “dobre praktyki” by zwiększać efektywność i poprawiać jakość i dopiero jako jeden z wielu elementów pojawia się weryfikacja jakości produktu, która może zostać przeprowadzona poprzez testowanie oprogramowania.

Z pojęciem Quality Assurance związanych jest bardzo wiele innych niezmiernie istotnych terminów takich jak CMMI czy normy ISO. To właśnie zapewnienie osiągnięcia wspomnianych norm jest dosyć często głównym celem procesu QA.  Quality Assurance to także praca z ludźmi, zarządzanie wiedzą, organizacja pracy, doskonalenie umiejętności pracowników etc.

Powyżej starałem się wyjaśnić podstawowe różnice pomiędzy QA a testerami – jest to tylko moja własna interpretacja tego co znajduje się w encyklopediach, poradnikach, normach itp. niemniej jednak czytając różne artykuły, blogi etc. powyższa interpretacja coraz bardziej się weryfikuje i klaruje także postanowiłem się nią podzielić.

Jeśli ktoś ma inne zdanie na temat QA to zapraszam do dyskusji.

Tajemniczy tytuł Shu-Ha-Ri to zaczerpnięte z kultury japońskiej trzy poziomy doświadczenia, często używane w kontekście sztuk walki takich jak aikido. Piszę o tym, gdyż nauka sztuk walki ma zaskakująco wiele wspólnego z wdrażaniem metodologi w organizacji. Trzy poziomy doświadczenia, trzy poziomy wtajemniczenia wymuszają na uczniu stopniową, systematyczną naukę dzięki czemu eliminuje się większość błędów.

Shu – przyswojenie, zachowanie, pielęgnacja
Jest to pierwszy etap nauki, w której uczeń skupia się na opanowaniu podstawowych technik i zachowań. Termin ten oznacza także lojalność wobec jednego nauczyciela. Podczas tego etapu najważniejsze jest przyswajanie wszystkiego z największa dokładnością bez możliwości wprowadzania jakichkolwiek zmian. W tej fazie nieistotne są powody stosowania technik, najważniejsze jest opanowanie do perfekcji podstaw. (Przypomina mi się scena z “Karate Kid” w której dzieciak uczy się podstawowych ruchów myjąc samochody ). Nie wszyscy zdają sobie sprawę z tego jak ważne jest zbudowanie podstaw, by móc z powodzeniem dalej rozwijać swoje umiejętności. Na poziomie Shu okazuje się, że do osiągnięcia celu jakim jest efektywne wykorzystanie umiejętności wystarczająca jest jedna droga, stąd też wymóg lojalności do nauczyciela i posłuszeństwo. Ta stara zasada jasno pokazuje, że mieszanie różnych technik a w naszym przypadku metodologi wprowadza chaos i doprowadza do sytuacji, w której mamy dużo różnych umiejętności ale nie reprezentują one żadnej wartości praktycznej ani technicznej jako całość. Według tradycji to nauczyciel decyduje o tym kiedy uczeń może zakończyć ten etap i przejść na poziom Ha.

Ha – odłączenie, zerwanie z tradycją
Drugi etap nauki polega na uwolnieniu się do pewnego stopnia od klasycznych metod. W tej fazie ważne jest by odnaleźć i zrozumieć powody technik nauczonych na poprzednim etapie. Tutaj zaczyna się sztuka, odłączenie od codziennie powtarzanych czynności i stopniowe rozwijanie technik. Na tym etapie uczeń rozpoczyna własne eksperymenty, powinien być gotowy na to by samodzielnie analizować i myśleć nad powodami wykorzystywania niektórych technik po to by w przyszłości samodzielnie je rozwijać i dołączać nowe. Cała dostępna wiedza została zdobyta, teraz uczeń musi nabyć doświadczenia.

Ri – uwolnienie
Ostatni etap, w którym uczeń staje się mistrzem, uwalnia się od tradycji, przechodzi poza granice. Uczeń posiadający duże doświadczenie i wiedzę może je wykorzystywać w życiu codziennym. Na tym etapie uczeń już nie uczy się sztuki walki od innych tylko tworzy swój własny niepowtarzalny styl. Dopiero tutaj możliwe jest całkowite uwolnienie od standardów i podstaw. Tutaj uczeń/mistrz może pozwolić sobie na niekonwencjonalność, która dzięki zdobytej wcześniej wiedzy i doświadczeniu ma bardzo duże szanse na sukces.

Jak to wszystko ma się do wdrażania metodologii? Miałem nie do końca przyjemną okazję kilkukrotnego obserwowania prób wdrożenia metodologi/narzędzi (Scrum, Kanban) w różnych organizacjach, które zakończyło się porażką. Porażka ta według moich obserwacji wynikała między innymi z tego, że wdrażający zakładali, iż członkowie zespołu i oni sami są co najmniej na poziomie Ha, z tym że wielokrotnie brakowało im wiele do osiągnięcia Shu – nie znali, bądź nie potrafili stosować podstaw. Ponadto wdrożenia typu “weźmy planowanie ze Scrum, tablicę z Kanban ale nie stosujmy na niej limitów, do tego eliminujmy waste za pomocą narzędzi Lean i nazwijmy to wszystko Agile to może nam coś tego wyjdzie” ciężko jest nazwać wdrożeniem. Jak już pisałem w notce o automatycznym chaosie jeśli wdrażamy coś w organizacji to przede wszystkim musimy wiedzieć co wdrażamy i mieć jakiś, co najmniej ogólny plan wdrożenia. Pisałem też już kiedyś o teorii i jej zestawieniu z praktyką, moje doświadczenia jasno pokazują, że teorie sprawdzają się w przygniatającej większości przypadków jeśli tylko spełni się jeden zasadniczy warunek – postępuje się według jednej teorii od początku do końca.
Miałem okazję jakiś czas temu wspierać jeden mały zespół podczas wdrażania Scrum, postanowiłem zastosować zasadę Shu-Ha-Ri. Na początku pokazałem im wszystkie artefakty, pokazałem jak powinno wyglądać planowanie, jak rozbijać zadania, jak rozmawiać podczas spotkań typu stand-up oraz wyjaśniłem klientowi w jaki sposób opisywać wymagania. Po dwóch sprintach, podczas których na prawdę sumiennie starali się przestrzegać wszystkich zasad, praktycznie nie musiałem już tłumaczyć po co to wszystko było – sami dobrze wiedzieli co zyskali porównując sytuację obecną z poprzednimi projektami i z łatwością potrafili wskazać przyczyny stosowania takich a nie innych technik. Obecnie po trzech miesiącach zespół skutecznie wprowadza własne usprawnienia do stosowanej metodologi – starają się używać TDD, programują w parach, robią regularne przeglądy kodu. Wielce pomocne okazały się retrospekcje, które dosyć szybko definiowały problemy, a metoda systematycznego wprowadzania poprawek do procesu owocuje polepszeniem jakości pracy a także lepszą atmosferą i motywacją wynikającą każdorazowo z sukcesu jakim jest eliminacja błędów z procesu.

Po raz pierwszy o Shu-Ha-Ri przeczytałem w książce Alistera Cockburn’a “Agile Software Development – Gra Zespołowa”, którą polecam. Lektura zachęciła mnie do dalszego drążenia tematu, którego efektem jest ta notka

Zastanawiałem się ostatnio nad czynnikami, które wpływają na to, że jedne projekty kończą się sukcesem, a inne niestety porażką. Po analizie kilku przypadków doszedłem do wniosku, że jednym z ważnych czynników sukcesu jest odpowiednie motywowanie pracowników. Oczywiście nie jest to jedyny warunek, który trzeba spełnić, niemniej jednak warto zastanowić się co nas motywuje do pracy? Pierwsza odpowiedź jaka się nasuwa zdecydowanej większości pytanych to “pieniądze”. Ale czy na pewno? Z doświadczenia wiem, że pieniądze owszem motywują na początku kariery, zwłaszcza wtedy, gdy się tych pieniędzy nie miało, a tu nagle co miesiąc na konto spływają regularne całkiem pokaźne sumy. O takiej motywacji możemy mówić jedynie w kontekście pracowników niedoświadczonych, przeważnie młodych, zaczynających swe kariery. Co innego, gdy mamy do czynienia z pracownikami doświadczonymi, wysokiej klasy specjalistami czy też ekspertami. Specjalistów rzadko motywują pieniądze, a jeśli już to jest to motywacja krótkotrwała. Nie wiem jak w innych dziedzinach ale jeśli o IT chodzi to obecnie w Polsce specjaliści są bardzo poszukiwani i wiele firm jest w stanie zapłacić na prawdę duże pieniądze za ich usługi, tym samym dla pracodawców zwiększa się ryzyko tego, że ktoś podbierze (podkupi) ich najlepszych pracowników oferując wyższą pensję.

Co zatem zrobić? Jak inaczej niż za pomocą pieniędzy motywować pracowników?

Okazuje się, że wspomniani ’specjaliści’ pracują głównie po to by osiągać satysfakcję z wykonanej pracy. Jeśli pracownik jest dumny z wykonywanej pracy samoistnie przekłada się to na jego wysoką motywację, co skutkuje wysoką produktywnością. Zastanawiając się nad tym co sprawia, że jesteśmy dumni z wykonywanej pracy możemy dojść do trzech wniosków.

Możemy być dumni z produktu naszej pracy. Jeśli oprogramowanie, które wytwarzamy jest dobre, dobrze napisane, spełnia wszystkie wymogi jakościowe to możemy być dumni ze swojego dzieła. Jako anty-przykład podam system, który ogólnie rzecz biorąc działa, marketingowcy z powodzeniem sprzedają go klientom dzięki czemu firma zarabia, niemniej jednak jakość kodu i sposób jego wytwarzania są na tak niskim poziomie, że żaden programista nie chciałby tego systemu pokazywać w swoim portfolio wiedząc, że potencjalny pracodawca mógłby ten kod przejrzeć. W takiej sytuacji pracownik może powiedzieć: “OK, cieszę się że system działa, ale po powrocie do domu nie czuje satysfakcji z wykonywanej pracy – system jest ok, ale tak na prawdę to jeden wielki śmietnik owinięty ładnym papierkiem”.

Kolejny rodzaj dumy to duma z osiągnięć. Pracownicy odczuwają satysfakcje, gdy ich praca przyczynia się do osiągnięcia sukcesu – sukcesu firmy, sukcesu projektu, czy nawet samego wybicia się zespołu ponad szeregi innych pracowników. Żeby motywować pracowników za pomocą tej metody wystarczy definiowanie odpowiednio małych celów, których osiągnięcie w krótkim czasie oznacza sukces, który następnie powinien być celebrowany w odpowiedni sposób. Dobrym przykładem zastosowania takiego rodzaju motywacji może być nagradzanie i ciągłe powtarzanie zespołowi, który pracuje nad wytwarzaniem nowych funkcjonalności frontendowych, które są potem sprzedawane klientom, że to oni generują większość zysku w firmie, która zatrudnia także programistów backendowych nie mających bezpośredniego wpływu na zyski firmy.

Oprócz powyższych jest jeszcze jeden ważny aspekt motywowania pracowników. Pracownicy są dumni z uczestnictwa w czymś dużym. Człowiek jest istotą stadną, dlatego łączymy się w grupy, społeczeństwa etc. Podobnie jest w przypadku wykonywania pracy im bardziej pracownik czuje się częścią małej społeczności w zakładzie pracy tym bardziej wpływa to na jego motywację. Ponadto znaczący wpływ na motywacje ma świadomość skali tego co jest produkowane. Zupełnie inne podejście w tej kwestii ma pracownik firmy takiej jak Google, Microsoft czy Apple, który ma świadomość tego, że z produktów jego pracy korzystają codziennie miliony użytkowników, a zupełnie inaczej swój udział w przedsięwzięciu ocenia pracownik małej firmy tworzącej sklepy internetowe, które może w najlepszym wypadku dojdą do kilku tysięcy wejść dziennie. Sam udział w przełomowych projektach dużej skali bywa często wystarczająco motywujący by pracownicy wykonywali swoją pracę najlepiej jak to tylko możliwe.

Powyżej opisałem trzy podstawowe czynniki mające wpływ na motywację pracowników. Oczywiście takich zależności jest znacznie więcej, chociażby sama atmosfera pracy, szef, wygodne krzesło, troska firmy o pracownika, rzetelne kierownictwo, które dotrzymuje słowa, społeczne aspekty wykonywanej pracy itd.

W tym tygodniu miałem okazję prowadzić w Warszawie dwudniowe szkolenie “Narzędzia w procesie testowym” w ramach programu szkoleń SQAM. Motywem przewodnim wspomnianego szkolenia stało się hasło będące tytułem poniższej notki.

Automatyczny chaos to tylko szybszy chaos…

Jeśli mówimy o automatyzacji testów, zarządzania testami, zarządzania konfiguracją, procedur deploymentu, zarządzania incydentami wszystko to wiąże się z wdrażaniem narzędzi. WDRAŻANIE – bardzo ciekawy termin. Według słownika języka polskiego wyraz “wdrażać” oznacza “wprowadzać coś nowego do użytku”. Ale ta notka nie będzie o samym procesie wdrażania narzędzi testowych, lecz o tym kiedy w ogóle o wdrożeniu narzędzia możemy zacząć myśleć.

Żeby zacząć planować wdrożenie narzędzia wspierającego w jakikolwiek sposób testy czy inną część procesu wytwarzania oprogramowania musi najpierw ten proces zdefiniować. Musimy mieć usystematyzowane pewne procedury, jasno określone i opisane zależności, zdefiniowany workflow etc. Jeśli zaczniemy automatyzować chaos to tylko przyspieszymy nasz marsz ku klęsce. Owszem, niektóre narzędzia służą właśnie do powstrzymywania chaosu, do porządkowania różnych elementów procesu (głównie narzędzia wspomagające zarządzanie) , niemniej jednak zanim zaczniemy używać takiego narzędzia musimy dobrze poznać jego możliwości i zaplanować sposób w jaki będziemy go używać.Powyższe wcale nie jest proste, wymaga odpowiednich przygotowań i odpowiedniego planu. Później jak już rozpoczniemy używanie narzędzia, czy to od razu w całej firmie czy w ramach jakiegoś projektu pilotażowego nadal musimy pamiętać chociażby o zapewnieniu szkoleń i wsparcia dla innych użytkowników. W dodatku musimy pilnować by przypadkiem ktoś nie zaczął używać narzędzia niezgodnie z zamierzonym workflowem.

Osobiście nie lubię narzędzi, które obsługują więcej niż jedno zagadnienie – zgodnie ze starą reklamą proszku do prania:  ” Jeśli coś jest do wszystkiego to jest do niczego”. W narzędziach cenię sobie prostotę i użyteczność, nie chcę czytać kilku tomów instrukcji by nauczyć się zgłaszania błędów, nie chcę marnować kilkunastu dni na szukanie najbardziej optymalnego sposobu używania narzędzia wspierającego zarządzanie projektem. Potrzebuje gotowych kompleksowych rozwiązań.

Bardzo często narzędzia są wdrażane w momencie, gdy pojawiają się problemy, są wdrażane po to by ratować projekt coraz szybciej zmierzający w kierunku przepaści. Wdrażanie narzędzi na miesiąc przed deadlinem to najgorsze co można zrobić. Jest już za późno by narzędzie mogło nam w czymkolwiek pomóc a wręcz przeciwnie zmarnujemy dużo czasu na jego wdrożenie etc. Później czyta się raporty mówiące o tym, że tylko 60% wdrożeń narzędzi kończy się sukcesem.

Rozpoczęcie automatyzacji testów w trakcie trwania projektu a nie na jego początku także wiąże się ze znacznym ryzykiem. Przede wszystkim w takiej sytuacji gdy testy jednostkowe i funkcjonalne nie były pisane od początku istnieje duże prawdopodobieństwo, że niektórych funkcjonalności nie da się już przetestować automatycznie. Pomysłem na rozwiązanie problemu zbyt późnego rozpoczęcia automatyzacji mógłby być refaktoring, niestety refaktoring kodu bez co najmniej 90% pokrycia kodu testami ma bardzo małe szanse powodzenia.

Błędne koło się zamyka. Nie twierdzę, że nie da się wprowadzić narzędzia do już trwającego projektu. Niemniej jednak by to zrobić, trzeba najpierw ogarnąć chaos bez narzędzi, lub przynajmniej mieć konkretny plan jak to zrobić z pomocą narzędzi.

Ostatnio na jednym ze śledzonych przeze mnie blogów pojawiła się świetna historyjka o smażeniu ryby, postaram się ją tutaj przetłumaczyć.

“Pewnego razu pewna mała dziewczynka, przyglądała się swojej mamie, gdy ta przygotowywała rybę do smażenia. Mama obcięła rybie ogon i głowę po czym położyła ją na patelni. Mała dziewczynka zapytała ją czemu tak właściwie obcięła rybie ogon i głowę. Mama zastanowiła się po czym odpowiedziała: w sumie to nie wiem, ale tak zawsze robiła twoja babcia a moja mama więc i ja tak robię. Mała dziewczynka była bardzo dociekliwa wiec postanowiła spytać się babci, która odpowiedziała: robię tak gdyż moja mama też tak robiła, więc tak też nauczyłam twoją mamę. Dla małej dziewczynki ta odpowiedź również nie była wystarczająca, wiec udała się do swojej prababci, ta zapytana o to dlaczego ucina rybie głowę i ogon przed położeniem jej na patelni odpowiedziała, że pamięta iż jej babcia robiła tak tłumacząc że mają zbyt małą patelnie by zmieściła się na niej cała ryba”

A Wam jak często udaje się odkrywać, że niektóre z Waszych przyzwyczajeń wynikają z tego, że kiedyś patelnie były mniejsze? Mnie dosyć często zdarza się odkrywać w projektach pewne zaszłości wynikające z “martwych” wymagań, które już dawno zostały zmienione. Ponadto języki programowania oraz technologie rozwijają się bardzo szybko i coś co kiedyś było niemożliwe nagle staje się banalnie proste, czasem wystarczy “tylko” trzymać rękę na pulsie by docenić i wykorzystać najnowsze rozwiązania.

W zespołach w których pracowałem/pracuję nierzadko spotykałem się (zwłaszcza, gdy w projekcie pojawiał się ktoś nowy) z sytuacją, w której pomysły “świeżej” osoby były dyskredytowane przez “weteranów” słowami: Tak, kiedyś już ktoś z nas próbował rozwiązać ten problem inaczej, ale to rozwiązanie, które teraz mamy jest najlepsze z możliwych. Moim zdaniem nie można stwierdzić nic bardziej błędnego – w tym przypadku zastosowane rozwiązanie było najlepszym z dostępnych wówczas rozwiązań. Do tego dochodzą jeszcze ograniczenia wynikające chociażby z niepełnej/innej wiedzy rozwiązujących problem. Z doświadczenia wiem, że “nowi” w projektach potrafią bardzo często dostarczyć wręcz oczywiste, proste rozwiązania, których nikt wcześniej nie potrafił dostrzec. Często wynika to z braku zaciemnienia obrazu (całokształtu projektu) przez szczegóły i informacje o ograniczeniach. Wspomnę jeszcze o testerach, którzy wchodząc do projektu po raz pierwszy znajdują w nim najwięcej błędów (zwłaszcza, gdy każe się im samemu eksplorować aplikację w celu jej dogłębnego poznania przed właściwym wykonywaniem scenariuszy testowych – tą metodę sam staram się stosować, czy to wchodząc do nowego projektu, czy też wdrażając kogoś nowego – praktycznie zawsze przynosi niesamowite efekty).

Kiedyś natrafiłem na stwierdzenie że nierozwiązywalne problemy mogą być rozwiązane tylko przez tych, którzy nie wiedzą o tym, że dany problem nie ma rozwiązania – w pełni zgadzam się z autorem i w praktyce kilka razy zdarzyło mi się zaobserwować ten fenomen.

Albert Einstein – znany wszystkim fizyk teoretyczny opracował swoje najważniejsze teorie nie przeprowadzając żadnego doświadczenia fizycznego. Właśnie dlatego, że w swoim rozumowaniu nie nawiązywał do “starej” fizyki Newtonowskiej, która była wynikiem wielu doświadczeń mógł z powodzeniem wymyślić coś zupełnie nowego, co dało początek chociażby dzisiejszym powszechnym zastosowaniom energii atomowej. Warto też wspomnieć, że pod koniec XIX wieku – tuż przed Einsteinem wśród fizyków powszechnie uważano, że w tej dziedzinie nauki już na prawdę niewiele zostało do odkrycia.

Wracając do smażonej ryby niestety czasem jest zbyt wiele ograniczeń pozwalających nam na zwiększenie patelni, więc jak powiedział jeden z moich kolegów z pracy: czasem trzeba poprzestać na łowieniu mniejszych ryb.

Historia o smażonej rybie kojarzy mi się  z moimi ostatnimi przemyśleniami i poszukiwaniami dotyczącymi myślenia lateralnego. Obiecuję wkrótce podzielić się wiedzą, którą zdobywam w tym temacie.

Oryginalny wpis z powyższą historyjką znajdziecie tutaj.

Poniedziałek 6.30 – dzwoni budzik – o 7.00 musisz być w pracy, za Tobą ciężki weekend (bo przecież kiedyś trzeba odreagować codzienne nierzadko nudne siedzenie po osiem godzin w pracy przy komputerze, do tego stres wywołany krytycznością wykonywanych zadań oraz napiętym – wręcz niewykonalnym harmonogramem). Pierwsza myśl po otwarciu oczu:  “byle do piątku”. I tak codziennie rano. Ta sama monotonia – sen, praca, dom, sen, praca, dom, sen, praca… A wszystko przez to, że ktoś kiedyś wymyślił, że etat ma mieć 8 godzin. 8 GODZIN! Osiem godzin to przecież 1/3 doby, to 30% naszego życia.

Kilka miesięcy temu miałem rozmowę o pracę w jednej z największych w Krakowie firm/korporacji zajmującą się wytwarzaniem oprogramowania. Rozmowy tej nie przeszedłem (pomijając oficjalną wersję) między innymi dlatego, że wdałem się ze swoim niedoszłym przełożonym w polemikę na temat czasu pracy. Otóż według mnie żaden programista/analityk a tym bardziej tester nie jest w stanie pracować efektywnie przez 8 godzin dziennie pięć dni w tygodniu. Praca na ośmiogodzinnym etacie z pewnością sprawdza się na kasie w supermarkecie, albo przy lżejszych pracach fizycznych, ale na pewno nie podczas pracy w której wymagane jest ciągłe skupienie i wytężone myślenie. Z doświadczenia wiem, że po 6 godzinach wytężonej pracy moja efektywność znacznie spada, co na moim stanowisku (QA/Tester) podczas pracy nad jakością i bezbłędnością czasem krytycznych systemów może oznaczać dla firmy poważne straty, jeśli z powodu zmęczenia jakaś krytyczna usterka przemknie się przez testy i pojawi się na produkcji. Nie wspomnę już nawet o głupotach które zdarzyło mi się robić z przemęczenia (np. ostatnie skasowanie całej zawartości katalogu domowego na jednej z testowych maszyn – na szczęście udało się to w miarę szybko przywrócić, ale mogło być gorzej). Z drugiej strony zdarza mi się przesiadywać w biurze nad rozwiązaniem jakiegoś frapującego problemu/zagadnienia czasem nawet po 12-14 godzin niemniej jednak po takim wysiłku potrzebuję porządnego wypoczynku by wrócić z powrotem na wysokie obroty i znów pracować na 100% swojej efektywności. Nie wiem czy Wy też tak macie, nie chce mi się nawet szukać jakiś badań naukowych czy naukawych dotyczących tego zagadnienia, po prostu obserwując siebie wiem że narzucony czas pracy nie sprawdza się w IT. Tutaj ważna jest skuteczność i bezbłędność dlatego nie rozumiem idei normowanego czasu pracy.

Drążąc głębiej ten temat mógłbym dojść do stwierdzenia, że nie rozumiem tego jak ten świat jest zbudowany – bo przecież ludzie powinni sobie ufać i na podstawie tego zaufania budować pewne zależności i podejmować się pewnych zobowiązań. Niestety powyższe dotyczy świata idealnego. Jak jest w rzeczywistości – każdy sam dobrze wie. Powyższe podejście zupełnie nienormowanego czasu pracy mogło by mieć zastosowanie tylko i wyłącznie, gdy mieli byśmy do czynienia ze Specjalistami (przez wielkie “S”) w pełni świadomymi wartości tego co robią i w pełni za to odpowiedzialnymi. Niestety kolejny raz już nie tylko tzw. “rynek IT” psują tzw. “studenci informatyki”, którzy za stosunkowo niskie pieniądze oferują usługi o bardzo niskiej jakości…

PS:  Bez obrazy dla Studentów Informatyki (Wielkie “S” “I”) bo są i tacy, którzy znają się na programowaniu znacznie lepiej niż niejeden programista.

PPS: W tytule nieprzypadkowo fragment piosenki Kumka Olik “Zaspane poniedziałki”.

Jako, że dawno nie było żadnej notki pora na małe wyjaśnienia i usprawiedliwienia.

Po długiej przerwie spowodowanej nawałem obowiązków związanych z… uwaga… zmianą pracy… Tester powraca!

Powraca jako oficjalnie Quality Assurance Engineer (tak mam na umowie ) w iLoop mobile Inc.

A’propos  umowy to tym razem umowa o pracę – ma to swoje zalety ale jak dla mnie niestety znacznie więcej wad:

• normowany czas pracy – etat,
• złodziejskie stawki na ZUS, opiekę medyczna, podatki etc.
• problemy z urlopami,
• karta obowiązków na danym stanowisku – za robienie czegoś ponad to nikt mi nie zapłaci dodatkowo,
• ograniczone możliwości mobilności na rynku pracy,
• ograniczenia lojalnościowe,
• klauzule tajności.

Ale dość narzekania! Głównym powodem zmiany pracy były pieniądze, po prostu dostałem ofertę nie do odrzucenia i tyle  (pomijam fakt że teraz odczuwalna część swojej pensji oddaje państwu), nawiązując do wątku na forum.testerzy.pl okazuje się, że nawet w naszym kraju jako już nie tester ale na stanowisku obejmującym trochę więcej obowiązków i wymagającym znacznie większej wiedzy i umiejętności, lecz nadal mocno związanym z testowaniem można zarabiać całkiem fajne pieniądze pracując na etacie.

Właśnie “na etacie” – ostatnio zainteresowałem się rynkiem freelancerskim w naszym kraju i nie tylko. Miałem także okazję wymienić na ten temat kilka maili z bardziej doświadczonymi w tym zakresie ludźmi i ogólnie jeśli o testowanie chodzi to nie jest lekko. Nie tylko u nas ale i na świecie. Generalnie rynek w tym zakresie jest zalany przez tania (i na prawdę stosunkowo dobrą) siłę roboczą z Indii i podobnych krajów. Poza tym projekty freelancerskie to przeważnie projekty, które nie wymagaja stałego zespołu a także ich wielkość pozwala na prowadzenie ich bez etatowych testerów. Co innego jeśli chodzi o usługi doradcze – tutaj na szczęście jest jeszcze trochę miejsca i miałem okazję ostatnio dorobienia jako doradca i wdrożeniowiec procesów testowych w kilku projektach.

Nadal aktualna jest moja współpraca z Code Sprinters w temacie szkoleń i doradztwa z zakresu Agile. W przygotowaniu też e-seminarium w ramach Polskiej Grupy Scrum ponownie dotyczace środowiska testowego dla zespołu Agilowego, tym razem wszystko powinno zadziałać .

Jeśli o bloga chodzi to obiecuje poprawę. Jest kilka zakiszonych notek które może wreszcie uda się opublikować. Jest także kilka tematów które chciałbym poruszyć.

I oto nadeszła ta wiekopomna chwila – nasze (Code Sprinters) autorskie narzędzie do zarządzania projektami w metodyce Scrum – Banana Scrum deczekało się wersji 2.0!

Banana Scrum to narzędzie w pełni przystosowane do wymogów Scrum. Aplikacja ta jest idealnym narzędziem nie tylko dla doświadczonych zespołów scrumowych ale także dla tych początkujących. Przejrzystość oraz nazewnictwo zgodne nomenklaturą Scrum pozwalają bardzo szybko poprzez praktykę przyswoić podstawowe zasady Scrum. Oprócz podstawowych funkcjonalności jak Pruduct Backlog, Sprint Backlog, Sprint Planning posiada ono także kilka innych bardzo przydatnych ficzerów jak na przykład Timeline View – ekran, który pozwala w bardzo przystępny sposób zobrazować dotychczasowy przebieg prac nad projektem, a także rozplanować w czasie przyszłe zadania. Do tego wszystkiego za jeden z killer ficzerów można śmiało uznać synchronizacje działań użytkowników w czasie rzeczywistym – zmiany przez nich dokonywane są od razu widoczne na ekranach pozostałych użytkowników – jest to niezwykle przydatne podczas pracy w rozproszonych zespołach.

Jako współtwórca tego narzędzi i pasjonat zwinnych metodologii muszę nieskromnie stwierdzić, że wykonaliśmy kawał dobrej roboty

Co tu dużo pisać – zapraszam do przeglądania wersji demonstracyjnej: demo.bananascrum.com.

W Scrumie istnieją trzy podstawowe role: Członek Zespołu (Team Member), Właściciel Produktu (Product Owner) i Mistrz Scruma (Scrum Master). To właśnie rola tego ostatniego jest najczęściej uważana za najistotniejszą (szczerze nie jestem do końca przekonany czy słusznie).

Należało by się zastanowić czym taki Scrum Master powinien się zajmować. Według mnie taka osoba ma dwa podstawowe zadania:

1. Dbanie o przestrzeganie zasad ustalonych przez zespół.
2. Wsparcie prac zespołu i zapewnienie mu odpowiednich warunków do pracy.

W nawiązaniu do pierwszego podpunktu trzeba pamiętać o kilku podstawowych zasadach narzucanych przez Scruma samego w sobie, po pierwsze zespół jest samo-organizujący się. To zespół ustala zasady, jakie zamierza stosować. Scrum Master nie może narzucać swoich zasad, co najwyżej może proponować na podstawie obserwacji pewne udoskonalenia lub zmiany, ale musi się to spotkać z aprobatą reszty zespołu by można było je wdrożyć. Właśnie tutaj Mistrz Scruma musi wykazać się nie lada zdolnościami interpersonalnymi by zachowując odpowiedni dystansł wymóc na zespole stosowanie przyjętych zasad. Ponadto Scrum Master jest strażnikiem samego procesu co zobowiązuje go do nadzorowania poprawnego przestrzegania praktyk Scrumowych. W tym celu można wykorzystać Scrum Check Listę (o której może innym razem). Dobrym pomysłem jest codzienne sprawdzanie czy wszystko idzie zgodnie z planem by móc jak najwcześniej zareagować na ewentualne problemy i odstępstwa od normy.

Drugi podpunkt porusza problem znacznie trudniejszy do zdefiniowania, gdyż pojęć wsparcia zespołu i zapewnienia odpowiednich warunków nie da się odpowiednio sprecyzować. Co do wspomnianych warunków przypomina mi się pewna historia opowiedziana przez kolegę, który opowiadał o tym jak bezcenny jest widok dwóch managerów przepychających muszlę klozetową . Jest to dość skrajny przykład, niemniej jednak można by to zaliczyć do zapewniania odpowiednich warunków pracy. Bardziej realnym problemem którego rozwiązania powinien podejmować się Scrum Master jest załatwianie dostępu do odpowiednich informacji i pilnowanie klientów by nie mieszali się zbytnio w proces. Rolą Mistrza jest także wyjaśnianie wszelkich niejasności wynikających z niedoprecyzowania wymagań, a także rozwiązywanie konfliktów w zespole dotyczących np. sposobu implementacji danej funkcjonalności.

Ponadto oprócz dwóch powyższych podpunktów Mistrz Scruma powinien także potrafić obserwować zespół i jego reakcję po to by wyciągać trafne wnioski pozwalające na usprawnienie procesu i lepsze wsparcie. Ważne na przykład jest to by Scrum Master potrafił skutecznie motywować swoich współpracowników, by wiedział jakie są ich ambicję i by w miarę możliwości pozwalał im się spełniać w tym co chcą robić.

Z powyższego wynika, że nie każdy może być Scrum Masterem, a już na pewnie nie każdy może być “Dobrym Mistrzem Scruma”. By to osiągnąć trzeba umieć obserwować ludzi, ich zachowania, współprace, zależności etc. Ponadto warto posiadać podstawową wiedzę psychologiczną i socjologiczną. Warto też mieć odrobinę pojęcia na temat różnych innych metodologi zarządzania, niekoniecznie zwinnego, by móc także z nich czerpać pewne pomysły i udoskonalenia. Scrum jest na tyle elastyczny, że pozwala na pewną ewolucję. Każdy zespół może interpretować Scruma na swój sposób i za każdym razem może to być poprawne i prowadzić do sukcesów, ważne by przestrzegać podstawowych zasad. Mistrz Scruma powinien także brać czynny udział w procesie ewolucji i udoskonalania a także przestrzegać by mieścił się on w odpowiednich, bezpiecznych granicach.

Na zakończenie dodam, iż jest to wyłącznie moja subiektywna opinia i interpretacja roli Scrum Mastera w zespole powstała na bazie obserwacji i doświadczeń. W pewnym stopniu pokrywa sie to z teorią Scruma ale chyba raczej nie do końca.

Dawno, dawno temu ktoś próbował mnie usilnie przekonywać, że w ogólnym pojęciu teoria jest jedynie teorią i w praktyce sprawdza się bardzo, na prawdę bardzo rzadko. Po latach własnych życiowych i zawodowych doświadczeń odkryłem, iż teoria to nie taka głupia sprawa. Ostatecznie ktoś te teorie z jakiegoś powodu wymyślił, ktoś zanim je opublikował dokładnie wszystko sprawdził, a jeśli teoria jest popularna to oznacza to, że wielu innym udało się ją z powodzeniem wdrożyć w życie.

Ostatnio postanowiłem lepiej przyjrzeć się Scrumowi. Także w tym przypadku sprawdzają się moje wcześniejsze spostrzeżenia – jeśli chodzi o zastosowanie teorii w praktyce to aby w ogóle było to możliwe podstawowym warunkiem jest stosowanie tej teorii od początku do końca. W efektywnym wykorzystywaniu metodologii nie ma miejsca na odstępstwa od zasad. Ktoś kiedyś te zasady dokładnie opracował i przeważnie wynikają one z wielu prób i błędów. Jeśli oczywiście mamy czas i środki na to by powtarzać czyjeś błędy to czemu nie – jak najbardziej powinniśmy eksperymentować, gdyż eksperymenty to najkrótsza droga do udoskonaleń, lecz jeśli chcemy w szybki i sprawny sposób tworzyć produkty o wysokiej jakości to nie ma mowy o eksperymentowaniu. W takich przypadkach najlepiej sprawdzają się rozwiązania wypróbowane już wcześniej przez innych. Stosując daną metodologię od początku do końca zgodnie z jej wszystkimi zasadami mamy prawie stó-procentową pewność, że jeśli coś idzie nie tak jak powinno to nie jest to wina metodologii lecz jakiegoś innego czynnika – np. źle dobrany zespół, nieodpowiednia technologia.

Niestety w życiu bywa różnie, a problem pojawiają się zawsze. Bez względu na to jak mocno trzymamy się ustalonych zasad i jak dobry mamy zespół, w końcu coś pójdzie nie tak jak powinno. Nawet drobne, z początku niedostrzegalne odstępstwa od normy w dłuższym okresie czasu spiętrzają się i nawarstwiają. Na szczęście Scrum dostarcza nam odpowiednich narzędzi do walki z tym zjawiskiem – najbardziej przydatnym jest retrospekcja. W agile zmienność wymagań, założeń, środowisk etc. jest czymś zupełnie normalnym, tak samo jak problemy z niej wynikające, dlatego też w zwinnym zarządzaniu projektami należy walczyć z problemami jak najwcześniej – gdy tylko zostaną zauważone. Właśnie do wczesnego wykrywania problemów służy retrospekcja.

W retrospekcji uczestniczy cały zespół, który na osi czasu (trwania ostatniego sprintu lub kilku sprintów) zaznacza wszystko to co było lub mogło być istotne i mieć wpływ na przebieg sprintu. Jest to pewna odmiana burzy mózgów, podczas której jak sama nazwa wskazuje wyciąga się wnioski z tego co wydarzyło się w przeszłości. Ważne jest to, by wskazywać nie tylko negatywne rzeczy ale także to co było pozytywne, daje to lepszy pogląd na sytuację w zespole i pozwala na opracowanie lepszych sposobów organizacji zasobów czy motywowania. Z założenia zespół w Scrumie jest samo organizujący się i właśnie dzięki temu podczas retrospekcji jego członkowie sami dochodzą do problemów które napotkali podczas realizacji projektu, a także sami dochodzą do tego jak te problemy rozwiązać i co zrobić by nie powtarzać tych samych błędów w przyszłości. Oczywiście samo przeprowadzenie retrospekcji to nie wszystko, ważne jest by wnioski z niej wyciągnięte zostały utrwalone.

Czasem bywa tak, że wniosków jest bardzo dużo a co za tym idzie potencjalnych usprawnień procesu jest jeszcze więcej. Niestety przeważnie próba poprawienia wszystkiego “na jeden raz” ma małe szanse powodzenia. Rozwiązaniem tego problemu jest odpowiednie kategoryzowanie problemów na te poważne i mniej istotne, można to zrobić np. przy pomocy głosowania, gdzie każdy uczestnik ma do dyspozycji kilka głosów (ich liczba powinna odzwierciedlać ilość problemów, które chcemy w najbliższym czasie rozwiązać). Przy pomocy głosowania ustalamy priorytety.

Po wprowadzeniu poprawek w kolejnym sprincie warto przeprowadzić kolejną retrospekcje by sprawdzić na ile udało się poprawić proces, oraz by ustalić nowe priorytety pozostałych problemów.

Reasumując retrospekcja to narzędzie, które jeśli zostanie wykorzystane w odpowiedni sposób daje nam wiele możliwości i informacji na temat tego jak wygląda praca w naszym zespole. Można by pokusić się o jakąś głębszą psychologiczną analizę tego narzędzia i korzyści z niego płynących, lecz wydaje mi się to nie potrzebne.

Po szampańskiej zabawie sylwestrowej przyszedł czas na chwilę refleksji nad minionym rokiem. Dla mnie był to rok dużych zmian i sukcesów.

Rok 2009 rozpoczął się rozczarowaniem zawodowym, które spowodowane było zderzeniem mojej osoby z pseudokorporacyjną ścianą biurokracji, która dość skutecznie blokowała, albo przynajmniej spowalniała moje możliwości rozwoju zawodowego. Powyższa sytuacja spowodowała drastyczną decyzję o zmianę pracy.

Tutaj pojawia się pierwszy sukces – bardzo szybkie (całkowity proces rekrutacji – od wysłania CV do zatrudnienia trwał tylko 2 dni) nawiązanie współpracy z Code Sprinters. Tutaj poznałem świetnych ludzi, którzy bardzo skutecznie motywowali i nadal motywują mnie do dalszego rozwoju i zdobywania wiedzy oraz umiejętności.

Jeśli mowa o sukcesach, to warto nadmienić, że znaczną ich część jeśli chodzi o moją osobę można zaliczyć do sukcesów firmy w której pracuję (albo na odwrót). Może się to wydać trochę dziwne, ale są jeszcze tacy pracodawcy, którzy potrafią stworzyć atmosferę, która sprzyja utożsamianiu się pracowników z firmą, w której pracują. I oto właśnie pierwsza lekcja z minionego roku – bardzo ważne jest aby wszystko to co robisz sprawiało Ci radość, by możliwe było utożsamianie się z tym oraz byś zawsze czerpał z tego satysfakcję. Bardzo ważne w tym wszystkim jest wsparcie innych.

Z nową pracą i związanym z nią natłokiem przemyśleń i wniosków związane było także powstanie tegoż bloga, na którym staram się dzielić z Wami wszystkim tym co sobie uroję. Jeśli oczywiście pozwala mi na to czas.

Kolejną lekcją ubiegłego roku była nauka bezpośredniej współpracy z klientami, którzy nie zawsze są idealni. Powyższe zmotywowało mnie do rozwoju swoich umiejętności interpersonalnych – zainteresowanie retoryką, NLP oraz psychologią.

Moje wcześniejsze zainteresowanie zwinnymi metodami zarządzania projektami sprawiło, iż w Sprintersach poczułem się jak ryba w wodzie. Miałem tutaj możliwość poznania od kuchni Scruma (jak jakiś czas temu stwierdziła moja znajoma jeśli chodzi o Scrum to w Krakowie nie mogłem lepiej trafić niż do CS) oraz XP. Współpracę z Adamem, z którym wdrażaliśmy dobre praktyki związane z nadzorowaniem jakości projektów (automatyzacja, testy regresyjne) oraz wplątanie tego wszystkiego w Scruma uważam za niesamowicie owocną, a jej efekty mogę śmiało uznać za kolejny sukces. Nauczyłem się wiele o procesach testowych, ale jeszcze wiele nauki przede mną.

W międzyczasie odbyła się Sesja Kół Naukowych AGH, na której mój referat o usability został nagrodzony wyróżnieniem. To taki mały osobisty sukces, który można uznać nawet za naukowy – streszczenie referatu doczekało się publikacji.

Później były już chyba wakacje, które spędziłem w pracy i uważam ten okres za bardzo męczący. Zarówno psychicznie jak i fizycznie nie czułem się dobrze. Wniosek, który wtedy mi się nasunął może dla niektórych wydać się oczywisty, lecz dla mnie wtedy taki nie był – należy zawsze zachowywać równowagę pomiędzy życiem zawodowym a osobistym. Uwierzcie nie jest to łatwe. Po wakacjach postanowiłem spróbować naprawić zerwane kontakty ze znajomymi i z satysfakcja stwierdzam, że do końca roku w dużym stopniu się to udało.

Po wakacjach miałem okazję “na boku” uczestniczyć w kilku projektach jako ekspert od użyteczności. Owe projekty już niedługo ujrzą światło dzienne i z pewnością wtedy się nimi pochwalę. Przez cały rok, niestety tylko w mitycznych “wolnych chwilach” trwały prace nad narzędziem do zarządzania testami. Niestety w miarę rozwoju moich umiejętności programistycznych kolejne wersje trafiały do kosza i status na chwilę obecną jest taki, że pozostał sam pomysł i zaimplementowanych kilka podstawowych funkcjonalności.

Co do projektów i pracy nad nimi nauczyłem się także, że nie zawsze najważniejsza jest jakość – czasem dysponujemy ograniczonymi środkami i wtedy musimy znaleźć najbardziej optymalne rozwiązania, niekoniecznie te najlepsze, które mogą się okazać zbyt pracochłonne. Niektóre projekty pomimo tego, że są świetne pozostają tylko projektami i nigdy nie ujrzą światła dziennego. Czasem warto jest wydać projekt średniej klasy, tylko dlatego by najlepszego projektu nie wyrzucić do kosza.

Należało by także wspomnieć o tym, iż udało mi się wrócić na studia, ale co z tego będzie to się dopiero okaże.

Podsumowując rok 2009 był dla mnie rokiem ciężkiej pracy i nauki. Poznałem wiele wspaniałych osób – począwszy od kolegów z pracy, poprzez ciekawe osoby związane z branżą IT, skończywszy na rozmowach z autorytetami w kilku ciekawych dziedzinach takich jak kognitywistyka czy psychologia.

Pozostaje mi tylko życzyć sobie oraz wszystkim Czytelnikom kolejnego owocnego roku, oraz samych sukcesów. Do Siego Roku 2010!

Dużo się mówi i pisze ostatnio o nieuczciwych praktykach Microsoftu, a mianowicie o monopolistycznym podejściu do przeglądarek internetowych instalowanych wraz z Windowsami. Niby wywalczono już jakieś ustępstwa ze strony Microsoftu, które mówią o tym, że podczas instalacji Windowsa będzie możliwość wyboru przeglądarki internetowej. Niemniej jednak natrafiłem ostatnio na bardzo istotny problem związany z Internet Explorerem, otóż zaczęło się od tego, że potrzebowałem zainstalować na komputerze starszą wersję Internet Explorera (zainstalowany był IE8). Niestety okazało się, że nie jest to tak trywialne jak mogło by się wydawać. Pierwsza próba ściagnięcia i odpalenia instalatora IE6 skończyła się komunikatem “Nowsza wersja Internet Explorer jest już zainstalowana na tym komputerze”. Z ciekawości spróbowałem jeszcze zainstalować IE7, niestety z takim samym skutkiem. Ponieważ potrzeba posiadania IE6 zainstalowanego na moim Windowsie XP była dość paląca nie mogłem się tak łatwo poddać, więc zgodnie z powiedzeniem “potrzeba matką wynalazku” postanowiłem usunąć najnowszą wersje IE i zainstalować starszą. Wszystko było by ok, gdyby nie jeden szczegół – pełne odinstalowanie Internet Explorera z Windows XP jest niemożliwe. Próbowałem chyba wszystkiego – począwszy od odnistalowania IE za pomocą Menagera Aplikacji, skończywszy na ręcznej próbie usunięcia katalogu z Internet Explorerem z dysku (nawet w trybie awaryjnym jest to niemożliwe). Próbowałem także wyłączyc wszystkie procesy, które mogły by blokowac usunięcie plików IE, niestety nie udało się. Koljnym krokiem było wygooglowanie rozwiązania, które skończyło się odnalezieniem informacji o tym, iż IE można jedynie wyłączyć w Systemie Operacjnym, ale nie ma możliwości jego odinstalowania, gdyż jest on nieodłącznym składnikiem systemu, który jest wykorzystywany między innymi przez usługę Live Update. Po wyłączeniu IE nadal nie było możliwości zainstalowania starszej wersji – ten sam komunikat.

Niestety Microsoft nie pozwala nam na zrobienie kroku wstecz i cofnięcie się do starszej wersji Internet Explorera. Pozostaje tylko jedno rozwiazanie – zainstalować aplikację Multiple IE, która pozwala nam na korzystanie ze starszych wesji IE.

Ostatnio miałem okazje uczestniczyć w konferencji PyConPl’09 poświęconej programowaniu w pythonie (i nie tylko). Konferencja odbyła się w ośrodku wczasowym “Gwarek” w  malowniczym Ustroniu. Kto był ten wie jak było, a kogo nie było niech czyta i zazdrości .

Pokuszę się o  krótkie streszczenie tego co według Testera było ciekawe.

Piątek 16 X 2009:
Niesamowicie ciekawy wykład Wesley’a Chuna o referencjach i modelach pamięci w pythonie. Podczas tego wykładu wreszcie udało mi się w pełni (mam nadzieję) zrozumieć idee alokacji pamięci nie tylko podczas programowania w Pythonie. Poza tym na uwagę zasłużyło stwierdzenie Wesley’a – “Wy jesteście młodzi i to do Was należy przyszłość świata”, miało ono sens ponieważ zostało poparte niewątpliwym przykładem w osobie samego Wesley’a który te słowa usłyszał kilka/kilkanaście lat temu od jednego ze swoich nauczycieli i teraz polata jak spojrzał wstecz i podsumował to co udało mu się osiągnąć (kilka książek o Pythonie, wykłady, prelekcje, szkolenia) to faktycznie wniósł jakiś wkład w przyszłość świata.

Sobota 17 X 2009:
Dzień zaczął się od warsztatów Pair Programing i TDD prowadzonych przez Konrada Delaga i Krzysztofa Goja, o ile do Pair Programing (patrząc z boku) jestem dość sceptycznie nastawiony o tyle TDD uważam za podstawę prowadzenia projektów agileowych. Niemniej jednak ponieważ TDD jest u nas w firmie na porządku dziennym i mamy w  tym spore doświadczenie to same warsztaty dla mnie osobiście nie były interesujące (może po części też dlatego, że jednak wymagały umiejętności programowania w Pythonie). Ale brawa dla chłopaków, bo tego typu praktyki trzeba jak najbardziej propagować, jeśli chcemy zapewnić wysoką jakość tworzonych a zwłaszcza rozwijanych aplikacji.

Kolejną dość ciekawą prelekcją było zagadnienie praktycznego wykorzystania Pythona we współczesnych systemach pomiarowych używanych w laboratoriach fizycznych. Prelekcje poprowadził Paweł Nita. Duży plus za pokazanie praktycznego wykorzystania języka.

Następnie bardzo interesujący wykład Marcina Mierzejewskiego o dataminingu i przewidywaniu przyszłości za pomocą Python i Orange. Dla mnie wykład był o tyle interesujący, że po dwóch latach studiów Informatyki i Ekonometrii wreszcie ktoś pokazał mi na prawdę proste ale bardzo efektywne zastosowanie podstaw metod ekonometrycznych i statystycznych. Oczywiście aspekt wykorzystania pythona do tworzenia modeli, które przewidują przyszłość obliczając trendy i inne tego typu rzeczy pokazuje kolejne praktyczne i wydajne zastosowanie tego języka. Sam temat dataminingu jest wart zainteresowania i w mitycznej wolnej chwili na pewno postaram się poszerzyć swoja wiedzę w tym temacie.

A po obiedzie był Adam Zieliński współtwórca serwisu dla kinomaniaków Filmaster.pl. I tutaj przeżyłem szok, gdy usłyszałem, że w serwisie, którego kod jest otwarty nie napisano prawie żadnych testów. Ja bym się wstydził pokazywać innym coś takiego i raczej bym się z tym krył. Niemniej jednak serwis świetny i wart polecenia.

Niedziela 18 X 2009:
Niedzielny poranek rozpoczął Jarosław Zgoda prezentacją o WSGI której konkluzją była idea wykorzystywania istniejących już rozwiązań a nie próba wynajdywania koła od nowa. Prezentacja bardzo wartościowa zwłaszcza dla początkujących programistów, którzy zawsze wiedzą lepiej

Wartym uwagi był też wykład Mrka Gajdy o tworzeniu prostych gier w Pythonie i nie tylko. Chyba nawet złapałem bakcyla, może to fajny pomysł na nowe hobby.

Podsumowanie: Konferencja na pewno pozostawiła pozytywne wrażenie – ciekawa tematyka i świetni ludzie. Kilka minusów organizacyjnych: bardzo marny internet, prąd którego dosyć często brakowało, ciasna i duszna sala etc. ale na plus świetna lokalizacja i doskonałe jedzenie . Mała dygresja – czemu można zorganizować konferencję dla programistów pythona której koszt to około 300 zł, a nie można zorganizować konferencji dla testerów za mniej niż 1000zł?

A i oczywiście podziękowania dla Code Sprinters i Andy’ego za zasponsorowanie naszego udziału w konferencji.

Wiele razy słyszałem (z różnych ust), że testerzy są niepotrzebni… Muszę się z tym zgodzić… (!?)

(…teraz strzelam sobie zawodowego samobója )

Jeśli spojrzymy na współczesne metodologie wytwarzania oprogramowanie (mowa głównie o agile) możemy dostrzec zanik roli testera w projekcie. Zwykłe przeklikiwanie się przez aplikację już nie wystarcza by sprostać wymaganiom stawianym przez współczesnych klientów – aplikacje mają być w pełni modyfikowalne i rozwijalne w dowolnym kierunku (i przeważnie są wielokrotnie modyfikowane i rozwijane), popularność zyskuje nawiązanie do prototypowania, gdzie w celu sprawdzenia czy dana aplikacja/serwis zdoła przyciągnąć uwagę klientów, najpierw wypuszcza się jego okrojoną wersję w celu zdobycia informacji na temat zapotrzebowania klientów, a dopiero później rozwija się serwis w kierunku wyznaczonym przez potencjalnych klientów. Gdy w aplikacji następuje wiele częstych zmian zwykłe klikanie staje się mało opłacalne. Jeśli np. mamy  do czynienia z serwisem społecznościowym w którym zmiany są publikowane co tydzień, ilość potrzebnych testów i możliwych scenariuszy jest tak duża, że wymagane jest zatrudnianie coraz więcej testerów.

W większości zwinnych metodologi podstawą są automatyczne testy, czy to unit testy, czy testy integracyjne zasadniczo pisane przez programistów, więc gdzie tu miejsce dla testera? Oczywiście, tester przydaje się do wykonania testów akceptacyjnych, ale to tak na prawdę szybka robota w porównaniu do długości całego cyklu wytwarzania oprogramowania. Na szczęście mało kto zdaje sobie sprawę z konieczność zapewnienia odpowiedniego – maksymalnego (w granicach rozsądku) pokrycia kodu testami (o tym innym razem),  dzięki temu testerzy mają jeszcze co robić… Testy akceptacyjne, testy sprawdzające warunki odbioru produktów będą zawsze potrzebne, więc zawód testera raczej nie zaniknie, zmienią się, zostaną okrojone jedynie jego zadania i kompetencje. Może to trochę czarna wizja przyszłości niemniej jednak jest to wizja prawdopodobna.

W dobie automatyzacji w każdej dziedzinie życia, praca testera też zostanie zastąpiona przez maszyny, testy automatyczne, konkretniej funkcjonalne testy automatyczne. W przypadku aplikacji www testy mogą być wykonywane np. przy pomocy Selenium lub innych narzędzi, gdy mamy do czynienia z aplikacjami desktopowymi np. przy użyciu TestComplete…  Narzędzia tego typu jeszcze do niedawna niedoceniane coraz bardziej zyskują na popularności i zwiększa się ich ilość. Właśnie przeczytałem o czymś co nazywa się AutoIT (ale o tym też innym razem, jak już to wypróbuje). Dlatego w projektach wzrasta rola kogoś określanego mianem Iżyniera Testów, czyli osoba która potrafi programować na tyle by pisać tego typu testy i je utrzymywać, a jednocześnie posiadająca wiedzę nt testowania aplikacji na poziomie umożliwiającym projektowanie odpowiednich scenariuszy i przypadków testowych.

Jak to mówią “potrzeba matką wynalazków”, więc sygnaturka w moim firmowym mailu zmieniła się na SQA & Test Engineer.  Awans? Raczej nie, w sumie od samego początku się tym zajmowałem, ale dopiero podczas jednej z rozmów przy piwie zostało to w pewnym stopniu sprecyzowane. Cytuje Adama: “Wg mnie każdy tester powinien być także inżynierem testów” – po przemyśleniu nie pozostaje mi nic innego jak zgodzić się z tym stwierdzeniem. Podczas ciągłych zmian samo przeklikiwanie się przez aplikację już nie wystarczy, niemniej jednak same testy automatyczne nie są w stanie wszystkiego sprawdzić, a gdy ich ilość osiąga pewną krytyczna masę ich utrzymanie staje się zbyt kosztowne i “testerzy górą”, dlatego Tester i Inżynier Testów w jednym to idealne rozwiązanie.

Pozostaje mi tylko życzyć powodzenia wszystkim testerom, którzy nie zamierzają uczyć się pisania testów. Moje mroczne wizje prawdopodobnie się nie spełnią chociażby dlatego, że znacząca większość projektów nadal jest rozwijana wg. starych metodologi i pewnie jeszcze długo będzie, a metodologie zwinne mało kto potrafi i chce w pełni wykorzystywać.

Na blogu pojawił się jakiś czas temu kurs Selenium. To dopiero początek! W mitycznych wolnych chwilach postaram się go uaktualniać i dopisywać różne ciekawe rzeczy z tym narzędziem powiązane.

Dlaczego oddzielna strona – a dlatego, że jest to narzędzie na tyle rozbudowane, oraz posiadające na tyle dużo możliwości (często trudnych do odkrycia), że warto mu poświęcić osobną stronę. Jeśli chodzi polskojęzyczny Internet ciężko jest znaleźć cokolwiek na ten temat, więc może komuś przyda się to co tutaj zamieszczę… Na razie jest tego niewiele – kilka podstawowych pojęć i sposób instalacji… Wszystko opisuję raczej z pamięci, więc mogą być tam małe błędy… Gdyby ktoś miał jakieś uwagi piszcie na maila… Gdyby ktoś odkrył coś ciekawego w tym narzędziu także proszę o kontakt…

Jak już pisałem Selenium pomimo tego, że jest to Open Source, jest narzędzie niesamowicie rozbudowany, potrafiącym przetestować prawie wszystko co jest w stanie obsłużyć przeglądarka internetowa, a ponadto umożliwia testowanie w różnych środowiskach… Ale o tym wszystkim wkórtce na stronach kursu…

Selenium jest idealnym narzędziem wspomagającym testowanie aplikacji zarządzanych agile’owo. Świetnie sprawdza się w continues integration. Za jego pomocą można łatwo przetestować większość java script na stronie, do których testy jednostkowe są często traktowane po macoszemu. Jeśłi testy są dobrze napisane i zaplanowane ich utrzymanie wcale nie jest tak kosztowne jak by się to wydawało.

“Testowanie wymagań i chodzenie po wodzie jest łatwe pod warunkiem, że są zamrożone”

Planując testy akceptacyjne staram się oprzeć na wymaganiach, które według klienta powinny zostać spełnione by aplikacja była akceptowalna. To jest oczywiste. Jednak co zrobić, gdy wymagania zmieniają się wraz z rozwojem aplikacji, jak to często w projektach Agile’owych i nie tylko bywa? Standardowy model “V” nie nadaje się tutaj do  zastosowania, gdyż zakłada on planowanie testów akceptacyjnych, a co za tym idzie implementację tych testów w odpowiedniej, stosunkowo wczesnej fazie projektu. Przy takim rozwiązaniu gdy testy są wcześnie zaimplementowane a wymagania nie są do końca sprecyzowana (ulegają ciągłym zmianom) utrzymanie testów staje się zbyt kosztowne.

Testowanie zmieniających się wymagań nigdy nie będzie proste i nigdy nie będzie tanie, chociażby  nie wiem jak te testy były zaplanowane i napisane/zrealizowane. Najbardziej optymalnym rozwiązaniem w takiej sytuacji jest powrót do podstaw i rozbicie aplikacji na poszczególne podsystemy o określonych, zawężonych funkcjonalnościach, maksymalnie oddzielone od reszty aplikacji, po czym doprowadzenie kolejno jeden po drugim każdy z tych podsystemów do oczekiwanego akceptowalnego stanu. W innym wypadku wpadniemy w “Cowoboy Coding” z “Bug Huntingiem”, co obrazuje się w sposób następujący: testerzy znajdują błędy w różnych częściach aplikacji, developerzy je poprawiają, dodają nową funkcjonalność psując coś w innym miejscu, testerzy lub automatyczne testy znajdują te błędy, deweloperzy  znów poprawiają psując coś innego i tak w kółko. Nie da się ogarnąć projektu bez zaplanowanej metodologi działania. Wszelkie poprawki i zmiany powinny być z góry zaplanowane i w odpowiedni sposób przetestowane przed wysłaniem ich na serwer, gdzie następują testy integracyjne. Bardzo istotny jest obieg informacji – co, kto i dlaczego robi, oraz co jeszcze ktoś inny będzie musiał  z tym zrobić. W agile testowanie w dużym stopniu opiera się na testach poszczególnych funkcjonalności, które wykluczają większość błędów nie wynikających z problemów integracyjnych.

Słyszałem o aplikacjach powstających metodą “Wielkiego Wybuchu”, która polega na tym, że wszyscy nagle siadają i coś kodują, starając się nie wchodzić sobie w drogę. Zazwyczaj kończy się to wielkim bałaganem, który czasem nawet działa ale nikt nie jest z niego zadowolony. Najgorsze jednak w tym wszystkim jest to, że jeśli przyjdzie zrobić jakąś zmianę, albo poprawić jakieś błędy to nagle okazuje się, że wiele fragmentów kodu jest zduplikowanych, albo zależy od nich zbyt wiele innych części aplikacji.

Rozwiązaniem większości problemów jest skrupulatne planowanie oraz pozostawienie możliwości przyszłego rozwoju dla każdej części aplikacji w każdym możliwym kierunku. Ważnym jest też dobór odpowiedniej metodologii. Dzięki tym rozwiązaniom nawet najbardziej zmienne wymagania nie są nam straszne. Jeśli wymagania się zmieniają, wracamy do odpowiedniej części aplilkacji i ponownie pracujemy nad nią, aż nowe wymagania zostaną spełnione, nie ingerując w inne części projektu.

Przeczytałem kilka publikacji na temat testowania w metodologiach zwinnych, ale jak do tej pory żadna nie oddaje w pełni tego co ja doświadczyłem podczas pierwszego zetknięcia się z testowaniem w Scrum’ie ( o nim samym może innym razem). Jak ogólnie wiadomo Scrum zakłada iteracyjny model wytwarzania oprogramowania, czyli po każdym sprincie (w moim przypadku co dwa tygodnie) powinniśmy mieć przynajmniej jedną nową, w pełni działającą “funkcjonalność”.

Mądre książki podają, że podstawą takiego wytwarzania oprogramowania są automatyczne testy pisane przed rozpoczęciem implementacji właściwego kodu programu – nie zamierzam z tym polemizować, gdyż jest to działka raczej programisty nie testera. Kolejną rzeczą która powinna zostać zrobiona jest tworzenie i aktualizowanie na bieżąco automatycznych testów funkcjonalnych (Selenium, TestComplete, etc.) – słuszne podejście, moje ostatnie doświadczenia potwierdziły istotność takich testów, a konkretnie potwierdził to ich brak. Utrzymanie automatycznych testów funkcjonalnych jest jednak czasochłonne i kosztowne. Przejdźmy więc do testów manualnych. Jak testować w modelu iteracyjnym?

Działając zgodnie z procedurami opisanym tu i ówdzie testowałem każdą nową funkcjonalność z osobna (tutaj znów spostrzegłem potrzebę istnienia automatycznych testów, gdyż nie sposób było przetestować całą aplikację po każdej małej zmianie), przynosiło to dobre efekty, lecz jedynie na krótką metę, ponieważ jeśli chodzi o nowe, właśnie wprowadzone funkcjonalności mogliśmy z dużym prawdopodobieństwem stwierdzić, że działają poprawnie, lecz niestety aplikacja jako całość w zasadzie nigdy (aż do testów akceptacyjnych) nie została przetestowana. I tu pojawia się właśnie rola testów akceptacyjnych, które zostały zostawione na sam koniec. Czy to złe podejście? Moim zdaniem nie do końca, dzięki temu unikamy zbędnego powtarzania się (zakładając, że nie mamy do dyspozycji automatycznych testów funkcjonalnych), testy akceptacyjne w których z konieczności zawierają się także testy integracyjne, mogą zostać przeprowadzone w środowisku praktycznie identycznym z produkcyjnym. Liczba błędów, które udało mi się znaleźć podczas tych testów jest naprawdę znikoma, co ukazuje wyższość zwinnych testów  każdej poszczególnej funkcjonalności i poprawność odizolowania od siebie poszczególnych części kodu aplikacji (co też powinno być/jest niepisaną zasadą Scrum’a). Błędy które znalazłem wynikały głównie ze środowisk na których aplikacja została zainstalowana.

Lecz to jeszcze nie koniec  – jak wiadomo najlepszymi testerami są zwykli użytkownicy, dlatego głośno i stanowczo postuluje za tym, by wszystkie większe projekty agile’owe były wydawana najpierw w wersji BETA i dopiero po zatwierdzeniu przez grupę testowych użytkowników publikowane jako gotowe finalne wersje produktu. Myślę, że nawet koszty obniżenia ceny pierwszej wersji produktu zostaną zrównoważone jego jakością. Spójrzmy na najlepszych/największych Gmail od pięciu lat jest w wersji beta i pewnie jeszcze długo będzie, jest to typowy przykład projektu rozwijanego iteracyjnie w Agile, testowany przez klientów i cieszący się dużą popularnością oraz względną niezawodnością.

O kosztach testowania postaram się napisać innym razem. Konkluzja: pozostawienie integracyjnych testów na sam koniec wydaje się być w miarę rozsądne, oczywiście jeśli mamy na to czas.

Zdarzyło mi się ostatnio uczestniczyć w ciekawej konferencji prowadzonej przez dwóch panów z Microsoftu. Tematami konferencji były Sillverlight (o którym kiedy indziej) i oprogramowanie wspomagające pracę ludzi z IT. Prezentacja była przygotowana dla członków krakowskiej grupy Adobers  (www.adobers.org) – ludzi na co dzień związanych z Flash i podobnymi technologiami, niemniej jednak z szybkiej ankiety wynikało, że prawie połowa osób na sali nie była bezpośrednio związana z w.w. technologią. Panowie pokazywali jak fajny jest Silverlight, jak w przyjemny sposób wykorzystywać narzędzia oferowane przez Microsoft (Visual Studio, Blend etc.) do szybkiej współpracy różnych osób zajmujących się projektami, począwszy od programistów, skończywszy na grafikach, designerach a nawet samym kliencie. Wszystko fajnie tylko jakoś zbyt pięknie to dla mnie wyglądało. Skoro MC jest taki fajny i dostarcza takie fajne narzędzia to czemu mało kto z nich korzysta? Chyba każdy ma swoje powody.

Kolejne ciekawe spostrzeżenie – w Krakowie mamy na prawdę dużo osób zaangażowanych w ruch Open Source – padło  wiele pytań w tym kontekście. Jak się okazało bardzo wielu ludzi z IT korzysta darmowych systemów operacyjnych i narzędzi (o czym już wcześniej wiedziałem patrząc na kolegów z pracy – ale pytania zadawane na konferencji pozwoliły mi uogólnić swoje spostrzeżenia). Oby tak dalej.

Moja obecność na tym eventcie nie wynikała czysto z zainteresowania Silverlightem, byłem tam służbowo – moje zadanie to wyciągnięcie jak najwięcej informacji o tym w jaki sposób najtaniej pozyskać wspomniane narzędzia Microsoftu a także licencje na Windowsy etc. Zadanie zakończone sukcesem. Otóż okazuje się że nie taki straszny Microsoft jakim go malują – ta zdawałoby się zadufana w sobie korporacja wspiera, małe i średnie przedsiębiorstwa oferując im różnoraką pomoc, ale nie będę o tym pisał – wszystkie te informacje można znaleźć na stronach www.microsoft.com (tzn. trzeba baaardzo długo szukać, bo niestety projektanci tych stron nie mieli pojęcia o usability i prawidłowym przedstawianiu informacji, a i jeszcze jedno – strony Microsoftu nie działają zbyt dobrze w innych przeglądarkach niż IE) . Dla naszej firmy też udało się znaleźć pewne optymalne rozwiązanie, które pozwoli nam zaoszczędzić trochę na licencjach…

Jeszcze jedno spostrzeżenie inżynierowie a raczej projektanci z Microsoftu skłaniają się powoli w stronę rozwiązań zwinnych, świadczą o tym chociażby narzędzia projektowane w celu zachowania ciągłej współpracy z klientem i silnego rozgraniczenia wszystkich warstw projektu w celu uczynienia ich w pełni niezależnymi od siebie. Kolejnym plusem jest wymuszenie stosowania się programistów i nie tylko do zasad MVC, a także ułatwienie dostępu do dobrych wzorców projektowych. O tych i innych ciekawostkach związanych z technologiami od wujka Billa postaram się napisać w przyszłości, a myślę, że będzie ku temu okazja, gdyż moim nowy długoterminowym zadaniem w firmie jest wdrożenie się w możliwie najlepszy sposób w te technologie. A wszystko w imię zasady “Nasz klient – nasz pan”, niestety (a może stety) rynek rozwija się w wielu kierunkach także w stronę rozwiązań Microsoftu.