Process Patterns For Distributed Development

advertisement
Process Patterns For
Distributed Development
Vladimir Pavlov
Vladimir.L.Pavlov@Intel.com
Andrey A. Terekhov
AndreyTe@Microsoft.com
1
Process Patterns
For Distributed Development
Introduction
Organizational Patterns
Process Patterns
Transitional Patterns
2
About The Authors
Vladimir Pavlov (Intel, Russia)



Outsourcing and Development Processes Manager
Microsoft Endorsed MSF Practitioner,
MCSD for .NET, MCSD, MCDBA, MCT,
CompTIA Certified IT Project+
Member of PMI, ACM, IEEE and IEEE Computer Society
Andrey A. Terekhov (Microsoft, Russia)




Academic Programs Manager
PhD in Computer Science
Microsoft Endorsed MSF Practitioner, MCSD, (ex-)MCT,
IEEE Certified Software Development Professional
Member of ACM, IEEE and IEEE Computer Society
This presentation is mostly based on experience gained by authors prior to
joining Intel/Microsoft, when authors worked as chief executives of several
large Russian/Ukrainian software outsourcing companies

We had a chance to look at outsourcing projects from both sides of the ocean
3
Intel in 2003
35 years old (founded in 1968)
78,000 people, 294 offices and facilities
in 48 countries
Over 450 products and services
Revenue of $30.1 billion
Net income of $5.6 billion
R&D Investment of $4.4 billion
R&D is distributed all over the world
4
Microsoft in 2003
29 years old (founded in 1975)
55,000 people, 89 subsidiaries
Revenue of $32.2 billions
Net income of $10 billions
R&D investment: $5.2 billions
As a general rule, all development is carried out
at main campus in Redmond, WA
5
What Is a “Process Pattern”?
A Pattern is a description of a general solution
to a common problem or issue from which a
detailed solution to a specific problem can be
determined
A Process Pattern is a specific Pattern created
for, employed within or defined in terms of
Software Process Engineering domain
Software Process Engineering is a knowledge
area concerned with the definition,
implementation, assessment, measurement,
management, change, and improvement of the
software engineering process itself
6
In This Presentation
We will use MSF in our examples. To understand these examples one
does not need to know MSF. However some experience in one of the
modern IT management methodologies/frameworks (RUP, MSF, CDM
etc.) is required
The Microsoft Solutions Framework (MSF) is a collection of
Microsoft's proven practices on managing successful IT projects
Microsoft almost does not market MSF and they are not selling it.
Instead, Microsoft is focused on making money using MSF
Similar to Windows or any other product, MSF evolves and matures
as new versions are released. Initially Microsoft made MSF available
in 1994. The latest version of MSF is 3.0 and it was published last
year
You cannot buy this product from Microsoft, but you still can get it –
it’s free. Both whitepapers describing MSF and sample templates for
MSF lifecycle deliverables are available on the Microsoft web-site
7
Software Outsourcing: Typical Models
Different approaches to adapting modern software development management
methodologies and frameworks to offshore outsourcing projects are possible
US / Europe
Development
company
Mediator
company
Client
Development
office
Main office
Client
CIS - Commonwealth of Independent States (Russia, Ukraine and other former Soviet countries) 8
client gets PRODUCT or service
development office provides SERVICE
CIS
How Many Borders Do We Have?
Europe / US
CIS
US/Europe
office
CIS office
language
barrier
time
shift
Client
cultural
difference
s
9
Single-Site Development
a strategy
an organizational structure
business processes
10
Distributed Development
How to distribute/customize a strategy, an organizational
structure and business processes?
CIS
US / Europe
11
Process Patterns
For Distributed Development
Introduction
Organizational Patterns
Process Patterns
Transitional Patterns
12
Software Outsourcing: Typical Models
Different approaches to adapting modern software development management
methodologies and frameworks to offshore outsourcing projects are possible
Europe / US
Development
company
Mediator
company
Client
Development
office
Main office
Client
CIS - Newly Independent States (Russia, Ukraine and other former Soviet countries)
client gets PRODUCT or service
development office provides SERVICE
CIS
13
Software Outsourcing:
the “Broken Phone” Game
CIS
“Technical”
people
US / Europe
“Business”
people
Client
When a technical person speaks to a business person, some
information is often lost or misinterpreted
When two specialists from different countries speak over the
ocean, some information is often lost or misinterpreted
So, imagine what happens when a technical person speaks to
a business person over the ocean…
14
MSF Team Model
Delivering the solution
within project constraints
Satisfied
customers
Program
Management
Product
Management
Building to
specification
Development
Communication
User
Experience
Enhanced user
effectiveness
Test
Release
Management
Approval for release only
after all quality issues are
identified and addressed
Smooth deployment and
ongoing operations
15
MSF Team Model for Software
Outsourcing Projects
CIS
Europe / US
Program
Management
Development
Test
Product
Management
User
Experience
Release
Management
16
Our Solution: In Software Outsourcing
Projects All Functional Areas Should be
Covered on Both Sides
CIS
US / Europe
Program
management
Program
management
Product
Management
Product
Management
Development
Development
User
Experience
Test
User
Experience
Release
Mngmnt
Test
Release
Management
17
MSF Team as a Matrix Organization
An MSF team is structured as a team of peers. In this
model, the Program Management role takes a highly
facilitative approach to managing the functions within its
responsibilities. As such, the MSF team would
organizationally be structured similarly to what is referred
to in the PMBOK as a Matrix Organization. These are
cross-functional teams that combine the skills and foci from
difference areas of the organization into a single team
assembled for the project
Additionally, the MSF team, as a team of peers, would
most closely resemble a Weak Matrix Organization, in its
purest form, as described in the PMBOK. Here, “weak”
refers to the level of decision-making clout of the project
manager and not the quality or capabilities of the team
from MS whitepaper “MSF and the Project Management
Body of Knowledge”
18
Matrix Organizations
Organizational
Type
Functional
Project
Characteristics
Matrix
Projectized
Weak Matrix
Balanced Matrix
Strong Matrix
Little or None
Limited
Low to
Moderate
Moderate
to High
High to
Almost Total
% of Organization's
Personnel Assigned
Full-time
Virtually
None
0-25%
15-60%
50-95%
85-100%
Project Manager’s
Role
Part-time
Part-time
Full-time
Full-time
Full-time
Common Titles for
Authority PM’s Role
Project
Coordinator/
Project Leader
Project
Coordinator/
Project Leader
Project
Manager/
Project Officer
Project
Manager/
Program Manager
Project
Manager/
Program Manager
Project Manager’s
Administrative Staff
Part-time
Part-time
Part-time
Full-time
Full-time
Project Manager’s
Authority
PMI PMBOK
19
Functional Organization
Chief
Executive
Functional
Manager
Functional
Manager
Project
Coordination
Functional
Manager
Staff
Staff
Staff
Staff
Staff
Staff
Staff
Staff
Staff
20
Project
Coordination
Project Organization
Project
Manager
Chief
Executive
Project
Manager
Project
Manager
Staff
Staff
Staff
Staff
Staff
Staff
Staff
Staff
Staff
21
Weak Matrix Organization
Chief
Executive
Functional
Manager
Functional
Manager
Functional
Manager
Staff
Staff
Staff
Staff
Staff
Staff
Staff
Staff
Staff
Project
Coordination
22
Balanced Matrix Organization
Chief
Executive
Functional
Manager
Functional
Manager
Functional
Manager
Staff
Staff
Staff
Staff
Staff
Staff
Staff
Staff
Project Manager
Project
Coordination
23
Strong Matrix Organization
Chief
Executive
Functional
Manager
Functional
Manager
Manager of
Project Managers
Staff
Staff
Project Manager
Staff
Staff
Project Manager
Staff
Staff
Project Manager
Project
Coordination
24
Our Solution: MiniMax Pattern for
Geographically Distributed Matrix
Organizations
If a matrix organization is geographically distributed over
number of offices/countries/time zones

