Diff for "PolicyAndProcess/FeatureDevelopment"

Not logged in - Log In / Register
Differences between revisions 3 and 4
⇤ ← Revision 3 as of 2011-06-23 13:47:52 →
Size: 2799
Editor: flacoste
Comment: Use role delegation
← Revision 4 as of 2011-06-23 13:49:53 → ⇥
Size: 2789
Editor: flacoste
Comment: Project lead is responsible for the dev process def
Deletions are marked like this. Additions are marked like this.
Line 4: Line 4:
 * '''Owner:''' [[https://launchpad.net/~launchpad-strategist|Launchpad Product Strategist]]  * '''Owner:''' [[https://launchpad.net/~launchpad-leader|Launchpad Project Lead]]

Contents

  1. Process Overview
    1. Process Description
      1. 0. Stakeholder process
      2. 1. Analysis / LEP drafting / evidence gathering
      3. 2. Core development cycle (2 weeks)
      4. 3. User acceptance testing with stakeholders
      5. 4. Release & promote
    2. Participants
  2. Supporting Documentation

Process Overview

We develop or re-work features for Launchpad all of the time. It turns out that there's quite a lot of stuff that we have to do for each feature. This process summarises what we do for most features, and links out to more detailed process documents.

feature-flow.png

Process Description

0. Stakeholder process

Feature work starts by consulting Launchpad stakeholders to decide what feature we should work on next.

1. Analysis / LEP drafting / evidence gathering

2. Core development cycle (2 weeks)

  1. Plan work

  2. User research / UI design

  3. Development (this is what happens when software engineers make software)

  4. Product team checkpoint

3. User acceptance testing with stakeholders

  • Stakeholders should already be consulted at each checkpoint
  • Announce to stakeholders that work is finishing up and that this is their last chance to review the feature
  • Major changes strongly discouraged
  • Purpose is to communicate that the feature is done and to help stakeholders feel ownership of it

4. Release & promote

  1. Ask the Squadron Leader to add a feature flag for ~launchpad-beta-testers.
  2. Announce a time-boxed beta period:
    • briefly explain the feature
    • warn of any known limitations
    • link to where bugs should be reported and state the tag people should use.
  3. Prepare announcements:
    • Record a screencast of the beta.
    • Write an announcement blog post.
    • Draft any documentation updates.
    • If appropriate, contact press (OMG Ubuntu! is receptive) and get them excited about the feature. Draft something for them, if required.
  4. On the final day of the beta, check that the Squad is ready to take it live.
  5. On release day, coordinate with the Squad as to when they'll take the feature live. Post the announcement, screencast and documentation changes straight after release.
  6. If press are to be involved, contact them.

Participants

  • Launchpad Product Strategist
  • Feature squad
  • Testers

Supporting Documentation

PolicyAndProcess/FeatureDevelopment (last edited 2011-06-23 13:49:53 by flacoste)