<?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: Long live the Waterfall</title>
	<atom:link href="http://thetesteye.com/blog/2009/06/long-live-the-waterfall/feed/" rel="self" type="application/rss+xml" />
	<link>http://thetesteye.com/blog/2009/06/long-live-the-waterfall/</link>
	<description>by rikard edgren, henrik emilsson and martin jansson - with torbjörn ryber and henrik andersson</description>
	<lastBuildDate>Thu, 17 May 2012 16:53:59 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Martin Jansson</title>
		<link>http://thetesteye.com/blog/2009/06/long-live-the-waterfall/comment-page-1/#comment-158</link>
		<dc:creator>Martin Jansson</dc:creator>
		<pubDate>Wed, 29 Jul 2009 22:09:18 +0000</pubDate>
		<guid isPermaLink="false">http://thetesteye.com/blog/?p=302#comment-158</guid>
		<description>&quot;I’m interested in if Agile is particularly hard to use as a tester&quot;. If Agile means getting builds more often and earlier, thus being able to spend more time testing than waiting for testing, it is easier to use.

One down side with Agile is that project members tend to cut down on describing what they build and what they plan. Things are more flexible and it often means that testers has to do more guessing. Naturally specifications are not the salvation to everything, but my experience so far is that you get less information in general.

Whatever you wish to call the project model I think that working incrementally, not describing the whole system from start, is a good thing for all actors in the project.</description>
		<content:encoded><![CDATA[<p>&#8220;I’m interested in if Agile is particularly hard to use as a tester&#8221;. If Agile means getting builds more often and earlier, thus being able to spend more time testing than waiting for testing, it is easier to use.</p>
<p>One down side with Agile is that project members tend to cut down on describing what they build and what they plan. Things are more flexible and it often means that testers has to do more guessing. Naturally specifications are not the salvation to everything, but my experience so far is that you get less information in general.</p>
<p>Whatever you wish to call the project model I think that working incrementally, not describing the whole system from start, is a good thing for all actors in the project.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rikard Edgren</title>
		<link>http://thetesteye.com/blog/2009/06/long-live-the-waterfall/comment-page-1/#comment-157</link>
		<dc:creator>Rikard Edgren</dc:creator>
		<pubDate>Wed, 29 Jul 2009 19:45:02 +0000</pubDate>
		<guid isPermaLink="false">http://thetesteye.com/blog/?p=302#comment-157</guid>
		<description>I have never worked in a truly Agile project, but I&#039;m pretty sure that the actual work as a tester (providing important information about the application) isn&#039;t easier or harder because of the process (the people and the product are more important.)
However, there are many ancient ideas and expectations about testing that are difficult to fulfill.
In Agile it is probably more difficult to answer questions like:
* How many testing resources are needed for each period of time?
* How many tests will you run?
* When will testing be done?

On the other hand, for most projects it is possible to assign a reasonable number of test resources, and then do your very best.</description>
		<content:encoded><![CDATA[<p>I have never worked in a truly Agile project, but I&#8217;m pretty sure that the actual work as a tester (providing important information about the application) isn&#8217;t easier or harder because of the process (the people and the product are more important.)<br />
However, there are many ancient ideas and expectations about testing that are difficult to fulfill.<br />
In Agile it is probably more difficult to answer questions like:<br />
* How many testing resources are needed for each period of time?<br />
* How many tests will you run?<br />
* When will testing be done?</p>
<p>On the other hand, for most projects it is possible to assign a reasonable number of test resources, and then do your very best.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ola Janson</title>
		<link>http://thetesteye.com/blog/2009/06/long-live-the-waterfall/comment-page-1/#comment-156</link>
		<dc:creator>Ola Janson</dc:creator>
		<pubDate>Wed, 29 Jul 2009 18:48:19 +0000</pubDate>
		<guid isPermaLink="false">http://thetesteye.com/blog/?p=302#comment-156</guid>
		<description>I know that Agile is not flawless and its also very hard to speak of all practices (xp,scrum, agile, lean etc) as one &quot;hype&quot;. Waterfall is very good for predictable project (made by engineers and architects). From my perspective game design benefits very much from something else than waterfall (i.e scrum).
I&#039;m interested in if Agile is particularly hard to use as a tester. What is your opinion on that?</description>
		<content:encoded><![CDATA[<p>I know that Agile is not flawless and its also very hard to speak of all practices (xp,scrum, agile, lean etc) as one &#8220;hype&#8221;. Waterfall is very good for predictable project (made by engineers and architects). From my perspective game design benefits very much from something else than waterfall (i.e scrum).<br />
I&#8217;m interested in if Agile is particularly hard to use as a tester. What is your opinion on that?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Martin Jansson</title>
		<link>http://thetesteye.com/blog/2009/06/long-live-the-waterfall/comment-page-1/#comment-155</link>
		<dc:creator>Martin Jansson</dc:creator>
		<pubDate>Wed, 29 Jul 2009 16:25:45 +0000</pubDate>
		<guid isPermaLink="false">http://thetesteye.com/blog/?p=302#comment-155</guid>
		<description>Welcome Ola!

Agile is just a hype, just like the internet. We know that noone really use it, they just &quot;say&quot; they do.

PS.
This was a ironic article, perhaps not all too obvious. Still, I used the famous Irony-tag.

All three of us got lots of experience with different kinds of project models. Is there anything in particular you is interested in?
DS.</description>
		<content:encoded><![CDATA[<p>Welcome Ola!</p>
<p>Agile is just a hype, just like the internet. We know that noone really use it, they just &#8220;say&#8221; they do.</p>
<p>PS.<br />
This was a ironic article, perhaps not all too obvious. Still, I used the famous Irony-tag.</p>
<p>All three of us got lots of experience with different kinds of project models. Is there anything in particular you is interested in?<br />
DS.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ola Janson</title>
		<link>http://thetesteye.com/blog/2009/06/long-live-the-waterfall/comment-page-1/#comment-154</link>
		<dc:creator>Ola Janson</dc:creator>
		<pubDate>Wed, 29 Jul 2009 09:05:17 +0000</pubDate>
		<guid isPermaLink="false">http://thetesteye.com/blog/?p=302#comment-154</guid>
		<description>Intresting blog brother. I have couple of questions:
What is your (all three of you) experience of Agile?
Why is agile bad? 
Why is Agile a hype ? Is it because it works or because every one is fooled by the dark side? ;)</description>
		<content:encoded><![CDATA[<p>Intresting blog brother. I have couple of questions:<br />
What is your (all three of you) experience of Agile?<br />
Why is agile bad?<br />
Why is Agile a hype ? Is it because it works or because every one is fooled by the dark side? <img src='http://thetesteye.com/blog/wp-includes/images/smilies/icon_wink.gif' alt=';)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rikard Edgren</title>
		<link>http://thetesteye.com/blog/2009/06/long-live-the-waterfall/comment-page-1/#comment-136</link>
		<dc:creator>Rikard Edgren</dc:creator>
		<pubDate>Tue, 16 Jun 2009 16:07:55 +0000</pubDate>
		<guid isPermaLink="false">http://thetesteye.com/blog/?p=302#comment-136</guid>
		<description>I have made some calculations with Grubb&#039;s method, and for a conference like this, with the specified objectives, taking 6 Standard Deviations into account, the delay will probably mean that the conference take place early next year!
Should we book some group tickets?</description>
		<content:encoded><![CDATA[<p>I have made some calculations with Grubb&#8217;s method, and for a conference like this, with the specified objectives, taking 6 Standard Deviations into account, the delay will probably mean that the conference take place early next year!<br />
Should we book some group tickets?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Henrik Emilsson</title>
		<link>http://thetesteye.com/blog/2009/06/long-live-the-waterfall/comment-page-1/#comment-134</link>
		<dc:creator>Henrik Emilsson</dc:creator>
		<pubDate>Tue, 16 Jun 2009 11:17:23 +0000</pubDate>
		<guid isPermaLink="false">http://thetesteye.com/blog/?p=302#comment-134</guid>
		<description>I would have loved to see the keynote by Brian Marick:
&quot;Put Testing Where It Belongs--At the End&quot;
http://www.waterfall2006.com/marick.html</description>
		<content:encoded><![CDATA[<p>I would have loved to see the keynote by Brian Marick:<br />
&#8220;Put Testing Where It Belongs&#8211;At the End&#8221;<br />
<a href="http://www.waterfall2006.com/marick.html" rel="nofollow">http://www.waterfall2006.com/marick.html</a></p>
]]></content:encoded>
	</item>
</channel>
</rss>

