Firefox OS/ProgramManagement: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(connected devices)
 
(67 intermediate revisions by 15 users not shown)
Line 1: Line 1:
==Rollout Strategy==
==FXOS Engineering Program Management Office (PMO)==
<center> <big>'''Click the program on the graphic to view further information'''</big> </center>
<imagemap>Image:EPMPortfolio1.png
rect 10 125 170 225 [[Connected Devices Portfolio Management|Connected Devices Portfolio Management]]
rect 10 200 170 245 [[2.5 Program Manager|2.5 Program Manager]]
rect 10 395 170 408 [[Hackability|Hackability]]
rect 10 409 170 430 [[Bugzilla Lite|Bugzilla Lite]]
rect 10 431 170 450 [[FirefoxOS/FlyWeb|FlyWeb]]
rect 10 451 170 470 [[Android Ports|Android Ports]]
rect 10 471 170 490 [[B2Gdroid|B2Gdroid]]
rect 171 125 320 195 [[NSEC (New Security Model)|NSEC (New Security Model)]]
rect 171 196 320 215 [[Foxfooding|Foxfooding]]
rect 171 216 320 230 [[Project Alopex|Project Alopex]]
rect 171 395 320 408 [[TV|TV]]
rect 171 409 320 430 [[Marigold|Marigold]]
rect 171 431 320 450 [[RTL (Right to Left)|RTL (Right to Left)]]
rect 171 451 320 470 [[Emulator|Emulator]]
rect 320 125 470 180 [[Kill Switch|Kill Switch]]
rect 320 140 470 200 [[Task Continuity Description|Task Continuity Description]]
rect 320 395 470 408 [[Voice|Voice]]
rect 320 409 470 430 [[Data Sync|Data Sync]]
rect 320 431 470 450 [[Cloud Storage|Cloud Storage]]
rect 320 451 470 490 [[NSEC (New Security Model)|NSEC (New Security Model)]]
rect 320 491 470 505 [[Geolocation Description|Geolocation Description]]
rect 320 506 470 530 [[Bluetooth|Bluetooth]]
rect 470 125 620 200 [[Engineering Quality Program|Engineering Quality Program]]
rect 470 395 620 430 [[OTA (Over the Air) updates|OTA (Over the Air) updates]]
rect 630 125 770 180 [[Privacy|Privacy]]
rect 630 140 770 200 [[Late Customization|Late Customization]]
rect 630 196 770 215 [[Marketplace TV|Marketplace TV]]
rect 630 216 770 230 [[Pin the Web|Pin the Web]]
rect 630 395 770 408 [[Performance|Performance]]
rect 630 409 770 460 [[DRM (Digital Rights Media)|DRM (Digital Rights Media)]]
rect 780 125 950 180 [[Add-ons Description|Add-ons Description]]
rect 780 395 950 438 [[FirefoxOS/NGA|FirefoxOS/NGA]]
rect 780 439 950 450 [[Metrics Description|Metrics Description]]
rect 780 451 950 480 [[Data|Data]]
desc bottom-left
</imagemap>


===Team Kickoff Meetups===


Some teams have scheduled a three day meetup for functional team process kickoff. An example agenda:
* [[FxOS Portfolio Management]]
* [[2.5 Program Manager]]
* [[NSEC (New Security Model)]]
* [[Foxfooding]]
* [[Project Alopex]]
* [[Kill Switch]]
* [[Firefox OS Cloud Servies]]
* [[Privacy Description]]
* [[Late Customization]]
* [[Marketplace TV]]
* [[Pin the Web]]
* [[Add-ons Description]]
* [[Aha Admin]]
* [[Hackability]]
* [[Bugzilla Lite]]
* [[Wikis]]
* [[TV]]
* [[Marigold]]
* [[RTL (Right to Left)]]
* [[Emulator]]
* [[Voice]]
* [[Data Sync]]
* [[Cloud Storage]]
* [[Geolocation Description]]
* [[Bluetooth]]
* [[Red Tai/Red Square]]
* [[OTA (Over the Air) updates]]
* [[Performance Description]]
* [[DRM (Digital Rights Media)]]
* [[FirefoxOS/NGA]]
* [[Metrics Description]]
* [[Web Components]]
* [[Web Components Performance]]
* [[Data]]
* [[Engineering Quality Program]]
* [[OWDCRB]]


