blog.testowka.pl

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”.

Zgodnie z informacjami napływającymi z Scrum Alliance oraz Scrum.org Scrum Allicane odebrał Kenowi Schwaberowi Tytuł “Certified Scrum Trainter” co uniemożliwia mu przyznawanie certyfikatów sygnowanych przez Scrum Alliance w tym także CSM. Sytuacja jest o tyle paradoksalna, że to Ken Schwaber utworzył program tej ścieżki certyfikacyjnej. Powodem powyższej decyzji było złamanie przez pana Schwabera jednego z podpunktów umowy CST, który mówi o tym, że będąc trenerem Scrum Alliance nie wolno przeprowadzać szkoleń scumowych nieakredytowanych przez tą organizację. Ken złamał regulamin tworząc nową ścieżkę certyfikacji Professional Scrum Master – Scrum in Depth.

Szkolenie Scrum In Depth zostało utworzone przez Kena głównie po to by wyróżnić osoby posiadające zaawansowaną wiedzę z dziedziny SCRUM, którą nabędą podczas tego szkolenia oraz praktyki/samodzielnej nauki. Kolejnym powodem była ogólna opinia na rynku mówiąca o tym, że certyfikaty CSM tracą na znaczeniu przez to, iż nie wymagały zdawania żadnego egzaminu (obecnie samo przystąpienie do egzaminu CSM już uprawnia do otrzymania tego certyfikatu).

Po szkoleniu Scrum in Depth uczestnicy przystępują do zdawania egzaminu Professional Scrum Master I (który z założenia jest trudniejszy od CSM oraz faktycznie poświadcza o posiadaniu konkretnej wiedzy z dziedziny SCRUM i Agile). Jego zdanie (wynik powyżej 80%)  oznacza przyznanie certyfikatu Professional Scrum Master I. Szkolenie Scrum in Depth oraz zdanie egzaminu PSM I otwierają drogę do dalszej ścieżki certyfikacyjnej sygnowanej przez Scrum.org. Po odbyciu szkolenia i zdaniu egzaminu PSM I każdy uczestnik może przystąpić do egzaminu PSM II.

Ścieżkę egzaminacyjną Professional Scrum Master możemy uznać za równoległą do ścieżki CSM, z tym jednak wyjątkiem, że certyfikaty PSM wymagają ZDANIA trudniejszych egzaminów dzięki czemu mają większe znaczenie na rynku i nie każdy może taki certyfikat otrzymać. Certyfikat PSM II można uznać za równoznaczny z CSP (Certyfied Scrum Practitioner) z Scrum Alliance. Po zdaniu tych dwóch egzaminów istnieje możliwość stania się trenerem Scrum in Depth, wymaga to pozytywnego rozpatrzenia podania przez Kena Schwabera i spełnienia kilku indywidualnie wyznaczanych przez Kena warunków.

Przypomnę może jeszcze jak wygląda ścieżka certyfikacji Scrum Alliance:
Obecnie uczestnicy kończąc szkolenie i przystępując do egzaminu (obecnie wszyscy którzy do niego przystąpią automatycznie go zdają bez względu na wynik) otrzymują certyfikat CSM (Certyfied Scrum Master). Po pewnym okresie czasu (obecnie jest to chyba conajmniej rok) posiadacze CSM mogą ubiegać się o przyznanie certyfikatu CSP (Certyfied Scrum Practitioner) który dostaną na podstawie pozytywnej opinii komisji Scrum Alliance. Po uzyskaniu CSM, CSP, oraz CSPO (Certified Scrum Product Owner) można się ubiegać o nadanie tytułu CST (Certified Scrum Trainer) albo CSC (Certified Scrum Coach), niemniej jednak zasady przyznawania tych tytułów i uprawnień są bardzo płynne i ich spełnienie wymaga posiadania szerokich znajomości wśród wysoko postawionych członków Scrum Alliance oraz innych trenerów, co także było powodem utworzenia oddzielnej ścieżki przez Kena Schwabera. Utrzymanie tych certyfikatów wymaga corocznego uiszczenia opłaty oraz zdawania egzaminów.

Miło mi poinformować, że wśród trenerów Professional Scrum Master znalazł się także Andy Brandt z Code Sprinters.

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ć.

Zgodnie z obietnicą zamieszczam prezentację z ostatniego SPINu. Dziękuję wszystkim za przybycie.

Link do prezentacji znajduje się tutaj: TDD i Continous Integration.

Ze względu na trudności techniczne podczas praktycznej części prezentacji film który był nagrywany zostanie uzupełniony o DZIAŁAJĄCE przykłady (oczywiście link do niego też znajdzie się na blogu). Za wszelkie niedociągnięcia techniczne przepraszam, tak to jest gdy w ostatniej chwili wpada się na “genialne” pomysły przeróbek i udoskonaleń prezentacji…

Wyciągnąłem wnioski na przyszłość…

