blog.testowka.pl

XP

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

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

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

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

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

1 komentarz więcej...

To nie proces ale ludzie odnoszą sukcesy

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

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

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

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

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

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

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

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

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

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

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

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

Dodaj komentarz więcej...

A mury runą, runą, runą…

opublikowany przez 13, Lip, 2012, w kategoriach Agile, Automatyzacja, CI, Programowanie, Scrum, Testowanie, XP, Zarządzanie

…i pogrzebią stary świat…

Tak wiem, że Kaczmarski miał niewiele wspólnego z wytwarzaniem oprogramowania. O jaki mur chodzi? Mur, który od lat budowaliśmy pomiędzy tzw. programistami i tzw. testerami. Często powstawały nawet fizyczne mury i bariery – chociażby odległość liczona w tysiącach kilometrów.

Od dawna już wiadomo, że zarządzanie poprzez konflikt (tutaj konflikt między testerami, a programistami) jest jedynie (o ile w ogóle) efektywne w krótkich okresach czasu – długofalowo niszczy motywacje i powoduje mnóstwo problemów wynikających z komunikacji. Programowanie (wytwarzanie oprogramowania) jest grą zespołową – zespół to nie tylko programiści. Zespół to też testerzy, zespół to także klienci, to czasem też docelowi użytkownicy – stawianie murów pomiędzy nimi powoduje jedynie wzrost złożoności i zwiększoną ilość problemów.

Cały ruch Agile czy metodyki takie jak Scrum, XP, Crystal heroicznie walczą z podziałami i sprowadzają się do zapewnienia odpowiednich interakcji pomiędzy ludźmi wytwarzającymi oprogramowanie. W efekcie powstają produkty wysokiej jakości.

Dlatego proszę oprócz fizycznych, technicznych i psychologicznych barier usuńmy też wszelkie inne spory i kłótnie. Męczą mnie już dyskusje na temat tego jakie testy powinien pisać/wykonywać tester a jakie programista? Czy to  na prawdę ma znaczenie?! Jeśli będziemy pracować razem, to prawdopodobnie osiągniemy dużo lepsze rezultaty. Co złego się stanie jeśli programista siądzie w parze z testerem i razem coś zakodują, albo przetestują?

Testowanie (czy to manualne, czy automatyczne) jest nieodłącznym elementem programowania. Bez testowania (jakiegokolwiek) oprogramowanie najprawdopodobniej nigdy by nie powstało. Bez programowania nie było by co testować. Cała idea inkrementalnego wytwarzania oprogramowania opiera się o nie dzielenie procesu wytwarzania oprogramowania na testowanie i kodowanie – robimy te rzeczy równolegle i ciągle.

Pisanie testów automatycznych jest równoznaczne z tworzenie tzw. kodu produkcyjnego. Gdy byłem na szkoleniu z Clean Code u Uncle Bob’a (Robert C. Martin) z wielkim oburzeniem mistrza spotkało się moje stwierdzenie, że rzadko tworzę kod produkcyjny, gdyż zajmuję się głównie automatyzacją testów. Testy automatyczne są kodem produkcyjnym – często dużo ważniejszym i bardziej wartościowym niż kod funkcjonalności aplikacji.

Nie stawiajmy więc sztucznych barier pomiędzy testowaniem a programowaniem – obydwie te czynności mają na celu dostarczenie produktu wysokiej jakości i na tym powinniśmy się skupić.

2 komentarze więcej...

Dlaczego automatyzujemy testy?

opublikowany przez 21, Cze, 2012, w kategoriach Agile, Automatyzacja, CI, Programowanie, Testowanie, XP

Mamy różne rodzaje testów. Jeśli chodzi o testerów to najczęściej zajmują się oni automatyzacją testów funkcjonalnych GUI czy też testami typu end-to-end.

