blog.testowka.pl

XP

Trzech developerów – czyli krótka historia z morałem

opublikowany przez 09, Kwi, 2015, w kategoriach Agile, Automatyzacja, TDD, Testowanie, XP

5597863793_60f320a45d_o

Trzech programistów zostało zapytanych o to jak długo zajmie im przejście przez pole do domu?

Junior Developer popatrzył na dystans dzielący go od domu i powiedział: „Nie wygląda żeby było daleko  – zajmie mi to 10 minut”. 

Senior Developer popatrzył uważnie na pole i powiedział: „Powinienem być w stanie dotrzeć tam w ciągu dnia”. Oczywiście zdziwiło to Junior Developera. 

Ninja Developer popatrzył na pole i powiedział: „Wygląda na dziesięć minut drogi, ale myślę, że piętnaście minut będzie odpowiednią estymatą”

Junior Developer wystartował ale po kilku krokach wybuchła pierwsza mina zakopana na polu co sprawiło, że Junior Developer musiał zboczyć z najprostszej drogi. Po tym jak wielokrotnie musiał zawracać wysadzając po drodze kolejne miny, po dwóch dniach udało mu się dotrzeć do celu. Oczywiście nie obyło się bez ran.

Senior Developer od razu rozpoczął swoją podróż na czworaka uważnie sprawdzając każdy metr drogi i przemieszczając się tylko tam gdzie jest bezpiecznie. Oczwiście kilka razy natknął się na minę ale zdążył dotrzeć do celu w trochę ponad jeden dzień. 

Ninja Developer wystartował i spokojnie przeszedł przez pole do celu. Dotarł tam po dziesięciu minutach. 

Dwaj pozostali programiści zszokowani zapytali: „Jak udało Ci się to osiągnąć?”, „Jak przeszedłeś przez pole nie wysadzając żadnej miny?”

„To było łatwe” odpowiedział Ninja Developer – „Po prostu nie zakopałem tam tych min wcześniej”.

[znalezione na Quorze  i przetłumaczone na nasze]

Konkluzja: Emergent Architecture – fajna sprawa, ale warto czasem pamiętać o reużywalności i możliwościach rozwoju naszego kodu. Warto też mieć testy automatyczne, które przez takie pole minowe nas spokojnie, może trochę powoli, ale jednak bezpiecznie przeprowadzą.

 

 

Dodaj komentarz więcej...

Coding Dojo – TDD Kata

opublikowany przez 31, Mar, 2014, w kategoriach Agile, Automatyzacja, CI, TDD, XP

Kanji-shu-ha-ri507
Kilka tygodni temu miałem przyjemność poprowadzić dla jednego z moich klientów krótki warsztat w formie Coding Dojo. Na codzień z tymi zespołami pracujemy nad wdrożeniem Continuous Delivery oraz innych praktyk związanych z Agile. Dojo nie było częścią regularnego Agile Coachingu, ale pomyśleliśmy, że może być dobrą formą oderwania się od codziennej pracy, wyjścia ze strefy komfortu i nauczenia się czegoś nowego. I tak też chyba się stało.

Po pierwsze czym jest Coding Dojo?

Dojo to termin pochodzący z języka japońskiego oznaczający „miejsce treningu”. Odnosił się on do trenowania sztuk walki takich jak Kendo czy Aikido. Nie jest to zwykła sala treningowa, gdyż obowiązują na niej pewne zasady, wchodząc do Dojo zgadzamy się postępować zgodnie z obowiązującymi tam normami.

Coding Dojo to również miejsce gdzie chcemy potrenować nie tyle sztuki walki co sztuki tworzenia kodu. Tutaj też obowiązują pewne zasady, o których za chwilę…

Podczas Coding Dojo zgromadzeni programiści próbują rozwiązać określony problem. W naszym przypadku podeszliśmy do problemu „String Calculator” – prosty kalkulator obliczający sumę parametrów podanych na wejściu. Backlog do tego zadania udostępniłem tutaj.

Zasady

Dojo zorganizowaliśmy w formie TDD Kata oraz podzieliliśmy je na 4 iteracje. Każda iteracja to 30 minut kodowania, 6 minut na code review i 6 minut na wspólną retrospekcję.

Uczestnicy programowali w parach. Po każdej iteracji zmiana pary, poniżej więcej na ten temat.