Serdecznie zapraszam na najbliższe spotkanie krakowskiej grupy SPIN, które odbędzie się 27.05.2010 o godzinie 18.00 tradycyjnie już w siedzibie Comarchu. Na spotkaniu tym postaram się przybliżyć ideę Continous Integration oraz TDD a przede wszystkim pokażę jak za darmo stworzyć kompletne środowisko do automatycznych testów GUI (zgonie z zasadami CI).

Po spotkaniu zamieszczę tutaj prezentację pewnie z jakimś szczegółowym opisem, a także nagranie (jeśli wszystko pójdzie zgodnie z planem).

Jeszcze raz serdecznie zapraszam!

Scrum to nie filozofia, to nie religia, nawet nie metodologia – to tylko proste narzędzie. Zauważyłem, że wielu ludzi próbuje uczynić ze Scruma jakąś metodologię do wszystkiego. Moim zdaniem Scrum powstał dlatego, że niektórzy mieli już dosyć sformalizowanych metodologii. Miał z założenia być prostym narzędziem oferującym kilka artefaktów, a wszystko inne miało zależeć od wizji i potrzeb użytkowników. Wspomniane artefakty to Backlog, Iteracje, Daily Scrum, Burndown Chart, Scrum Master oraz Product Owner (chyba o niczym istotnym nie zapomniałem). Wszystko inne powstało na potrzeby konkretnych projektów/użytkowników. Scrum miał być narzędziem dla każdego, narzędziem które miało być kompatybilne z różnymi metodologiami i narzędziami.

Dlaczego Scrum staje się rozbudowaną, coraz mniej zrozumiałą metodologią? Wielu użytkowników Scruma z powodzeniem zastosowała go wraz z innymi rozwiązaniami z pod znaku Agile i nie tylko, po czym próbowali swoje sukcesy i spostrzeżenia jak najbardziej uogólnić i przekazać innym. Niemniej jednak to co z tego powstało nie nazwał bym już Scrumem samym w sobie, Scrumem – narzędziem, tylko raczej Scrumem metodologią opartą o Scrum jako narzędzie, a wzbogaconą o wiele artefaktów i rozwiązań z innych metodologii i narzędzi. Należy zatem rozróżniać Scrum od wszystkiego co Scrumopochodne co możemy znaleźć w wielu często interesujących publikacjach i na wielu szkoleniach/konferencjach.

Owszem, takie rozwiązania są często bardzo wartościowe, niemniej jednak zanim wprowadzi się je w życie należy się zastanowić czy na prawdę tego potrzebujemy. Czasem warto stosować sprawdzone wcześniej przez innych rozwiązania, lecz czasem warto też wrócić do korzeni, do podstaw i na nich zbudować własny framework scrumowy idealnie dopasowany do projektu, zespołu oraz warunków.

Scrum Master to praca na pełny etat właśnie dlatego, że jednym z zadani mistrza młyna jest rozwijanie metodologii i eksperymentowanie z nowymi narzędziami by jak najbardziej zwiększyć wydajności i jakość pracy. Ale o tej konkretnie roli Scrum Mastera może innym razem.

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.

Jako że jestem studentem (nadal, jeszcze, znowu itd ) postanowiłem wykorzystać ten fakt i skorzystać z możliwości pobrania “darmowego” Windowsa. Darmowego i jak najbardziej legalnego zgodnie z licencją MSDNAA E-Academy License Management System (ELMS), która to przysługuje mi z racji bycie studentem na mojej Uczelni.

Pomijam fakt, że podczas rejestracji w cudownym systemie ELMS hasło, które podawałem przy pierwszej rejestracji zostało mi przesłane ponownie drogą mailową, niczym nie zabezpieczonym plain textem. Ot taki mały security sic problem, ale w systemach z pod znaku M$ nic takiego nie jest mnie już w stanie zaskoczyć.

Po wypełnieniu papierków na uczelni – podpisaniu umowy (oczywiście w języku angielskim, którego przecież mógłbym nie zrozumieć, ale kogo to obchodzi) dopełniłem rejestracji klikając w link aktywacyjny i logując się na moje konto w MSDN Academic Alliance Software Center. Pierwsze zdziwienie nastąpiło, gdy okazało się, iż jest to marna przeróbka sklepu internetowego Micro$oftu, w której aby coś pobrać, podobnie jak w sklepie najpierw muszę dodać to do koszyka, po czym zatwierdzić “zakup” (nawet niektórych tekstów nie pozmieniali). Na szczęście w miejscu cen było “Free”. Po dokonaniu “zakupu” polskiej wersji Windows XP Proffessional (Single User) na ekranie wyświetliła się instrukcja by kliknąć w link “download” co też uczyniłem. Możecie sobie wyobrazić moje zaskoczenie (albo jego brak),.gdy okazało się, iż aby ściągnąć Windowsa musże najpierw zainstalować aplikację Windows_XP_ISO_Downloader.exe. W skrócie, by zainstalować Windowsa potrzebuję Windowsa, który tą aplikację obsłuży.

Żeby nie było, że tak łatwo się poddałem spróbowałem uruchomić “downloadera” używając do tego celu Wine. Po chwili niepewnośći moim oczom ukazał się poniższy obrazek:

