blog.testowka.pl

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

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

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

Funkcjonalność                      Czas

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

Budżet                                       Jakość

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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.

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.

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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.

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

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

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

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

Mindmapa do szkolenia "Zapewnianie jakości w Agile"

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

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

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

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

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

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

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

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

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

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

Retrospekcja podczas szkolenia.

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

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

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

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

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

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

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

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

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

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

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

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

Tajemniczy tytuł Shu-Ha-Ri to zaczerpnięte z kultury japońskiej trzy poziomy doświadczenia, często używane w kontekście sztuk walki takich jak aikido. Piszę o tym, gdyż nauka sztuk walki ma zaskakująco wiele wspólnego z wdrażaniem metodologi w organizacji. Trzy poziomy doświadczenia, trzy poziomy wtajemniczenia wymuszają na uczniu stopniową, systematyczną naukę dzięki czemu eliminuje się większość błędów.

Shu – przyswojenie, zachowanie, pielęgnacja
Jest to pierwszy etap nauki, w której uczeń skupia się na opanowaniu podstawowych technik i zachowań. Termin ten oznacza także lojalność wobec jednego nauczyciela. Podczas tego etapu najważniejsze jest przyswajanie wszystkiego z największa dokładnością bez możliwości wprowadzania jakichkolwiek zmian. W tej fazie nieistotne są powody stosowania technik, najważniejsze jest opanowanie do perfekcji podstaw. (Przypomina mi się scena z “Karate Kid” w której dzieciak uczy się podstawowych ruchów myjąc samochody ). Nie wszyscy zdają sobie sprawę z tego jak ważne jest zbudowanie podstaw, by móc z powodzeniem dalej rozwijać swoje umiejętności. Na poziomie Shu okazuje się, że do osiągnięcia celu jakim jest efektywne wykorzystanie umiejętności wystarczająca jest jedna droga, stąd też wymóg lojalności do nauczyciela i posłuszeństwo. Ta stara zasada jasno pokazuje, że mieszanie różnych technik a w naszym przypadku metodologi wprowadza chaos i doprowadza do sytuacji, w której mamy dużo różnych umiejętności ale nie reprezentują one żadnej wartości praktycznej ani technicznej jako całość. Według tradycji to nauczyciel decyduje o tym kiedy uczeń może zakończyć ten etap i przejść na poziom Ha.

Ha – odłączenie, zerwanie z tradycją
Drugi etap nauki polega na uwolnieniu się do pewnego stopnia od klasycznych metod. W tej fazie ważne jest by odnaleźć i zrozumieć powody technik nauczonych na poprzednim etapie. Tutaj zaczyna się sztuka, odłączenie od codziennie powtarzanych czynności i stopniowe rozwijanie technik. Na tym etapie uczeń rozpoczyna własne eksperymenty, powinien być gotowy na to by samodzielnie analizować i myśleć nad powodami wykorzystywania niektórych technik po to by w przyszłości samodzielnie je rozwijać i dołączać nowe. Cała dostępna wiedza została zdobyta, teraz uczeń musi nabyć doświadczenia.

Ri – uwolnienie
Ostatni etap, w którym uczeń staje się mistrzem, uwalnia się od tradycji, przechodzi poza granice. Uczeń posiadający duże doświadczenie i wiedzę może je wykorzystywać w życiu codziennym. Na tym etapie uczeń już nie uczy się sztuki walki od innych tylko tworzy swój własny niepowtarzalny styl. Dopiero tutaj możliwe jest całkowite uwolnienie od standardów i podstaw. Tutaj uczeń/mistrz może pozwolić sobie na niekonwencjonalność, która dzięki zdobytej wcześniej wiedzy i doświadczeniu ma bardzo duże szanse na sukces.

Jak to wszystko ma się do wdrażania metodologii? Miałem nie do końca przyjemną okazję kilkukrotnego obserwowania prób wdrożenia metodologi/narzędzi (Scrum, Kanban) w różnych organizacjach, które zakończyło się porażką. Porażka ta według moich obserwacji wynikała między innymi z tego, że wdrażający zakładali, iż członkowie zespołu i oni sami są co najmniej na poziomie Ha, z tym że wielokrotnie brakowało im wiele do osiągnięcia Shu – nie znali, bądź nie potrafili stosować podstaw. Ponadto wdrożenia typu “weźmy planowanie ze Scrum, tablicę z Kanban ale nie stosujmy na niej limitów, do tego eliminujmy waste za pomocą narzędzi Lean i nazwijmy to wszystko Agile to może nam coś tego wyjdzie” ciężko jest nazwać wdrożeniem. Jak już pisałem w notce o automatycznym chaosie jeśli wdrażamy coś w organizacji to przede wszystkim musimy wiedzieć co wdrażamy i mieć jakiś, co najmniej ogólny plan wdrożenia. Pisałem też już kiedyś o teorii i jej zestawieniu z praktyką, moje doświadczenia jasno pokazują, że teorie sprawdzają się w przygniatającej większości przypadków jeśli tylko spełni się jeden zasadniczy warunek – postępuje się według jednej teorii od początku do końca.
Miałem okazję jakiś czas temu wspierać jeden mały zespół podczas wdrażania Scrum, postanowiłem zastosować zasadę Shu-Ha-Ri. Na początku pokazałem im wszystkie artefakty, pokazałem jak powinno wyglądać planowanie, jak rozbijać zadania, jak rozmawiać podczas spotkań typu stand-up oraz wyjaśniłem klientowi w jaki sposób opisywać wymagania. Po dwóch sprintach, podczas których na prawdę sumiennie starali się przestrzegać wszystkich zasad, praktycznie nie musiałem już tłumaczyć po co to wszystko było – sami dobrze wiedzieli co zyskali porównując sytuację obecną z poprzednimi projektami i z łatwością potrafili wskazać przyczyny stosowania takich a nie innych technik. Obecnie po trzech miesiącach zespół skutecznie wprowadza własne usprawnienia do stosowanej metodologi – starają się używać TDD, programują w parach, robią regularne przeglądy kodu. Wielce pomocne okazały się retrospekcje, które dosyć szybko definiowały problemy, a metoda systematycznego wprowadzania poprawek do procesu owocuje polepszeniem jakości pracy a także lepszą atmosferą i motywacją wynikającą każdorazowo z sukcesu jakim jest eliminacja błędów z procesu.

Po raz pierwszy o Shu-Ha-Ri przeczytałem w książce Alistera Cockburn’a “Agile Software Development – Gra Zespołowa”, którą polecam. Lektura zachęciła mnie do dalszego drążenia tematu, którego efektem jest ta notka

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

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

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

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

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

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

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

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

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

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

Gra w golfa a Scrum

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

Wprowadzenie

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

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

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

#1 Nie skupiaj się na piłce

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

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

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

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

#2 Skup się na celu, nie na przeszkodach

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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