So it becomes 3D matrix
Each function should be present on as many sites as
possible

However, for offshore development some functions (i.e. sales)
may not make sense on some sites
Each project should be allocated to as few sites as
possible


This is an extension to the known approach called “collocation”
However, for offshore development each project will be allocated
to at least two sites
25
Process Patterns
For Distributed Development
Introduction
Organizational patterns
Process patterns
Transitional patterns
26
MSF Risk Management Discipline
Analyze and
Prioritize
Risk Statement
Identify
Risk
Assessment
Document
Control
Learn
Risk Database,
Risk Concepts and
Processes
Top n Risks
Plan and
Schedule
Track and
Report
27
Risk Management for Software
Outsourcing Projects
Europe / US
CIS
Analyze
and
Prioritiz
e
Risk Statement
Identify
Risk
Assessment
Document
Control
Learn
Risk Database,
Risk Concepts
and Processes
Top n
Risks
Track
and
Report
Analyze
and
Prioritiz
e
Risk Statement
Identify
Risk
Assessment
Document
Plan
and
Schedul
e
Control
Learn
Risk Database,
Risk Concepts
and Processes
Top n
Risks
Plan
and
Schedul
e
Track
and
Report
28
Our Solution: One Transparent Risk
Management Process
for All Sub-Teams
US / Europe
CIS
Analyze
and
Prioritize
Risk Statement
Identify
Control
Learn
Risk Database,
Risk Concepts and
Processes
Risk
Assessment
Document
Top n Risks
Plan and
Schedule
Track and
Report
29
IBM Rational Unified Process
Phases
Disciplines
Inception Elaboration
Construction
Transition
Business Modeling
Requirements
Analysis & Design
Implementation
Test
Deployment
Configuration Mgmt
Management
Environment
Preliminary
Iteration(s)
Iter.
#1
Iter.
#2
Iter.
#n
Iter. Iter.
#n+1 #n+2
Iter.
#m
Iter.
#m+1
Iterations
30
RUP Disciplines For Software
Outsourcing Projects
CIS
Europe / US
31
Our Solution: All Disciplines Are
Important For Every Sub-Team
US / Europe
CIS
Inception
Elaboration
Construction
Transition
32
Project Postmortem
A postmortem is a procedure whereby project team summarizes a project's history and analyzes its
positive and negative aspects. The goal of a postmortem is to draw meaningful conclusions to help
project team learn from past successes and failures
CIS
POSTMORTEM
Europe / US
POSTMORTEM
POSTMORTEM
33
Our Solution: “Big Postmortem” For All
Project Stakeholders
Unfortunately, it is not a common practice for offshore outsourcing projects today
Europe / US
CIS
P O S T M O R T E M
POSTMORTEM
POSTMORTEM
POSTMORTEM
34
One Of The GRASP Design
Patterns: Polymorphism
Problem:

