<?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: Talking about Agile</title>
	<atom:link href="http://www.taylor.se/blog/2005/11/24/talking-about-agile/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.taylor.se/blog/2005/11/24/talking-about-agile/</link>
	<description>Smart consulting</description>
	<lastBuildDate>Tue, 08 Jun 2010 05:02:39 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
	<item>
		<title>By: Unit testing internals</title>
		<link>http://www.taylor.se/blog/2005/11/24/talking-about-agile/comment-page-1/#comment-825</link>
		<dc:creator>Unit testing internals</dc:creator>
		<pubDate>Wed, 04 Oct 2006 11:49:19 +0000</pubDate>
		<guid isPermaLink="false">http://www.taylor.se/blog/2005/11/24/talking-about-agile/#comment-825</guid>
		<description>[...] One of the cool things about Dotway is that we have these &#8220;competence weekends&#8221; three or four times a year, where we go away to some hotel and geek out about something more or less of technical nature. As Andrés mentions recently we spent a weekend learning about TDD. One of the things that we discussed was how to test code that is not public. Normally you place your tests in a separate assembly and reference the production code. However, that means you need to make types and members public to be able to test them. So if you want to keep the implementation details hidden (with internal access level) you will need to have the tests in the same assembly as the production code. That brings further challenges in setting up the build environment to create different builds, since you naturally do not want to include the tests in the released code. [...]</description>
		<content:encoded><![CDATA[<p>[...] One of the cool things about Dotway is that we have these &#8220;competence weekends&#8221; three or four times a year, where we go away to some hotel and geek out about something more or less of technical nature. As Andrés mentions recently we spent a weekend learning about TDD. One of the things that we discussed was how to test code that is not public. Normally you place your tests in a separate assembly and reference the production code. However, that means you need to make types and members public to be able to test them. So if you want to keep the implementation details hidden (with internal access level) you will need to have the tests in the same assembly as the production code. That brings further challenges in setting up the build environment to create different builds, since you naturally do not want to include the tests in the released code. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Thought Leadership</title>
		<link>http://www.taylor.se/blog/2005/11/24/talking-about-agile/comment-page-1/#comment-5</link>
		<dc:creator>Thought Leadership</dc:creator>
		<pubDate>Mon, 19 Dec 2005 17:42:44 +0000</pubDate>
		<guid isPermaLink="false">http://www.taylor.se/blog/2005/11/24/talking-about-agile/#comment-5</guid>
		<description>&lt;strong&gt;Agile Software Construction&lt;/strong&gt;

Another very smart architect at work who happens to have my first name who is a believer in agile methods has been busy championing the incorporation of SCRUM into our lifecycle. I wonder if I could convince him to speak with others about dropping Th...</description>
		<content:encoded><![CDATA[<p><strong>Agile Software Construction</strong></p>
<p>Another very smart architect at work who happens to have my first name who is a believer in agile methods has been busy championing the incorporation of SCRUM into our lifecycle. I wonder if I could convince him to speak with others about dropping Th&#8230;</p>
]]></content:encoded>
	</item>
</channel>
</rss>
