<?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/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: Outcomes over Features &#8211; the fifth agile value?</title>
	<atom:link href="http://blog.dannorth.net/2006/10/28/outcomes-over-features-the-fifth-agile-value/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.dannorth.net/2006/10/28/outcomes-over-features-the-fifth-agile-value/</link>
	<description>It&#039;s all behaviour</description>
	<lastBuildDate>Wed, 08 Sep 2010 03:28:12 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: Sean DeNigris</title>
		<link>http://blog.dannorth.net/2006/10/28/outcomes-over-features-the-fifth-agile-value/#comment-7794</link>
		<dc:creator>Sean DeNigris</dc:creator>
		<pubDate>Tue, 31 Mar 2009 18:40:52 +0000</pubDate>
		<guid isPermaLink="false">http://dannorth.net/archives/32#comment-7794</guid>
		<description>The DDD/BDD combination is what got me back into coding.  Programming seemed very hit-or-miss before TDD came to town and developed to this point :)

I&#039;ve been using Boost.Test until I find/create a true BDD solution.

e.g.
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
//Specification source file
...
class steps {
public:
	// Givens
	void GivenIHaveNotCollectedAnyMoney() {}

	void GivenThereIsOneMemberInTheSystem(const std::string&amp; member_name) {
		member_repository_.removeAllMembers();
		member_repository_.addMember(member_name);
	}

	//Whens
	void WhenIStartTheApplication() {
		CoffeeFundCGIApp app(member_repository_, output_stream_);
	}

	//Thens
	void ThenIShouldSeeAMenuWithMember(const std::string&amp; member_name) {
		verifyHeader();
		HTMLExpert daveRagett(outputAsString().substr(25));
		BOOST_CHECK(daveRagett.doesOutputContainAMenuWithChoices(member_name));
	}
...
};

...

BOOST_FIXTURE_TEST_CASE( scenarioStartCollectingWithOneMember, steps )
{
	GivenThereIsOneMemberInTheSystem(&quot;DeNigris&quot;);
	WhenIStartTheApplication();
	ThenIShouldSeeAMenuWithMember(&quot;DeNigris&quot;);
}

///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
//CoffeeFundCGIApp specification file
...
BOOST_AUTO_TEST_CASE( shouldOutputMenuWithOneMember )
{
	MemberRepositoryForTesting member_repository;
	std::ostringstream output;
	CoffeeFundCGIApp app(member_repository, output);
	HTMLExpert daveRagett(output.str().substr(25));
	BOOST_CHECK(daveRagett.doesOutputContainAMenuWithChoices(member_repository.member_name));
}