Warto się zastanowić po co tworzymy takie testy automatyczne? Jeśli robimy to wyłącznie by przyspieszyć testowanie, to nie jest to najlepsza odpowiedź. Celem tworzenia takich testów powinno być poprawianie jakości – może nie bezpośrednio ale ogólnie testy automatyczne powinny przyczyniać się do poprawy jakości. Robię to poprzez dostarczanie szybkiej – dużo szybszej niż tester manualny informacji zwrotnej na temat działania produktu, a przede wszystkim na temat tego czy programista wprowadzając zmiany niczego nie zepsuł. Jest to niezwykle istotne zwłaszcza, gdy mamy do czynienia z systemami typu legacy – kaszana bez wyraźnej, przejrzystej architektury i testów jednostkowych. Systemy tego typu maja to do siebie że bardo trudne, o ile wręcz niemożliwe jest przetestowanie ich przy użyciu testów jednostkowych. Tworzenie unit testów do już istniejącego kodu, napisanego przed testami jest bardzo czasochłonne (swoją drogą to jeden z powodów dla którego niektórzy mówią, że pisanie testów jest strasznie kosztowne i czasochłonne). Kod który nigdy nie był pisany z myślą o testach jednostkowych, które będą go testowały często jest po prostu nietestowalny.

By móc poprawiać jakość naszego produktu musimy być w stanie poprawiać kod i jego jakość. Niestety bez szybkiej informacji na temat tego czy kod działa  – na przykład w postaci unit testów nie mamy nigdy pewności czy nasze zmiany niczego nie popsują, a co za tym idzie brakuje nam  odwagi by cokolwiek zmieniać i poprawiać. Pętla się zamyka – nie możemy zmienić nie testowalnego kodu tak by był testowalny bez obawy o to, ze czegoś nie popsujemy. Błędne koło się zamyka a dług technologiczny ciągle rośnie.

Jednym ze sposobów jest wdrożenie testów typu end-to-end które traktują testowany system jak „black box” lub „gray box”, do którego mają dostęp tylko w odpowiednich miejscach. Takie testy mają niestety kilka wad – na przykład są wolne i trudne w utrzymaniu.

Powyższe problemy to jeden z wielu powodów stosowania w projektach tzw. piramidy testów, która zakłada, że będziemy tworzyć jak najwięcej testów jednostkowych, trochę mniej testów funkcjonalnych i akceptacyjnych, a testów typu end-to-end nie będziemy tworzyć wcale, lub będą to tylko skrajne przypadki.

Takie podejście sprawdza się idealnie, rozpoczynamy projekt od zera i od samego początku postępujemy według wyżej wymienionych zasad. Niestety rzeczywistość jest inna. Na początku projektów informatycznych mało kto przejmuje się automatyzacja w ogóle, o testach jednostkowych i TDD już nawet nie wspomnę. Testy automatyczne wdraża się przeważnie dopiero, gdy zaczyna się już robić na prawdę niedobrze, a dług technologiczny daje o sobie znać na każdym kroku. W ten sposób powstają właśnie systemy typu legacy.

Gdy kilka miesięcy temu na konferencji 33rd degree podczas jednej z prezentacji Uncle Bob powiedział coś w stylu: „Nie piszcie testów end-to-end – one są złe”, a ja zobaczyłem bezmyślnie przytakujące głowy setek programistów siedzących na sali pomyślałem sobie: „Cholera – ostatnie 2 lata prowadzonej przez nas indoktrynacji w dziedzinie automatyzacji testów w naszym kraju właśnie trafił szlag…”. Miałem o to spory żal do Bob’a, który zresztą na niego wylałem w postaci bardzo długiej dyskusji na temat legacy code etc. Bob oczywiście na myśli miał projekty typu green-field, gdzie zaczynamy od zera. Oczywiście bardzo dobrze, że skorzystał ze swojego autorytetu i może przynajmniej kilka osób do tego przekonał, dzięki czemu w przyszłości będzie znacznie mniej systemów przepełnionych legacy code. Ale co z projektami, które już istnieją i które nadal trzeba rozwijać? To właśnie w takich projektach pracuje większość testerów (domyślcie się dlaczego).

