blog.testowka.pl

Podczas wytwarzania oprogramowania często mówi się o “Trójkącie Project Managera”, w którym to co chcemy osiągnąć umieszczam gdzieś pomiędzy: budżetem, scopem, a czasem i w zależności od którego z krańców trójkąta jesteśmy dalej tym więcej tego będziemy potrzebowali. W powyższym podejściu nie ma mowy o jakości, jak opisuje to Jurgen Appelo w swojej książce Management 3.0 organizacje mają tendencję do budowania łańcuszków zaufania także w tej dziedzinie – poruszając się w Trójkącie PM klienci zakładają, że to co dostaną będzie wysokiej jakości, managerowie zakładają, że zespół wie jak zbudować produkt wysokiej jakości i właśnie to robi, a zespoły developerów liczą na to, że przecież jeśli to co robią jest niewystarczającej jakość to w końcu ktoś da im jakąś informację zwrotną. Niestety rzeczywistość jest trochę bardziej bolesna – jakość (być może dlatego, że nie znajduje się ww. trójkącie i ciężko jest ja zmierzyć) jest najczęściej obcinanym elementem wytwarzanego systemu.

W przypadku zespołów samo-organizujących się (takich, które nie są bezpośrednio sterowane przez managerów i które mają określony cel i granice, w których mogą się poruszać) jeśli pokażemy trójkąt i powiemy, że naszym celem jest dostarczenie nowej wersji na konkretną datę to zespół z pewnością weźmie to za cel i za wszelką cenę będzie chciał dostarczyć produkt w określonym terminie. Orzez “wszelką cenę” mam na myśli głównie jakość, bo wszystko inne zostało już określone w trójkącie i zespół wie na co może sobie pozwolić.

Pomysłem na rozwiązanie tego problemu jest stosowanie Żelaznego Kwadratu Ograniczeń (Iron Square of Constraints) w poszczególnych rogach mamy: funkcjonalności (scope), czas, jakość, zasoby (budżet) i podobnie jak w przypadku trójkąta im bardziej oddalamy się od któregoś rogu tum większe straty ponosimy w zakresie w tym rogu zdefiniowanym.

Funkcjonalność                      Czas

——————————————-
|                                                        |
|                                                        |
|                                                        |
|                                                        |
|                                                        |
|                                                        |
|                                                        |
|                                                        |
——————————————-

Budżet                                       Jakość

Mam nadzieję, że mój ASCI Iron Square of Constraints jest widoczny

Oczywiście trójkąty i kwadraty to tylko pewien skrót myślowy, który pozwala na wizualizację tego co się dzieje w głowach ludzi pracujących nad produkcją oprogramowania.

Wdrożenie Agile w organizacji oznacza między innymi zapewnienie maksymalne transparentności. Czasem przejrzystość bywa nie na rękę niektórym osobom. O ile zrozumiałe są względy prawne czy ograniczenie dostępu do poufnych i czułych informacji to bezpodstawne wydają się być próby ograniczania dostępu do podstawowych narzędzi i zasobów. Bardzo często spotykam się z sytuacją, gdzie testerzy nie mają dostępu do kodu aplikacji – jak w takim razie mają na prawdę zrozumieć jej działanie, jak badać zależności, szacować ryzyko etc. Jak testerzy mają poszerzać swoją wiedzę na temat programowania i inżynierii nie wspominając już o wiedzy na temat aplikacji, gdy widzą tylko okrojoną warstwę interfejsu użytkownika.

Drugie pytanie dlaczego nie mają dostępu? Trudno mi nawet próbować zgadywać co jest przyczyną bo odpowiedzi które przychodzą mi do głowy są bliskie wielkiej torii konspiracji i zmowy wszechświata na temat tego, że Ziemia tak na prawdę jest sześcianem… Zyski z dostarczenia testerom kolejnych źródeł wiedzy są oczywiste i nie będę ich tutaj opisywał.

Wspomniany wcześniej problem zarządzania w organizacji często jest inicjatorem problemów czysto politycznych – bo jak to tak bez zarządcy niewolników? Przecież organizacja musi mieć swoją strukturę. Fakt – musi, ale to nie przeszkadza w tym by ta struktura istniała poza samo-organizującymi się zespołami i służyła wyłącznie do ogarnięcia kwestii formalnych i kadrowych. Agile i Scrum dostarczają pewnych struktur – mamy Product Ownera, który de facto jest managerem produktu, mamy Scrum Mastera który aby wykonywać swoje obowiązki i skutecznie usuwać przeszkody stojące na drodze zespołowi powinien mieć wystarczającą moc sprawczą i decyzyjną (nie zatracając się w iluzję władzy nad zespołem). Ciekawy, empiryczny opis roli managera w Agile przedstawił Andy Brandt na swoim blogu.

By Agile mogło działać sprawnie potrzebna jest współpraca na wszystkich szczeblach organizacji – wszyscy łącznie z kierownictwem powinni mieć wspólny jasno zdefiniowany cel i wizję tego co tworzą – tylko dzięki temu i przejrzystości działań, która ogólnie poprawia komunikację możliwe jest rozwinięcie najwyższej prędkości bez start jakości.

Tylko zapewnienie przejrzystej wizji produktu pozwala na uniknięcie wykonywania zbędnej pracy. Alberto Savoia w wykładzie otwierającym GTAC 2011 zatytułowanym “Test is dead” podsumował obecne zmagania zapewniania jakości oprogramowania w jednym zdaniu: “It’s no more about doing now it is about doing the right It” – programowanie jest kosztowne, a jedynym miejscem gdzie należy szukać oszczędności jest ilość tego co się programuje i eliminowanie ficzerów o małej wartości lub zupełnie zbędnych.

Użyłem słowa Polityka bo to właśnie z tym kojarzy mi się to co widzę często w organizacjach – problemy związane z komunikacją, dostępem do informacji, konfliktami interesów etc. Widziałem wiele prób zamykania zespołów w swoistych szklanych kulach, które chroniły ich od polityki – takie rozwiązania przeważnie działają, ale prędzej czy później coś się przez kulę przebija i wtedy zaczynają się problemy.

Powyższy post jest rozwinięciem kolejnej części prezentacji na temat przyczyn niepowodzeń wdrożeń Agile w organizacjach, którą od czasu do czasu wygłaszam przy różnych okazjach. Wkrótce pojawią się kolejne części opisujące kolejne problemy. Prezentacja oraz notka powstały na podstawie obserwacji moich i moich koleżanek i kolegów zajmujących się na co dzień wdrożeniami Agile, a także wielu godzin rozmów z różnymi ludźmi na tematy mniej lub bardziej związane z wdrożeniami Agile. Cały cykl możecie znaleźć tutaj.

Z zaszłości historycznych, a w niektórych krajach (w tym także w Polsce) również z powodu norm prawnych często wynika problem związany z brakiem zdefiniowanej struktury zarządzania w organizacjach wytwarzających oprogramowanie w sposób zwinny. Agile stawia na podstawowe wartości i równość każdego człowieka/członka zespołu. Iluzja posiadania władzy nad drugim człowiekiem jaką często mają managerowie w organizacjach kultywujących tradycyjne podejście do zarządzania prowadzi często do niepotrzebnych konfliktów i niezmiernie de-motywuje pracowników.

W Agile nie ma managerów, którzy mogli by komuś kazać coś robić. Zamiast zdalnego zarządzania poprzez ścisłą kontrolę w Agile stawia się na coachów i trenerów, których zadaniem jest pilnowanie przestrzegania zasad i usuwanie przeszkód stojących na drodze do efektywnej pracy developerów oraz przede wszystkim wspieranie każdego pracownika w ciągłym polepszaniu swoich umiejętności.

Osoby ściśle przywiązane do określonej struktury, w której do tej pory ktoś mówił im co mają robić (często także jak mają to zrobić i ile mają na to czasu) mają problem z tym, by samemu zorganizować swój czas i by pracować nad zwiększaniem swojej efektywności.