W przeciwieństwie do typowego Code Retreat po każdej iteracji nie usuwaliśmy wytworzonego kodu tylko kontynuowaliśmy poprzednio zaczętą pracę.

Przebieg Coding Dojo

Pierwsza iteracja to dla większości uczestników pierwsze kroki w TDD (niektórzy mieli już pewną wprawę, niemniej jednak przypomnienie zasad każdemu się przydało) – programujemy zgodnie z zasadą Red -> Green -> Refactor. Co 3 minuty zmienia się osoba przy klawiaturze – to wymuszało komunikację. TDD Kata to ćwiczenie służące do doskonalenia swoich umiejętności.

Po blisko pół godziny tworzenia kodu przyszedł czas na Code Review, ze względu na to, że było około 20 osób postanowiliśmy, że w ramach Code Review wymieszamy pary, praca każdej pary musiała zostać przejrzana przez kogoś z innej pary. Ta praktyka pozwoliła bardzo szybko pokazać różnice pomiędzy parami i poszczególnymi uczestnikami, a następnie pozwoliła wymienić się zdobytą wiedzą i spostrzeżeniami.

I oczywiście wspólna retrospekcja, podczas której rozwiewaliśmy wszelkie wątpliwości i omawialiśmy problemy oraz spostrzeżenia.

W drugiej iteracji wprowadziłem dwie zmiany – po pierwsze postanowiliśmy stosować TDD ping-pong. Jest to metoda programowania w parze polegająca na tym, że pierwsza osoba pisze test, druga pisze funkcjonalność spełniającą ten test, pierwsza refaktoryzuje, druga pisze test itd. To ćwiczenie pozwoliło uczestnikom lepiej dostrzec różnice pomiędzy poszczególnymi etapami w pętli TDD, oraz to czym się różni TDD od Test-First.

Drugą zmianą (nie do końca w mojej ocenie udaną, powinienem zostawić to na trzecią iterację) był zakaz rozmawiania podczas kodowania. Znacznie lepiej było by, gdybyśmy wprowadzili to w następnej iteracji, po tym jak już uczestnicy opanowali podstawy pętli TDD. Celem wprowadzenia tej zasady było wymuszenie pisania na tyle czytelnego kodu by druga osoba mogła łatwo zrozumieć intencje. Niemniej jednak było to całkiem zabawne nawet pomimo tego, że jeszcze nie wszyscy zrozumieli dobrze zasady TDD w tej iteracji. Braki nadrobiliśmy w kolejnej.

Trzecia iteracja po Code Review i Retrospekcji była podobna do poprzedniej z tą różnicą, że teraz można było już rozmawiać. To zaowocowało ożywionymi dyskusjami, oraz dzieleniem się pomysłami, które nagromadziły się w poprzedniej iteracji, oraz podczas Code Review. W efekcie było dużo refactoringu.

Iteracja czwarta – „porzuć swój kod”. Ponieważ w życiu programisty bardzo często bywa tak, że musi grzebać się w kodzie, którego sam nie tworzył postanowiłem podczas naszego Coding Dojo również zrobić taki eksperyment. Tym razem zasada przy dobieraniu się w pary była prosta – wszyscy wstają od komputerów przy których siedzą i starają się dobrać w pary z kimś z kim jeszcze nie programowali oraz wspólnie usiąść przy komputerze przy którym jeszcze nie siedzieli.

Była to chyba jeden z najciekawszych eksperymentów jaki przeprowadzałem na ludziach (i ich kodzie) ;-). To niesamowite jak bardzo różnie można zaimplementować te same funkcjonalności oraz na jak wiele różnych pomysłów można wpaść w zależności od tego z kim się pracuje. Podczas tej iteracji niektórzy zawzięcie refaktoryzowali (pamiętając o zasadach TDD) inni starali się dodawać nowe funkcjonalności przyjmując zastane konwencje.

W ramach przedłużonego Code Review po tej iteracji poprosiłem by wszyscy wracali do wszystkich komputerów, przy których mieli okazję wcześniej pracować i dokładnie przejrzeli co stało się z „ich” kodem odkąd opuścili to miejsce (nie tylko w ostatniej iteracji ale także w poprzednich).

Wnioski

Pojawiło się kilka ciekawych pytań i wniosków oto kilka z nich:

„Tworząc kod w ten sposób widzę, że implementując w sumie prosty problem poprzez stosowanie TDD wydłużył się czas implementacji oraz tak na prawdę spadła jakość tego co zrobiłem – gdybym nie stosował TDD to zrobił bym to szybciej i lepiej”. 

