AWB - 11 - Extreme Programming

369 Agile White Book – AXA Emerging Markets EMEA-LATAM
Chapter 11
EXTREME PROGRAMMING
V1.0

Contents
DIAGRAM........................................................................................................................................................................................................ 372
EXTREME PROGRAMMING AT A GLANCE .......................................................................................................................................................... 373
WHY DO YOU NEED XP?.......................................................................................................................................................374
UNDERSTAND THE IRON TRIANGLE AND RISKS...........................................................................................................................375
KNOW THE CORE OF EXTREME PROGRAMMING........................................................................................................................................................ 379
VALUES..............................................................................................................................................................................380
PRINCIPLES.........................................................................................................................................................................382
BEST PRACTICES ................................................................................................................................................................................................ 383
TEST DRIVEN DEVELOPMENT.................................................................................................................................................384
ACCEPTANCE TESTS .............................................................................................................................................................387
PLANNING GAME ................................................................................................................................................................388
WHOLE TEAM TOGETHER .....................................................................................................................................................389
PAIR PROGRAMMING ...........................................................................................................................................................390
CONTINUOUS INTEGRATION ..................................................................................................................................................391
DESIGN IMPROVEMENT (REFACTORING)..................................................................................................................................392
SMALL RELEASES .................................................................................................................................................................394
SIMPLE DESIGN...................................................................................................................................................................395
SYSTEM METAPHOR ............................................................................................................................................................396
COLLECTIVE CODE OWNERSHIP..............................................................................................................................................398
CODING STANDARD AND CONVENTIONS..................................................................................................................................399
SUSTAINABLE PACE..............................................................................................................................................................400
SPIKE TO REDUCE RISK ..........................................................................................................................................................401
XP OVERALL CHARACTERISTICS .............................................................................................................................................................................. 402
SCRUM AND XP ..................................................................................................................................................................403
TAKE AWAY.................................................................................................................................................................................................. 404

Extreme Programming
Extreme programming is a methodology which
helps avoiding large, up-front design approaches
found in many software projects. It focuses on short
development cycles with high-quality and regular
potential software increments to the customer. It
also reinforces team working, good programming
practices and can be fully integrated into Scrum.

Diagram
EXTREME PROGRAMMING
I know the Extreme Programming benefits.
I know the XP essence and good practises.
I know the techniques for continuous improvement.
XP
BENEFIT
S
KNOW THE
XP ESSENCE
- Values
- Principles
- Project
variables
PRACTISES &
CONCEPTS
- Spiking
- Small Release
- Team practises
- Code practises
LEARN ABOUT
IMPROVEMENT
TECHNIQUES
- Refactoring
- Test-driven dev.
- Continuous integration
- Continuous deployment

EXTREME PROGRAMMING at a glance
Extreme programming (XP) is an Agile software development methodology which helps improve
software quality and responsiveness to changing customer requirements. It offers quick
feedback with frequent releases and short development cycles. This intends to improve
productivity and introduce checkpoints where new customer requirements can be accepted and
implemented.
XP includes practices and values which are compatible with the ones found in Agile. It
integrates a set of widely used and disciplined engineering tools, such as Unit Testing,
Continuous Integration, Refactoring and regular and responsible communication between
Business and IT.
Most of the concepts and practices found in Scrum are also used in here, such as Release
Planning, Estimation, Sprints with Customer Reviews, Daily meetings and User Stories
to capture requirements, so you will find XP familiar.
XP mainly focuses on keeping things simple and try to reduce complexity everywhere.

WHY DO YOU NEED XP?
We have seen in many traditional initiatives a common set of problems that make projects less
flexible and add several risks, such as:
- Business does not clearly understand requirements.
- Schedule slips.
- Business pressure on development teams reduces code quality.
- Increase defect rate and lack of code standards.
- Increase technical debt/unmaintainable codebase.
- Lack of motivation in teams.
- Lack of Team commitment.
These problems become critical but are not fully considered in traditional methodologies.
As I see, all these problems are tied up very closely and a complex solution that involves the
Team and technical approach is needed in order to:
 Reduce project risk.
 Improve responsiveness to business changes.
 Improve productivity throughout the life of a system.
 Add fun to building software teams and keep people motivated.

