<?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>claudioromero.com.br &#187; Qualidade de Software</title>
	<atom:link href="http://www.claudioromero.com.br/weblog/category/qualidade-de-software/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.claudioromero.com.br/weblog</link>
	<description>Artigos, notícias e pensamentos sobre TI. Resultado das andanças diárias pela Web.</description>
	<lastBuildDate>Wed, 28 Apr 2010 22:48:52 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>O &#8220;mito&#8221; da documentação</title>
		<link>http://www.claudioromero.com.br/weblog/2009/08/08/o-mito-da-documentacao/</link>
		<comments>http://www.claudioromero.com.br/weblog/2009/08/08/o-mito-da-documentacao/#comments</comments>
		<pubDate>Sat, 08 Aug 2009 14:30:25 +0000</pubDate>
		<dc:creator>Claudio</dc:creator>
				<category><![CDATA[Engenharia de Software]]></category>
		<category><![CDATA[Geral]]></category>
		<category><![CDATA[Qualidade de Software]]></category>
		<category><![CDATA[Desenvolvimento Ágil]]></category>
		<category><![CDATA[Scrum]]></category>

		<guid isPermaLink="false">http://www.claudioromero.com/weblog/?p=84</guid>
		<description><![CDATA[Ultimamente tenho lido muito  respeito de desenvolvimento ágil, principalmente no que diz respeito a Scrum. Navegando por aí, caí no blog de James Shore, co-autor do livro &#8220;The Art of Agile Development&#8220;, da editora O&#8217;Reilly. Vasculhando o blog, vi um artigo chamado &#8220;The Documentation Myth&#8221;, que pode ser lido
na íntegra (e em inglês) clicando [...]]]></description>
			<content:encoded><![CDATA[<p>Ultimamente tenho lido muito  respeito de desenvolvimento ágil, principalmente no que diz respeito a Scrum. Navegando por aí, caí no blog de James Shore, co-autor do livro &#8220;<a href="http://jamesshore.com/Agile-Book/" target="_blank">The Art of Agile Development</a>&#8220;, da editora O&#8217;Reilly. Vasculhando o blog, vi um artigo chamado &#8220;The Documentation Myth&#8221;, que pode ser lido<br />
na íntegra (e em inglês) clicando <a href="http://jamesshore.com/Blog/The-Documentation-Myth.html" target="_blank">neste link</a>. Vale ressaltar que, assim como grande parte das pessoas que postaram comentários no referido blog, eu concordo/discordo de partes do texto, e cabe a cada um fazer sua avaliação pessoal. Mas achei bastante interessante e aqui sintetizo, em português, a idéia do mesmo:</p>
<blockquote><p><strong>O mito da documentação</strong></p>
<p>Um dos grandes mitos do desenvolvimento ágil é que equipes ágeis não documentam seu trabalho. Realmente, equipes ágeis preferem conversas cara-a-cara do que comunicação através de documentos, e preferem escrever documentação para manutenção, no final do projeto, do que no começo (significando menos retrabalho e garantido conteúdo atualizado).</p>
<p>Junto com as acusações de más práticas de documentação, há um outro mito: &#8220;Documentação é uma coisa boa&#8221;.</p>
<p>Pessoas pensam &#8220;estou tendo problemas para entender isto!&#8221; e, depois de quebrar a cabeça, amaldiçoam o desenvolvedor pela sua falta de visão de documentação.</p>
<p>Muitos programadores escrevem linhas e mais linhas de comentários, antes de realmente começar a implementar. Mas isso não significa que a implementação que vem a seguir é de qualidade! O bom, desta forma, não vem automaticamente (e necessariamente) da prévia documentação. Isto é um mito!</p>
<p>Então o que é realmente bom? O que é que estamos procurando quando vamos atrás da documentação? A resposta é: Respostas.</p>
<p>Se você mudar sua forma de pensar, procurando as respostas, e não apenas documentação em si, você irá mudar inteiramente sua perspectiva. <strong>Documentação então é um meio para um fim, e não um fim em si própria</strong>.</p>
<p>A realidade é: queremos respostas, elas sim nos ajudam. E o quanto mais rápido as temos, melhor é.</p>
<p>O melhor caso é quando, as vezes o próprio código fonte, bem escrito e com partes bem nomeadas, não precisa nem de comentários, é intuitivamente óbvio. XP prega isso, e realmente não é uma coisa fácil de atingir, mas é o que se deve tentar.</p>
<p>O segundo melhor caso é quando é possível perguntar a alguém e obter logo a resposta. É o caso de equipes ágeis, onde se recomenda ter equipes com seus membros distribuídos através de várias funções. Os ganhos de produtividade por causa da comunicação são incríveis.</p>
<p>Ainda, continua sendo bom ser possível ir ao Google e procurar pela respostas. Algumas vezes vou ao Google e digito minha mensagem de erro. Descubro que 500 pessoas tiveram o mesmo erro, e proveram soluções. Fantástico.</p>
<p>Por último da lista de como/onde obter resposta, está a atividade de ler documentação atrás da mesma. è claro que algumas vezes a documentação é divinamente organizada, maravilhosamente escrita, e prazerosa de ler. Sim. Mas muitas vezes não. E quanto mais documentação você tiver que ler para obter sua resposta, pior. Ter muita documentação não é bom. A única coisa boa sobre ter toneladas de documentação é o jeito como isso soa.</p>
<p>Então, da próxima vez que você ouvir alguém reclamando sobre a falta de comentários ou de documentação, pare-o por um momento. Do quê realmente ele está reclamando? O código não está claro? A biblioteca tem uma organização pobre? Talvez corrigir isso primeiro fosse a melhor solução. Ou, talvez, nada está errado, e esta pessoa está sucumbindo ao <strong>mito da documentação</strong>.</p></blockquote>
]]></content:encoded>
			<wfw:commentRss>http://www.claudioromero.com.br/weblog/2009/08/08/o-mito-da-documentacao/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
	</channel>
</rss>
