microsoft solution framework for agile software development workshop april 18 th & 20 th, 2006

Microsoft Solution Framework for

Agile Software Development

WorkshopApril 18th & 20th , 2006

AgendaTime Topic Speaker

09:00-09:15 Opening Tom Lee

09:15-09:30 Expectations Alignment

Bobby Mak

09:30-11:00 MSF for Agile Software Development

11:00-11:15 Coffee Break

11:15-12:30 Process run through (Part 1)

12:30-13:30 Lunch Break

13:30-15:00 Process run through (Part 2)

15:00-15:15 Coffee Break

15:15-16:30 Customizing the process

16:30-17:00 Q&ATom Lee, Wong-Tun Chou

Bobby MakSenior Consultant

Microsoft Technology CenterMicrosoft Taiwan

[email protected]

Expectations Alignment




Goal of this workshop

• Helps you to better understanding the MSF for Agile Software Development methodology

• Helps you to evaluate the adoption of MSF for Agile Software Development methodology

What will be the take-away for this workshop?

• Understanding the relationship between– Microsoft Solution Framework– Agile Software Development– MSF for Agile Software Development– Visual Studio Team System

• Run through each of the tracks and work streams– Go through each activities– Go through each work products

• Compares how things were done– In Microsoft Product Group– Microsoft Technology Center– MSF for Agile Software Development

• How you can modify the process– To better fit your needs






[email protected]

MSF for Agile Software Development

A Brief History of MSF(Microsoft Solution

Framework)

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

MS

F O

fferi

ng

MS

F O

fferi

ng

MSF MSF v1v1

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 v2.5MSF v2.5 MSF v3MSF v3

EssentialsEssentials+ Exam+ Exam

CoreCoreAgileAgileCMMICMMI……

MSF v4MSF v4

MethodologyMethodology

Overview

Agile MSF v4Essential

MSF4ASD MSF4CMMI

VSTS

Principle

Mindset Role

Project Management

Process

Practices

Activities

Work Products

Tools

Microsoft Solutions Framework

Key goals for MSF:• Drive business success through

business & technology alignment• Ensure high quality solutions;

handling the many facets of quality as defined by multiple stakeholders

• Accelerate delivery, reduce costs, minimize risks

• Improve team effectiveness

MSF offers guidance in how to organize people and projects to

plan, build, and deploy technology solutions

successfully and effectively

MSF for Agile MSF for Agile Software Software

DevelopmentDevelopment

MSF for CMMIMSF for CMMI®® Process Process

ImprovementImprovement

InfrastructInfrastructureure

MSFv4 MSFv4 EssentialsEssentials

Application Application DevelopmenDevelopmen

tt

DisciplineDiscipline

ProductProduct(instantiated)(instantiated)

FamilyFamily

MSFv3 MSFv3 EssentialsEssentials

Since 1994

The Origin of MSF

• Results from project teams and product groups are analyzed • Analyzed results are contrasted with industry practices and

methods• Combined results are then organized and consolidated into

“people and process” guidance

Microsoft Products Groups

MicrosoftOperations & Technology

Group

MicrosoftServices

Microsoft Certified Partners

ProvenPractices

MSF v4 Principles• Foster open communications

– to maximize members’ individual effectiveness and optimize efficiencies in the work, information has to be readily available and actively shared.

• Shared vision– vision helps to clarify goals and bring conflicts and mistaken

assumptions to light so they can be resolved• Empower team members

– MSF advocates bottom-up scheduling, a schedule that the team can support because it believes in it

• Clear accountability and shared responsibility– establishing well-understood lines of accountability and

responsibility reduces uncertainty around the "who, what, when, and why,"

• Focus on business value– By combining a focus on business value with shared vision,

the project team and the organization can develop a clear understanding of why the project exists and how success will be measured in terms of business value to the organization.

MSF v4 Principles (cont.)• Stay agile, expect change

– MSF advises teams to expect changes from stakeholders and even the team itself

• Invest in quality– investment in people, as well as in processes and tools

• Learn from all experiences– the failure to learn from all experiences is a guarantee

that we will repeat them, as well as their associated project consequences.

• Partner with customers– Understanding the value proposition of your solution and

communicating it effectively is a key success factor.• Always create shippable solutions

– Each change should be done in the context of the belief that the product should be ready to ship at any time.

MSF v4 Mindsets• Team of Peers

– all roles must have ownership of the product’s quality, must act as customer advocates, and must understand the business problem they are trying to solve.

• Customer-focused mindset– Satisfied customers are priority number one– A customer focus throughout development includes a commitment from

the team to understand and solve the customer’s business problem.• Solution mindset

– It is about treating the results of your labor as a solution– MSF advocates the creation of project identities so that team members

see themselves less as individuals and more as members of a project team

• Trusting mindset– Trusting your peers

• Quality mindset– commitment to quality.– team goal is to perform their work at the highest quality possible, so that

if they have to deliver tomorrow, they can deliver something• Willingness to learn

– commitment to ongoing self improvement through the gathering and sharing of knowledge

MSF v4 Advocacy GroupsTeam Model

Advocacy

Solution Delivery


TestTest

Release /OperationsRelease /

Operations

UserExperience

UserExperience

ProductManagement

ProductManagement

Program Management

Program Management ArchitectureArchitecture

Solution Design

Solution Definition

Solution QualitySolution Usability

Solution Construction

Solution Deployment

MSF v4 Advocacy Groups Focus

Operations

Technology Focus

Business FocusUsers

Solutions Architects

Customer

Technology Architects

Operations Support

Project Team

UserExperience

Development

Test

Release / Operations

ProductManagement

