• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Incremental Design and Agile

 
Ranch Hand
Posts: 312
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi there,

In my current project there was a unanimous decision to follow agile methodology. This is the first time we are going Agile so may be we have not followed it strictly.
The question I have is about the Agile principle "Incremental Design". We had a release which was scheduled to complete in 1 year time-frame. We divided this major release into four sub releases ( 1 per quarter). We did not spend too much time in the architecture and design phase upfront as we thought of doing it the Agile way (evolving the design as we move along i.e. sub release wise).
With this approach what we saw is as the design started changing in subsequent minor releases this kind of impacted the already delivered prior sub releases. Every sub release was integrated and had considerable QA effort involved. This whole effort kind of went into the drain as the design changed in the subsequent sub release and these changes derailed what was already delivered in previous sub releases. We had to kind of rework and redo a lot of stuff. I think we have missed something here.

Could someone post their comments on the above and enlighten about proper approach towards "Incremental Design".

Regards,
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It certainly sounds like you missed or misunderstood something...

Can you tell us more about the impact on the earlier sub releases?

Where did that "considerable QA effort" come from?

Did you practice continuous integration? Automated acceptance and unit testing?
 
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Did you have iterations within the release cycle? Or were your releases your iterations?
 
manish ahuja
Ranch Hand
Posts: 312
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi there,

Yes we did have continuous integration of our unit tests.
This worked very well but that is not my question here.

I am actually trying to understand how people go about incorporating
incremental design.

To reiterate we had divided our major release into 4 sub-releases.
The design changes of our subsequent sub-releases
was impacting the functioning of our prior sub-releases.
Due to these design changes in our subsequent releases we had to revisit the previous releases.
To answer Eric's question yes we had iterations within the release cycle
so we had allocated time for system integration testing as well as QA testing for each sub-release.

Things overall worked well but this was one of the important lesson learned
and we would want to gather facts so we can avoid such hurdles in our future projects.

Thanks,
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Incremental design evolution always entails the risk of rework.

The whole point is that this risk, which often realizes in some extent, is worth taking because you learn so much about the problem, solution and context along the way.

The significant testing effort you mention is the biggest reason for test automation being so frequent topic of discussion in the context of agile methods. You need automation to make your pace of development sustainable and not get bogged down by the continuously increasing effort needed for regression testing.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm still not totally clear on what you did, but it sounds to me like you didn't take continuous integration as far as I you probably "should" have. In my experience, system integration testing should be done at least once a day (for example on a nightly build), on the fully integrated system - that is, on the functionality of the current sub release, *plus* all prior sub releases.
 
First, you drop a couch from the plane, THEN you surf it. Here, take this tiny ad with you:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic