Print

Oh no! Bugs are still on the loose!



David Rubinstein
Email
January 30, 2013 —  (Page 3 of 4)

BEST PRACTICE #3: PRIORITIZE, AND USE YOUR TIME WISELY
If everything is a Priority-1 defect, then nothing is a Priority-1 defect, said Alexsys’ Bianchi. “You have to effectively prioritize,” he said.

The definition of an acceptable level of defects will vary between organizations, or even from product to product, according to TechExcel senior product manager Vineet Agarwal. “Some organization might decide that there can be no user-visible bugs in the product. Others might say only a Priority 2 or 3 is allowed in a release.”

These kinds of priorities help organizations get the most out of their engineering resources.

Atlassian’s Nolen said his engineering teams only have two versions of the software in development at any given time: trunk and stable. “The way we do versioning is, let’s say you’ve got project version 3.4.0. From that moment on, your 3.4 branch, that is your stable branch. You’ll do .0, .1, .2, .3... While that’s going on, your trunk, which is 3.5, or 4.0, that’s in development internally and usually customers are not seeing that at this point, and so you split you efforts between bug fixes and maintenance on [the stable branche]. Usually, we spend like 15 or 20% of total engineering effort in that bucket,  sometimes a little less. And then trunk—your 3.5 or 4.0—is on a three- to four-month delivery cycle, and that’s where the majority of your effort is going. What that means is, anything prior to your 3.4 version is essentially frozen.

“We don’t do fixes, we don’t do special one-offs, we don’t do branches per customer, we don’t do custom anything,” he added. “The only time we ever go back further than that four months is in the case of critical security fixes. We will issue patches for those. But we don’t do any traditional bug fix or any maintenance. That basically means our engineering efforts are not split or divided across multiple current versions of the software, and we don’t have to do each fix six or 12 or 18 times as I’ve seen other companies sometimes do. It gets especially bad when you end up branching with custom features per customer or per even slice of customer. It’s something I would highly encourage for people to draw a line in the sand and not do that.”  

Bianchi said he’s a big fan of doing high-level build plans to begin with: Lay out what you want to produce, and let the engineers work from that.

“Make it as clear as possible,” he said. “People want to know one thing: What am I supposed to work on today?” But, you have to remain flexible as well. “For every 20 planned tasks you have, you’ll have 50-100 other things—mostly bugs—and you have to track them,” he said.


Related Search Term(s): agile, software quality

Pages 1 2 3 4 


Share this link: http://sdt.bz/37336
 

close
NEXT ARTICLE
Agile: The team game
Experts explain how organizations can transition development teams to agile, best practices to follow, and what to watch for Read More...
 
 
 




News on Monday  more>>
Android Developer News  more>>
SharePoint Tech Report  more>>
Big Data TechReport  more>>

   
 
 

 


Download Current Issue
APRIL 2014 PDF ISSUE

Need Back Issues?
DOWNLOAD HERE

Want to subscribe?