wtorek, 28 maja 2013

"Nie chcę być członkiem klubu, który chce abym był jego członkiem"

Julius Henry "Groucho" Marx wśród wielu swoich powiedzonek ukuł jedno z moich ulubionych: "I don't want to belong to any club that will accept people like me as a member". Kiedy czytałem maila wysłanego do mnie z adresu "sjsi@sjsi.org" sparafrazowałem w głowie to powiedzenie w sposób następujący "Nie chcę być członkiem klubu, który chce abym był jego członkiem".

Przypuszczam, że list został wysłany przez "Stowarzyszenie Jakości Systemów Informatycznych". Piszę "przypuszczam" bo jest wiele powodów braku mojej pewności.

Poniżej przytaczam pełnego e-maila z wyjątkiem listy adresów e-mail, które SJSI raczyło mi dostarczyć.
Od: Komitet programowy
Data: 27 maja 2013 14:23
Temat: Zaległe składki SJSI
Do: (jawna lista adresów email wycięta przez TZ)
W chwili obecnej SJSI posiada w swoich strukturach wielu nieaktywnych członków zwyczajnych (osoby nie uczestniczą w pracach SJSI, nie płacą składki członkowskiej, nie ma z nimi kontaktu - dane kontaktowe są nieaktualne). Na spotkaniu Zarządu SJSI, które miało miejsce w Łodzi w dniu 2013.03.23, podjęto decyzję o uporządkowaniu listy członków zwyczajnych.
Do wszystkich członków SJSI zwracamy się zatem z prośbą o uregulowanie składki członkowskiej za rok 2013, co rozumiemy jako chęć pozostania w strukturach Stowarzyszenia. Osoby, które tej składki nie uregulują do końca maja 2013, oraz nie zapłaciły jej w latach 2011-2012 zostaną skreślone z listy członków Stowarzyszenia Jakości Systemów Informatycznych na mocy paragrafu 15, pkt.1, ppkt. 4 Statutu Stowarzyszenia.
Przydatne odnośniki:
- Statut Stowarzyszenia Jakości Systemów Informatycznych
- Dane do przelewu
Sebastian Małyska
Member of SJSI Board
e: s.malyska@sjsi.org | skype: sebam6
SJSI – Polish Association of the International Software Testing
Qualifications Board
Str. Poznanska 16 (r. 4), 00-680 Warsaw, Poland
http://www.sjsi.org
Członkiem stowarzyszenia zostałem bardzo dawno temu. Dokładnej daty nie pamiętam ale z całą pewnością było to przed rokiem 2008. Po zapłaceniu pierwszej składki w wysokości - chyba - 50 złotych - i rocznej hibernacji stwierdziłem, że nie chcę być członkiem stowarzyszenia. W statucie przeczytałem, że jeśli nie zapłacę następnej składki to po prostu zostanę usunięty z listy członków po dwóch latach (Paragraf 15, pkt.1, ppkt.3). A więc efektywnie od roku 2011 formalnie i zgodnie ze statutem nie byłem członkiem Stowarzyszenia. Niestety nie pamiętam czy podejmowałem próby rezygnacji w trybie paragraf 15, pkt. 1, ppkt. 1 więc się na to nie powołuję.

Z drugiego akapitu maila dowiaduję się, że zostanę skreślony "z listy członków Stowarzyszenia Jakości Systemów Informatycznych na mocy paragrafu 15, pkt.1, ppkt. 4 Statutu Stowarzyszenia". Zajrzałem więc do tego dokumentu i dowiedziałem się, że zostanę usunięty z listy członków SJSI za "zachowanie nie licujące z godnością członka Stowarzyszenia lub sprzecznego z celami Stowarzyszenia".

I tak oto stanąłem przed logicznym problemem: jak mogę zostać usunięty z listy członków Stowarzyszenia, którego członkiem formalnie nie jestem. Ta zagadka mnie rozbawiła bo paradoksalnie wskazuje na bałagan i brak jakości w Stowarzyszeniu, którego statutowym celem jest jakość.

