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.

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.

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.

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.

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.

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.

Jakiś czas temu znalazłem ogłoszenie w którym ogłoszeniodawca szukał między innymi testerów do dużego projektu jakim miało być przepisanie systemu wspierającego bankowość elektroniczną pewnego banku.

Poniżej fragment ogłoszenia:

“Projekt ma trwać ok. 4-5 lat i jest organizowany przez 6 krajów: Polskę, Chiny, Brazylię, Stany Zjednoczone, Singapur i Indie. Na całym świecie do tego projektu ma być zatrudnionych 2000 osób”

Jestem w stanie zrozumieć, że systemy bankowe są dosyć skomplikowane (miałem z nimi trochę do czynienia) niemniej jednak 4-5 lat dla jakiegokolwiek projektu IT to perspektywa niesamowicie abstrakcyjna (przynajmniej dla mnie). Jeśli już na wstępie pomysłodawcy zakładają taki okres czasu to w jaki sposób uwzględnią zmiany jakie przez ten okres mogą się pojawić. Przez “zmiany” mam na myśli chociażby zmiany prawne, nie wspominając już o tym, że w takim okresie czasu mogą powstać zupełnie nowe technologie, które zrewolucjonizują tą branżę etc. Kolejny element ogłoszenia - 2000 osób [SIC!] – a po co aż tyle? – co oni chcą cały system operacyjny (albo cztery) do tego napisać, czy co? (a może… kto wie…). Skład narodowy zaangażowany w ten projekt też o czymś mówi – czyżby dewiza “zróbmy to tanio”?

Nie mówię, że się nie uda – w 5 lat można na prawdę wiele zrobić. Nawet jeśli 3/4 albo 9/10, a nawet 95/100 z tych ludzi będzie robiło rzeczy zupełnie bez sensu i zbyteczne to powinno się udać stworzyć ww. system bankowości elektronicznej, który być może będzie nawet działał lepiej od tego, który ów bank posiada obecnie. Pytanie tylko “Po co angażować tyle osób skoro prawdopodobnie można by było to zrealizować przy udziale kilkunastu do kilkudziesięciu osób?”.

Pozostaje mi tylko życzyć powodzenia. A gdyby przypadkiem zajrzał tutaj któryś ze szczęśliwie zatrudnionych do tego projektu to z chęcią usłyszę jakieś relacje z postępów prac.

Powyższe ogłoszenie najprawdopodobniej wynika z podejścia do wytwarzania oprogramowania i zarządzania projektami zawierającego taki termin jak “zasoby ludzkie” – wspomniane podejście zakłada, że jeśli praca postępuje zbyt wolno to należy dostarczyć więcej “zasobów” w postaci programistów/testerów/stażystów/praktykantów/whatever. Takie “zarządzanie zasobami ludzkimi” w wielu organizacjach doprowadziło do niesamowitego wzrostu liczby pracowników tworzących (z punktu widzenia funkcjonalności) względnie proste rzeczy, pracujących w środowisku w którym narzut komunikacji z tak dużą ilością osób na około jest tak duży, że praktycznie nie da się zrobić nic. Z zaszłości historycznych systemów wytwarzanych przez jakiś czas przez tak dużą ilość osób wynika nadzwyczajne skomplikowanie tych systemów – każdy programista pisze po swojemu i rozwija system w swoją stronę, z problemów komunikacyjnych wynika rosnąca ilość duplikacji i kierunków (wizji) w jakich system podąża etc. do większej ilości kodu potrzeba więcej osób, które w jakiś magiczny sposób posiądą tajemną wiedzę przynajmniej o jakimś wycinku funkcjonalności tworzonych produktów i w ten sposób spirala sama się nakręca.

Na jednej z prezentacji na konferencji ALE w Berlinie przedstawiono ciekawą teorię na temat tego, że Agile może wydajnie działać w organizacjach nie przekraczających 200 osób, gdyż średnio właśnie tyle osób każdy człowiek jest w stanie poznać, zapamiętać i z tyloma osobami jest w stanie utrzymywać mniej lub bardziej bliskie kontakty, a przede wszystkim jest w stanie spamiętać czym dana osoba się zajmuje. Podobnie liczba optymalna osób w zespole 5-12 to liczba wynikająca z naszej natury – mniej więcej tyle jest średnio liczba osób w rodzinie (powyższe wynika z uwarunkowań genetycznych, historycznych i ewolucyjnych).

Ponadto żeby skutecznie wdrożyć Agile w organizacji potrzeba przekonać do tego jak największą ilość osób, w tak dużych organizacjach przekonanie do czegokolwiek nawet połowy osób jest z góry skazane na niepowodzenie (lub zajmie nieskończoną ilość czasu).

Agile stawia na małe zespoły, które potrafią w krótkim czasie przy minimalnym narzucie komunikacyjnym dostarczyć działające oprogramowania wytworzone w sposób prosty. Niektórzy mówią nawet o ekstremalnie prostym programowaniu – stąd właśnie termin Extreeme Programming (XP). Przeważnie skomplikowanie rozwiązań wynika z problemów komunikacyjnych w organizacji, traktuje o tym między innymi Prawo Conway’a które obrazuje to jak problemy komunikacyjne między ludźmi wpływają na problemy integracji systemów tworzonych przez tych ludzi.

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.

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.

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.

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