6449
Comment:
|
6417
|
Deletions are marked like this. | Additions are marked like this. |
Line 3: | Line 3: |
'''Where's the beef? Go to the [[LEP|List of drafting, approved and archived LEPs]]!''' Go to the '''[[LaunchpadEnhancementProposalTemplate|template]]'''. |
|
Line 4: | Line 6: |
* '''Process Owner:''' JonathanLange | * '''Process Owner:''' ProductStrategist |
Line 14: | Line 16: |
Ultimately, it's at your discretion. If you end up spending a lot of time on something, then others on the team are going to want something like a Launchpad Enhancment Proposal to read. Some rules of thumb: You do '''not''' need to follow this process if * you are making a change that's not visible to users, * you are fixing a shallow defect, or * you already have answers for each item on the ReadyToCode checklist You definitely need to follow this process if |
You '''must''' follow this if: |
Line 29: | Line 22: |
When in doubt, ask the Product Strategist or the relevant Team Lead. | You '''probably don't need''' to follow this if: * you are making a change that's not visible to users, * you are fixing a shallow defect, or * you already have answers for each item on the ReadyToCode checklist The first list overrides the second list. When in doubt, ask the Product Strategist. |
Line 41: | Line 39: |
* Do not specify implementation approaches | |
Line 44: | Line 43: |
This process is triggered when the Product Strategist schedules the implementation of a new feature onto the Launchpad RoadMap. At this point, the feature is already expected to have a UserStory associated with it. |
This process is triggered when you want to do a new feature, or when beginning work on a feature squad. |
Line 60: | Line 57: |
The input should include a user story with a form like: | The input should include as many [[UserStories|user stories]] as possible with a form like: |
Line 78: | Line 75: |
* Some kind of UserStory — don't be too fussy here, whatever helps * A reason for doing this now === Create the blueprint === 1. Think of a HeadLine for the feature. It should be short and punchy. e.g. “Bug heat” 1. Create a blueprint with the headline in the name 1. Mark the Product Strategist as the approver 1. Mark yourself as the drafter |
* Some [[UserStories|user stories]] — This helps the Product team later with [[https://wiki.canonical.com/Launchpad/PolicyandProcess/UserResearch|user research]] and [[https://wiki.canonical.com/Launchpad/PolicyandProcess/ExploratoryTesting|exploratory testing]] |
Line 90: | Line 79: |
1. Make a page on https://dev.launchpad.net/, give it a similar name to the blueprint | 1. Make a page on https://dev.launchpad.net/, give it a short, punchy name |
Line 92: | Line 81: |
1. Link it to the blueprint | |
Line 95: | Line 83: |
1. Add the reasons for doing it now | 1. Add the wiki page to the "Drafting" section of [[LEP]] |
Line 102: | Line 90: |
=== Talk to the product strategist === Just in case you missed it, you should really talk to the Product Strategist. |
|
Line 125: | Line 117: |
=== Identify workflows === | === Delete any unused sections === |
Line 127: | Line 119: |
Any new feature will have a bunch of workflows in the UI. Get as many of these down as possible. Once you've got them down, start making mockups for them. | It makes the document easier to read. |
Line 131: | Line 123: |
Review the output with the Product Strategist. | Move the link to the proposal on [[LEP]] from "Drafting" to "Needs approval". Review the output with the Product Strategist, who will move it on to "Ready to code" or bounce it back to "Drafting". |
Line 143: | Line 137: |
A Launchpad blueprint and a wiki page. | A wiki page and a link on [[LEP]]. |
Line 161: | Line 155: |
* Are not set in stone * Do not specify a solution |
* Is not set in stone * Does not specify a solution |
Line 164: | Line 158: |
== Supporting Documentation == | |
Line 165: | Line 160: |
TODO: Need to mark all existing blueprints as obsolete before using blueprints again == Comments == |
* [[PolicyAndProcess/LEPImplementationReview|LEP Implementation Review Process]] |
Launchpad Enhancement Proposal Process
Where's the beef? Go to the List of drafting, approved and archived LEPs! Go to the template.
Process Name: Launchpad Enhancement Proposal process
Process Owner: ProductStrategist
Parent Process/Activity:
Supported Policy: None
Description
A way of proposing an enhancement to Launchpad, so that we're ReadyToCode as quickly as possible.
Do I need to follow this?
You must follow this if:
- you are adding a new feature
- you are reworking an existing feature
- you are extending or changing the workflows of an existing feature
- you have spent more than thirty minutes talking about the change without doing it
You probably don't need to follow this if:
- you are making a change that's not visible to users,
- you are fixing a shallow defect, or
you already have answers for each item on the ReadyToCode checklist
The first list overrides the second list. When in doubt, ask the Product Strategist.
Rationale
Launchpad regularly develops new features. We'd like to make sure that these features are implemented well, and that they are what our users actually need.
This process is successful if it helps us make exactly what users want, with no wasted extra features and no crappy pain points in the new interfaces.
In particular, we want to have feature definitions that:
- Produce requirements for use by Launchpad developers
- Can inform QA
- Make it easy for timely input from people who are interested
- Do not specify implementation approaches
Triggers
This process is triggered when you want to do a new feature, or when beginning work on a feature squad.
Roles
- Product Strategist
- Analyst
- Stakeholders
The Product Strategist triggers this process and approves any output from it.
The Analyst is the author of any of the outputs. The Analyst can be any Launchpad developer or community member. The Strategist should be available to take the role of doing the actual writing, particularly if the Analyst finds it a burden. The thinking must come from the Analyst.
Inputs
The input should include as many user stories as possible with a form like:
As a $PERSON
I want $FEATURE
so that $BENEFIT
There must also be a list of Stakeholders — people who are actually interested in the feature.
The input should also include a written reason as to why we are working on this feature right now, instead of other features that we could be doing.
Any existing user research data should be considered as input.
Process
Collect the inputs
Make sure you have:
- A list of Stakeholders
Some user stories — This helps the Product team later with user research and exploratory testing
Create the wiki page
Make a page on https://dev.launchpad.net/, give it a short, punchy name
Consider using the LaunchpadEnhancementProposalTemplate
- List the Stakeholders at the top
- Add the story
Add the wiki page to the "Drafting" section of LEP
Talk to someone
Talk to someone, anyone. Talk over the phone and make notes with something like Gobby, or just on the wiki page directly.
Good people to talk to include Stakeholders and the Product Strategist.
Talk to the product strategist
Just in case you missed it, you should really talk to the Product Strategist.
Start adding constraints
A constraint is some condition that the solution must satisfy. The constraints listed here should be:
specific, avoid “motherhood and apple pie” statements such as “feature must be awesome”
- testable, it should be clear when the constraint is satisfied
But actually, the more the merrier. Get them down first, get them right later.
It's important to work with Stakeholders at this stage. Remember to ask “why” a million times over so that we get the right constraint down.
These constraints should not specify a solution.
Often, it's very helpful to describe what things are not included as part of the feature.
Jot down sub-features
Thinking about the problem will probably lead you to discover sub-features, smaller things that can be delivered independently and will add value while building up to reach the bigger story.
These sub-features can have their own feature document / blueprint thing, or they can go down in this document.
Either way, each sub-feature should go through a process very similar the one of the overall feature.
Delete any unused sections
It makes the document easier to read.
Get it reviewed
Move the link to the proposal on LEP from "Drafting" to "Needs approval".
Review the output with the Product Strategist, who will move it on to "Ready to code" or bounce it back to "Drafting".
This process is complete when we feel we have enough information to start designing a UI. Remember the process is iterative. It's expected that the actual constraints will be better understood as we start to design & implement.
Success criteria
Answer the following questions:
- How will we know when it's done?
- How will we know if it's done well?
Output
A wiki page and a link on LEP.
If not already, the LEP should be raised for discussion on the development mailing list.
Consider blogging or tweeting about it.
If the LEP is really, actually to be done, then make sure that it is linked from the RoadMap.
When doing user testing of this feature, use the LEP as a reference.
Notes
What is a requirement?
- A constraint on a feature
- Makes the "value" of the feature apparent
- You can do an experiment that shows whether or not the requirement is met
- A requirement is always for someone for some benefit
- Is not set in stone
- Does not specify a solution