Blogs

Wiktor's Blog (in Polish): Dlaczego tniemy jakość?

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.

Wiktor's Blog (in Polish): Nie dla ACTA

W skrócie…
Gdyby zapisy zawarte w ACTA obowiązywały pięć lat temu ten blog najprawdopodobniej nigdy by nie powstał, lub znalazł by się też paragraf na to, by go teraz zdelegalizować.

O ile to co tutaj zamieszczam jest moją własnością lub jest udostępniane na zasadzie wolnego oprogramowania o tyle wiedza, którą zdobyłem na przestrzeni ostatnich kilku lat zapewne w większości nie była by dostępna, gdyby przepisy takie jak te zawarte w ACTA, SOPA czy PIPA zostały wprowadzone, a to właśnie ta wiedza jest moją własnością – no właśnie, czy w świetle ACTA nadal jest moją własnością?

Więcej o ACTA możecie dowiedzieć się z tego filmiku, oraz dyskusji na Wikipedii i przede wszystkim stąd.

Swoją drogą nigdy nie miałem ochoty a przede wszystkim powodu by wychodzić na ulicę i manifestować swoje poglądy a przede wszystkim jakikolwiek sprzeciw. Natomiast tym razem zamierzam skorzystać z demokratycznego prawa do manifestacji swojego niezadowolenia.

A jeśli jesteście we Wrocławiu i okolicach zapraszam do przyłączenia się do protestu w środę – i przekazywania informacji dalej.

Oczywiście zachęcam też, do protestów w Waszych miastach.

Wiktor's Blog (in Polish): Agile a polityka

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.

Wiktor's Blog (in Polish): “Jeśli jesteś managerem w Agile to nie istniejesz.”

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.

Andy's Blog: CFO – Chief Fun Officer

Software development is a very peculiar industry. If work is not fun for those doing it the products will be mediocre at best and so will be the company – it can make money but it will never be a great company attracting talented people.

This is so because software development is not really engineering – it only looks like it because it is so technical. If done right it is in fact a fusion of art and technology – very much like a craft only requiring mental, not manual abilities. If people are not emotionally attached to their craft (like those who code&test solely for the money) they will not care if they produce a mess of spaghetti code rather than an elegant solution, they will not care what the user experience will be and they will not really care what happens with the product after they no longer work there. The only way to make them care is to make sure work is fun for them and they see a reason for the product’s existence other than the revenues it will bring.

Of course, this rule is more universal – happy people work better in general. For example Southwest Airlines’ happy flight crews deliver a better passenger experience, happier dialysis providers at DaVita provide better treatment etc. However, in software development the difference has a more profound effect – an unhappy flight crew will get you from A to B as effectively, keeping development teams unhappy will in the long run ruin the products/systems they create if not the whole company. This is so, because the less fun their work is the more technical debt there is (of all kinds: bugs, low code readability, C&P programming, suboptimal ad-hock solutions limiting scalability etc.) – and technical debt is as lethal for a business as any other unpaid accumulating debt.

Why it is so? I could bring up some theories, but I think it is less important than realising it and taking notice. Big players do. Take Google for example. They go to great lengths to make the experience of working there as fun as possible. The most visible aspect of this is their offices (each is different, BTW) but it goes way deeper – the way they treat their people, the way they allow them to access all of their code for example, all of that shows that people running this company have a profound understanding of what makes development teams tick. And they are not alone in this, almost every leading business now goes to great lengths to ensure the work itself and environment make the experience as enjoyable as possible for the employees.

Just to be sure – “fun” means a lot more here than just a nice working environment, cool perks and good atmosphere. It also means a shared sense of purpose in what you are doing as a company and as a team. And it also means dedication to technical excellence – a policy of zero tolerance for makeshift solutions and lack of craftsmanship. This mixture means people working in such a company can be rightly proud of what they do, proud of where they work and want to continue investing their time&energy there.

The notion of seeing the workplace as fun is sometimes dismissed as childish. It is so because there are many jobs that simply can’t be made to be fun (think of garbage collectors, people working in slaughterhouses or on assembly lines – by now mostly Chinese – assembling over and over again same parts) and historically practically all work was “serious” – not fun at all. Luckily for us that idea is slowly eroding as people search for self-fulfilment. Spending at least 8 hours a day on a job you hate is definitely not self-fulfilment.

Globalization and shortage of talent, especially in software development and other high tech sectors, make it very easy to run away from jobs where the “fun” part is gone (or wasn’t there ever).

Therefore one of the key duties of executives in an IT company is to make sure people working there have fun at work. And that means not that they can play computer (or traditional) games in a special room or have fancy office furniture – this means ensuring they are having fun doing the actual work as I’ve already explained above. I’m joking sometimes that there are companies that badly need a CFO – Chief Fun Officer – to shake the boat and bring some fun back. But seriously I don’t think one such guy can make a difference – I think that rather this attitude must be at the very core of company’s culture.

