1 msf: microsoft solutions framework. 2 agenda introduction msf team model msf process model msf...

96
1 MSF: Microsoft Solutions Framework

Upload: lorraine-white

Post on 25-Dec-2015

250 views

Category:

Documents


3 download

TRANSCRIPT

1

MSF: Microsoft Solutions Framework

2

Agenda

Introduction MSF Team Model MSF Process Model MSF Project Management Discipline MSF Risk Management Discipline MSF Readiness Management Discipline

3

What Is the MSF

Guidance to help organizations be more successful delivering IT Solutions

A collection of principles, processes and best practices grouped into “Models & Disciplines”

Framework for project management Team Model Process Model Risk Management

A “Framework” Can be used in place of a method Integrates well with existing processes and procedures

Can be combined with methods MSF is a platform for reducing risk Pieces of the framework are often useful no matter the situation… look for

the best practices Use to identify gaps in existing processes or methods

4

What’s a Framework?

Unlike a methodology, a framework is a set of “tools” or best practices to choose from

Is that good? Yes, because it is easier to apply, more flexible and less restrictive Yes, because it combines well with methodologies

(Agile,RUP, Prince 2...) No, because you have to make choices

5

Framework: Supplementing Methodologies

1st Avenue Plu

m S

tree

t

Ora

ng

e S

tree

t

. .Smith River

2nd Avenue

3rd Avenue

4th Avenue

. .

.. .

S

MSF

.

EW

. .N

.

.. .A methodology applies specific directions to a known destination

A framework, like a compass, verifies progress and provides directional guidance

A framework is a methodology partner!

6

One IT Lifecycle – Multiple Perspectives

MicrosoftSolutions

Framework

CommonDisciplines

&Shared

Responsibility

MicrosoftOperationsFramework

EnterprisePerspective

SystemsPerspective

Pla

n

Build

Dep

loy

Operate

7

Origins of MSF

Microsoft Worldwide Products Groups

Microsoft Worldwide Products Groups

MicrosoftInformationTechnology

MicrosoftInformationTechnology

Microsoft Consulting

Services

Microsoft Consulting

Services

Microsoft Partners

Microsoft Partners

Best PracticesBest Practices Microsoft Solutions FrameworkMicrosoft Solutions Framework

Concepts

Principles

Models

Best Practices

• Development AND Deployment, not just Development

• Microsoft has a lot of experience in successful and failed projects and there is a lot to learn from them

8

MSF & MOF

Microsoft Solutions Framework Established in 1991, last major revisions in 1999 , 2003 Visual Studio 2005 Team System Software Development and Infrastructure Deployment

Microsoft Operations Framework Established in 1999 based on mature ITIL (IT Infrastructure

Library) Updated December 2002 Concentrates on management of IT operations

MSF is a vehicle for delivering Microsoft’s contributions to the software development community

Microsoft almost does not market MSF and they are not selling it, instead, they focus on making money using MSF

9

A Brief History

1994 1995 1997 1999 2002 1994 1995 1997 1999 2002 2005-06 2005-06

MS

F O

fferi

ng

MS

F O

fferi

ng

MSF MSF v1v1

21 Rules21 Rules

““DynamicDynamics”s”

SolutionsSolutionsDevDevDisciplineDiscipline(SDD)(SDD)

MSF v2MSF v2Principles of …Principles of …App Dev (PAD)App Dev (PAD)Infra Deploy (PID)Infra Deploy (PID)Ent Arch (PEA)Ent Arch (PEA)Comp Des (PCD)Comp Des (PCD)

MSF MSF v2.5v2.5

MSF v3MSF v3

EssentialsEssentials+ Exam+ Exam

CoreCoreAgileAgileCMMICMMI……

MSF v4MSF v4

10

MSFv4 Family TreeFrameworkFramework

MethodologyMethodology

MSF for MSF for Agile Agile

Software Software DevelopmeDevelopme

ntnt

MSF for MSF for CMMICMMI®®

Process Process ImprovemenImprovemen