Kolejnym problemem wynikającym przeważnie z braku umiejętności budowania poczucia odpowiedzialności za produkt są próby obchodzenia ograniczeń dotyczących braku bezpośredniej “władzy” nad pracownikami i szukanie sposobności do stosowania metody kija i marchewki. W Agile nie skupiamy się na karaniu tych, którzy coś popsuli lub popełnili błąd, tylko na tym jak takich błędów uniknąć w przyszłości. Karanie, poza masochistyczną satysfakcją karzących nie wnosi żadnej wartości do produktu i projektu, a może jedynie obniżyć motywacje karanego i całego zespołu. Błędy są najwartościowszą lekcją i to właśnie na nich najszybciej i najwydajniej się uczymy.

Oczywiście jeśli nasz zespół ciągle popełnia błędy, które dużo nas kosztują powinniśmy poszukać przyczyn tego stanu rzeczy. Podstawą Agile są ludzie – właściwi ludzie, czasem po prostu okazuje się, że w naszym zespole takich nie ma. By działać zwinnie potrzebujemy odpowiedzialnego zespołu, który będzie w stanie sam rozwiązywać problemy i nie podda się przy pierwszej porażce. Niestety, niektórzy ludzie nie potrafią wziąć na siebie ciężaru odpowiedzialności i potrzebują ciągłej kontroli i zdalnego sterowania we wszystkim co robią.

No dobrze, ale przecież rzeczy nie dzieją się same. Czy na prawdę w Agile nie ma managerów? Tytuł powyższego postu miał być pewnego rodzaju prowokacją wynikającą głównie z błędnej interpretacji/tłumaczenia słowa manager.W naszej krajowej kulturze zwykło się nazywać managerami osoby zarządzające ludźmi, zarządzające procesem etc. W oryginale słowo manager nie musi odnosić się bezpośrednio do zarządzania i tak właśnie jest w Agile – manager w Agile to osoba, która sprawia, że rzeczy się dzieją – ustalone zasady są przestrzegane, spotkania odbywają się o czasie, konflikty są rozwiązywane, etc. Manager w Agile to taki trochę ninja, którego nie widać ale zawsze gdzieś tam jest i dba o to by proces działał sprawnie – istotne jest to, że to nie manager tworzy proces (bo robi to cały zespół – często wespół z managerem), ale to rolą managera jest dbanie o to by proces mógł być stosowany i by wszystko działo się płynnie i bez przeszkód.

“Jeśli jesteś managerem w Agile to nie istniejesz” – a może: “Jeśli jesteś managerem w Agile to twoje istnienie nie powinno być dostrzegalne”? Problemem jest to co opisałem powyżej – niektórym ciężko jest wyzbyć się iluzji władzy i możliwości kontroli drugiego człowieka, przez co stwarzane są różnego rodzaju niepotrzebne nikomu problemy i konflikty, w tym także konflikty interesów. Wszyscy mamy wspólny cel do którego dążymy więc nie potrzebujemy nikogo kto by nas batem poganiał – oczywiście, gdy nie ma celu…

Można być managerem nie zarządzając niczym i przede wszystkim nikim, można być managerem służąc innym, pomagając innym, rozwiązując problemy, sprawiając, że rzeczy się dzieją i wszystko przebiega sprawnie i bez przestojów – wcale nie potrzeba do tego “władzy”.

Powyższy post jest rozwinięciem kolejnej części prezentacji na temat przyczyn niepowodzeń wdrożeń Agile w organizacjach, którą od czasu do czasu wygłaszam przy różnych okazjach. Wkrótce pojawią się kolejne części opisujące kolejne problemy. Prezentacja oraz notka powstały na podstawie obserwacji moich i moich koleżanek i kolegów zajmujących się na co dzień wdrożeniami Agile, a także wielu godzin rozmów z różnymi ludźmi na tematy mniej lub bardziej związane z wdrożeniami Agile. Cały cykl możecie znaleźć tutaj.

Poprzednio pisałem o długu technologicznym. Skończyłem na tym, że dług technologiczny tak jak każde inne zadłużenie trzeba prędzej czy później spłacić.

W przypadku tego długu odsetki rosną dosyć szybko, więc wydawało by się, że ze spłatą nie należy zwlekać. Niemniej jednak czasem okazuje się, że pomimo wysokiego długu i rosnących odsetek nadal opłaca się dodawać nowe funkcjonalności i rozwijać system bez dbania o jakość – przeważnie wynika to z wysokiego popytu na oferowane przez nasz system usługi – jeśli popyt jest wystarczająco duży to nasi klienci są w stanie wybaczyć niską jakość, a inwestorów nie będzie ona wcale obchodziła póki da się jeszcze coś dodać do naszego systemu tak by koszty/czas wytwarzania tej funkcjonalności nie przewyższyły zysków.

Z czasem każda aplikacja/system wytwarzane w ten sposób osiągają pewną masę krytyczną, w której nawet najmniejsza zmiana może spowodować nieodwracalne straty. Wtedy właśnie inwestorzy decydują się na spłatę zaciągniętego długu technologicznego (lub sprzedają cały biznes komuś innemu, kto od teraz będzie musiał powyższe problemy samemu rozwiązać – taki ktoś przeważnie zacznie od zatrudnienia sztabów QAów).

Nie zrozumcie mnie źle – nie krytykuję startupów za to, że pierwsze ich wersje były kaszaną programistyczną – wręcz przeciwnie, z perspektywy biznesowej takie rozwiązania są wręcz genialne – tworzymy niskim kosztem coś co zaczyna zarabiać – lub nie – i właśnie jeśli okaże się, że nasza idea nie chwyciła i nie zaczyna zarabiać to tracimy znacznie mniej, niż gdybyśmy od początku inwestowali w wysoką jakość. A jeśli nasz pomysł okaże się strzałem w dziesiątkę i zacznie zarabiać pokaźne sumy to przestają nas obchodzić koszty jakości i możemy sobie pozwolić nawet na przepisanie całego systemu od nowa, czy podwojenie liczby zatrudnionych developerów.

“Naturalną” drogą obieraną przez wiele firm podczas zaciągania długu technologicznego jest zatrudnianie coraz większej ilości programistów, których ilość ma rekompensować spadek prędkości rozwijania aplikacji. Niestety samo zwiększenie liczby pracowników nie spowoduje spłaty zaciągniętego długu, mało tego często brak dodatkowych starań w kierunku zapewniania jakości i odpowiedniej presji w tym kierunku może spowodować jeszcze większy wzrost zadłużenia – więcej osób oznacza więcej kodu słabej jakości czyli szybszy przyrost zadłużenia.

Jeśli przez długi czas żyło się na kredyt to aby spłacić zadłużenie trzeba czasem zacisnąć pasa – spłacanie długu spowoduje drastyczne spowolnienie rozwoju naszego biznesu. Wynika to z tego, że teraz dostępne zasoby będziemy przeznaczać na poprawę jakości zamiast na rozwijanie nowych ficzerów. “Poprawa jakości” czegoś co nigdy znamion tejże jakości nie nosiło często oznacza napisanie tego od nowa. Przepisywanie funkcjonalności od nowa nie jest proste. By dobrze to zrobić należy najpierw dokładnie zdefiniować to co napisana wcześniej funkcjonalność tak naprawdę miała robić, jakie były co do niej wymagania i założenia – w przypadku braku dbania o jakość o jakiejkolwiek dokumentacji wymagań przeważnie można tylko pomarzyć.