How this looks at your current place? Is working there fun? If not – take my advice: don’t waste your life, move on.

Wiktor's Blog (in Polish): Niekoniecznie kros-funkcjonalny zespół

Problemy z kros-funkcjonalnością zaczyna się już na etapie definicji zespołu kros-funkcjonalnego. Niestety zadając pytanie o to na czym polega kros-funkcjonalność bardzo często słyszę niepoprawne odpowiedzi.

Zespół jako całość ma posiadać kompetencje do tego by regularnie dostarczać oprogramowanie gotowe do wydania na produkcję – to jest wystarczająca definicja kros-funkcjonalności.

Ciężko jest mówić o kros-funkcjonalnych zespołach, opartych na ścisłej współpracy ich członków, dostarczających działające i przetestowane oprogramowanie na zakończenie każdej iteracji, gdy na przykład testerzy pracują w oddzielnym zespole niż programiści, często siedząc w osobnym pokoju, budynku, mieście, kraju, kontynencie – jak wtedy powiedzieć, że po zakończeniu każdej iteracji mamy działający produkt. “Scrumowy zespół testowy” to nie zespół Scrumowy.

Jeśli trzeba oprogramowanie testować (a gdzie nie trzeba?) to w skład zespołu powinni wchodzić testerzy. Jeśli do konfiguracji i wydania oprogramowania potrzebna jest praca administratora to taki administrator lub developer z odpowiednimi umiejętnościami powinien się w tym zespole znajdować. Warto wspomnieć jeszcze o tym, że taki zespół nie powinien być zbyt duży. Podział na zespoły funkcjonalne powoduje utworzenie silosów, pomiędzy którymi znajduje się ściana przez, którą jedni i drudzy przerzucają problemy na innych zamiast skupiać się na dostarczaniu wartości. Pisałem już wcześniej o probelmach komunikacyjnych, które także dotyczą takich wyspecjalizowanych zespołów zamkniętych w swoich silosach.

Niestety z powyższym wiąże się kilka problemów – np. problem ze znalezieniem odpowiednio wykwalifikowanych osób – często trzeba po prostu członków zespołu kros-funkcjonalnego szkolić od podstaw. Wszelkie protezy typu “Scrumowy Zespół Testowy” wspomniany powyżej nie będę działać tak wydajnie jak dobrze zmotywowane zespoły kros-funkcjonalne, Problem z silosami wynika też często z zaszłości historycznych – wcześniej organizacja musiała mieć określoną strukturę, posiadać poszczególne specjalistyczne działy i kierowników tych działów – niestety dla takich specjalistycznych kierowników w Agile raczej miejsca nie ma. Oczywiście mogą się oni przekwalifikować np. na Scrum Masterów, albo po prostu członków zespołu – niemniej jednak wraz z tym utracą “władzę” i większość mocy decyzyjnej – byćmoże stąd wynika częsty opór przed wdrożeniami Agile.

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.

Andy's Blog: An interesting experience in servant leadership

I have been leading a two day workshop a couple of months ago and it was an interesting experience in servant leadership that I can now share. The workshop was about the overall systems architecture at the company I was working with at the time. My mission there was transforming their IT department into an agile organization and the workshop took place three months after the change effort started.

The catch was that I was doing it as the company’s CIO – effectively being the boss of all the other people in the room. Given the culture that existed there before it meant there was a real risk they will stay silent and expect me to tell them what architecture I had in mind rather than discuss their ideas. Therefore I had to adopt a very different approach to leading it than when I’m acting as an external consultant/coach. The fact that I genuinely had no idea how to solve the problem at hand helped me do it – I had no architecture to push for.

On the first day I kicked the meeting off with a presentation nevertheless, as everyone expected. I invited the company CEO to present the business plans and the strategy the company leadership wanted to pursue in the near future. After he was done I presented the problem as I understood it by discussing all the systems they had both acquired and developed in house and how I thought they interrelate. I finished by asking the team what architecture we should have in a year from now to support business’ needs and plans. I then started the discussion by asking the group to split into four smaller teams and work on an idea by a flipchart (we had asked for many flipcharts so each group congregated around one of them in the rather large room where we were meeting in).

Then I… left the room walking the CEO to his car (him leaving at that point was of course agreed with him before). This gave the teams the room they needed to start working. When I came back they have been already immersed in a discussion. I could observe how different people participated – some very actively discussing their ideas as they came to them, few scribbling on sheets of paper to join the discussion later, some sticking by one flipcharts others wandering from group to group.

This is how we worked for the rest of the workshop. However, that doesn’t mean I did nothing more – in fact I was needed to moderate some discussions, ask questions but primarily to break stalemates. There were moments when no one was sure how to proceed further and the discussion just died – then I had to step in and push the meeting forward a bit. All that was needed to get them going again was just a question or a simple exercise like voting on what was proposed so far. However, mostly I was just walking around the room, listening to people discussing, watching their diagrams, stickies on the wall etc. – and on many occasions leaving the room altogether.