tt

InfrastructInfrastructureure

MSFv4 CoreMSFv4 Core

Application Application DevelopmeDevelopme

ntnt

DisciplineDiscipline

ProductProduct(instantiated)(instantiated)

FamilyFamily

11

Content RelationshipMSFv4 MSFv4 “Core”“Core” DisciplineDiscipline

InfrastructurInfrastructuree

MSF for Agile MSF for Agile Software Software

DevelopmentDevelopment

MSF for CMMIMSF for CMMI®® Process Process

ImprovementImprovementProductProduct

Application Application DevelopmentDevelopment FamilyFamily

MSF v4MSF v4

MSF v3MSF v3

InfrastructureInfrastructureCMMICMMI

AgileAgile

12

Setting Expectations NOT

MSF does not solve all your problems MSF does not guarantee your project’s success

YES MSF increases your success percentage MSF tells you VERY early in the project life cycle that you are going

to fail (You can stop the project before it costs too much) MSF is easy to learn and implement

MSF is an “agile” process

13

Is It For Everyone?

Some parts of MSF will work for every project, but in

general, most of MSF works for larger projects How small is large enough? 3-12 months (best of all 4-6) and with a team of at least 3

(best of all 7-11) Or more, by using built-in team scaling tools, such as Feature

Teams

14

Where MSF Fits in the IT Life Cycle

Microsoft Operations Framework

Microsoft Solutions Framework

Operate

Dep

loy

Build

Pla

n

15

RiskManagement

Discipline

ProcessModel

TeamModel

ProjectManagement

Discipline

ReadinessManagement

Discipline

Key Parts of MSFModels

Disciplines

Getting Results Minimize Surprises Anticipate & Grow Skills

16

MSF Foundational Principles

17

Agenda

Introduction MSF Team Model MSF Process Model MSF Project Management Discipline MSF Risk Management Discipline MSF Readiness Management Discipline

18

Team Goals for Success Satisfied customers Delivery within project constraints Delivery to specifications that are

based on user requirements Release after addressing all known issues Enhanced user performance Smooth deployment and ongoing management

19

MSF Team Model

ProgramManagement

ProgramManagement

DevelopmentDevelopment

TestingTesting

ReleaseManagement

ReleaseManagement

UserExperience

UserExperience

ProductManagement

ProductManagement

Team of Peers

20

Why These 6 Roles? Key goals need dedicated equally valued roles:

Customer Satisfaction: Product Manager Project delivered within Project Constraints: Program Manager Design and Implementation Based on Specification: Development All Issues Known and Addressed: Testing Users Performing Better: User Experience Deployment, Admin, and Support: Release Management

21

MSF Team Model

22

MSF Team Model

23

MSF Team Model

Communication

Delivering the solution within project constraints

Satisfied customers

Enhanced user effectiveness

Smooth deployment and ongoing operations

Approval for release only after all quality issues are identified and addressed

Building to specification

Program Management

Development

Test

Release Management

User Experience

Product Management

24

Team of Peers

Is a team whose members relate as equals Has specific roles and responsibilities for each member Empowers individuals in their roles Holds members accountable for the success of their roles Drives consensus-based decision-making Gives all team members a stake in the success of the

project

25

Product Manager

Acts as customer advocate to the Team Drives shared project vision/scope Manages customer requirements definition Develops and maintains business case Manages customer expectations Drives features vs. schedule vs. resources tradeoff

decisions Manages marketing, evangelizing and public relations Develops, maintains, and executes the communications

plan

26

Program Manager

Drives development process to ship product on time Manages product specification—primary project architect Facilitates communication and negotiation within the team Maintains the project schedule and reports project status Drives implementation of critical trade-off decisions Develops, maintains, and executes the project master plan

and schedule Drives and manages risk assessment and risk management

27

Development Role

Specifies the features of physical design Estimates time and effort to complete each feature Builds or supervises building of features Prepares product for deployment Provides technology subject matter expertise to the team

28

Test Role

29

User Experience Role