How to handle alternatives based on type? How to create
pluggable components?
Solution:

When related behaviors vary by type, assign responsibility for
the behavior to types using polymorphism
PRO:


Extensions (new variations) easy to add
New implementations can be introduced without affecting clients
CON:


Avoid “future-proofing” if variation is unlikely to occur
Adds additional effort to design
35
Our Solution: Inheritance Helps
Minimize Bureaucracy
Traditional approach
C coding
standard
Our approach
General style
and coding
standard
C++ coding
standard
Java coding
standard
Total 64 pages
C coding
standard
C++ coding
standard
Java coding
standard
Total 34 pages
36
Our Solution: Define Your Process
Architecture Using Inheritance
CIS
US / Europe
CIS Office
Policy
US/Europe Office
Policy
Policy
Policy
Policy
Policy
Policy
Public Domain
Policy
Policy
Policy
Policy
37
Process Patterns
For Distributed Development
Introduction
Organizational Patterns
Process Patterns
Transitional Patterns
38
More Workload, More Resources…
Company
workload
Most companies
are in this area
Company size /
resources
39
A Few Words About Productivity…
Productivity of
employees
Most companies are in
this area
Number of
40
employees
Transitional Patterns
Transitional patterns deal with process
transformations during the period of rapid
growth/change of the company
When the company grows to more than 3-5
persons, a formal hierarchy of command should
appear
When the company grows to more than 40-50
persons, delegation of authority from the chief
executive to the middle managers is needed
When the company grows beyond 90-110
persons, formal policies and quality programs
become necessary for keeping the company on
track
41
MSF Readiness
Management Discipline
Define
Knowledge,
Skills,
Abilities
Assess
Evaluate
Change
42
Our Solution: Integrated
Readiness/Effectiveness/Transition
Management Discipline
Corporate
Knowledge
Base
Define
Assess
Evaluat
e
Change
Plan
43
Summary
MiniMax pattern helps organize work within
geographically distributed matrix organizations

