"How we plan a cycle" (Mounir/JamieBennett)

Original Agenda

Discussion about how we plan a cycle from initial requirements gathering through blueprint creation and execution.

This discussion should help with the production of the presentation "How we plan a cycle" which will be circulated to the Linaro Team members and interested parties before Linaro@UDS.

Topics

  • Requirements gathering and the TSC.
  • What makes up a blueprint?
  • Specifications.
  • Pre UDS activities.
  • UDS discussions.
  • Post UDS activities.

Requirements Gathering

  • Linaro differs slightly from Ubuntu in requirements gathering. Traditionally with Ubuntu there are some hard requirements but there is room for engineers to decide on what they would like to do in their area of interest too. Also community items can be included. With Linaro the requirements are hard requirements decided by the TSC and upper management.
  • TSC made up of member companies and Linaro upper management.
  • Requirements are gathered into a Requirements Specification. This looks nothing like the blueprints and work items format we use for Engineering effort. Usually reference numbers, high level goals (even though they could go into quite technical detail), hard to measure completion of the requirements (subject to interpretation).
  • Area's of engineering that the Technical Requirements document concentrates on:
    • Tool Chain
      • Core Tool Chain
      • Performance
      • Debug
    • Kernel Consolidation
      • Boot
      • Kernel
      • Performance
    • Power Management
    • Emulation
    • Middleware
      • General
      • Graphics
      • Multimedia
      • Web 2.0
      • System Services
    • Platforms and Infrastructure
      • Heads
      • Tools

Each of these area's will have their own requirements.

Blueprints

  • Blueprints are Linaro's way of capturing work to be done.
  • Blueprints can have other blueprint dependancies. This way

Stages of creating a blueprint for a cycle

Pre Linaro@UDS

  • Create the blueprint in the appropriate project.
    • Core engineering from Linaro Foundations, User Platforms and Infrastructure should be created in the Linaro project.
    • Working group blueprints should be created in their own working group project.
  • Set Priority according to the priority of the technical requirement that the blueprint fulfils.
  • Set Definition to drafting and Implementation to not started.
  • Set Series Goal to the correct current series.
  • Set Approver to your manager.
  • Set Drafter to whoever is responsible for creating the specification that accompanies the blueprint.
  • Set Assignee to who ever will be implementing the blueprint or if not the implementor, whoever is responsible for the blueprint.
  • Set Milestone Target to the milestone where the blueprint is expected to be completed.
  • Create a specification for the blueprint. Just under the description for the blueprint, there is a button to create a link to another page where the specification can be written. Set this to http://wiki.linaro.org/Platform/team-name/Specs/specname for a Foundations/User Platforms/Infrastructure blueprint or http://wiki.linaro.org/WorkingGroups/working-group/Specs/specname for the working groups.

Linaro@UDS

  • Each blueprint, where appropriate, will have a session assigned to it for discussion at Linaro@UDS.
  • Be well prepared for the session and beforehand, plan what you would like to get out of the session.
  • Notes should be take for each session and put in the correct section of the specification wiki page. Please do this as soon as possible after the session.

Post Linaro@UDS

  • If necessary, the specification is rewritten to take into consideration any discussions/decisions that were made at Linaro@UDS.
  • Use the whiteboard to add work items of 2 days or less. Use the correct syntax to align the individual items to milestones for the project. This helps greatly with tracking.
  • Please see https://wiki.linaro.org/Process/WorkItemsHowto for information on how to create good work items.

  • Set Definition to review.
  • Ask for feedback from your manager or any party who could give good input. Use the Request feedback link on the blueprint to track this.
  • Once approved set the Definition to approved.

JamieBennett/MeetingNotes/2010-09-07 (last modified 2010-09-07 11:52:58)