Jednym ze sposobów na rozwiązanie tego problemów jest pisanie testów funkcjonalnych typu “black box” – tworzymy testy automatyczne, które traktują daną funkcjonalność jak czarną skrzynkę – podają wartości wejściowe i sprawdzają stan na wyjściu nie wnikając w to co dzieje się w środku. Takie testy piszemy na starym systemie (przed przepisaniem) traktując go jak wyrocznie testową – zakładamy, że system działa poprawnie i zwraca prawidłowe wartości – wyrocznia prawdę ci powie. Po napisaniu tego typu testów i maksymalnym pokryciu nimi przepisywanej funkcjonalności możemy przystąpić do przepisywanie czy refaktoryzacji tejże funkcjonalności nie martwiąc się o to, że coś zepsujemy. Oczywiście jest to dosyć naiwne stwierdzenie. Niemniej jednak jest to jedno z najbardziej optymalnych rozwiązań w przypadku wcześniejszego braku jakichkolwiek testów automatycznych czy dokumentacji wymagań. Należy także pamiętać o tym by pisząc nową funkcjonalność od razu zapewniać jej wysoką jakość stosując dobre praktyki programistyczne takie jak np. TDD.

Nawet jeśli uda się uniknąć przepisywania całej aplikacji to koszty “wdrażania jakości” są wielokrotnie wyższe niż gdyby od początku tworzono software wysokiej jakości, co nie oznacza, że w skrajnych przypadkach jest to nawet bardziej opłacalne.

Ciarki przechodzą mi po plecach gdy czytam na różnego typu forach, tudzież goldenline i linkedin posty z pytaniami typu: “Jak estymować testowanie w Agile?”, “Jak raportować postępy testów w Agile?”, “Jak dokumentować testy w Agile?”, “Jak organizować pracę zespołu testowego w Scrum?”, “Jak przeprowadzać, planować testy wydajności w Agile?”. Jako, że staram się być pragmatyczny (a w tym przypadku po prostu nie chce mi się odpisywać za każdym razem na wszystkie posty tego typu) postanowiłem odpowiedzieć, a przynajmniej spróbować odpowiedzieć na powyższe pytania tutaj.

Jak estymować testy w Agile?
Testy i testowanie czy to automatyczne czy manualne są integralną częścią procesu developmentu i jako takowa część powinny być estymowane razem z innymi zadaniami developerskimi typu analiza i estymacja. Na przykład gdy estymujemy Itemy (User Stories) w Scrumie to szacujemy estymaty dla całego itemu (chyba, że jest zbyt duży – wtedy dzielimy na mniejsze), zawierając w naszej estymacie trudność wykonania zadania jako całości, czyli zawieramy w tym analizę, implementację, a także testy. Dopiero podczas drugiej części Sprint Planningu (bardziej szczegółowej) rozbijamy Itemy na poszczególne taski, gdzie jednym z zadań może być przetestowanie User Story lub napisanie testów automatycznych. Niemniej jednak należy uważać na to by nie popaść w mini-waterfall w każdym itemie – żeby lista tasków nie wyglądała w ten sposób: 1. analiza, 2. implementacja, 3. testy. Ciężko jest mówić o czymś takim jak “proces testowy” w Agile, dlatego nie można mówić o estymacji testów.

Jak raportować postępy testów w Agile?
Zwinne metodyki wytwarzania oprogramowania stawiają na szeroko rozbudowaną automatyzację. Najlepszym raportem z testów automatycznych (chociaż niekoniecznie doskonałym) jest raport z pokrycia kodu testami (code coverage). Zgodnie z zasadami Definition of Done każde zreleasowane zadanie musi przejść testy, więc raportem z testów jest sam fakt ukończenia zadania.

Jak dokumentować testy w Agile?
Jak wyżej – stawiamy na automatyzację, automatyczne skrypty testowe same w sobie stanowią specyficzną dokumentację do kodu aplikacji. Jeśli natomiast dodamy do tego elementy BDD z wykorzystaniem odpowiednich narzędzi służących do pisania wykonywalnych scenariuszy użycia mamy od razu wykonywalną dokumentację testową wraz z testami. Raporty tworzą się oczywiście automatycznie. W Agile jednym z kluczowych elementów jest zaufanie, jeśli powierzamy komuś zadanie to dlatego, że ufamy, iż wykona to zadanie dobrze (najlepiej jak potrafi), z tego założenia wnioskujemy, że dokumentacja przebiegu testów nie jest potrzebna. Aby to zrozumieć warto się zastanowić po co dokumentujemy testy – ja widzę dwa główne powody:
1. zapewnienie powtarzalności,
2. zapewnienie możliwości sprawdzenia czy testy zostały wykonane dobrze, zgodnie z wymaganiami, ile i jakie wymagania zostały przetestowane,
Ad 1. Jeśli potrzebujemy powtarzalności to automatyzujemy testy i powtarzalność jest zapewniona, nie wspominając o innych korzyściach.
Ad 2. Jeśli ufamy testerowi to nie potrzebujemy weryfikować jego pracy, pokrycie wymagań testami możemy sprawdzić przeglądając testy automatyczne. Dokumentacja testów jest między innymi po to by oceniać pracę testera, w Agile skupiamy się na celu i efekcie końcowym, jeśli aplikacja działa dobrze i spełnia wymagania biznesowe, a błędy nie pojawiają się na produkcji to znaczy, że nie tylko testerzy ale cały zespół spisał się dobrze, jeśli natomiast na produkcja pojawiają się błędy to wina leży po stronie całego zespołu a nie tylko testera.

Jak organizować pracę zespołu testowego w Scrum?
Przepraszam czego? W Scrum nie ma takiej roli jak “Tester” – jest natomiast Developer. Przez “Developerów” mamy na myśli wszystkie osoby dodające do naszego projektu jakąś wartość. Widziałem próby organizacji pracy zespołów testerskich za pomocą Scrum – ale proszę nie nazywajmy tego Scrum. To, że testerzy spotykają się co rano i odpowiadają na trzy pytania, że mają jedną osobę wyznaczoną do usuwania impedimentów, że pracują w iteracjach wcale nie oznacza, że jest to Scrum. W Scrum nie ma zespołów programistów i zespołów testerskich jest jeden Scrum Team w skład którego mogą wchodzić developerzy o różnych umiejętnościach w tym także umiejętnościach testerskich, zespoły tego typu powinny być interdyscyplinarne. 

Jak planować i przeprowadzać testy wydajności w Agile?
Odpowiednia wydajność jest (powinna być) jednym z kryteriów akceptacji dla poszczególnych itemów czy całych projektów. Powinna się także znaleźć w Definition of Done. Testy wydajnościowe a także inne testy niefunkcjonalne to także integralna część developmentu, więc powinny być wykonywane zawsze wtedy, gdy są potrzebne. Skupiamy się na celu, a dzięki krótkim iteracjom i rozbijaniu zadań na jak najmniejsze możemy bardzo często mierzyć zmiany wydajności (oczywiście w sposób zautomatyzowany) i reagować, gdy tylko zauważymy jej spadek, poprawiając błędy znacznie niższym kosztem niż gdybyśmy testowali wydajność na samym końcu.

Rozumiem, że niektórym (z moich obserwacji wynika, że przerażającej większości, ale to tylko moje obserwacje) trudno jest się przestawić z tradycyjnego myślenia obciążonego procedurami na myślenie zwinne pozbawione ograniczających procedur i oparte na prostych regułach, które nie tylko pozwalają, ale nawet często zmuszają do myślenia “out of the box”, do wykroczenia poza schematy i skupienia się czasem na tym co tak właściwie jest naszym celem. Nie da się ukryć, że “myślenie zwinne” różni się od tradycyjnego, oprócz samego nastawienia na cel ważnych jest kilka innych czynników – chociażby takich jak wspomniane zaufanie, umiejętność współpracy w zespole i pomiędzy zespołami (tak, Agile i Scrum się skalują i czasem mamy więcej niż jeden zespół!). To prawda, że Scrum jest megaprosty, że można opanować jego zasady w kilka godzin, niemniej jednak opanowanie zasad Scrum nie oznacza, że w Scrumie potrafimy pracować, że potrafimy się w nim odnaleźć. Aby być zwinnym potrzebna jest nam praktyka i dobrzy nauczyciele, potrzeba też teorii, ale przede wszystkim musimy być otwarci na zupełnie nowe, czasami dosyć abstrakcyjne spojrzenie na wytwarzanie oprogramowania.

