<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="http://blogs.msdn.com/utility/FeedStylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>Project Life Cycles at patterns &amp;amp; practices</title><link>http://blogs.msdn.com/jmeier/archive/2008/08/03/project-life-cycles-at-patterns-practices.aspx</link><description>Periodically I like to revisit our project life cycle in patterns &amp;amp; practices. I like to see how it's shape-shifted over the years. (Note - our project life cycle wraps our product cycle) patterns &amp;amp; practices Project Life Cycle Circa 2005 Here's</description><dc:language>en-US</dc:language><generator>CommunityServer 2.1 SP1 (Build: 61025.2)</generator><item><title>re: Project Life Cycles at patterns &amp; practices</title><link>http://blogs.msdn.com/jmeier/archive/2008/08/03/project-life-cycles-at-patterns-practices.aspx#8832013</link><pubDate>Mon, 04 Aug 2008 22:54:05 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:8832013</guid><dc:creator>Kash Baghaei</dc:creator><description>&lt;p&gt;Thanks for another great post,&lt;/p&gt;
&lt;p&gt;You mentioned that you projec needed more agility! What do you think of iterative design? It seemed that all of your team's design was done before impl. started ... I have to add that iterative design causes scope changes constantly and senior managers in my company don't like that ... too much agility! The stages and phases that you described very well would match the requirements needed to manage my manager's expectations, though:)&lt;/p&gt;
</description></item><item><title>re: Project Life Cycles at patterns &amp; practices</title><link>http://blogs.msdn.com/jmeier/archive/2008/08/03/project-life-cycles-at-patterns-practices.aspx#8834294</link><pubDate>Tue, 05 Aug 2008 18:41:37 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:8834294</guid><dc:creator>J.D. Meier</dc:creator><description>&lt;p&gt;Thanks Kash. &amp;nbsp;&lt;/p&gt;
&lt;p&gt;I'm a fan of iterative development for the right scenarios. &amp;nbsp;It's great for when you haven't done exactly the same thing before -- since you don't know what you don't know and you need to be flexible.&lt;/p&gt;
&lt;p&gt;I've seen the most effective iterative development continuously deliver incremental value and keep the customers involved so there's less surprises. &amp;nbsp;The way to constrain risk for these projects is to fix time and budget, but flex scope.&lt;/p&gt;
&lt;p&gt;I can understand the concern around constant scope changes. &amp;nbsp;A few things help:&lt;/p&gt;
&lt;p&gt;1. have a vision up front -- if there's too much shape-shifting there may be a lack of vision&lt;/p&gt;
&lt;p&gt;2. know the key &amp;quot;tests for success&amp;quot;&lt;/p&gt;
&lt;p&gt;3. tune and adjust review cycles so that you can separate the forest from the trees (if you review too frequently, it can be easy to lose the macro view)&lt;/p&gt;
&lt;p&gt;If you really need to fix scope, then what I often see is the schedule has to be very flexible and there's often surprises when the scope delivered doesn't match expectations (because people are human and requirements are a tough space -- particularly around user experience)&lt;/p&gt;
&lt;p&gt;Keep in mind the figure is circa 2005, but to clarify, the &amp;quot;candidate&amp;quot; design was done before implementation, and shape-shifted as necessary throughout the project. &amp;nbsp;Also, while the project cycle was less iterative, the product cycle was more iterative and incremental.&lt;/p&gt;
&lt;p&gt;Also, check a relevant post on my ShapingSoftware blog - &lt;a rel="nofollow" target="_new" href="http://shapingsoftware.com/2008/06/23/evolutionary-incremental-and-high-risk/"&gt;http://shapingsoftware.com/2008/06/23/evolutionary-incremental-and-high-risk/&lt;/a&gt;&lt;/p&gt;
</description></item></channel></rss>