Program Management Plan
NOTE: THIS PAGE IS SOMEWHAT OUT OF DATE AS OF FEB 2012 - jefro
Overview of PMP
The purpose of this document is to identify and describe the overall program management processes and methods to be used during all phases of the open source Yocto Project. Derivate programs will follow their own program management processes and methods and document them accordingly.
This Program Management Plan (PMP) establishes the overall plan for the project management of the Yocto Project for versions 1.0 and later. The PMP is a living document and shall be modified as needed under configuration control.
The following documents may be referenced within:
Yocto Project PRD
For this document, the following terms and abbreviations apply:
BSP Board Support Package
CCB Change Control Board
PMP Program Management Plan
POR Plan of Record
PRD Product Requirements Document
Please see Yocto Project Feature List for a description of the specific features in any given release of Yocto Project.
Project Startup Checklist
Upon receiving consent to begin the Project, the Engineering Program Manager will conduct the tasks marked as applicable in the table below to begin the Project. Details on how to conduct these tasks are contained in this document. Completion status will be reported in the project wiki at https://wiki.yoctoproject.org/wiki/Yocto_1.0_Schedule.
|Task||Required for this project?|
|Internal Team Kick-off meeting||Required|
|Review staffing plan and roles with team.||Required|
|Review proposal (Feature List, Assumptions, deliverables, design approach).||Required|
|Discover and document additional requirements.||Required|
|Review and update risk tracking list||Required|
|Review and update project plan (schedule, milestones).||Required|
|Review acceptance approach.||Required|
|Prepare communication plan and flow.||Required|
|Determine meeting types and schedule.||Required|
|Determine report types and schedule.||Required|
|Set up configuration management team||Required|
|Set up any new e-mail aliases required||Required|
|Formalize issue tracking and escalation plan.||Required|
|Prepare initial status report.||Required|
|Update Project Portal on wiki||Required|
Project Defined Processes and Tools
This section documents the project’s defined processes. Where a discrepancy is found between a process described in a linked document or website and this document, this document shall be considered to be the correct process.
Design and Development Process
Quality Management Process
The quality management process and test plan is documented in the following wiki page: https://wiki.yoctoproject.org/wiki/QA --> Yocto Project v1.0
Overall Release Engineering Process
The process used for producing Yocto Project releases is documented on the following wiki page: https://wiki.yoctoproject.org/wiki/Yocto_Release_Engineering and https://wiki.yoctoproject.org/wiki/Yocto_Project_v._1.0_Release_Cycle.
Configuration Management Process
The configuration management tool for all software will be GIT. Current Configuration management practices regarding the rules for access and changes will be followed and are described in the following wiki page: https://wiki.yoctoproject.org/wiki/Best_Known_Methods_(BKMs)_for_Package_Updating
Change Management Process
Yocto Project will have a Change Control Board that will control changes to documents under change control, such as the Feature List or PRD. Changes to documents under change control must be proposed in writing to the Change Control Board via the public Change Control board email list. At least 50% of the CCB needs to respond with a two-thirds approval rate. If there are any disapprovals, the Yocto Project Architect needs to understand the reason for disapproval and agree that the change can proceed in spite of the disapproval.
The Change Control Board members shall be appointed by the Yocto Project Architect. Anyone in the community is welcome to apply to the CCB.
The Yocto Project code base will be considered under change control during the Test/Release phase of each Milestone. During this time, the CCB will approve any significant changes to the code base.
This project will use the Poky standard for BSP formats, documented in the BSP Development Guide: http://www.yoctoproject.org/sites/default/files/bsp-guide_7.pdf
Requirements Management Process
This project will manage features in a Feature List on the project wiki, which will be extruded into the project PRD. The Feature List for 1.0 is ratified as POR by the Yocto Project CCB. Any material changes to the Feature list after POR is set must be ratified by the CCB. Non-material changes may be made by a member of the Yocto Project community by notifying the CCB by email.
The feature list is created by the following process: Current release minus one month: Yocto Project Architect sends a solicitation for next release features. All comments are collected. Current release minus one week: Yocto Project Engineering Managers, Yocto Project Architect, and Yocto Project PM go through the feature request list. Yocto Project Architect prioritizes the features. Group agrees on a theme. PM begins the planning process around this. It is desirable to do this as a mini-conference so that additional people beyond Management, Architects, and PMs are invited.
Current release plus one week: Yocto Project Engineering Manager makes an announcement of the features and themes for the next release.
Maintainers take the finalized feature list and schedule it into different milestones and sprints. The PM will use this list to manage the project.
The following toolset will be used in the execution of this Project:
|Schedule and Progress Tracking||Yocto Project Wiki (ex. https://wiki.yoctoproject.org/wiki/Yocto_1.0_Schedule)|
|Overall Milestone Tracking||Via email to firstname.lastname@example.org|
|Bug Tracking (pre-release)||Bugzilla - http://bugzilla.yoctoproject.org|
|Bug Tracking (post-release)||Bugzilla - http://bugzilla.yoctoproject.org|
|Requirement Tracking||Yocto Project PRD|
|Software Configuration tool||GIT|
|Document Repository||Yocto Project Wiki (https://wiki.yoctoproject.org/wiki/Main_Page)|
|Communication to Team||Mailing lists: email@example.com, firstname.lastname@example.org|
|Feature Tracking||Yocto Project Wiki (https://wiki.yoctoproject.org/wiki/Yocto_Features)|
Project Organization and Roles
Project Roles includes the processes required to make the most effective use of the people involved with the project.
Project Team Roles/Responsibilities
Generic Description of Roles and Responsibilities
Engineering Managers: An engineering manager is a manager at a company contributing to Yocto Project that has a team of Yocto Project engineers reporting to them. The engineering manager is responsible for managing the resources, schedule and requirements within their company for a particular feature area. Responsibilities include but are not limited to:
• Creating and maintaining a schedule for their particular feature group
• Reporting progress against the schedule
• Ensuring development within the feature group is on schedule and determining recovery plans when not on schedule
• Identifying and resolving any resource conflicts for staff reporting to them and/or working in their feature group or escalating problem if resolution not found
• Ensuring all committed requirements owned by feature group are met
• Preparing risk mitigation plan for feature group
• Escalating problems and issues to overall project manager Note that the managers may delegate any or all of their day-to-day responsibilities to an appropriate individual contributor but they still own the responsibilities above.
Engineering Program Manager
The Engineering Program Manager is responsible for the managing the overall project. Responsibilities include but are not limited to:
Creating and maintaining a schedule for the overall project
Reporting progress against the schedule
Reporting status of overall project
Ensuring project is on schedule and working with development managers to determine recovery plans when not on schedule
Determining overall staffing requirements for project and creating staffing plan
Identifying resource conflicts in consolidated schedule and working with development managers to resolve
Ensuring all committed requirements which are not assigned to a feature group are met
Preparing and executing risk mitigation plan for overall project
Escalating problems and issues to the project architect and the project Steering Group as a last resort
Running project meetings, recording minutes and tracking actions
Coordinating activities with groups external to the project
Publishing project information on project portal on the wiki
Scheduling and running program reviews
A Maintainer is an engineer who works on projects requiring advanced knowledge or technical expertise in a particular field of specialization and has been recognized as a responsible leader for this area. The Maintainer is responsible for:
• Technical direction for their area
• Ensuring all design documents are completed and all design reviews held
• Technical program oversight
o Of the program and other cross functional programs
o Deciding which patches or components for their area contributed by members of the community will be accepted or rejected
o Periodic review and tracking of progress toward design milestones
o Periodic review and tracking of implementation vs. High Level Design
o Identification of issues affecting the program or other cross functional areas
o Escalation point for implementation problems or critical defects
• Being the Point of Contact for technical questions and engineering impact assessment against the program of requirement changes
• Sign-off for IP review
The Architect for the project has overall ownership for the technical direction for the project. This includes, but is not limited to:
• Choice of major project components and how major components interact
• Final decision on which patches will be accepted in the project (which may be delegated to one or more Maintainer)
• Developing a long-term roadmap for the project and mapping functionality from the current release into the roadmap
• Ensuring that a proper sequence of steps are followed in releasing the project to maintain quality
Business Program Manager
The business program manager is a senior staff manager with significant technical and commercial experience in one or more specialized areas. The business program manager is the escalation point within the interest group and is responsible for scheduling and driving all marketing and sales related activates, including but not limited to:
• Press announcements
• Conferences and trade shows
• Design wins
Advisory Board Member
The Advisory Board is appointed by the Linux Foundation and is used as a last resort for making decisions on the Yocto Project. It is desirable that decisions for the Yocto Project are defined at the lowest reasonable level. Organizations can request participation at this level based on being LF members and acceptance by the Advisory Board.
A record of minutes from past meetings is on the Minutes page.
Staff Planning and Changes
The number of staff required will be determined between the Engineering Program Manager and the Development Managers.
Project Roll Off and Completion of Project Responsibilities
Prior to roll off, team members will need to check in all code modifications and documentation into GIT. Bugs that have been assigned to that team member will need to be resolved prior to roll off or transitioned to another team member.
Communications and Escalations
Day to Day Communication Path and escalation
The open source governance mechanism will govern the project. The Yocto Project website Governance page defines the Yocto Project governance model in additional detail: http://www.yoctoproject.org/community/governance.
Issue resolution should be handled at the lowest possible level in the project, to avoid bottlenecking decision making. If a decision cannot be reached at the lowest level, then escalation should be made in this sequence:
• Steering Group (only as a last resort)
Project Planning and Tracking
This section is used to capture and summarize the results of project planning and to list the project tracking activities.
Program Management Oversight
A program manager has been assigned from both development and marketing to ensure effective management of the project. Responsibilities are as detailed in Section 6.1 commitments.
Project Scope Management
Scope Planning / Definition
The PRD will be used to define the scope of the project.
Any changes to the scope will be mutually agreed on by development and marketing and will be handled via the Change Management process, see section 5.5.
For Yocto 0.9 and Yocto 1.0, the project will be managed as a series of 6-week milestones. The milestones will be broken out as follows:
• 1 week – planning for this milestone
• 3 weeks – development
• 1 week – stabilization
• 1 week – release
The final project milestone is: 4 weeks of stabilization and release.
Project Time Management
Time management is at the discretion and using the processes of the respective group.
Risks will be recorded in the Engineering Sync meeting minutes.
Action Items and Major Issues Tracking
Action Items and Issues will be tracked on the Engineering Sync meeting minutes. Action Items and Issues will be reviewed and updated at a minimum of weekly.
The software configuration management system used will be GIT. All electronic project documentation, including all schedules, will be stored in the Yocto Project Wiki at https://wiki.yoctoproject.org/wiki/Main_Page.
Any material changes to the commitments made in the PRD require an agreement by the Change Control Board.
Project Meetings and Reviews
The following project meetings and reviews will be held:
|Engineering Sync||Project maintainers and technical leads , Yocto Project Architect, Engineering Manager, Program Manager||Weekly|
|F2F Milestone meetings||Project maintainers and technical leads , Yocto Project Architect, Engineering Manager, Program Manager||Every quarter (~3 months)|
|Steering Group||See section 6.1.2||Bi-weekly (on IRC)|
|Yocto Project CCB||Appointed by Yocto Project Architect||As needed|
The status of the Yocto Project will be reported through the weekly Engineering Sync meeting.