Jeśli macie więcej pytań podobnych do powyższych piszcie, a postaram się znaleźć na nie odpowiedź (jakąś odpowiedź, bo nie na wszystkie pytania da się odpowiedzieć dobrze).

Od ponad roku oprócz działalności testerskiej zajmuję się także między innymi szkoleniami z zakresu testowania oprogramowania i zarządzania projektami według zwinnych metodyk zarządzania. Jako że staram się być pragmatyczny we wszystkim co robię to także proces przygotowywania szkoleń staram się jak najbardziej zoptymalizować stosując do tego celu różne narzędzia.

Kanban board dla szkolenia "Zapewnianie jakości w projektach Agile"

Szkolenie można potraktować jako projekt dlatego też uważam, iż do zarządzania takim projektem można śmiało zastosować narzędzia stosowane do zarządzania projektami innego rodzaju – także projektami IT. Po wielu próbach i analizach doszedłem do wniosku, iż idealnie w moim przypadku sprawdza się Kanban, a właściwie tablica kanbanowa, która idealnie wizualizuje postępy prac. Moja standardowa tablica składa się z siedmiu kolumn:

Backlog: Tutaj zbieram swoje pomysły na zagadnienia, które chciałbym omówić podczas szkolenia. Zasadniczo (trochę wbrew zasadom kanbana) nie przejmuje się kolejnością zadań – w zależności od natchnienia i humoru wybieram zadania, nad którymi akurat mam ochotę popracować.

Mindmapa do szkolenia "Zapewnianie jakości w Agile"

Analiza: Tutaj pojawiają się zadania nad którymi aktualnie pracuje. Sposób analizy poszczególnych zagadnień zależy w dużej mierze od samych zagadnień, niemniej jednak w moim przypadku najpierw rozpoczynam od zbierania materiałów na dany temat, następnie analizuje zebrane materiały wybierając najważniejsze i najbardziej wartościowe informacje (w końcu czas szkolenia jest ograniczony), po czym jeszcze raz weryfikuje wszystko czy pasuje do ogólnej tematyki szkolenia. Do analizy używam mindmap na których opracowuje materiały – dzięki temu cały czas mam obraz całości szkolenia i unikam zbędnych duplikacji. W efekcie dostaje obraz całego szkolenia, który bardzo łatwo zweryfikować i ogarnąć. Przygotowanie prezentacji na podstawie takiej mindmapy to już w zasadzie formalność. W kolumnie “Analiza” na mojej tablicy kanbanowej przeważnie stosuje limit maksymalnie 2 zadań wykonywanych równolegle – pozwala to na uniknięcie niepotrzebnego rozproszenia, a jednocześnie jeśli jedno zagadnienie zbytnio mnie zmęczy to dzięki temu, iż limit wynosi dwa a nie jeden mogę rozpocząć pracę nad innym zadaniem a do tego wrócić później. Narzuca to pewną dyscyplinę nie zabierając jednocześnie swobody i nie psując całej zabawy jaką jest przygotowywanie szkolenia.

Kolejną kolumną na tablicy jest kolumna Przeanalizowane jest to swego rodzaju backlog dla prezentacji. Tutaj znajdują się zagadnienia dla których opracowałem już mindmapy i które czekają tylko na przetworzenie informacji na prezentację. Tutaj także stosuje limity (przeważnie od 5 do 10) po to by uniknąć przygotowywania wszystkich slajdów nie zostawiać na sam koniec, dzięki temu mam zachowaną pewną płynność i cały czas wzrasta wartość dodana w moim projekcie – mierzona ilością slajdów.

Prezentacja - tutaj znajdują się zagadnienia dla których właśnie opracowuje slajdy. Podobnie jak w przypadku analizy tutaj też stosuje limity – powody takie same jak powyżej.

Do weryfikacji to kolumna, w której znajdują się w pełni opracowane zadania wraz z utworzonymi slajdami czekające na ostateczną weryfikację. Nie stosuje tutaj limitów, gdyż najbardziej efektywne okazało się weryfikowanie wszystkiego na samym końcu, gdy mam już pełny obraz całości szkolenia.

Weryfikacja, jak sama nazwa wskazuje w tej kolumnie pojawiają się zagadnienia, które są aktualnie weryfikowane. Narzuciłem sobie limit weryfikowanych zadań równy jeden, gdyż weryfikacja wymaga dużego skupienia i zwracania uwagi na wszystkie szczegóły. Weryfikacja polega na sprawdzeniu poprawności merytorycznej, wyłapaniu błędów i literówek, oraz ogólnym przejrzeniu materiałów. Często też podczas weryfikacji a także analizy zdarza mi się pytać o opinię koleżanki i kolegów po fachu.

Done - tę kolumnę lubię najbardziej, zwiększająca się tutaj ilość zagadnień daje mi największą satysfakcję i jest najlepszą miarą postępów w pracy nad przygotowywaniem szkolenia. Dzięki przejściu przez wszystkie poprzednie etapy/kolumny każde zagadnienie spełnia swoistą “definition of done”, która wygląda mniej więcej tak: Każde zagadnienie zostało zaplanowane i przeanalizowane, następnie zostały utworzone slajdy oraz nastąpiła ostateczna weryfikacja merytoryczna oraz weryfikacja pod kątem bezbłędności materiałów.

Dzięki powyższemu procesowi mam pewność, iż prezentowane przeze mnie materiały są w pełni wartościowe i nie zawierają błędów. Niemniej jednak na tym  nie kończy się cykl życia moich szkoleń. Pozostaje jeszcze ich prezentacja oraz ciągły rozwój i udoskonalanie.

Gdy rozpoczynałem swoją przygodę ze szkoleniami miałem okazję porozmawiać na ten temat z jednym z weteranów prowadzenia szkoleń w naszym kraju, zwrócił on moją uwagę na pułapkę monotonii. Pomimo tego, iż samo prowadzenie i przygotowywanie szkoleń jest bardzo ciekawe to z czasem znużenie podczas prezentowania po raz n-ty tych samych materiałów dotyka każdego, nawet najlepszego trenera. Mając na uwadze rady starszego kolegi (któremu z tego miejsca dziękuję) staram się takiej monotonii unikać, dlatego też moje szkolenia żyją własnym życiem i cały czas się rozwijają.

Nawiązując do zwinnych metodyk zarządzania projektami których jestem pasjonatem i które często są tematem moich szkoleń staram się prowadzić szkolenia mając na uwadze jedną z kluczowych zasad Agile – informację zwrotną. Gdy sam uczestniczyłem w różnego rodzaju szkoleniach zauważyłem pewne podobieństwo większości szkoleń do projektów informatycznych prowadzonych według klasycznych metodyk zarządzania opartych o waterfal. Przeważnie prowadzący szkolenie dostawał informacje zwrotną dopiero na sam koniec szkolenia, gdy uczestnicy wypełniali ankiety i oceniali szkolenie – podobnie jak w projektach informatycznych w modelu kaskadowym testy dające informacje zwrotną na temat tego czy aplikacja działa przeprowadzane są na końcu. Taka informacja owszem jest bardzo wartościowa, ale niestety prowadzący dostaje ją po fakcie i może co najwyżej udoskonalić następne szkolenia, niestety niezadowolenie czy też niedosyt uczestników obecnego szkolenia pozostaje.

Zastanawiając się nad tym jak efektywniej prowadzić szkolenia doszedłem do wniosku, iż podobnie jak w projektach informatycznych najważniejsze jest zdanie i wymagania klienta. Klientem dla moich szkoleń są ich uczestnicy, wiec szukałem sposobu, który podobnie jak Agile pozwala klientowi na sterowanie pracami na projektem informatycznym, pozwoli moim klientom sterować szkoleniem. Obecnie stosuje dwa artefakty zaczerpnięte z -Agile/Scrum – spotkania typu stand-up oraz retrospekcje.

Retrospekcja podczas szkolenia.