As Time is a strong variable in here, it
influences the dependencies between this
and the others.
UNDERSTAND THE IRON TRIANGLE AND RISKS
The heart of XP contains four main variables (Cost, Time, Quality and Scope) that are used
during the product development cycle, where Time is a prevailing element.
This is a huge difference with traditional methodologies where other parameters are used.
Cost – Indicates the amount of money to be spent in the initiative, people and
resources available (computers, equipment, logistic, etc.).
Time - Establishes when the product is expected to be released and its milestones or
intermediate goals.
Quality - The accuracy of the system as defined by the client and how well tested it
is.
Scope - What and how much functionality is included in the product and when.

The previous idea is to provide a clear relationship between them to help predict different
behaviours during a project lifecycle.
Let’s me show you some examples:
- If Quality is increased, then Time needs to increase as more testing is needed.
- If Quality is decreased, then short-term time is reduced to a certain degree as
the number of functional tests are reduced (but technical debt is also increased.)
- If Cost is increased (taking on board more developers) then it could mean less time
but also the opposite effect which is more Time (i.e. more people late in a project
can increase overhead of communication).
- If Cost is decreased, then Time increases dramatically.
- If Scope is increased, then more Time is needed as there is more work to do.
- If Scope is decreased Time is reduced.
If for example, Scope is increased (more features are “pushed” into the team) and Quality and
Cost are held (same people and other resources), then Time must be increased in order to get
predicted results. There is a special situation here that arises when Scope is increased and
Time is fixed; XP prevents this situation by clearly stating that:
 Business can control Cost, Quality and either Time OR Scope.
 The remaining variable is owned by development.

There are other risks associated that can jeopardise the whole project. Let’s take a look first at
these threats and see later how we can help diminish them:
- Change in Requirements
There is a spread idea that requirements can be frozen or fixed in advance. We
believe that there are changes in almost all the cases as a result of:
o Users needing one or more changes as they learn a better way to solve
a problem.
o The problem changes as clients discover what they want and get it by
only seeing working software.
o There are market variations which make rules to change in an
unpredictable way.
o Elements are immature, imprecise or not fully understood.
- Technology
Two areas generally related to the Development Team but that compromises
everyone:
o New or not well-known technologies/tools.
o People with lack of a required new skill.
o Technical debt, where poor software architecture and
development exacerbates the time to market.
- Performance
Products that have problems regarding expected response time or work load.

In order to target the previous areas and bring a sustainable solution, XP provides guidelines for
Business and IT people:
Business people (Stakeholders, Product Owners, etc.)
o Are part of the Team.
o Give frequent feedback based on working software increments.
o are involved and writes requirements from their perspective.
o Define Scope (what the system have to do).
o Set Priorities (which requirements are more important).
o Define the Release contents and when timeline.
(What makes up each release and when to deploy it).
Development Team
o Understands all requirements well.
o Decides what is needed in order to consider a requirement
complete.
o Estimates and decides what to take on board (Pull system).
o Decides how to build a product in terms of technical
architecture.
o Evaluates the consequences (what the implications of making a
particular decision are.)
o Feel proud and responsible for their work.

KNOW the core of Extreme Programming
XP uses Values, Principles and Best Practises to establish some clear boundaries and allow
people work in harmony with personal and corporate values while staying aligned to clear beliefs.
That helps reduce risks and establish a concrete way of work.

Extreme Programming - values
VALUES
Values are a vital part to understand why XP works; people clearly need to interiorise them in
order to get its day-to-day benefits.
Simplicity
Teams will do everything needed and requested but nothing else. This helps maximize
the value created for the investment made. Small and simple steps should be taken
towards a goal and clear measures established to mitigate failures as they happen. People
should create something they are proud of and maintain it long term at a reasonable cost.
Communication
Everyone is part of the Team and daily face to face communication is a need. People
work together on everything from requirements to code.
Feedback
All iterations commitments are taken seriously by delivering working software.
Software is early and often demonstrated and requested changes are carefully listened from
clients. People will talk about the project and adapt its process to it, not the other way
around.
Respect
Everyone gives and feels the respect they deserve as a valued team member. People give
value even if it's simply enthusiasm. Developers respect the expertise of the customers and
vice versa. Management respects the right from people to accept responsibility and
receive authority over their own work.

