<?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>Comments on: scrum inibe a equipe?</title>
	<atom:link href="http://blog.fabiomassa.com.br/2009/02/14/scrum-inibe-a-equipe/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.fabiomassa.com.br/2009/02/14/scrum-inibe-a-equipe/</link>
	<description>reflexões e algumas viagens</description>
	<lastBuildDate>Sun, 24 Jul 2011 23:26:53 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Jonas Abreu</title>
		<link>http://blog.fabiomassa.com.br/2009/02/14/scrum-inibe-a-equipe/comment-page-1/#comment-2</link>
		<dc:creator>Jonas Abreu</dc:creator>
		<pubDate>Mon, 02 Mar 2009 00:16:54 +0000</pubDate>
		<guid isPermaLink="false">http://blog.fabiomassa.com.br/?p=11#comment-2</guid>
		<description>Olá Massa!

A equipe não pode se sentir inibida de forma alguma se está usando scrum. O ponto é que o segredo do scrum (pelo menos na minha experiência) está em saber o que conseguimos fazer dentro da timebox e de termos um scrum master que entenda que o que está na timebox não pode ser mudado (a não ser em casos de cancelamento de sprint ou de trocas por valor).

Outra coisa, independente do porque, quando um sprint atrasa não deve ser feita uma cassa às bruxas culpando as pessoas. Independente do que causou o problema, se a equipe não entregou o que ela se comprometeu no começo, a EQUIPE é culpada. Não um indivíduo. Individuos só devem existir da equipe pra dentro. Pra fora, o mundo deve ver como uma coisa só todos os programadores que fazem parte da equipe, para evitar pressão.

E compromentimento é fundamental. Lembro do meu primeiro sprint que deu errado (tivemos um dia de atraso, mas uma perda de qualidade muito grande na minha opnião). Me senti destruído, porque foi a primeira vez que não conseguimos entregar o que tinhamos nos proposto a fazer. Na verdade, aquele acabou sendo um dos melhores sprints, pois passamos a levar muito mais a sério tudo e a tentar resolver todos (sem exceção) os problemas assim que eles apareciam. E descobrimos como o review e cross inpection eram importantes.

Até!</description>
		<content:encoded><![CDATA[<p>Olá Massa!</p>
<p>A equipe não pode se sentir inibida de forma alguma se está usando scrum. O ponto é que o segredo do scrum (pelo menos na minha experiência) está em saber o que conseguimos fazer dentro da timebox e de termos um scrum master que entenda que o que está na timebox não pode ser mudado (a não ser em casos de cancelamento de sprint ou de trocas por valor).</p>
<p>Outra coisa, independente do porque, quando um sprint atrasa não deve ser feita uma cassa às bruxas culpando as pessoas. Independente do que causou o problema, se a equipe não entregou o que ela se comprometeu no começo, a EQUIPE é culpada. Não um indivíduo. Individuos só devem existir da equipe pra dentro. Pra fora, o mundo deve ver como uma coisa só todos os programadores que fazem parte da equipe, para evitar pressão.</p>
<p>E compromentimento é fundamental. Lembro do meu primeiro sprint que deu errado (tivemos um dia de atraso, mas uma perda de qualidade muito grande na minha opnião). Me senti destruído, porque foi a primeira vez que não conseguimos entregar o que tinhamos nos proposto a fazer. Na verdade, aquele acabou sendo um dos melhores sprints, pois passamos a levar muito mais a sério tudo e a tentar resolver todos (sem exceção) os problemas assim que eles apareciam. E descobrimos como o review e cross inpection eram importantes.</p>
<p>Até!</p>
]]></content:encoded>
	</item>
</channel>
</rss>