30

Release Management Role

31

Roles & Responsibilities

32

Principles of a Successful Team

Shared project vision Product mindset Zero-defect mindset Customer-focused mindset Willingness to learn

33

Fixed-Ship-Date Mindset A fixed-ship date mindset means that a team treats its projected ship date

as unchangeable Essentially the schedule side of the triangle is considered fixed The team cannot use this side of the triangle for making corrective decisions unless no other

option is available. Forces creativity by requiring the team to implement features in as

timely a manner as possible and removing the option of delaying the ship date

Prioritizes tasks according to importance -- If the team needs to drop features in order to make the ship date, it delivers those most important to the customer)

Empowers the team by providing an effective decision-making tool -- The team makes decisions on the basis of how they will affect the team’s ability to deliver on the fixed ship date.

Provides a motivational goal for the team “There’s a thousand different variables that go into shipping a product, the feature

sets, the people working on it, how long they’re working, a bunch of stuff. All we’re trying to do is fix one of them, just one. Of all the thousand variables, let’s just fix one variable and let’s vary the other 999 variables. When you fix the ship date, you force creativity, you force decisions.”

34

Principles of a Successful Team

35

Combining Roles for Small Projects

ProgramManagement

ProgramManagement DevelopmentDevelopment TestTest Release

ManagementRelease

ManagementUser

ExperienceUser

ExperienceProduct

ManagementProduct

Management

ProgramManagement

ProgramManagement

DevelopmentDevelopment

TestTest

ReleaseManagement

ReleaseManagement

ProductManagement

ProductManagement

P

P

P

P

P

P P

P P

P

P

P

P

P

P

P P

P P

P

U

U

UU

U

U

U

U

U

U

UU

U

U

U

U

N

N

N

N N

N

N

N

N

N N NN

N

N

N N

N

N

N

N

N N N

UserExperience

UserExperience

P = Possible U = Unlikely N = Not Recommended

36

ProductManagement

ProductManagement

Teams: Scaling Down

ProgramManagement

ProgramManagement DevelopmentDevelopment

TestingTesting

ReleaseManagement

ReleaseManagement

UserExperience

UserExperience

37

Scaling for Large Projects

Divide large teams into smaller teams, which have Lower process overhead Lower management overhead Lower communication overhead Faster implementation

Create feature teams—multidisciplinary subteams organized around product feature sets

Create function teams—unidisciplinary subteams organized by functional roles

38

Feature TeamsMultidisciplinary sub-teams organized around product feature sets or created to focus on a particular capability

ProgramManagement

ProgramManagement

ReleaseManagement

ReleaseManagement

ProductManagement

ProductManagement

UserExperience

UserExperience

DevelopmentDevelopment

TestTest

Lead Team

DesktopFeatureTeam

ProgramManagement

ProgramManagement

UserExperience

UserExperience

DevelopmentDevelopment

TestTest

File and Print FeatureTeam

ProgramManagement

ProgramManagement

UserExperience

UserExperience

DevelopmentDevelopment

TestTest

MessagingFeatureTeam

ProgramManagement

ProgramManagement

UserExperience

UserExperience

DevelopmentDevelopment

TestTest

39

Example: Function Team

Group ProductManagement

Evangelism

PublicRelations

Marketing

Product Planning

ProductManagement

ProductManagement

40

Functional Teams

Marketing

41

MSF Team Role Clusters and Their Functional Areas

Business valueMarketingCustomer advocacyProduct planning

Project managementSolution architectureProcess assuranceAdministrative services

Technology consultingImplementation architecture and designApplication developmentInfrastructure development

Test planningTest engineeringTest reporting

InfrastructureSupportOperationsLogisticsCommercial release management

AccessibilityInternationalizationUser advocacyTraining/support materialUsability research and testingUser interface design

DevelopmentDevelopment

TestTest

Release Management

Release Management

UserExperience

UserExperience

ProductManagement

ProductManagement

Program Management

Program Management

42

Agenda