Ponieważ nie życzę sobie aby ktoś publicznie pomawiał mnie o brak godności i długi postanowiłem napisać ten wpis i email (wysłany osobno) do Komitetu Programowego protestując przeciwko takiemu prowadzeniu komunikacji.

Studiując listę adresów dostarczoną mi przez SJSI zorientowałem się, że jakość jest bardzo umowna w tym kręgu, gdyż ze składkami zalegają prezes i dwóch wiceprezesów co jest po prostu czymś obrzydliwym i wskazuje na zaistnienie okoliczności, w których wskazany przez Sekretarza Stowarzyszenia podpunkt 4, punktu 1 paragrafu 15 powinien znaleźć zastosowanie, w przypadku gdyby to nie były pomówienia lub pomyłka - jak to mówią „ryba psuje się od głowy”. Mam nadzieję, że to jednak jest pomyłka i przeoczenie wynikające z "ręcznej" pracy nad listą adresów.

To co mnie jeszcze uderzyło, to brak jednoznacznego wskazania skąd mail pochodzi. W adresie nadawcy jest SJSI. W stopce znajduje się także skrót SJSI rozwinięty jako „Polish Association of the International Software Testing Qualifications Board” a adres pocztowy podany jest w formacie angielskim. Jedyne wskazanie na wprost jest w postaci linka do statutu stowarzyszenia.

Jestem testerem oprogramowania z wieloletnim stażem i na co dzień wiem jak trudno jest zdefiniować jakość i jak łatwo jest ją "pogubić". Dumny jest z wykonywanego przeze mnie zawodu! Tym bardziej jest mi przykro, że Stowarzyszenie, które powstało w celu „wspierania członków Stowarzyszenia w zakresie edukacji dotyczącej testowania i zapewnienia jakości” poległo na tak prostej rzeczy i zapomniało o ludziach. A przecież jakość w systemach informatycznych istnieje przede wszystkim przez ludzi i dla ludzi – parafrazując kolejną postać historyczną.

Reasumując, bardzo się cieszę, że takie stowarzyszenie istnieje i stara się działać w zakresie jakości oprogramowania. Jednak namawiałbym członków i osoby odpowiedzialne za tę organizację aby mniej skupiali się na „sprzedaży słowników” – bo za coś takiego uważam ISTQB – a bardziej skoncentrowali się na realnych wyzwaniach i potrzebach w zakresie testów.

Testowanie oprogramowania – jako jedna z gałęzi informatyki – staje przed wieloma wyzwaniami. Jest coraz więcej platform mobilnych, coraz więcej urządzeń. Integracja oprogramowania i urządzeń postępuje bardzo szybko. Oczekiwania użytkowników rosną w miarę rozwoju – zwłaszcza w zakresie systemów czasu rzeczywistego lub „prawie rzeczywistego”. Funkcjonalność jest implementowana w coraz większym rozproszeniu. Coraz więcej oferowanych jest usług złożonych (np. w "chmurze").

Kilkuletnie doświadczenie z ISTQB wskazuje, że skupianie się na nazewnictwie artefaktów nie przyniesie tutaj żadnej ulgi a sprzedaż certyfikatów nie doprowadzi do rozwoju wiedzy i doświadczenia oraz umiejętności radzenia sobie z rosnącym skomplikowaniem rozwiązań informatycznych. Uważam, że zawód testera polega na umiejętności rozwiązywania problemów "testerskich" i ten kierunek sugerowałbym Stowarzyszeniu.

PS: Dzisiaj przyszedł z SJSI email w tonie bardziej pojednawczym wymuszonym, jak wynika z treści przez reakcję adresatów pierwotnej korespondencji.

środa, 15 maja 2013

Zarządzanie zadaniami w arkuszu kalkulacyjnym

Moje środowisko pracy jest wieloprojektowe. Rodzi to konieczność radzenia sobie z kilkoma projektami na raz. Poniżej chciałem przedstawić i zaproponować prosty sposób w jaki ja staram się kontrolować i planować zadania w przecięciu na osoby i zasoby.

