<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	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/"
		>
<channel>
	<title>Komentarze do wpisu: Scrum a kultura bylejakości</title>
	<atom:link href="http://www.scrum.org.pl/2010/01/scrum-a-kultura-bylejakosci/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.scrum.org.pl/2010/01/scrum-a-kultura-bylejakosci/</link>
	<description>Polska Grupa Scrum</description>
	<lastBuildDate>Sat, 26 Feb 2011 20:00:24 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.1</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>Przez: Mariusz Opaliński</title>
		<link>http://www.scrum.org.pl/2010/01/scrum-a-kultura-bylejakosci/comment-page-1/#comment-100</link>
		<dc:creator>Mariusz Opaliński</dc:creator>
		<pubDate>Wed, 03 Nov 2010 08:20:38 +0000</pubDate>
		<guid isPermaLink="false">http://www.scrum.org.pl/?p=195#comment-100</guid>
		<description>Ja zadaję sobie zawsze pytanie przy takich analizach czy, jesli zespół pracowałby &quot;tradycyjną&quot; metodyką to także rezultat byłby podobny czy może lepszy lub gorszy.  Często odpowiedz brzmi - jeszcze gorszy

Scrum jest prosty ale nie znaczy to że łatwy. Scrum masterzy są lepsi i gorsi  i zgadzam sie,  Zespoły sa lepsze i gorsze.  Należy się zastanowić czy nie popełniono błędów przy adapfacji i filozofii Agile i metodyki Scrum

Scrum nie rozwiązuje wszystkich problemów, ale czyni je bardziej widocznymi i daje narzędzia  (Retrospektywa, Timeboxing,..) aby skuteczniej (częściej bo co sprint, wspólnie bo przez cały zespół ) je rozwiązywać 

Scrum to tylko framework zarządczy - pewne (moim zdaniem bardzo sprawne) ramy pracy które trzeba dopełnić - najlepiej technicznymi praktykami spod znaku Agile (np XP ) ale i nie tylko.  

Ciekawą inicjatywą jest  http://en.wikipedia.org/wiki/Software_craftsmanship

Nie lubię stwierdzenia Scrum nie działa i przejścia nad tym do porządku dziennego.   