Mniej więcej co 3 godziny robię spotkanie stand-up na którym każdy z uczestników odpowiada na trzy pytania:
- Co ciekawego dowiedziałem się od ostatniego spotkania?
- Co było nudne i nużące, czego powinniśmy unikać na przyszłość?
- Czy było coś czego nie zrozumiałem/zrozumiałam i chciałbym/chciałabym aby zostało wyjaśnione dokładniej?
Dzięki odpowiedziom na powyższe pytania od razu dostaję informację zwrotną na temat tego co należy poprawić i co omówić dokładniej. Ponadto odpowiedzi na pierwsze pytanie nie są bezpośrednio dla mnie, lecz raczej podobnie jak spotkania stand-up w projektach informatycznych mają za zadanie wspierać wymianę informacji pomiędzy uczestnikami szkolenia – jest to pewnego rodzaju podsumowanie wiedzy, którą uczestnicy szkolenia zdobywają w jego trakcie.

Na zakończenie każdego dnia szkolenia przeprowadzamy retrospekcję podczas której na osi czasu, każdy uczestnik szkolenia zaznacza wydarzenia, które według niego miały wpływ na całkowity obraz szkolenia. Wbrew pozorom w ciągu jednego dnia może wydarzyć się bardzo dużo – na przykład na jednym z ostatnich szkoleń właśnie dzięki retrospekcjom uzyskałem bardzo trafną informacje na temat tego z jaką częstotliwością powinniśmy robić przerwy kawowe, czy też sugestię, że po każdej większej partii materiału powinienem zrobić jeszcze małe podsumowanie i utrwalenie wiedzy, a także jakich informacji było podczas szkolenia za mało. Ostatniego dnia szkolenia retrospekcje przeprowadzam przeważnie około 2 godziny przed planowanym czasem zakończenia szkolenia, dzięki temu mam jeszcze czas na wprowadzenie ostatnich poprawek i zadowolenie moich klientów.

Powyższa metoda jest cały czas w fazie rozwoju, jak na razie wszystko się sprawdza i uczestnicy są zadowoleni (ostatnia średnia ocena po szkoleniu była powyżej 4,7). Jeśli macie jakieś propozycje jak jeszcze mógłbym udoskonalić swoją pracę piszcie, będę wdzięczny za jakąkolwiek informację zwrotną!

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.

Złapałem się na tym, że ostatnimi czasy piszę głównie o zarządzaniu projektami, agile, procesach wytwarzania oprogramowania itp., a coraz mniej skupiam się na testowaniu. W podtytule tego bloga jak zapewne zauważyliście jasno jest napisane: “Blog o jakości oprogramowania”. Gdzie ta jakość?

Odpowiedź jest prosta – wszędzie. To, że skupiam się głównie na procesach wytwarzania oprogramowania, zarządzania tymże wytwarzaniem oprogramowania oraz aspektach bardziej miękkich z tym związanych wynika z tego, iż doszedłem do wniosku, że szukanie bugów jest bez sensu. Tak! (Jak ja lubię strzelać sobie zawodowego samobója – najpierw, że testerzy są niepotrzebni, teraz, że szukanie błędów jest bez sensu…). Testowanie oprogramowania nie tworzy żadnej wymiernej wartości w projektach informatycznych, wynika to między innymi z tego, że jakości samej w sobie nie da się zmierzyć – często ciężko jest nawet zdefiniować jakość. Znalezione błędy muszą być poprawione – i przeważnie zostają poprawione, po czym powinny zostać sprawdzone i dopiero wtedy produkt może ujrzeć światło dzienne, ot i cała filozofia.

Błędy kosztują – wszyscy doskonale o tym wiedzą, ale większość komentarzy skupia się na kosztach błędów, które nie zostały wykryte. Warto czasem spojrzeć na temat z drugiej strony – znalezione błędy też kosztuję. Każdy znaleziony błąd wymaga opisania, zgłoszenia, debugownia, poprawienia oraz ponownego sprawdzenia, do tego dochodzą jeszcze inne zróżnicowane w zależności od projektu i innych czynników czynności takie jak oczekiwanie na zbudowanie nowej paczki czy mergowanie zmian. To wszystko zajmuje pewną ilość czasu, a jak powszechnie wiadomo czas to pieniądz.

Skoro już wiemy, że znalezione błędy też kosztują i wiemy ile kosztują to zastanówmy się co zrobić by zmniejszyć koszty. Najprostsze rozwiązanie – nie popełniać błędów. Istnieje wiele teorii na temat tego skąd biorą się błędy, większość z nich ma wspólne elementy takie jak np. “to człowiek jest źródłem błędów”, “niepełne wymagania powodują błędy”, “ograniczona wiedza i możliwości technologiczne zwiększają prawdopodobieństwo powstawania wad”, “coraz większe skomplikowanie projektów powoduje wzrost prawdopodobieństwa pojawienia się błędów, wynikający z większej ilości możliwych scenariuszy użycia” itd.. Próbując znaleźć najprostsze rozwiązanie dochodzę, do wniosku, iż kluczem do osiągnięcia sukcesu w tym przypadku jest skupienie się na procesie i zarządzaniu tymże procesem. Zapobieganie błędom jest dużo tańsze niż ich wykrywanie i poprawianie – nie wspomnę już nawet o tym, że jeszcze droższe jest nie znalezienie błędów i ich niepoprawienie.

Dlatego właśnie ostatnio moje myśli i poszukiwania skupiają się wokół zarządzania projektami i zapewniania jakość a nie weryfikacji jakości jaką jest testowanie oprogramowania samo w sobie.

Mam to szczęście (a może właśnie pecha), że podczas swojej stosunkowo krótkiej (kilka lat) “kariery” w IT, miałem okazje pracować z kilkoma bardzo różnymi zespołami i uczestniczyć w wielu bardzo zróżnicowanych projektach dzięki czemu mam spory zasób doświadczeń na podstawie których mogę wyciągać trafne (czytaj: “sprawdzające się w praktyce”) wnioski.

Jeśli zadbamy o jakość od samego początku i każdy z członków zespołu (a także klient, zarząd etc.) będzie zaangażowany w zapewnianie jakości to możemy być pewni, iż ta inwestycja się nam zwróci.

Zapytacie pewnie o liczby, dane, w jaki sposób mogę zagwarantować, że tak właśnie jest? Nie mogę niczego zagwarantować – nie da się tego zbadać doświadczalnie, nie można zmierzyć ile pieniędzy czy czasu zaoszczędziliśmy dzięki podejściu skupiającemu się na jakości. Musicie mi uwierzyć na słowo – to działa. Zresztą nie tylko ja tak uważam. Jak pogooglujecie, poczytacie książki na temat testowania oprogramowania, zarządzania projektami etc. sami prędzej czy później dojdziecie do podobnych wniosków.

W jaki sposób dbać o jakość? Odpowiedzi są na wyciągnięcie ręki – czytajcie tego bloga, a także szukajcie innych. Ludzie i ich doświadczenia to najlepsze źródła wiedzy. Dzielcie się swoją wiedzą i przemyśleniami po to by je zweryfikować i skonfrontować z przemyśleniami innych. Na prawdę warto!

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.

Bardzo często na wszelkiego rodzaju szkoleniach z metodyk i zarządzania projektami mówi się o tak zwanych wąskich gardłach, niestety bardzo rzadko ktokolwiek wspomina o tym co należy zrobić, gdy takie wąskie gardło już znajdziemy.
Żeby lepiej ugryźć ten temat przeanalizujmy potencjalny sposób przyspieszenia prac w projekcie – próba zwiększenia efektywności na każdym z etapów wytwarzania oprogramowania. Wielu managerów skupia się na tym by poszczególne zespoły, członkowie zespołów zwiększały swoją efektywność przez co dążą do zwiększenie efektywności całkowitej pracy nad projektem. Jeśli praca na wszystkich etapach przebiega równomiernie (nie mamy istotnych wąskich gardeł) zwiększenie wydajności w każdym etapie spowoduje zasadnicze przyspieszenie prac w całym projekcie. Niestety wystarczy już jedno wąskie gardło by pomimo zwiększenia efektywności na wszystkich innych etapach skutecznie spowolnić pracę w całym projekcie (zakładając względnie równomierny wzrost efektywności na każdym etapie, zwiększenie efektywności na etapie będącym wąskim gardłem niczego nie zmieni, gdyż nadal będzie to wąskie gardło).