I have to admit that I had to make a conscious effort to behave like this. While I have no trouble in getting out of people’s way in normal work when I’m leading a meeting I tend to take charge of it and even if I don’t come to it with a pre-determined idea I still steer the agenda and the progress. Here, however, I was leading a workshop by being mostly absent and only facilitating when for one reason or another the participants stalled. This was – I think – servant leadership in a nutshell: what I did as the leader was to set the stage, fire up the discussion by presenting a problem and then get out of the way.

How did this workshop end? The team walked away with a general idea of their future architecture but also – most importantly – an understanding that they could not design it in advance and implement it, but rather that they would have to evolve it by changing what they have now over time. In other words, they decided to go for the emergent architecture approach and wrote down a couple of conditions it has to fulfill to guide the evolution in the right direction. Along the way they discovered a lot about what they did and did not know.

I was really satisfied with the outcome, it was more than I hoped to achieve – and certainly much more than I would have achieved if I tried to pressure and steer the discussion in some predetermined direction.

Wiktor's Blog (in Polish): Wizja produktu

Agile jako niezmiernie elastyczne podejście do procesów wytwarzania oprogramowania ma także pewne wymagania, które by Agile działało muszą zostać spełnione. Jednymi z krytycznych wymagań są jasno określona wizja wytwarzanego produktu oraz zdefiniowane cele dla zespołu/zespołów.

Paradoksalnie decyzja o wdrożeniu Zwinnych Metodyk Wytwarzania Oprogramowania jest często spowodowana problemami z jakimi borykają się organizacje. Agile w zamyśle osób decyzyjnych często ma być lekiem na całe zło i srebrną kulą rozwiązującą wszystkie problemy. Zaletą Agile jest między innymi to, że nawet jeśli nie dostarcza rozwiązań problemów to bardzo dobrze te problemy obnaża i pozwala na identyfikację ich źródeł.

Problemem, który często obserwuje jest brak spójnej (o ile jakiejkolwiek) wizji produktu oraz problem związany z decyzyjnością w sprawach tejże wizji. Często widzę łańcuszek “zaufania” wyglądający mniej więcej tak: developerzy ufają managerom, że mają oni wizję rozwoju produktu, line managerowie ufają swoim przełożonym, że to oni wiedzą jak produkt powinien się rozwijać, wyżsi managerowie wierzą w to, że to zarząd czy też dyrektor decyduje o tym jak ma produkt ostatecznie wyglądać i że ma wszystkie konieczne informacje do tego by takie decyzje podejmować, dyrektor jest pewien że jego przełożony/prezes wie co tak na prawdę robimy bo ma “więcej informacji”… I w drugą stronę prezes jest przekonany, że oddelegował wystarczającą ilość władzy dyrektorowi (bo przecież jako prezes ma mniej informacji, które ma dyrektor) by ten dbał o wizję i rozwój produktu, dyrektor jest pewien, że bez względu na to, że być może on do końca nie wie jak produkt ma wyglądać jego pracownicy w postaci managerów jakoś dają sobie radę i przecież mają więcej informacji od niego, managerowie wierzą w to, że developerzy wiedzą co robią w końcu przecież znają ten system najlepiej. Ostatecznie okazuje się, że większość decyzji podejmowanych jest ad-hoc i za plecami przełożonych, a osoby, które teoretycznie powinny być odbiorcami produktu godzą się z tym co dostają myśląc, że takie były idea i zamysł managerów czy innych osób, które według ich mniemania są odpowiedzialne za kształt produktu.

Problem braku decyzyjności jest bardzo często jednym z pierwszych problemów bezlitośnie obnażanych przez zwinne metodyki zarządzania projektami.

Nie jest na szczęście tak, że w Agile z powyższym problemem nie da się nic zrobić – np. Scrum dostarcza takich narzędzi jak Product Backlog i rolę Product Ownera, który jest odpowiedzialny między innymi za kolejność wykonywanych zadań i formowanie wizji produktu. Niemniej jednak odpowiedni dobór Product Ownera nadal pozostaje często problematyczny.

Często słyszę pytania na temat motywacji zespołów i poszczególnych osób. Nie ma żadnych ogólnych zasad, które by mówiły o tym jak motywować poza jedną mówiącą o tym, że ludzi nie da się zmotywować – można tylko utworzyć odpowiednie środowisko, które będzie sprzyjało motywacji i dostarczyć odpowiednich narzędzi, które tą motywację pozwolą wykorzystać. Takim narzędziem jest między innymi zdefiniowanie kierunku w którym zespół będzie mógł podążać, celu, który będzie osiągalny i którego osiągnięcie będzie stanowiło samo w sobie świetną nagrodę. Z moich obserwacji wynika, że zespoły, które wiedzą do czego dążą i znają wizję produktu, który tworzą pracują znacznie efektywniej niż zespoły, które mają ograniczone informacje na ten temat.