Łatwo znaleźć rozwiązanie dla systemów już istniejących, gdy uświadomimy sobie, że celem testowania nie jest tylko testowanie samo w sobie ale też poprawa jakości. Podstawowym celem wdrożenia testów automatycznych jest zapewnienie możliwości wprowadzania bezpiecznych zmian – podobnie jak celem testów regresyjnych (które przypadkiem powstają przy wdrożeniu automatyzacji) jest dostarczenie informacji zwrotnej na temat tego, czy nasze zmiany nie wprowadziły błędów w istniejącej już funkcjonalności. Aby móc cokolwiek zmieniać tworzymy takie testy które dadzą nam przynajmniej ogólna informację na temat tego czy funkcjonalność która zmieniamy nie uległa popsuciu z punktu widzenia użytkownika.

W skrócie tworzymy odwróconą piramidę testów – z dużą ilością testów end-to-end i funkcjonalnych. Dzięki temu możemy zmieniać kod aplikacji i poprawiać jego jakość (refaktoryzować, zmieniać architekturę etc.) sprawiając, że staje się on testowalny także na niższych poziomach. Za każdą zmianą idzie dopisywanie nowych testów jednostkowych (a nawet to zmiany sterowane są pisaniem testów jednostkowych jak w TDD). Po pewnym, czasie mamy testowalny system z przejrzystą architekturą, w której każdą warstwę możemy przetestować oddzielnie, a GUI i logika w nim ograniczone są do minimum. To jest dobry moment by zacząć pozbywać się naszych testów typu end-to-end. Tak! Właśnie tak! Cały czas tworzyliśmy testy typu end-to-end z myślą o tym, że za chwilę je usuniemy. Największym kosztem podczas utrzymywania testów są duplikacje – więc jeśli tworzymy testy jednostkowe, które w przybliżeniu testują to samo co nasze testy end-to-end to oczywistym staje się potrzeba usunięcia tych, które są bardziej kosztowne i mniej wartościowe – end-to-end. W ten sposób stopniowo obracamy naszą piramidę testów i zaczyna ona powoli wyglądać tak jak powinna.

Celem całej naszej pracy nie jest zwiększenie pokrycia testami – co w podanym przykładzie mogło by doprowadzić do pokrycia nawet powyżej 100% (oczywiście zależy jak liczonego) – pytanie czy taka metryka cokolwiek nam mówi poza tym, że straciliśmy dużo czasu? Prawdziwym celem jest poprawa jakości, jakości na najniższym poziomie, zapewnienie poczucia bezpieczeństwa podczas wprowadzania zmian, wydzielenie odpowiednich modułów i domen w naszej aplikacji, odseparowanie modelu o danych, logiki od interfejsu użytkownika, itd.

Powyżej opisałem jeden (jak dotąd z pośród sprawdzonych przeze mnie w praktyce, jedyny działający) z kilku sposobów radzenia sobie z długiem technologicznym.

4 komentarze więcej...

Tester w Agile – sztuka zadawania pytań

opublikowany przez 31, Maj, 2012, w kategoriach Agile, Automatyzacja, Inne, Scrum, Testowanie, XP

Cały czas ludzie pytają mnie o to jaka jest rola testera w zespole pracującym wg Agile/Scrum? Jakie kompetencje powinien mieć taki tester? Czy wystarczy by tester w Agile tylko „klikał”? Jeśli klikanie to za mało to w jaki sposób poszerzać kompetencje testerów?

Rola testera w Agile jest niezwykle istotna! Szeroko rozumiane testowanie jest podstawą zwinnych metodyk wytwarzania oprogramowania. Przez „szeroko rozumiane” mam na myśli oczywiście nie tylko klikanie ale i automatyzację. Tak! Drodzy testerzy dobrze jeśli potraficie automatyzować testy – nie mówię tutaj o regularnym programowaniu, ale o ułatwianiu swojej i innych pracy. Oczywiście nie skreślam nigdy testerów klikających – ich wiedza i umiejętności są niewątpliwie istotne. Tester nie programujący/automatyzujący na co dzień może i powinien pełnić rolę „adwokata diabła” (klienta) – to tester potrafi najlepiej wczuć się w potencjalnego użytkownika testowanej aplikacji i spojrzeć na nią z zupełnie innej niż programiści perspektywy.