Architecture

ProgramManagement

Project Sponsor

Advocacy Group

Advocates Quality Goals Constituents Functional Areas

Product Management

Solution Definition

o Satisfy stakeholderso Define solution within

project constraints

o Stakeholders o Marketing/Corporate Communications

o Business Analysto Product Planningo Release Management

Program Management

Solution Delivery

o Coordinate identification and optimization of project constraints

o Deliver solution within project constraints

o Project Sponsor(s)

o Project managemento Program Managemento Resource Managemento Process Assuranceo Project Quality

Managemento Project Operations

Architecture Solution Design

Design a solution within project constraints

o Solution Architectureo Technical Architecture

Development

Solution Construction

Build solution to specifications

Test Solution Quality

Approve solution for release only after making sure all aspects of the solution meet or exceed their respective, defined quality levels

o Functional Testingo System Testing

User Experience

Solution Usability

Maximize/ Enhance user performance/ effectiveness

o Userso Operations

Support

o Accessibilityo Internationalizationo Technical Support

Communicationso Trainingo Usabilityo Graphic Design

Release / Operations

Solution Deployment

Smooth deployment and transition to operations

o Operations o Delivery Infrastructureo Operationso Commercial Release

Managemento Build Mastero Tool Administrator

MSF v4 Advocacy Groups

• Roles may be combined, but some combinations pose risks

N

N N

N

N

N

N

N

N

N N N

P

P

P

P

P

P

P

P

P

P

U

U

U

U

U U

U

U

P Possible U Unlikely N Not Recommended

ProductManagement

ProductManagement

ProgramManagement

ProgramManagement DevelopmentDevelopment TestTest

UserExperience

UserExperience

ProductManagement

ProductManagement

ProgramManagement

ProgramManagement


TestTest

UserExperience

UserExperience

ReleaseManagement

ReleaseManagement

ReleaseManagement

ReleaseManagement

MSF v4 Advocacy GroupsSmall Team

UserExperience

UserExperience

ProductManagement

ProductManagement

TestTest

ProgramManagement

ProgramManagement

ReleaseManagement

ReleaseManagement


Small team, combined roles

MSF Sub-teams in Relation to the Lead Team

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

ProgramManagement

ProgramManagement

Release / OperationsRelease /

Operations

ProductManagement

ProductManagement

UserExperience

UserExperience


TestTest

DesktopFeatureTeam

ProgramManagement

ProgramManagement


TestTest

ArchitectureArchitecture



Operations

ProductManagement

ProductManagement

File & PrintFeatureTeam

ProgramManagement

ProgramManagement


TestTest


Operations

MessagingFeatureTeam

ProgramManagement

ProgramManagement


TestTest



Operations

ProductManagement

ProductManagement

UserExperience

Role Lead

Function Team

Feature Teams

Agile Manifesto

• Individuals and interactions over processes and tools

•Working software over comprehensive documentation

• Customer collaborationCustomer collaboration over contract negotiation

•Responding to change over following a plan

Established 2001Established 2001


“An agile method is– Iterative– Incremental– Self-Organizing and– Emergent.

It must include these attributes; otherwise it is a ‘lightened defined process’.”

– Ken Schwaber, First eWorkshop on Agile Methods

• MSF fulfills the definition of an Agile Process

Agile Management Philosophy

• Cost Accounting vs. Throughput Accounting

Classic Agile

Focus is on hours spent Focus is on value deliveredEliminate waste

Device Management Ike II Cumulative Flow

020406080

100120140160180200220240

10-F

eb

17-F

eb

24-F

eb

2-M

ar

9-M

ar

16-M

ar

23-M

ar

30-M

ar

Time

Fe

atu

res

Inventory Started Designed Coded Complete

Well known Agile Methodologies

• Extreme Programming (XP)• Scrum• Adaptive Software Development (ASD)• Crystal• Feature-Driven Development (FDD)• DSDM• RUP• Unisys QuadCycle• Etc.

Agile – Software Development Lifecycle Support

VTT Agile Software Development Method - http://www.inf.vtt.fi/pdf/publications/2002/P478.pdf


• Represent a version of MSF that– De-emphasizes formal project governances– Emphasizes agile principles within smaller

collaborative teams

• an iterative, scenario-driven, context-based software development process for building .NET, Web, Web Service, and other object-oriented applications.


• First Microsoft-branded software development methodology

• Complete with – documented processes– Guidance and templates– Incorporate hooks into tools

• “White label” approach– Designed for adopt then customized and

extend as required

MSF4CMMIMSF4CMMIMSF4ASDMSF4ASD

MSF for CMMI Process Improvement

• Help organizations operate at Capability Maturity Model® Integration (CMMI®) level 3, a standard defined by the Carnegie Mellon Software Engineering Institute (SEI)

• Does not replace process improvement infrastructure• An Agile approach to CMMI

– Introduce additional formality, reviews, verification, and audit

• Compare to MSF4ASD– Based on the same MSF meta-model– Same set of principles– Same set of mindsets

MSFMSFEssentialEssential

MSF for CMMI Process Improvement

• Coverage of 20 out of 25 process areas• Footprint only 150% bigger than MSF

AgileApproximately 200 activities

• Only 50 documents (work products)– Typical CMMI implementation ~100

• Supported by around 50 automated queries and reports– Easier certification

CMMI Model

Level 2

Project PlanningProject Monitoring & ControlMeasurement & AnalysisRequirements ManagementConfiguration ManagementProcess & Product Quality AssuranceSupplier Agreement Management

