|
|
| (131 intermediate revisions by 6 users not shown) |
| Line 1: |
Line 1: |
| =Firefox Desktop Iterative Development=
| | #REDIRECT [[Loop#Triage]] |
| <p> </p>
| |
| | |
| ==Objectives==
| |
| <p> </p>
| |
| 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.
| |
| <p> </p>
| |
| | |
| ==Iteration 37.2 Performance==
| |
| <p> </p>
| |
| '''Note:''' Next update on Tuesday January 27 following the conclusion of Iteration 38.1
| |
| <p> </p>
| |
| At the conclusion of Iteration 37.2:
| |
| <p> </p>
| |
| * '''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.
| |
| <p> </p>
| |
| * '''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 .
| |
| <p> </p>
| |
| * '''Firefox Release 38 Production Goal:'''
| |
| ** New production goal will be established prior to the start of IT 38.1.
| |
| <p> </p>
| |
| * '''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.
| |
| <p> </p>
| |
| * '''Iteration 37.2 - Completed Work:'''
| |
| <p> </p>
| |
| <bugzilla>
| |
| {
| |
| "include_fields":"id, summary, status, assigned_to, cf_fx_points",
| |
| "f1":"OP",
| |
| "j1":"AND",
| |
| "f2":"cf_fx_iteration",
| |
| "o2":"equals",
| |
| "v2":"37.2",
| |
| "f3":"flagtypes.name",
| |
| "o3":"substring",
| |
| "v3":"firefox-backlog+"
| |
| }
| |
| </bugzilla>
| |
| <p> </p>
| |
| | |
| ==Product Backlog==
| |
| <p> </p>
| |
| 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.
| |
| <p> </p>
| |
| The Product Backlog is maintained by the Senior Management team (Chad, Gavin, Madhava) to ensure new priorities are available for each Sprint Planning meeting.
| |
| <p> </p>
| |
| '''Product Backlog:''' [http://tinyurl.com/mzxrgre View Bugzilla]
| |
| <p> </p>
| |
| | |
| ==Backlog Triage==
| |
| <p> </p>
| |
| ===Triage Guidelines===
| |
| <p> </p>
| |
| These guidelines determine whether a bug should be included in the Firefox Desktop Backlog.
| |
| <p> </p>
| |
| To be included in the Firefox Desktop Backlog, a bug should:
| |
| <p> </p>
| |
| * 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
| |
| <p> </p>
| |
| * have a difficulty/user-impact ratio low enough that we can reasonably expect to spend time fixing the bug within the next 6 months
| |
| <p> </p>
| |
| * 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
| |
| <p> </p>
| |
| | |
| ===Triage Backlog===
| |
| * [http://tinyurl.com/nd2awrh View Triage Backlog in Bugzilla]
| |
| <p> </p>
| |
| ===Adding Bugs to Triage===
| |
| <p> </p>
| |
| * Click on 'set flags'
| |
| * Set 'firefox-backlog' flag to '?'
| |
| * Desktop Team will review for inclusion in the Product Backlog every two weeks
| |
| | |
| ==Iterations==
| |
| <p> </p>
| |
| '''Note:''' Next update on Tuesday January 27 following the conclusion of Iteration 38.1
| |
| <p> </p>
| |
| The Iteration Backlog is a collection of Work that the team has committed to implement, test and deliver in a two-week iteration.
| |
| <p> </p>
| |
| ===Current Iteration - 37.3===
| |
| <p> </p>
| |
| <bugzilla>
| |
| {
| |
| "include_fields":"id, summary, status, assigned_to, cf_fx_points",
| |
| "f1":"OP",
| |
| "j1":"AND",
| |
| "f2":"cf_fx_iteration",
| |
| "o2":"equals",
| |
| "v2":"37.3",
| |
| "f3":"flagtypes.name",
| |
| "o3":"substring",
| |
| "v3":"firefox-backlog+"
| |
| }
| |
| </bugzilla>
| |
| <p> </p>
| |
| ===Upcoming Iterations===
| |
| <p> </p>
| |
| '''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
| |
| <p> </p>
| |
| | |
| ==Definition of Done==
| |
| <p> </p>
| |
| * The Definition of Done ensures a potentially shippable product increment is released at the conclusion of a release cycle.
| |
| <p> </p>
| |
| * A potentially shippable product increment means compliance with the work's individual acceptance criteria and not the full story under development.
| |
| <p> </p>
| |
| | |
| ==Roles and Responsibilities==
| |
| {| class="wikitable fullwidth-table"
| |
| ! Role !! Contacts !!
| |
| |-
| |
| | Project Champion ||
| |
| * [https://mozillians.org/u/johnath/ Johnathan Nightingale]
| |
| |-
| |
| | Program/Project Management
| |
| * Monitor team and project performance
| |
| * Submit status report at conclusion of each Iteration
| |
| * Organize and facilitate Triage and Planning meetings
| |
| * Guide team through the practices and procedures of the project
| |
| * Ensure team and project impediments are addressed
| |
| |
| |
| * [https://mozillians.org/u/mmucci/ Marco Mucci]
| |
| * [https://mozillians.org/u/jchaulk/ Jenn Chaulk]
| |
| |-
| |
| | Product Manager
| |
| * Define and document product features
| |
| * Maintain Product Backlog, Feature Stories up-to-date and prioritized
| |
| * Review Iteration Build Release
| |
| |
| |
| * [https://mozillians.org/u/cweiner/ Chad Weiner]
| |
| * [https://mozillians.org/u/clarkbw/ Bryan Clark]
| |
| |-
| |
| | UX/Design
| |
| * Self-organizing and self-managing; team determines how much work they can commit to from the Product Backlog during each Iteration Planning meeting
| |
| * Deliver UX assets/work necessary to progress work in backlog
| |
| * Responsible for attending Planning meetings
| |
| * Report impediments to the Project Manager
| |
| * Keep work item, Feature Story and Epic status up-to-date
| |
| |
| |
| * [https://mozillians.org/u/madhava/ Madhava Enros]
| |
| * [https://mozillians.org/u/sevaan/ Sevaan Franks]
| |
| * [https://mozillians.org/u/darrin/ Darrin Henein]
| |
| * [https://mozillians.org/u/mmaslaney/ Michael Maslaney]
| |
| * [https://mozillians.org/u/phlsa/ Philipp Sackl]
| |
| * [https://mozillians.org/u/bwinton/ Blake Winton]
| |
| |-
| |
| | Dedicated Engineering
| |
| * Self-organizing and self-managing; team determines how much work they can commit to from the Product Backlog during each Iteration Planning meeting
| |
| * Deliver build for every sprint consisting of work from sprint backlog
| |
| * Responsible for attending Planning meetings
| |
| * Report impediments to the Project Manager
| |
| * Keep work item, Feature Story and Epic status up-to-date
| |
| |
| |
| * [https://mozillians.org/u/gavin/ Gavin Sharp]
| |
| * [https://mozillians.org/u/paolo/ Paolo Amadini]
| |
| * [https://mozillians.org/u/mak/ Marco Bonardo]
| |
| * [https://mozillians.org/u/Enn/ Neil Deakin]
| |
| * [https://mozillians.org/u/felipe/ Felipe Gomes]
| |
| * [https://mozillians.org/u/mhammond/ Mark Hammond]
| |
| * [https://mozillians.org/u/smacleod/ Steven MacLeod]
| |
| * [https://mozillians.org/u/8879c6d17a/ Asaf Romano]
| |
| * [https://mozillians.org/u/ttaubert/ Tim Taubert]
| |
| * [https://mozillians.org/u/adw/ Drew Willcoxon]
| |
| * [https://mozillians.org/u/dolske/ Justin Dolske]
| |
| * [https://mozillians.org/u/dao/ Dao Gottwald]
| |
| * [https://mozillians.org/u/Gijs/ Gijs Kruitbosch]
| |
| * [https://mozillians.org/u/Unfocused/ Blair McBride]
| |
| * [https://mozillians.org/u/MattN/ Matthew Noorenberghe]
| |
| * [https://mozillians.org/u/jaws/ Jared Wein]
| |
| * [https://mozillians.org/u/mdeboer/ Michael de Boer]
| |
| |-
| |
| | QA
| |
| * Create and execute test plans
| |
| * Verify acceptance criteria
| |
| * Responsible for attending Planning meetings
| |
| * Report impediments to the Project Manager
| |
| |
| |
| * [https://mozillians.org/u/mschifer/ MarcSchifer]
| |
| * [https://mozillians.org/u/juanb/ Juan Becerra] (Firefox 32)
| |
| * [https://mozillians.org/u/ae5685404e/ Tracy Walker] (Firefox 33)
| |
| * [https://mozillians.org/u/lizhenry/ Liz Henry] ([https://wiki.mozilla.org/Releases/Firefox_34/Test_Plan Firefox 34])
| |
| |-
| |
| | Release Management ||
| |
| * [https://mozillians.org/u/lmandel/ Lawrence Mandel]
| |
| * [https://mozillians.org/u/lsblakk/ Lukas Blakk]
| |
| * [https://mozillians.org/u/sylvestre/ Sylvestre Ledru]
| |
| |-
| |
| |}
| |
| <p> </p>
| |
| | |
| ==Communication==
| |
| <p> </p>
| |
| ===General===
| |
| <p> </p>
| |
| * '''Team Mailing list:''' [[Firefox/firefox-dev]]
| |
| * '''Team IRC Channel:''' [irc://irc.mozilla.org/fx-team #fx-team]
| |
| <p> </p>
| |
| | |
| ===Sprint Planning/Review and Status Meeting===
| |
| <p> </p>
| |
| {| class="wikitable"
| |
| |-
| |
| ! 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 || [http://arewemeetingyet.com/Los%20Angeles/2014-04-29/8:00/w/Firefox%20Planning/Status%20Meeting AWMY]
| |
| |-
| |
| | "Afternoon" || Tuesdays || 4:00PM - 5:00PM || 7:00PM - 8:00PM || 1:00AM - 2:00AM || [http://arewemeetingyet.com/Los%20Angeles/2014-05-20/04:00/w/Firefox%20Planning AWMY]
| |
| |}
| |
| | |
| * '''Duration:''' 1 hour
| |
| * '''Vidyo Room:''' "Firefox"
| |
| * '''Iteration Backlog:''' [https://docs.google.com/spreadsheets/d/10sr6YhDNmO4oimlNtxDZ5fe6IaQKmZ7gqT-ZWqAygrI/edit?usp=sharing View Priority List]
| |
| <p> </p>
| |
| | |
| ==Iteration Performance Reports==
| |
| <p> </p>
| |
| '''Note:''' Next update on Tuesday January 27 following the conclusion of Iteration 38.1
| |
| <p> </p>
| |
| * View Current Report - [https://wiki.mozilla.org/Firefox/IterativeDevelopment/IT-37.2PerformanceReport Iteration 37.2: Tuesday December 9 - Monday December 22]
| |
| * [https://wiki.mozilla.org/Firefox/IterativeDevelopment/PerformanceReportArchive View Report Archive]
| |
| <p> </p>
| |
| | |
| ==Contribute to Firefox Desktop==
| |
| <p> </p>
| |
| ===Good First Bugs===
| |
| <p> </p>
| |
| 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 [https://developer.mozilla.org/en-US/docs/Introduction excellent documents on MDN] to help you get started, and the #introduction IRC channel exists just to help people getting started as contributors.
| |
| <p> </p>
| |
| * '''Desktop Backlog Good First Bugs - [http://tinyurl.com/n7neqn6 View in Bugzilla]
| |
| <p> </p>
| |
| ===Good Next Bugs===
| |
| <p> </p>
| |
| 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.
| |
| <p> </p>
| |
| * '''Desktop Backlog Good Next Bugs - [http://tinyurl.com/n5go84a View in Bugzilla]
| |
| <p> </p>
| |
| ===Diamond Bugs===
| |
| <p> </p>
| |
| 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.
| |
| <p> </p>
| |
| * '''Desktop Backlog Diamond Bugs - [http://tinyurl.com/kmqddfd View in Bugzilla]
| |
| <p> </p>
| |