Treść powyższego dość jednoznacznie sugeruje, że jest to nie tylko dowloader ale i installer Windowsa. Nie zważając na ryzyko (wykorzystując defaultowe C:\Temp – z ciekawości co się stanie) przeszedłem do następnego kroku.

Ściąga się… W sumie zastanawiam się jak to możliwe, gdyż nie odpaliłem Wine jako root (może ustawiłem to gdzieś, kiedyś tylko o tym zapomniałem). Poczekamy na efekty za kilka minut…

Obraz ISO z Windowsem ściągnął się. Przynajmniej tak twierdzi ta wspaniała aplikacja. Osobiście nie udało mi się odnaleźć tego pliku na moim dysku. No nic… Raz się żyje – klikam “Launch”. I… Stało się to czego się w sumie spodziewałem wysypał się Wine. Może właśnie problemem był brak uprawnień do pisania po dysku, albo nieistniejąca ścieżka do katalogu. Chyba wypadało by sprawdzać takie rzeczy przed narażeniem użytkownika na kilkugodzinne bezcelowe ściąganie pliku.

Efekt końcowy dość przewidywalny. Być może jest jakiś sposób na efektywne pobranie Windowsa przy użyciu Linuksa, ale niestety nie mam teraz czasu by się tym zajmować. Powyższy eksperyment został przeprowadzony na potrzeby niniejszej notki, a sprowokował go kolega, który miał problemy z samym ściągnięciem Windowsa nie mówiąc o jego instalacji przy użyciu powyższego narzędzia.

PS: Powyższa notka powstawała w trakcie wykonywania opisywanych w niej czynności. Na początku nie wiedziałem jak to się skończy.

Miało być tak pięknie a jest jak zawsze… Niezastąpiony M$ nigdy Cię nie zawiedzie…

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.

Na wstępie chciałbym w skrócie przedstawić podstawowe zasady CI, a może raczej ACI (Automated Continous Integration):

Trzymaj kod w repozytorium
A nawet nie tyle trzymaj co commituj swoje zmiany jak najczęściej, dzięki temu każdy będzie miał możliwość integrowania swoich zmian z Twoimi. Do tego należy także pamiętać o tym aby także updateować jak najczęściej swoje lokalne repozytorium na którym się pracuje aby integrować swoje zmiany z najświeższymi zmianami kolegów.
Cechy dobrego repozytorium to przede wszystkim:
- przejrzysty widok ostatnich zmian
- możliwość tworzenia rozgałęzień i automatycznego łączenia ich
- system powiadomień o zmianach
- łatwa możliwość odwrócenia ostatnich zmian
Osobiście używam GIT i SVN, jak na razie obydwa spełniają większość moich oczekiwań.

Automatyzuj buildy
Buildy powinny być odpalane automatycznie. Do automatyzacji buildów polecam Hudson lub CruiseControll. Warto też wspomnieć o tym co taki build powinien robić, mianowicie powinien:
- odpalać testy jednostkowe
- odpalać inne testy (jeśli są)
- generować raporty z pokrycia kodu testami
- generować raporty z wynikami testów
- wysyłać powiadomienia, zwłaszcza gdy testy nie przechodzą
- powinien być zintegrowany ze środowiskiem RC do którego commity powinny trafiać jedynie, gdy build przechodzi
- powinien generować inne artefakty, które są w danym projekcie potrzebne.

Stosuj TDD
Tak, by to wszystko miało sens potrzebne są testy do kodu, który piszemy. Jak najwięcej testów. Najlepszą praktyką w tej dziedzinie jest TDD – pisanie testów przed napisanie właściwego kodu (ale o tym może innym razem).

Zasada nie zabierania zakiszonego kodu do domu
Każdy programista commituje przynajmniej raz dziennie. Im częściej tym lepiej.

Każdy commit odpala build
Po każdej zmianie kodu powinny być odpalane testy w celu jak najszybszego wykrycia błędów i ich poprawy,a także w celu łatwiejszego wykrycia przyczyny błędu (zazwyczaj należy jej szukać tylko w ostatnim commicie).

Utrzymuj build szybkim
Buildy powinny być jak najszybsze, by niepotrzebnie nie marnować czasu na czekanie, aż build przejdzie. Obecnie rozwiązuje się ten problem w sposób sprzętowy np stosując chmury obliczeniowe do odpalania testów.

Środowisko testowe powinno być bliźniacze do środowiska produkcyjnego
Chociażby dlatego by uniknąć błędów wynikających z różnicy w tych środowiskach.

W każdej chwili powinieneś mieć dostęp do ostatniej stabilnej wersji oprogramowania
Zgodnie ze wspomnianą zasadą Agile, w każdej chwili powinniśmy mieć pod ręką jakąś stabilną wersję oprogramowania teoretycznie gotową do publikacji.

Każdy powinien mieć dostęp do wyników buildów
Na przykład Hudson ma wbudowany ciekawy plugin, który umożliwia graficzna prezentację wyników ostatnich buildów. Tego typu aplikacje mają zazwyczaj także api, które sprzyja tworzeniu własnych rozwiązań do prezentacji efektów testów etc. My w firmie używamy właśnie Hudsona i specjalnego monitora który stojąc w widocznym dla każdego miejscu prezentuje efekty ostatnich commitów.