Korzystam w tym celu z arkusza kalkulacyjnego wyprodukowanego przez amerykańskiego potentata ale jestem przekonany, że taki sam efekt można osiągnąć korzystając z produktów innych producentów.

Arkusz składa się z trzech zasadniczych arkuszy:
  • arkusz "Ewidencja projektów"
  • arkusz "Ludzie i zasoby"
  • arkusz "Plan gry"

Arkusz "Ewidencja projektów"

Jest to prosta lista projektów wraz z parametrami takimi jak:
  • osoba odpowiedzialna za projekt
  • szacowana pracochłonność w osobodniach
  • testerzy przypisani do projektu
  • rekomendacja wdrożeniowa
  • testowy cykl życia
Ostatnia pozycja odzwierciedla aktualny etap, na którym - z perspektywy procesu testów - znajduje się projekt. Może to być, planowanie, wykonanie lub zakończenie.

 Ostatni etap okazuje się szczególnie "kłopotliwy". Zasada ogólna jest taka, że testy kończą się wraz z wygenerowaniem raportu końcowego. Raport końcowy zaś może być wygenerowany po kompletnym zakończeniu testów rozumianym jako zrealizowanie wszelkich rozpoznanych zadań testowych. W efekcie drobne zadanie, które może być zrealizowane dopiero po uruchomieniu całego projektu może "zablokować" raport końcowy. Dlatego zdecydowałem się na wprowadzenie dwóch raportów końcowych; wstępnego i końcowego.

Raport wstępny, jest dostępny po realizacji zasadniczej części testów, tuż przed "wdrożeniem". Tak jak raport końcowy, zawiera on rekomendację wdrożeniową ale zawiera także informacje o tym co pozostaje do zrobienia. Raport końcowy przygotowywany jest po definitywnym ukończeniu aktywności testowych.

Na marginesie zaznaczę, że "układanie" cyklu życia testów najlepiej jest zacząć od przyjętego modelu a następnie modyfikować go do zastanych potrzeb. Wprowadzenie cyklu życia testów wymaga także zmian po stronie innych partnerów. To z kolei modyfikuje sam proces testowy co właśnie wymusza iteracyjność procesu wdrażania cyklu życia testów.

Obrazek poniżej pokazuje wyimaginowany cykl życia testów.
Przykład struktury arkusza "Ewidencja"

Arkusz "Ludzie i zasoby"

Tutaj znajduje się zasadnicza część i stąd wynikaja główna korzyść: łatwy dostęp do informacji umożliwiającej planowanie i przeplanowywanie zadań testowych w zależności od oczekiwań developmentu bądź "biznesu". Z założenia jest to informacja szacunkowa. Nie wierzę w planowanie pracy członkom zespołu w godzinach.

Na początku potrzebne są pewne nakłady pracy ale dzięki temu uzyskujemy elastyczne narzędzie do planowania.

W komórce "B2" należy wpisać datę początkową. Ponieważ w moim wypadku datą przecięcia jest 1 stycznia to wpisuję jako datę początkową, poniedziałek ostatniego pełnego tygodnia grudnia - aby uzyskać pewien margines.
Następnie ciągnę komórkę aby uzyskać dzienne daty z całego roku. Korzystając z funkcji "DZIEN.TYG" oznaczam weekendy i dopisuję numery poszczególnych tygodni. Nie należy zapominać także o świętach. Jest to praca, którą rutynowo wykonuję na początku roku.

W pierwszej kolumnie wypisuję nazwiska osób. Można także wypisać środowiska testowe. Od tego momentu korzystam z elementów graficznych nazwanych "smartArt" ale równie dobrze mogą to być standardowe kształty. Przypisując zadanie do osoby ustawiam tak kształt aby jego początek zaczynał się pierwszego dnia aktywacji a koniec ostatniego. Następnie można skopiować kształt i ustawić go na środowisku także w odpowiednich ramach czasowych.

W przykładzie poniżej tego nie widać, ale ja używam czterech różnych kolorów na oznaczenia różnych klas aktywności. Wizualnie wyodrębniają mi one:
  • duże projekty
  • małe zadania wspierające dewelopment lub testy ad hoc
  • szkolenia i inne wydarzenia
  • urlopy

