W skrócie: Opisany zespół, miał największą wydajność i najmniej bugów gdy:

• Historyjki były dewelopowane przez programistów o najmniejszej wiedzy domenowej (w obszarze danej historyjki)
• Historyjki były dewelopowane przez pary, które same wybierały nad czym chcą pracować
• Historyjki nie były przypisane konkretnym osobą, cały zespół był odpowiedzialny za historyjkę
• Pary rotowały co ~2 godziny. (Osoba która była dłużej w parze opuszcza parę).

Daj znać innym

Ponieważ to jakie praktyki najlepiej się sprawdzą zależy od naszego kontekstu, zacząłem od opisania sytuacji mojego zespołu.

Zespół w którym jestem jest

• mały (~7 osób)
• wszyscy siedzimy w jednym pokoju
• mamy wewnętrznego klienta / product ownera. Siedzi z nami na tym samym piętrze i ma dla nas czas
• tworzymy ważny, ale wewnętrzny system

Dla każdej praktyki powiedziałem:

• na czym polega
• dlaczego/po co ją stosujemy
• „dobre rady”

Oto lista praktyk, które aktualnie stosujemy w moim zespole:

Codziennie

• Stand-up
• Pair programming
• TDD
• Continuous Integration
• Continuous Delivery
• Story wall / Story lifecycle
• Work in progress limits
• Information radiators
• Learning huddle

Raz na tydzień

• Coding dojo
• Team lunch
• Dev-ops stand-up

Raz na dwa tygodnie

• 1-1 feedback

Raz na miesiąc

• Retrospekcja

Około raz na 3 miesiące

• Incepcja
• Estymacja
• Story mapping
• Persony

Na żądanie / Wg potrzeby

• Technical spike
• Demo / Show case
• Public code review
• Team charter

A jakie praktyki stosuje Twój zespół?

Daj znać innym

Wideo można zobaczyć tutaj: Refactoring of test

Filmik trwa 5 minut podczas których:

1. Rozbijam jeden duży test na kilka mniejszych (by testy były łatwiejsze do zrozumienia, a gdy nie przechodzą by dokładnie było wiadomo co nie działa)
2. Zamieniam assertEquals na assertThat (naturalniej się czyta)
3. Zastępuje komentarze opisowymi nazwami testów (by samo zerknięcie do raportu w ciągłej integracji wystarczyło do zorientowania się, co się dzieje)

Daj znać innym

W roku 2011

Udało mi się:

• W lutym zostać magistrem – uff!
• Pracować w świetnym zespole!
• Nauczyć się nowych rzeczy o testowaniu.
• Pojechać jako wolontariusz na QCon w Londynie, XP w Mardycie i GOTO w AArhus
• Być koordynatorem wolontariuszy w czasie konferencji ALE w Berline
• Zorganizować razem z Markusem lipcowe CodeRetreat w Berlinie
• Zorganizować i poprowadzić razem z Markusem CodeRetreat w Berlinie w ramach światowego dnia CodeRetreat w grudniu
• Prowadzić w Nokii cotygodniowe Coding Dojo
• Poprowadzić mały warsztat na temat „1-1 feedback” dla innego zespołu w Nokii. Poprowadzić Extreme Startup w ramach dojo.
• Zapisać się i wygłosić 3 mowy w berlińskim klubie Toastmasters
• Uczestniczyć w kilku spotkaniach #xtcb (Extreme Tuesday Berlin)
• Rozpocząć naukę Scali i Rubiego
• Zostać certyfikatowanym programistą Springa
• Przeczytać: Release It, Presentation Zen, The Clean Coder, Managment 3.0, Kanban, Specification By Example, Lean Startup i rozpocząć kilka innych książek.
• Poeksperymentować z Kanbanem.
• Założyć konto na githubie

• Czytać 1 książki na miesiąc
• Pojechać na Agile2011 do stanów ani wziąć udział w Agile Testing Days w Berlinie
• Zostać prelegentem na konferencji
• Nauczyć się niemieckiego na tyle, by móc biernie uczestniczyć w spotkaniach prowadzonych po niemiecku.