Values need to be shared in order to avoid
creating a dysfunctional system!
Extreme Programming – values
Courage
People tell the truth about progress and estimates. They don't document excuses for
failure because they plan to succeed. Individuals don't fear anything because no one ever
works alone. People adapt to changes whenever they happen.
If people continuously give importance to different things, they won't converge on an agreement
but each will undermine the efforts of the others.

Extreme Programming - principles
PRINCIPLES
There are 3 principles that form the core of XP and are based on the values described above; they
are intended to foster decisions during the product development lifecycle. Principles are more
concrete than values and easily translated to guidance in practical situations.
Feedback
We believe in frequent and prompt feedback. It means that a minimal delay between
an action and its feedback is critical to learn and make changes. The customer should have
a clear insight into the system that is being developed, and should be able to give feedback
and steer the development as needed. As we will see later, Unit testing contributes to this
principle.
Assuming simplicity
XP treats every problem as if its solution were "extremely simple". Traditional software
development methodologies try to plan for the future and to code for reusability. Extreme
programming rejects these ideas.
Embracing change
People should never be working against changes but embracing them. If something has
changed dramatically, people need to embrace this and plan the new requirements for the
next iteration.

All of these things allow me
to do my job better!
Best practices
We finally have 12 engineering practises that help bring the whole team together, support
frequent feedback and enable people see where they are.

Best practices
TEST DRIVEN DEVELOPMENT
Quality assurance is essential when creating software and Testing is a core technique in XP to
accomplish it. Despite its name, Test Driven Development is a programming practice, not a testing
technique. It is more about setting concrete, detailed expectations in advance, and allowing those
expectations of code behaviour to guide the implementation than it is about testing. Let’s start with
Unit Test…
A Unit Test is a piece of code that is automated and test functionality such as a class, method,
function, etc. We will also see another type of test called Acceptance Test which is used to check
client expectations such as requirements. One main difference is that Unit Tests are always written
before the implementation is coded.
A common test-driven development sequence looks something like the following:
Create a Unit Test that exercises the functionality that you intend to develop.
Compile your Unit Test. It will fail to compile, because the code you’re trying to test
does not exist yet.
Write just enough functionality to allow the Unit Test to pass.
Run your test(s). It will fail, because you haven’t actually implemented the class.
Write your class implementation.
Run your test again until it passes.

You should follow these three laws:
- Not to write production code unless you’ve
first written a failing unit test.
- Not to write more of a unit test than is
sufficient to fail.
- Not to write more production code than is
sufficient to make the failing unit test pass.
Best practices
Because most of the TDD tools use a red signal when a test doesn’t work, and green when it does, we
refer to this flow as Red-Green-Refactor.
Extracted from thealmightyjenny.com
We have seen that test-driven development gives developers the confidence to make changes to
the product, because they know that the tests will tell them if they have broken anything and where.
We found this as one of the most effective feedback mechanisms that the development team can
have for guaranteeing stability and high quality. This approach also helps people think about
conditions in which code could fail. XP says that a specific implementation is finished when the
developer can’t come up with any further realistic condition on which the code may fail.

Best practices
You should always have in mind that a coding task in XP is split in very small steps, starting always with
the tests. The following is our recommendation when coding a requirement:
Read the User Story (requirement) and analyse what is needed in order to consider it
as done.
Write a Unit Test first, thing which will help you think of the solution before
implementing a single piece of the solution.
Implement just enough code to make the tests run.
Refactor/Simplify the code if necessary.
Integrate the changes into the codebase and, if problems occur, resolve them. If the
issues cannot be resolved, start over.

Best practices
ACCEPTANCE TESTS
A requirement in XP is written by following information contained in a User Story and a further
communication with the client. A User Story has one or more sentences of what the user need in the
everyday language of the business, all captured in a card.
One very positive aspect about them is that they have a list of what is needed in order to consider the
requirement complete (Acceptance Criteria). It is here where a second kind of test called Customer
Tests or technique Acceptance Test-Driven Development (ATDD) comes into play.
ATTD focuses on testing the functionality from the user’s point of view to ensure that the system
implements the expected requirement and behaviours (i.e. Insurance was cancelled and client notified).
When using them, Business and IT collaborate to produce testable requirements to make sure they
are fulfilling the clients’ requirements. Check Chapter 4 (Agile Requirements) for more details.

