blog.testowka.pl

Archiwum wiadomości z Grudzień, 2012

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

Developerzy są jacyś inni…

opublikowany przez 10, Gru, 2012, w kategoriach Inne

Developer – dziwna istota spędzająca przynajmniej jedną trzecią swojego  życia przed ekranem komputera. Developer – magik które zwykłe literki na ekranie potrafi zaczarować w taki sposób, że stają się mniej lub bardziej ruchomymi obrazami. Developer – szaman zaklinacz zaklinający pliki z kodem źródłowym* (taka księga z zaklęciami) tak by wykonywały jego polecenia i na ekranie komputera wyświetlały dokładnie to czego potrzebuje. Developer – ufoludek posiadający nadzwyczajne moce pozwalające na manipulowanie tymi wszystkimi dziwnymi urządzeniami wykorzystującymi tzw. software.

Developer na co dzień pracuje ze złymi, choć czasem mało rozgarniętymi posłańcami piekieł nazywanymi managerami. Problem z managerami polega na tym iż dawno, dawno temu potężny zły czarownik nazywany rewolucja przemysłowa obdarował ich mocą zarządzania developerami. Od tamtej pory developerzy z całego świata są niewolnikami tejże mocy i muszą spełniać najdziwniejsze i nierzadko bezsensowne zachcianki managerów. Niedobrzy managerowie nie dość, że nękają biednych developerów to jeszcze czasem niemalże siłą wciągają niektórych z nich do swojej sekty mianując ich managerami.

Kilku developerów zbuntowało się. Niektórzy z nich niestety przeszli na ciemną stronę mocy i założyli własne firmy, w których powoli pod wpływem niewyjaśnionej siły stawali się managerami. Na szczęście pozostała garstka renegatów – buntowników nazywanych freelancerami. Ich życie jest często dużo trudniejsze niż życie normalnego developera niemniej jednak są oni wyzwoleni spod mocy managerów.

Kto zrozumie developera? Pewnie tylko inny developer.

A teraz na serio. Pracując jako niezależny Coach miałem przyjemność poznać na prawdę wielu niesamowitych developerów. Nie zawsze było też tak źle z managerami – niektórzy z nich wspaniale wspierają developerów w ich codziennej pracy. Developerzy kimkolwiek są, są troszeczkę inni niż „normalni” ludzie. Pracując z nimi zawsze mam nieodparte wrażenie, że znajduje się wśród ludzi niezwykle inteligentnych, znających się na tym co robią, lubiących to co robią i wykonujących swoją pracę z pasją (oczywiście zdarzały się też wyjątki potwierdzające tą regułę). Ludzie ci nie potrzebowali kontroli a co najwyżej pomocy w usuwaniu przeszkód powstrzymujących ich od wykonywania ich pracy dobrze. Właśnie na tym polega rola managera w Agile. Manager jest facilitatorem (nie znam polskiego odpowiednika tego słowa) – jego główne zadanie to ułatwianie pracy developerom bo to oni produkują wartość. Ci ludzie są zbyt mądrzy i inteligentni by nimi zarządzać! Aczkolwiek czasem potrzebują pomocy…

1 komentarz więcej...

„…i ludzie za to płacą?”

opublikowany przez 07, Gru, 2012, w kategoriach Agile, Zarządzanie

Ostatnio tłumaczyłem koleżance (warto dodać, że koleżanka nie ma nic z IT wspólnego – wręcz jest humanistką, po studiach humanistycznych) na czym ten cały Agile polega i po jakichś 15 minutach tłumaczeń padło z jej strony pytanie/stwierdzenie: „Ale zaraz, przecież to co mówisz jest oczywiste i naturalne… Nie ma w tym nic odkrywczego… I ludzie na prawdę płacą za szkolenia z tego?”

Dobrych kilka dni byłem przytłoczony tą rozmową. Może faktycznie miała rację – to co robimy i o czym opowiadamy jest takie… ludzkie… Nie ma w tym nic odkrywczego, w zasadzie re-odkrywamy na nowo pewne zachowania społeczne już dawno przez socjologów i psychologów opisane – co najwyżej pokazujemy empiryczne dowody na zapisane wcześniej teorie. Nauczamy o metodach radzenia sobie z problemami – metodach które wcale nie są nowe tylko powstały czasem wręcz kilkaset lat temu. Opieramy się o manifest Agile który jest wręcz oczywisty…