Moja odpowiedź brzmiała: Tak! Gdybyś dzisiaj to zaimplementował bez TDD to zrobił byś to ładniej (i może nawet napisał byś testy). Niemniej jednak w TDD Kata chodzi właśnie o dążenie do perfekcji i doskonalenie swoich umiejętności. Tego typu ćwiczenia wykonujemy właśnie po to, by za którymś razem napisać ten kod jeszcze lepiej i szybciej używając TDD, gdyż ta metoda ma wiele innych zalet, które warte są poświęcenia czasu potrzebnego na jej dobre opanowanie.

„TDD jest proste, gdy tworzymy nową funkcjonalność – a co jeśli mam już sporo kodu i to nawet z testami i nagle przychodzi zmiana wymagań. Co jeśli mam na przykład 5000 testów? Mam teraz szukać i zmieniać wszystkie testy zanim wprowadzę zmiany?”

Moja odpowiedź: jeśli wiesz, które testy trzeba zmienić i możesz to w miarę prosto i szybko zrobić to to zrób. Jeśli nie wiesz to… napisz nowy test, wprowadź testowaną zmianę w zachowaniu aplikacji, odpal testy i zobacz które testy przestały przechodzić. Potem zastanów się czy testy, które przestały przechodzić zrobiły to. bo zmieniło się zachowanie, czy dlatego, że coś zepsułeś. Następnie przemyśl, czy poprawiając testy przypadkiem nie duplikujesz tych, które przed chwilą napisałeś. Jeśli nie, to zastanów się, czy zmiana w funkcjonalności, którą wprowadziłeś nie była przypadkiem zbyt duża i nie miała jeszcze innych niechcianych konsekwencji. Jeśli wszystko jest ok, to powtórz powyższą pętlę aż wprowadzisz wszystkie zmiany.

Moja ogólna rada – nie bójcie się czerwonych testów. One właśnie po to są by często nie przechodziły i pokazywały Wam status systemu. Jeśli zastosujecie zasady z Clean Code oraz dobrze przemyślicie swoje testy to analiza tego dlaczego nie przechodzą będzie łatwa i przyjemna, a co za tym idzie wniesie to znaczną wartość do Waszej pracy.

Reasumując

Coding Dojo w tej formie jest w mojej ocenie bardzo fajnym ćwiczeniem wartym polecenia każdemu zespołowi. Przedmiotem Dojo wcale nie musi być TDD Kata – możecie spróbować zmienić się z zupełnie innym problemem nawet niekoniecznie programistycznym. Najważniejsze jest to, by wykonywane ćwiczenia wnosiły jakąś wartość i pozwalały Wam poszerzyć wiedzę.

Dojo, które przeprowadziłem z zespołem B&T Skyrise miało na celu przede wszystkim poszerzenie wiedzy na temat TDD oraz nabranie wprawy w praktykach Code Review. Myślę, że cel został osiągnięty.

PS: Niezmiernie ciekawi mnie, czy któryś z uczestników spróbował później podejść do samodzielnego rozwiązania jakiejś TDD Katy… Sprawdzę to przy najbliższej okazji.

1 komentarz więcej...

Komentarz do: „Błąd Arystotelesa w IT”

opublikowany przez 26, Lut, 2014, w kategoriach Agile, CI, Scrum, XP

[W ostatnim wydaniu Computerworld pojawił się artykuł autorstwa Bogdana Berezy zatytułowany „Błąd Arystotelesa w IT„, który wręcz domagał się komentarza. Nie chodzi tyle o jakieś rażące błędy merytoryczne ale raczej o niedomówienia i drobne naginanie faktów, które troszeczkę zaciemniają prawdziwy obraz. Komentarz jednak trochę urósł więc zrobiła się z tego też notka na blogu – poniżej… zapraszam do dyskusji]

Wygląda na to, że autor pisząc o testowaniu w Agile jako o czymś co jest w 85% takie samo jak „zwykłe” testowanie chyba nie do końca zdaje sobie sprawę z tego czym faktycznie testowanie w Agile różni się od testowania w procesach „tradycyjnych”.

Pamiętam jak kilka dobrych lat temu zmieniłem pracę przenosząc się z organizacji pracującej wg tzw. Modelu Kaskadowego opatrzonego normami ISO i certyfikatami CMMI do prawdziwie zwinnego zespołu pracującego w Scrum… Różnica była zasadnicza!

