blog.testowka.pl

Kanban

Samoorganizacja i korki uliczne

opublikowany przez 18, Lut, 2013, w kategoriach Agile, Kanban, Scrum

Często przykłady samoorganizacji czerpie się z ruchu ulicznego – to samo zamierzam zrobić i ja. Najlepszym dowodem istnienia samoorganizacji w ruchu drogowym są wszelkiego rodzaju skrzyżowania o ruchu okrężnym – ronda. Mało tego samoorganizacja działa całkiem nieźle także na zwykłych skrzyżowaniach. Dobrym przykładem jest tutaj kilka skrzyżowań w ścisłym centrum Krakowa (między innymi okolice, Galerii Krakowskiej oraz Teatru Bagatela) gdzie awaria sygnalizacji świetlnej jakiś czas temu pokazała, że bez niej przestały się tworzyć w tych miejscach korki uliczne a ruch zaczął odbywać się dużo płynniej niż wcześniej. Miało to pozytywny wpływ nie tylko na najbliższą okolicę tych miejsc ale także bardziej odległe drogi dojazdowe. Na szczęście ewenement ten został zauważony przez odpowiednie osoby i sygnalizacja została tam wyłączona na stałe – na co nikt chyba już nie narzeka.

Jak to się dzieje, że jako kierowcy potrafimy się samemu zorganizować i efektywnie działać na drogach?

Możliwe jest to dzięki wspólnym dla wszystkich, transparentnym, jednoznacznym i przede wszystkim prostym zasadom. Niestety nawet te zasady nie uchronią nas przed korkami ulicznymi.

Co tak właściwie jest przyczyną korków? Na temat tego jak korki powstają przeprowadzono wiele badań i wyciągnięto równie wiele wniosków. Naukowcy są na pewno zgodni co do jednego – na korki wpływ ma ilość samochodów. Każda droga ma swoją przepustowość czyli ilość samochodów, która może się na niej znajdować w danym momencie tak by możliwy był płynny ruch.

W zarządzaniu organizacjami często mówi się o wykorzystywaniu zasobów. Zarządzanie zasobami miało swoje początki w czasach manufaktur i rewolucji przemysłowej kiedy to niezwykle istotnym było wykorzystywanie maszyn w 100% na 3 zmianach, gdyż koszty wszelkiego rodzaju przestojów były bardzo wysokie.

Niestety te metody sprzed kilkudziesięciu o ile nie kilkuset już lat wielu managerów próbuje stosować również dzisiaj do zupełnie innych celów. Często mówi się o ludziach jako o „zasobach” – czego nie znoszę! Pomijając dehumanizację i uprzedmiotowienie człowieka, tego typu język powoduje błędne, stereotypowe myślenie, które prowadzi do niewłaściwego stosowania niewłaściwych narzędzi – na przykład właśnie wspomnianego zarządzania zasobami ludzkimi.

O ile w przypadku maszyn w fabrykach wykorzystanie zasobów w 100% miało sens o tyle na drogach jak i w organizacjach, gdzie liczy się praca umysłowa jaką jest między innymi wytwarzanie oprogramowania tego typu podejście się nie sprawdza. Autostrada wykorzystana w 100% wygląda tak jak na obrazku powyżej.

Według Scrum zespoły powinny być samo-organizujące się – podobnie jak ruch uliczny. W Scrum Guide jest również napisane, że zespoły powinny pracować w stałym, stabilnym i niewyśrubowanym tempie (ang. sustainable pace).

Wracając do skrzyżowań bezkolizyjnych – przeważnie działają całkiem nieźle. Ale zdarzają się sytuacje, gdy działać przestają. Nawet na rondzie może utworzyć się korek. Z czego to wynika?

Przede wszystkim ilość samochodów wjeżdżających na rondo nie może być zbyt duża. Podobnie w zespołach developerskich – jeśli ilość zadań jest zbyt duża to praca będzie przebiegała znacznie wolniej oraz pojawią się problemy.

Równie problematyczny jest brak miejsca za rondem, gdzie samochody mogłyby zjechać. Jeśli praca zespołów developerskich nie jest odbierana regularnie i nie jest dostarczany feedback na temat poprawności ich pracy to wszelkiego rodzaju problemy i wątpliwości będą się gromadzić aż zablokują przepływ zadań w procesie. Jest to niezwykle istotne, gdyż tak jak i z ronda mamy wiele zjazdów i jest wiele dróg którymi możemy dotrzeć do celu tak i w produkcji oprogramowania jest wiele możliwości osiągnięcia tych samych efektów. Gdy widzimy, że za rondem droga jest zablokowana możemy podjąć decyzję o wybraniu innej drogi.

