Microsoft Solution Framework for
Agile Software Development
Workshop
April 18th & 20th , 2006
Agenda
Time
Topic
Speaker
09:00-09:15
Opening
Tom Lee
09:15-09:30
Expectations Alignment
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&A
Bobby Mak
Tom Lee,
Wong-Tun Chou
Expectations Alignment
Bobby Mak
Senior Consultant
Microsoft Technology Center
Microsoft Taiwan
bobbymak@microsoft.com
Microsoft Solution Framework for
Agile Software Development
Workshop
April 18th & 20th , 2006
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
MSF for Agile Software Development
Bobby Mak
Senior Consultant
Microsoft Technology Center
Microsoft Taiwan
bobbymak@microsoft.com
Microsoft Solution Framework for
Agile Software Development
Workshop
April 18th & 20th , 2006
A Brief History of MSF
(Microsoft Solution Framework)
MSF Offering
MSF v2
Solutions
Dev
Discipline
(SDD)
MSF v2.5
MSF v3
MSF v4
Principles of …
App Dev (PAD)
Infra Deploy (PID)
Ent Arch (PEA)
Comp Des (PCD)
Essentials
+ Exam
Core
Agile
CMMI
…
MSF v1
1994
1995
1997
1999
2002
2005-06
Overview
Methodology
Agile
MSF4ASD
MSF v4
Principle
Essential
Mindset
Role
Practices
MSF4CMMI
Project
Management
Activities
Process
Work
Products
Tools
VSTS
Since 1994
Microsoft Solutions Framework
MSF offers guidance in how to organize
people and projects to plan, build, and deploy
technology solutions
successfully and effectively
MSFv3
Essentials
Key goals for MSF:
Discipline
• Drive business success through business
MSFv4
& technology alignment
Essentials
• Ensure high quality solutions; handling
the many facets of quality as defined by
Application
Family
Infrastructure
multiple stakeholders
Development
• Accelerate delivery, reduce costs,
minimize risks
MSF for Agile
MSF for CMMI®
Product
Software
Process
• Improve team effectiveness
(instantiated)
Development
Improvement
The Origin of MSF
Microsoft
Products
Groups
Microsoft
Services
Microsoft
Operations &
Technology
Group
Microsoft
Certified
Partners
Proven
Practices
• 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
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 Groups
Team Model
Solution Delivery
Solution Design
Program
Management
Architecture
Solution Definition
Solution Construction
Product
Management
Development
Advocacy
User
Experience
Solution Usability
Test
Release /
Operations
Solution
Deployment
Solution Quality
MSF v4 Advocacy Groups Focus
Business Focus
Users
Operations
Support
User
Experience
Product
Management
Customer
Test
Project Team
Development
Operations
Release /
Operations
Program
Management
Architecture
Technology Architects
Technology Focus
Project
Sponsor
Solutions
Architects
Advocacy Group
Advocates
Quality Goals
Constituents
Functional Areas
Product
Management
Solution
Definition
o Satisfy stakeholders
o Define solution within project
constraints
o Stakeholders
o Marketing/Corporate
Communications
o Business Analyst
o Product Planning
o 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
o
o
o
o
o
Architecture
Solution
Design
Design a solution within project
constraints
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
User Experience
Solution
Usability
Maximize/ Enhance user
performance/ effectiveness
o Users
o Operations
Support
o Accessibility
o Internationalization
o Technical Support
Communications
o Training
o Usability
o Graphic Design
Release /
Operations
Solution
Deployment
Smooth deployment and transition
to operations
o Operations
o
o
o
o
o
Project management
Program Management
Resource Management
Process Assurance
Project Quality Management
Project Operations
o Solution Architecture
o Technical Architecture
o Functional Testing
o System Testing
Delivery Infrastructure
Operations
Commercial Release Management
Build Master
Tool Administrator
MSF v4 Advocacy Groups
• Roles may be combined, but some combinations pose
risks
Product
Management
Program
Development
Management
N
Product
Management
Test
User
Experience
Release
Management
N
P
P
U
N
U
U
P
N
N
N
P
P
Program
Management
N
Development
N
N
Test
P
U
N
User
Experience
P
U
N
P
Release
Management
U
P
N
P
P Possible
U Unlikely
N Not Recommended
U
U
MSF v4 Advocacy Groups
Small Team
Small team, combined roles
User
Experience
Program
Management
Product
Management
Release
Management
Test
Development
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
Function Team
Program
Management
Architecture
Role Lead
User
Experience
Program
Management
Product
Management
Product
Management
Development
User
Experience
Test
Architecture
Desktop
Feature
Team
Release /
Operations
Release /
Operations
Program
Management
Product
Management
Development
Test
Program
Management
File & Print
Feature
Team
Release /
Operations
Development
Test
Architecture
Messaging
Feature
Team
Development
Test
Release /
Operations
Feature Teams
Established 2001
Agile Manifesto
•Individuals and interactions over
processes and tools
•Working software over comprehensive
documentation
•Customer collaboration over contract
negotiation
•Responding to change over following a
plan
Agile Software Development
“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
Accounting
vs.
Throughput
30
-M
ar
23
-M
ar
16
-M
ar
9M
ar
2M
ar
eb
24
-F
17
-F
10
-F
eb
240
220
200
180
160
140
120
100
80
60
40
20
0
eb
Features
Device Management Ike II Cumulative Flow
Time
Inventory
Classic
Focus is on hours spent
Started
Designed
Coded
Complete
Agile
Focus is on value delivered
Eliminate waste
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
MSF for Agile Software Development
• 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 objectoriented applications.
MSF for Agile Software Development
• 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
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
MSF
Essential
MSF4ASD
MSF4CMMI
MSF for CMMI Process Improvement
• Coverage of 20 out of 25 process areas
• Footprint only 150% bigger than MSF Agile
Approximately 200 activities
• Only 50 documents (work products)
– Typical CMMI implementation ~100
• Supported by around 50 automated queries
and reports
– Easier certification
50% coverage
Level 2
Project Planning
Project Monitoring
& Control
Measurement &
Analysis
Requirements
Management
Configuration
Management
Process & Product
Quality Assurance
Supplier
Agreement
Management
Omitted
CMMI Model
Level 3
Integrated Project
Management
Risk Management
Integrated Teaming
Requirements
Development
Technical Solution
Product Integration
Verification
Validation
Decision Analysis &
Resolution
Organizational
Process Definition
Organizational
Environment for
Integration
Organizational
Process Focus
Organizational
Training
Integrated Supplier
Management
Level 4
Organizational
Process
Performance
Quantitative
Project
Management
Level 5
Organizational
Innovation and
Deployment
Causal Analysis &
Resolution
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.
Work
Products
Activities
Practices
Project
Management
Process
MSF for Agile Software Development
• Tracks
• Cycle
• Roles
• Work Streams
• Activities
• Work Products
Tracks
1
n
Cycle
1
n
Roles
1
n
Work
Streams
1
n
Activities
1
n
Work
Products
Tracks
MSF 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 Approach
Cycle
• Minimize risks by breaking large projects into
multiple versions
Version 3
Version 2
Version 1
Time
Iterations
Cycle
• 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
Visual Studio
Visual Studio
Team Architect
Team Developer
Team Test
Application Designer
Dynamic Code Analyzer
Load/Web Testing
Logical Datacenter Designer
Static Code Analyzer
Manual Testing
Deployment Designer
Code Profiler
Test Case Management
Unit Testing
Code Coverage
Class Designer
Visio and UML Modeling
Team Foundation Client (includes CAL)
Microsoft® Visual Studio® Professional Edition
Visual Studio
Team Foundation
Team Build
Version Control
Team Reporting
Integration Services
Work Item Tracking
Project Portal
Project Management
Visual Studio Industry Partners
Process and Architecture Guidance
Visual Studio Team System
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
Work
Products
Work
Streams
Source
Control
Test
Results
Work
Items
Reports
Team System
Process Run Through
Bobby Mak
Senior Consultant
Microsoft Technology Center
Microsoft Taiwan
bobbymak@microsoft.com
Microsoft Solution Framework for
Agile Software Development
Workshop
April 18th & 20th , 2006
Envision
Capture Project Vision
Capture Project Vision
Write Vision Statement
Define Personas
Plan an Iteration
Determine Iteration Length
Plan
Build
Iteration
Guide Project
Access Progress
Create a Scenario
Create a Scenario
Create Solution Architect
Create Solution Architect
Plan an Iteration
Brain Storm Scenario
Prioritize Scenario List
Partition the System
Determine Interface
Schedule scenario
Create a QoS/Scenario
Create a Scenario
Create a Scenario
Plan an Iteration
Create Solution Architect
Plan an Iteration
Dev. Lifestyle Snapshot
Write Scenario Description
Storyboard a scenario
Estimate a scenario/QoS
Create Architecture Phototype
Divide Scenario to Tasks
Create a QoS
Create a QoS
Create Solution Architect
Create Solution Architect
Plan an Iteration
Implement a Dev Task
Brain Storm QoS
Prioritize QoS Requirement
Develop Performance Model
Dev. Threat Model
Schedule QoS
Cost a Dev Task
Capture Project Vision
Create a QoS
Create a QoS
Test a QoS
Create Solution Architect
Plan an Iteration
Refine Personas
Write QoS Requirement
Identify Security Objectives
Write QoS Test
Create Infrastructure Arch.
Divide QoS to Tasks
Test a Scenario
Test a Scenario
Define Test Approach
Write Validation Test
Fix a Bug
Fix a Bug
Fix a Bug
Fix a Bug
Guide Project
Reproduce the bug
Locate the bug cause
Decide Bug Fix Strategy
Reassign the bug
Triage Bug
Implement a Dev Task
Fix a Bug
Fix a Bug
Imp Dev Task/Fix Bug
Create of Update Unit Test
Code the Fix
Create of Update Unit Test
Code Review
Implement a Dev Task
Imp Dev Task/Fix Bug
Imp Dev Task/Fix Bug
Imp Dev Task/Fix Bug
Implement a Dev Task
Write Code for Dev Task
Perform Unit Test
Perform Code Analysis
Refector Code
Integrate Code Change
Build
Build a Product
Fix a build
Stable
Check-In
Accepted Build
Test a Scenario/QoS
Conduct Exploratory Test
Build a Product
Build a Product
Build a Product
Test a Scenario/QoS
Test a Scenario
Start a build
Verify a build
Accept Build
Select & Run a test case
Open a Bug
Test a Scenario
Test a Scenario
Verify Fix(s)
Close Bug(s)
Deploy
Release a Product
Release a Product
Release a Product
Release a Product
Execute a release plan
Validate a release
Create Release Note
Deploy the product
Cont.
Guide Project
Guide Project
Guide Project
Guide Iteration
Guide Iteration
Guide Iteration
Review Objectives
Access Progress
Identify Risk
Monitor Iteration
Mitigate a Risk
Conduct Retrospective
Envision
Capture Project Vision
Capture Project Vision
Write Vision Statement
Define Personas
Plan an Iteration
Determine Iteration Length
Plan
Iteration
Guide Project
Access Progress
Create a Scenario
Create a Scenario
Create Solution Architect
Create Solution Architect
Plan an Iteration
Brain Storm Scenario
Prioritize Scenario List
Partition the System
Determine Interface
Schedule scenario
Create a QoS/Scenario
Create a Scenario
Create a Scenario
Plan an Iteration
Create Solution Architect
Plan an Iteration
Dev. Lifestyle Snapshot
Write Scenario Description
Storyboard a scenario
Estimate a scenario/QoS
Create Architecture Phototype
Divide Scenario to Tasks
Create a QoS
Create a QoS
Create Solution Architect
Create Solution Architect
Plan an Iteration
Implement a Dev Task
Brain Storm QoS
Prioritize QoS Requirement
Develop Performance Model
Dev. Threat Model
Schedule QoS
Cost a Dev Task
Capture Project Vision
Create a QoS
Create a QoS
Create Solution Architect
Plan an Iteration
Refine Personas
Write QoS Requirement
Identify Security Objectives
Create Infrastructure Arch.
Divide QoS to Tasks
Test a Scenario
Define Test Approach
Check-In
Build
Build
Stable
Deploy
Cont.
Accepted Build
Envision
Plan
Iteration
Guide Project
Access Progress
Create a Scenario
Create a Scenario
Create Solution Architect
Create Solution Architect
Plan an Iteration
Brain Storm Scenario
Prioritize Scenario List
Partition the System
Determine Interface
Schedule scenario
Create a QoS/Scenario
Create a Scenario
Create a Scenario
Plan an Iteration
Create Solution Architect
Plan an Iteration
Dev. Lifestyle Snapshot
Write Scenario Description
Storyboard a scenario
Estimate a scenario/QoS
Create Architecture Phototype
Divide Scenario to Tasks
Create a QoS
Create a QoS
Create Solution Architect
Create Solution Architect
Plan an Iteration
Implement a Dev Task
Brain Storm QoS
Prioritize QoS Requirement
Develop Performance Model
Dev. Threat Model
Schedule QoS
Cost a Dev Task
Capture Project Vision
Create a QoS
Create a QoS
Test a QoS
Create Solution Architect
Plan an Iteration
Refine Personas
Write QoS Requirement
Identify Security Objectives
Write QoS Test
Create Infrastructure Arch.
Divide QoS to Tasks
For next iteration
Build
Test a Scenario
Test a Scenario
Define Test Approach
Write Validation Test
Fix a Bug
Fix a Bug
Fix a Bug
Fix a Bug
Guide Project
Reproduce the bug
Locate the bug cause
Decide Bug Fix Strategy
Reassign the bug
Triage Bug
Implement a Dev Task
Fix a Bug
Fix a Bug
Imp Dev Task/Fix Bug
Create of Update Unit Test
Code the Fix
Create of Update Unit Test
Code Review
Implement a Dev Task
Imp Dev Task/Fix Bug
Imp Dev Task/Fix Bug
Imp Dev Task/Fix Bug
Implement a Dev Task
Write Code for Dev Task
Perform Unit Test
Perform Code Analysis
Refector Code
Integrate Code Change
Build
Build a Product
Fix a build
Stable
Check-In
Accepted Build
Test a Scenario/QoS
Conduct Exploratory Test
Build a Product
Build a Product
Build a Product
Test a Scenario/QoS
Test a Scenario
Start a build
Verify a build
Accept Build
Select & Run a test case
Open a Bug
Test a Scenario
Test a Scenario
Verify Fix(s)
Close Bug(s)
Deploy
Cont.
Guide Project
Guide Project
Guide Project
Guide Iteration
Guide Iteration
Guide Iteration
Review Objectives
Access Progress
Identify Risk
Monitor Iteration
Mitigate a Risk
Conduct Retrospective
Envision
Plan
Iteration
Guide Project
Access Progress
Test a QoS
Write QoS Test
Test a Scenario
Write Validation Test
Build
Fix a Bug
Fix a Bug
Fix a Bug
Fix a Bug
Guide Project
Reproduce the bug
Locate the bug cause
Decide Bug Fix Strategy
Reassign the bug
Triage Bug
Implement a Dev Task
Fix a Bug
Fix a Bug
Imp Dev Task/Fix Bug
Create of Update Unit Test
Code the Fix
Create of Update Unit Test
Code Review
Implement a Dev Task
Imp Dev Task/Fix Bug
Imp Dev Task/Fix Bug
Imp Dev Task/Fix Bug
Implement a Dev Task
Write Code for Dev Task
Perform Unit Test
Perform Code Analysis
Refector Code
Integrate Code Change
Build
Build a Product
Fix a build
Stable
Check-In
Accepted Build
Test a Scenario/QoS
Conduct Exploratory Test
Build a Product
Build a Product
Build a Product
Test a Scenario/QoS
Test a Scenario
Start a build
Verify a build
Accept Build
Select & Run a test case
Open a Bug
Test a Scenario
Test a Scenario
Verify Fix(s)
Close Bug(s)
Deploy
Cont.
Guide Project
Guide Project
Guide Project
Guide Iteration
Guide Iteration
Guide Iteration
Review Objectives
Access Progress
Identify Risk
Monitor Iteration
Mitigate a Risk
Conduct Retrospective
Envision
Plan
Build
Iteration
Guide Project
Access Progress
Fix a Bug
Fix a Bug
Fix a Bug
Fix a Bug
Guide Project
Reproduce the bug
Locate the bug cause
Decide Bug Fix Strategy
Reassign the bug
Triage Bug
Fix a Bug
Fix a Bug
Imp Dev Task/Fix Bug
Code the Fix
Create of Update Unit Test
Code Review
Imp Dev Task/Fix Bug
Imp Dev Task/Fix Bug
Imp Dev Task/Fix Bug
Implement a Dev Task
Perform Unit Test
Perform Code Analysis
Refector Code
Integrate Code Change
Build
Build a Product
Fix a build
Stable
Check-In
Accepted Build
Test a Scenario/QoS
Conduct Exploratory Test
Build a Product
Build a Product
Build a Product
Test a Scenario/QoS
Test a Scenario
Start a build
Verify a build
Accept Build
Select & Run a test case
Open a Bug
Test a Scenario
Test a Scenario
Verify Fix(s)
Close Bug(s)
Deploy
Cont.
Guide Project
Guide Project
Guide Project
Guide Iteration
Guide Iteration
Guide Iteration
Review Objectives
Access Progress
Identify Risk
Monitor Iteration
Mitigate a Risk
Conduct Retrospective
Envision
Plan
Iteration
Build
Check-In
Build
Accepted Build
Stable
Deploy
Release a Product
Release a Product
Release a Product
Release a Product
Execute a release plan
Validate a release
Create Release Note
Deploy the product
Cont.
Guide Project
Guide Project
Guide Project
Guide Iteration
Guide Iteration
Guide Iteration
Review Objectives
Access Progress
Identify Risk
Monitor Iteration
Mitigate a Risk
Conduct Retrospective
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 approach
Capture 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)
Example
Capture Project Vision
For
online shoppers
Who
are interested in sporting and camping
equipment, but do not like shopping in brickand-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
Personas
Define 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 Personas
On-site
Customer
Persona
Actor
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
•Larry Sykes
Business Analyst
•Mort Gaines
Developer
•Jacqui Ackerman
Project Manager
•Art Benson
Architect
• Renee Davis
Tester
• Ian Manning
Release Manager
Personas Resources
Define Personas
• Personas: Practice and Theory Whitepaper
http://www.research.microsoft.com/research/coet/Grudin/Personas/
Pruitt-Grudin.doc
• Personas book
• The Persona Lifecycle
Where do Scenario fit in?
Create a Scenario
User stories
Scenarios
Use cases
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!!
Satisfied
Customer
“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
“More Is Better”
•Speed of Internet Connection
•Flavor of coffee
•Gas Mileage
•Battery life on digital camera
Indifferent Needs
Poor
Functionality
“I don’t care”
•MapPoint on standard tool bar
Excellent
Functionality
•Color of coffee cup
•Size of tires
“If it’s not there, I’ll never
be satisfied”
•Voltage of battery
•Ability to Print
•Coffee is hot
•Car has brakes
•Ability to transfer digital
pictures to computer
Dissatisfied
Customer
Survey Questions:
Functional
If the speed of the internet connection is fast, how do you
feel?
1. I like it
Dysfunctional
If the speed of the internet connection is slow, how do you
feel?
5. I dislike it
One-Dimensional Need
I like it
I expect it
I am neutral
I can tolerate it
I dislike it
A A
I I
I I
I Q
RM RM
O
M
M
M
Q
3. I am neutral
2. I expect it
Q A
RA Q
RA I
RA I
RO RM
5. I dislike it
1.
2.
3.
4.
5.
4. I can tolerate it
Example
1. I like it
Dysfunctional
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
Kano Evaluation Table
Functional
Form of
Question
Functional
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
Dysfunctional
Form of Question
Customer Requirement Is
A: Attractive
O: One-Dimensional
M: Must Have
Q: Questionable Result
R: Reverse
I: Indifferent
% Response by Category
Must-Have
OneDimensional
Attractive
Indifferent
Need1
45
20
20
10
Need2
10
60
25
Need3
5
10
Need4
5
Need5
Need6
Reverse
Questionable
M+O
O+A
5
65
40
5
70
85
5
80
15
15
5
85
5
10
90
25
30
20
25
55
50
85
5
10
90
5
{
{
100%
Attractive
90%
O+A
– Corners
• Strong Requirement
– Center
• Mix of segments
(respondents)
• Weak requirement
Need2
70%
60%
O+A
• Location on Grid
Need4
80%
if Included
Satisfaction
One Dimensional + Attractive
M+O
One-Dimensional
50%
40%
Need5
Need1
30%
20%
Need6
Need3
10%
M+O
Indifferent
Must Have
0%
0%
10%
20%
30%
40%
50%
60%
70%
Dissatisfaction if Missing
Must Have + One Dimensional
80%
90%
100%
100%
Attractive
90%
One-Dimensional
Need4
Need2
One
Dimensional
+ Attractive
if Included
Satisfaction
80%
Perform slightly
better than
Competitors
Include as
Differentiator
s
70%
60%
Need5
50%
40%
Need1
Ignore
30%
DO NOT
IGNORE!
20%
Need6
Need3
10%
Indifferent
Must Have
0%
0%
10%
20%
30%
40%
50%
60%
Dissatisfaction
Missing
Must Have + One if
Dimensional
70%
80%
90%
100%
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
Context
• Examples
– “When the system is being used by 25,000 simultaneous users,
the catalog search results response time
Stimulus
should not exceed 5 seconds in 95% of the cases.” [Performance]
Response
– “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
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
How long is an
iteration?
Scenario 1
Scenario 2
Scenario 3
Scenario 4
Scenario List
Iteration 1
Scenario 1
Scenario 2
Scenario 3
How big is a
scenario?
How many scenarios
can I implement in an
interation?
Iteration Plan
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 1 – ROM 1
Scenario 2 – ROM 2
Scenario 3 – ROM 1
Scenario 4 – ROM 1
Scenario List
Initial velocity =
(3 developers * 4 weeks) / 3 = 4
Iteration 1
Scenario 1
Scenario 2
Scenario 3
Iteration Plan
Using Kano Analysis
Plan an Iteration
Minimum
Acceptance Level
Minimum
Acceptance
Level
Iteration 3
Iteration 2
Iteration 1
Divide a Scenario/QoS to Tasks
Plan an Iteration
Scenarios
Split
Browse
Catalog
for Products
Order
Products
for Pickup
Catalog
Create
UI
Order DB
Browse for
Products –
Catalog
Provisioning
Browse for
Products –
Product
Selection
Create Sporting
Good Order
Dev Tasks
Divide
Test Tasks
Assign
Cost a Dev Task
Implement 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: Architects
Create 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 Architecture
Create 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 Model
Create 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 Threat
Create 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
Someone put your salary slip up on the wall at the office
Disclosure
Service
Someone slashed your car tyres and you can’t get to
work.
Elevation of
You use your boss’ phone to order free lunch.
Denial of
Privelege
DREAD-Rank Threats
Create 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
Create Solution Architect
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 Update
Unit Tests
Write Code for a
Development Task
Perform
Unit Test
Check Code against
Design and Code
Guidelines
Coding Guidelines
Implement a Dev Task
• Full Design Guidelines can be accessed at
http://msdn.microsoft.com/library/enus/cpgenref/html/cpconNETFrameworkDesignGuidel
ines.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_Coding_
Standards.pdf
Integrate Code Change
Implement 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 locally
3. Compile and must PASS Check-In Suit
4. Check in only the changes
5. 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 Build
Build 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 Case
Test 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 Case
Test 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 Bug
Test a Scenario
• Testers decide, NOT the developers
Risk
Guide 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
Risk
Guide 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
Risk
Guide 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 Progress
Guide Project
• Remaining Work
– How much work is left to be done, and when will it be completed?
Access Progress
Guide Project
• Quality Indicator
– What is the quality of the software?
Access Progress
Guide Project
• Velocity
– How quickly is the team completing work?
Access Progress
Guide Project
• Unplanned Work
– How much unplanned work is there?
Access Progress
Guide Project
• Actual vs. Planned Work
– How many scenarios can be completed before quality is
unacceptable?
Access Progress
Guide Project
• Bug Rates
Access Progress
Guide Project
• Reactivations
Access Progress
Guide 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
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 Solutions Framework
Microsoft Operations Framework
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
Customizing VSTS
Bobby Mak
Senior Consultant
Microsoft Technology Center
Microsoft Taiwan
bobbymak@microsoft.com
Microsoft Solution Framework for
Agile Software Development
Workshop
April 18th & 20th , 2006
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
Activities
Workstream
Roles
etc
Single Primary XML
Datasource
XSL
Transforms
Index
Activities
Roles
etc
(With PageInfo.xml Info)
Single
HTML
URLs
IE (User)
CTP/Betas
MSDN
Project Portal
JScript
XML Mapping Table
Keyword & Context -> URL
XML Index
F1
Search
Process Guidance Integration (VSTS)
URLs
Help System
(DExplorer)
Extending Team System
VSTF Extension Kit
• 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
Q&A
Tom Lee – DPE Architect Evangelist
Wong-Tun Chou – DPE ISV Evangelist
Microsoft Solution Framework for
Agile Software Development
Workshop
April 18th & 20th , 2006
© 2005 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.
Appendix
Methodology
Agile
MSF4ASD
MSF v4
Principle
Essential
Mindset
Role
Practices
MSF4CMMI
Project
Management
Activities
Process
Work
Products
Tools
VSTS
Microsoft Solution Framework For Agile Software Development
Workshop
April 18th & 20th, 2006
Envision
Capture Project Vision
Capture Project Vision
Write Vision Statement
Define Personas
Microsoft Solution Framework For Agile Software Development
Workshop
April 18th & 20th, 2006
Plan an Iteration
Determine Iteration Length
Plan
Build
Iteration
Guide Project
Access Progress
Create a Scenario
Create a Scenario
Create Solution Architect
Create Solution Architect
Plan an Iteration
Brain Storm Scenario
Prioritize Scenario List
Partition the System
Determine Interface
Schedule scenario
Create a QoS/Scenario
Create a Scenario
Create a Scenario
Plan an Iteration
Create Solution Architect
Plan an Iteration
Dev. Lifestyle Snapshot
Write Scenario Description
Storyboard a scenario
Estimate a scenario/QoS
Create Architecture Phototype
Divide Scenario to Tasks
Create a QoS
Create a QoS
Create Solution Architect
Create Solution Architect
Plan an Iteration
Implement a Dev Task
Brain Storm QoS
Prioritize QoS Requirement
Develop Performance Model
Dev. Threat Model
Schedule QoS
Cost a Dev Task
Capture Project Vision
Create a QoS
Create a QoS
Test a QoS
Create Solution Architect
Plan an Iteration
Refine Personas
Write QoS Requirement
Identify Security Objectives
Write QoS Test
Create Infrastructure Arch.
Divide QoS to Tasks
Test a Scenario
Test a Scenario
Define Test Approach
Write Validation Test
Fix a Bug
Fix a Bug
Fix a Bug
Fix a Bug
Guide Project
Reproduce the bug
Locate the bug cause
Decide Bug Fix Strategy
Reassign the bug
Triage Bug
Implement a Dev Task
Fix a Bug
Fix a Bug
Imp Dev Task/Fix Bug
Create of Update Unit Test
Code the Fix
Create of Update Unit Test
Code Review
Implement a Dev Task
Imp Dev Task/Fix Bug
Imp Dev Task/Fix Bug
Imp Dev Task/Fix Bug
Implement a Dev Task
Write Code for Dev Task
Perform Unit Test
Perform Code Analysis
Refector Code
Integrate Code Change
Build
Build a Product
Fix a build
Stable
Check-In
Accepted Build
Test a Scenario/QoS
Conduct Exploratory Test
Build a Product
Build a Product
Build a Product
Test a Scenario/QoS
Test a Scenario
Start a build
Verify a build
Accept Build
Select & Run a test case
Open a Bug
Test a Scenario
Test a Scenario
Verify Fix(s)
Close Bug(s)
Deploy
Release a Product
Release a Product
Release a Product
Release a Product
Execute a release plan
Validate a release
Create Release Note
Deploy the product
Cont.
Guide Project
Guide Project
Guide Project
Guide Iteration
Guide Iteration
Guide Iteration
Review Objectives
Access Progress
Identify Risk
Monitor Iteration
Mitigate a Risk
Conduct Retrospective