Arkusz monitorujący ludzi i zasoby w czasie

Ten arkusz wykorzystuję do celów komunikacyjnych w rozmowach z innymi osobami lub działami, planując przyszłe zadania, pokazując status bieżący czy po prostu przygotowując plan prac na nadchodzący tydzień.

Arkusz "Plan gry"

Ten arkusz służy mi do komunikacji z najbliższym otoczeniem. Przygotowuję tutaj listę zadań przypisanych do osób i wysyłam do zainteresowanych (głównie mój zespół, inni kierownicy oraz dyrekcja). Przydzielam także procentowo czas.  20% oznacza 1 dzień roboczy. Jest to wartość umowna pozwalająca przyjąć moim współpracownikom pewne założenia co do organizacji tygodnia pracy.


Pozycja "Urlopy/Święta" oraz "Zasoby" jest stała i pozwala mi alokować czas odpowiednio albo dla nieobecności albo dla zadań typu ad hoc (np. szybkie testy fixów). Staram się też regularnie przeznaczać pewien czas w tygodniu na aktywność nazywaną "wsparciem developmentu". Jest to rodzaj dyżuru. W ramach tej aktywności, przypisana osoba ma za zadanie obsługiwanie małych zadań testowych, których potrzebę doraźnie zgłasza development.

Ukrywając przemijające tygodnie jestem w stanie wysłać prostą tabelkę, pokazującą plan prac per osoba z obciążeniem. Pozwala też na dystrybucję informacji o dostępności poszczególnych ludzi.

Podsumowanie

Podejście przedstawione powyżej wypracowywałem w różnych wariantach przez parę lat. Dla obecnej organizacji i w obecnym trybie pracy wydaje się to wystarczające do realizacji potrzeby planowania, uzgadniania i kontrolowania przepływu pracy.

Dodatkowo, korzystając z mechanizmów automatyzujących (VBA) można użyć tego arkusza do bardziej wyrafinowanych celów. W moim przypadku najbardziej przydatne funkcje to:

  1. Automatyczne monitorowanie czasu
    Za każdym razem kiedy w arkuszu ewidencji projektów zmieniam status projektu, w odpowiednich komórkach skrypt VBA wpisuje datę tej zmiany. Pozwala to na zbieranie danych statystycznych pomocnych przy szacowaniu pracochłonności. Mając informację ile średnio zajmuje planowanie i wykonanie jestem w stanie dostarczać prawdziwych szacunków.
  2. Generowanie zadań w Outlooku
    Jeszcze do niedawna wykorzystywałem funkcjonalność Outlooka do przydzielania zadań do wykonania. Stworzyłem dodatkowy arkusz, w którym z przygotowywałem spis zadań dla każdego członka zespołu. Taką informację wysyłam do wszystkich zainteresowanych (development, produkcja, zarządzanie produktem).
    Następnie stworzyłem macro, które szczytuje wszystkie zadania razem z osobą odpowiedzialną. To samo macro odwołuje się do macra odpowiedzialnego za utworzenie obiektu zadanie w Outlooku. W ten sposób bardzo szybko jestem w stanie generować zadania dla zespołu.
  3. Synchronizowania listy aktywnych projektów pomiędzy arkuszem "Ewidencja projektów" a "Plan gry".
Główną wadą tego rozwiązania jest brak możliwości współdziałania grupowego. Jednak nie taki miał być zasadniczy cel i jak wspomniałem poszczególne zadania definiowane są w systemie zewnętrznym. Aby jednak umożliwić dostęp on-line zainteresowanym, wygospodarowałem w infrastrukturze firmy miejsce na wewnętrznym serwerze www i tam publikuję aktualną wersję tego pliku. Korzystam z wbudowanego mechanizmu, który przy każdym zapisaniu pliku publikuje mi jego wersję na serwer www.

Informacje o tym jak skorzystać z tego mechanizmu, można uzyskać w wbudowanym systemie pomocy, wyszukując frazę "Zapisywanie całości lub części skoroszytu w statycznej stronie sieci Web".