slide1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
DEV439 Visual Studio 2005 Team System and Microsoft Solution Framework: Implementing an Agile or CMMI Process PowerPoint Presentation
Download Presentation
DEV439 Visual Studio 2005 Team System and Microsoft Solution Framework: Implementing an Agile or CMMI Process

Loading in 2 Seconds...

play fullscreen
1 / 50

DEV439 Visual Studio 2005 Team System and Microsoft Solution Framework: Implementing an Agile or CMMI Process - PowerPoint PPT Presentation


  • 185 Views
  • Uploaded on

DEV439 Visual Studio 2005 Team System and Microsoft Solution Framework: Implementing an Agile or CMMI Process. Randy Miller Program Manager Microsoft Corporation. MSF for Agile Software Development Overview. Creating New Team Projects. Plan. Plan. Plan. Plan. Plan. Plan. Plan. Plan.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'DEV439 Visual Studio 2005 Team System and Microsoft Solution Framework: Implementing an Agile or CMMI Process' - norm


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide2

DEV439Visual Studio 2005 Team System and Microsoft Solution Framework: Implementing an Agile or CMMI Process

Randy Miller

Program Manager

Microsoft Corporation

agile methods

Plan

Plan

Plan

Plan

Plan

Plan

Plan

Plan

Analyze Design Build Test

Analyze Design Build Test

Analyze Design Build Test

Analyze Design Build Test

Analyze Design Build Test

Analyze Design Build Test

Analyze Design Build Test

Analyze Design Build Test

Analyze Design Build Test

Analyze Design Build Test

Analyze Design Build Test

Analyze Design Build Test

Analyze Design Build Test

Analyze Design Build Test

Analyze Design Build Test

Analyze Design Build Test

Analyze Design Build Test

Analyze Design Build Test

Analyze Design Build Test

Analyze Design Build Test

Analyze Design Build Test

Analyze Design Build Test

Analyze Design Build Test

Analyze Design Build Test

Release

Release

Release

Release

Release

Release

Release

Release

Agile Methods

Operative Principle

Change is inevitable, so plan for it by doing the most valuable work first and adjusting the plan.

Characteristics

Cycle typically takes 2 weeks to 2 months

Business value delivered iteratively & incrementally

Advantages

Business value realized early and often

Change is an accepted part of the process

Acceptance testing occurs during each cycle

Bugs identified much earlier in process

Whole team engaged throughout process

Decision to release to public is in business’ hands

Disadvantages

Early adopters often encounter resistance

Some practices seem to contradict common sense

Some practices have a learning curve

Best with very experienced team members

Requires active “customer” participation in process

second generation agile methods
Second Generation Agile Methods
  • Expand the roles to include architects, testers, …
  • Relax communication discipline
    • Standup meetings optional
  • Add Complexity
    • More activities
    • More values/principles
second generation readiness
Second Generation Readiness

Some teams suffer from “me first” syndrome. Kent Beck, author of Extreme Programming, explains it as follows:

“None of these groups saw themselves as part of a larger whole. Under stress, they reverted to trying to do all of their work up front.

It was as if the different perspectives were roped together walking up a glacier and all they wanted to do was argue about who got to be first in line. It didn’t matter who was first. What the whole team was missing was a sense that they were roped together. Walking abreast, they could make more progress than if any one group tried to force the others to follow.” [Beck 2005]

what we will cover
What We Will Cover

Microsoft Solutions Framework

  • Team Model
  • Working with Customers
  • Iteration Planning
  • Shadow Architecture
  • Exploratory Testing
  • Guiding Projects
agile vs cmmi

Functional/Exploratory Testing

Iteration Planning

Test Driven Development

Shadow Architecture

Context-Driven Test

MSF for Agile Software Development

Change Requests

Process Improvement Activities

Formal Reviews

Approvals

MSF for CMMI Process Improvement

Requirements Analysis

Agile vs. CMMI
what we will cover1
What We Will Cover
  • Microsoft Solutions Framework
    • Team Model
    • Working with Customers
    • Iteration Planning
    • Shadow Architecture
    • Exploratory Testing
getting the whole team involved

Larry Sykes Business Analyst

Jacqui AckermanProject Manager

Art BensonArchitect

Renee DavisTester

Getting the Whole Team Involved

Mort GainesDeveloper

Ian Manning

Release Manager

activities in msf
Activities in MSF
  • Composed of 14 basic work streams
    • Basic activity building blocks of MSF
    • A work stream is an activity that is composed of other activities
    • Activities are described using the ETVX format
    • Contains 70 activities (not including work streams)
    • Most work streams are performed by a single role