Agile\ Scrum jest najbardziej projakościowym podejściem jakie znam.</description>
		<content:encoded><![CDATA[<p>Ja zadaję sobie zawsze pytanie przy takich analizach czy, jesli zespół pracowałby &#8220;tradycyjną&#8221; metodyką to także rezultat byłby podobny czy może lepszy lub gorszy.  Często odpowiedz brzmi &#8211; jeszcze gorszy</p>
<p>Scrum jest prosty ale nie znaczy to że łatwy. Scrum masterzy są lepsi i gorsi  i zgadzam sie,  Zespoły sa lepsze i gorsze.  Należy się zastanowić czy nie popełniono błędów przy adapfacji i filozofii Agile i metodyki Scrum</p>
<p>Scrum nie rozwiązuje wszystkich problemów, ale czyni je bardziej widocznymi i daje narzędzia  (Retrospektywa, Timeboxing,..) aby skuteczniej (częściej bo co sprint, wspólnie bo przez cały zespół ) je rozwiązywać </p>
<p>Scrum to tylko framework zarządczy &#8211; pewne (moim zdaniem bardzo sprawne) ramy pracy które trzeba dopełnić &#8211; najlepiej technicznymi praktykami spod znaku Agile (np XP ) ale i nie tylko.  </p>
<p>Ciekawą inicjatywą jest  <a href="http://en.wikipedia.org/wiki/Software_craftsmanship" rel="nofollow">http://en.wikipedia.org/wiki/Software_craftsmanship</a></p>
<p>Nie lubię stwierdzenia Scrum nie działa i przejścia nad tym do porządku dziennego.   </p>
<p>Agile\ Scrum jest najbardziej projakościowym podejściem jakie znam.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Przez: Andy Brandt</title>
		<link>http://www.scrum.org.pl/2010/01/scrum-a-kultura-bylejakosci/comment-page-1/#comment-57</link>
		<dc:creator>Andy Brandt</dc:creator>
		<pubDate>Wed, 10 Feb 2010 17:17:53 +0000</pubDate>
		<guid isPermaLink="false">http://www.scrum.org.pl/?p=195#comment-57</guid>
		<description>W/g mnie niedokończony sprint jest zawsze porażką. Należy oczywiście zastanowić się wspólnie czy jest to porażka planowania, wykonania czy wynik nieprzewidywalnych zdarzeń lub okoliczności (choćby większego skomplikowania zadania niż się wydawało). W każdym przypadku nie można przejść nad tym gładko do porządku jak gdyby nic się nie stało, a już napewno nie można robić tego konsekwentnie. 

Oczywiście, sprawa jest delikatna bo to zespół powinien sam jakby dojść do tego, sam czuć się źle z tym, że nie dotrzymał swoich zobowiązań w jakiś sposób. Dlatego najlepszym rozwiązaniem jest dobra retrospekcja - i dlatego jest taka ważna. Retrospekcje to jest w ogóle  rzecz, której robii się zdecydowanie za mało - my sami robimy je zdecydowanie za rzadko.</description>
		<content:encoded><![CDATA[<p>W/g mnie niedokończony sprint jest zawsze porażką. Należy oczywiście zastanowić się wspólnie czy jest to porażka planowania, wykonania czy wynik nieprzewidywalnych zdarzeń lub okoliczności (choćby większego skomplikowania zadania niż się wydawało). W każdym przypadku nie można przejść nad tym gładko do porządku jak gdyby nic się nie stało, a już napewno nie można robić tego konsekwentnie. </p>
<p>Oczywiście, sprawa jest delikatna bo to zespół powinien sam jakby dojść do tego, sam czuć się źle z tym, że nie dotrzymał swoich zobowiązań w jakiś sposób. Dlatego najlepszym rozwiązaniem jest dobra retrospekcja &#8211; i dlatego jest taka ważna. Retrospekcje to jest w ogóle  rzecz, której robii się zdecydowanie za mało &#8211; my sami robimy je zdecydowanie za rzadko.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Przez: bartek</title>
		<link>http://www.scrum.org.pl/2010/01/scrum-a-kultura-bylejakosci/comment-page-1/#comment-56</link>
		<dc:creator>bartek</dc:creator>
		<pubDate>Sat, 06 Feb 2010 10:55:49 +0000</pubDate>
		<guid isPermaLink="false">http://www.scrum.org.pl/?p=195#comment-56</guid>
		<description>Ciekawy artykuł. Zgadzam się z tym, że tak jak w przypadku informatyzacji chaosu masz zinformatyzowany chaos, tak i przy wprowadzeniu zwinnych zasad SCRUMa w kulturze bylejakości efektem będzie jeszcze większa bylejakość. Ken Schwaber w googlu mówił że SCRUM działa ze wszystkimi (użył słowa idioci), tyle że za każdym razem na koniec sprintu masz bubel.

Widziałem taki zespół. Ruszenie go z posad status quo było trudne i nie do końca się to udało. Zdecydowanie ziarno Scruma zaowocuje najlepiej tam, gdzie ludzie są otwarci na zmianę, chcą się uczyć i lubią to co robią. 

Wspomniałeś w artykule o czymś co mnie zainteresowało.Ostatnio byłem na wrocławskim spotkaniu Agilopolis gdzie dyskutowano o tym w jakich kategoriach nalezy traktować sprint, w którym zespołowi nie udało się wszystkiego zrobić. Było kilka zdecydowanych głosów, że nie można mówić o porażce zespołu czy rozpatrywać wynik w kategoriach winy. Mówiono raczej o sprincie w którym nie wykonano wszystkich zadań. Ja osobiście się z tym zgadzam - faktycznie może to działać demotywująco na zespół. Niemniej jednak granica między mówieniem o sprincie że się nie udał i był porażką a tym że zespół nie zrobił wszystkiego co zaplanował jest cienka i łatwo ją przekroczyć. 
Jak według Was powinno mówić się o sprincie który się nie udał? Ciekawy jestem jakie macie zdanie na ten temat.</description>
		<content:encoded><![CDATA[<p>Ciekawy artykuł. Zgadzam się z tym, że tak jak w przypadku informatyzacji chaosu masz zinformatyzowany chaos, tak i przy wprowadzeniu zwinnych zasad SCRUMa w kulturze bylejakości efektem będzie jeszcze większa bylejakość. Ken Schwaber w googlu mówił że SCRUM działa ze wszystkimi (użył słowa idioci), tyle że za każdym razem na koniec sprintu masz bubel.</p>
<p>Widziałem taki zespół. Ruszenie go z posad status quo było trudne i nie do końca się to udało. Zdecydowanie ziarno Scruma zaowocuje najlepiej tam, gdzie ludzie są otwarci na zmianę, chcą się uczyć i lubią to co robią. </p>
<p>Wspomniałeś w artykule o czymś co mnie zainteresowało.Ostatnio byłem na wrocławskim spotkaniu Agilopolis gdzie dyskutowano o tym w jakich kategoriach nalezy traktować sprint, w którym zespołowi nie udało się wszystkiego zrobić. Było kilka zdecydowanych głosów, że nie można mówić o porażce zespołu czy rozpatrywać wynik w kategoriach winy. Mówiono raczej o sprincie w którym nie wykonano wszystkich zadań. Ja osobiście się z tym zgadzam &#8211; faktycznie może to działać demotywująco na zespół. Niemniej jednak granica między mówieniem o sprincie że się nie udał i był porażką a tym że zespół nie zrobił wszystkiego co zaplanował jest cienka i łatwo ją przekroczyć.<br />
Jak według Was powinno mówić się o sprincie który się nie udał? Ciekawy jestem jakie macie zdanie na ten temat.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Przez: Przemek</title>
		<link>http://www.scrum.org.pl/2010/01/scrum-a-kultura-bylejakosci/comment-page-1/#comment-53</link>
		<dc:creator>Przemek</dc:creator>
		<pubDate>Sun, 31 Jan 2010 22:46:30 +0000</pubDate>
		<guid isPermaLink="false">http://www.scrum.org.pl/?p=195#comment-53</guid>
		<description>Trafiłeś w sedno. Przynajmniej dwa razy miałem do czynienia z ludźmi, którzy byli bardzo krytycznie nastawieni wobec Agile, ponieważ ich doświadczenia dowodziły, że oznacza to po prostu brak zarządzania w ogóle...</description>
		<content:encoded><![CDATA[<p>Trafiłeś w sedno. Przynajmniej dwa razy miałem do czynienia z ludźmi, którzy byli bardzo krytycznie nastawieni wobec Agile, ponieważ ich doświadczenia dowodziły, że oznacza to po prostu brak zarządzania w ogóle&#8230;</p>
]]></content:encoded>
	</item>
</channel>
</rss>