W roku 2012 chciałbym:

• Pracować z ludźmi, od których mogę się bardzo dużo i szybko uczyć (tak jak to było w roku 2011)
• Pojechać jako wolontariusz na QCon i wziąć udział w 2 innych dużych konferencjach (XP? GOTO? ALE?)
• Zorganizować coś otwartego w Nokii, np. co 2 tydzień robić otwarte Coding Dojo dla ludzi z poza firmy
• Co najmniej raz w miesiącu brać udział w spotkaniu społeczności w Berlinie
• Wziąć udział w CodeRetreat jako uczestnik
• Wygłosić 6 mów w Toastmasters. Wziąć udział w konkursie na najlepszą mowę w klubie.
• Czytać jedną książkę na miesiąc
• Spopularyzować refactor-my-code step by step
• Poprowadzić wykład dla studentów
• Założyć anglojęzycznego bloga
• Nauczyć się biegle innego języka niż Java (Ruby?).
• Oglądać co najmniej jedną prezentację na tydzień (np. z infoq, ted)
• Spróbować wcielić w życie koncepcję lunch with a stranger w pracy.
• Zorganizować mini konferencję w pracy.
• Stworzyć „continuous delivery pipeline” dla projektu, w którym teraz pracuję
• Certyfikować się w jakieś kolejnej technologii

Jakie są Twoje plany na rok 2012?

Daj znać innym

Pomyślałem, super by było, gdyby ktoś mi pokazał jak napisać to lepiej.. „Refactor my code”.. Po krótkim googlowaniu okazało się, że jest już taki serwis: http://refactormycode.com/

O ile nazwa jest już zajęta .. to mój pomysł miał jeszcze jeden istotny składnik. Założyłem, że ważne jest by „mój” kod nie tylko został poprawiony, ale żeby został poprawiony w małych kroczkach z wytłumaczeniem „dlaczego”, tak bym mógł się nauczyć i następnym razem sam napisać coś porządnie..

W gruncie rzeczy, to marzy mi się „coding dojo” rozproszone w czasie i przestrzeni. Piszę kod, który zapewne może zostać napisany lepiej. Chciałbym abyś wziął ten kod i w małych kroczak go ulepszył. Po każdym kroczku zrób commit i wyjaśnij co i dlaczego zrobiłeś.

Prototyp tego co mam na myśli dość szybko udało mi się stworzyć przy pomocy githuba.

https://github.com/dziemid/refactormycode

Napisałem  dość brzydką wersję String Calculatora , którą następnie trochę  poprawiłem .. Nie mniej wersja końcowa nie jest aż tak ciekawa jak sam proces jej tworzenia, gdzie każdy mały kroczek został udokumentowany.

Pomysł został podchwycony przez Martina, która zrefaktoryzował mój kod krok po kroku (tutaj jeden z jego kroków w raz z moim komentarzem).

Dziś wrzuciłem kolejny kod do poprawienia: Grę w życie w Javie. Kod jest napisany średnio. Miejscami jest brzydki, niektóre klasy są w ogóle niepotrzebne, inne klasy robią rzeczy, które być może powinny być gdzie indziej.

Zachęcam Cię do zrobienia „Fork”a i zrefaktoryzowania tego kodu krok po kroku. W każdym commicie napisz co i dlaczego robisz. W ten sposób razem stworzymy coding dojo rozproszone w czasie i przestrzeni

Daj znać innym

Wczoraj rozmawiając z kolegą zaproponowałem zrobienie prostej aplikacji.

Odpowiedział: „O ciekawe! Myśleliśmy już o tym – super pomysł…. Kiedyś mieliśmy „dni innowacji”, ale potem z czasem jakoś przestaliśmy je robić. Gdzie podziały się te pomysły?”

Zapewne jest wiele sposobów na podtrzymanie ekscytującej atmosfery w pracy.