Agile opiera się na samo-organizacji zespołów, która w skrócie polega na tym by określić pewien obszar w którym zespół może się poruszać i zdefiniować cel, który zespół ma osiągnąć (bez względu na to czy mówimy tutaj o “zespole” jako programistach, czy np. całym dziale IT, albo całej organizacji). Bez określonego celu zespół będzie się poruszał w kółko, a ewentualne sukcesy będą dziełem przypadku. Oczywiście możemy zdefiniować granice na tyle twardo i zminimalizować obszar do tego stopnia, że poruszanie się po nim będzie prowadziło tylko w jednym kierunku – do osiągnięcia celu – ale to już jest Manage and Control a nie Agile i jak sama nazwa wskazuje wymaga ciągłej, ścisłej kontroli i nadzoru.

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.

Wiktor's Blog (in Polish): Zbyt wiele osób a za mało kompetencji.

Wiktor's Blog (in Polish): Agile? – tak znam – to taki iteracyjny waterfall.

Zwinne podejście często oznacza zmiany sposobu myślenia, co okazuje się być niezmiernie trudne zwłaszcza w organizacjach, które od dłuższego czasu stosowały znacznie „cięższe” metodyki oparte na zarządzaniu i kontroli. Przyzwyczajenie chociażby do tego, że niektóre etapy wytwarzania oprogramowania następują w ściśle określonej kolejności jeden po drugim często jest przekładane na implementację Agile.

Częstym pomysłem na wdrożenie Agile jest rozbicie iteracji na poszczególne etapy: najpierw mamy kilka pierwszych dni na analizę, pisanie dokumentacji, planowanie i projektowanie, następnie kilka do kilkunastu dni na kodowanie i pod koniec jak starczy czasu tak zwany code freeze lub feature freeze oznaczający nie dodawanie w tym czasie nowych funkcjonalności kosztem skupiania się na testowaniu. W praktyce okazuje się, że jest to nierealne i niestety czasu na testy już nie ma albo jest mocno ograniczony.

Niejako rozwinięciem powyższego pomysłu jest tworzenie specjalistycznych iteracji poświęconych konkretnym etapom wytwarzania oprogramowania. Tak mamy po sobie kolejno: iteracje analizy, planowania i projektowania, kilka iteracji kodowania i jak starczy czasu to iteracje w całości poświęcone integracji, testowaniu i wdrażaniu. Oczywiście możemy wtedy stworzyć specjalistyczne zespoły zajmujące się każdy tylko jednym etapem. Niektórzy próbują nawet układać harmonogramy takich iteracji tak, by żaden zespół się nigdy nie nudził i żeby nie było przestojów produkcyjnych (pomocne bywają wykresy Gant’a) .

Powyższe pomysły z Agile nie mają zbyt wiele wspólnego o ile w ogóle coś mają. Na pierwszy rzut oka widać, że wygląda to jak Waterfall lub Mini-Waterfall w postaci inkrementalnej. Kiedyś spotkałem się nawet z określeniem “Wagile” będącym kombinacją słów Waterfall i Agile.

W Agile każda iteracja musi dostarczać działające, przetestowane i zintegrowane oprogramowanie wnoszące jakąś wartość biznesową. Spełnienie tego warunku nie jest proste – wiąże się z tym wdrożenie odpowiedniej organizacji pracy i zbudowanie silnie współpracującego ze sobą zespołu, co w efekcie daje jeszcze większe korzyści.

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.

Wiktor's Blog (in Polish): To jest tak proste, że aż się prosi by to uprościć.

Agile jest niezwykle nieskomplikowanym podejściem do wytwarzania oprogramowania narzucającym jedynie niezbędne minimum zasad w zupełności wystarczających do zbudowania mocnych i stabilnych podstaw na bazie których można wprowadzać pewne modyfikacje i ulepszać istniejące procesy.

W zasadzie Agile samo w sobie nie jest metodyką – to sposób myślenia (mindset), sposób codziennej pracy,  oparty na czterech filarach spisanych w postaci Manifestu Agile:

Ludzie i ich wzajemne interakcje ponad procedury i narzędzia.
Działające oprogramowanie ponad wyczerpującą dokumentację.
Współpraca z klientem ponad negocjację umów (tworzenie kontraktów).
Reagowanie na zmiany ponad ścisłe realizowanie planu.

To minimum zasad często samo w sobie staje się pokusą tego by je jeszcze bardziej ograniczyć. Postulaty manifestu Agile chociaż wydawało by się proste bardzo często są błędnie interpretowane co prowadzi do wdrożeń zwinnych metodyk zarządzania projektami kończących się porażką lub nie dających oczekiwanych (lub możliwych do osiągnięcia) efektów. Na Manifeście Agile opiera się wiele “zwinnych” metodyk i praktyk takich jak Scrum czy Programowanie Ekstremalne (XP). Metodyki te są same w sobie bardzo proste – zawierają tylko podstawowe zasady, których przestrzeganie gwarantuje wzrost efektywności zespołów developerskich. Niemniej jednak dla niektórych wydaje się to tak proste, że staje się bez znaczenia i niektóre praktyki są pomijane.