scaling for small projects
Scaling for Small Projects
  • Constituencies may be combined in small teams
larger projects

ProgramManagement

Architecture

Architecture

Architecture

Architecture

ProductManagement

ProgramManagement

Development

Site Engine & Design

ReleaseOperations

UserExperience

Test

Larger Projects….

Lead team

Feature teams

Function team

Development

UserExperience

UserExperience

Test

ReleaseOperations

ProgramManagement

ProgramManagement

Development

Development

Catalog

Fulfillment

UserExperience

Test

Test

what we will cover2
What We Will Cover
  • Microsoft Solutions Framework
    • Team Model
    • Working with Customers
    • Iteration Planning
    • Shadow Architecture
    • Exploratory Testing
software invisibility
Software Invisibility

“The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.”

Source: Brooks 1987

among the customer rights
Among the Customer Rights

You have the right to change your mind, to substitute functionality, and to change priorities without paying exorbitant costs.

problems with the onsite customer
Problems with the Onsite Customer
  • May be many customers (heterogeneous, homogeneous)
  • Customer must cover:
    • Commitment
    • Requirements
    • Planning
    • Testing (Basic and Comprehensive)
    • Adoption
customer involvement
Customer Involvement

Working Software

Scenarios

Personas

Review

Refine

Linkages

Real Customers

personas
Personas

Source: http://www.research.microsoft.com/research/coet/Grudin/Personas/Pruitt-Grudin.doc

what we will cover3
What We Will Cover
  • Microsoft Solutions Framework
    • Team Model
    • Working with Customers
    • Iteration Planning
    • Shadow Architecture
    • Exploratory Testing
date or feature driven
Date or Feature Driven
  • Projects can be driven by date or functionality. When a project is driven by date, project deadlines are usually determined by the market, events, competitors, regulations, financial implications, or other business reasons.
  • Understanding the progress of the system is critical to managing expectations and planning according. Additionally, organizational, technical, and project risks may need to be tracked when they have a time component. Even if a project is not date-driven, understanding the estimated time of arrival helps to other groups put the sales/deployment/marketing/training/operations elements in place.
iteration planning

Iteration Planning

Iteration 0

Brainstorming Scenarios

Iteration Planning

slide25

Brainstorm

Quality of

Service

Requirements

Vision Statement

Quality of ServiceRequirement List

Develop

Lifestyle

Snapshot

Storyboard

a Scenario

Risk

Plan an Iteration

Write Vision Statement

Define

Personas

Refine

Personas

Capture Project Vision

Brainstorm

Scenarios

R

Personas

Lifestyle

Snapshot

Develop

Lifestyle

Snapshot

R

R

Scenario List

BusinessAnalyst

Prioritize

Quality of

Service

Requirements

Prioritize

Scenario

List

C

Scenario

Quality of

Service

Requirement

Scenario

Description

Write

Scenario

Description

Write

Quality of

Service

Requirement

C

Reports

Customer

Storyboard

Create a Quality of

Service Requirement

Estimate

Quality of

Service

Requirement

Review

Objectives

Estimate

Scenario

Create a Scenario

Guide Project

slide26

Evaluate

Test Metric

Thresholds

Review

Objectives

Assess

Progress

Determine

Iteration

Length

Schedule

Scenario

Test

Approach

Schedule

QoS

Requirement

Iteration Plan

Schedule

Bug Fixing

Allotment

Risk

Task

Scenario

Quality of

Service

Requirement

Triage List

Divide QoS

Requirements

Into Tasks

Divide

Scenarios

Into Tasks

Estimate

Quality of

Service

Requirement

Estimate

Scenario

Triage

Bugs

Identify

Risk

Guide Project

R

Monitor

Iteration

R

R

Project

Manager

Mitigate a

Risk

Conduct

Retrospective

Guide Iteration

Plan an Iteration

slide27

Partition

The System

Determine

Interfaces

Threat

Model

Iteration Plan

Risk

Task

Quality of

Service

Requirement

Divide QoS

Requirements

Into Tasks

Divide

Scenarios

Into Tasks

Plan an Iteration

Develop

Threat

Model

Develop

Performance

Model

Create

Architectural

Prototype

Create

Infrastructure

Architecture

Create Solution Architecture

R

Application and

System Diagrams

Architect

C

Prototype

Logical Datacenter

And Deployment Diagrams

slide28

Locate the

Cause of

A Bug

Reassign a

Bug

Reproduce

The Bug

Cost a

Development

Task

Code the

Fix for a

Bug

Create or

Update a

Unit Test

Create or

Update a

Unit Test

Decide on a

Bug Fix

Strategy

Perform

Code

Analysis

Unit

Test

Code

Perform a

Unit Test