Best practices
PLANNING GAME
Business and development work together to produce the maximum business value as rapidly as
possible.
The planning game happens at various scales and its rules are:
Business comes up with a list of desired requirements for the product. Each
feature is written as a User Story.
Development estimates how much effort each User Story will take, and
how much effort the Team can produce in a given cycle.
Business then decides which stories to implement in what order, as well as when
and how often to produce a product release.
Development Team analyses its capacity and sees what to take on board.

Best practices
WHOLE TEAM TOGETHER
In XP, the Development Team has continuous access to the customer who will actually be using the
product or sit together to answer questions straight away.
A customer representative (i.e. Product Manager) can be designated or, if Scrum is used, the Product
Owner will be the vital link. We strongly recommend an open space office in order to encourage full
communication.

Best practices
PAIR PROGRAMMING
Pair programming is a method of programming in which two people work and share knowledge
together. One person, temporarily types at the keyboard and the other reviews each line of code as it
is typed, checking for errors and thinking about the overall design.
Some benefits you can expect are better code (simpler design, fewer bugs, more maintainable),
higher morale (more fun!), shared knowledge throughout your team (both specific product and
general programming knowledge), better time management, higher productivity. It also reduces
the truck factor (“Number of people on your team who have to be hit with a truck before the project
is in serious trouble”).
This is the ABC´s of pair programming that you should not forget:
 All production code must be developed by the pair.
 Both parties contribute to the solution switching roles frequently.
 Change pairs frequently one to three times a day.
 Develop at a comfortable computer that accommodates the people side by side.
 End Pairing when people are tired. There is a suggestion here that no more than 2/3 of a day
should people be pairing.
There are some games that can be played to encourage pairing and make the activity more enjoyable.
Pairing is also a great tool when you have senior and junior people working together as they make
sure that knowledge is shared and the best possible code is produced.
Remote pairing can also be done but you need to double check that the tools to support a fluent
communication are available (Check chapter 13 for more information about distributed Teams).

Best practices
CONTINUOUS INTEGRATION
Continuous Integration (CI) is a practise coming from Extreme Programming (XP) that uses a tool
which helps developers integrate code and Unit Tests into a shared repository several times a
day. Each time a developer checks-in their modifications/additions, the product is compiled, verified
and tested by an automated build, allowing teams to detect problems early. By integrating regularly,
people can detect errors quickly, and locate them more easily. Unit Tests are also run 100% before
and after integration.
Inspired by simple-talk.com
We have seen that infrequent integration leads to serious problems on software products. Weak
integration process leads to long development paralysis which means that people have long time
periods where they could be working on important features instead of endlessly trying to find bugs.
Continuous Integration requires members to:
 Check in frequently.
 Try not to check-in broken code.
 Avoid checking-in untested code.
 Never check-in when the build is broken.
 Never go home after checking-in, wait until the product is fully built.
 Make sure the build is self-testing.
You can also use Continuous Deployment, which is the practice of potentially releasing a good build
to users, every time a change is made. By adopting both Continuous Integration and Continuous
Deployment, you not only reduce risks and catch bugs quickly, but also move rapidly to working
software and getting continuous feedback from customers.

Best practices
DESIGN IMPROVEMENT (REFACTORING)
As we mentioned before, XP advocates developing only what is needed today, and implementing it
as simply as possible. One of the drawbacks with this approach is the need for constant maintenance. It
is here where a technique called refactoring is used to improve or remove duplicated code generated
during a coding session.
Refactoring is also a great lesson in understanding an unfamiliar code. It is basically a number of
transformations that preserve code behaviour while focusing on simplicity. As automated tests are
widely used, refactoring is simplified as changes can always be verified.
The steps to refactoring code are:
Run the Unit Test(s) associated to the functionality you want to refactor.
Improve/Simplify the code.
Run Unit Test(s) again and make sure they all pass and performance is good.

Best practices
As you can see, the process of writing Unit Test solidifies your understanding and expectations of the
code before started working on it. The following are some of the common techniques used during
refactoring:
Extract Method Allow define a new method based on a selection of code already
existing in a method.
Encapsulate field Turns a public field into a private one by encapsulating it as a
property.
Extracts interface Defines a new interface type based on a set of existing type
members.
Reorder
parameters
Provides a way to reorder member arguments.
Remove
Parameters
Removes a given argument from the current list or parameters.
Rename Renames a code token (method, field, local variable, etc.)
throughout a project.
Promote Local
Variable to
Parameter
Moves a local variable to the parameter set of the defining method.
Check “Additional Resources” section for more information about different techniques to refactor
software.