Oczywiście potrzeba ludzi wkręconych i kochających to co robią. Ale Ci ludzie pozostawieni sami sobie z czasem popadną w rutynę, będą znali się na wylot, będą mieli swoje ulubione techniki i style pracy.

Naszemu zespołowi może pomóc: czytanie książek, blogów, Twittera i wyjazdy na konferencje. To zapewni przypływ świeżych pomysłów.

Ale skąd brać siły na ich wdrażanie w terenie, który jest dobrze zbadany i unormowany? Czasem, zwłaszcza z małymi rzeczami nie jest to problem: „Spróbujmy przez tydzień programować w parach.. Hmm, czemu nie?„.

Czasem nie jest to takie proste: „Spróbujmy wrzucać nasz soft na produkcje jednym kliknięciem myszki.. No co ty, to się nie uda, za dużo biurokracji, próbowaliśmy„. Każdy wie, że jest coś czego nie da się zrobić, ale przychodzi ktoś kto nie wie, że się nie da i robi to ! ” Albert Einstein. Jednym słowem potrzebujemy studenta .. Lub, kogoś z autorytetem i wiedzą że się da, bo zrobił to gdzie indziej: konsultanta.

Na chwilę obecną uważam, że by zapewnić przepływ świeżej krwi w zespole potrzeba: konsultantów, którzy są z zespołem od 3 do 6 miesięcy i studentów. Konsultanci wzbogacą zespół ideami z innych miejsc, w których byli. Studenci będą zadawać pytania. Wszystko to zachwieje ustalonym statusem quo i zapewni jakże potrzebny powiew świeżości.

Masz jakieś doświadczenia lub przemyślenia w tym temacie?

Daj znać innym

Na otwarcie konferencji Google przygotowało niespodziankę – nowy język programowania Dart. Dokładnie, została zaprezentowana wczesna wersja języka, nad którym ciągle trwają prace.

Jest to język opcjonalnie typowany. Możesz używać typów, ale nie musisz. Jeśli będziesz używał typów, kompilator pomoże Ci podpowiadając co dany typ potrafi lub sugerując, że chyba używasz nie poprawnego typu. Nie mniej kompilator nie będzie Cię do niczego zmuszał – to czy Twój program będzie działał czy nie, okaże się po uruchomieniu (podobnie jak w przypadku JavaScript).

Po co nowy język?