Zastanówmy się może skąd się biorą wąskie gardła. Najczęstszą przyczyną powstawania wąskich gardeł jest niedobór zasobów (pracowników, technologi, wiedzy) na jednym z etapów projektu i/lub nadmiar w innych częściach zespołu/projektu. Niektóre zadania po prostu wymagają znacznie więcej czasu niż inne – np. wymyślenie i zaimplementowanie skomplikowanego algorytmu szyfrującego jest trudniejsze i bardziej czasochłonne niż zdefiniowanie wymagań dla takiego algorytmu.

Istnieje wiele różnych sposobów wykrywania wąskich gardeł, jednym z nich jest np. tablica kanbanowa z wprowadzonymi limitami zadań znajdujących się w poszczególnych fazach produkcji. Różne inne sposoby monitoringu, nadzoru pracy, monitorowania postępów, mierzenia czasu pracy etc. także bywają pomocne przy lokalizowaniu wąskich gardeł.

Dobrze dajmy na to, że już znaleźliśmy wąskiego gardło:
Załóżmy że mamy zespół składający się z 4 programistów i jednego testera. Zastosowaliśmy tablicę kanbanową z limitami odpowiedni 4 zadania w develompencie i 1 zadanie w fazie testowania w tym samym czasie (przydział naturalny – badania pokazują, że ludzie są najefektywniejsi gdy pracują nad jednym zadaniem – jednowątkowo). Okazuje się, że programiści (jako zespół) znacznie szybciej kończą swoje zadania niż tester jest w stanie je przetestować. Średnio czas zaprogramowania funkcjonalności okazał się dwukrotnie dłuższy niż czas jej przetestowania co w efekcie spowodowało, że tester miał dwa razy więcej zadań niż mógł przetestować.
Pobawmy się w dosyć śmieszną pseudo matematykę, żeby lepiej zobrazować problem.

Na tym etapie dokonano pewnych zmian, które miały na celu zwiększyć wydajność pracy każdego z członków zespołu o 50% – wdrożenie się udało. Zobaczmy więc jak wygląda sytuacja po zwiększeniu efektywności. Dzięki temu rozwiązaniu teraz tester mógł przetestować trzy zadania w tym samym czasie co wcześniej dwa, niestety tym samym programiści byli w stanie dostarczyć o połowę więcej zadań do testów niż poprzednio przez co wąskie gardło nadal pozostało wąskim gardłem.

