Archiwa tagu: agile

Wrażenia po Agile By Example

Hmm… już drugi raz zabieram się za spisywanie wrażeń po konferencji w jakiś czas po jej zakończeniu. Może następnym razem użyję twittera zamiast bloga, żeby wszystko było na bieżąco 😉

Agile By Example to pierwsza agile’owa konferencja w Warszawie. Konferencja bardzo udana. Chciałbymsię teraz skupić nie tyle na jej opisywaniu, co na konkretnych rzeczach, które z niej wyniosłem.

Wartości a praktyki

Jutta Eckstein mówiła o agile’owych praktykach w zespołach rozproszonych. Ważną myślą dla mnie było to, żeby pamiętać, jak praktyki mają się do celów i wartości. Otóż samo stosowanie praktyk nie sprawi, że wspólne cele czy pożądane wartości (agile’owe/XP) pojawią się w zespole. Jest tak, że to z wartości wypływają praktyki. Stosowanie praktyk może pomóc we wprowadzaniu tych wartości czy w ich podtrzymaniu, ale nie sprawi, że się pojawią. Jutta namawia, aby rozważając rozpoczęcie jakieś praktyki odnieść ją do celów i wartości zespołu. Czy cel praktyki jest również naszym celem? Czy ten cel wspiera nasze wartości?

W moim zespole jest tak, że prawdopodobnie mamy wspólne wartości i cele, ale nie jestem w stanie ich w sposób pewny nazwać (tzn. mogę zgadywać). Z tego wynika, że nasze wartości nie są uświadomione. Co mogłoby nam dać uświadomienie ich? Może chociażby lepsze zrozumienie tego, jak działamy, jak działają dla nas różne praktyki. Daje to właściwie gotowy pomysł na retrospekcję czy dzień budowania zespołu.

Testy jednostkowe budują zaufanie

Z prezentacji Jutty biorę jeszcze jedną zgrabną myśl: testy jednostkowe budują zaufanie. Przede wszystkim chodzi o zaufanie do kodu, co ma ogromne znaczenie w zespołach rozproszonych. Myślę jednak, że można to rozszerzyć na wzajemne zaufanie deweloperów. Ufam kolegom z zespołu, bo widziałem, że tworzą rzetelne, kompletne testy wokół swego kodu.
Znów, mogę zadać pytanie o to jak jest w moim zespole – czy testy, które mamy, budują zaufanie (do kodu, do nas samych)?

Ekstremalne zasady

W zespołach rozproszonych, które rozciągają się na kilka stref czasowych, nie można pozwolić sobie na przekazywanie kolegom niedziałającego kodu. Stąd Jutta przytacza dość rygorystyczne zasady proponowane przez Josepha Pelrine’a:

Na koniec dnia:

  • kod jest wczekinowany
  • testy są zielone
  • build przechodzi
  • build trwa poniżej 10 minut

albo wyrzucasz wszystko i wracasz do ostatniej wersji, gdzie te warunki były spełnione. 

Mocne? Co by się stało, gdyby Twój zespół wprowadził takie zasady?

Twórczość w projektach IT

Prezentacje Moniki Konieczny i Marcina Maciejewskiego przypomniały mi o temacie twórczości. Twórczość budzi we mnie skojarzenia z „Treningiem twórczego myślenia„, z używaniem mazaków, kredek i dużych kartek, z nieskrępowanym wypowiadaniem własnych pomysłów w bezpiecznym środowisku.

Co zrobię z tym? Na razie zamówiłem kilka książek, żeby sobie przypomnieć co nieco w tym temacie.

User Stories – problem a nie rozwiązanie

Bardzo spodobało mi się spojrzenie Moniki i Marcina na User Stories. Otóż Marcin jako Product Owner przynosi User Story do zespołu jako historię, w której występują konkretne postacie, mające prawdziwe problemy. Zespół konfrontowany jest z takimi problemami i to jego zadaniem jest wymyślenie rozwiązania.
To podejście jest inne od tego, co spotkałem dotychczas, gdzie User Story od Product Ownera przychodziło maksymalnie wyspecyfikowanie, często łącznie z projektem ekranów aplikacji.
Jeśli Product Owner jest sam, to korzystając z potencjału zespołu może dojść do znacznie lepszych rozwiązań. Być może nie jest to potrzebne, jeśli rolę Product Ownera wypełnia dedykowany zespół np. analityków. Ale z tym rozwiązaniem spotkałem się tylko w opowieściach…

Historie i metafory

Nie wiem, czy ktoś jeszcze pamięta o takiej praktyce Extreme Programming jak Metafora. Może wkrótce sobie przypomnimy, bo podobno Agile 2.0 to XP :-).
Mi się przypomniało, gdy Marcin opowiadał o swoich wysiłkach poszukiwania metafor przy tworzeniu User Stories. Czy nasz system wieloagentowy działa podobnie jak „rój pszczół zbierających pyłek”? Czy jeśli użytkownik może coś zrobić dokładnie raz i tylko raz, to jest to podobne do „spotkania opryszka w ciemnym zaułku„?
Przyznam, że nie miałem dotąd okazji pracować w projekcie, w którym pojawiłyby się metafory choćby o takiej mocy. Wyobrażam sobie, że mogą mieć duży wpływ na to, jak się myśli o domenie, jak się projektuje. Jaki jest pierwszy krok, żeby spróbować? Jeszcze nie wiem.

Czas iść dalej…

Jeszcze wiele ciekawych myśli zainspirowało mnie na tej konferencji. Nie będę się już o nich rozpisywał, ale wypunktuję kilka:

  • Kanban jako sposób zarządzania zmianą w zespole (Paweł Brodziński)
  • Sposób na ćwiczenie refaktoryzacji – robić przykłady z książki „Refaktoryzacja” lub „Refaktoryzacja do wzorców projektowych” (Alexandru Bolboaca)
  • Wartość testów akceptacyjnych – budowanie jednakowego zrozumienia domeny przez klienta i zespół (Szczepan Faber)
  • Single command environment – mogę jednym poleceniem odtworzyć całe środowisko deweloperskie (Szczepan Faber)
  • Rola managera w Scrumie: ustal ograniczenia i daj zespołowi to, co potrzebuje, by wykonać pracę. Nic więcej – nic mniej. (Boris Gloger)

Mam nadzieję, że za rok spotkamy się na równie ciekawej konferencji na tym samym basenie 🙂