Firefox/IterativeDevelopment: Difference between revisions
| Line 115: | Line 115: | ||
<p> </p> | <p> </p> | ||
===Upcoming Iterations=== | ===Upcoming Iterations=== | ||
<p> </p> | <p> </p> | ||
'''Firefox 38 Release''' | '''Firefox 38 Release''' | ||
* '''Iteration 38.1:''' Tuesday January | * '''Iteration 38.1:''' Tuesday January 13 - Monday January 26 | ||
* '''Iteration 38.2:''' Tuesday January | * '''Iteration 38.2:''' Tuesday January 27 - Monday February 9 | ||
* '''Iteration 38.3:''' Tuesday February | * '''Iteration 38.3:''' Tuesday February 10 - Monday February 23 | ||
<p> </p> | <p> </p> | ||
Revision as of 03:48, 24 December 2014
Firefox Desktop Iterative Development
Objectives
The Iterative Development Model implemented for Firefox Desktop aims to accomplish six key objectives:
- Transparent - Who is working on what, when, and why.
- Predictable and Repeatable - Know what to expect from the process.
- Inclusive - Include all key participants (Eng, UX, QA, Security, Product) and stakeholders in the process.
- Clear Direction and Decision Making - Know what we should do and who makes the call.
- Clear and Stable Priorities - Be clear on what is most important for each iterative cycle.
- Innovative - Provide flexibility to engage in experimental and original projects.
Iteration 37.2 Performance
Note: Next update on Tuesday January 27 following the conclusion of Iteration 38.1
At the conclusion of Iteration 37.2:
- Velocity Range:
- Modified velocity range established using new performance modelling technique and data starting from IT 32.2 when the full desktop team was integrated into the iterative development model.
- Maximum production capacity rebased to 250.
- Median production capacity rebased to 170.
- Minimum production capacity rebased to 74.
- Modified velocity range will be used as the baseline to evaluate performance in Q1 2015 starting with IT 38.1.
- Modified velocity range established using new performance modelling technique and data starting from IT 32.2 when the full desktop team was integrated into the iterative development model.
- Firefox Release 37 Production Goal:
- Team failed to achieve the production goal of 470 points and completed 417 points (89%) across the two iterations of the 37 release cycle .
- Firefox Release 38 Production Goal:
- New production goal will be established prior to the start of IT 38.1.
- Team Performance:
- Points completed increased to 234 across 86 bugs from the previous iteration.
- Percentage of point target completed increased to 97% from the previous iteration.
- Iteration 37.2 - Completed Work:
89 Total; 0 Open (0%); 47 Resolved (52.81%); 42 Verified (47.19%);
Product Backlog
All work related to the ongoing development and maintenance of the Firefox Desktop Product are collected and prioritized in the Product Backlog. The goals of the Product Backlog are to:
- Enable work to be prioritized so that the team is always working on the most important features.
- Support continual planning as the product emerges so the plan matches reality.
- Improve forecasts so that the stakeholders make the best decisions about the direction of the product.
The Product Backlog is maintained by the Senior Management team (Chad, Gavin, Madhava) to ensure new priorities are available for each Sprint Planning meeting.
Product Backlog: View Bugzilla
Backlog Triage
Triage Guidelines
These guidelines determine whether a bug should be included in the Firefox Desktop Backlog.
To be included in the Firefox Desktop Backlog, a bug should:
- be in an actionable state
- for defects, the problem is ready for Engineering or UX: diagnosis, measurement, design, or fixing
- for feature requests or enhancements, it means that there's a clear problem statement or suggestion
- have a difficulty/user-impact ratio low enough that we can reasonably expect to spend time fixing the bug within the next 6 months
- be within the general area of ownership/responsibility of the Firefox Desktop Team (Engineering and UX)
- this means e.g. platform bugs that are outside of our area of expertise/ownership should generally not be added to the Backlog
Triage Backlog
Adding Bugs to Triage
- Click on 'set flags'
- Set 'firefox-backlog' flag to '?'
- Desktop Team will review for inclusion in the Product Backlog every two weeks
Iterations
Note: Next update on Tuesday January 27 following the conclusion of Iteration 38.1
The Iteration Backlog is a collection of Work that the team has committed to implement, test and deliver in a two-week iteration.
Current Iteration - 37.3
No results.
0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);
Upcoming Iterations
Firefox 38 Release
- Iteration 38.1: Tuesday January 13 - Monday January 26
- Iteration 38.2: Tuesday January 27 - Monday February 9
- Iteration 38.3: Tuesday February 10 - Monday February 23
Definition of Done
- The Definition of Done ensures a potentially shippable product increment is released at the conclusion of a release cycle.
- A potentially shippable product increment means compliance with the work's individual acceptance criteria and not the full story under development.
Roles and Responsibilities
| Role | Contacts | |
|---|---|---|
| Project Champion | ||
Program/Project Management
|
||
Product Manager
|
||
UX/Design
|
||
Dedicated Engineering
|
||
QA
|
| |
| Release Management |
Communication
General
- Team Mailing list: Firefox/firefox-dev
- Team IRC Channel: #fx-team
Sprint Planning/Review and Status Meeting
| Meeting | Day of week | Pacific Time | Eastern Time | Central European Time | Time zone conversions |
|---|---|---|---|---|---|
| "Morning" | Tuesdays | 8:00AM - 9:00AM | 11:00AM - 12:00PM | 5:00PM - 6:00PM | AWMY |
| "Afternoon" | Tuesdays | 4:00PM - 5:00PM | 7:00PM - 8:00PM | 1:00AM - 2:00AM | AWMY |
- Duration: 1 hour
- Vidyo Room: "Firefox"
- Iteration Backlog: View Priority List
Iteration Performance Reports
Note: Next update on Tuesday December 23 following the conclusion of Iteration 37.2
- View Current Report - Iteration 37.1: Tuesday November 25 - Monday December 8
- View Report Archive
Contribute to Firefox Desktop
Good First Bugs
These are tagged as [good first bug] in a bug's Whiteboard field. The challenge of a "good first bug" is only peripherally about the bug itself. The focus, for a new contributor, should be on getting your development environment set up and learning how to navigate Mozilla's contribution process. There are some excellent documents on MDN to help you get started, and the #introduction IRC channel exists just to help people getting started as contributors.
- Desktop Backlog Good First Bugs - View in Bugzilla
Good Next Bugs
Marked as [good next bug] on the whiteboard, these are a the next level up, where the challenge of the bug is actually fixing the bug. There are four parts to a well-described Good Next Bug: a willing mentor, a clear initial description of the problem, clear expectations on the part of the both the mentor and contributor, and a cooperative working relationship as the bug is resolved.
- Desktop Backlog Good Next Bugs - View in Bugzilla
Diamond Bugs
Marked as [diamond] on the whiteboard, this label doesn't speak to a bug's difficulty, but rather speaks to its importance. Diamond bugs are bugs that have been brought up as important bugs in engineering's various priority-triage processes but aren't assigned to an engineer by the end of the triage process.
- Desktop Backlog Diamond Bugs - View in Bugzilla