Introduction MSF Team Model MSF Process Model MSF Project Management Discipline MSF Risk Management Discipline MSF Readiness Management Discipline

43

MSF Process Model

Project Plans Approved

Scope Complete

Release ReadinessApproved

DeploymentComplete

Vision/Scope Approved

MSF

44

MSF Process Principles and Practices Using versioned releases Scheduling for an uncertain future Managing trade-offs Maintaining a fixed-ship-date mindset Managing risk Breaking large projects into manageable parts Driving process with milestones Using bottom-up and milestone-based estimating Performing daily builds Conducting post-project reviews

45

MSF Process Model Is an Iterative Approach

Time

Fu

nct

ion

alit

yMinimize risks by breaking large projects into multiple versions

Version 1

Version 2

Version 3

46

Why Versioned Releases You can’t effectively manage a project if it is longer than 6 months Most projects are longer then 6 months By deciding on versioned releases you can decide which subset of the problem is

fitted to the time The customer must prioritize the features The customer has something in hand earlier Mistakes discovered early are cheaper to fix Establish your credibility Give you flexibility in case of pressure

“We can move this feature to the next release” Enable you to better fit the solution to your precise customer’s needs

You respond faster to changes The delta between the specification and the real world is smaller

47

Envisioning Phase

Deliverables Vision/scope

document Project structure

document Initial risk

assessment document

48

Vision Components

49

Vision Components

50

Planning Phase

Deliverables: Functional

specifications Master project

plan Master project

schedule

51

Planning Components

52

53

Developing Phase

Deliverables: Solution code Build images Training materials Documentation

Deployment processes Operational procedures Support and troubleshooting

Marketing materials Updated master plan and schedule

54

Developing Components

55

Developing Phase

56

Zero Defect Mindset

57

Daily Build

58

Stabilizing Phase

Deliverables: Pilot review Release-ready versions:

Source code andexecutables

Scripts and installation documentation

End-user help and training materials

Operations documentation Release notes

Testing and bug reports Project documents

59

Stabilizing Components

60

Bug Convergence

61

MSF

Testing the SolutionTesting is part of the build cycle, not a standalone activity

Release ReadinessApproved

ScopeComplete

Project PlansApproved

62

Team Focus During Stabilizing Phase

63

Deploying Phase

Deliverables Operations and

support informationsystems

Repository of allversions of docs,load sets, configs,scripts, and code

Project close-out report

64

Team Focus During Deploying Phase

65

MSF Phases and Milestones

Project Plans Approved

Scope Complete

Release ReadinessApproved

DeploymentComplete

Vision/Scope Approved

Pilot Complete

Pre-Production Testing Complete

Release Candidates

User Acceptance Testing Complete

Zero Bug Bounce

Bug Convergence

Technology Validation Complete

Functional Specifications Baselined

Master Project Plan Baselined

Master Project Schedule Baselined

Development/Test Environment Set Up

Deployment Stabilized

Site Deployments Complete

Core Technology Deployed

Core Team Organized

Vision/Scope Baselined

Proof of Concept CompleteInternal Release 1

Internal Release 2Internal Release n

66

Standard MSF Deliverables

I. Envisioning: “Vision Approved” Milestone Vision document Risk assessment Project structure document

II. Planning: “Scope Complete” Milestone Functional specification Risk assessment Project schedule Operation and support information systems

Procedures and processes Knowledge base, reports, logbooks

III. Developing: “Scope Complete” Milestone Frozen functional specification Risk management plan Source code and executables Performance support elements Test specification and test cases Master project plan and master project schedule

IV. Stabilizing: “Release” Milestone Golden release Release notes Performance support elements Test results and testing tools Source code and executables Project documents Milestone review

V. Deploying: “Deployment Complete” Milestone Documentation repository for all versions of

documents, load sets, and code developed during the project.

Project close-out report Final versions of all project documents Customer/user satisfaction data Definition of next steps

67

Envisioning Phase Planning Phase Developing Phase Stabilizing Phase Deploying Phase Overall goals Identify customer requirements Vision / scope document