Best practices
SMALL RELEASES
In XP, delivery of the software is done via frequent releases of working software that creates
concrete business value. The small releases help the customer to gain confidence in the progress
of the project and keep everyone aligned with the current progress.
A small release is also cheaper than having big chunks delivered every few months as they allow
people to see a working piece of software and get the return of investment more quickly. It also helps
maintain the concept of the whole team as the customer can now come up with suggestions on the
product based on real hands-on experience.
The idea is simple… code and small releases mean that you are traveling light: low up-front investment,
and not much to slow you down when needing a change. Remember that not all the releases need to
be public but can be available if needed.
A roadmap can also be used as an invaluable tool to associate specific releases with times and help
align everyone´s expectations. Check Chapter 6 for more details.

Whenever a new piece of code is written, we ask… 'is
there a simpler way to introduce the same
functionality?'
Best practices
SIMPLE DESIGN
In XP a "simple is best" approach to software design is always favoured
A good trick for simple design is to think that everything in the system to be designed from the
beginning will have little or no change throughout the development life cycle. Having in mind this
idea, keep developers away from trying to predict the future and forces the design to be just
enough to meet what is known about the system today.
It does not mean that no design is needed during the Release/Sprint Planning but that it needs to be
“barely” sufficient. The detailed design starts during the first sprint and evolve in the subsequent
iterations.
For this process to work, XP uses incremental an iterative software development. Iterative means
that you write loads of stuff that works but is a complete mess and then start refining it. Incremental
means that you write Part A and then add part B until the whole system has all the desired
characteristics.

Best practices
SYSTEM METAPHOR
A system metaphor is a story that everyone involved (Business, IT, etc.) can tell about how the
system works. XP uses a metaphor instead of a formal and detailed architecture, which means, a simple
shared tale of how the system works. This story typically involves a handful of classes and patterns
that shape the core flow of the system being built. Albert Einstein said "Explain it to me like I was a
four-year-old kid". Metaphors create a way for everyone to share a common vision of what the system
is.
If a customer tells the Development Team that the system needs an Insurance shopping cart feature (a
metaphor), they should not have the need to initially go into significant detail as everyone knows what
it is.
You don’t need the fine detail in order to clearly understand what it entails.
System Metaphors generally help everyone:
- Define a common vision.
- Create a shared vocabulary.
- Think of the whole system and proactively bring new ideas.

Best practices
One of the usual techniques to create a metaphor is by organising a brain storming session, it means,
a fixed-time meeting where everyone brings ideas about the system. Before the session, ask people
to think of the whole system and have the most important objects in mind as well as its patterns and
interactions.
Follow these rules for a successful brainstorming session:
- Do not criticise ideas.
- Encourage people to get huge number of ideas (and after the session focus on quality).
- Hunt for wild ideas and have fun.
- Give opportunity to everyone to participate.
- Encourage building on each other´s ideas.
Have in mind that metaphors only describe the logical architecture of the system in order to
keep it simple to understand. This is, in the case of an object oriented system, the most important
classes and objects and how they interact.

As a general rule, anyone can “touch” anything but we (the
whole Team) are responsible for the results. This transforms
us from being a group of individuals to a Team of highly
committed people.
Best practices
COLLECTIVE CODE OWNERSHIP
In traditional development you divide an application in functional areas and assigning ownership of
components or subsystems to specific individuals. The main issue with this approach is that creates
bottlenecks which obstruct development when the component or subsystem owners are flooded with
work. The result is a queue that affects other team members and creates a huge chain of delays,
making more pressure on individuals and placing them in difficult situations.
XP uses the concept of Collective Code Ownership to eliminate bottlenecks, remove silos and
share knowledge. In here, any developer has the right to change or enhance any piece of code
within the application. It also motivates everyone to contribute new ideas to all segments of the
project. Any developer can change any line of code to add functionality, fix bugs, improve design or
refactor.
Collective code ownership also encourages the transfer of knowledge among all people in the Team.
As information is spread across and communication improves, the risk of people with specific skills not
being unavailable and affecting the Team becomes lower.

