The Microsoft Software Development Process. Scott Guthrie Program Manager Microsoft Corporation

(1)

The Microsoft Software

Development Process

Scott Guthrie

Program Manager

Microsoft Corporation

(2)

“Natural” Phases of a

Software Project

v v EnthusiasmEnthusiasm v v DisillusionmentDisillusionment v v PanicPanic v

v Search for the GuiltySearch for the Guilty

v

v Punishment of the InnocentPunishment of the Innocent

v

(3)

Successful Projects

v

v Not all software projects have toNot all software projects have to progress this way!

progress this way!

v

v Those that are successful typicallyThose that are successful typically

share three outstanding characteristics: share three outstanding characteristics:

À À PeoplePeople À À PoisePoise À À ProcessProcess

(4)

Today’s Agenda:

The Microsoft Development Process

v

v Origin of a MS ProductOrigin of a MS Product

v

v The Product TeamThe Product Team

v

v Designing the ProductDesigning the Product

v

v Scheduling the ProductScheduling the Product

v

v Implementing the ProductImplementing the Product

v

v Testing the ProductTesting the Product

v

(5)

Origin of a MS Product

(6)

How to Start a MS Product

v

v Step 1: Identify market opportunityStep 1: Identify market opportunity

À

À Customers, Competitors, Market DynamicsCustomers, Competitors, Market Dynamics

v

v Step 2: Determine viability of market entryStep 2: Determine viability of market entry

À

À Volume, price/cost margins, fixed costs, etc.Volume, price/cost margins, fixed costs, etc.

v

v Step 3: Define vision statementStep 3: Define vision statement

À

À Crisp enunciation of goals + issue ownershipCrisp enunciation of goals + issue ownership

À

À Explain strategic importance to companyExplain strategic importance to company

v

(7)

The Product Team

(8)

The Product Team

Product Unit Manager

Group Program Manager

Dev Manager Test Manager

Dev Lead Dev Lead Test Lead Test Lead PM Lead PM Lead Dev Dev PM PM Tester Tester

(9)

Designing the Product

(10)

Product Design

v

v Thoroughly understand your customersThoroughly understand your customers

À

À How do they work? What do they really do?How do they work? What do they really do?

À

À Visit, observe, listen & meticulouslyVisit, observe, listen & meticulously documentdocument

v

v Thoroughly understand your competitorsThoroughly understand your competitors

À

À Evaluate their product strengths/weaknesses?Evaluate their product strengths/weaknesses?

v

v Identify the Identify the strategicstrategic and and tacticaltactical themes themes and requirements that your features

and requirements that your features should be thinking about

should be thinking about

À

(11)

Feature Design

v

v Drill down on feature specificsDrill down on feature specifics

À

À Focus on “what it does” Focus on “what it does” vsvs. “how we build it”. “how we build it”

v

v Questions to consider:Questions to consider:

À

À How do we make a feature usable/simple?How do we make a feature usable/simple?

À

À How do we make a feature visible?How do we make a feature visible?

À

À How do we integrate other parts of a product?How do we integrate other parts of a product?

v

v Document scenarios, assumptions andDocument scenarios, assumptions and design proposal in a detailed spec

design proposal in a detailed spec

À

(12)

Implementation Issues

v

v Developers own thinking through theDevelopers own thinking through the implementation issues of a feature

implementation issues of a feature

v

v Questions to consider:Questions to consider:

À

À How factorable is the feature?How factorable is the feature?

À

À Can the feature be delivered in stages?Can the feature be delivered in stages?

À

À What dependencies does it have?What dependencies does it have?

À

À What other features are dependent on it?What other features are dependent on it?

À

(13)

Scheduling the Product

(14)

Scheduling/Planning

v

v Schedules are done after the initial designSchedules are done after the initial design document is ready for review

document is ready for review

v

v There is an inherit tension between theThere is an inherit tension between the schedule and the design document

schedule and the design document

À

À Each needs to be constantly re-evaluated andEach needs to be constantly re-evaluated and re-calibrated against the other

re-calibrated against the other

v

v Software scheduling in general isSoftware scheduling in general is something of an imprecise science something of an imprecise science

À

(15)

Scheduling Questions

v

v Is the ship date driven by features or aIs the ship date driven by features or a hard schedule?

hard schedule?

v

v Can/should the product vision be stagedCan/should the product vision be staged over multiple product releases?

over multiple product releases?

v

v How long has the product team workedHow long has the product team worked together? What size will it be?

together? What size will it be?

À

À Big != Good. Keep in mind the N-1 rule...Big != Good. Keep in mind the N-1 rule...

v

v Will the team be working at a normal paceWill the team be working at a normal pace or in “Death-March” mode?

(16)

Milestones

v

v Milestones are used to logically segmentMilestones are used to logically segment development into 9-12 week periods

development into 9-12 week periods

À

À Early Milestones: Critical features & core codeEarly Milestones: Critical features & core code

À

À Later Milestones: Functionality that can be cutLater Milestones: Functionality that can be cut

v

v Milestones help maintain “ship-mode”Milestones help maintain “ship-mode” focus/atmosphere over long projects focus/atmosphere over long projects

v

v Milestones encourage staging of productsMilestones encourage staging of products

À

À Enable review of progress (“Postmortems”)Enable review of progress (“Postmortems”)

À

(17)

Rules for Picking Dates

v

v Whatever date you publish will be theWhatever date you publish will be the earliest

earliest you possibly ship you possibly ship

À

À Date should be aggressive Date should be aggressive andand realistic realistic

