Agile Surfing

Ciekawa sesja na temat “The lean startup”.

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.

Wczoraj miałem okazję wziąć udział w Zimowym Agile Tuningu.  Jestem zadowolony z wypadu do Krakowa

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?:)

Ciekawy artykuł o programowaniu w parach (którego jestem zwolennikiem).

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.

Właśnie wróciłem ze spotkania lokalnej grupy agile.. Temat: Why scrum works while implemented properly?

Było bardzo fajnie, a ja chciałbym zwrócić tu uwagę tylko na jedną kwestię

Agenda spotkania:

• 1800-1900 prezentacja
• 1900-2000 pytania, rozmowy, itp.

A jak było naprawdę?

• Start spotkania 1810 osobiście uważam, że to wysyła zły sygnał – można się spóźniać
• Koniec spotkania 2140 uważam, że to trochę za późno, ja jestem bardzo zmęczony

Bardzo ciekawy był też przebieg prezentacji.. Mówcom co kilka slajdów przerywano i toczyła się bardzo żywa dyskusja. Uważam, że to było świetne! Miałem okazję wysłuchać dużo ciekawych historii i punktów widzenia i działo się to w bezpośrednim sąsiedztwie tego co działo się na slajdach. Fajnie by było, gdyby ta forma została zachowana na kolejnych spotkaniach Jedyne co proponuje zmienić to dodać: “Kończymy o 2100,  jest OK nie wyrobić się ze wszystykimi slajdami, trudno..” Slajdy można wrzucić na www i umożliwić ich komentowanie.

To tyle spostrzeżeń na świeżo

Właśnie dowiedziałem się o nowo powstałym magazynie agileowym – Agile Record.

Pierwszy numer można pobrać za darmo stąd.

Czy warto? Jeszcze nie miałem czasu się przyjrzeć, na pewno napiszę coś więcej później.