Conceptual design Business requirements

analysis Communications plan

Customer expectations Communications plan execution

Launch planning

Customer feedback, assessment, signoff

Design goals Solution concept Project structure

Conceptual and logical design Functional specification Master project plan Master project schedule Budget

Functional specification management

Project tracking Plan updating

Project tracking Bug triage

Solution / scope comparison Stabilization management

Prototypes Development and technology

options Feasibility analysis

Technology evaluation Logical and physical design Development plan / schedule Development estimates

Code development Infrastructure development Configuration documentation

Bug resolution Code optimization

Problem resolution Escalation support

User Performance needs and implications

Usage scenarios / use cases User requirements Localization / accessibility

requirements User documentation, training

plans and schedules

Training Training plan updates Usability testing Graphic design

User documentation stabilization

Training materials

Training Training schedule

management

Testing approach Test acceptance criteria

Design evaluation Testing requirements Test plan and schedule

Functional testing Issues identification Documentation testing Updated test plan

Testing Bug reporting and status Configuration testing

Performance testing Problem resolution

Deployment implications Operations management and

supportability Operations acceptance criteria

Design evaluation Operations requirements Pilot and deployment plan and

schedule

Rollout checklists Rollout and pilot plan updates Site preparation checklists

Pilot setup and support Deployment planning Operations and support

training

Site deployment management Change approval

DevelopmentDevelopment

TestTest

Release Management

Release Management

UserExperience

UserExperience

ProductManagement

ProductManagement

Program Management

Program Management

68

Team Participation

69

Agenda

Introduction MSF Team Model MSF Process Model MSF Project Management Discipline MSF Risk Management Discipline MSF Readiness Management Discipline

70

Project Management

Full alignment with PMIBOK (Project Management Institute Body of Knowledge)

Remember: MSF is not a project management method, but a project framework that needs some project management – PMI is great for that

71

Project ManagementTeam leads for each role own the responsibilities corresponding to the listed knowledge areas

Team Leads

Program Management

Product Management

Development

Test

User Experience

Release Management

Quality M

anag

emen

t

Procurem

ent M

anag

emen

t

Risk M

anag

emen

t

Communicatio

ns Man

agem

ent

Human R

esource

Man

agem

ent

Cost M

anag

emen

t

Time M

anag

emen

t

Scope M

anag

emen

t

Integrat

ion Man

agem

ent

at overall project level at sub-team level

72

Specialization of Program Management

73

Making Project Trade-offs

Res

ourc

es

Res

ourc

esFeaturesFeatures

Schedule

ScheduleQuality

74

Why use Project Trade-offs?

Because you will have to It never goes according to plan Why bury your head in the sand? Why not discuss it with your customer? You will have to do it anyway so why wait for the first

crisis How can we do all this ??? …

75

Project Trade-off Matrix

ConstrainConstrainOptimizeOptimize AcceptAccept

ScheduleSchedule

FeaturesFeatures

ResourcesResources

Res

ourc

es

Res

ourc

es

FeaturesFeatures

Schedule

Schedule

Help your customer help you

• Constrain – do not change, this is a constant

• Optimize – try to minimize this

• Accept – well, I’ll except any changes on this

76

Milestone-Driven Process Milestones are review and synchronization points,

not freeze points Milestones enable the team (and customer) to assess progress and make

mid-course corrections The process model uses two sorts of milestones

Major milestones, end of logical quarter Interim milestones, in the logical quarter

Achieving interim milestone represents team agreement on position in the process

Achieving a major milestone represents team and customer agreement on position in the process

77

Milestones are based on Deliverables

Deliverables are physical evidence (documents) Deliverables are signed by the team (and sometimes the

customer) A signed (or agreed) deliverable signal that the team has

reached a milestone

78

Milestone MSF Role Cluster

Vision/scope approved Product management

Project plans approved Program management

Scope complete DevelopmentUser experience

Release readiness approved TestingRelease management

Deployment complete Release management

