the release cycle

1 May 2008 - 12:52pm
6 years ago
2 replies
337 reads
Loredana
2008

Hi everyone,

This question is a little outside the scope of IxD but is closely
related to one of our goals: getting our work in front of real people.

What I'm interested to know is - in the web world, how do your
companies approach new releases?
How much time is spent on QA, and how often do you release improved
versions of your product - be it fixes, or new features?
What's your release criteria?

I know this tends to be different for different types of companies...
but would love to hear what works for you.

Loredana

Comments

1 May 2008 - 2:24pm
Ari
2006

we're on a 2 week release cycle - with alternating "hot" and "cold"
releases. hot releases are for complex new features or enhancements. cold
releases are for minor features or enhancements. bug fixes occur regardless
of release.

QA occurs in parallel with the release cycle. issues are tracked and
literally tested individually and closed out or kicked back to developers
according to FIFO priority. issues that touch many areas or need lots of
testing are tackled first. we, of course, have separate dev, stage and
production environments with sandboxes to prevent hosing anything important
and items are promoted to different environments only after they are
verified to work.

our particular product and business changes constantly so we release a new
product version every 2 weeks. some releases are more dramatic than others.

the release criteria is determined on business need - most of them i
prioritize and personally define. we keep a running log of all possible
features and dole out a certain amount each release based on their relative
necessity and difficulty to implement - usually 30-40 and leave room for
bugs. items closed range from 54-90 per release and can be anything from
fixing typos to building major admin tools.

i plan everything for the next release, including detailed functional specs
usually 1-2 weeks prior of the item's projected release. this way, i'm on
schedule, if not ahead with funneling items to our dev team.

has it worked? for the most part yes. we've done 21 releases this way
(though hot and cold are relatively new) and we've missed the release
schedule only twice.

On Thu, May 1, 2008 at 1:52 PM, Loredana Crisan <loredana at lexy.com> wrote:

> Hi everyone,
>
> This question is a little outside the scope of IxD but is closely
> related to one of our goals: getting our work in front of real people.
>
> What I'm interested to know is - in the web world, how do your
> companies approach new releases?
> How much time is spent on QA, and how often do you release improved
> versions of your product - be it fixes, or new features?
> What's your release criteria?
>
> I know this tends to be different for different types of companies...
> but would love to hear what works for you.
>
> Loredana
>
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

--
--------------------------------------------------
www.flyingyogi.com
--------------------------------------------------

1 May 2008 - 2:41pm
Loredana
2008

Hi Dave,

We're building a cross-platform application that allows you to build
a smart podcast playlist (self-updating) and listen to it either on
our site, or over the voice channel of your mobile phone.
We build in weekly iterations, but find that even very small fixes,
such as changes the size of our podcast thumbnails get pushed off for
weeks because of a rigid QA release cycle.

What we're building is pretty new - to us and the public - so we need
to be able to respond really fast to feedback from our users.
Unfortunately right now we can't, and bug fixes get mixed up with new
features, creating this "soup" of releasable items in QA land.

I've seen other start-up companies build things and release them the
same day... so I wonder where the best (or just better) solution lies.

Loredana

On May 1, 2008, at 12:14 PM, Dave Meeker wrote:

> loredana,
>
> That's an interesting question. I think the answer is much harder than
> you'd think. It really depends on the approach a team takes towards a
> project, what the client goals are in terms of "getting to market",
> and what the specific project entails. I see a lot of teams working in
> a very iterative manner these days.... and doing so removes the
> waterfall/linear "design -->develop-->test-->deploy" process,
> replacing it for something that is more circular, requiring
> involvement of all parties throughout the project.
>
> If you could give the list more info on what type of thing you are
> building, it might be helpful and allow folks to give you a better
> response.
>
>
>
> On Thu, May 1, 2008 at 12:52 PM, Loredana Crisan
> <loredana at lexy.com> wrote:
>> Hi everyone,
>>
>> This question is a little outside the scope of IxD but is closely
>> related to one of our goals: getting our work in front of real
>> people.
>>
>> What I'm interested to know is - in the web world, how do your
>> companies approach new releases?
>> How much time is spent on QA, and how often do you release improved
>> versions of your product - be it fixes, or new features?
>> What's your release criteria?
>>
>> I know this tends to be different for different types of
>> companies...
>> but would love to hear what works for you.
>>
>> Loredana
>>
>>
>>
>> ________________________________________________________________
>> Welcome to the Interaction Design Association (IxDA)!
>> To post to this list ....... discuss at ixda.org
>> Unsubscribe ................ http://www.ixda.org/unsubscribe
>> List Guidelines ............ http://www.ixda.org/guidelines
>> List Help .................. http://www.ixda.org/help
>>
>
>
>
> --
> Any fool can make things bigger, more complex, and more violent. It
> takes a touch of genius - and a lot of courage - to move in the
> opposite direction. -- Albert Einstein

Syndicate content Get the feed