Poszukajmy więc alternatyw…
Niestety mamy ograniczony budżet i nie możemy pozwolić sobie na zatrudnienie większej liczby osób.
Widzimy, że mamy za dużo programistów a za mało testerów, może więc powinniśmy jednego z programistów w razie potrzeby wykorzystywać jako testera, chwilowo zmniejszy to ilość dostarczanych funkcjonalności i tym samym pozwoli na przyspieszenie etapu testowania – wąskie gardło będzie odrobinę szybsze, może nawet całkowicie zniknie – super – udało się. Ale zaraz, teraz jeden z programistów stał się testerem – coś tu jest nie tak – przecież płacimy temu gościowi za programowanie a nie za testowanie, on sam pewnie też to dosyć szybko zauważy i zapewne jego morale spadną, a w rezultacie może nawet zmieni pracę bo nikt nie chcę pracować dla pracodawcy, który nie wywiązuje się z zawartych umów, a w jego umowie jasno było napisane, że jest programistą a nie testerem. (evil: A niech się zwalnia – w jego miejsce zatrudnimy testera
Kolejnym sposobem na zlikwidowanie wąskiego gardła mogło by być spowolnienie pracy programistów. TAK – SPOWOLNIENIE! Ale jak to?! Przecież w zarządzaniu chodzi o zwiększanie efektywności, przyspieszanie, dostarczanie produktu na czas etc. Otóż nie zawsze, efektywność okazuje się być bez znaczenia w miejscach nie będących wąskim gardłem [Cockburn 2008]. Jeśli już mamy wąskie gardła, to zwiększenie efektywności w innych miejscach w niczym nam nie pomoże, wręcz przeciwnie może spowodować jeszcze większe straty np. wzrost frustracji testerów spowodowany nadmiarem zadań i nierealnymi terminami, konflikty pomiędzy testerami a resztą zespołu spowodowane naciskami ze strony tych drugich na szybsze wykonywanie zadań testerskich, mniejsza dokładność testów w celu przetestowania większej ilości funkcjonalności itd.

Co zatem należy zrobić?
Jeśli mamy już sytuację jak opisaną powyżej to warto zastanowić się nad tym dlaczego praca testerów zajmuje tyle czasu i co zrobić by ją przyspieszyć. Żeby przeanalizować ten problem trzeba by sięgnąć do korzeni – po co jest testowanie? Testowanie służy odnalezieniu błędów. Dlaczego testujemy? Testujemy, gdyż zakładamy że dostarczona funkcjonalność zawiera błędy. Z powyższej toku myślowego wynika, że jednym ze sposobów rozwiązania problemu wąskiego gardła z powyższego przykładu mogło by być dostarczanie do testów funkcjonalności o wyższej jakości. Jak to zrobić? Sposobów jest wiele – począwszy od dbania o jakość od samego początku np. poprzez zastosowanie TDD co także zwiększy pokrycie kodu testami automatycznymi dzięki czemu zmniejszy się czas testów regresyjnych, skończywszy na poświęceniu większej uwagi planowaniu i zrozumieniu wymagań przez programistów, czy też zastosowanie wielu innych dobrych praktyk programistycznych takich jak na przykład Code Review. Zastosowanie któregoś z powyższych rozwiązań niesie ze sobą podwójne korzyści: programiści muszą poświęcić więcej czasu na pisanie testów, planowanie, analizę, dzięki czemu wąskie gardło testerskie nie zapycha się, a także wzrasta jakość kodu i funkcjonalności, przez co zmniejsza się ilość poprawek i re-testów, dzięki czemu tester ma więcej czasu. Kolejnym bardzo ważnym aspektem takiego rozwiązania jest także wzrost zaufania testerów do produktów dostarczanych przez programistów (czasem bywa to zgubne, niemniej jednak w większości przypadków skutkuje polepszeniem atmosfery, lepszą komunikacją i ostatecznie większą ilością sukcesów).

Powyższy opis problemu i propozycja jego rozwiązania dotyczyły wąskiego gardła na etapie testowania, ale zasada jest dosyć ogólna – nie należy zwiększać efektywności w miejscach które nie są wąskimi gardłami (może to np. dotyczyć sytuacji gdy 7 programistów okupuje jednego DBA – wtedy też należy programistów zmusić do przeprowadzania analizy problemów po ich stronie, a do DBA kierowania tylko próśb o podjęcie ostatecznych decyzji w rozpracowanych wcześniej problemach, lub próśb o pomoc w sytuacjach krytycznych). Oczywiście jeśli nie ma wąskich gardeł, lub wszystkie zlikwidowaliśmy możemy dalej pracować nad równomiernym wzrostem efektywności pamiętając o tym by nie stworzyć kolejnych newralgicznych punktów w naszym procesie.

Warto też pamiętać o wąskich gardłach przy budowaniu budżetu projektu, czy też zatrudnianiu nowych pracowników.

Jakiś czas temu skontaktował się ze mną Krystian Kaczor z ciekawą propozycją – wymiany postami na naszych blogach. Po wstępnej analizie tego co Krysitan ma u siebie na blogu doszedłem do wniosku, że w wielu aspektach dotyczących zarządzania projektami oraz testowania mamy bardzo podobne zdanie więc nie pozostało mi nic innego jak tylko zgodzić się na propozycję Krystiana. Efekt poniżej.

Gra w golfa a Scrum

Tytuł tego artykułu przyciągnął Twoją uwagę i obiecuję, że się nie rozczarujesz. Najpierw zarysuje krótki wstęp, a potem dowiesz się ile ogólnych zasad takich jak te z gry w golfa możesz zastosować na swoim projekcie. Proszę o chwilkę cierpliwości.

Wprowadzenie

Kolega z zespołu zaczął grać w golfa. Niespodziewanie okazuje się, że to przestał być drogi sport i nie potrzeba być członkiem klubu. Oczywiście do golfa trzeba mieć partnera, więc kolega zaczął namawiać mnie do towarzyszenia w jego ćwiczeniach. Okazało się, że uderzenie piłki wcale nie jest takie łatwe, a kontrola jej lotu to już wyższy poziom wtajemniczenia. Często rozmawiamy na ten temat i ostatnio zaskoczyły mnie dwie wskazówki przekazane przez jednego z trenerów.

2 uniwersalne wskazówki, które wykorzystasz w Scrum

• “Nie skupiaj się na piłce, tylko na uderzeniu (tzw. swing). Piłka jest tylko wskaźnikiem. Piłka Ci pokaże jak na prawdę uderzyłeś.”
• “Gdybyś nie widział przeszkody wodnej, posłałbyś piłkę dalej bez żadnego wysiłku.”

#1 Nie skupiaj się na piłce

To jest blog o projektach prowadzonych przy użyciu metod zwinnych, o projektach agile. Czasami poruszam też temat testowania oprogramowania i agile testing. Pytasz pewnie siebie “Co ma z tym wspólnego golf?”

Spójrzmy najpierw na pierwszą radę, w skrócie “Nie skupiaj się na piłce”. Jeżeli dobrze opanujesz uderzenie, nie będziesz musiał skupiać się na piłce, bo zawsze uderzysz tak samo i będziesz wiedział gdzie piłka powinna polecieć. Kontrolując obrót ciała i układ rąk, wiesz gdzie znajdzie się kij w decydującym momencie. Piłka tylko pokaże, jak wykonałeś ruch i oceniłeś warunki środowiska. Skup się, bądź tu i teraz i wykonaj uderzenie jak najlepiej potrafisz. Często początkujący gracze skupiają się na tym, żeby “przyłożyć” w piłkę jak najsilniej. Czasem trafią, czasem nie, ale na pewno nie potrafią posłać piłki dwa razy w to samo miejsce.
Czy nie jest tak samo z Sprint Burndown? Spójrzmy na powszechne błędy.

• Często zespoły, zwłaszcza te wdrażające Scrum skupiają się na idealnym Sprint Burndown.
• Project Manager albo Scrum Master naciskają na członków zespołu, żeby zaniżyli ilość oszacowanej pracy dla zadania.
• Nowe zadania i zgłaszane defekty nie mają estymat, bo przecież to może zepsuć wykres Sprint
• Zapomina się o koncepcji “ideal day” i oczekuje się rejestrowana 8 godzin pracy w zadaniach każdego dnia. Bo przecież “za 8 godzin im płacimy” i pojemność Sprintu została określona poprzez pomnożenie ilości dni roboczych w Sprincie przez 8h.

No i czasem uda się, że te dwie linie Sprint Burndown i Ideal Sprint Burndown spotkają się na koniec Sprintu. Ale jednak Product Owner nie będzie zadowolony, wyjdzie na jaw kilka defektów, kilka niedokończonych zadań i w kolejnym Sprincie Burndown będzie wyglądał dużo gorzej. A może Sprint Burndown zejdzie do zera, a część zadań nie będzie DONE. Dlaczego? Bo skupiasz się na piłce a nie na technice. Jeżeli nauczysz się dobrze planować i szacować oraz pozwolisz zespołowi zorganizować prace, to Sprint Burndown będzie to obrazował. Sprint Burndown to tylko wykres i nie jest celem sam w sobie. Jest tylko narzędziem. Tak samo jak piłka pokazuje Ci jak uderzyłeś, tak Sprint Burndown pokazuje Ci jak Zespół oszacował zadania i jak idzie ich wykonywanie. Te same zasady dotyczą drugiego burndownu, Release Burndown.

#2 Skup się na celu, nie na przeszkodach

Jak zapewne orientujesz się na polu golfowym są umieszczone przeszkody takie jak piasek czy woda. Trzeba je pokonać na drodze do dołka. Często gracz tak bardzo skupia się na tym, żeby nie trafić w przeszkodę, że w końcu w nią trafia. To może mieć podstawy w jednym z podstawowych założeń NLP – mózg nie rozpoznaje słowa “nie”. Jest ono sztuczne i nie ma przypisanego obrazu, filmu dźwięku itd., które by określały co to jest “nie”. Dlatego jeżeli napiszę: “Nie wyobrażaj sobie zielonego ogra pożerającego autobus”, to pewnie właśnie zrobiłeś na odwrót. Fakt jest taki, że początkujący gracz wybija piłkę na odległość przynajmniej 80 metrów. Woda jest 50 metrów przed nim, więc ma 30 metrów zapasu. Wystarczy skupić się na dołku i piłka nie wpadnie do wody.
Na projektach agile czasem skupiamy się na przeszkodach, zamiast na celu. Skupiamy się, żeby:

• nie mieć żadnych defektów,
• zautomatyzować wszystkie przypadki testowe,
• architektura była jak najbardziej elastyczna,
• interfejs użytkownika był doskonały

i w efekcie mamy nieudany Sprint.
Często początkujące zespoły dopada bezlitosne prawo Parkinsona, które w skrócie polega na tym, że na wykonanie zadania zużyjesz tyle czasu, ile masz dostępne. Bardzo dobrze widać to przy każdego rodzaju pracach zaliczeniowych. Student odda pracę dopiero przy końcu terminu, a nawet wykona tę pracę dopiero blisko terminu, albo dołoży różne, nie wymagane w specyfikacji, żeby wypełnić czas. Kolejnym z powszechnych błędów jest realizowanie łatwiejszych zadań na początku i odkładanie tych trudniejszy, mniej przyjemnych na później, nazywa się to zjawisko prokrastynacją. W efekcie dochodzi sytuacji, że odkładana zadania okazują się trudniejsze niż przewidziano, albo powodują pewne problemy, których rozwiązanie wymaga czasu, którego na koniec Sprintu już nie mamy.

Jak sobie z tym radzić? Skupiaj się na celu. Skup się na zrealizowaniu celu Sprintu, gola i dostarczeniu wartości biznesowej. Omijanie przeszkód i rozwiązywanie problemów jest częścią gry i przyjdzie Ci naturalnie, kiedy pamiętasz co chcesz osiągnąć.

“What do you mean Agile?” usłyszałem pół roku temu na rozmowie rekrutacyjnej w firmie w której obecnie pracuje.Agile – zwinny, elastyczny… Jak właściwie mamy rozumieć pojęcie Agile? Czy Agile to brak dokumentacji, brak ustalonych reguł, iteracyjny model wytwarzania oprogramowania, a może to tylko idealistyczny ruch społeczny? Wielu ludzi używa pojęcia Agile ale to słowo samo w sobie nie ma konkretnej definicji.

Spróbujmy może sięgnąć do historii. Pierwszych wzmianek o Agile (lub tym co właściwiej się pod tym pojęciem kryje) możemy doszukać się już w latach 60tych ubiegłego wieku w kontekście przyrostowego modelu wytwarzania oprogramowania. Wzrost popularności i uznanie Agile  jako pełnoprawnej metodyki zarządzania projektami są niewątpliwie powiązane z ogłoszeniem Manifestu Agile w 2001 roku kiedy to czołowi przedstawiciele takich metodyk jak  Scrum, Crystal Clear, Extreeme Programming, spotkali się by na podstawie swych doświadczeń sformułować cztery podstawowe zasady Agile:

1. Ludzie i interakcje ponad procedury i narzędzia.
2. Działające oprogramowanie ponad obszerną dokumentację.
3. Współpraca z klientem ponad negocjację kontraktów.
4. Reagowanie na zmiany ponad podążanie według ściśle ustalonego planu.

Oprócz powyższych filarów manifestu agile sformułowane zostało 12 dodatkowych zasad:

• Zadowolenie klienta szybkie dostarczanie użytecznego oprogramowania.
• Otwartość na zmianę wymagań nawet w późnej fazie developmentu.
• Częste dostawy działającego oprogramowania.
• Działające oprogramowanie jest podstawową miarą postępu projektu.
• Stałe tempo rozwoju oprogramowania.
• Bliska współpraca pomiędzy klientem a zespołem.
• Bezpośrednie rozmowy są najlepszym sposobem wymiany informacji.
• Projekt jest budowany wokół wysoce zmotywowanego,  godnego zaufania zespołu.
• Ciągłe poświęcanie uwagi wysokiej jakości kodu i odpowiedniemu projektowaniu.
• Prostota.
• Samo-organizujące się zespoły
• Regularne dostosowywanie się do zmieniających się okoliczności.

Niemniej jednak powyższe zasady nadal mogą być różnie interpretowane i pozostawiają wiele pola do manewru dla tych, którzy chcieli by się do ruchu Zwinnego Wytwarzania Oprogramowania przyłączyć. Nie ma żadnych zasad przystąpienia do tego ‘elitarnego’ klubu użytkowników Agile – wystarczy się zdeklarować, że powyższe zasady nie są nam obce i staramy się ich przestrzegać w naszej codziennej pracy. Czy to dobrze? Z jednej strony tak – im nas więcej tym lepiej, tym więcej ciekawych pomysłów i rozwiązań, niemniej jednak takie rozproszenie często prowadzi do powstawania ‘potworków’ opartych na zasadach Agile, które niestety próbują się zaadoptować do abstrakcyjnych sytuacji w których nie mają racji bytu.

Zatem co ja mam na myśli, gdy mówię Agile?

Moja interpretacja czterech filarów Agile wygląda następująco:

Ludzie i interakcje ponad procedury i narzędzia. Dla mnie Agile to przede wszystkim ludzie – dobrze zmotywowany zespół ekspertów (lub ludzi którzy dążą do tego by stać się ekspertami), dla którego jakość ma znaczenie, ludzie którzy znają wartość dobrego projektowania, ludzie dla których komunikacja i przekazywanie informacji jest podstawą udanej współpracy, ludzie którzy dobrowolnie biorą odpowiedzialność za to co robią i zdają sobie sprawę z konsekwencji decyzji, które podejmuj, ludzie którzy potrafią także rozmawiać z klientem, samodzielnie uzyskiwać potrzebne informacje, ludzie którzy potrafią zorganizować swoją pracę i współpracę. Procedury, narzędzia, metodyki, proces – czemu nie, ale to ludzie stanowią podstawę. Agile nie wyklucza narzędzi czy procesów, wręcz przeciwnie, XP, Scrum, czy Crystal Clear mają ściśle określone zasady, których przestrzeganie jest wskazane. Jeśli decydujemy się na używanie jakiejś metodyki czy narzędzia – np. Scrum, musimy pamiętać o tym, by używać jej zgodnie z ściśle określonym planem, używać go w celu do którego została stworzona, nie tworzyć potworków, które nie są sprawdzone i mogą doprowadzić do kalectwa procesu, takie postępowanie może wręcz zniechęcić do używania narzędzia czy nawet do samego Zwinnego Wytwarzania Oprogramowania. Po co wynajdywać koło od nowa, skoro można korzystać z tego co zostało już dosyć dobrze sprawdzone i działa.

Działające oprogramowanie ponad obszerną dokumentację. Będę Szczery- czytam dokumentację projektową tylko w ostateczności, uważam to za stratę czasu, jeśli tylko mam dostęp do osoby która daną dokumentację pisała to w pierwszej kolejności wolę porozmawiać i uzyskać potrzebne mi informację bezpośrednio u źródło. Dosyć często już podczas takich rozmów znajdujemy błędy w założeniach (często już zaimplementowane) bez odpalania komputera. Uważam, że efektywność jest nieporównanie większa niż gdybym musiał przedzierać się przez czasem kilkadziesiąt stron dokumentów. Nie mówię, że cała dokumentacja jest zła – warto dokumentować niestandardowe rozwiązania, nowe technologie, albo przynajmniej gromadzić w jednym miejscu referencje do informacji na ich temat. Niewątpliwą zaletą dokumentacji jest to iż wraz z odejściem pracowników wiedza nie ginie. Niemniej jednak utrzymanie aktualnej dokumentacji może nawet przewyższyć koszty samego wytworzenia oprogramowania. Jeśli dbamy o jakość kodu, o to by był jak najbardziej czytelny, o to by stosowane były znane powszechnie wzorce projektowe to nie musimy się martwić o dokumentację – dobrze napisany kod sam się dokumentuje, a testy jednostkowe/funkcjonalne/integracyjne stanowią dokumentację funkcjonalną.

Współpraca z klientem ponad negocjację kontraktów. Agile opiera się na zaufaniu klienta do firmy, zaufaniu managera do zespołu, zaufaniu członków zespołu do siebie na wzajem. Stosy dokumentacji projektowej zawartej w załącznikach do kontraktów stają się niepotrzebne, gdy klient ma pewność tego, że funkcjonalność, której potrzebuje zostanie rzetelnie wyceniona i zaimplementowana z gwarancją wysokiej jakości. Ponadto klient zyskuje możliwość wpływania na projekt w trakcie jego trwania – może nawet zmieniać wymagania. Nie ustala się ceny z góry, co najwyżej obie strony ustalają dopuszczalne widełki. Idealnie do tego typu projektów sprawdza się Scrum, w którym można określić stałą cenę za sprint. Niemniej jednak jak wspomniałem wyżej tutaj też podstawą jest zaufanie.

Reagowanie na zmiany ponad podążanie za ścisłym planem. Szczegółowe planowanie przed rozpoczęciem projektu to strata czasu. Nie jesteśmy w stanie zaplanować szczegółowo przebiegu projektu. Nie możemy przewidzieć interakcji ze światem zewnętrznym, które mogą mieć wpływ na projekt. Niemniej jednak Agile nie odrzuca całkowicie planowania! Dużo bardziej efektywne okazuje się częste planowanie w krótkich etapów projektu – iteracji/sprintów. Dzięki krótszym okresom czasu możemy dokładniej przewidzieć to co się wydarzy – nikt nie jest w stanie dokładnie określić co będzie robił za pół roku, dużo łatwiej jest nam powiedzieć czym będziemy się zajmować za tydzień, a jeszcze łatwiej co planujemy na dzisiaj. Dlatego idealnie sprawdzają się codzienne spotkania typu stand-up, które pozwalają na szczegółowe zaplanowanie pracy w najbliższym dniu, oraz rozliczenie samego siebie z zadań wykonanych od ostatniego spotkania, ponadto jest to świetna okazja do wymiany informacji pozwalająca na bardzo wczesne reagowanie na zmiany zachodzące wokół nas. Możecie mi wierzyć lub nie ale WYMAGANIA SIĘ ZMIENIAJĄ, nie da się zaplanować wszystkiego z góry, dlatego warto korzystać z mechanizmów pozwalających na szybką reakcję.

Dla mnie powyższe zasady są pewną podstawą wokół której możemy dalej rozwijać nasz proces wytwarzania oprogramowania. Agile nie odrzuca wszystkiego innego, z moich doświadczeń wynika że np. idealnie ze zwinnym wytwarzaniem oprogramowania sprawdza się stosowanie wykresów Gant’a czy ustalanie ścieżek krytycznych, albo stosowanie wzorów optymalizacyjnych dla szeregów produkcji. Dodając do tego Continous Improvement możemy osiągnąć na prawdę wiele, niemniej jednak należy pamiętać o tym by zapewnić sobie dobry start do wprowadzania zmian, ale o tym może innym razem.

A Ty co masz na myśli, gdy mówisz “Agile”?

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.

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.

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!