SLIDE 1
The Microsoft Software The Microsoft Software Development Process Development Process
Scott Guthrie Scott Guthrie Program Manager Program Manager Microsoft Corporation Microsoft Corporation
SLIDE 2 “Natural” Phases of a “Natural” Phases of a Software Project Software Project
Enthusiasm
Disillusionment
Panic
Search for the Guilty
- Punishment of the Innocent
Punishment of the Innocent
- Praise and Honors for Non-Participants
Praise and Honors for Non-Participants
SLIDE 3 Successful Projects Successful Projects
- Not all software projects have to
Not all software projects have to progress this way! progress this way!
- Those that are successful typically
Those that are successful typically share three outstanding characteristics: share three outstanding characteristics:
People
Poise
Process
SLIDE 4 Today’s Agenda: Today’s Agenda:
The Microsoft Development Process The Microsoft Development Process
Origin of a MS Product
The Product Team
Designing the Product
Scheduling the Product
Implementing the Product
Testing the Product
Shipping the Product
SLIDE 5
Origin of a MS Product Origin of a MS Product
SLIDE 6 How to Start a MS Product How to Start a MS Product
- Step 1: Identify market opportunity
Step 1: Identify market opportunity
- Customers, Competitors, Market Dynamics
Customers, Competitors, Market Dynamics
- Step 2: Determine viability of market entry
Step 2: Determine viability of market entry
- Volume, price/cost margins, fixed costs, etc.
Volume, price/cost margins, fixed costs, etc.
- Step 3: Define vision statement
Step 3: Define vision statement
- Crisp enunciation of goals + issue ownership
Crisp enunciation of goals + issue ownership
- Explain strategic importance to company
Explain strategic importance to company
- Step 4: Make a lot of noise!
Step 4: Make a lot of noise!
SLIDE 7
The Product Team The Product Team
SLIDE 8 The Product Team 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
SLIDE 9
Designing the Product Designing the Product
SLIDE 10 Product Design Product Design
- Thoroughly understand your customers
Thoroughly understand your customers
- How do they work? What do they really do?
How do they work? What do they really do?
- Visit, observe, listen & meticulously
Visit, observe, listen & meticulously document document
- Thoroughly understand your competitors
Thoroughly understand your competitors
- Evaluate their product strengths/weaknesses?
Evaluate their product strengths/weaknesses?
Identify the strategic strategic and and tactical tactical themes themes and requirements that your features and requirements that your features should be thinking about should be thinking about
- Ensure that they are inline w/ vision statement
Ensure that they are inline w/ vision statement
SLIDE 11 Feature Design Feature Design
- Drill down on feature specifics
Drill down on feature specifics
Focus on “what it does” vs
. “how we build it”
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?
- Document scenarios, assumptions and
Document scenarios, assumptions and design proposal in a detailed spec design proposal in a detailed spec
- Maintain tight feedback/evaluation loop
Maintain tight feedback/evaluation loop
SLIDE 12 Implementation Issues Implementation Issues
- Developers own thinking through the
Developers own thinking through the implementation issues of a feature implementation issues of a feature
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?
- How many developer weeks are required?
How many developer weeks are required?
SLIDE 13
Scheduling the Product Scheduling the Product
SLIDE 14 Scheduling/Planning Scheduling/Planning
- Schedules are done after the initial design
Schedules are done after the initial design document is ready for review document is ready for review
- There is an inherit tension between the
There is an inherit tension between the schedule and the design document schedule and the design document
- Each needs to be constantly re-evaluated and
Each needs to be constantly re-evaluated and re-calibrated against the other re-calibrated against the other
- Software scheduling in general is
Software scheduling in general is something of an imprecise science something of an imprecise science
- Concatenation of educated guesses
Concatenation of educated guesses
SLIDE 15 Scheduling Questions Scheduling Questions
- Is the ship date driven by features or a
Is the ship date driven by features or a hard schedule? hard schedule?
- Can/should the product vision be staged
Can/should the product vision be staged
- ver multiple product releases?
- ver multiple product releases?
- How long has the product team worked
How 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...
- Will the team be working at a normal pace
Will the team be working at a normal pace
- r in “Death-March” mode?
- r in “Death-March” mode?
SLIDE 16 Milestones Milestones
- Milestones are used to logically segment
Milestones are used to logically segment development into 9-12 week periods development into 9-12 week periods
- Early Milestones: Critical features & core code
Early Milestones: Critical features & core code
- Later Milestones: Functionality that can be cut
Later Milestones: Functionality that can be cut
- Milestones help maintain “ship-mode”
Milestones help maintain “ship-mode” focus/atmosphere over long projects focus/atmosphere over long projects
- Milestones encourage staging of products
Milestones encourage staging of products
- Enable review of progress (“Postmortems”)
Enable review of progress (“Postmortems”)
- Facilitate corrections to master schedule
Facilitate corrections to master schedule
SLIDE 17 Rules for Picking Dates Rules for Picking Dates
- Whatever date you publish will be the
Whatever date you publish will be the earliest earliest you possibly ship you possibly ship
- Date should be aggressive
Date should be aggressive and and realistic realistic
- Budget vacations and sick-leave
Budget vacations and sick-leave
- Plan for unexpected absences
Plan for unexpected absences
- maternity/paternity leave
maternity/paternity leave
- Pad schedule for stabilization and non-
Pad schedule for stabilization and non- deterministic progress delays deterministic progress delays
SLIDE 18
Implementing the Product Implementing the Product
SLIDE 19 Establish Best Practices Establish Best Practices
Source code management
- Whatever happened to Microsoft Pascal?
Whatever happened to Microsoft Pascal?
Coding Standards
- What dialect of Hungarian do you use?
What dialect of Hungarian do you use?
Code Reviews
- Every line of code should be peer reviewed
Every line of code should be peer reviewed
Localization Guidelines
- If you plan ahead it is money in the bank…
If you plan ahead it is money in the bank…
SLIDE 20 First Implementation Steps First Implementation Steps
- Define overall code-base structure:
Define overall code-base structure:
- Specify directory hierarchy (headers,
Specify directory hierarchy (headers, libs libs, etc.) , etc.)
Setup Makefile Makefile and build environment and build environment
- Come up with common Macros and
Come up with common Macros and Ifdefs Ifdefs
- Define overall code-base architecture:
Define overall code-base architecture:
- Design core APIs, interfaces and structures
Design core APIs, interfaces and structures
SLIDE 21 Builds Builds
- Products are compiled and released daily
Products are compiled and released daily
- Forcing factor for code interoperation
Forcing factor for code interoperation
- Provides steady progress measurement
Provides steady progress measurement
- Enables daily test coverage of entire product
Enables daily test coverage of entire product
- 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
- It is critical that delays are minimized
It is critical that delays are minimized
- Strict check-in procedures typically enforced
Strict check-in procedures typically enforced
SLIDE 22 Check-in Procedures Check-in Procedures
- Step 1: Finish writing code
Step 1: Finish writing code
- Step 2: Code review with a team member
Step 2: Code review with a team member
- Step 3: “Buddy build” on 2 clean systems
Step 3: “Buddy build” on 2 clean systems
- Step 4: Send “check-in request” mail to the
Step 4: Send “check-in request” mail to the Build Technician and daily “Build Build Technician and daily “Build Meister Meister” ”
- Step 5: If check-in is approved, the build
Step 5: If check-in is approved, the build technician will check-out appropriate files technician will check-out appropriate files into the build tree into the build tree
SLIDE 23 Build Problems Build Problems
- Build Breaks (compile/linking error)
Build Breaks (compile/linking error)
- Basically means some bozo screwed up
Basically means some bozo screwed up
- Punishment should fit the crime… :-)
Punishment should fit the crime… :-)
- Build Verification Test (BVT) Failures
Build Verification Test (BVT) Failures
- Automated test indicates functionality failure
Automated test indicates functionality failure
- Each build classified at release:
Each build classified at release:
“Self Host”
“Self Test”
“Self Toast”
SLIDE 24
Ensuring Product Quality Ensuring Product Quality
SLIDE 25 Software Testing Software Testing
- Testing is critical to software development
Testing is critical to software development
- Must be analytical, methodical and thorough
Must be analytical, methodical and thorough
- Test plan documents must be developed
Test plan documents must be developed before code is even written before code is even written
- Automation is key to stabilizing a product
Automation is key to stabilizing a product
- Comprehensive code coverage
Comprehensive code coverage
- Enables quick verification of product health
Enables quick verification of product health
- Enables easy reproducibility of errors
Enables easy reproducibility of errors
SLIDE 26 Bug Triage Bug Triage
- Discovered bugs are logged to a database
Discovered bugs are logged to a database
- Senior team members meet at least once a
Senior team members meet at least once a day to review/rank active bugs day to review/rank active bugs
- Bugs assigned severity, priority, owner
Bugs assigned severity, priority, owner
- Must-fix bugs marked as “showstoppers”
Must-fix bugs marked as “showstoppers”
“Scrubbing” the bug list
- Process of upgrading bugs to future releases
Process of upgrading bugs to future releases
- Done when a bug is just too dangerous to fix
Done when a bug is just too dangerous to fix
SLIDE 27
Getting It Out The Door Getting It Out The Door
SLIDE 28 The End Game The End Game
Alpha Release
Beta1 Release
Code Complete
Beta2 Release
Zero Bug-Bounce
Release Candidate (RC)
- Release to Manufacturing (RTM)
Release to Manufacturing (RTM)
SLIDE 29 End Game Responsibilities End Game Responsibilities
- Program Management: Ensure that all
Program Management: Ensure that all scenarios documented in design spec scenarios documented in design spec are fully operational. are fully operational.
- Test: Ensure that all features
Test: Ensure that all features implemented are at 0 showstoppers. implemented are at 0 showstoppers.
- Development: Resolve critical bugs as
Development: Resolve critical bugs as they appear. Ensure that the build they appear. Ensure that the build remains stable remains stable
SLIDE 30 The End The End
- Once the build hits zero showstoppers, it
Once 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.
- 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.
- The CD will then be released to a
The CD will then be released to a manufacturing factory where shrink- manufacturing factory where shrink- wrapped products will be produced. wrapped products will be produced.
SLIDE 31
