microsoft solution framework for agile software development workshop april 18 th & 20 th, 2006
TRANSCRIPT
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
Expectations Alignment
Microsoft Solution Framework for
Agile Software Development
WorkshopApril 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
Microsoft Solution Framework for
Agile Software Development
WorkshopApril 18th & 20th , 2006
Bobby MakSenior Consultant
Microsoft Technology CenterMicrosoft Taiwan
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
DevelopmentDevelopment
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
DevelopmentDevelopment
TestTest
UserExperience
UserExperience
ReleaseManagement
ReleaseManagement
ReleaseManagement
ReleaseManagement
MSF v4 Advocacy GroupsSmall Team
UserExperience
UserExperience
ProductManagement
ProductManagement
TestTest
ProgramManagement
ProgramManagement
ReleaseManagement
ReleaseManagement
DevelopmentDevelopment
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
DevelopmentDevelopment
TestTest
DesktopFeatureTeam
ProgramManagement
ProgramManagement
DevelopmentDevelopment
TestTest
ArchitectureArchitecture
ArchitectureArchitecture
Release / OperationsRelease /
Operations
ProductManagement
ProductManagement
File & PrintFeatureTeam
ProgramManagement
ProgramManagement
DevelopmentDevelopment
TestTest
Release / OperationsRelease /
Operations
MessagingFeatureTeam
ProgramManagement
ProgramManagement
DevelopmentDevelopment
TestTest
ArchitectureArchitecture
Release / OperationsRelease /
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
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 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
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 object-oriented 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
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.
MSF for Agile Software Development
• 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
Bobby MakSenior Consultant
Microsoft Technology CenterMicrosoft Taiwan
Process Run Through
Microsoft Solution Framework for
Agile Software Development
WorkshopApril 18th & 20th , 2006
Capture Project Vision
Write Vision Statement
Capture Project Vision
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
Capture Project Vision
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
Create Solution Architect
Determine Interface
Create Solution Architect
Dev. Threat Model
Create Solution Architect
Develop Performance Model
Create Solution Architect
Create Infrastructure Arch.
Create Solution Architect
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
Implement a Dev Task
Create of Update Unit Test
Implement a Dev Task
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
Create of Update Unit Test
Fix a Bug
Reproduce the bug
Fix a Bug
Locate the bug cause
Imp Dev Task/Fix Bug
Perform Code Analysis
Imp Dev Task/Fix Bug
Refector Code
Imp Dev Task/Fix Bug
Code Review
Implement a Dev Task
Integrate Code Change
Imp Dev Task/Fix Bug
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
Capture Project Vision
Write Vision Statement
Capture Project Vision
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
Capture Project Vision
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
Create Solution Architect
Determine Interface
Create Solution Architect
Dev. Threat Model
Create Solution Architect
Develop Performance Model
Create Solution Architect
Create Infrastructure Arch.
Create Solution Architect
Create Architecture Phototype
Implement a Dev Task
Cost a Dev Task
Test a Scenario
Define Test Approach
Envision
Plan
Build
Stable
Deploy
Cont.
IterationIteration
Check-InCheck-In
Accepted BuildAccepted BuildBuildBuild
Iteration 0
Iteration 0
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
Capture Project Vision
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
Create Solution Architect
Determine Interface
Create Solution Architect
Dev. Threat Model
Create Solution Architect
Develop Performance Model
Create Solution Architect
Create Infrastructure Arch.
Create Solution Architect
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
Implement a Dev Task
Create of Update Unit Test
Implement a Dev Task
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
Create of Update Unit Test
Fix a Bug
Reproduce the bug
Fix a Bug
Locate the bug cause
Imp Dev Task/Fix Bug
Perform Code Analysis
Imp Dev Task/Fix Bug
Refector Code
Imp Dev Task/Fix Bug
Code Review
Implement a Dev Task
Integrate Code Change
Imp Dev Task/Fix Bug
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)
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
Iteration 1
Iteration 1
For next iterationFor next iteration
Guide Project
Access Progress
Test a Scenario
Write Validation Test
Test a QoS
Write QoS Test
Implement a Dev Task
Create of Update Unit Test
Implement a Dev Task
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
Create of Update Unit Test
Fix a Bug
Reproduce the bug
Fix a Bug
Locate the bug cause
Imp Dev Task/Fix Bug
Perform Code Analysis
Imp Dev Task/Fix Bug
Refector Code
Imp Dev Task/Fix Bug
Code Review
Implement a Dev Task
Integrate Code Change
Imp Dev Task/Fix Bug
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)
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
Iteration N + 1
Iteration N + 1
Guide Project
Access Progress
Fix a Bug
Reassign the bug
Fix a Bug
Decide Bug Fix Strategy
Fix a Bug
Code the Fix
Fix a Bug
Create of Update Unit Test
Fix a Bug
Reproduce the bug
Fix a Bug
Locate the bug cause
Imp Dev Task/Fix Bug
Perform Code Analysis
Imp Dev Task/Fix Bug
Refector Code
Imp Dev Task/Fix Bug
Code Review
Implement a Dev Task
Integrate Code Change
Imp Dev Task/Fix Bug
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)
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
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
Conduct Retrospective
IterationIteration
Check-InCheck-In
Accepted BuildAccepted BuildBuildBuild
Iteration N +3
Iteration N +3
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
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
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
Scenario 1Scenario 1
Scenario 2Scenario 2
Scenario 3Scenario 3
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
Scenario 1Scenario 1
Scenario 2Scenario 2
Scenario 3Scenario 3
Initial velocity = (3 developers * 4 weeks) / 3 = 4
Using Kano Analysis Plan an Iteration
MinimumMinimumAcceptanceAcceptanceLevelLevel
Iteration 1Iteration 1
Iteration 2Iteration 2
Iteration 3Iteration 3
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
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 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
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?
Access ProgressGuide Project
• Quality Indicator– What is the quality of the software?
Access ProgressGuide Project
• Velocity– How quickly is the team completing work?
Access ProgressGuide Project
• Unplanned Work– How much unplanned work is there?
Access ProgressGuide Project
• Actual vs. Planned Work– How many scenarios can be completed before quality is
unacceptable?
Access ProgressGuide Project
• Bug Rates
Access ProgressGuide Project
• Reactivations
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
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
Bobby MakSenior Consultant
Microsoft Technology CenterMicrosoft Taiwan
Customizing VSTS
Microsoft Solution Framework for
Agile Software Development
WorkshopApril 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
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
Microsoft Solution Framework for
Agile Software Development
WorkshopApril 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
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
Microsoft Solution Framework For Agile Software DevelopmentWorkshop
April 18th & 20th, 2006
Capture Project Vision
Write Vision Statement
Capture Project Vision
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
Capture Project Vision
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
Create Solution Architect
Determine Interface
Create Solution Architect
Dev. Threat Model
Create Solution Architect
Develop Performance Model
Create Solution Architect
Create Infrastructure Arch.
Create Solution Architect
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
Implement a Dev Task
Create of Update Unit Test
Implement a Dev Task
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
Create of Update Unit Test
Fix a Bug
Reproduce the bug
Fix a Bug
Locate the bug cause
Imp Dev Task/Fix Bug
Perform Code Analysis
Imp Dev Task/Fix Bug
Refector Code
Imp Dev Task/Fix Bug
Code Review
Implement a Dev Task
Integrate Code Change
Imp Dev Task/Fix Bug
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
Microsoft Solution Framework For Agile Software DevelopmentWorkshop
April 18th & 20th, 2006
Microsoft Solution Framework For Agile Software DevelopmentWorkshop
April 18th & 20th, 2006