W ten sposób powstaje coś takiego jak ScrumBut: „Używamy Scrum, ale nie mamy codziennych spotkań”, „Używamy Scrum, ale nie mamy czasu na retrospekcje”, „Używamy Scrum ale nasz manager mówi nam co i ile będziemy robić w tej iteracji” etc.  Podejście typu “Weźmiemy trochę tego, trochę tamtego a resztę pozostawimy tak jak w modelu kaskadowym” powoduje, że wprowadzane zmiany nie mają szans działać w pełni o ile w ogóle cokolwiek polepszają.

Transformacja organizacji w stronę Agile to proces długofalowy, który wymaga wielu poświęceń i wyrzeczeń, a przede wszystkim wymaga otwartości na zupełnie nowe podejście do wytwarzania oprogramowania a także często wymaga od wdrażających możliwości wprowadzania zmian nie tylko w samym IT.

Gwoli ścisłości: to nie jest tak, że metodyki nie wdrażane w pełni nie będą działały w ogóle – będą, tylko efekty takiego wdrożenia będą dużo mniej stabilne i dużo mniej widoczne. Kilkukrotnie widziałem sytuacje w których metodyki pomimo tego, że wdrożone niekompletnie lub nieprawidłowo same się regulowały i ostatecznie coraz bardziej przypominały podręcznikowe wdrożenia, niestety widziałem też sytuacje, w których niecierpliwość spowodowana brakiem widocznych, obiecywanych efektów prowadziła do całkowitej rezygnacji z dalszego podążania w kierunku Agile.

Powyższy post jest rozwinięciem pierwszej 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.

Wiktor's Blog (in Polish): Testowanie Oprogramowania made in PL

(Zdielano w Polandii)

Minęło już trochę czasu od konferencji Test Warez 2011, w której miałem okazję brać udział jako prelegent, więc chyba najwyższa pora, by podzielić się moimi spostrzeżeniami.

Test Warez jest obecnie największa i prawdopodobnie najpopularniejszą konferencją skierowaną do testerów w Polsce. W zasadzie można śmiało stwierdzić, że nie ma żadnych konurencyjnych wydarzeń w tej tematyce na taką skalę… Właśnie to, że jest to jedyna taka konferencja w naszym kraju jest naszym największym problemem.

Sam poziom konferencji pomimo tego, iż na polskie warunki na prawdę bardzo wysoki niestety nie ma się co równać z konferencjami za granicą. Niemniej jednak wielkie podziękowania dla organizatorów za to, że próbują zrobić coś dla testerów w Polsce.

Nie będę się rozpisywał na temat wszystkich prelekcji i prelegentów, ale chciałem się skupić na dwóch, które pozwoliły mi zrozumieć jaki jest obecny stan Polskiego światka testerów oprogramowania.

Na pierwszy ogień panel dyskusyjny Radka Smilgina z Testerzy.pl zatytułowany: “Dokąd idziesz Testowanie? Co ważnego wydarzyło się w testowaniu w ostatnim roku i co wydarzy się w kolejnych latach”. Panel miał na celu wskazanie najważniejszych wydarzeń w polskim testowaniu oprogramowania, które miały miejsce w minionym roku. Do jednych z głównych wydarzeń roku zostały zaliczone:
- rozpoczęcie kierunku studiów “Testowanie Oprogramowania”
- start platformy crowdsourcingowej testuj.pl
Obydwa powyższe wydarzenia na prawdę są znaczące, niestety polskie testowanie oprogramowania jest daleko w tyle za innymi krajami. Gdy na całym świecie coraz większą popularność zyskuje Agile, a o czymś takim jak Waterfall wszyscy powoli zapominają u nas nadal wszyscy skupiają się na tym jak wykrywać błędy zamiast pracować nad tym jak tych błędów do oprogramowania nie wprowadzać. Platformy crowdsourcingowe skupiające testerów oprogramowania także nie są niczym nowym.
Chociaż akurat powstanie polskiej platformy powinno niektórym dać jasny sygnał do tego, że testowanie oprogramowania w wielu firmach w postaci takiej jak miało miejsce przez ostatnich wiele lat (klikanie) powoli ma się ku końcowi – po co utrzymywać dział klikaczy skoro zawsze można tą usługę dużo taniej wydzierżawić na zewnątrz płacąc tylko za efekty.
Niestety powyższe wydarzenia to tylko kopia tego co na całym świecie miało miejsce już wiele lat temu.