A co jeśli na rondzie będzie miała miejsce jakaś stłuczka (to też się czasem zdarza)? Co jeśli komuś zepsuje się samochód i zablokuje skrzyżowanie? W produkcji oprogramowania dosyć często pojawiają się różne problemy, które również mogą zaburzyć przepływ zadań. Takie problemy powinny być rozwiązywane w pierwszej kolejności by w jak najmniejszym stopniu zaburzać proces. Potrzebna jest tutaj praca całego zespołu by nie skończyło się to tak jak na zdjęciu obok. Jak trudne jest usunięcie zepsutego samochodu z drogi wie każdy właściciel samochodu takiego jak mój :). Na szczęście kilkukrotnie spotkałem się z bardzo uprzejmymi gestami ze strony innych kierowców czy też przechodniów, którzy widząc mój problem od razu oferowali swoją pomoc, a czasem nawet bez słowa pomagali mi zepchnąć moje auto na pobocze. Za co serdecznie dziękuję! Podobnie w zespole Scrum potrzebna jest tego typu bezinteresowna i naturalna pomoc w rozwiązywaniu problemów. Problem jednego członka zespołu zawsze jest problemem całego zespołu a nawet całej organizacji. Dlatego rozwiązywanie bieżących problemów, poprawianie bugów, naprawianie testów automatycznych i leżących buildów oraz problemów z infrastrukturą powinny być priorytetowe.

Na rondach pojawiają się problemy jeszcze z jednego powodu. Podobnie jak na innych skrzyżowaniach tak i na tych z ruchem okrężnymobowiązują pewne zasady (między innymi zakaz wjazdu na skrzyżowanie jeśli nie ma możliwości jego opuszczenia). Wystarczy, że jedna osoba tych zasad nie będzie przestrzegać a problemy bardzo szybko się pojawią i będą narastać. Potrzebne są też pewne ograniczenia – jak na przykład klomb z kwiatami na środku ronda niepozwalający na przejechanie przez nie na wprost. Takie ograniczenia narzuca metodyka – np. Timeboxes w  Scrum i WIP limit w Kanban.

Żadna metodyka, tak samo jak przepisy uliczne nie sprawi, że nie trzeba będzie myśleć. Być może doczekamy czasów w których samochody będą jeździły same a procesy wytwarzania oprogramowania będą całkowicie zautomatyzowane ale do tego czasu myślenie i wysiłek umysłowy zarówno na drogach jak i podczas wytwarzania oprogramowania to podstawa!

Czasem zdarza się też tak, że drogę blokuje stado baranów… Samoorganizacja będzie miała szanse działać tylko jeśli zostanie wytworzona odpowiednia przestrzeń i zespół nie będzie rozpraszany i blokowany przez innych. W Scrum rolę pasterza owiec pełni Scrum Master, który nie pozwala im wchodzić w drogę zespołowi.

Na drodze pojawiają się też różne przeszkody i tutaj też istotna jest rola Scrum Mastera który niczym robotnik drogowy będzie te przeszkody jak najszybciej usuwał.

Są jeszcze dobre praktyki, których stosowanie pozwala nam na przykład na bardziej ekonomiczną i bezpieczną jazdę, dzięki której nasze auto będzie nam służyło dłużej. Tutaj przydaje się Scrum Master w roli coacha zachęcającego do poprawiania swojego stylu jazdy – wytwarzania oprogramowania. Cel jest jasny – chcemy wykorzystywać drogę lepiej i móc jeździć po niej szybciej.

4 komentarze więcej...

Skrzynka z narzędziami – dlaczego dobrzy developerzy zmieniają pracę?

opublikowany przez 29, Sty, 2013, w kategoriach Agile, Kanban, Scrum, XP