Oczywiście zgadzam się, że samo testowanie to testowanie i nie różni się niczym w obydwu podejściach… Smutny jest fakt, że wielu „testerów” w tym obszarze ma nadal poważne, podstawowe braki dotyczące technik testowania i projektowania testów, pomimo nawet uczestnictwa w wielu certyfikowanych szkoleniach, które częściej bardziej uczą jak zdać egzamin, niż jak faktycznie coś dobrze przetestować (oczywiście zdarzają się wyjątki)…

Wracając do różnic pomiędzy Agile a nie-Agile… Już na przykład: rola testera, jego miejsce w zespole i organizacji, wartość i sposoby komunikacji, zasadnicza przewaga bezpośredniej współpracy wewnątrz zespołu wskroś-funkcjonalnego ponad przerzucanie się zgłoszeniami bugów pomiędzy działem testów i działem programowania, częstotliwość testowania, feedback dla programistów, proporcje pomiędzy testami regresyjnymi a testami akceptacyjnymi zupełnie nowych funkcjonalności, rola automatyzacji testów i jej wsparcie w procesie testowym i procesie zapewniania jakości oprogramowania, ciągła integracja i ciągłość testowania to tylko niektóre z różnic, o który autor zdaje się zapominać… Jest tego trochę więcej niż by mogło się, a przynajmniej na tyle więcej że potrafimy nad tym pracować przez ponad 80% czasu na naszych warsztatach z Testowania w Agile na które serdecznie autora zapraszam.

Samo omawianie od podstaw metod zwinnych w 2014 roku jest już raczej zbyteczne.
Agile nie jest już żadną nowością – 13 lat praktyki od Manifestu Agile popartych wieloma sukcesami to przy obecnym tempie naszego życia i rozwoju chyba już całkiem sporo. A początków Agile można się doszukiwać w okolicach 1991 roku, a jak twierdzą niektórzy (np. Tom Gilb) jeszcze jakieś 20 lat wcześniej…

Co do samej terminologii stosowanej w Agile to… „Jeśli chcesz coś zmienić to musisz coś zmienić” – terminologia i używany język są dobrym punktem startu. Ma to głębokie uzasadnienie zwłaszcza, gdy potrzebujemy zmienić istniejącą organizację.

Podsumowując – nie rozumiem co autor miał na myśli krytykując realnie działające (przynajmniej na podstawie moich kilkuletnich doświadczeń) metody jakoby były one zupełnie nienaukowymi „modnymi bzdurami”. Tym bardziej, że metody te również mają podstawy w nauce – może bardziej w psychologii i naukach humanistycznych niż inżynierii ale jednak…

Przypominam, że „Waterfall” również kiedyś był modną bzdurą, która z siłą wodospadu miała popychać projekty IT do przodu…
Zmieniła się jednak rzeczywistość i mechanizmy współczesnego wytwarzania oprogramowania przez co dawne metody przestały działać… Już widać, że Scrum powoli przestaje być wystarczający na współczesnym rynku, a wydania raz na dwa tygodnie wywołują uśmiech na twarzach praktyków Continuous Delivery pracujących w organizacjach tworzących produkty według zasad Lean Startup (gdzie nikt nie wspomina nawet o rzeczach z ich perspektywy tak archaicznych jak inżynieria wymagań)

6 komentarzy więcej...

Agile dla „dużych projektów” nie działa

opublikowany przez 19, Wrz, 2013, w kategoriach Agile, Kanban, Scrum, Testowanie, XP, Zarządzanie

5665717830_dfe3ea51c2_o

Po raz kolejny ktoś próbował mi udowodnić, że Agile dla „dużych projektów” się nie sprawdzi. I… Generalnie zgadzam się z tym stwierdzeniem. Zgadzam się, tak! Agile dla „dużych projektów” nie działa!

Agile z pewnością nie zadziała jeśli za miarę wielkości „dużego projektu” przyjmiemy ilość ludzi nad tym projektem pracujących. Jeśli duże projekty dla Was to takie nad którymi pracuje 200 lub więcej osób to macie znacznie większe problemy niż, to czy Agile zadziała, czy nie.

„Duże projekty” to dysfunkcja sama w sobie.