• Dart ma być językiem, w którym „trudno” jest pisać nie wydajne programy. Google chce ułatwić swoim programistom pisanie aplikacji, które działają szybko.
• Dart kompilowany jest do JavaScriptu, więc może działać na większości „nowoczesnych” przeglądarek. Trwają również prace nad maszyną wirtualną Darta, która będzie częścią przeglądarki Chrome. Jedna z ciekawszych opcji: „snapshot” kodu (kod może zostać prekompilowany i dostarczony do przeglądarki w postaci gotowej do wczytania do pamięci), ułatwiający bardzo szybki i wydajny start aplikacji.
• Model konkurencji zaczerpnięty z języka Erlang. Izolaty na wzór aktorów.
• Przemawia do ludzi z dwóch obozów (języki dynamiczne (JavaScript), języki silnie typowane(Java)
• Być może zastąpi Javę na platformie Android?

• http://try.dartlang.org/
• http://www.dartlang.org/
• http://dartinside.com/

Język wydaje się fajny. Na następnym dojo zaproponuje, by rozwiązać w nim jakiś problem. Ciebie również zachęcam do poeksperymentowania

Daj znać innym

Warsztaty: A user user manual (how to build software that works the way your users think) z Chrisem Nodderem

W czasie warsztatów kilka razy przewinęło się: „Obserwuj normalnych użytkowników używających twoje oprogramowanie. Będziesz zaskoczony co z nim robią” (Tip: Ludzie z branży IT nie są normalni Są z reguły ekspertami w korzystaniu z komputerów).

Materiał przedstawiony w warsztatach został podzielony na zasady dotyczące:

• aspektów poznawczych
• komputery dobrze radzą sobie z „liczeniem” i „pamiętaniem” – w przeciwieństwie do ludzi. Tworząc nasze interfejsy powinniśmy o tym pamiętać, i nie zmuszać ludzi do wykonywania tych czynności.
• aspektów dotyczących postrzegania
• Zasada grupowania - jako grupy postrzegamy obiekty które: są blisko siebie, są podobne do siebie, tworzą rozpoznawalny kształt
• superstitious behavior - zabobonne zachowanie. Użytkownicy czasem doszukują się prawidłowości tam gdzie ich nie ma. Zawsze włączam najpierw Worda, a dopiero potem Internet Explorera, bo w tej kolejności działa (zadziałało kiedyś).
• Użytkownicy nie czytają tego, co do nich piszesz! Nie czytamy tekstu – skanujemy. Z badań z wykorzystaniem śledzenia ruchu gałek ocznych wynika, że ludzkie oczy skanując tekst bardzo często podążają za wzorem litery F. Czytamy pierwsze kilka zdań tekstu, następnie pierwsze słowa w lewej części ekranu, aż „wyczujemy” zapach interesującej nas informacji. Wtedy zaczynamy znów czytać dokładniej. Skąd charakterystyczny kształt litery F.
• aspektów fizycznych
• Prawo Fitt’a. Łatwiej jest kliknąć w coś dużego, niż w coś małego
• Nazwy przycisków, linki, powinny opisywać co robią. Zamiast „OK” -> „Zapisz”. Zamiast „Kliknij tu” -> „Przejdź do koszyka z zakupami”.
• Jak bardzo cierpliwi jesteśmy?
• mniej niż 0.1 sekundy, gdy przeciągamy coś po ekranie
• mniej niż 1 sekunda, po kliknięciu w przycisk
• mniej niż 10 sekund, by utrzymać koncentrację na aktualnym zadaniu, np. startowanie aplikacji (by rozpocząć z nią pracę).
• Historia dotycząca „cierpliwości” i instalacji Windows Service Pack 2 dla systemu XP. Proces instalacji tego serwis packa wymagał restartu systemu, po którym system „wstawał” na wielu komputerach przez parę minut. W tym czasie ekran był „czarny”. W czasie testów z użytkownikami, okazało się że wielu z nich widząc czarny ekran „tak długo” decydowało się zrestartować komputer jeszcze raz. Powodowało to trwałe uszkodzenie systemu. Problem został rozwiązany przez zastosowanie stałego wizualnego indykatora postępu: kropek wypisywanych na ekran w odstępie około jednej sekundy.
• aspektów dotyczących „workflow”ów
• „Sprytne” wartości domyślne. Pokazując, która opcja jest preferowana/domyślna, ułatwiamy życie użytkownikom. Większość użytkowników nie zmienia wartości domyślnych. „Sprytne” – by je zdefiniować, czasem potrzebne jest badanie na użytkownikach by „odkryć” co jest preferowanym wyborem.
• Użytkownik może mieć więcej lub mniej kontroli nad wykonywanym zadaniem. Może być prowadzony (przy pomocy „wizarda”) lub sam może decydować o wykonywanych akcjach i ich kolejności. „Wizardy” są preferowane dla zadań, które użytkownicy wykonują rzadko i nie są w nich biegli.
• Ujawniaj informacje stopniowo. Np. w czasie instalacji można wybrać instalację „standardową”. Dla ciekawskich, dostępna jest opcja by kliknąć i dokładnie dowiedzieć się, co składa się na tę instalację.
• aspektów dotyczących komunikacji
• Wydrukuj wszystkie „ekrany” w aplikacji i powieś obok siebie na ścianie. Czy są spójne?
• „Pomoc nie pomaga”. Bardzo często pomoc pisana jest z perspektywy funkcji, jakie aplikacja dostarcza. Użytkownicy z reguły szukają pomocy na temat tego, jak wykonać jakieś zadanie. Dlatego np. FAQ są bardzo skuteczne.
• jak zachwycać użytkowników
• Czy użytkownicy używając danej funkcjonalności będą zachwyceni?

Daj znać innym

W telegraficznym skrócie:

Niedziela

• Warsztaty A user user manual z Chrisem Nodderem. Porady na temat tego jak tworzyć przyjazne i łatwe w użytkowaniu oprogramowanie + teoria na temat tego, jak zachowują się użytkownicy i dlaczego.

Poniedziałek

• Google prezentuje nowy język programowania – Dart

Wtorek

• TODO

 Środa

• TODO

Czwartek

• Warsztaty „Evolutionary Architecture – How to Make it Work” z Martinem Fowlerem i Rebeccom Parsons
• Warsztaty ”Influence Strategies for Practitioners” z Linda Rising

Piątek

• Warsztaty ”Maintaining and Evolving Legacy Systems” z Frankiem Buschmann

Ogólne komentarze i podsumowanie:

W tym roku do materiałów konferencyjnych dołączone zostały dwie małe książeczki: „The 3 pillars of personal effectiveness” oraz „Priming Kanban” - oryginalne i fajne posunięcie.

I tak na przykład w „Priming Kanban” wyczytałem, co robić gdy osiągamy limit „work in progress„. Jest to moment na dyskusję. Do wyboru mamy albo powiększyć limit (co będzie skutkować zwiększeniem czasu, jaki jest potrzeby by historyjka przewędrowała od „koncepcji” do „wdrożenia”) albo usprawnić/wspomóc „wąskie gardło”. Np. gdy „testowanie” jest wąskim gardłem, może jako programiści możemy zautomatyzować wrzucanie nowej wersji na środowisko testowe? Tak czy inaczej, osiągnięcie limitu „work in progress” jest pretekstem do dyskusji.

Konferencja to również męczące wydarzenie (pełno wrażeń, codziennie integracja), nie mniej z niecierpliwością czekam na kolejną konferencję organizowaną przez Trifork, QCon 2012 w Londynie

Daj znać innym

Podczas tego warsztatu zadaniem uczestników jest napisanie aplikacji webowej, która odpowiadać będzie na zapytania „wirtualnych” klientów. Uczestnicy warsztatu nie wiedzą, co ich czeka i z logów serwera muszą wywnioskować, czego chcą klienci.

Klienci będą między innymi pytać:

• Ile jest 2 + 5?
• Która z tych liczb się największa: 4, 234, 2, 4?
• Jaki kolor ma banan?

W warsztacie wzięło 8 osób, zostały uformowane 4 pary. Zaczęliśmy o 1700 i około 50 minut zajęła nam sesja próbna, gdzie uczestnicy konfigurowali sieć tak, by móc połączyć się z serwerem i odpowiedzieć na proste zapytanie „Jak masz na imię”.

Około 18 zaczęliśmy ”prawdziwą” rundę z normalnymi pytaniami. Niestety z braku czasu, runda trwała tylko około 45 minut. Na przyszłość, „normalna” runda powinna trwać co najmniej 90 minut. Na potrzeby warsztatu przygotowane jest 6 zestawów pytań i wczoraj dobrnęliśmy tylko do trzeciego, a tak naprawdę mało który zespół miał poprawnie zaimplementowane wszystkie pytania z 2 pierwszych zestawów.

Z 4 zespołów tylko jeden pisał testy. Wszystkim zespołom poszło „podobnie źle” – zdobyły po około -2000 punktów. Prawdopodobnie gdyby warsztat trwał dłużej, to w miarę implementowanie poprawnych odpowiedzi dla kolejnych pytań, pary wyszłyby na prostą.

Pary, które używały „cięższych” serwerów aplikacji (jak Jetty ) traciły sporo punktów podczas redeployu aplikacji. Niestety nikt nie pokusił się o rozwiązanie z load balancerem

Technologie jakich używali uczestnicy

• Scala
• Node.js
• Groovy
• Smalltalk, a potem z powodu problemów Java

Ogólnie chyba się podobało .. Może powtórzymy ten warsztat za jakiś czas…

Daj znać innym