<?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: Talk su Test-driven development	</title>
	<atom:link href="http://matteo.vaccari.name/blog/archives/71/feed" rel="self" type="application/rss+xml" />
	<link>http://matteo.vaccari.name/blog/archives/71</link>
	<description>Extreme enthusiasm</description>
	<lastBuildDate>
	Mon, 25 Feb 2019 15:18:16 +0000	</lastBuildDate>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=5.1.1</generator>
			<item>
				<title>
				By: Uberto				</title>
				<link>http://matteo.vaccari.name/blog/archives/71/comment-page-1#comment-2300</link>
		<dc:creator><![CDATA[Uberto]]></dc:creator>
		<pubDate>Wed, 24 Jan 2007 11:13:15 +0000</pubDate>
		<guid isPermaLink="false">http://matteo.vaccari.name/blog/?p=71#comment-2300</guid>
					<description><![CDATA[Secondo me, c&#039;e&#039; un altro punto.
Nulla vieta negli agili di fare design prima. Quello che e&#039; &quot;vietato&quot; e&#039; il BigUpFront Design. Cioe&#039; un conto e&#039; fare design per il prossimo mese e un conto e&#039; mettersi un paio d&#039;ore a pensare come creare qualche classe prima di iniziare a scrivere codice.
Secondo me il TDD va bene dove non ci sono grossi problemi oppure dove dopo due ore non si e&#039; ancora trovato un &quot;buon design&quot;, allora tanto vale andare a tentoni col TDD.
Ma se il problema e&#039; gia&#039; conosciuto e non del tutto banale, basarsi un minimo di design iniziale non lo vedo affatto contrario ai principi dell&#039;Agile, tanto alla peggio si puo&#039; sempre rifattorizzare dopo.
Sono d&#039;accordo sul fatto che il design non puo&#039; essere fatto sempre da una stessa persona (anche se immancabilmente ci sara&#039; chi e&#039; piu&#039; bravo e chi meno).
Pero&#039; il TDD non e&#039; l&#039;unica tecnica per condividere il design, ci sono anche le sessioni con le CRC o le MindMap, per esempio.]]></description>
		<content:encoded><![CDATA[<p>Secondo me, c&#8217;e&#8217; un altro punto.<br />
Nulla vieta negli agili di fare design prima. Quello che e&#8217; &#8220;vietato&#8221; e&#8217; il BigUpFront Design. Cioe&#8217; un conto e&#8217; fare design per il prossimo mese e un conto e&#8217; mettersi un paio d&#8217;ore a pensare come creare qualche classe prima di iniziare a scrivere codice.<br />
Secondo me il TDD va bene dove non ci sono grossi problemi oppure dove dopo due ore non si e&#8217; ancora trovato un &#8220;buon design&#8221;, allora tanto vale andare a tentoni col TDD.<br />
Ma se il problema e&#8217; gia&#8217; conosciuto e non del tutto banale, basarsi un minimo di design iniziale non lo vedo affatto contrario ai principi dell&#8217;Agile, tanto alla peggio si puo&#8217; sempre rifattorizzare dopo.<br />
Sono d&#8217;accordo sul fatto che il design non puo&#8217; essere fatto sempre da una stessa persona (anche se immancabilmente ci sara&#8217; chi e&#8217; piu&#8217; bravo e chi meno).<br />
Pero&#8217; il TDD non e&#8217; l&#8217;unica tecnica per condividere il design, ci sono anche le sessioni con le CRC o le MindMap, per esempio.</p>
]]></content:encoded>
						</item>
			</channel>
</rss>