Programowanie jest rozwiązywaniem problemów – nie potrafię sobie wyobrazić problemu, który potrzebował by więcej niż kilkadziesiąt osób do jego rozwiązania. Owszem, niektóre problemy są bardziej złożone od innych – w takim przypadku jedyne rozsądne rozwiązanie to rozbicie ich na mniejsze – być może mniej złożone problemy i stworzenie mniejszych zespołów rozwiązujących je.

Waterfall powstał właśnie po to, by radzić sobie z „dużymi projektami”. Waterfall jest cool. Waterfall działa… dopóki nie zaczniesz się nad tym zastanawiać…

Cała pseudonauka o tym w jaki sposób powinniśmy testować (oczywiście manualnie) skomplikowane projekty, zarządzać milionami przypadków testowych, poprawnie zgłaszać miliony bugów, następnie zarządzać tymi zgłoszeniami, mierzyć ilość tych zgłoszeń i co gorsza tworzyć z tego metryki mające na celu określenie jakości pracy testerów [BLAH!], to wszystko powstało w odpowiedzi na realne problemy. Problemy, które sami sobie stworzyliśmy budując niewłaściwe oprogramowanie w niewłaściwy sposób.

Skalowanie Agile to kolejny urojony problem.

Coraz więcej na około słyszy się o nowych, pięknych i kompleksowych metodach skalowania Agile. Niektóre z nich nawet zapewne działają. Ba, nawet widziałem je w działaniu. Niestety nadal są to narzędzia służące do rozwiązywania problemów, które ktoś, gdzieś sam sobie stworzył.

Agile nie trzeba skalować, jeśli jesteśmy w stanie przeskalować nasz produkt. Tak jak na przykład zrobili to w Spotify. Kluczem do sukcesu nie jest stworzenie squad’ów, tribe’ów, chapter’ów czy guild’ów… To wszystko powstało tylko po to by wokół wielu, względnie niezależnych komponentów produktu, rozwijanych przez interdyscyplinarne i kros-funkcjonalne zespoły stworzyć platformę służącą do synchronizacji pracy i wymiany wiedzy. Agile jest gdzieś indziej – w każdym zespole z osobna. Nie ma tutaj żadnego skalowania.

Więc tak, Agile nie działa w „dużych projektach”! Duże projekty są problemem samym w sobie. Nie chcę tutaj rozwodzić się nad potencjalnymi i faktycznymi przyczynami tego dlaczego nadal mamy do czynienia z tak wieloma „dużymi projektami”. To nie jest czas na to – niech ten post będzie dla Was przestrogą, by Wasze małe jeszcze projekty nigdy nie stały się „dużymi projektami”.

8 komentarzy więcej...

Czy potrzebujesz Agile Coacha?

opublikowany przez 10, Wrz, 2013, w kategoriach Agile, Coaching, Kanban, Praca, Scrum, XP, Zarządzanie

2536358399_88e6544fa9_o
Po raz kolejny utwierdziłem się w przekonaniu, że ludzie nie czytają, nie tylko moich książek, czy mojego bloga… Ludzie nie czytają w ogóle, albo czytają bardzo mało rzeczy związanych z ich pracą. Utwierdziłem się w sposób najprostszy – pytając około 35 osób czy czytają… Ludzie nie czytają i nie jeżdżą na konferencje bo najzwyczajniej nie mają na to czasu przez pracę. Często przez to, że ich praca jest nieefektywna muszą pracować więcej, by osiągnąć oczekiwane rezultaty. Pracując więcej nie mają czasu na to, by poczytać o tym jak pracować efektywniej…

I w sumie bardzo dobrze… Bo ja czytam… Bo ja piszę książki… Bo ja jeżdżę na konferencje i czasem tam coś opowiadam… Publikuję czasem coś na blogu ale przede wszystkim czytam blogi innych… Poświęcam dużo czasu na naukę nowych rzeczy, ale też na przemyślenia związane z praktycznym zastosowaniem tego co już umiem… Eksperymentuje z nabytą wiedzą stosując ją w praktyce… Ciągle nabywam coraz więcej doświadczenia związanego z tymi tematami… Bardzo różnorodnego doświadczenia dzięki pracy dla bardzo różnych klientów… Klientów w różnym kontekście, w różnym środowisku, w różnych technologiach i w różnych branżach… Rozmawiam z ludźmi, dzielę się swoim doświadczeniem ale też korzystam z doświadczeń innych…