Kolejną prelekcja, która dużo mi uświadomiła był agile’owy wykład Moniki Konieczny na temat kontaktów między testerami a programistami w zespołach (głównie mniej, lub bardziej zwinnych zespołach), oraz o tym jak przy użyciu gemifikacji można te kontakty poprawiać. Podczas prelekcji na sali zaistniał pewien szum rozmów, a nawet śmiechów i pytań typu “o czym ona gada?, jakie konflikty z programistami?”. Dało mi to wiele do myślenia i w końcu po przeprowadzeniu kilku wywiadów środowiskowych przypomniałem sobie o potencjalnych przyczynach tego problemu. Mówienie o pozornie nieznaczących konfliktach między programistami a testerami w zespołach może nie docierać do wielu osób, które nigdy w zespole programistyczno-testerskim nie pracowały. Sam pamiętam czasy, gdy pracowałem w firmie, gdzie dział testerski znajdował się na pierwszym piętrze budynku, a programiści siedzieli na czwartym. Wielu z tych programistów nie spotkałem nigdy osobiście i nawet nie wiem o tym jak wyglądają, a co dopiero mówić o konfliktach i problemach komunikacyjnych w codziennej pracy face2face. To jeszcze jeden argument świadczący o tym, że niestety świadomość polskich firm IT o jakości oprogramowania i zapewnianiu tejże jakości jest dosyć niska w porównaniu do naszych kolegów i koleżanek z zagranicy.

Wisienką na torcie, a raczej kroplą, która przelała czarę goryczy była rozmowa z jednym z wysoko postawionych członków Stowarzyszenia Jakości Systemów Informatycznych (SJSI), który przy obiedzie opowiedział mi o swoich odczuciach po spotkaniu z Tom’em Gilb’em (jeden ze specjalistów od Lean Software Development), na którym Tom opowiadało o tym, że jakość oprogramowania wcale nie bierze się z jego testowania tylko jest zaszyta w nim dużo wcześniej. Testowanie oprogramowania a zwłaszcza wykrywane błędy to zwykły waste. Wspomniany przedstawiciel SJSI był pod wielkim wrażeniem powyższego stwierdzenia i niesamowicie zaskoczony jego trafnością (WTF!). Dlaczego dopiero teraz?! Mamy 2011 rok! 10 lat od opublikowania manifestu Agile, kilkanaście lat od powstania eXtreeme Programming, kilka lat od ogłoszenia Software Craftmentship Manifest, a w Polsce ludzie, którzy są odpowiedzialni za głoszenie informacji mających na celu poprawianie jakości wytwarzanego oprogramowania dopiero teraz odkrywają rzeczy, które na całym świecie są oczywiste od ponad dekady.

Tak jak kiedyś na moim blogu w komentarzu napisał Krystian Kaczor: “W tym roku jest konferencja TestWarez pod tytułem “Testować tradycyjnie, czy zwinnie?”. No co to za pytanie w ogóle? Może “Iść pod prąd, czy nie?””  Agile i wytwarzanie oprogramowania wysokiej jakości od samego początku jest faktem. To nie bajka, o której opowiadają gdzieś na mitycznym Zachodzie, to fakt, który bardzo szybko wykluczy polskie firmy IT, które nie będą w stanie sprostać wymaganiom narzucanym przez zagraniczną konkurencję.

Wiktor's Blog (in Polish): Procedury i narzędzia

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

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

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

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

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

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

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

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

Wiktor's Blog (in Polish): Spłata długów

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.

Wiktor's Blog (in Polish): Myśleć zwinnie

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

Wiktor's Blog (in Polish): Dług technologiczny

“Blog o jakości oprogramowania” – chyba łatwiej mi się pisze ostatnio o brakach w jakości oprogramowania niż o samej jakości.

Rozwój oprogramowania to bardzo złożony proces, na który wpływ ma wiele czynników, jednym z najważniejszych są szeroko rozumiane wymagania biznesowe. Wiadomo, jeśli nie wiadomo o co chodzi to pieniądze – po coś oprogramowanie się tworzy i przeważnie robi się to właśnie dla pieniędzy (nawet oprogramowanie Open Source jest w pewnym sensie tworzone dla pieniędzy, w mniej lub bardzie pośredni sposób ktoś na tym zawsze zarabia). W większości przypadków to tak zwany “Biznes” steruje rozwojem oprogramowania (w odpowiedzi na właśnie takie zapotrzebowanie powstały zwinne metodyki wytwarzania oprogramowania – by Biznes mógł jeszcze częściej i szybciej reagować na zmiany rynkowe). Niestety często bywa tak, że presja ze strony Biznesu jest na tyle duża, że zapomina się o tym by o wspomnianą na początku tej notki jakość dbać. Tworzy się nowe funkcjonalności zapominając o pisaniu testów, dokumentacji, refactoringu, odpowiednim projektowaniu etc. bo przecież nie ma na to czasu, liczy się tylko zwielokrotnianie zysków, dodawanie wartości do oprogramowania (testów, dokumentacji, projektowania nie da się w żaden sposób przeliczyć na wymierne korzyści finansowe) – w ten właśnie sposób tworzy się coś co nazywamy Długiem Technicznym (albo Długiem Technologicznym). Dług Techniczny (Technical Debt) swoją nazwę zawdzięcza podobieństwu do zwykłej pożyczki zaciągniętej w banku. Każdy pominięty test, nieudokumentowany ficzer, dodanie czegoś ad-hoc – bez odpowiedniego zaprojektowania prowadzi do obniżenia ogólnie pojętej jakości projektu, co w rezultacie prowadzi do widocznego spowolnienia rozwoju prac nad projektem.

