(Page 3 of 4)
BEST PRACTICE #3: PRIORITIZE, AND USE YOUR TIME WISELYIf 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.