Level 3Integrated Project ManagementRisk ManagementIntegrated TeamingRequirements DevelopmentTechnical SolutionProduct IntegrationVerificationValidationDecision Analysis & ResolutionOrganizational Process DefinitionOrganizational Environment for IntegrationOrganizational Process FocusOrganizational TrainingIntegrated Supplier Management

Omitted

Level 4Organizational Process PerformanceQuantitative Project Management

Level 5Organizational Innovation and DeploymentCausal Analysis & Resolution

50% coverage

20% coverage

When to choose MSF4ASD?

• … for projects with results-oriented teams who can work without lots of intermediate documentation

• “Stretch to Fit” instead of “Shrink to Fit”– Minimalist approach– Agile methodologies promote adaptation

When to choose MSF4CMMI?

• Choose the MSF for CMMI Process Improvement process for projects with longer lifecycles and that require a record of decisions made. Choose MSF for CMMI Process Improvement over MSF for Agile Software Development, if your organization is undertaking a broad quality assurance and process improvement initiative or your team needs the assistance of explicit process guidance rather than relying on tacit knowledge and experience.


• Tracks• Cycle• Roles• Work Streams• Activities• Work Products

Tracks

Cycle

Roles

WorkStreams

Activities

WorkProducts

1n

1n

1n

1n

1n

Project Management

ProcessPracticesActivitiesWork Products

TracksMSF for Agile Software

Development• Tracks overlap each other and are controlled by

checkpoints– Envision– Plan– Build– Stabilize– Deploy– Continuous

Cycle

• Foundation of every day’s coordinated team work

Iterative ApproachCycle

• Minimize risks by breaking large projects into multiple versions

Time

Envis

ion Pla

n Devel

opSta

biliz

e Deplo

y

Version 3Env

isio

n Plan Dev

elop

Stabi

lize Dep

loy

Version 2

Envis

ion Pla

n Devel

opSta

biliz

e Deplo

y

Version 1

IterationsCycle

• Achievement of a pre-determined level of quality

• Based on planning of feature-sets• Mechanism to correct project plan

deviations

Team Roles

Work Streams

• Work streams are groups of activities that flow logically together and are often associated with a particular role

Activities

• 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

Work Products

• Work products are files, documents, specifications, binaries, parts, and other tangible items that are necessary to complete activities and build the product.

Visual Studio Team System

Version Control

Work Item Tracking

Team Reporting

Project Portal

Visual Studio

Team Foundation Integration Services

Project Management

Pro

cess an

d A

rch

itectu

re

Pro

cess an

d A

rch

itectu

re

Gu

idan

ce

Gu

idan

ce

Dynamic Code Analyzer

Visual Studio

Team Architect

Static Code Analyzer

Code Profiler

Unit Testing

Code Coverage

Visio and UML Modeling

Team Foundation Client (includes CAL)

Microsoft® Visual Studio® Professional Edition

Load/Web Testing

Manual Testing

Test Case Management

Application Designer

Logical Datacenter Designer

Deployment Designer

Visual Studio

Team DeveloperVisual Studio

Team Test

Vis

ual S

tud

io I

nd

ustr

y

Vis

ual S

tud

io I

nd

ustr

y

Part

ners

Part

ners

Team Build

Class Designer

Work Items

• A work item is a record uses to track the assignment and state of work.

• The MSF for Agile Software Development process defines five work items to assign and track work. – Scenario– Quality of service requirement– Task– Bug– Risk

Reports

• Aggregates– Work Items– Source Controls– Test Results

WorkStreams

WorkProducts

WorkItems

SourceControl

TestResults

Reports

Team SystemTeam System



[email protected]

Process Run Through




Capture Project Vision

Write Vision Statement


Define Personas

Plan an Iteration

Determine Iteration Length

Guide Project

Access Progress

Create a Scenario

Brain Storm Scenario

Create a Scenario

Prioritize Scenario List

Plan an Iteration

Estimate a scenario/QoSWrite Scenario Description

Create a Scenario

Write QoS Requirement

Create a QoS

Plan an Iteration

Divide Scenario to Tasks

Refine Personas


Brain Storm QoS

Create a QoS

Prioritize QoS Requirement

Create a QoS

Dev. Lifestyle Snapshot

Create a QoS/Scenario

Storyboard a scenario

Create a Scenario

Identify Security Objectives

Create a QoS

Plan an Iteration

Schedule scenario

Plan an Iteration

Schedule QoS

Plan an Iteration

Divide QoS to Tasks

Create Solution Architect

Partition the System


Determine Interface


Dev. Threat Model


Develop Performance Model


Create Infrastructure Arch.


Create Architecture Phototype

Implement a Dev Task

Cost a Dev Task

Test a Scenario

Define Test Approach

Test a Scenario

Write Validation Test

Test a QoS

Write QoS Test


Create of Update Unit Test


Write Code for Dev Task

Fix a Bug

Reassign the bug

Fix a Bug

Decide Bug Fix Strategy

Fix a Bug

Code the Fix

Fix a Bug


Fix a Bug

Reproduce the bug

Fix a Bug

Locate the bug cause

Imp Dev Task/Fix Bug

Perform Code Analysis


Refector Code


Code Review


Integrate Code Change


Perform Unit Test

Build a Product

Start a build

Build a Product

Verify a build

Build a Product

Fix a build

Build a Product

Accept Build

Test a Scenario

Verify Fix(s)

Test a Scenario/QoS

Select & Run a test case

Test a Scenario/QoS

Conduct Exploratory Test

Test a Scenario

Open a Bug

Test a Scenario

Close Bug(s)

Release a Product

Execute a release plan

Release a Product

Validate a release

Release a Product

Create Release Note

Release a Product

