Re: Incremental and Iterative Development
- --- In firstname.lastname@example.org, "Megan Brown" <mbrown@...> wrote:
>Iteration: A measure of *time*, in which a full development cycle is
> Better Software Magazine: April 2008 Feature Article
> By Alistair Cockburn
> People still get wrapped around the axle trying to understand the
> difference between incremental and iterative development.
executed to deliver a high-value feature to the product owner.
Increment: A measure of *functionality*. Baseline + Increment = New
> The UnifiedI'm not following you. Yes, you can certainly iterate without
> Process authors in the 1990s didn't help by indiscriminately calling
> everything iterative development. The two are different and must be
> managed differently. Successful teams do both at the same time, usually
> without thinking about it. Then someone starts thinking about it and
> does one without the other. Bad news follows.
producing an increment of software. Many organizations that adopt RUP
often fall into this trap. They "iterate" once to produce a
requirements document, and the "iterate" again to produce a design
document, etc. In a nutshell, they jam waterfall into an iterative model.
However, they're not really iterating, if you accept the definition of
an iteration as a pass through the full development cycle.
>Really??? Isn't the whole point of an iteration/sprint to build an
> Current agile practice doesn't seem to make it important that the users
> get to see what's being built and have a chance to change it.
increment of working software that incorporates the product owner's
highest priority features, and allow the user to evaluate the software
in order to adjust the product backlog with additional features or
> lengths are so short that the programmers barely have time to program upI'm not following you. The iteration length is selected to allow the
> the basics before the end of the iteration, so there's no time for the
> users to show up and say, "No, that's not actually what I want."
team enough time to produce running software. The product owner gets
to see the working software at the end of the iteration. The product
owner is generally not allowed to change the contents of the sprint,
but they certainly can be available to the team for feedback. In the
worst case, the product owner will evaluate the software at the end of
the iteration, and incorporate any changes into the product backlog.
What's the beef?
> Read More: http://www.stickyminds.com/BSM103