Day 1:
==Bugzilla Flags==
* Team introductions
* Kickoff intro: Purpose and Goal of work week (Eng Mgr)
* High Level Roadmap for agile rollout and 1.2 (PO / EPM)
* FFOS Dev Process Training (EPM) - 1.5hr
* First pass review of user stories, acceptance criteria, UX wireframes, Scope etc (PO)


Day 2:
The team will be using the following whiteboard text for tracking user stories and their priorities in Bugzilla.


* Introduction to Estimation and Planning Poker (EPM)
'''Overview'''
* Definition of Done (All Team)
* ONE bug per user story. Implementation tasks and bugs should be marked as blocking the user story bug.
* #1 planning poker session (target top half of backlog)
* ALL user stories that are either committed or targeted to a release must have a bug filed.
* If a bug is not a user story it will NOT have any of these flags in the whiteboard.


Day 3:
'''Data'''
* The user story id, as found in the Product backlog spreadsheet, is written in the bug whiteboard as "ucid:{id}", eg: "ucid:Browser326".
* The functional team that is responsible for the implementation of the user story is written as "ft:{teamname}", eg: "ft:media".


* Sprint Planning and commitment (all team)
'''Format'''
* Incorporation of user stories into bugzilla (PO / EPM)
* Grammar: [ucid:{id}, {release-version}, ft:{team-id}]
* The entire block is contained within square brackets
* Case-insensitive. UCID and ucid are both valid.
* Key and value are separated by a colon (no spaces).
* Key/value pairs are separated by a space and comma.


===Steps For Developing and Communicating Each Topic===
'''Examples'''
* [ucid:System26, 1.3, ft:systems-fe]
* [ucid:Comms27, 1.3, ft:comms]


* Create a common consensus among leadership
===feature-b2g Flag===
* Document the decision with the goal of maximum penetration and education
'''The purpose'''
* Insure that team receives the documentation and is encourage to digest it
* The feature-b2g flag is intended to be used to help define scope for a particular release.
* Training sessions
* The feature-b2g flag enables us to isolate the particular engineering tasks that make up the completion of the feature in a release time frame.
* Screencasts
* feature-b2g version#? is defined as "this feature is being proposed for this release"
* Documentation on the wiki
* feature b2g- version#+ is define as "this feature has been committed (by the engineering team(s)) for this release"
'''How to tag'''
* [meta] bugs features and all dependencies targeted for a particular release should mark feature-b2g flag.
* The feature-b2g flag should assigned to engineering tasks falling under the user stories AND the user stories themselves.
* feature-b2g should flag to feature work only, not polish, enhancement or refactor work. Unless there's a user story dedicated for those work in a particular release. This gives us a more stable feature-b2g bug number and better prediction/tracing.
* You can only mark the flag for engineers assigned on your team - not partner teams.
'''Who has the permission'''
* PM and EPM, engineer managers and partner peers have the access


