12
The State of OpenStack Product Management Carol Barrett – Intel Shamail Tahir – IBM August 24, 2016 All product and company names are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.

The State of OpenStack Product Management

  • Upload
    tesora

  • View
    92

  • Download
    0

Embed Size (px)

Citation preview

Page 1: The State of OpenStack Product Management

The State of OpenStackProduct Management

Carol Barrett – Intel Shamail Tahir – IBMAugust 24, 2016

All product and company names are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.

Page 2: The State of OpenStack Product Management

2

Meet The Product Work Group• Formed at the Paris Summit (2014)• To improve the quality of the delivery process, the delivered product, and the product

experience for operators and end users, by:• Gathering Requirements• Creating common User Stories• Teaming-up with project teams to create and implement specs/blueprints• Generating a multi-release Community roadmap

• Consists of product managers, technologists, operators and end-users from a diverse set of organizations and industries

Page 3: The State of OpenStack Product Management

3

Analyze

Design

Implementation & Test

Document

Maintain, then Deprecate

Product Lifecycle Model

Page 4: The State of OpenStack Product Management

4

Requirements Vary By Perspective

DIY

Distribution

Managed Private Cloud

Public Cloud

Enterprise

Telco

HPC

Frequency of releases

Capacity Management

Prefer more frequent releases; upgrades are not an issue and prefer getting new features/fixes faster

Fine with either slower or faster releases

Prefer less frequent releases due to upgrade processes

Prefer more frequent releases; upgrades are not an issue and prefer getting new features/fixes faster

Desired but not priority; not seen as blocker

Desired but not priority; relevant but have more focus on monitoring/troubleshooting currently

High priority item; one of the 4 top priorities outlined by the Scientific WG

Consumption Models

Market Segments

Page 5: The State of OpenStack Product Management

5

Collecting Requirements

LargeDeployments

Telco

Academic/Scientific

Monitoring

Upgrades

APIs

Ecosystem

OpenStackProjects

IndustryExperts

Enterprise

Logging Operators Meetups

OpenStackSummits

MarketSegments

Capabilities

Experts

Gathering requirements from WGs, Operators and others• User Story template fields includes:

• Problem Definition• Use Cases (using Personas)• Usage Scenario Examples• Requirements

Do we have your requirements?

Page 6: The State of OpenStack Product Management

6

User Story CreationMarket

Segments

Capabilities

Experts

UserStories

Gathering requirements from WGs, Operators and others Creating common User Stories

Viewable Here

Proposed User Story

Concept ValidationTemplate Check

Dashboard for Community

User Story Tracker

• Rolling Upgrades• HA VM• Bare Metal Service• Capacity Management• Fleet Management

Priority User Stories

Reviewable Here

Are your use cases included?

HA VM

RollingUpgrades

CapacityManagement

LargeDeployments

Telco

Academic/Scientific

Monitoring

Upgrades

APIs

Ecosystem

OpenStackProjects

IndustryExperts

Enterprise

Logging Operators Meetups

OpenStackSummits

Page 7: The State of OpenStack Product Management

7

Implementing User Stories

• Assess gaps and overlaps• Define implementation plan and stakeholders• Integrate with Community development work flow • PWG User Story owner tracks and reports progress

Implementation Plan

Blueprints

Specs

Code/Status

Gap and Overlap Analysis

Cross Project Spec

Cross Project Discussions

New Project

1 or more actions

IRC meeting in #openstack-cp

HAVM

Gathering requirements from WGs, Operators and others Creating common User Stories Teaming-up with project teams to create and implement

specs/blueprints

Page 8: The State of OpenStack Product Management

8

Community Roadmap

* Some projects that are deemed essential but don’t have adoption data are also included (e.g. Oslo, QA, etc.)

• Provides forward-facing information on direction for over 25 projects*

• Roadmap information updated twice per release cycle

• Views present information by themes

Form Design Series Team

ConductVideo

Interviews

Build Slides,

Validate & Publish

Gathering requirements from WGs, Operators and others

Creating common User Stories Teaming-up with project teams to create and

implement specs/blueprints Generating a multi-release Community

Roadmap

Interview PTLs

Identify Project

List

Form Team

Generate 100’,

1K, 10K Views

Validate &

PublishCommunity Roadmap

Newton Design Series

Are the projects and information you need included?

Page 9: The State of OpenStack Product Management

9

Community Roadmap ExamplesNewton Design Series

Page 10: The State of OpenStack Product Management

10

Wrap-up• Our Community wants and values your input

• Together we can develop the best solutions• There are many ways to get involved

• Bring your requirements to the Community• Review and help improve User Stories• Join the Roadmap team to shape which Projects are included

• Keep an eye out for us in Barcelona• Roadmap session• Work Group session

Wiki PageMeeting Info and Logs

Page 11: The State of OpenStack Product Management

Thank You

Page 12: The State of OpenStack Product Management

12

Product Lifecycle Model: OpenStack Style

Shamail

AnalyzeA need is identified based on customer feedback, direct ops feedback, bug reports, or user stories.

DesignA spec (or cross project spec) is created that includes the use case, feature design details, and how it will be implemented. A blueprint may also be created depending on the project.

Implementation/TestDevelopers implement the feature and the code is reviewed by peers in Gerrit. Tempest tests are also created (if applicable) for unit testing and CI (continuous integration) tests also occur to ensure the change does not break the service.

DocumentThe new feature or enhancements are documented in the relevant docs (devref, user, admin, etc.)

MaintainBug fixes and critical fixes (including security) are resolved for impacted features/capabilities.

DeprecateOnce a capability has been superseded, or is no longer required, a depreciation plan is created and implemented by the development team.