Automatyczny deployment
Fajny ficzer zwłaszcza w fazie maintenance projektu, gdy zmiany są dosyć często wgrywane na serwer produkcyjny. Istnieją gotowe narzędzia pozwalające na automatyczne deployowanie aplikacji.

Żeby lepiej zrozumieć na czym polega CI należało by się pierw zastanowić po co właściwie coś takiego jak Ciągła Integracja jest nam potrzebne? Najprościej będzie gdy wrócimy do jednego z podstawowych założeń zwinnego zarządzania projektami a mianowicie: “w dowolnym (odpowiednio zaawansowanym) momencie trwania projektu powinniśmy być w stanie dostarczyć ‘jakiś’ produkt, który spełnia pewne założenia i udostępnia pewną funkcjonalność, produkt ten teoretycznie powinien być gotowy do wypuszczenia na rynek”. Idąc dalej tym tropem można łatwo wywnioskować, że aby produkt był gotowy do publikacji musi spełniać pewne kryteria jakości, które powinny zostać przetestowane. By jeszcze lepiej zrozumieć potrzebę ciągłej integracji w projekcie należałoby się zastanowić nad tym w jaki sposób integrować pracę wielu programistów, którzy pracują nad często zazębiającymi się fragmentami kodu. Może aby lepiej zobrazować strukturę problemu posłużę się przykładem w którym zespół projektowy nie wykorzystuje aspektów CI.

Wyobraźmy sobie zespół składający się z pięciorga programistów i dwojga testerów. Zespół ma dostarczyć jakąś określoną aplikację, która ma trzy podstawowe funkcjonalności. Tutaj pojawia się pierwszy problem – jak podzielić pracę? Może niech każdy programista zajmie się pojedynczą funkcjonalnością, a na koniec spróbują zintegrować to wszystko ze sobą (uwierzcie mi są firmy w których taki model wytwarzania oprogramowania jest stosowany na co dzień). No tak tylko, że funkcjonalności jest 3 a programistów pięcioro. Poza tym są jeszcze testerzy, którzy przez większość czasu będą się nudzić. No dobrze – klasyczny model Waterfall zakłada, że testy powinny być przeprowadzane na końcu, więc niech tak będzie. Żeby jeszcze lepiej wszystko zobrazować dodajmy trochę matematyki. Załóżmy, że wykonanie pierwszej funkcjonalności zajmie około 30 roboczogodzin, drugiej 60 roboczogodzin, trzeciej 15 roboczogodzin. Do tego przetestowanie około 1/3 czasu potrzebnego na implementację czyli odpowiednio 10, 20, 5 roboczogodzin (dość optymistyczne, ale realne założenia). Dobrze – prace ruszyły pierwsza po 15 godzinach zostaje ukończona funkcjonalność nr 3, programista który nad nią pracował teraz odpoczywa. Po kolejnych 15 godzinach została ukończona funkcjonalność nr 1, teraz programiści mogą rozpocząć prace nad integracją funkcjonalności 1 i 3, mają na to około 30 godzin. Po 60 godzinach od rozpoczęcia projektu dostarczono funkcjonalność nr 2, którą teraz trzeba jeszcze zintegrować, na tym etapie okazuje się że popełniono kilka błędów w założeniach, czegoś nie ustalono dokładnie etc. wiec integracja potrwa kolejne 20h. W sumie po 80 godzinach pracy dostarczono produkt do testów. Testowanie wraz z poprawkami zajmie około 40h.

Po 120 godzinach pracy mamy gotowy produkt. Przypomnijmy, że dla dwóch programistów nie było pracy, ciężko jest pracować nad jednym kawałkiem kodu na dwóch różnych komputerach. Co najwyżej służyli oni jedynie pomocą swoim kolegom.

A teraz podobny przykład (ten sam problem do rozwiązania) z tym że zespół wykorzysta większość aspektów CI.