Pozwolę sobie przytoczyć cytat z pewnego CTO, z którym miałem okazję kiedyś porozmawiać nt. jakości oprogramowania wytwarzanego przez podległych mu programistów: “Rok temu pracowaliśmy kilka razy szybciej, teraz wszystko jakby spowolniło – prawdopodobnie programiści się rozleniwili”. Wspomniany dyrektor był zdenerwowany tym, że rok wcześniej główny projekt firmy rozwijał się 6 razy szybciej niż obecnie. Domniemana przyczyną było “rozleniwienie programistów”,  którzy poczuli się zbyt bezpiecznie na swoich pozycjach – “przecież z tej firmy jeszcze nikogo nie zwolnili”. W odpowiedzi na domysły tego pana zadałem kilka pytań w stylu: Czy piszecie testy jednostkowe? Czy mierzycie pokrycie kodu testami? Jak wygląda wasza dokumentacja? Jak wyglądają wasze środowiska testowe? Czy możecie mi pokazać projekt architektury waszych aplikacji? etc… Na większość z tych pytań odpowiedź była negatywna (w sensie “nie, nie mamy czegoś takiego”). Przyczyną takiego stanu rzeczy była duża presja ze strony klientów, którzy wymagali jak najszybszych dostaw nowych ficzerów w celu zwiększenia zysków (co zresztą udawało im się przez dłuższy czas całkiem nieźle). Niestety nacisk tylko na wytwarzanie wartości biznesowej spowodował zanik takich praktyk jak testowanie, pisanie dokumentacji, czy nawet projektowanie – wszystko działo się ad-hoc, bez planu i spójnej wizji. W ten oto sposób powstał Dług Technologiczny, którego efektem było spowolnienie pracy. Nie wspomnę już o tym, że 80% czasu zajmowało łatanie dziur i naprawianie bugów.

Nazwa “Dług” nawiązująca do kredytu bankowego jest jak najbardziej adekwatna. Wyobraźmy sobie sytuacje w której w celu rozbudowania naszego przedsiębiorstwa i zwiększenie jego zysków zaciągamy kredyt w banku. Za uzyskane w ten sposób pieniądze inwestujemy w nowe maszyny, czy też zatrudniamy więcej ludzi co w pewnym stopniu zwiększa nasze zyski. Po jakimś czasie decydujemy się na jeszcze większe rozbudowanie naszego przedsiębiorstwa, więc bierzemy kolejny kredyt. Znowu zyski rosną. Robimy tak jeszcze kilka razy i nagle okazuje się, że owszem – mamy całkiem pokaźne przychody, ale większość zysków konsumują odsetki z zaciągniętych kredytów.

Sama świadomość tego, że taki dług zaciągamy jest już całkiem pozytywna – jeśli tylko WSZYSCY zdają sobie sprawę z konsekwencji takich a nie innych decyzji. Niestety z moich obserwacji wynika, że w większości organizacji z którymi miałem do czynienia ludzie nie mają pojęcia o czymś takim jak Technical Debt, lub nawet jeśli coś o tym, kiedyś słyszeli to nie potrafią wskazać u siebie miejsc w których taki dług jest zaciągany. Prawdę powiedziawszy to w każdej, nawet najlepiej zorganizowanej firmie zawsze znajdą się miejsca, w których w jakimś stopniu taki dług się nawarstwia.

Podobnie jak normalny kredyt, także Dług Techniczny trzeba w końcu spłacić. O tym jak można to robić napiszę następnym razem.

Wiktor's Blog (in Polish): Poszukiwany/Poszukiwana!

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

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

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

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

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

Szukamy też programistów PHP i Python.

Wiktor's Blog (in Polish): O przyszłości Agile…

Wracając taksówką z jednego ze szkoleń w Krakowie wdałem się z kierowcą tej taksówki w bardzo ciekawą konwersację na temat jakości dróg w mieście, organizacji ruchu, sposobach przeprowadzania remontów. Jak chyba każdy polak tak i ja i wspomniany taksówkarz oczywiście wiemy lepiej jak tego typu prace należy przeprowadzać. (Nie ukrywajmy, że da się to robić lepiej, spójrzmy na którychkolwiek naszych sąsiadów na zachód – w Holandii budowa tunelu pod autostradą trwa dwie doby w Polsce dwa lata…). Ogólnie rozmawialiśmy o oczywistych problemach, które każdy widzi tylko nikt nie ma wystarczająco dużej władzy – siły przebicia by móc te problemy rozwiązać. Gdy wysiadałem z taksówki kierowca powiedział do mnie coś co na początku wydało mi się zwykłą grzecznością ale w kontekście innej rozmowy z zupełnie innymi ludźmi nabrało zupełnie innego znaczenia. Taksówkarz powiedział mniej więcej coś takiego: “Dobrze, że są tacy młodzi ludzie jak Pan, którzy widzą to co się dzieje bo za parę lat być może, któryś z was będzie siedział na miejscu tych, którzy teraz decydują tam na górze i będzie podejmował znacznie lepsze decyzje, chociażby na podstawie tego o czym teraz rozmawialiśmy”. (A nie mówiłem, że zwykła grzeczność? )