As you can see, I&#039;ve noticed when implementing BDD, often my app controller tests and high-level features are almost duplicates of each other.  What is the point of having both, if any, unless you&#039;re mocking classes out?  Which I&#039;m not doing because the ostringstream is easier to use than to mock.</description>
		<content:encoded><![CDATA[<p>The DDD/BDD combination is what got me back into coding.  Programming seemed very hit-or-miss before TDD came to town and developed to this point :)</p>
<p>I&#8217;ve been using Boost.Test until I find/create a true BDD solution.</p>
<p>e.g.<br />
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////<br />
//Specification source file<br />
&#8230;<br />
class steps {<br />
public:<br />
	// Givens<br />
	void GivenIHaveNotCollectedAnyMoney() {}</p>
<p>	void GivenThereIsOneMemberInTheSystem(const std::string&amp; member_name) {<br />
		member_repository_.removeAllMembers();<br />
		member_repository_.addMember(member_name);<br />
	}</p>
<p>	//Whens<br />
	void WhenIStartTheApplication() {<br />
		CoffeeFundCGIApp app(member_repository_, output_stream_);<br />
	}</p>
<p>	//Thens<br />
	void ThenIShouldSeeAMenuWithMember(const std::string&amp; member_name) {<br />
		verifyHeader();<br />
		HTMLExpert daveRagett(outputAsString().substr(25));<br />
		BOOST_CHECK(daveRagett.doesOutputContainAMenuWithChoices(member_name));<br />
	}<br />
&#8230;<br />
};</p>
<p>&#8230;</p>
<p>BOOST_FIXTURE_TEST_CASE( scenarioStartCollectingWithOneMember, steps )<br />
{<br />
	GivenThereIsOneMemberInTheSystem(&#8220;DeNigris&#8221;);<br />
	WhenIStartTheApplication();<br />
	ThenIShouldSeeAMenuWithMember(&#8220;DeNigris&#8221;);<br />
}</p>
<p>///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////<br />
//CoffeeFundCGIApp specification file<br />
&#8230;<br />
BOOST_AUTO_TEST_CASE( shouldOutputMenuWithOneMember )<br />
{<br />
	MemberRepositoryForTesting member_repository;<br />
	std::ostringstream output;<br />
	CoffeeFundCGIApp app(member_repository, output);<br />
	HTMLExpert daveRagett(output.str().substr(25));<br />
	BOOST_CHECK(daveRagett.doesOutputContainAMenuWithChoices(member_repository.member_name));<br />
}</p>
<p>As you can see, I&#8217;ve noticed when implementing BDD, often my app controller tests and high-level features are almost duplicates of each other.  What is the point of having both, if any, unless you&#8217;re mocking classes out?  Which I&#8217;m not doing because the ostringstream is easier to use than to mock.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dan North</title>
		<link>http://blog.dannorth.net/2006/10/28/outcomes-over-features-the-fifth-agile-value/#comment-7793</link>
		<dc:creator>Dan North</dc:creator>
		<pubDate>Thu, 05 Mar 2009 13:58:44 +0000</pubDate>
		<guid isPermaLink="false">http://dannorth.net/archives/32#comment-7793</guid>
		<description>Hi Sean.

Thanks for your kind words. I took a look at your blog and I&#039;m really pleased you are looking at domain-driven design - it was a real awakening for me. The combination of a strong domain model and a focus on delivering value to stakeholders is unbeatable.

Let me know how you get on with this stuff in C++. I know the tool support isn&#039;t as strong for much of the process automation, although having said that, &lt;code&gt;make(1)&lt;/code&gt; has been around for about 25 years!</description>
		<content:encoded><![CDATA[<p>Hi Sean.</p>
<p>Thanks for your kind words. I took a look at your blog and I&#8217;m really pleased you are looking at domain-driven design &#8211; it was a real awakening for me. The combination of a strong domain model and a focus on delivering value to stakeholders is unbeatable.</p>
<p>Let me know how you get on with this stuff in C++. I know the tool support isn&#8217;t as strong for much of the process automation, although having said that, <code>make(1)</code> has been around for about 25 years!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Sean DeNigris</title>
		<link>http://blog.dannorth.net/2006/10/28/outcomes-over-features-the-fifth-agile-value/#comment-7792</link>
		<dc:creator>Sean DeNigris</dc:creator>
		<pubDate>Thu, 05 Mar 2009 02:27:38 +0000</pubDate>
		<guid isPermaLink="false">http://dannorth.net/archives/32#comment-7792</guid>
		<description>This is awesome!  I was was thinking the same thing (http://seandenigris.com/?p=63) and I stumbled upon your post.  There is a whole other level driving the behaviors.

- Sean

Thanks for the awesome work on BDD.  It really maximizes the benefits of TDD.</description>
		<content:encoded><![CDATA[<p>This is awesome!  I was was thinking the same thing (<a href="http://seandenigris.com/?p=63" rel="nofollow">http://seandenigris.com/?p=63</a>) and I stumbled upon your post.  There is a whole other level driving the behaviors.</p>
<p>- Sean</p>
<p>Thanks for the awesome work on BDD.  It really maximizes the benefits of TDD.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Stories and Capabilities :: iansrobinson.com</title>
		<link>http://blog.dannorth.net/2006/10/28/outcomes-over-features-the-fifth-agile-value/#comment-7791</link>
		<dc:creator>Stories and Capabilities :: iansrobinson.com</dc:creator>
		<pubDate>Tue, 28 Oct 2008 09:30:52 +0000</pubDate>
		<guid isPermaLink="false">http://dannorth.net/archives/32#comment-7791</guid>
		<description>[...] isn&#8217;t really news to the agile community, of course. Both Dan North and Martin Fowler have discussed the double-edged power of the user story, the benefits and dangers [...]</description>
		<content:encoded><![CDATA[<p>[...] isn&#8217;t really news to the agile community, of course. Both Dan North and Martin Fowler have discussed the double-edged power of the user story, the benefits and dangers [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Product Testing</title>
		<link>http://blog.dannorth.net/2006/10/28/outcomes-over-features-the-fifth-agile-value/#comment-7790</link>
		<dc:creator>Product Testing</dc:creator>
		<pubDate>Mon, 04 Feb 2008 04:59:57 +0000</pubDate>
		<guid isPermaLink="false">http://dannorth.net/archives/32#comment-7790</guid>
		<description>Role of QA and Testing in Software Product Development...

With the ever-shortening software release cycles, assuring the quality of codes, while managing the cost and risks involved, is a major challenge faced by a majority of software development enterprises nowadays. With project life cycles decreasing even...</description>
		<content:encoded><![CDATA[<p>Role of QA and Testing in Software Product Development&#8230;</p>
<p>With the ever-shortening software release cycles, assuring the quality of codes, while managing the cost and risks involved, is a major challenge faced by a majority of software development enterprises nowadays. With project life cycles decreasing even&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Manifesto for Agile Software Development (Agile Manifesto) &#171; PROJEKTMANAGEMENT BLOG</title>
		<link>http://blog.dannorth.net/2006/10/28/outcomes-over-features-the-fifth-agile-value/#comment-7789</link>
		<dc:creator>Manifesto for Agile Software Development (Agile Manifesto) &#171; PROJEKTMANAGEMENT BLOG</dc:creator>
		<pubDate>Tue, 16 Oct 2007 18:24:44 +0000</pubDate>
		<guid isPermaLink="false">http://dannorth.net/archives/32#comment-7789</guid>
		<description>[...] Outcomes over Features - the fifth agile value? [...]</description>
		<content:encoded><![CDATA[<p>[...] Outcomes over Features &#8211; the fifth agile value? [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ryan Hoegg</title>
		<link>http://blog.dannorth.net/2006/10/28/outcomes-over-features-the-fifth-agile-value/#comment-7788</link>
		<dc:creator>Ryan Hoegg</dc:creator>
		<pubDate>Wed, 21 Feb 2007 21:26:06 +0000</pubDate>
		<guid isPermaLink="false">http://dannorth.net/archives/32#comment-7788</guid>
		<description>Good insight, but I think this is really a corollary of &quot;customer collaboration over contract negotiation&quot;.  If the product owner is resisting changes to the release plan based on new information, perhaps he views the release plan as a contract you&#039;ve committed to.</description>
		<content:encoded><![CDATA[<p>Good insight, but I think this is really a corollary of &#8220;customer collaboration over contract negotiation&#8221;.  If the product owner is resisting changes to the release plan based on new information, perhaps he views the release plan as a contract you&#8217;ve committed to.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ryan Hoegg</title>
		<link>http://blog.dannorth.net/2006/10/28/outcomes-over-features-the-fifth-agile-value/#comment-7787</link>
		<dc:creator>Ryan Hoegg</dc:creator>
		<pubDate>Wed, 21 Feb 2007 21:22:29 +0000</pubDate>
		<guid isPermaLink="false">http://dannorth.net/archives/32#comment-7787</guid>
		<description>Good insight, but I think this is really a corollary of &quot;Customer collaboration over contract negotiation&quot;.  Perhaps the commitment to a list of features is really a symptom of the product owner&#039;s unspoken assumption that the release plan is a contract?</description>
		<content:encoded><![CDATA[<p>Good insight, but I think this is really a corollary of &#8220;Customer collaboration over contract negotiation&#8221;.  Perhaps the commitment to a list of features is really a symptom of the product owner&#8217;s unspoken assumption that the release plan is a contract?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Community Blogs</title>
		<link>http://blog.dannorth.net/2006/10/28/outcomes-over-features-the-fifth-agile-value/#comment-7786</link>
		<dc:creator>Community Blogs</dc:creator>
		<pubDate>Sun, 21 Jan 2007 17:30:28 +0000</pubDate>
		<guid isPermaLink="false">http://dannorth.net/archives/32#comment-7786</guid>
		<description>Software Architecture Workshop in Arosa: back to reality...

Last week I had the privilege to spend 5 days in Arosa, Switzerland, among a group of people who were...</description>
		<content:encoded><![CDATA[<p>Software Architecture Workshop in Arosa: back to reality&#8230;</p>
<p>Last week I had the privilege to spend 5 days in Arosa, Switzerland, among a group of people who were&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: FeatureDevotion at Le Duc McNamara Family</title>
		<link>http://blog.dannorth.net/2006/10/28/outcomes-over-features-the-fifth-agile-value/#comment-7785</link>
		<dc:creator>FeatureDevotion at Le Duc McNamara Family</dc:creator>
		<pubDate>Sat, 06 Jan 2007 19:10:59 +0000</pubDate>
		<guid isPermaLink="false">http://dannorth.net/archives/32#comment-7785</guid>
		<description>[...] The problem comes when this list suddenly grows horns and fangs and becomes a Fixed-Price Fixed-Scope Big Up-Front Project Plan. Craig Larman once joked that the waterfall process has strong antibodies that reject iterative processes by warping them into some form of waterfall. RUP has been a common victim of these antibodies, seeing its phases turn into some variant of the analysis-design-build-test conveyor. [...]</description>
		<content:encoded><![CDATA[<p>[...] The problem comes when this list suddenly grows horns and fangs and becomes a Fixed-Price Fixed-Scope Big Up-Front Project Plan. Craig Larman once joked that the waterfall process has strong antibodies that reject iterative processes by warping them into some form of waterfall. RUP has been a common victim of these antibodies, seeing its phases turn into some variant of the analysis-design-build-test conveyor. [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>
