Wideo Slajdy

To co szczególnie mi się spodobało to aplikacja opisana w 47 minucie. Nie udało mi się znaleźć jej w sieci, więc jak komuś się uda to proszę o info w komentarzach.

Aplikacja jest opisana następująco:

• Aplikacja zarządza muzyką, która leci w pomieszczeniu deweloperów
• Każdy może dodać swoją piosenkę do listy piosenek, które są puszczane
• Każdy może zagłosować, że dana piosenka mu się nie podoba. Nie będzie ona więcej puszczana. Po jakimś czasie lecą tylko takie piosenki, które wszystkim się podobają.
• Gdy Build nie przejdzie, zostaje natychmiast puszczona specjalna piosenka, np „Oops, I did it again”. Od razu wszyscy wiedzą, że build nie działa.
• Każdy może wybrać sobie swoją piosenkę. Po udanym check-in gdy Build przejdzie, zostaje ona puszczona na 20 sekund. W ten sposób od razu wiemy, że wszystko jest w porządku.

Daj znać innym

Razem z ludźmi z Wrocławskiego JUGa i Wrocławskiej grupy kunszt organizujemy też otwarte CodeRetreat dla Wrocławia! Wydarzenie prawdopodobnie odbędzie się 23 października, a o szczegółach poinformuje między innymi na tym blogu.

Ale dlaczego warto poświęcić sobotę i przyjść? Będziesz miał okazję ćwiczyć!

Dlaczego jest to ważne? Zapraszam do obejrzenia wideo z prezentacji Corey’a (jeden z pomysłodawców CodeRetreat).

Practise

Daj znać innym

Program

Jak widać, będzie wiele sesji, wiele prowadzonych przez autorów znanych książek (choćby Robert Martin, Mike Cohn, Alistair Cockburn, Jean Tabaka, Rachel Davies). Jedna z sesji jest o „Code Retreat” i poprowadzi ją Rob Park.

W tym roku nawet nie myślałem o tym żeby się tam wybrać, ale za rok chce pojechać Wyjazd drogi, więc albo będę musiał znaleźć firmę która mnie tam wyśle lub zgłosić się jako mówca

Ktoś kto tam prowadzi 180 minutową sesję ma pokryte większość kosztów udziału. Oczywiście, na razie jest to w sferze moich marzeń Ale może dałby radę poopowiadać coś przez 60 min

Daj znać innym

Ostatnio świadomie zdałem sobie sprawę z kliku analogi pomiędzy światem Agile a światem wodniaków.

W harcerstwie mamy zastęp, w agile mamy zespół. Jeśli mówimy o wodniakach, to mamy załogę, której jeszcze bliżej do zespołu zwinnego.  Tak jak zespół jest razem w projekcie tak załoga jest razem na jachcie. Podobnie jak załoga na jachcie musi współpracować by dopłynąć do celu tak i zespół musi wspólnie dążyć do realizacji projektu. Ktoś kto sprawdza się jako załoga na jachcie prawdopodobnie sprawdzi się również jako członek zespołu programistów.

Wiele wartości ze świata agile (jak i Craftsmanship) mamy również w harcerstwie

1. Ramię pręż słabość krusz i nie zawiedź w potrzebie
2. Podaj swą pomocną dłoń tym co liczą na ciebie
3. Zmieniaj świat, zawsze bądź sprawiedliwy i odważny
4. Śmiało zwalczaj wszelkie zło niech twym bratem będzie każdy

Fragment piosenki „Harcerskie ideały”

Na przykład w zacytowanym fragmencie doszukać się możemy

1. retrospekcje by dążyć do doskonałości

3. odwaga z XP

4.  refactoring, otwarta komunikacja

W swojej książce „Clean Code” Uncle Bob wprost nawiązuje do zasady skauta – „Zostaw miejsce biwaku w lepszym stanie niż je zastałeś” – gdy pisze o tym jak powinniśmy postępować z naszym kodem źródłowym.

Software craftsmanship a krzyż harcerski.

Zasady software craftsmanship (link) a symbolika krzyża (link).

Krąg
Lilijkę otacza krąg – symbol doskonałości do jakiej dąży harcerska rodzina. [..]. Inni dodają, że to oznaka ogromnej woli tworzenia kręgu, z którego promieniować będzie prawość myśli, słów i czynów.