Nie istnieje jeden, sprawdzony i zawsze działający sposób na efektywne wytwarzanie oprogramowania. Jako praktycy, trenerzy, doradcy i konsultanci nie jesteśmy w stanie dać wam (sprzedać) czegoś co sprawi, że wasz proces będzie działał i przynosił oczekiwane efekty. Jedyne co możemy wam zaoferować to pomoc przy kreacji takiego procesu przez was – bo to wasz proces, a i to z pewnymi ograniczeniami. Jako zewnętrzni doradcy (nawet gdybyśmy byli u was na etacie było by tak samo, a nawet gorzej) nie możemy kazać wam czegoś zrobić, ba z pewnością nie chcieli byśmy niczego wam nakazywać i brać za to odpowiedzialności.

To co możemy dla was zrobić to przekazać wam nasze doświadczenia i opowiedzieć historie o tym jak jakieś narzędzia i techniki działały bądź nie w innych organizacjach, w innych zespołach. Może niektóre z nich zadziałają u was, może będą wymagały odpowiedniego dopasowania. To co jeszcze możemy zrobić to przekazać wam wiedzę na temat danych narzędzi i metod pracy. Będzie to pewnie w większości tak lekceważona i dyskryminowana wiedza teoretyczna. Ale czy wiedza, chociażby teoretyczna nie jest wartościowa?

Do poniższego artykułu zachęcił mnie wpis Sandro Mancuso zatytułowany „The best approach to software development”. Jak zapewne w nim przeczytacie nie ma jednego, najlepszego podejścia do wytwarzania oprogramowania. Natomiast jest wiele podejść, które sprawdziły się w określonym kontekście w wielu różnych projektach.

W takim razie wszelkiego rodzaju dogmatyzm na tym poziomie jest co najmniej niewskazany. Warto natomiast znać wiele technik/narzędzi chociażby takich jak TDD, BDD, ATDD, DDD, XP, Scrum, Kanban, Lean Startup, Gamification, i wiele innych. Warto mieć doświadczenie w używaniu tych narzędzi i dzięki temu wiedzieć, do jakich zadań wykorzystywać jakie narzędzia. Wielu dobrych programistów, których znam zmienia pracę dosyć często – raz na dwa lata. Zapytani dlaczego odpowiadają przeważnie, że pomimo tego, iż firmy w których pracują są na prawdę fajne to po pewnym czasie następuje wypalenie i nuda spowodowana pracą nad ograniczonym zbiorem produktów, według ograniczonych metod pracy i w ograniczonej liczbie technologii.

Wiele firm takich jak np. Google zauważyło ten problem i wręcz wymusza na swoich pracownikach zmianę projektu w którym pracują przynajmniej raz na dwa lata (przykład właśnie z Google). Dobrzy pracownicy są dobrzy przeważnie dlatego, że szybko się uczą i lubią się uczyć. Jest to coś co ich motywuje. Ale dobrzy pracownicy też łatwo się nudzą. Jeśli mają cały czas możliwość rozwoju i nauki to praca ich nie nudzi. Jeśli natomiast cały czas pracują w tym samym środowisku to z czasem motywacja spada choćby nie wiem jak wysokie były premie, jak fajni ludzie na około i jak fajne imprezy firmowe.

Dobrzy developerzy cały czas poszukują nowych narzędzi, doświadczeń i możliwości rozwoju i to właśnie te narzędzia i doświadczenie sprawiają, że są dobrzy.

1 komentarz więcej...

Jeśli twój manager nie pozwala na wdrożenie Agile…

opublikowany przez 18, Gru, 2012, w kategoriach Agile, Kanban, Scrum, XP, Zarządzanie

Wiele razy byłem pytany o to jak przekonać managerów albo zarząd do Agile. Odpowiedź jest prosta – jeśli nie wiesz jak to zrobić zatrudnij konsultanta – np. mnie. Jeśli management albo zarząd są negatywnie nastawieni do wdrożenia Agile to po co ich w ogóle do tego przekonywać? Wystarczy, że postąpisz zgodnie z powtarzaną wielokrotnie przeze mnie złotą zasadą: jeśli chcesz coś zmienić to zmień coś… Pierwszy krok żeby zmienić świat to zrobić pierwszy krok i coś zmienić.

