Transcript C# 3.0 new features

Global Software
Development
Niels Hallenberg
IT University of Copenhagen
BAAAP – Spring 2009
www.itu.dk
Outline
• Global Software Development at Siemens:
Experience from Nine Projects Splitting the
• Organization and Integrating the Code:
Conway’s Law Revisited
• Agile Practices reduce Distance in Global
Software
www.itu.dk
Nine Projects at Siemens
• Methodology:
– 18 interviews, three Siemens sites
– Project management, technical leadership, middle
management positions and executive or senior
management roles
– Locations: Europe, India, US, Japan
– Interview topics
•
•
•
•
•
•
Role and responsibilities
Development divided among sites
How work was managed
Cross-site relationships
Processes and tools
Problems, issues and best practices
www.itu.dk
Nine Projects at Siemens
• Management and Control
– Incentives may differ among the sites
– There may be “hidden” tensions: job cuts,
competition, same functionalities goes in different
products.
– Decision-making having a negative impact on
product, eg., when decisions are made of
personal or political reasons and not for rational
or technical reasons - this also happens on single
sited projects.
• Project planning and tracking is a discipline
and differences will cause problems.
• Informal communication is very difficult
www.itu.dk
Nine Projects at Siemens
• Formal communication is slow and time consuming
and not always precise
– Examples of formal contra informal communication?
• Skills – are we satisfied with the other sites
programmers?
• Project insight at the other site – no information
often means that they are behind schedule.
• Projects involving integration relied heavily on
tracking information
• Late deliverables or deliverables of poor quality at
one site leave the other site with no work.
www.itu.dk
Nine Projects at Siemens
• Process compatibility:
– Translating formal documents
– Confusion about roles – what is exactly the role of
a project manager – does he make decisions or is
she basically an information gathering function.
• Engineering style: do you use lot of time on
design or do you make design and
implementation simultaneously.
• Process maturity: Poor process quality infer
late deliverables of poor quality. If you cant
provide a status for your project, then you
are probably performing poorly.
www.itu.dk
Nine Projects at Siemens
• Decision making: are staff at the lowest
technical level allowed to make decisions not
affecting functionality and schedule
negatively? This is highly cultural dependent.
• Development environment:
– Build capabilities at all sites – maybe even a
central build capability.
– Connection Speed!
• Collaboration technology – “is there really a
person over there”:
– Photo gallery
– Photo-annotated organization chart
www.itu.dk
Nine Projects at Siemens
• Communication
– You really needs to know who you ara talking to –
getting to know each other.
– Are you communicating through a project
manager (centralized) or directly between the
involved persons (decentralized)
– Do you understand the format that is
communicated – eg. UML or a home made class
diagram notation.
• The domain knowledge is very important –
an external contractor may have more need
for education than a newly hired employee at
your local site.
www.itu.dk
Nine Projects at Siemens
• Workshops are very effective – and all important
decisions should be made the last day.
• We want to meet people and spend time – also on
non professional matters
• Drink a few beers together – it makes a big
difference when problems occur.
• The way agreement and disagreement is expressed
differs among cultures!
• Some cultures are good at asking questions and
very precisely express their agreement and
disagreement. But other cultures may give the
impressions of agreement but actually it is just to be
polite.
www.itu.dk
Nine Projects at Siemens
• Time zones make it harder to have over
lapping working hours.
• YOU MUST DEVELOP TRUST
• ALWAYS SPEND YOUR TRAVELING BUDGET
AT THE START OF THE PROJECT
www.itu.dk
Integrating the Code
• Case study of integrating a geographically
distributed project.
• Project dimensions:
– Project structure: what is to be developed
– Development process: how is the project
developed
– Milestones: when is the milestones achieved
– Ressources: who is working on the project.
• Brooks law: if a project is late then adding
more people will slow the project even more.
• Capability Maturity Model (CMM – 5 levels)
• http://en.wikipedia.org/wiki/Capability_Maturity_Model
www.itu.dk
Integrating the Code
• It is impossible to avoid the unpredictable
and “outside-the-plan” actions.
• Informal communication is very important –
you do not know what you don’t know – and
informal communication often leads to make
the unkown known.
• The functionality of an Interface Specification
is hard to make precise:
– Two sites building simulators for the other sites
deliverables. Different assumptions got into the
simulators and the programmers didn’t realize
before integration started.
www.itu.dk
Integrating the Code
• Change Control Board (CCB)
– They must cover the entire project and still be
able to make decisions.
• Informal Communication:
– Who to contact.
– It is difficult to get an informal contact right away
– time zone etc.
– Language barriers
– Lack of trust for an openly communication
• Unplanned contacts are very important!
• You must communicate even though there is
no reason for it – why? Many problems are
unknown.
www.itu.dk
Integrating the Code
• Efficient communication:
– Do communicate cross site even though its expensive and
troublesome.
– Publish your calendar openly – else people will ware time
trying to get in contact with you
– Agree on communication slots if you are working long
distances.
– Reduces responsiveness is hard to avoid when working
across sites.
– Consequences are high if you don’t communicate
– Communication is hard when you can’t see what the other
site is talking about, eg. a detail on a GUI.
– Use communication different communication technologies:
email, chat, wiki, skype, etc.
– YOU MUST PUSH THE COMMUNICATION
www.itu.dk
Lessons Learned
• Reduce the need for cross-site
communication:
– Modular and independent modules
– Products must have well understood boundaries
• Overcome barriers to informal
communication:
– Travel at the beginning of the project.
– Build relationships
– Use appropriate tools
www.itu.dk
Agile Practices
• Agile Development Methodologies in Global
Software Development (GSD)
– XP
– Scrum
• Agile methods are characterized by short,
iterative cycles of development driven by
product features, periods of reflection,
collaborative decision making, incorporation
of rapid feedback and continuously
integration of code.
• Agile in GSD is difficult because
communication is difficult.
www.itu.dk
Agile Practices
• Distributed eXreme Programming – practices
that are independent of location:
– Small releases, simple design, testing, refactoring
and coding standards
• Practices that is highly dependent on
location:
– Planning game, pair programming, continuous
integration and on-site customers
• This study asks: can agile methods be used
to reduce the negative influence of distance
on communication, coordination, and control
in a GSD context?
www.itu.dk
Agile Practices
• Locations: US, Ireland, India, Poland, China
and Malaysia
• Challenges with Temporal Distance:
– Time zones
– You get behind a discussion – happended while
you were at sleep.
– Slow responsiveness
• Challenges with Geographical Distance:
– Hard to build trust – we are two separate teams
– Also people at the technical level should meet
physically
– Plan when people should meet face-to-face, fx
while integration
www.itu.dk
Agile Practices
• Challenges with Sociocultural Distance, that
is company culture, national culture and
language.
– Language limitations – it is harder to socialize in a
foreign language than talking technicalities.
– In some cultures it is impolite to say no – can you
deliver on Monday – yes – and still three month
later there had been no delivery.
– Different interpretation
www.itu.dk
Agile Practices
• Conclusions – GSD benefits:
– XP and Scrum improve communication,
coordination and control
– XP pair programming -> collective ownership,
higher and coherent code quality
– XP simple design -> design documents evolve
while coorporating
– XP refactoring -> bugs are eliminated
– Scrum planning game -> project activities are
shared openly
www.itu.dk
Agile Practices
• Conclusions – GSD benefits:
– XP Pair programming -> increase time overlap
and reduce temporal distance
– Scrum planning game -> increase “teamness”
and reduce geographical distance
– XP pair programming and Scrum pre-game phase
-> increase mutual understanding and reduce
sociocultural distance.
www.itu.dk