Deploy the product

Envision

Plan

Build

Stable

Deploy

Cont.Guide Project

Review Objectives

Guide Project

Access Progress

Guide Project

Identify Risk

Guide Iteration

Monitor Iteration

Guide Iteration

Mitigate a Risk

Guide Iteration

Conduct Retrospective

Guide Project

Triage Bug

IterationIteration

Check-InCheck-In

Accepted BuildAccepted BuildBuildBuild

Complete View

Complete View




Define Personas

Plan an Iteration


Guide Project

Access Progress

Create a Scenario


Create a Scenario


Plan an Iteration


Create a Scenario


Create a QoS

Plan an Iteration


Refine Personas


Brain Storm QoS

Create a QoS


Create a QoS




Create a Scenario


Create a QoS

Plan an Iteration

Schedule scenario

Plan an Iteration

Schedule QoS

Plan an Iteration

Divide QoS to Tasks




Determine Interface


Dev. Threat Model








Cost a Dev Task

Test a Scenario


Envision

Plan

Build

Stable

Deploy

Cont.

IterationIteration

Check-InCheck-In


Iteration 0

Iteration 0

Guide Project

Access Progress

Create a Scenario


Create a Scenario


Plan an Iteration


Create a Scenario


Create a QoS

Plan an Iteration


Refine Personas


Brain Storm QoS

Create a QoS


Create a QoS




Create a Scenario


Create a QoS

Plan an Iteration

Schedule scenario

Plan an Iteration

Schedule QoS

Plan an Iteration

Divide QoS to Tasks




Determine Interface


Dev. Threat Model








Cost a Dev Task

Test a Scenario


Test a Scenario


Test a QoS

Write QoS Test





Fix a Bug

Reassign the bug

Fix a Bug


Fix a Bug

Code the Fix

Fix a Bug


Fix a Bug

Reproduce the bug

Fix a Bug





Refector Code


Code Review




Perform Unit Test

Build a Product

Start a build

Build a Product

Verify a build

Build a Product

Fix a build

Build a Product

Accept Build

Test a Scenario

Verify Fix(s)

Test a Scenario/QoS


Test a Scenario/QoS


Test a Scenario

Open a Bug

Test a Scenario

Close Bug(s)

Envision

Plan

Build

Stable

Deploy

Cont.Guide Project

Review Objectives

Guide Project

Access Progress

Guide Project

Identify Risk

Guide Iteration

Monitor Iteration

Guide Iteration

Mitigate a Risk

Guide Iteration


Guide Project

Triage Bug

IterationIteration

Check-InCheck-In


Iteration 1

Iteration 1

For next iterationFor next iteration

Guide Project

Access Progress

Test a Scenario


Test a QoS

Write QoS Test





Fix a Bug

Reassign the bug

Fix a Bug


Fix a Bug

Code the Fix

Fix a Bug


Fix a Bug

Reproduce the bug

Fix a Bug





Refector Code


Code Review




Perform Unit Test

Build a Product

Start a build

Build a Product

Verify a build

Build a Product

Fix a build

Build a Product

Accept Build

Test a Scenario

Verify Fix(s)

Test a Scenario/QoS


Test a Scenario/QoS


Test a Scenario

Open a Bug

Test a Scenario

Close Bug(s)

Envision

Plan

Build

Stable

Deploy

Cont.Guide Project

Review Objectives

Guide Project

Access Progress

Guide Project

Identify Risk

Guide Iteration

Monitor Iteration

Guide Iteration

Mitigate a Risk

Guide Iteration


Guide Project

Triage Bug

IterationIteration

Check-InCheck-In


Iteration N + 1

Iteration N + 1

Guide Project

Access Progress

Fix a Bug

Reassign the bug

Fix a Bug


Fix a Bug

Code the Fix

Fix a Bug


Fix a Bug

Reproduce the bug

Fix a Bug





Refector Code


Code Review




Perform Unit Test

Build a Product

Start a build

Build a Product

Verify a build

Build a Product

Fix a build

Build a Product

Accept Build

Test a Scenario

Verify Fix(s)

Test a Scenario/QoS


Test a Scenario/QoS


Test a Scenario

Open a Bug

Test a Scenario

Close Bug(s)

Envision

Plan

Build

Stable

Deploy

Cont.Guide Project

Review Objectives

Guide Project

Access Progress

Guide Project

Identify Risk

Guide Iteration

Monitor Iteration

Guide Iteration

Mitigate a Risk

Guide Iteration


Guide Project

Triage Bug

IterationIteration

Check-InCheck-In


Iteration N +2

Iteration N +2

Envision

Plan

Build

Deploy

Cont.Guide Project

Review Objectives

Guide Project

Access Progress

Guide Project

Identify Risk

Guide Iteration

Monitor Iteration

Guide Iteration

Mitigate a Risk

Guide Iteration


IterationIteration

Check-InCheck-In


Iteration N +3

Iteration N +3

Release a Product


Release a Product

Validate a release

Release a Product

Create Release Note

Release a Product

Deploy the product

Stable

What is a Vision Statement?

Capture Project Vision• A short, coherent statement that concisely

describes the purpose of building the new or improved system.

• Provides the justification for building the system to the team.

• Ideally it should be 25 words or less.

• Everyone on the project team can recite it from memory and connect their daily work to it

The one-sentence approachCapture Project Vision

For (identified users)

Who (narrow the scope of the problem)

Our solution is

(set framework)

That (enumerate requirements)

Unlike (differentiate from competitors / alternatives)

ExampleCapture Project Vision

For online shoppers

Who are interested in sporting and camping equipment, but do not like shopping in brick-and-mortal shops