Jeśli chodzi o samo wdrażanie zmian to istnieją co najmniej dwa podejścia, a przynajmniej te dwa lubię często przywoływać: Kaizen i  Keikaku. To drugie to podejście z góry zaplanowane („keikaku” znaczy po prostu „plan”), Kaizen to ciągłe wprowadzanie bardzo małych ulepszeń – takie trochę bardziej Agile. Bardziej skuteczne wydaje się być (przynajmniej z mojej perspektywy zewnętrznego Coacha) podejście z góry zaplanowane, a tak na prawdę chodzi o skalę samych zmian, która w tym podejściu jest po prostu większa. A tak na prawdę najlepiej sprawdzają się oba podejścia stosowane jednocześnie. Keikaku żeby wystartować i Kaizen żeby trwale kontynuować rozpoczęte zmiany, gdyż proces transformacji organizacji nie ma końca.

No dobrze a co z tymi nieszczęsnymi managerami? Jeśli przewidujecie z góry duży opór z ich strony i wręcz strach przed zmianą po prostu nie poruszajcie tego tematu. Organizację możecie zacząć zmieniać od siebie i swojego najbliższego otoczenia. Bardzo podoba mi się zasłyszane na którejś konferencji stwierdzenie, że „łatwiej później prosić o wybaczenie niż za każdym razem błagać o zgodę”. Jeśli uda się coś poprawić to dobrze, jeśli nie to pewnie i tak nikt nie zauważy. A po jakimś czasie będziecie mogli postawić managerów i wszystkich innych oponentów zmian przed faktem dokonanym – „O popatrzcie to już gdzieś było – hmm, wygląda jak… Scrum?/Kanban?/XP?/TDD?/Whatever?”. Dużo łatwiej będzie Wam kogokolwiek przekonać jeśli pokażecie twarde dowody na to,  że to co proponujecie działa. To znaczy o ile to działa – bo przecież Agile nie jest do wszystkiego(?) i nie dla każdego(?)…

1 komentarz więcej...

To nie proces ale ludzie odnoszą sukcesy

opublikowany przez 02, Paź, 2012, w kategoriach Agile, Kanban, Praca, Programowanie, Scrum, XP, Zarządzanie

Zaczynają mnie męczyć licytacje (w których jeszcze do niedawna zdarzało mi się uczestniczyć) o to, który proces, która metodyka jest lepsza, dzięki której metodyce osiągniemy większe sukcesy. Propagatorzy i zwolennicy różnych mniej lub bardziej zwinnych podejść do wytwarzania oprogramowania prześcigają się w wynajdowaniu przeróżnych case-studies, które miały by być materiałem dowodowym potwierdzającym, że to właśnie metodyka X a nie Y jest lepsze i dzięki niej „projekty” kończyły się sukcesem. Czy Kanban jest lepszy od Scrum, czy na odwrót? Które praktyki z XP dają lepsze efekty? Waterfall vs Agile? Testowanie manualne vs Automatyzacja (…chyba się zapędziłem 🙂 )? I tak dalej…

Moje doświadczenie pokazuje natomiast, że to nie żadna metodyka czy proces były kluczowym czynnikiem sukcesu w projektach, w których uczestniczyłem, lecz ludzie, którzy do tego sukcesu doprowadzali. Na przykład oprogramowanie – projekty które realizowaliśmy w Code Sprinters nie odnosiły sukcesów dlatego, że używaliśmy Scrum, stosowaliśmy programowanie w parach, pisaliśmy testy automatyczne i staraliśmy się wszędzie stosować TDD… Osiągaliśmy sukcesy dlatego, że my – ludzie, którzy wytwarzali ten software potrafili do tych sukcesów doprowadzić. Scrum, TDD, Pair Programming, Testy automatyczne etc. to były tylko narzędzia, bardzo pomocne narzędzia, które w sprawnych, doświadczonych rękach były odpowiednio wykorzystywane.

Jeśli rzeźbiarz nie rzeźbi z pasją, nie ma talentu i nie ma pojęcia w temacie obróbki materiału w którym rzeźbi to bez względu na to jak dobre dłuto mu damy rzeźba arcydziełem raczej nie będzie”

Podobnie z oprogramowaniem. Jeśli tego co robimy nie robimy z pasja to niestety efekty naszej pracy będą co najwyżej średnie. Jeśli nie posiadamy wystarczającej wiedzy na temat technologii, którą stosujemy i ciągle nie wzbogacamy tej wiedzy to z pewnością nie unikniemy wielu błędów. Nawet jeśli metody i procesy są tylko(?) narzędziami to wcale nie znaczy, że możemy o nich zapomnieć. Umiejętne posługiwanie się narzędziami jest kluczowe – czym byłby rzeźbiarz bez dłuta, albo taki, który tym dłutem posługiwać się nie potrafi.

