Great write up I just noticed on quality & other related improvements: http://robhirschfeld.com/2010/12/22/black-hat/
-Adron On Wed, Dec 22, 2010 at 5:57 PM, Erick Thompson <[email protected]>wrote: > I think I wasn't completely clear. I wasn't making any statement about what > I work on (but to be honest, I have never worked on a project with 100% > whitebox coverage), but a suggestion for something to do post iteration. > > There may be projects that don't have time pressure and have enough > resources to have full test coverage (TDD with all edge cases covered, > integration, manual, whitebox, etc) for every iteration. If you work on such > a project, good on you. > > But if you've ever had a bug, you don't live in that world. There is always > a way to improve something. My read of the question was about suggestions on > areas to revisit post iteration. > > Erick > > > Sent from my iPhone > > On Dec 22, 2010, at 5:24 PM, Eric Ridgeway <[email protected]> wrote: > > 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]> > [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]> > [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]>[email protected][mailto:<[email protected]> > [email protected]] > >> On Behalf Of Erick Thompson > >> Sent: Wednesday, December 22, 2010 3:26 PM > >> To: <[email protected]>[email protected] > >> Cc: <[email protected]>[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]> > [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]> > [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] > >> [<[email protected]> > [email protected]] on > >> behalf of Anne Wax [ <[email protected]>[email protected]] > >> Sent: Wednesday, December 22, 2010 7:39 AM > >> To: <[email protected]>[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.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> > 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]> > [email protected]. > >> To unsubscribe from this group, send email to > >> <altnetseattle%[email protected]> > [email protected]. > >> For more options, visit this group at > >> <http://groups.google.com/group/altnetseattle?hl=en> > 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]> > [email protected]. > >> To unsubscribe from this group, send email to > >> <altnetseattle%[email protected]> > [email protected]. > >> For more options, visit this group at > >> <http://groups.google.com/group/altnetseattle?hl=en> > 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]> > [email protected]. > >> To unsubscribe from this group, send email to > >> <altnetseattle%[email protected]> > [email protected]. > >> For more options, visit this group at > >> <http://groups.google.com/group/altnetseattle?hl=en> > 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]> > [email protected]. > >> To unsubscribe from this group, send email to > >> <altnetseattle%[email protected]> > [email protected]. > >> For more options, visit this group at > >> <http://groups.google.com/group/altnetseattle?hl=en> > 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]> > [email protected]. > >> To unsubscribe from this group, send email to > >> <altnetseattle%[email protected]> > [email protected]. > >> For more options, visit this group at > >> <http://groups.google.com/group/altnetseattle?hl=en> > 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]> > [email protected]. > > To unsubscribe from this group, send email to > <altnetseattle%[email protected]> > [email protected]. > > For more options, visit this group at > <http://groups.google.com/group/altnetseattle?hl=en> > 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. > > -- > 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. > -- *Adron B Hall* *Tech*: http://compositecode.com *Transit*: http://transitsleuth.com *Twitter*: http://www.twitter.com/adronbh -- 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.