W zasadach przeczytać możemy o tym, że Craftsman ciągle się uczy dążąc do doskonałości. W manifeście Software Craftsmanship jest o budowaniu społeczności profesjonalistów (tworzenie kręgu).

Promienie
Promienie biegnące od lilijki oznaczają dążenie harcerstwa do promieniowania na cały świat wartościami, radością, dobrem.

Z zasad Software Craftsmanship – dziele się wiedzą by wpływać pozytywnie na rozwój całej branży.

Węzeł
Węzeł na wieńcu, jak węzeł na chuście ma przypominać o obowiązku wypełnienia przynajmniej jednego dobrego uczynku dziennie.

Uncle Bob promuje zielone opaski na rękę, które przypominają o tworzeniu dobrego kodu. Mówi też by z każdym wprowadzeniem zmian do repozytorium kodu wiązał się choć jeden akt dobroci (poprawa nazwy zmiennej, wyciągnięcie metody).

Software craftsmanship a żeglarstwo.

Robotę trzeba wykonywać porządnie. To samo przekonanie podzielać będzie żeglarz i craftsman. W obu kontekstach nieprzykładanie się do jakości pracy pociągać może poważne konsekwencje. Źle sklarowane liny doprowadzić mogą do wywrotki jachtu. Niechlujnie napisany kod może zawierać błędy, które spowodują rozbicie się sondy kosmicznej sterowanej wadliwym oprogramowaniem.

Podsumowując: To ciekawe i nigdy bym nie przypuszczał jak lata spędzone w  6 Harcerskiej Drużynie Żeglarskiej wpłyną na moje wybory jako programista. Jak przekonania, które wypracowałem w młodości będą ciągle aktualne w innym kontekście. Mam wrażenie, że czuję agile właśnie dzięki harcerstwu.

Rodzice: Warto zachęcać wasze dzieci do spróbowania harcerstwa.

Młodsi: Wodniactwo to nie tylko świetna przygoda ale również prawdziwa szkoła życia!

Hej, Morze, moje Morze,
Wdzięczny Ci jestem bardzo,
Toś Ty mnie wychowało,
Toś Ty mnie wychowało,
Szkołęś mi dało twardą.

Fragment: Morze, moje morze

Daj znać innym

W skrócie: Jest to cały dzień programowania w parach ćwicząc Test-Driven Development. Nacisk kładziony jest na to jak pracujemy (w przeciwieństwie do tego nad czym pracujemy). Słowo klucz: kata

Czym moje warsztaty różniły się od prawdziwych „CodeRetreat”?

• Były to warsztaty zamknięte (tylko dla pracowników)
• Były zorganizowane w dzień roboczy (a nie w sobotę)
• Odbyło się tylko 5 sesji (a nie 6-7)
• Nie poszliśmy na koniec do pubu

Z informacji zwrotnej uzyskanej od uczestników wynika, że warsztaty się podobały

Zresztą proszę poczytać co mieli do powiedzenia uczestnicy:

Na pewno ten czas spędziłem ciekawie. Programowanie w parach pokazało, że każdy może wnieść od siebie coś nowego, rzucić światło na pewne aspekty, których się nie dostrzegało. W każdej sesji rodziły się nowe pomysły i podejścia do rozwiązania wciąż tego samego problemu. Była to dobra okazja do wymiany doświadczeń a także do praktycznego wykorzystania TDD. Polecam każdemu wzięcie udziału w takich warsztatach. Uważam, że jest to czas dobrze wykorzystany. - Michał

Ciekawe i dobrze przygotowane szkolenie. Dużym plusem jest to, że szkolenie to jest w formie warsztatów. Forma ta pomaga wymieniać doświadczenie i uczyć się od siebie nawzajem, co uważam, za największą wartość, jaką wyniosłem. Poza tym, była to dobra zabawa. – Janek

Pierwszy raz uczestniczyłem w tego typu warsztatach i muszę przyznać, że jestem miło zaskoczony.
Kilkukrotne rozwiązywanie jednego problemu  (prostego swoją drogą), ale z różnymi osobami prowadziło do różnych ciekawych wyników.
Programowanie w parach ma w sobie moc, bez względu na to, czy programuje się z kimś słabszym czy lepszym – oto jeden z moich wniosków po tych warsztatach.
Warsztaty przygotowane dosyć rzetelnie, zarówno od strony technicznej ( sala, komputery ), jak i merytorycznej – całkiem sporo wiedzy zostało przekazane – wiedzy, która według mnie powinien posiadać każdy programista.
Jednym słowem – brawo Grzegorz! Wyszło świetnie, pomimo że pierwszy raz organizowałeś tego typu zajęcia. Mirek

