Professional Documents
Culture Documents
Lecture 4
People not process The skills of the development team should be recognized and
exploited. Team members should be left to develop their own
ways of working without prescriptive processes.
Embrace change Expect the system requirements to change and so design the
system to accommodate these changes.
Maintain simplicity Focus on simplicity in both the software being developed and
in the development process. Wherever possible, actively work
to eliminate complexity from the system.
SIMPLICITY
COMMUNICATION
FEEDBACK
AGGRESSIVENESS
SIMPLICITY
Means that the software is developed using the simplest possible design and
constructs, but it means more.
One of our rules is “You aren’t going to need it,” which reminds us to add
software or process only when we really need them, not in anticipation of
need.
COMMUNICATION
is key to rapid development and to customer satisfaction.
The on-site customer decides what will be built and in what order.
FEEDBACK
is important to any development process, but when you are trying to eliminate
everything you can, you need feedback to be sure you’re on track. Software testing is a
major source of quality feedback in XP, but we include resource, scope, and time
feedback as well.
AGGRESSIVENESS (or courage)
in moving forward is possible when you take the simplest possible approach and
employ a process high in communication and feedback. In other words, doing the right
thing even when it is not the most popular thing to do. It means being honest about
what you can and cannot do.
Practices:
There are twelve XP practices that the team should depend on when
adopting XP.
The Planning Process
Small Releases
Testing
Metaphor
Simple Design
Refactoring
Pair Programming
Collective Code Ownership
Continuous Integration
Sustainable Pace
On-site Customer
Coding Standard
The Planning Process
The team releases running, tested software, delivering business value chosen by the
Customer, every iteration.
Testing
• also known as customer tests
XP teams focus on validation of the software at all times.
Customers provide acceptance tests that enable them to be certain that the features
they need are provided.
Metaphor
• XP teams develop a common vision of how the program works, which we call
metaphor.
• In other words they use a common "system of names" and a common system
description that guides development and communication.
Simple Design
• A program built with XP should be the simplest program that meets the current
requirements. There is not much building "for the future". Instead, the focus is on
providing business value.
Refactoring
• or design improvement
• XP programmers work hard and at a pace that can be sustained indefinitely. This
means they do not work overtime, unless it’s effective, keeping themselves fresh,
healthy, as to reduce as much as possible mistakes.
On-site Customer
• An XP project is steered by a dedicated individual who is empowered to determine
requirements, set priorities, and answer questions as the programmers have them.
The effect of being there is that communication improves, with less hard-copy
documentation often one of the most expensive parts of a software project.
Coding Standard
• For a team to work effectively in pairs, and to share ownership of all the code, all
programmers need to write the code in the same way, with rules that make sure
the code communicates clearly.
The extreme programming release
cycle
Small releases The minimal useful set of functionality that provides business
value is developed first. Releases of the system are frequent
and incrementally add functionality to the first release.
Simple design Enough design is carried out to meet the current requirements
and no more.
Test-first development An automated unit test framework is used to write tests for a
new piece of functionality before that functionality itself is
implemented.
Refactoring All developers are expected to refactor the code continuously as
soon as possible code improvements are found. This keeps the
code simple and maintainable.
Chapter 3 Agile software development 30
Extreme programming practices (b)
Pair programming Developers work in pairs, checking each other’s work and
providing the support to always do a good job.
Collective ownership The pairs of developers work on all areas of the system, so that
no islands of expertise develop and all the developers take
responsibility for all of the code. Anyone can change anything.
Continuous integration As soon as the work on a task is complete, it is integrated into
the whole system. After any such integration, all the unit tests in
the system must pass.
Sustainable pace Large amounts of overtime are not considered acceptable as
the net effect is often to reduce code quality and medium term
productivity
On-site customer A representative of the end-user of the system (the customer)
should be available full time for the use of the XP team. In an
extreme programming process, the customer is a member of
the development team and is responsible for bringing system
requirements to the team for implementation.
Chapter 3 Agile software development 31