Our solution is

an AdventureWorks e-commerce Web site

That allows them to find and purchase exactly what they need

Unlike without having to physically visit the store

PersonasDefine Personas

• Descriptions of a group of typical users.– (Instances of actors)

• Instead of talking about the group of users in an abstract, impersonal way, a persona represents a 'proxy' for the user group, and provides a means to talk and reason about the group through the characteristics of one fictional individual, the persona.

Where Does Personas Fit in?

Define PersonasOn-siteCustomer

Actor

Persona

What is in a Personas?Define Personas

• A persona describes the typical skills, abilities, needs, desires, working habits, tasks and backgrounds of a particular set of users.

• A persona is fictional reality, collecting together real data describing the important characteristics of a particular user group in a fictional character.

Favored and Disfavored Personas

Define Personas• Favored personas are users who will

use the system “appropriately” or way that it was intended to be used.

• Disfavored personas are folks who will abuse the system. An example of a disfavored persona for an operating system is a hacker or virus writer.

Example: David Define Personas

• Role: Online Shopper

• Motivation: Get it Quick

• Usage: David hates to shop but wants his equipment immediately. He will place his order on Thursday night for his weekend activity. David doesn’t want to wade through a catalog. Instead, he wants things that he typically orders to show immediately.

Example: Judith Define Personas

• Role: Online Shopper

• Motivation: Get it Cheap

• Usage: Judith shops for the best bargain. She looks for the best deal on similar items. She will visit half a dozen sites to find the best deal.

Example: MSN Define Personas

Example: VSTS Personas Define Personas

•Jacqui AckermanProject Manager

•Art BensonArchitect

•Mort GainesDeveloper • Renee Davis

Tester

•Larry Sykes Business Analyst

• Ian ManningRelease Manager

Personas Resources Define Personas

• Personas: Practice and Theory Whitepaperhttp://www.research.microsoft.com/research/coet/Grudin/Personas/Pruitt-Grudin.doc

• Personas book• The Persona Lifecycle

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

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

http://images-eu.amazon.com/images/P/0125662513.02.LZZZZZZZ.jpg

Where do Scenario fit in? Create a Scenario

User stories

Use cases

Scenarios

Brain Storm Scenario Create a Scenario

• For each persona, determine their goals of the system.

• Decompose each goal into the scenarios that are required to achieve that goal or may result from an unsuccessful attempt to achieve that goal.

• Add an entry (called a scenario entry) for each brainstormed scenario

• One scenario is one path through the system

Example: Purchase Product: Find Product

Create a Scenario• David has heard about a new lightweight frame for his

mountain bike. He brings up the AdventureWorks Website and finds the search engine. He enters the text “mountain bike frame” and gets a list of the products that meet his search criteria. The list comes back sorted by the most popular (purchased most often) product but can be sorted by brand, product name, rating (number of stars by reviewers), and price. David sorts on brand and all of the “Excalibur” products are grouped together. He selects the “XJ11” which is $799.95 and has received five stars. When he presses the details button, he sees a picture of the new frame as well as links to the reviews and specification information.

• Note: the conclusion of adding the XJ11 to the cart has been omitted because it is described in the goal and scenario “Purchase Products: Add Product to Cart

Prioritize Scenario List Create a Scenario

• Determine the importance of the scenario

• Sort the Scenario list by priority

• Using Kano Analysis!!

Poor Functionality

Excellent Functionality

Dissatisfied Customer

Satisfied Customer

Indifferent Needs

Linear “1 D

imensional”

Needs

Must Have Needs

Attractiv

e Needs

“If it’s not there, I’ll never be satisfied”

•Ability to Print•Coffee is hot•Car has brakes•Ability to transfer digital pictures to computer

“I don’t care”•MapPoint on standard tool bar

•Color of coffee cup

•Size of tires

•Voltage of battery

“More Is Better”

•Speed of Internet Connection

•Flavor of coffee

•Gas Mileage

•Battery life on digital camera

“That’s Cool”

•Web page editing on IE Tool Bar

•Free Internet Access @ Starbucks

•Retractable light under hood

•Send digital pix with your cell phone

•Web page editing on IE Tool Bar

1b. If (need 1) is poor, how do you feel?

1. I like it

2. I expect it

3. I am neutral

4, I can tolerate

5. I dislike it

Customer Requirement IsA: Attractive O: One-Dimensional

M: Must Have Q: Questionable Result

R: Reverse I: Indifferent

Survey Questions:

1a. If (need 1) is good, how do you feel?

1. I like it

2. I expect it

3. I am neutral

4, I can tolerate it

5. I dislike it

1.

I li

ke it

2.

I e

xpe

ct it

3.

I a

m n

eu

tra

l

4.

I c

an

to

lera

te it

5.

I d

islik

e it

1. I like it Q A A A O2. I expect it RA Q I I M3. I am neutral I I I M4. I can tolerate it I I Q M5. I dislike it QF

un

cti

on

al

Fo

rm o

f Q

ue

sti

on

Dysfunctional Form of Question

Kano Evaluation TableFu

nc

tio

na

l D

ys

fun

cti

on

al

Example

If the speed of the internet connection is fast, how do you feel?

1. I like it

If the speed of the internet connection is slow, how do you feel?

5. I dislike it

One-Dimensional Need

RA

RA

RO RM RM RM

Fu

nc

tio

na

l D

ys

fun

cti

on

al

% Response by Category

Must-Have

One-Dimension

al

Attractive

Indifferent

Reverse

Questionable

Need1

45 20 20 10 5

Need2

10 60 25 5

Need3

5 10 5 80

Need4