Dziękuję za możliwość wzięcia udziału w warsztatach. Bardzo podobała mi się ich forma i zróżnicowanie doświadczenia uczestników. Choć byłem w mojej ocenie najmniej zaawansowanym uczestnikiem warsztatów poradziłem sobie z pomocą kolegów i koleżanek z zadaniem jakie mieliśmy do wykonania. Samo zadanie również było bardzo interesujące i wciągające. Czas podczas warsztatów upływał niemiłosiernie szybko lecz mimo to w kolejnych krokach udawało się dochodzić co raz to dalej. Warsztaty uświadomiły uczestnikom, a na pewno mi, że jeżeli chcę tworzyć poprawny kod to bez wątpienia powinienem wychodzić o tworzenia testów, a kończyć na implementacji (przekonałem się do tego już podczas drugiej sesji). Uważam, że osoba przygotowująca warsztaty zachowała się profesjonalnie i swoją postawą zachęcała do działania. Chciałbym, aby takie warsztaty były organizowane cyklicznie i uważam, że warto zainteresować nimi większy odsetek pracowników mających możliwość wykorzystania tej wiedzy w codziennej pracy.
Jeszcze raz dziękuję za ciekawy dzień pracy. Grzesiek

Wydarzenie było dość kameralne – uczestniczyło w nim 6 osób + ja.  Programowaliśmy w Javie.

Przez pierwsze 3 sesje byłem obserwatorem. Było to o tyle fajne, że mogłem podglądać co robią ludzie i na retrospekcjach po sesjach poruszać tematy dotyczącego tego, co widziałem że działo się u innych.

Ostatnie 2 sesje sam aktywnie kodowałem w parze i o ile pozwoliło mi to poczuć na własnej skórze to co robili uczestnicy, to bardzo utrudniło dawanie wskazówek odnoszących się do tego co działo się w innych parach.

Na retrospekcjach poruszaliśmy temat związane z:

• Różnymi pomysłami na zakodowanie rozwiązania
• Jak pisać czysty kod
• Jak efektywnie programować w parach (np. ping-pong programming)
• Test-driven development, TDD as you meant it

Warsztaty zaczęliśmy, krótkim wstępem, gdzie

• Każdy miał szansę się przedstawić
• Przedstawiłem plan dnia
• Opowiedziałem trochę skąd pomysł (QCon i wykład Corey’a Haines)
• Powiedziałem klika słów o Software Craftsmanship (care, practice, learn, share), manifest
• Przytoczyłem klika wskazówek na temat tego, jak programować w parach.
• Przypomniałem zasady TDD
• Omówiłem zasady „Gry w życie”

W czasie przerwy obiadowej przejrzeliśmy slajdy Sharpening the Tools

Code Retreat we Wrocławiu

Ponieważ warsztaty uważam za udane, myślę że warto zorganizować prawdzie „CodeRetreat” dla Wrocławia. Jeśli ktoś jest zainteresowany to proszę o kontakt.

Co jest niezbędne by to urzeczywistnić?

• Duża sala, gdzie wygodnie można siedzieć i kodować w parach przy laptopach.  (sponsor)
• Uczestnicy z laptopami
• Termin

Więc nie potrzeba chyba aż tak dużo?:)

A co mogłoby wydarzenie uczynić jeszcze fajniejszym

• Dodatkowe monitory, by wygodnie pracowało się na laptopach
• Obiad ufundowany przez sponsora
• Dostęp do neta
• Na zakończenie wyjście integracyjne, ufundowane przez sponsora

Jeśli ktoś ma pomysł jak powyższe rzeczy zdobyć a tym samym urzeczywistnić Wrocławskie CodeRetreat proszę o info w komentarzach

Linki:

• http://coderetreat.ning.com/profiles/blogs/how-to-run-a-coderetreat
• http://www.coderetreat.com/
• http://www.agileminds.be/workshop/2010/coderetreat/index.html

Daj znać innym

http://www.oredev.org/videos/the-lean-startup

Zaciekawił mnie fragment na temat Continuous Deployment. Eric Ries’a mówi, że zmiany, które commit’uje deweloper są automatycznie wdrażane na produkcje. Jednocześnie monitorowane są metryki biznesowe, np. liczba rejestracji. Jeśli jakaś metryka spadnie poniżej dopuszczalnej wartości zmiana jest automatycznie cofana a cały zespół jest informowany e-mailem, że wprowadzona zmiana wydaje się nie być zbyt korzystna. Feedback od klientów poniżej 1h

Czy wiecie o kimś w Polsce, kto się w to bawi? W szczególności, czy ktoś korzysta z Continuous Deployment?

Swoją drogą właśnie skończyła się konferencja organizowana przez Eric Ries’a http://www.sllconf.com/program. Widziałem, że w sieci są już nagrania.

Daj znać innym

Największą niedogodnością dla mnie była lokalizacja. Razem z Krzyśkiem mieliśmy zamiar dojechać autobusem i okazało się, że sugerowany na stronie organizatora autobus nie jeździł wczoraj (w ogóle rzadko w soboty jeździ..). Na szczęście uratował nas Adam, który podrzucił nas autem – jeszcze raz dzięki Nie mniej zgadzam się, że sama lokalizacja malownicza i ładna. Natomiast „kuchnia” za mała jak na tyle osób, ciężko było operować przy kawie i herbacie.

Jeśli chodzi o program konferencji to uczestniczyłem w ścieżce „ludzie”. Sesje były na poziome, chciałbym napisać tutaj tylko o jednej.

10 tips that ScrumMasters should know, (but probably don’t!) prowadzone przez Nigel Baker’a. Zgadzam się z tym co można było przeczytać na Twiterze (#agiletuning) – Nigel to świetny mówca. Naprawdę potrafi przemawiać Ciekaw jestem, gdzie się tego uczył? A może ma tak ‘od urodzenia’?:) Słychać też było, że zna się na skutecznej komunikacji – jego pytanie „To kto zada pierwsze pytanie?:)” nie umknęło mojej wyczulonej na takie chwyty uwadze

Poniżej lista tego co zapamiętałem z tej prezentacji, nie koniecznie w kolejności jaką podał Nigel (notowałem już po wykładzie)

• ScrumMaster to praca na cały etat. Strażak to strażak, nie zajmuje się rano roznoszeniem poczty jako listonosz. Tak samo powinno być ze SM, powinien on cały swój czas poświęcić pracy dla teamu.
• Stałe tempo. Nasze projekty to nie sprinty, raczej maratony. Tygodniowy sprint może być zbyt morderczym tempem prowadzącym do wycieńczenia pracowników. I nie tylko o pracowników chodzi – jakość produktu znacznie spada gdy pracownicy są przemęczeni.
• Texas holdem (poker) na żywo versus texas holdem w internecie. Brak komunikacji na żywo rodzi dysfunkcje społeczne (trole, nie szkoda nam zrobić komuś na złość). Jeśli pracujemy w teamie rozproszonym musimy włożyć dużo więcej wysiłku w to, by ludzie byli traktowanie i zachowywali się jak ludzi, niż musimy pracując z teamem, który siedzi razem.
• Mieć i stosować „Definition of Done”
• Nigdy nie dokładać dodatkowych dni na koniec sprintu (by dokończyć historyjki)
• Każdy sprint ma na celu dostarczenie produktu. Nie ma czegoś takiego jak „design sprint”, „technical debt sprint”, „sprint 0″
• Daily Scrum (stand up) jest dla teamu, nie dla SM
• Pamiętać o budowaniu zespołu. Wyjście razem na pizze jest fajne, ale to nie wystarczy by zbudować zespół.
• SM nie może być policjantem. Jeśli będziesz zachowywał się jak policjant ludzie zaczną ci kłamać (taaaak, oczywiście że wczoraj był stand up)

Tyle zanotowałem, coś ważnego przeoczyłem?:)

Daj znać innym