v

v Budget vacations and sick-leaveBudget vacations and sick-leave

v

v Plan for unexpected absencesPlan for unexpected absences

À

À maternity/paternity leavematernity/paternity leave

v

v Pad schedule for stabilization and non-Pad schedule for stabilization and non-deterministic progress delays

(18)

Implementing the Product

(19)

Establish Best Practices

v

v Source code managementSource code management

À

À Whatever happened to Microsoft Pascal?Whatever happened to Microsoft Pascal?

v

v Coding StandardsCoding Standards

À

À What dialect of Hungarian do you use?What dialect of Hungarian do you use?

v

v Code ReviewsCode Reviews

À

À Every line of code should be peer reviewedEvery line of code should be peer reviewed

v

v Localization GuidelinesLocalization Guidelines

À

(20)

First Implementation Steps

v

v Define overall code-base structure:Define overall code-base structure:

À

À Specify directory hierarchy (headers, Specify directory hierarchy (headers, libslibs, etc.), etc.)

À

À Setup Setup MakefileMakefile and build environment and build environment

À

À Come up with common Macros andCome up with common Macros and Ifdefs Ifdefs

v

v Define overall code-base architecture:Define overall code-base architecture:

À

(21)

Builds

v

v Products are compiled and released dailyProducts are compiled and released daily

À

À Forcing factor for code interoperationForcing factor for code interoperation

À

À Provides steady progress measurementProvides steady progress measurement

À

À Enables daily test coverage of entire productEnables daily test coverage of entire product

v

v Builds can often take a long time…Builds can often take a long time…

À

À “Clean Build” of Windows NT takes 36 hours“Clean Build” of Windows NT takes 36 hours

v

v It is critical that delays are minimizedIt is critical that delays are minimized

À

(22)

Check-in Procedures

v

v Step 1: Finish writing codeStep 1: Finish writing code

v

v Step 2: Code review with a team memberStep 2: Code review with a team member

v

v Step 3: “Buddy build” on 2 clean systemsStep 3: “Buddy build” on 2 clean systems

v

v Step 4: Send “check-in request” mail to theStep 4: Send “check-in request” mail to the Build Technician and daily “Build

Build Technician and daily “Build MeisterMeister””

v

v Step 5: If check-in is approved, the buildStep 5: If check-in is approved, the build technician will check-out appropriate files technician will check-out appropriate files into the build tree

(23)

Build Problems

v

v Build Breaks (compile/linking error)Build Breaks (compile/linking error)

À

À Basically means some bozo screwed upBasically means some bozo screwed up

À

À Punishment should fit the crime… :-)Punishment should fit the crime… :-)

v

v Build Verification Test (BVT) FailuresBuild Verification Test (BVT) Failures

À

À Automated test indicates functionality failureAutomated test indicates functionality failure

v

v Each build classified at release:Each build classified at release:

À

À “Self Host”“Self Host”

À

À “Self Test”“Self Test”

À

(24)

Ensuring Product Quality

(25)

Software Testing

v

v Testing is critical to software developmentTesting is critical to software development

À

À Must be analytical, methodical and thoroughMust be analytical, methodical and thorough

v

v Test plan documents must be developedTest plan documents must be developed before code is even written

before code is even written

v

v Automation is key to stabilizing a productAutomation is key to stabilizing a product

À

À Comprehensive code coverageComprehensive code coverage

À

À Enables quick verification of product healthEnables quick verification of product health

À

(26)

Bug Triage

v

v Discovered bugs are logged to a databaseDiscovered bugs are logged to a database

v

v Senior team members meet at least once aSenior team members meet at least once a day to review/rank active bugs

day to review/rank active bugs

v

v Bugs assigned severity, priority, ownerBugs assigned severity, priority, owner

À

À Must-fix bugs marked as “showstoppers”Must-fix bugs marked as “showstoppers”

v

v “Scrubbing” the bug list“Scrubbing” the bug list

À

À Process of upgrading bugs to future releasesProcess of upgrading bugs to future releases

À

(27)

Getting It Out The Door

(28)

The End Game

v

v Alpha ReleaseAlpha Release

v

v Beta1 ReleaseBeta1 Release

v

v Code CompleteCode Complete

v

v Beta2 ReleaseBeta2 Release

v

v Zero Bug-BounceZero Bug-Bounce

v

v Release Candidate (RC)Release Candidate (RC)

v

(29)

End Game Responsibilities

v

v Program Management: Ensure that allProgram Management: Ensure that all scenarios documented in design spec scenarios documented in design spec are fully operational.

are fully operational.

v

v Test: Ensure that all featuresTest: Ensure that all features

implemented are at 0 showstoppers. implemented are at 0 showstoppers.

v

v Development: Resolve critical bugs asDevelopment: Resolve critical bugs as they appear. Ensure that the build

they appear. Ensure that the build remains stable

(30)

The End

v

v Once the build hits zero showstoppers, itOnce the build hits zero showstoppers, it will be “escrowed” while the team spends will be “escrowed” while the team spends

several days verifying that no new nasty several days verifying that no new nasty

bugs are lurking. bugs are lurking.

v

v If no new showstopper bugs are identified,If no new showstopper bugs are identified, a “master” or “golden” CD will be burned a “master” or “golden” CD will be burned

with the product bits. with the product bits.

v

v The CD will then be released to aThe CD will then be released to a

manufacturing factory where manufacturing factory where shrink-wrapped products will be produced. wrapped products will be produced.

(31)