Ponieważ wiemy ile szacunkowo zajmą pracę nad każdą z funkcjonalności i wiemy, że funkcjonalność nr 2 zajmie najdłużej pracować nad nią będzie aż troje programistów, dodatkowo programista, który będzie pracował nad funkcjonalnością nr 3 po zakończeniu prac nad nią wesprze kolegę pracującego nad funkcjonalności nr 1. Praca zespołowa jest w pełni możliwa dzięki temu, że zespół korzysta z systemu kontroli wersji, który pozwala na łatwą dystrybucję najaktualniejszego kodu. Dodatkowo testerzy dzięki środowisku, które roboczo nazwiemy RC (Release Candidate) mogą w każdej chwili testować dostarczane funkcjonalności i zgłaszać błędy, które są dużo łatwiejsze do poprawienie we wcześniejszej fazie. Należy też zauważyć, że integracja całości odbywa się od samego początku, gdyż wszystkie zmiany wrzucane są do jednego repozytorium. Czas implementacji wydłuży się zapewne o około 1/3 ze względu konieczność pisania testów jednostkowych (nie jest to wymóg jeśli w zespole są testerzy, jednak dzięki temu ich praca powinna się skrócić o około połowę). Zobaczmy jak to teraz wygląda. Planowane czasy implementacji po uwzględnieniu dodatkowego pisania testów jednostkowych: F1 – 40 roboczogodzin, F2 – 80 roboczogodzin, F3 – 20 roboczogodzin. Testy: T(F1) – 7 roboczogodzin, T(F2) – 14 roboczogodzin, T(F3) – 4 roboczogodziny. Projekt startuje. Po 10 godzinach pracy rozpoczynają się testy dla funkcjonalności nr 2 (wykonuje je jeden tester). Po 16 godzinach od rozpoczęcia rozpoczynają się testy akceptacyjne dla funkcjonalności nr 3, po 20 godzinach od rozpoczęcia ta funkcjonalność jest już gotowa i przetestowana, programista, który nad nią pracował pomaga programiście pracującemu nad funkcjonalnością nr 1 (do jej ukończenia zostało 20 roboczogodzin, podzielone na dwóch daje po 10 godzin). Trzy godziny później rozpoczynają się testy funkcjonalności nr 1. Po kolejnych 7 godzinach funkcjonalność nr 1 jest ukończona i przetestowana – minęło 30 godzin od rozpoczęcia projektu. W międzyczasie po około 27 godzinach od rozpoczęcia projektu zostaje ukończona i przetestowana funkcjonalność nr 2. Wszystko powinno działać i być już zintegrowane, dla pewności testerzy sprawdzą wszystko jeszcze raz – po 8 godzin każdy.

W sumie daje nam to 38 godzin pracy nad projektem, których efektem jest gotowy, przetestowany produkt, którego dodatkowym gwarantem jakości są test jednostkowe. Dodatkowo od pewnego momentu w z środowiska RC mogliśmy pobrać stabilną – przetestowaną wersję aplikacji zapewniającą pewne funkcjonalności. To raczej znacznie lepszy wynik niż poprzednio. Powyższe założenia są trochę naciągane i wyssane z palca, ale uwierzcie mi już kilkukrotnie widziałem nawet dużo bardziej zaskakujące efekty wprowadzenia CI do procesu wytwarzania oprogramowania.

Powyższy wywód jest również pewnego rodzaju odpowiedzią na często stawiane pytanie: “Czy pisać testy jednostkowe?”. Postaram się w przyszłości poszukać (być może samemu przeprowadzić) jakichś badań na temat czasu wytwarzania oprogramowania z i bez. Ogólnie już teraz mogę wnioskując z doświadczenia jednoznacznie stwierdzić, że niemal zawsze automatyzacja testów znacząco przyspiesza pracę nad projektem, a zwłaszcza pracę w fazie maintenance.

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.

Ten post pisany jest z Google Chrome OS…

I stało się – Google udostępniło źródła Chrome OS, a w Sieci pojawiły się pierwsze obrazy tego systemu. Postanowiłem na własnej skórze (a raczej pececie) sprawdzić czym jest to co ma zrewolucjonizować korzystanie z komputerów osobistych. Po ściągnięciu gotowego wirtualnego dysku z zainstalowanym OSem i odpaleniu go w VirtualBoxie nastąpiło pierwsze miłe zaskoczenie: około 25 sekund i już – system gotowy do pracy.

Spróbujmy nasze rozważania skupić nad samą ideą Chrome OS. W zasadzie nie można go porównywać do Windowsa czy np. Ubuntu, gdyż zgodnie z założeniami Chrome OS jest czymś w rodzaju przeglądarki internetowej wzbogaconej o różne właściwości systemu, a nie systemem operacyjnym w pełnym znaczeniu tego określenie. Według twórców Chrome OS będzie dostępny w sprzedaży tylko razem ze sprzętem, co sprawi, iż będzie on skierowany do wąskiej (niekoniecznie) grupy odbiorców. W Chrome OS wszystko skupia się wokół przeglądarki i Internetu. Wizjonerzy z Google proponują by użytkownicy zrezygnowali z przechowywania danych na swoich dyskach lokalnych na rzecz korzystania z serwerów i aplikacji Google i nie tylko. Pomijając wszechobecną paranoję (mniej lub bardziej uzasadnioną) ogarniającą pewne grupy użytkowników Internetu pomysł wydaje się być całkiem niezły. Gdy dobrze przeanalizujemy zawartość Sieci, oraz wszystkie dostępne w niej aplikacje to okaże się, że oprogramowanie zainstalowane na naszych komputerach można by w całości zastąpić tym dostępnym w Internecie. System operacyjny wydajnie korzystający z zasobów Sieci, porzucający standardowy sposób wykorzystywania komputerów osobistych wydaje się być naturalnym kolejnym krokiem w ewolucji tychże komputerów.