Best practices
CODING STANDARD AND CONVENTIONS
XP projects use guidelines and rules for naming and formatting code. This specifies a style and
format for source code, within the chosen programming language, as well as various specific
constructs and patterns that should be avoided in order to reduce the probability of defects. The
first step is for the Team to explicitly agree on a set of code conventions specified by the language or
created by them. This means that each person chooses the names of classes, methods, variables etc.
and makes sure they comply with the “rules”. Using them assures a more consistent product so that
it is easier to read, understand, extend, refactor, etc. It also facilitates the journey to new members
through the product. We recommend applying the following 2 guidelines:
- Create the minimal set of standards you can live with.
- Focus on consistency and consensus over perfection.
One way you can start a coding standard is by selecting an industry-standard style guide for the
language. This will make sure you focus on the design and forget about the formatting.
When we talk about code-standards we are talking about the followings:
- Tools and IDE related.
- File and directory naming.
- Build conventions
- Error handling and assertions
- Approach to events and logging
- Practical cases conventions (i.e. how to deal with null references)
As a general rule, if developers find some part of the product that doesn’t follow the standards, they
should refactor it accordingly.

Best practices
SUSTAINABLE PACE
Projects are usually extensive with overtime and many superhuman efforts to deliver by a promised due
date. The result is an exhausted Team, less productive and a lower quality product.
The assumption in XP is that software development is not a sprint but a marathon. While a sprinter
will easily beat a marathon runner over a very short distance, the second will always win in the
long run. The idea is that Teams do not take on more work than they have proven to be capable of
completing, which will ensure a cadence and help people perform best, most creatively, estimate and
predict the future better.

What is the simplest thing we can program that
will convince everyone we are on the right
track?
Best practices
SPIKE TO REDUCE RISK
A spike is a commonly-used technique to reduce risks in projects. A spike is basically a User Story that
cannot be estimated until a development team runs a time-boxed investigation. They may be used
for a number of reasons:
- The team may not have knowledge of a new domain and can be useful for familiarising
the team with a new technology or domain.
- The User Story (requirement) may be too big to be estimated appropriately and can
help analyse how to split the story into estimable pieces.
- The User Story may contain significant technical risk, and the team may have to do
some research or prototyping to gain confidence in a technological approach.
- The User Story may contain significant functional risk and were not clear how the
system needs to interact with the user.
A Spike should always be wrapped into a Product Backlog Item and a maximum number of hours
should be specified. Remember that the output of a spike story is an estimate for the original
story.

XP overall characteristics
Let’s review the main Extreme Programming characteristics used in product during the product
lifecycle:
- Planning game is used; constant feedback and embracing change are day-to-day
activities.
- Highly interactive small teams are in place (2-12 persons).
- Open space offices are the right environment.
- IT and Business cooperate and communicate in a regular and honest way.
- Interactions such as workshops or demos are encouraged and frequent.
- User Stories, Refactoring and Code Standards are heavily used.
- Tools to support Continuous Integration and Change Management (code
repository) are in place.
- XP Values and Principles are always present and widely used.

All of these things together
work very well for us!
XP overall characteristics
SCRUM AND XP
While Scrum manages the steps to develop a product, XP focuses on keeping the quality of
the software. Scrum uses a fix number of meetings and practises, such as Sprints, Sprint
Planning, Daily Scrum, Retrospectives, etc. and a number of roles that are defined in the
framework. When used along with XP, all their practises are added into the day-to-day (simple
design, Continuous Integration, Pair Programming, Code repositories, etc.) in order to get the best
of the two worlds.

TAKE AWAY
REMEMBER
 Business is heavily involved and working with IT
 Fast and collaborative short lifecycles and feedback loops are a characteristic.
 Business value is the trading currency.
 Extreme Programming Values and Practises are needed in order to implement it.
 Engineering Practices are used by teams & sharing information is a day-to-day experience.
DEEPEN YOUR KNOWLEDGE
 Extreme Programming Organisation
 Refactoring Techniques(I)
 Refactoring Techniques (II)
 Ping pong pairing game
BENEFITS
 Encourages communication between Business and IT.
 Focuses on small releases and constant feedback.
 Offer clear and very productive engineering practises.
 Reassures simplicity in everything done.

AWB - 11 - Extreme Programming

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (12)

Similar to AWB - 11 - Extreme Programming

Similar to AWB - 11 - Extreme Programming (20)

Recently uploaded

Recently uploaded (20)

AWB - 11 - Extreme Programming