Haven't read any of the responses completely but if you are not including quality as part of the definition of done.... then that's not very agile of you ... not sure about your shop but we care about quality all the time ... and we try to be better every day . On Dec 22, 2010 5:06 PM, "Erick Thompson" <[email protected]> wrote: > Agreed, it is good to have end-to-end tests to define something as > "done". My thought was that these tests are often a low priority and > become technical debt. Seems like a good task for post iteration - > someone else mentioned technical debt as well. I wish I didn't ever > have any technical debt, but such a project hasn't come my way. :) > > Erick > > On Wed, Dec 22, 2010 at 3:48 PM, Ade Miller <[email protected]> wrote: >> Hi Erick, >> >> >> >> You can run some end to end integration tests as part of CI. You might want >> to automatically deploy your product to a test environment as part of this >> process. You may still require additional testing; automated or manual, but >> the implication is I can always build my product and have a clear idea of >> what’s “done”. This means that I can start testing while I’m still working >> on other features during the iteration. There is very little waiting until >> the end to see if it all works. >> >> >> >> I’m not saying there aren’t going to be exceptions to this rule. There are >> some things my teams leave “until the end” but in general anything you leave >> off your “done” list to the end is an unknown so represents risk. >> >> >> >> Ad >> >> >> >> >> >> From: [email protected] [mailto: [email protected]] >> On Behalf Of Erick Thompson >> Sent: Wednesday, December 22, 2010 3:26 PM >> To: [email protected] >> Cc: [email protected] >> Subject: Re: After the Code is Done - Strategies to Ensure Quality >> >> >> >> What about integration testing? TDD and CI help for building solid code, but >> there is also a need to test everything together. Perhaps it is UI whitebox >> testing, or some other style if tests that don't tend to get developed in >> the normal course of an iteration. >> >> >> >> Erick >> >> Sent from my iPhone >> >> On Dec 22, 2010, at 1:11 PM, Anne Wax <[email protected]> wrote: >> >> 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]<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]<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.