W związku z błyskawicznym rozwojem Internetu zmienia się poziom jego abstrakcji a Google wraz z Suse postanowili wyjść temu na przeciw. Jak mawia pewien profesor z którym mam wykłady z Architektury Systemów Komputerowych “Człowiek tak na prawdę nie wymyśla niczego nowego, wszystko co tworzy, tworzy na podobieństwo czegoś co już istnieje”. Zgodnie z powyższym można przyjąć, że system operacyjny można było porównać do biurka pracownika, na którym można znaleźć wszystkie potrzebne do pracy narzędzia, Internet był z założenia połączeniem wielu biurek – jakimś rodzajem systemu przesyłowego/kurierskiego, a Google tworząc swoje aplikacjie takie jak GoogleDoc, GoogleCalendar, GoogleWave etc., przeniosło biurka do Sieci.

Po kilku godzinach zabawy Google OS jestem skłonny stwierdzić, że pomysł może się przyjąć, ale na razie byłbym ostrożny w spekulacjach na temat tego czy system ten jest w stanie wyprzeć obecnie używane Windowsy i Linuxy.

Samo zjawisko ewolucji Internetu jest tematem niesamowicie ciekawym i będę chciał poświęcić mu pewnie jeszcze niejedną notką.

Do tej notki zainspirowały mnie ruch We don’t support IE i jemu podobne, oraz wieści o nadchodzącej premierze Internet Explorer 9. Dla mnie czyli testera między innymi stron internetowych świadomość pojawienia się kolejne przeglądarki spod znaku błękitnego “e” oznacza tylko jedno – więcej żmudnej pracy przy testach cross-browser. IE 9 to najprawdopodobniej jeszcze jeden “badziew”, którego twórcy tylko słyszeli o czymś takim jak standardy W3C, ale o ich przestrzeganiu nie ma mowy. Przecież IE i tak ma 33% rynku w Polsce, a na świecie około 37%  więc kto by się tym przejmował. Na szczęście w ciągu ostatniego roku ilość użytkowników przeglądarek od wuja Billa spadła o około 10% i miejmy nadzieję, że ten trend się utrzyma.

Dobrze, ale dlaczego nie lubię IE? Odpowiedź jest prosta – gdy mam do sprawdzenia kompatybilność jakiejś strony z kilkoma przeglądarkami to wyniki takich testów przeważnie wyglądają mniej-więcej tak:

Załóżmy, że strona była tworzona dla FireFox 3.* (Przeważnie tak jest chociażby ze względu na ilość dostępnych dodatków dla deweloperów do tej przeglądarki), więc zakładamy po przetestowaniu, że ta przeglądarka jest naszym wzorcem – zgodność oczekiwań 100%.

Zaczynamy testy w innej przeglądarce, powiedzmy starsza wersja FF 2.*  zazwyczaj znajdziemy jakieś drobne uchybienia związane raczej z ewolucją standardów (czasem nie do końca przestrzegana jest kompatybilność wstecz) wyniki takich testów utrzymują się przeważnie na poziomie 95%+.

Weźmy inną przeglądarkę niech to będzie Opera w najnowszej wersji – jeśli chodzi o CSS to możemy być prawie pewni, że wszystko jest ok, może czasem wystąpić jakiś błąd, ale to już nasza wina, że zaimplementowaliśmy coś niezgodnie z obowiązującymi standardami (wynika to z tego, że twórcy Opery są mocno związani z twórcami samego CSS i raczej przestrzegają swoich standardów), możemy się spodziewać kilku drobnych problemów z Java Scriptami, ale nic strasznego – wyniki testów około 92%+.

Przejdźmy do naszego ukochanego IE, zacznijmy od IE6 – ludzie nadal tego używają (około 10% rynku). Nawet nie chce mi się opisywać co jest nie tak: Java Scripty częściej nie działają niż działają, nie jest obsługiwana przezroczystość dla obrazków w formacie .png, CSSy dla FireFoxa można wyrzucić i trzeba pisać od nowa itd… Zgodność IE6 z oczekiwaniami 50%-, czasem tych stron po prostu nie da się otworzyć. Odrobinę lepiej jest w IE7 (obcenie największy odsetek wśród użytkowników Internet Explorera), niemniej jednak nadal względnie liczne problem z Java Scriptami. Nie wspomnę o tym, że w IE w ogóle wszystko zawsze wygląda inaczej i jeśli chodzi o CSS to nasze usilne starania by dobrać odpowiednie marginesy, paddingi i grubości ramek by wszystko wyglądało tak jak należy (w FF) w Internet Explorerze 7 będziemy musieli zapewne powtórzyć. Zgodność z oczekiwaniami około 75%+. Obecnie najnowszą wersją omawianej przeglądarki jest wersja nr 8. Tutaj widzimy już znaczącą poprawę, ale nadal czasem występują problemy z Java Scriptami, względnie mniejsze z CSS. Pomimo wszystko dość często zgłaszam błędy związane z tą przeglądarką, więc ogólna ocena na około 85%-.

Tak znaczące różnice oznaczają zwiększenie całkowitej pracy całego zespołu o kilkadziesiąt procent…

Powyższe oceny są dosyć subiektywne i opierają się na moich testerskich doświadczeniach z powyższymi przeglądarkami. Nie wspomnę już o tym, że IE przed wersją 8 był znacznie wolniejszy od pozostałych przeglądarek. Jedynym atutem jest, to że dzięki ładowaniu podczas startu systemu dużo szybciej uruchamia się za pierwszym razem. Niemniej jednak wadą IE jest to, że można go używać jedynie pod Windowsami.

Tak, zdecydowanie nie lubię Internet Explorera. Niemniej jednak ze względu na jedną trzecią udziałów w rynku jesteśmy zmuszeniu dostosowywać nasze aplikacje do pseudostandartów Microsoftu. Pojawienie się kolejnego Internet Explorera oznacza dla mnie zwiększenie ilości testów o jakieś 20% – testów które i tak są już redundante (dla FF2, FF3, IE8 i IE 7). Także wielkie dzięki. Może przynajmniej IE9 wyprze IE6, ale szanse na to są małe, gdyż IE6 jest głównie używane w korporacjach, a tam procedury zmiany narzędzi są dość skomplikowane, a poziom świadomości technicznej osób za to odpowiedzialnych jest raczej niski. Można śmiało stwierdzić, że ze względu na zwiększenie ilości pracym a co za tym idzie czasu, który jest potrzebny by wypuścić jakąś stronę/aplikację na rynek nieprzestrzeganie przez twórców przeglądarek tego typu wszystkich ustalonych wcześniej standartów stanowi świadome lub nie opóźnianie rozwoju Interntetu, co w dzisiejszych czasa oznacza spowolnienie rozwojuz cywilizacyjnego, na który Internet ma dość duży wpływ. Może za tym wszystkim stoją szlachetne idee zmiany świata przez gości z Microsoftu. Przypomina mi się pewne powiedzenie: “Chcesz zmienić świat na lepsze – zacznij od siebie”.

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.

…W ciemnym pokoju, blask monitora oświetla przygarbioną postać testera… W tle słychać odgłosy stukania w klawiaturę i klikania myszką… Nagle ciszę przerywa złowieszczy śmiech… Operacja się udała… Wszyscy żyją… Może nie wyglądają już tak pieknie jak kiedyś, ale żyją…

Wreszcie po długich oczekiwaniach zmiana layoutu na blogu ze standardowego WordPressowego “pixeled” na moją własną kompozycję kolorystyczną. Od razu podkreślam, że w zasadzie zmieniłem tylko kolorystykę i kilka drobnych szczegółów, gdyż uważam, że sam schemat layoutu “pixeled” jest zadowalający. Może teraz blog nie wygląda tak ładnie jak przedtem ale z pewnością… jest bardziej czytelny…

Z ciekawostek do doboru kolorów użyłem bardzo ciekawego narzędzia “Color palette generator“, które wyciąga głębie barw z podanego obrazka.

Zdjęcie, które wykorzystałem znalazłem na iStockphoto i mam nadzieję, że wyciągnięcie głębi barw nie stanowi naruszenia praw autorskich

Oto i obrazek:

…prawda, że podobne?

Wprost idealnie wpasowuje się w kolorystykę strony. Eksperyment się powiódł, jak widać narzędzia tego typu mogą być bardzo pomocne przy projektowaniu schematów kolorystycznych dla stron.

Marek Kasperski w swojej ksiażce “Projektowanie Stron WWW – Użytecznosć w praktyce” pokazuje przydatność takich narzędzi w wszelkiego rodzaju próbach podświadomego wpływu za pomocą barw na percepcje użytkownika. Na przykład barwy ze zdjęć rajskich wysp idealnie nadają się do kolorystyki stron biur podróży.

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ć.

Jakiś czas temu pisałem o usability formularzy. Jednym z tematów poruszonych przeze mnie było to, czy walidacja formularzy powinna odbywać się w czasie rzeczywistym (AJAXowo), czy dopiero po przeładowaniu strony. Spotkałem się z wieloma sprzecznymi opiniami na ten temat, począwszy od słabej wydajności i ograniczonych możliwości jeśli chodzi o walidację po stronie klienta, po chociażby to, że użytkownicy nie lubią gdy podczas pisania coś im gdzies wyskakuje. Dzisiaj znalazłem w Sieci coś co wydaje mi się pewnym kompromisem, mianowicie w formularzu składania zamówienia w sklepie internetowym sklep-presto.pl zostało zastosowane bardze ciekawe rozwiązanie przypominające użytkownikowi o zaznaczeniu zgody na warunki podane w regulaminie – po najechaniu na przycisk “Dalej” wykonuje się akcja (po stronie przeglądarki) która dodaje czerwoną ramkę wokół obszaru mówiącego o regulaminie. W ten oto prosty sposób została zastosowana walidacja po stronie klienta nie wykonywana w czasie rzeczywistym.

