Hi all and thank you. There's lots to think about here, and I will reread later tonight.
I wanted to answer some of your questions and key points. By end of an iteration I meant end of a sprint, the end of finishing a set of features to address a business need that takes longer than one sprint, and at the point when a version of the software is released for Production use (vs for testing/pilot use). We'll see if these designations open up a whole new can of worms regarding what is 'agile' or not 'agile'. re: the real world and ideal - it is not about giving up, but rather having processes that build in the ideal (refactor as you go) and recognize that sometimes you have to deliver, and then finish. For example, on a larger project you might have multiple sprints to build a significant piece of functionality, but then as you are finishing, you think of a better way to do it. The schedule does not allow the immeidate refactoring, but it is needed. Or what about when the installation or training documentation is hard to write as you go until the product has been developed. I am coming from the perspective of a large enterprise system used by over 20 customers with set delivery schedules/dates. Yet we are using many agile tools such as scrum, daily builds, teams of testers and developers working together on each sprint, unit and web testing, refactoring, etc. And we are trying to do a better job all the time. Thanks for all your input. I enjoy these discussions and am often watching the conversations. Anne On Wed, Dec 22, 2010 at 7:52 AM, Ade Miller <[email protected]>wrote: > Hum... > > > > So the title of your message concerns me. Don't think in terms of codeing > and testing, think engineering. Ensuring quality at the end is doomed to > failure. > > > > Assure functional quality *during *development. For example: > > - TDD or unit testing tend to get rid of lots of defects before they > are even committed to the codebase. > - Continuous integration ensures that your product builds as a whole > throughout development. > - Having a clear definition of "done" means that acceptance testing can > start on finished stories during the iteration. > - An iteration/sprint should be long enough to engineer (build *and*test) > a useful peice of functionality. > *Not* coding sprints followed by test sprints. > > All this adds up to not having a lot of quality debt at the end of an > iteration. > > > > Specifically on the what do you do at then end of an iteration. Typically > the team gets together and asks; "What went well?", "What went not so well?" > and "What things could we try and improve next iteration?" These may be > related to the quality of the product but might equally concern any other > aspect of building software. The team picks a couple of the top things they > think they could improve and works on them during the next iteration, over > time these small improvements add up. This is reflection-adaption but it > applies to all aspects of what you do not just product quality. > > > > Thanks, > > > Ade > > > ------------------------------ > *From:* [email protected] [[email protected]] on > behalf of Anne Wax [[email protected]] > *Sent:* Wednesday, December 22, 2010 7:39 AM > *To:* [email protected] > > *Subject:* After the Code is Done - Strategies to Ensure Quality > > What do you do at the end of a sprint or a release cycle to ensure > quality? > > We've seen some blogs that talk about stop-reflect-adapt and > review-reflect-repeat. What do you all do when you have completed an > interation or a release cycle to ensure your product's excellence? Do you > step back to review and improve before moving on to the next cycle or > project? > > What happens in "real life" and what is the ideal? > > Thank you, > > Anne > > > > > http://www.agileweboperations.com/stop-reflect-adapt-the-3-steps-to-stop-writing-bad-code > > > > > http://www.agilejournal.com/blogs/blogs/all-about-agile/704-how-to-implement-scrum-in-10-easy-steps-step-10-review-reflect-repeat > > -- > You received this message because you are subscribed to the Google Groups > "Seattle area Alt.Net" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<altnetseattle%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/altnetseattle?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Seattle area Alt.Net" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<altnetseattle%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/altnetseattle?hl=en. > -- You received this message because you are subscribed to the Google Groups "Seattle area Alt.Net" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/altnetseattle?hl=en.
