Wpisy otagowane ‘xp’

Praktyki stosowane w moim zespole

niedziela, 15 Styczeń 2012

W ramach „Poranku z Nokią i z SEnSem” poprowadziłem na PWr skierowany do studentów  wykład o praktykach stosowanych w moim zespole.

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:

(więcej…)

Retrospekcje – najważniejsze narzędzie w Agile?

piątek, 15 Lipiec 2011

W czasie jednej z luźnych rozmów z Alexem poprzedzających CodeRetreat poruszyliśmy temat retrospekcji.

Zgodziłem się z nim, że retrospekcje są bardzo ważnym elementem procesu wytwarzania oprogramowania. Jest to jedno z pierwszych narzędzi jakie wprowadza do zespołu Alex jako trener.

W czasie rozmowy zdałem sobie sprawę, że nie pamiętam kiedy dokładnie mój zespół miał retrospekcję. Wytłumaczyłem Alexowi, że w naszym zespole wszystko idzie dobrze, a ponadto regularnie mamy sesje feedbacku 1-1. Mina Alexa wskazywała na powątpiewanie :)

Alex wyraził opinię, że nie powinniśmy zaniedbywać retrospekcji. Następnie opowiedział trochę o jego obserwacji na temat deweloperów: „są bardzo odporni na ból” – z reguły nie narzekają i robią swoje. Dlatego Alex kładzie szczególny nacisk na zachęcenie deweloperów by zwracali szczególną uwagę na wszelki ból jaki odczuwają  ”sprzęt jest za wolny, IDE nie wspiera wykonywanych zadań, za dużo spotkań” itp.

W poniedziałek w pracy zasugerowałem: „kiedy właściwie mieliśmy ostatnią retrospekcję?:)”.

Na wczorajszej retrospekcji zidentyfikowaliśmy kilka konkretnych i poważnych spraw do załatwienia – warto było się spotkać i spojrzeć z boku na to co się dzieje :) -

Nie zaniedbuj swoich retrospekcji! Spotykajcie się co najmniej raz na miesiąc! (gdy są problemy, częściej!).

Jaki jest klucz do efektywnych retrospekcji? Zapiszcie konkretne akcje, które mają na celu polepszenie sytuacji / rozwiązanie (częściowe) problemów i przypiszcie konkretne osoby do tych akcji. Następnie akcje zawieście w widocznym miejscu na ścianie waszego pokoju.

Ps. Jeśli na prawdę wszystko idzie świetnie, retrospekcje są miejscem w którym można proponować i oceniać eksperymenty. Na przykład my w najbliższym czasie będziemy eksperymentować z WIP.

XP2011 – kto nie był niech żaluje!

sobota, 14 Maj 2011

Ostatni tydzień spędziłem jako wolontariusz na konferencji XP2011 w Madrycie. Atmosfera na konferencji była niesamowita. Jako wolontariusze nawiązaliśmy przyjaźnie, które przetrwają bardzo długo ;) Było masę śmiechu, dobrej zabawy, nauki, wymiany doświadczeń, dobrego jedzenia i sangrii. Hiszpania to magiczne miejsce, a otwartość, serdeczność i pogoda ducha naszych gospodarzy udzieliła się wszystkim! :)

Krótkie podsumowanie konferencji.

Po pierwsze, bliska mojemu sercu inicjatywa AgileLeanEurope Network nabiera rozpędu. W czasie konferencji odbyło się kilka sesji podczas których powstała wizja sieci, zaproponowano konkretne inicjatywy (na przykład Agile Couch Surfing), a co szczególnie istotne dla mnie omówiono pierwsze szczegóły konferencji ALE, która odbędzie się we wrześniu w Berlinie.

Konferencja ALE w Berlinie będzie szczególna, bo stawia sobie za cel łączenie ludzi ze wszystkich krajów europejskich. Chcemy mieć reprezentantów z każdego kraju wśród mówców, uczestników i wolontariuszy.  Dla mnie w szczególności będzie to szczególna konferencja, bo po raz pierwszy podejmę się roli koordynatora wolontariuszy, co mam nadzieję będzie świetną zabawą i okazją do nauki.

Wracając do XP2011.. W konferencji uczestniczyło około 200 osób co wydaje się być optymalnym rozmiarem, bo ułatwia nawiązywanie kontaktów z innymi uczestnikami. Nie jest się aż tak anonimowym jak pośród 800 uczestników np. QCona.

Warsztat Extreme Startup z Robert Chatley i Matt Wynne był dla mnie jednym z ciekawszych kąsków. Było to coś w rodzaju zawodów/coding dojo/symulacja w jednym. Warsztat polegał na tym, że mieliśmy w zespołach stworzyć strony, które „wygenerują” największy zysk. By uczestniczyć w zabawie należało postawić serwer http, którego adres należało zarejestrować na serwerze organizatorów. Od momentu rejestracji serwer organizatorów wysyłał do naszego serwera proste zapytania, na które nasz serwer musiał odpowiadać. Jeśli odpowiadał dobrze, to dostawaliśmy punkty, jeśli źle lub nasz serwer był niedostępny to punkty traciliśmy.

Przykładowe zapytania, które do nas trafiały to na przykład „Która liczba jest największa? 100, 2, 44″, „Jaki kolor ma banan?”, „Która liczba jest jednocześnie kwadratem i sześcianem jakiś liczb całkowitych”, „Kto jest premierem wielkiej Brytanii”, „Ile jest 2 plus 4″, „Ile jest 2 razy 5″, „Ile jest 6 do potęgi 7″, „Ile jest 2 razy 5 plus 7″. Każde zapytanie opatrzone było unikalnym ID, a na stronie serwera organizatorów mieliśmy log, z którego mogliśmy wyczytać czy za dane zapytanie przyznano nam punkty czy nie.

Zabawa trwała godzinę (moim zdaniem trochę za krótko) i była maksymalnie emocjonująca i wciągająca. Zapytania napływały w dużym tempie, na rzutniku na bieżąco prezentowany był ranking wszystkich drużyn.

W/g organizatorów warsztat miał pokazać w praktyce, że czasem warto jest coś szybko wrzucić na produkcję, nawet jeśli nie generuje to zawsze dobrych odpowiedzi – analogicznie jako warto czasem wrzucić na produkcję stronę umożliwiającą dodanie do koszyka, a nie umożliwiającą zakupu, by dowiedzieć się czy w ogóle ktoś jest zainteresowany zakupem. Ogólnie rzecz biorąc filozofia Lean Startup. Dodatkowo warsztat miał pokazać, że o ile na początku można zacząć z „okropnym” kodem po to tylko, by jak najszybciej zacząć generować zyski, to w końcu trzeba poświęcić czas na refactoring bo inaczej kod stanie się zbyt zagmatwany i nie będziemy w stanie reagować szybko na zmiany w zachowaniu klientów. W czasie naszego warsztatu w naszym kodzie zaczynało to być widoczne (konieczność refactoringu), ale myślę że gdybyśmy pograli jeszcze drugą godzinę to ta potrzeba była by jeszcze bardziej oczywista. Anyway, zabawę możecie powtórzyć „u siebie”. Kod serwera organizatorów można znaleźć tutaj.

Więcej informacji w XP2011 w kolejnym poście.

Automatyczne testowanie kodu – jak to robić?

poniedziałek, 28 Marzec 2011

W tym wpisie zbiorę moją aktualną wiedzę na temat automatycznego testowania kodu.

Po pierwsze, aplikację możemy automatycznie testować na różnych poziomach i każdy z tych poziomów ma swoje „wady” i „zalety”. Dobrym wprowadzeniem to tematu jest prezentacja Neala Forda – „Testing the entire stack” .

Na warsztatach prowadzonych przez autorów książki Growing Object-Oriented Software Guided by Tests spotkałem się po raz pierwszy z koncepcją architektury „The Ports & Adapters” . Na podstawie tej architektury dobrze można pokazać, na którym poziomie co testujemy.

I tak na przykład testy jednostkowe służą do testowania pojedynczych klas, z których składa się nasz model biznesowy (Aplikacja, w tym artykule), testy akceptacyjne testują model biznesowy, testy systemowe testują cały system za pomocą zewnętrznych interfejsów (GUI, Web service), a testy integracyjne testują integrację naszego kodu, z kodem, którego nie możemy zmienić (np. testowanie adapteru używającego biblioteki służącej do pracowania na bazie danych).

(więcej…)