===What we need people to have a common understanding on===
== EPM Toolbox ==  
* [https://etherpad.mozilla.org/AgileTeamRoles Roles and responsibilities]
Wiki: [[Firefox_OS/EPM_Toolbox|Link]]
* [https://etherpad.mozilla.org/AgileTeams What the teams are on FirefoxOS]
* How the scrum process works (flow diagram)
* How the flow works (flow diagram)
* Key deliverables at each handoff point (flow diagram)
* What a user story should contain
* Expanding user story bug with UX deliverables
* How to organize information in the backlog
* How to priorities and add buisness value points
* How to integrate user stories into bugzilla
* How to estimate add points to user stories
* How to run a scrum planning meeting
* How to manage dependencies
* Inter scrum team depedencies
* Platform team depedencies
* How to manage defects
* How to report on progress
* How to integrate release engineering
* How to integrate QA
 
===Audiences we have to ensure understand the expectations of the system===
* Senior Stackholders/Project Leadership
* Product Managers
* Engineering Project/Program Managers
* Development Managers
* UX
* Engineering Managers
* Engineering Developers
* QA
* Release Management
* Platform Egineering Managers
* Marketing and PR
* Launch Managers
 
===Suggested model from onboarding teams===
* We insert a experienced EPM with Scrum experience to run the iteration for the first iteration, they act as the Scrum Master
* Second round sees whomever has been assigned as the scrum master permanently to run the iteration with the EPM actively engaged
* Third around the EPM is monitoring the scrum master making sure that all is running well and putting out any remaining fires
* Fourth iteration, the EPM is no longer needed unless they are infact are he designated scrum master.
 
==FXOS Functional Teams==
* Productivity
* Media
* Performance
* Browser
* Comms (Dialer, SMS, Contacts)
* Systems (Notification, Apps Install, Customizations)
* RIL, BT, GPS
* Settings Cost Control
* GFX, Layout, Audio
* Devices
 
==Process Definitions and Sprint Meetings==
 
===BACKLOG GROOMING===
Backlog grooming is an exercise between Product, Engineering, and UX to review current stories and feature sets to better flesh out requirements, dependencies, risks, assumptions and acceptance criteria. Acceptance criteria is a bulletized list that confirms when a user story is DONE.
 
'''Example Metro story with detailed requirements for reference is [https://bug831910.bugzilla.mozilla.org/attachment.cgi?id=720141 here]'''
 
* '''ACTION ITEM:''' Meetings between product, engineering, UX to:
** Merge and consolidate multiple backlogs into one here [https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0AtVT90hlMtdSdEd4TVVjWXNfU3ctMlVhWFRrWkpweVE#gid=12 FFOS Backlog]
** Define User Acceptance Criteria (UAC)
** List assumptions, dependencies, and risk
** High-level Tshirt size scoping
** Determine UX wireframe necessity for each story
*'''OUTPUT:''' Fleshed out user stories in above backlog template that has been socialized between all teams
 
===DEFINITION OF DONE===
Agreement between product, development, and QA on what quantifies a story as "done." (Are we measuring to code-complete or release-ready?) This list needs to be drafted, socialized, and published team-wide for broad communication and expectation. This will set the team up for story point estimation.
 
'''Example:'''
* User Acceptance Criteria (UAC) Complete
* QA test suite complete (Regression Success Rate)
* Product and UX Sign-off
 
===RELATIVE SIZING AND ESTIMATION===
Because there is high uncertainty on what we are building in software development, it is very difficult to size a feature or user story in time. There are agile techniques to help weight and size stories relative to other stories that a team has completed.  Since this is our first pass as a scrum team we will start with a base range and begin relative sizing as the team moves farther through their sprints.
 
*'''STORY POINTS:''' an arbitrary measurement that is unique to a scrum team. Scrum follows the fibonacci sequence because it allows variance for work effort. (1,2,3,5,8,13...)
*'''PLANNING POKER:''' an exercise whereby the engineering team (development and QA) complete rounds of conversation with the product owner and vote accordingly on point value for a specific story. If votes between team members differ significantly, a conversation is time-boxed to possibly uncover more information needed. The voting cycles 3 times and story point estimates start to converge to an agreed about value.
 
===BACKLOG PRIORITIZATION===
Given all the above requirements (Backlog grooming, defining done, and estimation) Product Owners are more equipped to weight priority among the user stories in the backlog.
 
===SPRINT PLANNING===
A planning session with all team members (development, qa, us, product, pgm) to review top priority stories in backlog, break down stories into work tasks, and COMMIT to completing them in the following two weeks.
 
===SPRINT DEMO===
All team participation lead by engineering to demonstrate done-work from previous sprint.
 
===SPRINT RETROSPECTIVE===
All team participation review of wins, challenges, and action items for improvement from previous sprint. This is a very important meeting for team to better understand if our process is working for our team.
 
==Agile Workflow==
 
[[File:Screen_Shot_2013-06-12_at_3.48.10_PM.png]]
 
==Agile Process Action Plan==
(for all functional scrum teams)
 
===Week 1:===
* Complete backlog grooming using this [https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0Ah4HhR7Qg1hxdHREb0xEZV9zTktoUWg5WEhRQ0kxbWc#gid=2 template] - (product, eng, ux team leads)
* Get some communication channels for discussion.
* Get alignment on roles and responsibilities
* Get alignment on rollout plan.
** EPMs will be responsible for driving the rollout.
* Work on aligment on the process.
 
===Week 2: (Ending June 14)===
* Draft document of scrum flow - handoffs and responsible individuals
* Present draft of process for small team
* Work alignment on process
** How to handle distributed teams
* Define, agree, socialize and publish definition of done - (all team)
* '''Key Milestone''': User story requirements, assumptions, and dependencies for 1.2 MVP
 
===Week 3: (Ending June 21)===
* Present draft of process. (agile team leads) - need to have a recorded presentation for Taipei team
* Finalize alignment on the process
* START: FFOS Development Process Training - (epm team)
* START: Agile Estimation training and Planning Poker (epm team)
* '''Key Milestone''': User Acceptance Criteria and High level scope (Tshirt sizing) for 1.2 MVP (gut check for 1.2 list)
 
===Week 4: (Ending June 28)===
* IN PROGRESS: FFOS Development Process Training
* IN PROGRESS: Estimation Training and Planning Poker
 
===Week 5: (Ending July 5)===
* IN PROGRESS: FFOS Development Process Training
* IN PROGRESS: Estimation Training and Planning Poker
 
===Week 6: (Ending July 12)===
* Key Milestone: All training complete
 
===Week 7: (Ending July 18)===
* Final prioritization and scoring for backlog - (product, eng, ux team leads)
* '''Key Milestone''': Partner communication and project scope - (pgm and epm teams)
 
===Week 7: (Ending July 25)===
* START: Sprint Planning
* '''Key Milestone:''' First sprint start
 
==Agile Milestone Schedule:==
[[File:Rollout_milestones_6-27.jpg]]

Latest revision as of 19:15, 18 December 2015

FXOS Engineering Program Management Office (PMO)

Click the program on the graphic to view further information
Connected Devices Portfolio Management2.5 Program ManagerHackabilityBugzilla LiteFlyWebAndroid PortsB2GdroidNSEC (New Security Model)FoxfoodingProject AlopexTVMarigoldRTL (Right to Left)EmulatorKill SwitchTask Continuity DescriptionVoiceData SyncCloud StorageNSEC (New Security Model)Geolocation DescriptionBluetoothEngineering Quality ProgramOTA (Over the Air) updatesPrivacyLate CustomizationMarketplace TVPin the WebPerformanceDRM (Digital Rights Media)Add-ons DescriptionFirefoxOS/NGAMetrics DescriptionDataEPMPortfolio1.png
About this image


Bugzilla Flags

The team will be using the following whiteboard text for tracking user stories and their priorities in Bugzilla.

Overview

  • ONE bug per user story. Implementation tasks and bugs should be marked as blocking the user story bug.
  • ALL user stories that are either committed or targeted to a release must have a bug filed.
  • If a bug is not a user story it will NOT have any of these flags in the whiteboard.

Data

  • The user story id, as found in the Product backlog spreadsheet, is written in the bug whiteboard as "ucid:{id}", eg: "ucid:Browser326".
  • The functional team that is responsible for the implementation of the user story is written as "ft:{teamname}", eg: "ft:media".

Format

  • Grammar: [ucid:{id}, {release-version}, ft:{team-id}]
  • The entire block is contained within square brackets
  • Case-insensitive. UCID and ucid are both valid.
  • Key and value are separated by a colon (no spaces).
  • Key/value pairs are separated by a space and comma.

Examples

  • [ucid:System26, 1.3, ft:systems-fe]
  • [ucid:Comms27, 1.3, ft:comms]

feature-b2g Flag

The purpose

  • The feature-b2g flag is intended to be used to help define scope for a particular release.
  • The feature-b2g flag enables us to isolate the particular engineering tasks that make up the completion of the feature in a release time frame.
  • feature-b2g version#? is defined as "this feature is being proposed for this release"
  • feature b2g- version#+ is define as "this feature has been committed (by the engineering team(s)) for this release"

How to tag

  • [meta] bugs features and all dependencies targeted for a particular release should mark feature-b2g flag.
  • The feature-b2g flag should assigned to engineering tasks falling under the user stories AND the user stories themselves.
  • feature-b2g should flag to feature work only, not polish, enhancement or refactor work. Unless there's a user story dedicated for those work in a particular release. This gives us a more stable feature-b2g bug number and better prediction/tracing.
  • You can only mark the flag for engineers assigned on your team - not partner teams.

Who has the permission

  • PM and EPM, engineer managers and partner peers have the access

EPM Toolbox

Wiki: Link

Retrieved from "https://dev.wikimo.nonprod.webservices.mozgcp.net/index.php?title=Firefox_OS/ProgramManagement&oldid=1109937"