Indywidualności i interakcje… Co w tym odkrywczego? Każda organizacja to zbiór pewnych indywidualności i zachodzących pomiędzy nimi interakcji. To jest fakt – to nie teoria czy zasada, którą chcemy komuś narzucić. To jest natura – bo cała natura właśnie tak działa. Czymże jest natura jeśli nie właśnie złożonym systemem podsystemów w których indywidualne jednostki tworzą interakcji. Systemy – ekosystemy – nawet jest na to nazwa.

Współpraca z klientem… A da się w ogóle inaczej – przecież „klient” to ktoś komu zależy na tym oprogramowaniu nawet bardziej niż nam – developerom. To w jego interesie jest to by cały czas siedzieć z nami i pomagać nam rozwiązywać problemy. To w interesie klienta jest to byśmy my – developerzy mieli wszystko to czego potrzebujemy by wykonywać naszą pracę dobrze. I z naszej – developerów strony zależy nam na współpracy, gdyż ciągłe poprawianie czegoś wynikające z braku zrozumienia wymagań wspomnianego klienta jest po prostu nudne i nużące. Równie dobrze mogli byśmy już robić coś ciekawszego.

Działające oprogramowanie… Zaraz – to można produkować nie działające oprogramowanie? Po co wytwarzać niedziałające oprogramowanie? Przecież to jest cholernie oczywiste, że robimy to wszystko po to, by to co robimy działało i było używane przez użytkowników. Jeśli ktoś tworzy oprogramowanie z jakiegoś innego powodu to zapewne robi coś nie tak. I jak by nie było tylko „działające oprogramowanie” przynosi realną wartość i jest w stanie zarabiać pieniądze dla naszego klienta – patrzy punkt wyżej.

Reagowanie na zmiany… Całe nasze życie to ciągłe, nieustające reagowanie na zmiany… Cała nasza historia to historia reagowania na zmiany… Dlaczego w wytwarzaniu oprogramowania miało by być inaczej? Zmiany to naturalna kolej rzeczy – skoro nawet natura poradziła sobie z tym problemem – chociażby poprzez ewolucję, czy np. zmiany podczas przemian pór roku to dlaczego my mieli byśmy być jacyś wyjątkowi i na zmiany po prostu nie reagować, albo wręcz negować ich istnienie?

Tak! Cały ten Agile to nic nowego – jest to naturalne i oczywiste. Dlaczego więc ludzie w IT po prostu nie są w stanie sami dojść do tego? Czy to kwestia kulturowa? A może zaszłości historyczne? Pokorna natura ludzka? Brak kwestionowania tego co się dzieje dookoła? No ale przecież większość ludzi w IT to raczej osoby o ponadprzeciętnej inteligencji – dlaczego więc nie wpadli na to? Może po prostu z jakiegoś powodu jesteśmy upośledzeni, albo oślepieni? I nie – nie upatruję tutaj żadnego spisku (to nie brzoza, ani sztuczna mgła)… Pozostawiam pytanie otwarte – jeśli ktoś ma jakiś pomysł to chętnie posłucham…

1 komentarz więcej...

Wskroś funkcjonalność zespołu

opublikowany przez 04, Gru, 2012, w kategoriach Agile, Scrum, Zarządzanie

O  kros-funkcjonalności zespołów już kiedyś pisałem niemniej jednak warto ten temat poszerzyć. Wiemy już wszyscy, że zespół kros-funkcjonalny to taki, który posiada wszystkie umiejętności, które są potrzebne, by co iterację dostarczać potencjalnie gotowy do wydania inkrement i przeważnie nie potrzebuje do tego pomocy z zewnątrz. Ale co to tak właściwie znaczy? Jakie są te wszystkie umiejętności?

Zespół kros-funkcjonalny powinien posiadać kompetencje techniczne pozwalające na dostarczanie produktu. Powinien zatem mieć kogoś o umiejętnościach analitycznych, kto przeanalizuje wymagania i sprawdzi ich kompletność. Powinien mieć kogoś o umiejętnościach projektowania architektury, kto zaprojektuje dane rozwiązanie. Powinien mieć kogoś, kto wydevelopuje to rozwiązanie. Powinien w skład takiego zespołu wchodzić ktoś, kto sprawdzi czy wytworzona funkcjonalność nie zawiera błędów i czy została poprawnie zintegrowana z resztą systemu. Oczywiście może to być jedna osoba, która posiada kompetencje we wszystkich powyższych zakresach. Może to być kilka osób posiadających po kilka umiejętności, będących lepszymi w jednym z zakresów odpowiedzialności takiego zespołu a słabszymi w innych.