Uważam, że podpięcie wywołania walidacji już pod akcję najechania kursorem na przycisk zatwierdzający, a nie pod samo kliknięcie jest idealną wypadkową, która powinna przypaść do gustu większości użytkowników. Jedynym minusem takiego rozwiązania, który mi sie w chwili obecnej nasuwa jest brak tego typu rozwiązań – jest to pewnego rodzaju nowość, a jak to z nowościami bywa pomimo swojej użytecznosci może nie zostać zaakceptowana przez ogół użytkowników. Niemniej jednak sprawa jest warta przyjrzenia się i przeprowadzenia badań w tym kierunku, co postaram się w najbliższym (wolnym) czasie zrobić.

Jedną z kilku ostatnio przeczytanych przeze mnie książek – nie związanych (bezpośrednio) z informatyką była książka “Sztuka Wojny” w przekładzie Jarka Zawadzkiego. Jednym słowem: “Klasyka”. Książka, którą warto przeczytać. Kilka (w Polsce) lat temu książka robiła furorę w środowisku menagerskim, jednak wszystko jakby trochę przycichło – czyżby okazało się, że praca to nie do końca wojna? Jednak na potrzeby tej notki przyjmę założenie, że praca i kariera mają z wojną wiele wspólnego.

Krótka histora – książka powstała prawdopodobnie około 740 -470 r. p.n.e. autorami są najprawdopodobniej Sun Wu i Su Bin obydwaj zwani Sun Tzu. Pierwszy po sformułowaniu trzynastu rozdziałów dotyczących sztuki wojny został generałem i pokonał wrogie armie, drugi był doradcą innego generała kilkadziesiat lat później.

“Sztuka Wojny” przyciągnęła moją uwagę ze względu na dwa aspekty – możliwość wykorzystania opisanych w niej zasad do zarządzania projektami, ludźmi – “armią”, oraz zastosowanie tychże zasad w “pojedynkach” z konkurencją i klientami. Wiele lekcji Sun Tzu udaje mi się także zastosować w życiu codzienny nie związnym z pracą – w zwykłych kontaktach międzyludzkich, rozwiązywaniu problemów, konfliktów…

Czytając książkę chwilami wydawało mi się, że czytam dobry podręcznik do agile – np. “Aby pokonać wroga trzeba jego armię rozbić na mniejsze i słabsze oddziały”, brzmi jak aby dobrze i szybko wykonać projekt należy każde zadanie rozbić na mniejsze – łatwiejsze do wykonania, “Swoje najlepsze oddziały wystawiaj przeciwko średnim przeciwnika, swoje średnie przeciwko najsłabszym, a najsilniejsze oddziały przeciwnika zostawiaj na koniec i możliwie najbardziej je rozbijaj i osłabiaj” tą zasadę można porównać do odpowiedniego rozdzielenia pracy w zespole programistów. O ile w książce były opisane tak drastyczne metody jak ścinanie niefrasobliwych generałów – o tyle w życiu raczej nie zamierzam nikogo ścinać. Zarządzanie zespołem ludzi w firmie można porównać do zarządzania armią. O ile w scrumie zespół sam się organizuje, a scrum master pełni rolę bardziej nadzorczą i wsparcia, o tyle w innych metodologiach silny lider jest konieczny. W dużych zespołach ważne jest także posłuszeństwo i dokładna wiedza na temat tego co jest czyim zadaniem oraz kto jest za co odpowiedzialny.

Na rynku w branży IT (i nie tylko) trwa nieustanna walka (jeśli nawet nie wojna), w której wszyscy walczą o klienta nie zawsze czysto. Także w tej dziedzinie możemy znaleźć wiele alegorii pomiędzy sztuką wojny a sztuką handlu/merketingu. Według Sun Tzu podstawą do zwycięstwa jest wywiad, tak też wiedza o tym kto czego potrzebuje na rynku jest kluczem do pozyskania klientów, a wiedza o tym co robi konkurencja daje możliwośc bycia zawsze o krok przed nimi.

W walce o klienta, czy w normalnym życiu przydaje się też umiejętność wprowadzania wrogów w błąd – sztuka podstępu. Czasem dobrze jest sprawić, gdy akurat mamy bardzo silną pozycję by wszyscy myśleli, że jest ona słaba chociażby po to by ją jeszcze bardziej wzmocnić, lub wykorzystać pewność siebie konkurencji. Także odwrotnie czasami trzeba umieć stworzyć pozytywną atmosferę gdy wszystko idzie źle, po to, by nie dać przeciwnikom szans na skuteczny atak.

Choć nie wiem jak byśmy się starali nasze życie pełne jest codziennych walk, sporów, wojen, dlatego polecam “Sztukę Wojny” może nie jako poradnik codziennego oszukiwania siebie i innych, ale jako dobrą wskazówkę, że tak też można i co gorsza inni to robią.

Na początku napisałem, że książka nie jest związana z informatyką – chyba jednak się myliłem – czyżby pracocholizm??

Na zakończenie 5 zasad na drodze do wygrania wojny:

- jedność moralna ludzi z władcą
- zdolności wodza
- umiejętne wykorzystanie czasu
- umiejętne wykorzystanie przestrzeni
- dobrze wyszkolone i moralnie zwarte wojsko