Kolejną bardzo ciekawą rozmowę na zgoła odmienny temat odbyłem z dwoma znakomitymi (chyba najlepszymi i prawdopodobnie jedynymi w Polsce) trenerami, coachami, konsultantami Scrum/Agile (Pewnie niektórzy domyślają się o kim mowa ). Rozmawialiśmy między innymi o popularności Agile i o tym, że aby można było mówić, że Agile jest na prawdę popularne to musi ono zaistnieć w wielkich korporacjach. Moje stanowisko było bardzo sceptyczne – korporacje nie chcą zmian, a Agile może się okazać nieodpowiedni dla tego typu organizacji. Niemniej jednak korporacje jak wszystkie inne organizacje borykają się z wieloma problemami, które zwinne metodyki zarządzania projektami w bardzo prosty sposób rozwiązują. Ba – w związku z rozwojem rynku i samych organizacji pojawiają się coraz to nowsze i nie pasujące do żadnych wcześniejszych schematów problemy – tutaj Agile staje się jedyną słuszną drogą. Ale nie o tym chciałem napisać (pewnie rozpocznie się dyskusja na ten temat w komentarzach, do której serdecznie zapraszam)…

Kolejnym problemem, który poruszyliśmy był fakt, iż coraz więcej organizacji – korporacji, szkoli swoich pracowników niższego szczebla z zakresu Agile i Scrum, pomimo tego, że w tych organizacjach póki co nie ma szans na prawidłowe wdrożenie zwinnych metodyk wytwarzania oprogramowania. Wzbudziło to w nas pewne kontrowersje niemniej jednak w wyniku dalszej rozmowy wydaje mi się, że udało nam się znaleźć potencjalną przyczynę tego typu ruchów w organizacjach- o czym za chwilę. Oczywiście równie dobrze może to być nieracjonalne podążanie za modą i trendem – kto powiedział, że ludzie i organizacje zawsze postępują racjonalnie?

Jako że byłem najmłodszy i najmniej doświadczony w tym gronie (nie pracowałem jeszcze dla wielkiej korporacji) zostało mi postawione proste pytanie: “Jakiej metodyki będziesz używał jeśli zostaniesz managerem w korporacji?” – najprostsza i najszybsza odpowiedź jaka przyszła mi do głowy to “Scrum”. Potem padło stwierdzenie, że prawdopodobnie za jakiś czas zostanę wspomnianym managerem w korporacji – prawie każdy, kto chce się rozwijać i podążać jakąś ścieżką kariery w IT prędzej czy później zostaje project managerem w korporacji, a czasem zdarza się tak, że ten project manager awansuje i w pewnym momencie ma wystarczająco dużo mocy wykonawczej by podjąć decyzję o tym jaka metodyka/organizacja pracy ma być stosowana w całej organizacji.

Wnioski jakie z tego płyną pozostawiam jako temat otwarty. Według mnie z powyższych rozmów wynika kilka bardzo ważnych rzeczy – między innymi to, że będąc na dole mamy inne spojrzenie na organizację i dostrzegamy inne problemy – czasem znacznie więcej niż widać z góry, dlatego też potrzebna jest ciągła rotacja, która w sposób naturalny w większości organizacjach zachodzi – osoby, które były na dole awansują i mogą same rozwiązywać problemy, które do niedawna najbardziej ich dotykały. Oczywiście następuje też wymiana “wiedzy” pomiędzy organizacją i otoczeniem.

Wiktor's Blog (in Polish): Podsumowanie otwartego szkolenia “Rola testera w metodykach zwinnych”

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:

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

• 06-07.06.2011 Narzędzia w procesie testowania – Warszawa
• 27-28.06.2011 Zapewnianie jakości w Agile – Kraków
  (Jeśli powołacie się na mnie/mojego bloga podczas rejestracji to możecie liczyć na zniżkę 10-20%)
• W przygotowaniu także warsztaty/szkolenie z Automatyzacji testów  (“Od testera do inżyniera testów”), które skierowane jest do osób zajmujących się testowaniem (nie umiejących programować), które chciały by nauczyć się pisać testy automatyczne przy użyciu narzędzi open source.

Wiktor's Blog (in Polish): Jak przygotowuję szkolenia?

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.

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

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.

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

---