Odpowiedni ludzie, którym zapewniamy odpowiednie warunki do pracy to jest właśnie to co sprawia, że różnego typu narzędzia (metodyki, procesy, praktyki, technologie, etc.) działają tak jak powinny i w efekcie prowadzą do sukcesów.

Udowadnianie że metoda X jest lepsza od Y nie ma najmniejszego sensu. Wszelkie porównania także są bezcelowe, gdyż nie sposób zapewnić odpowiednio laboratoryjnych warunków, by jakiekolwiek miarodajne testy przeprowadzić. Nawet tan sam zespół będzie lepiej pracował używając danego zestawu narzędzi nie dlatego, że narzędzia są lepsze ale dlatego, że akurat te narzędzia bardziej do tego zespołu pasują.

Kiedyś, ktoś zapytał mnie na jakiejś konferencji czy Agile jest dla każdego – a jeśli nie to co zrobić z tymi, którzy do tego modelu nie pasują. Osoba pytająca była managerem w organizacji, która przymierzała się do Agile. Moją odpowiedzią było pytanie: „Jakie jest najważniejsze zadanie managera w organizacji? Takie, które ma zasadniczy wpływ na wszystkie inne decyzje np. o procesach i metodykach?”. Podstawą jest stworzenie zespołu i dobór odpowiednich osób do odpowiedniej pracy.

Niestety chyba powoli o tym zapominamy – zbyt często managerowie są zatrudniani do już istniejących zespołów, lub są wyłaniani z tychże zespołów drogą awansu. Często manager ma związane ręce w kwestii doboru osób do zespołu. A to właśnie odpowiedni dobór osób do wykonywania danego rodzaju pracy jest kluczowy. Pomijam już fakt, że sam proces doboru jest bardzo trudny i często pomimo najlepszych starań kończy się pomyłkami.

Co by się stało gdybyśmy nagle naszym programistom kazali budować domy?”

A co jeśli programistom php każemy od jutra pisać kod w C, albo na odwrót. Co jeśli ludziom z piętnastoletnim doświadczeniem w korporacyjnych procesach predykcyjnych nagle każemy przesiąść się do małych wskroś-funkcjonalnych zespołów pracujących w sposób czysto empiryczny.

Niektórzy programiści może i dom wybudują – ale raczej nie wszyscy są do tego zdolni…

Dodaj komentarz więcej...

„Jeśli jesteś managerem w Agile to nie istniejesz.”

opublikowany przez 09, Sty, 2012, w kategoriach Agile, Kanban, Scrum, XP, Zarządzanie

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.

3 komentarze więcej...

Podsumowanie otwartego szkolenia „Rola testera w metodykach zwinnych”

opublikowany przez 06, Cze, 2011, w kategoriach Agile, Kanban, Scrum

W sobotę 28.05.2011 miałem przyjemność poprowadzić w Katowicach krótkie (4h), otwarte szkolenie zatytułowane „Rola testera w metodykach zwinncyh”.

Celem mojej prezentacji było przybliżenie uczestnikom różnych rodzajów metodyk zwinnych oraz wspólne zastanowienie sie nad rolą testera w Agile.

Chciałbym podziękować wszystkim za przybycie (było około 40 osób) i poświęcony czas zwłaszcza, że była to sobota. Jestem pod wrażeniem tego, że są jeszcze tacy ludzie jak Wy, którym chce się wstać rano w sobotę i przyjść na szkolenie (tymbardziej, że niektórzy przyjechali z Warszawy i z Krakowa). Taka postawa niesamowicie motywuje mnie do tworzenia dalszych szkoleń a także innej pracy!

Podziękowania także dla Radka Smilgina z testerzy.pl za orgazniację i promocję szkolenia!

Relację i podsumowanie możecie przeczytać także na stronie testerzy.pl

Poniżej obiecane slajdy ze szkolenia:

[slideboom id=369320&w=425&h=370]

Zapraszam także na moje inne szkolenia – tym razem już pełnowymiarowe i zamknięte:

14 komentarzy więcej...

Jak przygotowuję szkolenia?

opublikowany przez 14, Maj, 2011, w kategoriach Agile, Kanban, Scrum, Zarządzanie

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.

kanbanery.com

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

Zapewnianie jakośći w Agile - mindmap

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ą!

3 komentarze więcej...