All functional areas should be covered in all sites
Every discipline should cover all sub-teams

One transparent risk management process for all subteams
“Big postmortem” for all project stakeholders
Define your process architecture

Inheritance helps minimize bureaucracy
Integrated readiness/effectiveness/transition
management
44
See Also
Process Patterns


http://hillside.net/ (English)
http://www.ambysoft.com/processPatternsPage.html (English)
Microsoft Solutions Framework


http://www.microsoft.com/msf (English)
http://www.microsoft.com/rus/msf (Russian)
IBM Rational Unified Process

http://www.rational.com/rup (English)
PMI Project Management Body Of Knowledge


http://www.pmibookstore.org/PMIBookStore/productDetail
s.aspx?itemID=110&varID=1 (English)
http://www.pmi.org/info/PP_PMBOK2000Excerpts.asp
(English)
45
See Also
“Using MSF for Software Outsourcing” by V.Pavlov and A.A.Terekhov


http://nl.itsmportal.net/binaries/MSF_for_software_outsourcing.ppt (English)
http://www.ukrsoftpro.com.ua/Pavlov_Terekhov_Kiev2003.zip (Russian)
“MSF-based Process Patterns” by D.Malenko and V.Pavlov

www.itlab.unn.ru/archive/seminar/SE/1502_2.ppt (English)
“How to Train Managers for IT Industry?”
by V.Pavlov and A.A.Terekhov (Russian)


http://www.it-education.ru/archive/2003/reports/pavlov_terekhov.htm
http://www.it-education.ru/archive/2003/reports/presentation/pavlov_terekhov.ppt
"Software Process Improvement in Russian Company: a Case Study”
by V.Kiyaev, A.A.Terekhov


http://users.tepkom.ru/ddt/articles/SPI_in_Russia.html (English)
http://www.nsda.ru/home.asp?artId=129 (Russian)
“Formalization and Automation of Global Software Development Processes”
by V.Kiyaev, I.Sobolev, A.A.Terekhov, B.Fedotov


http://users.tepkom.ru/ddt/Articles/DistributedDevelopment.html (English)
http://users.tepkom.ru/ddt/Articles/DistributedDevelopment_rus.html (Russian)
46
Our thanks to:
Alexandr Zverintsev (NOKIA, Poland)
Alexandr Zhuykov (ISD, Ukraine)
Andrey Filev (Murano Software, USA/Russia)
Andrey Nizovsky (Waveaccess, Russia)
Anna Tiunova (Lanit-Tercom, Russia)
Irina Mozgovaya (DNU, Ukraine)
Nikita Boyko (ISD, Ukraine)
Sergey Alpaev (ISD, Ukraine)
Sergey Goryainov (Berest, Ukraine)
Sergey Troshin (Lanit-Tercom, Russia)
Symon Moldavsky (UkrSoftPro, Ukraine)
Victor Churilov (ISD, Ukraine)
Vladimir Ufnarovsky (Lanit-Tercom, Russia)
Yuri Gubanov (Lanit-Tercom, Russia)
Yury Us (SCC, USA)
47
You can download this presentation from
http://www.vlpavlov.com
http://www.soft-outsourcing.com
Questions?
48
This presentation was delivered
at the Fourth “Russian
Outsourcing & Software
Summit” (ROSS)
St. Petersburg
June 10, 2004
49
Download