Napiszę teraz co nie co o sesji Software Craftsmanship, Beyond The Hype. Sesję poprowadził Corey Haines, który bardzo dosłownie potraktował idee „Journeyman” i jak możemy się dowiedzieć (http://www.coderetreat.com/) rok 2009 spędził podróżując po stanach ucząc programowania w parach w zamian za wikt i opierunek.

Jeśli nie słyszałeś jeszcze o Software Craftmanship, tutaj możesz przeczytać manifest. Jeśli agile jest o tym jak dostarczać oprogramowanie wysokiej jakości, to Software Craftmanship jest o tym jak kształcić deweloperów o wysokich kwalifikacjach.  Corey opowiadał o tym, co w ostatnim czasie działo się w środowisku i tak:

• Rozpowszechniła się idea Code Katas
• Temat jest poruszany na konferencjach, np. ścieżka w czasie QCon
• Coderetreat - może warto coś takiego zorganizować we Wrocławiu? Corey podróżuje z tym teraz po świecie, więc można by go spróbować zaprosić.
• Powstają User Groups – btw, mamy jakieś aktywne grupy w Polsce?
• Craftsman Swaps – firmy wymieniają się pracownikami, na tydzień lub dwa. Pracownicy mogą zobaczyć jak podchodzi się do wytwarzania oprogramowania w innych „warsztatach”. Ktoś słyszał o czymś takim w Polsce?
• Craftsman Journeys – Tak jak Corey, ludzie zaczynają ruszać na dłuższe podróże, podczas których spotykają się z deweloperami z różnych zakątków świata, kodując razem z nimi i wymieniając się doświadczeniem i technikami.
• Craftsman Spikes – firmy dają możliwość chętnym, przyjść i popracować u siebie przez parę dni. Np studenci mogą przyjść ze swoim problemem i nauczyć się czegoś od praktykujących deweloperów.

Daj znać innym

Streszczenie treści.. Programowanie w parach działa bo:

• Kiedykolwiek „oświeciło” cię samo zadania komuś pytania? Podobny efekt występuje podczas rozmów programistów w czasie programowania w parach.
• Kojarzysz eksperyment z liczeniem piłek do kosza?*. Często nie widzimy tego, czego nie szukamy lub co nie wydaje nam się być istotne (uliczni magicy korzystają z tego od dawna). Gdy pracujemy w parze i popełnimy błąd (ale go przeoczymy) jest duża szansa, że nasz partner go wychwyci.
• Para nawzajem się nakręca w korzystaniu z dobrych praktyk. Piszemy testy, refactorujemy bo inaczej „zawiedziemy” partnera. Poza tym, partner sam z siebie będzie wywierał pozytywną presję.  A dlaczego korzystamy ze złych praktyk? Np można powiedzieć, że code & fix jest podobne do grania na jednorękim bandycie. Jednoręki bandyta to jedna z najbardziej uzależniających gier w kasynie.
• Zespół wymienia i dyskutuje doświadczenia.

* Jeśli nie kojarzysz tego eksperymentu, obejrzyj ten filmik http://viscog.beckman.illinois.edu/flashmovie/15.php. Możesz go zobaczyć tylko raz, twoim zadaniem jest policzyć ile razy piłka została podana pomiędzy uczestnikami w białych koszulkach. Gdy już będziesz znał wynik, odwiedź tą stronę http://free.mailinfo.com/web/reality/step2.htm.

Daj znać innym

Technika jest bardzo prosta.

• Ustal co chcesz zrobić i nastaw timer na 25 minut.
• W czasie tego 25 minut intensywnie pracuj (wyłącz poczte, gg, poproś aby Ci nie przerywano).
• Po upływie 25 minut nastaw timer na 5 minut przerwy.
• W czasie przerwy, zajmij się czymś zupełnie nie związanym z pracą. Kawa, toaleta, spacer po biurze.
• Zrób 4 takie cykle. Po 4 cyklu przerwa powinna być dłuższa, np 20 minut.

Prawda, że proste?

Strona na której można dowiedzieć się jeszcze więcej.

Jedną z zalet jest wzrost Twojej produktywności. Gdy robisz przerwę, Twoja podświadomość dalej pracuje nad rozwiązaniem problemu z którym walczyłeś i jednocześnie gdy wracasz do zadania, patrzysz na nie z pewnym dystansem.

Super się to sprawdza podczas kodowania. Jeśli używasz TDD to przerwanie pracy gdy timer każe też nie będzie problemem, bo test szybko pozwoli Ci odświeżyć kontekst gdy wrócisz do zadania.

Już po pierwszej iteracji stosowania pomidorów zaczęliśmy estymować zadania właśnie używając tej jednostki. Naturalne też było stawianie „kropek” po każdym zakończonym pomidorze na karteczce reprezentującej zadanie, dzięki czemu mogliśmy śledzić dokładność naszych estymacji.

Daj znać innym