Different Roles Drive Different Phases

79

The process milestones based Approach

Segment the Project into milestones Help organize the team Facilitate communication in the team Facilitate communication with the customer YOU NEVER GET BLINDED YOU ALWAYS KNOW WHERE YOU ARE

80

Goals for a Successful Project Satisfied customers

The customer pays you, politics, seals person

Delivery within project constraints Watch the budget, deal with crises, mitigate

Delivery to specifications that are based on user requirements Write the code, take development decisions.

Release after addressing all known issues Test the code, specification, everything.

Enhanced user performance Most of the time, the customer doesn’t use the project. It’s the user of the system that make it a success or failure. (UI design,

Graphics, Cognitive approach)

Smooth deployment and ongoing management Packing, buying equipment, printing, delivering, electricity, water, air conditioning, logistics, etc’…

81

Overall success requires success in each goal Any of them may fail the project

It is straight from the root, because of the failure we discussed earlier Each goal must be equally valued Each goal requires disciplines that are focused on that goal Each goal needs different qualifications You need them all You can’t learn everything, you cant do everything, you cant be

everyone… So….

Understanding the Goals

82

Accountability

83

Agenda

Introduction MSF Team Model MSF Process Model MSF Project Management Discipline MSF Risk Management Discipline MSF Readiness Management Discipline

84

Risk Management Model Risk is a problem waiting to happen If you don’t analyze it, and prepare for it, you'll get it in you

face You should anticipate risks, mitigate risks and prepare

contingency plans for risks Because some of those risks are going to happen (it is just

statistics) Risk analyzing is integral, living, changing, part of any

project

85

Risk Considerations and Goals

Areas for consideration during risk assessment: Research. Do we know enough about this risk? Do we need to study the

risk further to acquire more information and better determine the characteristics of the risk before we can decide what action to take?

Accept. Can we live with the consequences if the risk were actually to occur? Can we accept the risk and take no further action?

Manage. Can the team do anything to mitigate the impact of the risk should the risk occur?

Avoid. Can we avoid the risk by changing the scope?

The three risk management goals are to: Reduce the probability of occurrence; Reduce the magnitude of loss; or Change the consequences of the risk.

86

MSF Risk Management Discipline

87

Analyze andPrioritize

Analyze andPrioritize

MasterRisk List

Top nRisks

Plan andSchedulePlan andSchedule

Identity

RiskStatement

ControlControl

The MSF Risk Management Process

LearnLearnRisk

Knowledge Base,Concepts,

and Processes

Track andReport

Track andReport

The ongoing deliverable of this process is a living risk assessment document

88

Agenda

Introduction MSF Team Model MSF Process Model MSF Project Management Discipline MSF Risk Management Discipline MSF Readiness Management Discipline

89

MSF Readiness Discipline

KnowledgeSkills

Abilities

AssessAssess

ChangeChange

DefineDefine

EvaluateEvaluate

90

Types Of Rediness

91

Types Of Readiness

92

Rediness Management Tasks

93

A few words about readiness

Readiness management is one of the least understood (and least implemented) practices– everybody claims that human resources are the most valuable capital, but virtually nobody invests in it

It is often unwise to rely on programmers’ self-assessment. Statement “5 years of Java experience” on a resume may actually refer to “5 years ago I read a book about Java”

Use certification exams for assessing team readiness. Lack of technical competence is more noticeable than lack of management

competence

94

Inheritance helps minimize bureaucracy

Option 1 Option 2

Total 64 pages

Total 34 pagesJava coding standard

C++ coding standard

C coding standard

Java coding standard

C++ coding standard

C coding standard

General style and coding standard

95

MSF Summary

Projects often fail for non-techy reasons A framework such as MSF fixes many of those problems You don’t have to use all of MSF at once If you use some bits you increase your chance of

succeeding

96

MOF Summary

“Enterprises operating a predominantly Microsoft environment should investigate MOF early. Enterprises in a heterogeneous environment should focus on ITIL and selectively pick best practices from MOF.”