PHP Team Development
This book is about ensuring project success for PHP teams. It explores technical as well
as non technical aspects that matter when achieving project success. On the technical
front, designing to divide complexity to conquer complex problems, keeping things
simple in the design, choosing the right process, and monitoring and improving the
process are important aspects. On the non technical front, making sure that they
collaborate effectively, the team should be open to changes. The team should be open to
user feedback. Having the right mindset about quality and other aspects related to project
success are discussed.
What This Book Covers
Chapter 1, Software is Complex, explains the complexities that we face while working
with today's software projects. PHP projects, some years ago, used to be small projects
involving one or two people. However, today, we need teams of people for PHP projects.
This chapter explores the need for teams for PHP projects. It also discusses how software
engineering principles help with PHP projects. There is an increasing need to use a
process for PHP projects. The complexity of having a team is figuring out how to divide
the project's problem among team members and solve it. This chapter discusses how to
divide and conquer projects. We will discuss how patterns help the PHP project to cope
with complexity. Finally, we will explore how to use tools to manage the development
and collaboration within the PHP team.
Chapter 2, MVC and Software Teams, discusses the MVC pattern in depth and how
MVC can help in a PHP project. It also explores how to use the MVC pattern as the
guiding principle to break down the complexity of a project, and how to implement MVC
with a team. It also discusses the integration challenges that are faced in putting together
all the pieces of MVC that are developed by different team members.
Chapter 3, Dealing with Complexity, discusses in depth how we can make use of
software design patterns to cope with complexities in a software project. We will also
discuss how PHP MVC frameworks simplify the complexity of a project. When using a
PHP framework, there are a bunch of expectations; we will explore what to expect and
what to look for in a PHP framework. The mere use of a PHP framework would not
guarantee project success. Hence, we will discuss how to achieve team success with PHP
frameworks in this chapter. We will also look at some leading PHP frameworks.
Moreover, we will also learn how to make things simple while using a PHP framework.
Chapter 4, The Process Matters, explains the relationship between the process and the
product. We will discuss, in depth, the consequences of ignoring the process and why the
process must be respected. We will learn how to move from no process to having a
process. We will explore the motivation that is required for a process, how a process
helps, and does not hinder a PHP project. We will also study a simple process model that
can be used for PHP projects.
Chapter 5, Agile Works Best, will introduce agile philosophy, including agile values and
agile principles. We will discuss common problems and fears that developers face when
developing a product, and see how agility can help to overcome them.We will discuss
extreme programming principles, and also learn the advantages of agile process models.
Finally, we will explore how we can achieve team agility.
Chapter 6, Ways of Collaboration, discusses the challenges faced while working with
teams, and we explore the implications of assumptions made by team members. Then we
will learn collaboration techniques for ensuring seamless integration of the various
components and layers developed by the team members. We will dig into the details of
source control, bug control, and configuration management, and learn how those relate to
effective team collaboration. Moreover, we will discuss some tools that we can use for
communication and collaboration.
Chapter 7, Continuous Improvement, will explain how to deal with change in PHP
applications. In order to make sure the software that we develop is useful, we have to
make sure that we are willing to embrace change and also be ready to evolve the system,
as we move along. We also have to ensue that the process being used is effective. We
will discuss how we can evolve the PHP application and also measure the effectiveness
of our process. People development is also another important aspect of continuous
improvement when ensuring success with teams. We will learn the team management and
people development aspect in this chapter.
Agile Works Best
In the previous chapter, we discussed a process model that can be used for PHP
projects. We can use the process model as the base for our projects and can also
succeed with the projects that we are working on. If you have a second look at the
process model that was suggested, you will note that the need for getting feedback
from the users is highlighted in multiple places. This was done very consciously and
with a purpose.
We are developing software for users, and we want to ensure that the software is
really useful for the users. Over time, people working on this software have faced
the same problem over and over again. Therefore, they have come up with a concept
called agile development. In this chapter, we will explore the concepts of agile
development and will also see how these can help us with the PHP projects.
In this chapter, we will cover the following:
- Introductions to agile philosophy, including agile values and agile principles
- Common problems and fears that developers face while developing a product
- What is meant by agility and how it can help
- Extreme programming principles
- Advantages of agile process models
- Team agility
- Agile process models
- Agile principles for the PHP project team
Introducing agile philosophy
Agile methodology consists of the following two parts:
- Agile values
- Agile principles
Agile values
Agile values identify the key characteristics of the way in which we develop
software. These values attempt to avoid those practices and norms that tend to
cause problems in the development of a software application.
Manifesto for Agile Software Development:
We are uncovering better ways of developing software by doing it and
helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items
on the left more.
Source: http://www.agilemanifesto.org/
These values try to address the key factors of success when it comes to developing
quality software. The rationale is not to overlook the values on the righthand side,
rather to focus more on the values on the left hand side. By having more of those
values on the left, we become more agile, thus responding to changes quickly.
Agile principles
The agile principles help us to stay focused on agile values throughout the project's
life cycle. These principles nurture agility in a project's team. The principles are
as follows:
Principles behind the Agile Manifesto
We follow these principles:
Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile
processes harness change for the customer's competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple
of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the
project.
Build projects around motivated individuals.
Give them the environment and support they need, and trust them to get
the job done.
The most efficient and effective method of conveying information to and
within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development.
The sponsors, developers, and users should be able to maintain a constant
pace indefinitely.
Continuous attention to technical excellence and good design enhances
agility.
Simplicity--the art of maximizing the amount of work not done--is
essential.
The best architectures, requirements, and designs emerge from selforganizing
teams.
At regular intervals, the team refl ects on how to become more effective,
then tunes and adjusts its behavior accordingly.
Source: http://www.agilemanifesto.org/principles.html
The following sections describe the agile values, as well as agile principles in detail:
Individuals and interactions
Agile philosophy values individuals and interactions over process and tools. In
the process that was introduced in the previous chapter, the three main sub-teams
working on the data, business logic, and presentation layers have their own activities
to follow. Moreover, they have their own tools that they use. However, as it was
mentioned, it is of paramount importance that each sub-team interacts with each other.
Not only that each sub-team should interact, but also, there should be a helping
communication between the members within sub-teams. If the team members
interact, it becomes so easy to solve problems, such as inconsistencies in the PHP
code that is written and the user interfaces that are designed. Moreover, that will
also enhance the reuse of the PHP functions, classes, and the written API methods.
This is because through interactions, individual team members can educate each
other on what the system has and what the system is about. They can also share their
technical expertise. Programming can be done in pairs so that more than one pair of
eyes would be looking at the code, as it is being written. However, interaction should
not be restricted to only those individuals who work on the same code. Interaction
should take place between all of the team members who work on the project. This is
because no matter how large the software project or the product would be, they all
work on building a single application. It needs to run as a single application at the
end of the project.
When it comes to placing the members into sub-teams, it is useful to identify
an individual's traits, preferences, and skills. Moreover, it is also useful for each
individual in the team to get to know each other so that they can share and relate to
know how, create better designs, and overcome problems by sharing experiences.
After all, it is about that human touch among the members, and no process or tool
can bring about that value into a team.
Working software over comprehensive documentation
We can spend weeks, if not months, documenting system requirements. Some
call this analysis paralysis. You'll never get out of the system requirements
analysis phase. However, what is most important is to get the software that we are
developing to a working state. This is done so that the users can use it for real life
tasks and get their jobs done.
Documentation is required for some aspects, especially when it comes to user
documentation. However, that is also a part of the software. In the traditional software
process, before any working piece of code was written, bundles of documents were
written on what the requirements were and what the design should be like.
It is important to understand the user environments and have some reference points
to refer to them if the need arises. Often, a set of diagrams alone can capture what is
required, and we can move on to make the software functional.
Customer collaboration
In traditional software processes, there was this notion that the client would sign the
requirement specifications before proceeding to the implementation phase. It is a fact
of life that the real world changes. The requirement specifications that you signed
today can expire tomorrow. Moreover, when the system is delivered, the client might
see that the software doesn't fit their purpose. This will result in the system being
discarded by the users and will be branded as low quality.
It is for this reason that there were so many user evaluation and feedback phases
that were added to the process. That was introduced in the previous chapter.
When we closely collaborate with the clients, making them a part of the process, and
giving them the opportunity to have their say early and often in the process, there
are chances that we make the software that we develop fit the bill for their use.
It is often the case that the users will not know for themselves what they want.
After all, if they knew, they would not have hired us to develop the software for
them. They would have done it themselves. Therefore, it is our job to make them
understand what they want, along the way, while we develop what they want.
Moreover, you will note that the team will also be learning more and more about the
system, as the project progresses. The best way to expand the understanding, both
of the users and of the team, is to collaborate with customers very closely and on a
regular basis.
Responding to change
Change is inevitable. Therefore, it is not feasible to stick to a plan and follow that.
If we are to adopt a change, even the plan we should change over time.
A process model provides us with a framework that will guide us on what to do
and when to do. It is a good plan to help us stay on the course. However, we need
to understand the need for change on the part of the users. We cannot afford to not
respond to the changes requested by users, simply because we are in the middle of
our process (in other words, in the middle of our plans). It is for this reason that we
should have ample room for incorporating users' feedback into what we are designing
and developing. More often than not, feedback comes disguised, as the requests
change. As the users do not know the internals of the software application, their
wishes might be beyond the scope of developers. Nevertheless, these expressions
from users will be an important feedback. The key to success is to make sure that all
of the project's team, as well as the users, are comfortable with the changes.
Customizing agile to our needs
Every project is unique. Therefore, we can learn from agile values and customize
them to suite our project's needs. The process model that was introduced at the end
of the previous chapter is a good starting point. Moreover, we can follow that model
with agile values in place. The process can be enhanced and complemented with
agile values, and can be customized and fine tuned as the time goes by.
|