Właśnie to wszytko, właśnie to, że ja MAM na to czas i że swój czas na to właśnie poświęcam jest głównym powodem tego, że bardziej opłaca Ci się zatrudnić mnie jako Agile Coacha, jako Mentora, jako Trenera, jako Doradce, niż samemu poświęcać nieskończoną ilość godzin na wyszukiwanie i zdobywanie tej wiedzy i doświadczenia. Jest to również bardziej opłacalne niż samodzielne popełnianie błędów – zwłaszcza tych kosztownych i tych, które ja już wcześniej miałem okazję popełnić, lub zaobserwować gdzieś indziej.

Poza tym ja lubię to robić. Robię to z pasją. Nie traktuję tego nawet jak pracę – jest to bardziej moje hobby…

Dość tej autopromocji! Generalnie chodzi o to, że zdobywanie wiedzy to również ciężka praca wymagające wielu poświęceń, a już na pewno dużej ilości poświęconego czasu. Czasem można jednak zdać się na kogoś, kto już tą wiedzę posiada, albo ma czas na to, by zdobyciu tej konkretnej wiedzy się poświęcić…

8 komentarzy więcej...

Kolejny post o diecie

opublikowany przez 21, Sie, 2013, w kategoriach Agile, Kanban, Scrum, XP, Zarządzanie

Dieta

I po raz kolejny będę pisał o diecie. O diecie dla organizacji. Tym razem zainspirował mnie artykuł, który Dion Almaer opublikował na portalu medium.com (swoją drogą sporo fajnych tekstów na tym portalu, sam też powoli zaczynam tam publikować – polecam).

Wróćmy na chwilę do poprzedniego wpisu w tym temacie oraz odpowiedzi nadesłanej przez Michała Gozderę. Ciekawą dyskusję wywołały powody przejścia na dietę. W przypadku diety mojej własnej może to być na przykład chęć lepszego samopoczucia czy też uzyskanie możliwości patrzenia w lustro bez odrazy do samego siebie. Może to być idea zdrowego i długiego życia, na które szans nie mamy, gdy mamy nadwagę i źle się odżywiamy. A może po prostu chcieli byśmy uzyskać lepszą sprawność fizyczną i wypracować lepszą kondycję by nie umierać po przebiegnięciu kilkunastu metrów w pogoni za odjeżdżającym autobusem.

Podobnie jeśli chcemy zmienić (odchudzić) naszą organizację również musimy mieć do tego dobry powód. Na tyle dobry byśmy sami byli do niego wystarczająco przekonani i byśmy mogli przekonać innych. Często będzie to już niepokojący stan obecny naszej firmy (nie możemy spokojnie spoglądać w lustro).

Dion w swoim artykule napisał coś bardzo istotnego – należy zacząć od restrykcyjnej diety, gdyż uprawianie sportu przy dużej nadwadze wcale nie sprawia przyjemności. Podobnie w przypadku organizacji, gdy cierpi ona na „nadwagę” nie sposób wdrożyć w niej pewnych metod takich jak na przykład TDD czy chociażby automatyzacja testów. A już na pewno nie będzie to przyjemne i łatwe.

Jak już wcześniej pisałem metody takie jak Kanban czy Scrum są swego rodzaju dietą dla naszej organizacji. Same w sobie nie wystarczą do tego, by już na zawsze być zwinnym. Do tego potrzeba długotrwałych zmian nawyków żywieniowych czyli w naszym przypadku zmiany kultury organizacyjnej.

Czy to znaczy, że z pewnymi praktykami i metodami musimy poczekać? Nie, czekać nie musimy, a nawet nie powinniśmy – wspomniane praktyki dodatkowo wzmacniają dyscyplinę i poprawiają efekty naszej „diety”. Niemniej jednak należy pamiętać o tym, że w pewnych sytuacjach będzie to bolesne i może nawet prowadzić do „uszczerbku na zdrowiu”. Bieganie przy dużej nadwadze może skończyć się problemami z kręgosłupem i/lub stawami u nóg, dlatego taki trening musi być dobrze dopasowany do naszych możliwości.

Zasada numer jeden: „mniej jeść” – a w zasadzie jeść rozsądniej i bardziej świadomie. Czy nie na tym właśnie bazuje Scrum czy Kanban? Mamy jeden backlog i ograniczone możliwości realizacji zadań więc musimy wybrać to co jest na tym backlogu najbardziej wartościowe.

