Extreme Programming (XP)
Extreme Programming (XP) is the most widely used agile process. The
characteristics of XP can be used very effectively for a PHP team’s projects. It is a
disciplined approach for software development that focuses on customer satisfaction.
XP focuses on capturing user’s requirements through simple tools. Releases are
planned as a series of iterations. Tests are defined up front at the beginning of the
project iterations. Smaller releases are done based on customer acceptance tests.
XP planning begins with the creation of user stories that are used to capture
requirements. Then, the team assesses each user story and assigns a cost based on
estimated time and effort required to complete the user story. After that, user stories
are grouped together for a deliverable increment and a commitment is made on the
delivery date. After the first increment is completed, based on how the increment
was accomplished, subsequent delivery dates for other increments would be defined.
The XP design follows the KISS (keep it simple & smart) principle. Simple design
techniques, such as CRC (Class, Repository, and Collaboration) cards can be
used to initiate the design. CRC cards are a brainstorming tool used to design the
object-oriented software. They are used to write down the information on classes
in the object-oriented system, and can help to keep the complexity of the design at
a minimum. However, the final design should be in the code. Therefore, conscious
effort is made to use the code for design. PHP is ideal for this purpose. For difficult
design problems, prototypes could be developed with PHP, which can be depicted as
spike solutions to help better understand the user problems and come up with better
One of the challenges of going into the PHP code for design is that the initial code that
we write will lead to problems with respect to the ideal design and implementation.
The solution is to encourage refactoring the PHP code. The iterative refinement of the
internal program design will lead to perfection of the design over time.
In the XP approach, it is recommended to construct unit tests before the coding
commences. This ensures that we can test as soon as the code is available. The other
key advantage is that by looking into unit testing before the real implementation,
we can make sure that we cover all the edge cases in the implementation, thereby
leaving little room for bugs. This model also enforces simplicity because instead of
worrying about making the code overly complex, the tests are written first and then
the minimal code is written to cover only those test cases.
The concept of pair programming is one of the most popular aspects that XP is
well known for. Based on the concept of ‘two minds are better than one’, a pair of
programmers, rather than one, will work on a single piece of code. One will look
over the shoulder of the other while the other one attends the code. This practice, as
you might know by experience, ensures that we make the code better on the spot.
Over time, due to the number of bugs being eliminated, thanks to this practice, the
employment of two resources to write one module pays off.
The approach for choosing pairs is again up to the team. For PHP projects,
we can get members from the same sub-team to pair up or members from different
sub-teams to pair up. For example, two people form the presentation layer could work
on a presentation aspect. Alternatively, one from the business layer can pair up with
one from the presentation layer. If different sub-team members are paired up, it will
ease integration pains in the PHP project, and the cross-domain know-how will also
enhance among the team. As we saw at the end of the previous chapter, business layer
implementation needs to wait until the data layer is available, and the presentation
layer needs to wait for the business layer. This opens up the opportunity for pairing
across the sub-teams so that presentation layer team will not need to wait idle until
the people in business layer complete their task. We can use the idle time for the
betterment of the overall project by means of paring up.
The approach for testing in XP is based on ‘test early and often’. All unit tests are
executed daily. This will expose regression and shortcomings in the design.
Acceptance tests are defined by the customer and are executed to assess the
customer-visible functionality. The project’s team will help the users to define those
tests. It is almost as if the customer will do system testing, which will convince the
customer on system quality and its readiness to be deployed into production.
Advantages of agile development process
An agile development process can deliver successful systems quickly. Users will
perceive the systems to be of high quality, and will make real use of those systems for
the betterment of the business. Agile software engineering development guidelines
stresses on on-time delivery of the operational software that will increment above
generating analysis and design documents.
Agile development focuses on continuous communication and collaboration
among developers and customers. This too contributes to quality. Agile software
engineering embraces a philosophy that encourages customer satisfaction, and
communication is the key to understand what they want. Incremental software
delivery also contributes to user satisfaction because they get to see the system and
evaluate if that is really what they want at the earliest, and provide feedback if that
is not what they want.
An agile team is able to respond to changes during project development. This is
because agile development recognizes the need for the project’s plans to be fl exible.
Changing something that one has developed over many weeks, if not months, is
a pain. But changing something written in PHP is comparatively trouble free. For
example, if you take a compiled programming language, such as Java or C, it takes
considerable efforts to compile and run the system, before the changes are verified to
not have any side effects. But with PHP, there is no compilation, therefore changing
and testing is comparatively easier. Therefore, there is no need to panic at all about
the need to change the implementation.
Attitudes of the individuals matter, both at the personal level and at the team
level. All team members, irrespective of their personal traits, need to be willing
to communicate with all others in the team. Not only communicating what you
think and what you want, but also understanding what others want and think
must be paid due attention. Effective communication includes effective listening
and the willingness to open the minds to confl icting view points. To facilitate
this, team structures and attitudes need to be nurtured and evolved. When it
comes to communication, it should always be remembered that developers, as
well as the customers, are a part of the same team. There is nothing to hide from
the users because the system is for the users. This is where the open source style
of development can help a great deal, where the developers discuss the design
decisions on an open-mailing list and the stakeholders, such as users can voice their
opinion openly. Everyone becomes a part of the system that is being developed.
The traditional thinking is that users use what developers develop, and that leads
to the separation and division between customers and developers. Agile looks to
eliminate this user and developer gap because the developers develop what the
Note that we mentioned the need to deliver the software in incremental phases.
However, it must be emphasized here that the rapid delivery of operational software
is very important. The iterations are not intermediate work products. Rather, they
are parts of the final system that the users can use in the real business environment.
In other words, deliver the client-usable software, instead of functional prototypes,
as soon as possible.
Agile process models
We have discussed Extreme Programming earlier, as it is the most widely used agile
process. In the following sections, we will discuss some additional agile process
models that are in use.
Adaptive Software Development
The philosophy driving Adaptive Software Development (ASD) is that
self-organization arises when independent members in a team cooperate to create
a solution to a problem that is beyond the capability of any individual member.
Adaptive cycle is mission-driven, component-based, iterative, time-boxed, risk driven,
and change-tolerant. Mission driven means that the team defines the objectives
to be achieved through the process, and take up the project as a mission that must
be accomplished. The system is defined as a set of components. In the case of PHP
projects, each layer can have one or more components. Each iteration of the project will
be time-boxed, meaning that we will come up with a well-defined schedule. Moreover,
each iteration will have a well-defined time frame within which that iteration will
be delivered. Throughout the project’s life cycle, the project’s team will watch out for
possible risks and keep open the doors for changes. Risks can be successfully dealt
with and mitigated, thanks to the change-tolerant approach of the project’s team. Riskdriven
planning allows us to be adaptive in the future iteration cycles.
Collaboration in ASD requires teamwork from a jelled team. The preferred
requirements-gathering approach is a joint application development. In other words,
prototyping is used for requirements gathering and requirements verification.
This process model facilitates team learning throughout the project’s life cycle. First,
the components are implemented and tested, and then the focus groups provide
feedback. Focus groups are those sets of users who are involved and interested in
that particular set of components and features that they encapsulate. This allows
both users and developers to learn. Users learn what they are going to get, and how
the system would look and feel when implemented for real using PHP. Developers
can learn from the users what they really wanted and what the development team
actually delivered. The development team can learn from what they did right as well
as from what they did wrong, with respect to meeting user requirements. The formal
technical reviews, as well as analyzing the success or failure of process iteration life
cycles, contribute to team learning. The next time around, either in the next iteration,
or in the next project, the probability of the team doing much better is very high.
Dynamic Systems Development Method
Dynamic Systems Development Method (DSDM) provides a framework for
building and maintaining systems, meet tight time constraints, using incremental
prototyping in a controlled environment. The guiding principle used in this process
is the Pareto principle. This states that 80% of a project can be delivered using 20% of
the time and effort that is required to deliver the entire project.
Each increment only delivers enough functionality to move to the next increment.
Time boxes are used to fix the time and resources to determine how much
functionality will be delivered in each increment.
Dynamic Systems Development Method’s life cycle
Let’s have a look at the Dynamic Systems Development Method’s life cycle:
- Feasibility study: This phase establishes the requirements and constraints
for the project.
- Business study: The objective of this phase is to establish functional and
information requirements that are needed to provide business value. In a
PHP project, with MVC pattern, this phase will identify the data model and
the business logic model.
- Functional model iteration: Functional model iterations produce a set
of incremental prototypes to demonstrate functionality to the customer.
Those prototypes also set the platform for user feedback.
- Design and build iteration: In this iteration, the prototypes are revisited to
ensure that they provide business value for end users. This can happen in
parallel with functional model iteration that is based on the user feedback.
- Implementation: The outcome of this latest iteration can be placed in an
operational environment because it produces the final product, evolving
prototypes into the final product, incorporating user feedback, and filling
in technical gaps.