Nie ma problemu – zbudowanie takiego zespołu nie jest jakoś specjalnie trudne. Wystarczy w organizacji, która decyduje się na wprowadzenie kros-funkcjonalnych zespołów pozbierać ludzi z różnych działów i posadzić razem by nauczyli się pracować wspólnie. Oczywiście uformowanie się zespołu zajmie trochę czasu i pewnie po drodze pojawi się mnóstwo problemów do rozwiązania ale w większości przypadków powinno się udać.

Czy powyższe wystarczy by osiągnąć kros-funkcjonalność? Czy taki zespół będzie w stanie dostarczać inkrementy? Moim zdaniem nie zawsze – pytanie czym jest ten inkrement? Pytanie czym jest nasz produkt? Inkrement musi być w pełni działający i potencjalnie gotowy do wydania, co oznacza, że musi być zintegrowany. Problemu nie ma gdy nad produktem pracuje jeden czy dwa zespoły – integracja zachodzi w sposób ciągły i można poukładać pracę w taki sposób by zespoły nie wchodziły sobie w drogę. Sytuacja komplikuje się, gdy nad produktem pracuje znacznie więcej osób. Integracja staje się poważnym problemem i często nawet pomimo Continuous Integration zajmuje dużo czasu i powoduje wiele błędów. Oczywiście wszystko opiera się o komunikację pomiędzy tymi zespołami, oraz ustalenie wspólnych celów i klarowne rozpropagowanie wizji produktu jako całość a nie tylko poszczególne komponenty.

Idąc dalej tą drogą należało by usunąć bariery komunikacyjne pomiędzy zespołami i rozproszyć wiedzę. Colective Code Ownership jest pierwszym krokiem w tym kierunku. Aby zespół był wskroś-funkcjonalny i mógł dostarczać w pełni zintegrowany produkt co iterację potrzebne jest coś więcej niż tylko kros-funkcjonalność na poziomie umiejętności i kompetencji. Potrzebna jest również kros-funkcjonalność na poziomie znajomości budowanego produktu.

Problemem może okazać się tu zbytnia złożoność i skomplikowanie architektury produktu. Niestety z wielu różnych ewolucyjnych powodów większość produktów IT rośnie w zastraszającym tempie bez konkretnej wizji i pomysłu na architekturę, która pozwalała by na uniezależnienie od siebie poszczególnych komponentów. W takiej sytuacji powołanie zespołu, który poza kros-funkcjonalnością na poziomie umiejętności byłby również kros-funkcjonalny pod względem wiedzy na temat całego produktu jest wręcz niemożliwe. Niemniej jednak nie znaczy to, że nie można próbować. Rozproszenie wiedzy na temat całego produktu pomiędzy zespołami w efekcie może zaowocować stworzeniem spójnej wizji architektury stosowanych rozwiązań – co w efekcie sprawi, że refaktoryzacja będzie przebiegała w określonym kierunku.

Nawet jeśli jesteśmy w stanie powołać zespół/zespoły, które będę wskroś-funkcjonalne w obydwu wspomnianych powyżej wymiarach to jeszcze nie koniec zapewnienia kros funkcjonalności. Dopiero teraz zabawa się zaczyna. Dla takiego zespołu musimy w specjalny sposób formułować wymagania – „w specjalny sposób” czyli tak jak się powinno było to robić od początku. Wymagania muszą przecinać wszystkie warstwy i komponenty naszego systemu. Tworzenie wymagań z perspektywy użytkownika np. w formie User Stories powinno tutaj wystarczyć.

Ci z Was, którzy pracują nad „małymi” produktami wytwarzanymi przez małą ilość zespołów zapewne nie odczuwają opisanych powyżej problemów, natomiast pozostali zapewne teraz zastanawiają się jak wiele wspaniałych możliwości daje posiadanie w pełni wskroś-funkcjonalnych zespołów.

Dodaj komentarz więcej...