Perform a

Unit Test

Bug

Task

Scenario

Quality of

Service

Requirement

Review

Code

Integrate

Code

Changes

Integrate

Code

Changes

Refactor

Code

Refactor

Code

Divide QoS

Requirements

Into Tasks

Divide

Scenarios

Into Tasks

Write Code

For a

Development

Task

Plan an Iteration

R

R

R

Developer

C

Review

Code

Fix a Bug

Implement a Development Task

slide29

Close the

Bug

Define Test

Approach

Verify Fix

Close a Bug

Write

Performance

Tests

Define

Test

Approach

Select and

Run a

Test Case

Test Case

Team Build

Test Approach

Write

Security

Tests

Open a

Bug

Open a

Bug

Tester

Bug

Task

Scenario

Quality of

Service

Requirement

Write

Load

Tests

Select and

Run a

Test Case

Conduct

Exploratory

Testing

Conduct

Exploratory

Testing

Write

Stress

Tests

Divide QoS

Requirements

Into Tasks

Divide

Scenarios

Into Tasks

Write

Validation

Tests

Plan an Iteration

R

R

C

R

Test a Scenario

Test a QoS Requirement

slide30

Execute a

Release

Plan

Validate a

Release

Create

Release

Notes

Deploy the

Product

Release a Product

Vision Statement

Test Case

Team Build

Release

Notes

Test Approach

Release Plan

Bug

Tester

Release

Manager

Developer

R

C

C

anatomy of an iteration
Anatomy of an Iteration

Iteration

Retrospective

Iteration

Planning

Meeting

iteration retrospective
Iteration Retrospective

- s

+ s

if you could do it again, what

kinds of improvements would

you make?"

what we will cover4
What We Will Cover
  • Microsoft Solutions Framework
    • Team Model
    • Working with Customers
    • Iteration Planning
    • Shadow Architecture
    • Exploratory Testing
larger projects1

ProgramManagement

Architecture

Architecture

Architecture

Architecture

ProductManagement

ProgramManagement

Development

Site Engine & Design

ReleaseOperations

UserExperience

Test

Larger Projects….

Lead team

Feature teams

Function team

Development

UserExperience

UserExperience

Test

ReleaseOperations

ProgramManagement

ProgramManagement

Development

Development

Catalog

Fulfillment

UserExperience

Test

Test

shadows
Shadows

Leading

  • Sometimes we need to sketch out architecture/design before we implement them
  • Whiteboard is often used
  • Should become working code within the iteration – no BDUF

Trailing

  • Should reflect the actual code
  • Should come for free
actions
Actions
  • System Model/Whiteboard the architecture using leading shadows
  • Agree and move a single architectural change (such as a new web service) at a time to the trailing shadow
  • Create unit test/façade & scaffold
  • Run unit test
  • Write code
  • Run unit test
  • Verify Design/Code/Refactor
  • Run unit test
what we will cover5
What We Will Cover
  • Microsoft Solutions Framework
    • Team Model
    • Working with Customers
    • Iteration Planning
    • Shadow Architecture
    • Exploratory Testing
levels of test cases
Levels of Test Cases
  • Build Verification Tests (Automated)
    • Fail -> Build fails
  • Iteration Tests (Automated)
    • Track progress
    • Fail -> Build succeeds
  • Scenario and QoS Requirement Tests
  • Exploratory Tests
  • Captured in the Test Approach Document
why exploratory testing
Why Exploratory Testing?
  • There are many areas that must be tested that fall outside of normal scenario and qos requirement tests
    • Pair-wise tests
    • States
    • Usability
    • …..
exploratory testing
Exploratory Testing
  • Formulate a hypothesis for area of concern
  • Set a session limit (e.g. 2 hours)
  • Grab a buddy (optional or record the session)
  • Test the hypothesis
  • Create bugs
  • Example: Persona based exploratory testing
what we will cover6
What We Will Cover
  • Microsoft Solutions Framework
    • Team Model
    • Working with Customers
    • Iteration Planning
    • Shadow Architecture
    • Exploratory Testing
most importantly
Most Importantly
  • MSF for Agile Software Development and MSF for CMMI Process Improvement is now available at:

http://www.microsoft.com/msf

what s next
What’s Next
  • DB Pro Integration
  • Better CI support
  • Better Shadow Architecture Support
  • CM Guidance
  • And More…
conclusions
Conclusions
  • MSF is a vehicle for delivering Microsoft’s contributions to the software development community
  • MSF version 4.0 comes in two flavors to deliver maximum flexibility
  • MSF updates will be delivered via MSDN
  • MSF can become a basis for your software development process
slide50

© 2006 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.

The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.