<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Espeo Software &#187; agile</title>
	<atom:link href="http://www.espeo.pl/tag/agile/feed" rel="self" type="application/rss+xml" />
	<link>http://www.espeo.pl</link>
	<description>Oprogramowanie na zamówienie - aplikacje inter/intranetowe, desktop, mobilne. Wykorzystujemy technologię Java, Java EE, Flex, Grails</description>
	<lastBuildDate>Mon, 30 Jan 2012 14:34:55 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
		<item>
		<title>Global Day of Code Retreat w Poznaniu</title>
		<link>http://www.espeo.pl/2011/12/03/global-day-of-code-retreat-w-poznaniu</link>
		<comments>http://www.espeo.pl/2011/12/03/global-day-of-code-retreat-w-poznaniu#comments</comments>
		<pubDate>Sat, 03 Dec 2011 18:30:48 +0000</pubDate>
		<dc:creator>Łukasz Stachowiak</dc:creator>
				<category><![CDATA[agile]]></category>
		<category><![CDATA[Blog]]></category>
		<category><![CDATA[CodeRetreat]]></category>
		<category><![CDATA[jug]]></category>
		<category><![CDATA[metodyki]]></category>
		<category><![CDATA[poznan]]></category>

		<guid isPermaLink="false">http://www.espeo.pl/?p=4007</guid>
		<description><![CDATA[Dzisiaj odbył się drugi Poznański Code Retreat. Impreza organizowana była z okazji światowego dnia Code Retreat. Tysiące deweloperów na całym świecie przez cały dzień zmagało się z problemem Game of Life Johna Conwaya. I są to naprawdę tysiące deweloperów! Na oficjalnej stronie eventu znajduje się lista (która była aktualizowana live), o statusie spotkań w miastach na całym świecie: live.coderetreat.org. Prawdziwe szaleństwo widać było bardzo wyraźnie na twitterze obserwując tag #gdcr11. Jestem pod ogromnym wrażeniem rozmachu eventu oraz chęci dzielenia się wiedzą przez uczestników! Warsztaty podzielone były na 5 sesji. Każda sesja miała swój ściśle określony cel i narzucała pewne ograniczenia na sposób pisania przez nas kodu. Te ograniczenia sprawiały, że skupialiśmy się na różnych aspektach wytwarzania oprogramowania i co za tym idzie &#8211; pisanie rozwiązania ciągle tego samego problemu wcale nie było nudne!:) Wręcz muszę przyznać, że każda sesja odkrywała coś nowego! Wszystkich uczestników wspierali dzielni moderatorzy, którzy doglądali nas co chwilę i kierowali nas właściwą ścieżkę, gdy coś szło nie tak jak powinno. Po krótkim przywitaniu o 9:30 ruszyliśmy. W pierwszej sesji bez utrudnień, najpierw zapoznanie się z problemem (prawie nikt z uczestników nie brał udziału w ubiegłorocznej edycji), więc bez udziwnień. Poszło dość gładko, z kolegą z którym programowałem dość dobrze się zrozumieliśmy. Trzeba się było tylko troszkę hamować, bo za duże kroki na raz chcieliśmy robić. Ale sesja bardzo miła. Druga sesja zaczynała się od 10 minut bez programowania &#8211; tylko dyskusja z partnerem i skrobanie na kartce tego co chcemy stworzyć. Akurat trafiłem na osobę, która była bardzo biegła w programowaniu w Rubym, więc zabawa podwójna :) Bardzo ciekawie testy się tworzy w tym języku i mam nadzieje kiedyś znaleźć chwilę by się bliżej zapoznać. Sesja trzecia &#8211; no primitives! W tej sesji niestety nie udało mi się uczestniczyć z powodu innych obowiązków. Udało mi się tylko coś usłyszeć, że koncepcja pochodzi z firmy ThoughtWorks. Urodziła się na ten temat dyskusja co nam to daje i czy to nie komplikuje tylko rozwiązania jednak też nie udało mi się w tym uczestniczyć :-( Wybiła godzina 12:40 i przyjechał do nas obiadek :) Ziemniaczki, dewolaj z serem + bukiet surówek &#8211; bardzo dobre! Sesja czwarta &#8211; TDD as you meant it &#8211; to jest dość kontrowersyjne podejście. Już od samego początku zrodziła się ostra dyskusja wśród uczestników &#8211; po pierwsze &#8220;o co chodzi?&#8221; i po drugie &#8220;do czego to ma nas prowadzić?&#8221; TDD as you ment it polega na tworzeniu kodu produkcyjnego w testach(!). Dopiero w fazie refactoringu kod, który uznamy za dobrze ustrukturyzowany i godny trafienia do produkcji zostaje przeniesiony. Czemu to ma służyć? Wykorzenieniu przedwcześnie stworzonych założeń. Ten test ma &#8220;oszlifować&#8221; nasze założenia i pokazać nam co dokładnie ma powstać.  Bardzo ciekawa i wiele ucząca sesja! Zupełnie inne spojrzenie na tworzenie kodu. I sesja piąta &#8211; ostatnia. Na koniec programowanie bez myszki oraz z ograniczeniem, że metoda nie może mieć więcej niż 5 linii. Bardzo mi się podobała ta sesja. Nauczyłem się sporo nowych skrótów w Eclipse (nie jestem z nim za bardzo zżyty, NetBeans jest moim głównym narzędziem) i bardzo ładnie udało nam się spełniać założenia dotyczące długości metody (przy okazji zahaczając o jakieś design patterny;). Tak po krótce wyglądała całość. Naprawdę nie mogę powiedzieć złego słowa na temat ten Code Retreat.  Uczestniczy byli bardzo zaangażowani, dodatkowo wspierani przez moderatorów prowadzili bardzo ciekawe dyskusje na temat problemów jak i doświadczeń wyniesionych z zajęć. Fajnie wypadały retrospekcje, zbieraliśmy się kółku i dyskutowaliśmy. To były jedne z najlepszych warsztatów w jakich udało mi się brać udział! :) Oby więcej takich! Na chwilę pisania tego tekstu inne Code Retreat na świecie ciągle trwają! W Honolulu zaraz zaczynają -&#62; https://twitter.com/#!/coreyhaines/status/143030796893159424 :) EDIT Pojawiły się już jakieś zdjęcia ze spotkania. Postaram się uzupełniać listę w miarę pojawiania się nowych źródeł. https://www.facebook.com/media/set/?set=a.303656346322075.71148.204997069521337&#38;type=3&#38;l=ccff0fc5b3]]></description>
		<wfw:commentRss>http://www.espeo.pl/2011/12/03/global-day-of-code-retreat-w-poznaniu/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Coding Dojo w Espeo</title>
		<link>http://www.espeo.pl/2011/10/23/coding-dojo-w-espeo</link>
		<comments>http://www.espeo.pl/2011/10/23/coding-dojo-w-espeo#comments</comments>
		<pubDate>Sun, 23 Oct 2011 21:35:49 +0000</pubDate>
		<dc:creator>Pawel Ziemba</dc:creator>
				<category><![CDATA[agile]]></category>
		<category><![CDATA[Blog]]></category>
		<category><![CDATA[technologia]]></category>

		<guid isPermaLink="false">http://blog.espeo.pl/?p=696</guid>
		<description><![CDATA[Podczas ostatniego spotkania technologicznego urządziliśmy Coding Kata. Jako, że to było pierwsze Dojo dla większości uczestników postanowiłem uprościć zasady maksymalnie &#8211; tak by pokazać istotę samego spotkania. Było to jednym z celów. Drugim elementem było ćwiczenie TDD, które jest w firmie wykorzystywane, lecz praktyki nigdy za wiele. Najpierw o założeniach. Przyjęliśmy formułę Randori, czyli para programuje przy użyciu rzutnika, zmienialiśmy pary co 4 minuty, całość trwała godzinę, z czego ostatnie 10 minut przeznaczyliśmy na retrospekcję. Podczas dojo rozwiązywaliśmy Kata Misswaper. Mimo krótkiego czasu udało się wysnuć kilka wniosków. Jednym z nich był problem jaki wyszedł z TDD. Po refaktoryzacji powstała nowa klasa, podzieliły się metody. Po czym trudno było napisać test do nowej metody, który by nie przechodził&#8230; Wychodzi na to, że TDD sprawdza się w oparciu o gotowe założenia, czy testy akceptacyjne. W przypadku testów jednostkowych pojedynczych metod, testy te tracą na jakości. Podczas retrospekcji wyciągnęliśmy też kilka wniosków co do samej organizacji. Dla niewielkiej liczby osób nie jest konieczne programowanie w parach (o ile właśnie tego nie ćwiczymy). Krótki czas powinien być dobrze przygotowany, opóźnienia techniczne zjadają dużo cennego czasu. Parę dni później, gdy rozmawiałem o sensie prowadzenia przeglądu kodu i przewadze programowania w parach, pomyślałem, że Coding Kata mogło by być z powodzeniem wprowadzone do katalogu technik XP. W ten sposób można rozwiązywać nie tylko problemy natury ogólnej filozofii programowania, ale też konkretne problemy projektowe. Podsumowując, Coding Dojo jest bardzo integrującą i efektywną wymianą doświadczeń. Może być przydatne, jeśli mamy kilka zespołów pracujących długo nad oddzielnymi projektami.]]></description>
		<wfw:commentRss>http://www.espeo.pl/2011/10/23/coding-dojo-w-espeo/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Prezentacja product backlog refinement</title>
		<link>http://www.espeo.pl/2011/02/18/prezentacja-product-backlog-refinement</link>
		<comments>http://www.espeo.pl/2011/02/18/prezentacja-product-backlog-refinement#comments</comments>
		<pubDate>Fri, 18 Feb 2011 13:07:24 +0000</pubDate>
		<dc:creator>Tomasz Liberski</dc:creator>
				<category><![CDATA[agile]]></category>
		<category><![CDATA[Blog]]></category>
		<category><![CDATA[scrum]]></category>

		<guid isPermaLink="false">http://blog.espeo.pl/?p=393</guid>
		<description><![CDATA[Wczoraj dyskutowaliśmy w Espeo na temat Product Backlog Refinement, który jest bardzo ważnym, ale często pomijanym elementem w metodologii Scrum. Product Backlog Refinement (PBR) czyli przegląd backlogu to spotkanie, w którym uczestniczą Product Owner, Zespół i Scrum Master. PBR odbywa się zazwyczaj pod koniec sprintu. Podczas spotkania omawiane są historie użytkownika o najwyższym priorytecie. Duże historie dzielone są na mniejsze. Product Owner przy asyście Zespołu precyzuje wymagania zawarte w każdej historii, a następnie definiuje dla każdej z nich testy akceptacyjne. Historie użytkownika, które uległy zmianie, są ponownie estymowane. Product Owner może pod koniec spotkania dokonać zmiany priorytetów w Product Backlogu, informując o tym Zespół. Poświęcenie około godziny Zespołu na taki warsztat w każdym sprincie wydaje się dobrą inwestycją. Dzięki temu unikamy przykrych niespodzianek na początku sprintu, kiedy to np. okazuje się, że postęp blokowany jest przez oczekiwanie na działanie ze strony naszego administratora czy na zakup potrzebnej licencji. Oprócz tych wyjątkowych sytuacji uczestnictwo Zespołu i Product Ownera w PBR sprawia, że na początku sprintu wszyscy są bardziej zorientowani w wymaganiach co przekłada się na krótsze i potencjalnie dużo owocniejsze planowanie.]]></description>
		<wfw:commentRss>http://www.espeo.pl/2011/02/18/prezentacja-product-backlog-refinement/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Po projekcie &#8211; usprawniamy nasz Scrum</title>
		<link>http://www.espeo.pl/2011/01/27/po-projekcie-usprawniamy-nasz-scrum</link>
		<comments>http://www.espeo.pl/2011/01/27/po-projekcie-usprawniamy-nasz-scrum#comments</comments>
		<pubDate>Thu, 27 Jan 2011 17:54:56 +0000</pubDate>
		<dc:creator>Pawel Rogowicz</dc:creator>
				<category><![CDATA[agile]]></category>
		<category><![CDATA[Blog]]></category>
		<category><![CDATA[scrum]]></category>

		<guid isPermaLink="false">http://blog.espeo.pl/?p=384</guid>
		<description><![CDATA[Kolejny projekt zakończony, kolejna retrospekcja za nami, kolejne ciekawe wnioski do zaimplementowania. Tym razem przede wszystkim na poziomie metodyki (Scrum), w ramach ciągłego doskonalenia warsztatu. Najważniejsze rzeczy które nam przeszkadzały i co chcemy zmienić - brak jednoosobowej odpowiedzialności decyzyjnej u klienta &#8211; im więcej osób podejmujących decyzję tym gorzej dla zespołu, zwłaszcza gdy każdy z nich mówi co innego. Więc wypowiadać się może każdy ale decyzje podejmować musi jedna osoba - klienci nieznający dobrze metodyki &#8211; jak się okazuje często stosują tylko te elementy procesu, które im się podobają (chyba jak każdy z nas?), więc  kształcenie i jeszcze raz kształcenie.  Teraz na początkukażdego nowego projektu będziemy przeprowadzali szkolenie i dostarczali materiały &#8211; &#8220;Product owner guide&#8221; i wałkowali ile wlezie wszystkie scrumy, sprinty backlogi, nasze oczekiwania i co tak naprawdę dostarczamy,  tak by każdy wiedział o co chodzi i współpraca była bardziej efektywna. - kolejny raz widać, że developerzy nie potrafią testować &#8211; mimo, ze twierdzą, że potrafią i ze wszystko jest przetestowane bugów jest zbyt dużo.Więc kolejna lektura to &#8220;Agile Testing&#8221; i wprowadzanie zmian w życie. (a tak przyokazji to poszukujemy testerów umiejących pracować w Agile&#8217;u) Ciekawe natomiast jak to wygląda w innych firmach pracujących w Agile / Scrum, czy mają tego typu problemy i jak sobie z nimi radzą? Dobre rzeczy tez oczywiście były, wśród nich przede wszystkim atmosfera w zespole no i oczywiście ostateczne powodzenie projektu. Klient zadowolony, zespół też. Zapraszamy więc do oglądania i także używania naszego &#8220;dzieła&#8221; &#8211; http://freelancity.pl]]></description>
		<wfw:commentRss>http://www.espeo.pl/2011/01/27/po-projekcie-usprawniamy-nasz-scrum/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