W trakcie sprintu/iteracji tester powinien poświęcać jak najwięcej czasu na… uwaga… testowanie. Testowanie to nie tylko wykonywanie scenariuszy czy też ich automatyzacja – to przede wszystkim zadawanie pytań. Pierwsze podstawowe pytanie zadawane, gdy ktoś oddaje coś do testów powinno brzmieć: „Czy to na pewno jest do testów gotowe?”, lub „Co programista rozumie poprzez zrobione?”. Ale czy moment „oddania do testów” jest pierwszą okazją do zadawania pytań? Oczywiście nie – pytać można dużo wcześniej – chociażby siadając z programistami i gdy nawet jeszcze nie przystąpią do swojej pracy zadawać pytania typu: „Jak zamierzasz to zaimplementować?”, „Czy wziąłeś pod uwagę taki scenariusz?”, „Jak to się ma do naszej Definition of Done?”. „Czy to na pewno wszystkie kryteria akceptacji jakie są wymagane by uznać tą funkcjonalność za skończoną?”. Oprócz programistów tester powinien gnębić swoimi pytaniami także klienta – doprecyzowując wymagania i eliminując wszelkie wątpliwości. Efektem ubocznym rozmów z klientem i programistami jest ciągłe poszerzanie wiedzy na temat testowanego produktu co w efekcie drastycznie podnosi jakość testów i przekłada się na produktywność całego zespołu.

Tester w Agile musi się wykazać pewną pro-aktywnością i samemu organizować swoją pracę. To tester powinien zawsze wychodzić na przeciw klientowi, użytkownikom czy programistom i aktywnie uczestniczyć w projekcie od samego początku.

Jeśli programiści korzystają z praktyk Programowania eXtremalnego (XP) takich jak programowanie w parach i Test Driven Development to nie ma lepszego miejsca dla testera niż siedzenie w parze z programistą. Oczywiście tester nie umiejący programować w kwestiach technicznych niewiele pomoże (przynajmniej na początku) ale już na przykład podczas dobierania odpowiednich przypadków testowych w TDD jego wiedza może być niezwykle przydatna. Tester w parze z programistą pełni rolę nawigatora (patrz google + pair programming). Tego typu podejście bardzo szybko sprawi, że tester poprzez najpierw zrozumienie kodu a następnie czynny udział w programowaniu będzie rozwijał swoje umiejętności potrzebne do automatyzacji testów i nie tylko.

Kolejny temat, który ostatnio ktoś poruszył to problem z testerami, którzy uważają, że naturalną ścieżką kariery testera jest w pewnym momencie zostanie (młodszym) programistą. Ogólnie uważam, że nie ma w tym nic złego – jeśli weźmiemy pod uwagę fakt że programowanie to gra zespołowa to posiadanie w zespole programisty z backgroundem testerskim niezwykle ułatwia życie. Taki programista/tester jest w stanie fachowo wspierać kolegów testerów w momencie, gdy akurat zadań dla testerów jest więcej. Ponadto bagaż doświadczeń zdobytych na stanowisku testera sprawia, że taka osoba dużo lepiej rozumie istotę i problemy związane z testowaniem więc wykorzystując swoje umiejętności programistyczne może skutecznie ułatwiać pracę testerów. Z drugiej strony kto by tam chciał być programistą gdy testowanie jest takie ciekawe! 😛

Powyższe to tylko kilka moich pomysłów, a w zasadzie zbiór prywatnych doświadczeń związanych z testowanie w zespole pracującym wg Agile/Scrum. Z chęcią posłucham o Waszych pomysłach a przede wszystkim doświadczeniach co do tego jak pracować w takim zespole – w komentarzach jest dużo miejsca…

6 komentarzy więcej...

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

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

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

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

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

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

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

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

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

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

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

3 komentarze więcej...

To jest tak proste, że aż się prosi by to uprościć.

opublikowany przez 05, Gru, 2011, w kategoriach Agile, Scrum, XP

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.

2 komentarze więcej...