Wyobraźmy sobie, że nasze codzienne menu jest zapisane w postaci backlogu – dodajmy limit kalorii (czyli nasze velocity) i teraz możemy uporządkować backlog tak by osiągnąć największą wartość (wartość odżywczą i jednocześnie przyjemność z jedzenia). Nie, nie próbowałem tego – to tylko taki eksperyment myślowy (ale w sumie kto wie…).

Jeszcze jedno wartościowe przesłanie z wspomnianego artykułu – bardzo ważne są widoczne efekty. To właśnie one wzmacniają naszą motywację do dalszego działania. Dlatego też warto zwłaszcza na początku obrać strategię małych zmian dających widoczne efekty.

1 komentarz więcej...

Skrzynka z narzędziami – dlaczego dobrzy developerzy zmieniają pracę?

opublikowany przez 29, Sty, 2013, w kategoriach Agile, Kanban, Scrum, XP

Nie istnieje jeden, sprawdzony i zawsze działający sposób na efektywne wytwarzanie oprogramowania. Jako praktycy, trenerzy, doradcy i konsultanci nie jesteśmy w stanie dać wam (sprzedać) czegoś co sprawi, że wasz proces będzie działał i przynosił oczekiwane efekty. Jedyne co możemy wam zaoferować to pomoc przy kreacji takiego procesu przez was – bo to wasz proces, a i to z pewnymi ograniczeniami. Jako zewnętrzni doradcy (nawet gdybyśmy byli u was na etacie było by tak samo, a nawet gorzej) nie możemy kazać wam czegoś zrobić, ba z pewnością nie chcieli byśmy niczego wam nakazywać i brać za to odpowiedzialności.

To co możemy dla was zrobić to przekazać wam nasze doświadczenia i opowiedzieć historie o tym jak jakieś narzędzia i techniki działały bądź nie w innych organizacjach, w innych zespołach. Może niektóre z nich zadziałają u was, może będą wymagały odpowiedniego dopasowania. To co jeszcze możemy zrobić to przekazać wam wiedzę na temat danych narzędzi i metod pracy. Będzie to pewnie w większości tak lekceważona i dyskryminowana wiedza teoretyczna. Ale czy wiedza, chociażby teoretyczna nie jest wartościowa?

Do poniższego artykułu zachęcił mnie wpis Sandro Mancuso zatytułowany „The best approach to software development”. Jak zapewne w nim przeczytacie nie ma jednego, najlepszego podejścia do wytwarzania oprogramowania. Natomiast jest wiele podejść, które sprawdziły się w określonym kontekście w wielu różnych projektach.

W takim razie wszelkiego rodzaju dogmatyzm na tym poziomie jest co najmniej niewskazany. Warto natomiast znać wiele technik/narzędzi chociażby takich jak TDD, BDD, ATDD, DDD, XP, Scrum, Kanban, Lean Startup, Gamification, i wiele innych. Warto mieć doświadczenie w używaniu tych narzędzi i dzięki temu wiedzieć, do jakich zadań wykorzystywać jakie narzędzia. Wielu dobrych programistów, których znam zmienia pracę dosyć często – raz na dwa lata. Zapytani dlaczego odpowiadają przeważnie, że pomimo tego, iż firmy w których pracują są na prawdę fajne to po pewnym czasie następuje wypalenie i nuda spowodowana pracą nad ograniczonym zbiorem produktów, według ograniczonych metod pracy i w ograniczonej liczbie technologii.

Wiele firm takich jak np. Google zauważyło ten problem i wręcz wymusza na swoich pracownikach zmianę projektu w którym pracują przynajmniej raz na dwa lata (przykład właśnie z Google). Dobrzy pracownicy są dobrzy przeważnie dlatego, że szybko się uczą i lubią się uczyć. Jest to coś co ich motywuje. Ale dobrzy pracownicy też łatwo się nudzą. Jeśli mają cały czas możliwość rozwoju i nauki to praca ich nie nudzi. Jeśli natomiast cały czas pracują w tym samym środowisku to z czasem motywacja spada choćby nie wiem jak wysokie były premie, jak fajni ludzie na około i jak fajne imprezy firmowe.

Dobrzy developerzy cały czas poszukują nowych narzędzi, doświadczeń i możliwości rozwoju i to właśnie te narzędzia i doświadczenie sprawiają, że są dobrzy.

1 komentarz więcej...