5 5 85 5

Need5

25 30 20 25

Need6

85 5 10

M+O O+A

65 40

70 85

15 15

10 90

55 50

90 5

{

M+O

{O+A

• Location on Grid– Corners

• Strong Requirement

– Center• Mix of segments

(respondents) • Weak requirement

Need6

Need5

Need4

Need3

Need2

Need1

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

Must Have + One Dimensional

On

e D

ime

ns

ion

al

+ A

ttra

cti

ve

One-Dimensional

Must Have

Attractive

Indifferent M+O

O+

A

Dissatisfaction if Missing

Sat

isfa

ctio

n if

Incl

ud

ed

Need6

Need5

Need4

Need3

Need2

Need1

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

Must Have + One Dimensional

On

e D

ime

ns

ion

al

+ A

ttra

cti

ve

One-Dimensional

Must Have

Attractive

Indifferent

Ignore

Include as Differentiator

s

Perform slightly better than

Competitors

DO NOT IGNORE!

Dissatisfaction if Missing

Sat

isfa

ctio

n i

f In

clu

ded

Write Scenario Create a Scenario

• A scenario is a single path of user interaction through the system. As the user attempts to reach a goal, the scenario records the specific steps that they will in attempting to reach that goal. Some scenarios will record a successful path; others will record an unsuccessful one.

• When writing scenarios, be specific. Since there are an infinite number of possible scenarios for all but the most trivial systems, it is important to be discerning in deciding which scenarios to write.

Storyboard Scenario Create a Scenario

• Capture the screens that are presented to the persona. Draw out a rough sketch of the user interface called for in the scenario. Collaborate with members of the development team to ensure the user interface is consistent with the user interface metaphor.

• Tools that work well for storyboards include Microsoft Visio and Microsoft PowerPoint.

Brain Storm a QoS Create a QoS

• “Non-functional” requirements• QSRs constrain other functionality• Top 5

– Performance– Security– User Experience– Platform– Load

Example Create a QoS

• Examples– “When the system is being used by 25,000 simultaneous

users, the catalog search results response time

should not exceed 5 seconds in 95% of the cases.” [Performance]

– “When the catalog prices are updated, the system should log the user that has done this to the Windows Security Event Log.” [Security]

– “When the user changes the text size in his Web browser, the web pages should adjust accordingly” [User Experience]

Source: Carriere

Stimulus

Context

Response

Define Test Approach Test a Scenario

• Called Test Metric Thresholds in MSF Agile– Objective definition of when the product

quality is high enough to ship

• Context-based– Testing that is acceptable on one

project may be criminal on another

Sample Test Thresholds Test a Scenario

Planned test coverage/ release criteria for:

What are we going to look at? When is it good enough?

Code Unit tests for all code 70% code coverage, 100% pass rate

Scenarios Validation tests for all scenarios At least 1 test per scenario, 100% pass rate

Key QSRs(enumerate)

Home page load time 10,000 simultaneous users

Within 2 seconds

Key Risks System administrator not able to deploy the system in the production environment because of an incomplete/incorrect Installation Guide

A person that has never deployed the system before is able to do it in our test environment by following the Installation Guide

Bugs Bugs will be classified as follows … No Priority 1 & 2 bugs

Build Verification All unit tests will be run as part of the daily build

100% pass rate

Configurations Scenario validation tests executed with IE6, IE7, FireFox and Safari browsers

100% pass rate

Other Bug debt per developer Less than 7

Agile Plan Plan an Iteration

Scenario ListScenario List

Iteration PlanIteration Plan

Scenario 1Scenario 1Scenario 2Scenario 2

Scenario 3Scenario 3

Iteration 1Iteration 1Scenario 4Scenario 4




How long is an iteration?

How long is an iteration?

How many scenarios can I implement in

an interation?

How many scenarios can I implement in

an interation?

How big is a scenario?

How big is a scenario?

How Long is an Iteration?Plan an Iteration

•Time-boxed– 2 to 6 weeks– 4 weeks is a reasonable default– Planning overlaps with developing

and testing•(Self-organizing)

How Big is the Scenario?Plan an Iteration

• Use Rough Order of Magnitude (ROM)– ~1 day -> 0– ~5 days or less -> 1– ~10 days -> 2– > 10 days -> 3

•Consider splitting

How many scenario per Iteration?

Plan an Iteration• Velocity

– The number of scenario units completed in an iteration

• Calculating velocity– Sum of the ROM of each scenario

• Initial velocity– (developers * iteration weeks) / 3

Example: Schedule Scenario

Plan an Iteration

Scenario ListScenario List

Iteration PlanIteration Plan

Scenario 1 – ROM 1Scenario 1 – ROM 1Scenario 2 – ROM 2Scenario 2 – ROM 2

Scenario 3 – ROM 1Scenario 3 – ROM 1

Iteration 1Iteration 1Scenario 4 – ROM 1Scenario 4 – ROM 1




Initial velocity = (3 developers * 4 weeks) / 3 = 4

Using Kano Analysis Plan an Iteration

MinimumMinimumAcceptanceAcceptanceLevelLevel

Iteration 1Iteration 1



Minimum Acceptance Level

Divide a Scenario/QoS to Tasks

Plan an Iteration

Create Sporting

Good Order

Split

Divide

Assign

Browse Catalog

for Products

Order Products for Pickup

Scenarios

Dev Tasks

Test Tasks

Catalog

UI

Create

Order DB

Browse forProducts –

CatalogProvisioning

Browse forProducts –

ProductSelection

Cost a Dev TaskImplement a Dev Task

• At the beginning of each iteration• Developers estimate their tasks in hours

– Check if SumOf(tasks) + overhead > iteration length• Split or load-balance tasks if necessary• Update with the actual hours when done

• Use velocity for estimation• Use actual hours for tracking• The difference between the two is the project

overhead:– Meetings, code reviews, e-mail, etc.

ROLE: ArchitectsCreate Solution Architect

• Coordinate between Development and Operations – Not a Developer– Not responsible for Class Design

• Hands-On Architect– Limited documentation (Architectural decisions)– Setup Solution structure

• Responsible for Quality of Service Requirements– Architectural (evolving) prototype– Threat Modeling– Performance

TOOLS: Application Designer

Create Solution Architect• Define and

visualize applications in a Visual Studio Solution and how they are connected

Layering Architecture Create Solution Architect

Shadow ArchitectureCreate Solution Architect

• MSF (Agile community) has to BDUF is that– Without working software, these efforts have

no feedback mechanism.

• Architecture must lead and reflect the structure and logic of the working code

• MSF utilize Shadowing– Architecture for the functionality to be

completed in the iteration– A top-down approach of using System Designer

• System Designer in VSTS is optimized for bottom-up “composition” of systems

Threat ModelCreate Solution Architect

• Brainstorm threats to the system• Rank the threats by risk

– How serious are the consequences?– How easy is the attack?

• Find mitigations for the threats• Decide which threats to address, and

follow up

STRIDE-Categorize ThreatCreate Solution Architect

Types Example

Spoofing Somebody looked over your shoulder when you entered your PIN.

Tampering Extra, unwanted items show up in your basket at the counter in the supermarket.

Repudiation “You never lent me 1000 euros!”

Information Disclosure

Someone put your salary slip up on the wall at the office

Denial of Service

Someone slashed your car tyres and you can’t get to work.

Elevation of Privelege

You use your boss’ phone to order free lunch.

DREAD-Rank ThreatsCreate Solution Architect

Rankings Description

Damage Potential

The extend of the damage

Reproducibility How easy is it to get a potential attack to work?

Exploitability How much effort and expertise is required to mount an attack?

Affected Users A numeric value characterizing the ratio of installed instances of the system that would be affected if an exploit became widely available

Discoverability The likelihood that, if the vulnerability were to go unpatched, it would be found by external security researchers, hackers, etc

TOOLS: Threat Modeling Tool


Coding!!Implement a Dev Task

• Unit Testing– Not a choice– Rule of thumb: 70% code coverage

• Check-in Policy– Check as early as possible– Prevent breaking the build– Unit Tests must succeed

• Refactoring is not bad– Requirements change– Visions change

Test First or Code First?Implement a Dev Task

• It doesn’t matter, just do it!

Create or UpdateUnit Tests

Write Code for aDevelopment Task

PerformUnit Test

Check Code againstDesign and Code

Guidelines

Coding GuidelinesImplement a Dev Task• Full Design Guidelines can be accessed at

http://msdn.microsoft.com/library/en-us/cpgenref/html/cpconNETFrameworkDesignGuidelines.asp. – These provide some more detail and some

justifications for the guidelines described above.

• Community Efforts, by Lance Hunt– C# Coding Standard for .NET– http://home.comcast.net/~lancehunt/CSharp_C

oding_Standards.pdf

http://msdn.microsoft.com/library/en-us/cpgenref/html/cpconNETFrameworkDesignGuidelines.asp



http://home.comcast.net/~lancehunt/CSharp_Coding_Standards.pdf

http://home.comcast.net/~lancehunt/CSharp_Coding_Standards.pdf

Integrate Code ChangeImplement a Dev Task

• Policies– Pass Unit Test– Pass Code Analysis– Conduct Code Review

• IMPORTANT: Make sure you…1. Put a lock on to the server (source control)2. Get latest version of the code from server

1. Integrate the differences locally3. Compile and must PASS Check-In Suit4. Check in only the changes5. Release the lock

Coding!!!Fix a Bug

• Bug classification– MSF 4 Process Guidance

• 1 = This iteration• 2 = This release• 3 = May or may NOT fix

– Microsoft Best Practice: Tell and Ask– Be aware: Honesty pays off

• Unit Test– Helps validating bug fixing– Can be used to repro a bug and check for the fix

Daily BuildBuild a Product

• Daily Build Vital!– Heartbeat– Keep quality near 100%

• Use Build Verification Tests (BVT) for validation– Scenario based

• Daily Integration– No surprises in the end– Saves time

Select and Run a Test CaseTest a Scenario

• Involve testers during the project– Not at the end

• Automate tests– Where possible

Opening a Bug (in Microsoft)

Test a Scenario

Select and Run a Test CaseTest a QoS

• Performance Testing– Global performance, scenario

performance– Load testing (users)– Stress testing (resources)

• Security Testing– Various roles, environment

• Exploratory Testing– Not monkey testing– Act as persona

Close a BugTest a Scenario

• Testers decide, NOT the developers

RiskGuide Project

• Definitions– Dictionary: “Possibility of loss or injury”

Webster’s Collegiate Dictionary, 10th edition

– Common: A problem waiting to happen • Characteristics

– Inherent in every project– Neither intrinsically good nor bad– Not something to fear, but something

to manage

RiskGuide Project

• Simplified risk management framework• Risk is just another work item• New or renamed Fields

– Severity is the same as Impact– Priority replaces Exposure

• No Probability field• Prioritization is done by customer

– State • Risks can be in Active or Closed states

– Reason• Reason a risk is in current State

RiskGuide Project

• New or renamed Fields– Iteration

• Iteration in which risk could be realized• Risk can be made part of Iteration Backlog

– Mitigation and Contingency plans are tracked in a general Description field

• Risks that impacts solution architecture are handled by the Architect– Architect creates an architectural

prototype to validate proposed architecture

Access ProgressGuide Project

• Remaining Work– How much work is left to be done, and when will it be

completed?


• Quality Indicator– What is the quality of the software?


• Velocity– How quickly is the team completing work?


• Unplanned Work– How much unplanned work is there?


• Actual vs. Planned Work– How many scenarios can be completed before quality is

unacceptable?


• Bug Rates


• Reactivations


• Remaining Work– How much work is left to be done, and when will it be

completed? • Quality Indicator

– What is the quality of the software?• Velocity

– How quickly is the team completing work?• Unplanned Work

– How much unplanned work is there?• Actual vs. Planned Work

– How many scenarios can be completed before quality is unacceptable?

• Bug Rates• Reactivations

Stabilize

• Focus on delivery• Feature Complete

– NO new functionality will be added

• Bugs Fixed should exceed Bugs Found• Balances stability against customer

needs• Can result in loss of features for the

sake of stability

Deploy

Microsoft Operations Framework

Microsoft Solutions Framework

Operate

Dep

loy

Build

Pla

n

Deploy

• Goal: Release to Production or Acceptance• Team focus

– To facilitate the smooth transfer of the solution from the project team to the operations team

– To secure customer approval that the project is complete Validate Release

• Deliverables– Repository of all versions of documents, load

sets, configurations, scripts, and code– Release Notes

Deployment Best Practice

• Test deployment early in an environment with production characteristics

• Deploy multiple times during Development Lifecycle to improve the process

• Automate as much as possible• Produce useful and up-to-date Release

Notes• Work closely with the Operations Team



[email protected]

Customizing VSTS




Process Templates in VSTS

• Work Item types, workflow• Check-In policy• Document templates• Reports• Groups and permissions• Integrated help

Extensibility

• Process templates can be edited• Process guidance includes Microsoft®

InfoPath® editing form• Third-party tools available from

Osellus

Method of Extension

• Framework – Building a process within the MSF meta-model, adopting pieces or all of MSF for Agile or Formal Software Development process

• Prototype – Using pieces or all of MSF for Agile Software Development or Formal as a base to build your own process without the meta-model

Process Guidance Architecture

Process Guidance (MSF) Layout

Word Docs

ActivitiesWorkstream

Rolesetc

Single Primary XML Datasource

(With PageInfo.xml Info)

Single HTML

XSL Transforms

IndexActivities

Rolesetc

JScript

IE (User)CTP/Betas

MSDNProject Portal

URLs

Process Guidance Integration (VSTS)

XML Mapping TableKeyword & Context -> URL

XML Index

URLsF1 Search Help System

(DExplorer)

Extending Team System

• Process– Process Template

Customization Guide– MSF Process Guidance

Customization Guide• Core Service

– Authoring work items– Work Item Query Language– Work Item Tracking Object

Model– Check In policy extensibility– Continuous Integration– Event Subscription– Object Model Help– Linking Service Extension– Reports Extension– Security Service Guide

• Operation– Configure TFS to use a

Remote SharePoint Server– Migrate TFS from a single to

dual server– Migrate TFS to a new server– TFS Backup and Restore

VSTF Extension Kit

Tom Lee – DPE Architect Evangelist

Wong-Tun Chou – DPE ISV Evangelist

Q&A




Appendix

MethodologyMethodology

Agile MSF v4Essential

MSF4ASD MSF4CMMI

VSTS

Principle

Mindset Role

Project Management

Process

Practices

Activities

Work Products

Tools

Microsoft Solution Framework For Agile Software DevelopmentWorkshop

April 18th & 20th, 2006


April 18th & 20th, 2006




Define Personas

Plan an Iteration


Guide Project

Access Progress

Create a Scenario


Create a Scenario


Plan an Iteration


Create a Scenario


Create a QoS

Plan an Iteration


Refine Personas


Brain Storm QoS

Create a QoS


Create a QoS




Create a Scenario


Create a QoS

Plan an Iteration

Schedule scenario

Plan an Iteration

Schedule QoS

Plan an Iteration

Divide QoS to Tasks




Determine Interface


Dev. Threat Model








Cost a Dev Task

Test a Scenario


Test a Scenario


Test a QoS

Write QoS Test





Fix a Bug

Reassign the bug

Fix a Bug


Fix a Bug

Code the Fix

Fix a Bug


Fix a Bug

Reproduce the bug

Fix a Bug





Refector Code


Code Review




Perform Unit Test

Build a Product

Start a build

Build a Product

Verify a build

Build a Product

Fix a build

Build a Product

Accept Build

Test a Scenario

Verify Fix(s)

Test a Scenario/QoS


Test a Scenario/QoS


Test a Scenario

Open a Bug

Test a Scenario

Close Bug(s)

Release a Product


Release a Product

Validate a release

Release a Product

Create Release Note

Release a Product

Deploy the product

Envision

Plan

Build

Stable

Deploy

Cont.Guide Project

Review Objectives

Guide Project

Access Progress

Guide Project

Identify Risk

Guide Iteration

Monitor Iteration

Guide Iteration

Mitigate a Risk

Guide Iteration


Guide Project

Triage Bug

IterationIteration

Check-InCheck-In



April 18th & 20th, 2006


April 18th & 20th, 2006

microsoft solution framework for agile software development workshop april 18 th & 20 th, 2006

Documents

adoption of msf

team effectiveness msf

origin of msf results

needs slide

technology solutions

business technology

wongtun chou slide

work streams