PHP Team Development — Save 50%
Easy and effective team work using MVC, agile development, source control, testing, bug tracking, and more
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 article, we will explore the concepts of agile development and will also see how these can help us with the PHP projects.
In this article by Samisa Abeysinghe, we will cover the following:
- 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
What is agility
Agility includes effective, that is, rapid and adaptive, response to change. This requires effective communication among all of the stakeholders. Stakeholders are those who are going to benefit from the project in some form or another. The key stakeholders of the project include the developers and the users. Leaders of the customer organization, as well as the leaders of the software development organizations, are also among the stakeholders.
Rather than keeping the customer away, drawing the customer into the team helps the team to be more effective. There can be various types of customers, some are annoying, and some who tend to forget what they once said. There are also those who will help steer the project in the right direction. The idea of drawing the customer into the team is not to let them micromanage the team. Rather, it is for them to help the team to understand the user requirements better. This needs to be explained to the customers up front, if they seem to hinder the project, rather than trying to help in it. After all, it is the team that consists of the technical experts, so the customer should understand this.
Organizing a team, in such a manner so that it is in control of the work performed, is also an important part of being able to adapt to change effectively. The team dynamics will help us to respond to changes in a short period of time without any major frictions.
Agile processes are based on three key assumptions. These assumptions are as follows:
- It is difficult to predict in advance, which requirements or customer priorities will change and which will not.
- For many types of software, design and construction activities are interweaved. We can use construction to prove the design.
- Analysis, design, and testing are not as predictable from the planning's perspective as we software developers like them to be.
To manage unpredictability, the agile process must be adapted incrementally by the project's team. Incremental adaptation requires customer's feedback. Based on the evaluation of delivered software, it increments or executes prototypes over short time periods. The length of the time periods should be selected based on the nature of the user requirements. It is ideal to restrict the length of a delivery to get incremented by two or three weeks.
Agility yields rapid, incremental delivery of software. This makes sure that the client will get to see the real up-and-running software in quick time.
Characteristics of an agile process
An agile process is driven by the customer's demand. In other words, the process that is delivered is based on the users' descriptions of what is required. What the project's team builds is based on the user-given scenarios.
The agile process also recognizes that plans are short lived. What is more important is to meet the users' requirements. Because the real world keeps on changing, plans have little meaning. Still, we cannot eliminate the need for planning. Constant planning will make sure that we will always be sensitive to where we're going, compared to where we are.
Developing software iteratively, with a greater emphasis on construction activities, is another characteristic of the agile process. Construction activities make sure that we have something working all of the time. Activities such as requirements gathering for system modeling are not construction activities. Those activities, even though they're useful, do not deliver something tangible to the users. On the other hand, activities such as design, design prototyping, implementation, unit testing, and system testing are activities that deliver useful working software to the users.
When our focus is on construction activities, it is a good practice that we deliver the software in multiple software increments. This gives us more time to incorporate user feedback, as we go deeper into implementing the product. This ensures that the team will deliver a high quality product at the end of the project's life cycle because the latter increments of software are based on clearly-understood requirements. This is as opposed to those, which would have been delivered with partially understood requirements in the earlier increments.
As we go deep into the project's life cycle, we can adopt the project's team as well as the designs and the PHP code that we implement as changes occur.
Principles of agility
Our highest priority is to satisfy the customer through early and continuous delivery of useful and valuable software. To meet this requirement, we need to be able to embrace changes. We welcome changing requirements, even late in development life cycle. Agile processes leverage changes for the customer's competitive advantage. In order to attain and sustain competitive advantage over the competitors, the customer needs to be able to change the software system that he or she uses for the business at the customer's will. If the software is too rigid, there is no way that we can accommodate agility in the software that we develop. Therefore, not only the process, but also the product, needs to be equipped with agile characteristics. In addition, the customer will need to have new features of the software within a short period of time. This is required to beat the competitors with state of the art software system that facilitate latest business trends.
Therefore, deliver the working software as soon as possible. A couple of weeks to a couple of months are always welcome. For example, the customer might want to improve the reports that are generated at the presentation layer based on the business data. Moreover, some of this business data will not have been captured in the data model in the initial design. Still, as the software development team, we need to be able to upgrade the design and implement the new set of reports using PHP in a very short period of time. We cannot afford to take months to improve the reports. Also, our process should be such that we will be able to accommodate this change and deliver it within a short period of time.
In order to make sure that we can understand these types of changes, we need to make the business people and the developers daily work together throughout the project. When these two parties work together, it becomes very easy for them to understand each other.
The team members are the most important resource in a software project. The motivation and attitude of these team members can be considered the most important aspect that will determine the success of the project. If we build the project around motivated individuals, give them the environment and support they need, trust them to get the job done, the project will be a definite success.
Obviously, the individual team members need to work with each other in order to make the project a success. The most efficient and effective method of conveying information to and within a development team is a face-to-face conversation. Even though various electronic forms of communication, such as instant messaging, emails, and forums makes effective communication possible, there is nothing comparable to face-to-face communication.
When it comes to evaluating progress, working software should be the primary measure of progress. We need to make sure that we clearly communicate this to all of the team members. They should always focus on making sure that the software they develop is in a working state at all times. It is not a bad idea to tie their performance reviews and evaluations based on how much effort they have put in. This is in order to make sure that whatever they deliver (software) is working all of the time.
An agile process promotes sustainable development. This means that people are not overworked, and they are not under stress in any condition. The sponsors, managers, developers, and users should be able to maintain a constant pace of development, testing, evaluation, and evolution, indefinitely.
The team should pay continuous attention to technical excellence. This is because good design enhances agility. Technical reviews with peers and non-technical reviews with users will allow corrective action to any deviations from the expected result. Aggressively seeking technical excellence will make sure that the team will be open minded and ready to adopt corrective action based on feedback.
With PHP, simplicity is paramount. Simplicity should be used as the art of maximizing the amount of work that is not done. In other words, it is essential that we prevent unwanted wasteful work, as well as rework, at all costs. PHP is a very good vehicle to achieve this.
The team members that we have should be smart and capable. If we can get those members to reflect on how to become more effective, at regular intervals, we can get the team to tune and adjust its behavior to enhance the process over time. The best architectures, requirements, and designs emerge from self-organizing teams. Therefore, for a high quality product, the formation of the team can have a direct impact.
|Easy and effective team work using MVC, agile development, source control, testing, bug tracking, and more|
eBook Price: $20.99
Book Price: $34.99
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 focusses on customer satisfaction. XP focusses 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 design solutions.
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. 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 focusses 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 flexible. 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 conflicting 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 users want.
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. Risk-driven 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 form what they did right as well as form 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.
The Scrum process focusses on small working teams that are used to maximize communication and minimize overhead. The process is adaptable to both technical and business challenges to ensure that the best product is produced. The process yields frequent increments that can be inspected, adjusted, tested, documented, and built on.
People performing development work are partitioned into clean, low coupling segments. This ensures that each partition, or sub-team, can work on their part, independent of each other. We need to carefully partition the work for the sub-teams so that there is less overlapping. The MVC based partitioning is a good model to achieve this.
Testing and documentation is performed as the product is built as a part of the development work. This ensures that not only the code, but the tests and documents are also available. Thus ensuring that the product that is being developed is completely developed. Often, it is the case that code will be the first thing that the development team focusses, and at the end, it will only be the code that is available. At that time, if we try to develop tests and documents, the chances of missing elements are high, as even the team members who wrote the code might have forgotten what exactly they themselves did. Therefore, it is always a good idea to perform testing and documentation as we go along.
The other key characteristic of the Scrum process is the ability to declare that the product is done whenever required. Constant focus is on the working software and the division of work items into working subsets. All of the working partitions, when put together, form the working software.
Scrum uses the concept of a backlog to maintain the prioritized list of requirements or features that provide business value to customer. The items are attended to, based on the priority. Items can be added at any time and their priorities can be changed based on the customer's demand.
Sprint, in the context of Scrum, is the work units required to achieve one of the backlog items. These work units must fit into a predefined time box, meaning that the Sprint must be completed within a predefined time period. The backlog items that are affected due to a higher priority backlog items are frozen to make way for highest priority items in the list.
Scrum meetings are intended to check the health of the process and the product. These are daily meetings of 15 minutes to discuss the following:
- What was done since last meeting?
- What obstacles were encountered?
- What will be done by the next meeting?
Demos, in the context of the Scrum process, deliver a software increment to customer for evaluation. Based on the feedback given by the customer, backlog items and their priorities will be updated and the next Sprints will be scheduled.
|Easy and effective team work using MVC, agile development, source control, testing, bug tracking, and more|
eBook Price: $20.99
Book Price: $34.99
Feature Driven Development
As in most of the other agile style process models, FDD emphasizes collaboration among team members. The complexity of the project is handled by using feature-based decomposition of the problem, followed by the integration of software increments. The technical communication is done using verbal, graphical, and textual means. Software quality is assured by using incremental development, design and code inspections, metric collections, and use of patterns in all areas, such as analysis, design, and construction.
In FDD, we develop an overall model that contains a set of classes that depicts the business model of the application that is to be built.
Then, based on this model, a features list is built. Features are categorized and prioritized and then work is broken up into two week chunks.
The project planning is then done by feature. Features are assessed based on priority, effort, technical issues, and schedule dependencies.
Design is also done based on each feature. Classes relevant to a feature are chosen first, and then class and method logics are written. An owner is assigned to each class. That owner is responsible for maintaining the design document for his or her own work packages.
The build system is also based on each feature. The class owner translates the design into source code and performs unit testing, and the integration is performed by a team leader.
Agile Modeling (AM) is a practice-based methodology for effective modeling and documentation of software systems in a light-weight manner.
Modeling is based on a set of guiding principles. First, modeling will be done with a purpose. Multiple design models are used to capture different perspectives. Out of the multiple models, only models with a long-term value are retained.
It is important to note that the model content is more important, than the model representation. In the modeling process, it is important to get to know the models and tools that we use to create the models.
In the requirements gathering and analysis modeling phases, we need to work collaboratively with the customer to find out what the customer wants to do with the system. To ensure this occurs, once the requirements model is built, collaborative analysis modeling continues with the customer.
Architectural modeling derives a preliminary architecture from the analysis model. An architectural model must be real for the user's environment. Also, it must be understandable by developers because they should ensure that key characteristics of the model are preserved while constructing the system.
Agile for the PHP team
Now that we have a good understanding on the agile principle, let us discuss how the PHP team can benefit from the application of agile principles.
Pair programming will help in improving team bonding, team interaction, and will help each team member to uplift their standard. We can use all of the principles of pair programming that we discussed under the heading Extreme Programming (XP).
Body language is important, therefore, they should sit side by side so that both partners of the pair feel comfortable.
The PHP code should be written while conversing with each other. Rather than criticizing each other, the pair needs to collaborate. They need to discuss the strengths and weaknesses of the PHP constructs used, conventions and guidelines followed, and the libraries and APIs used. The pair should focus on the elegance, efficiency, performance, and readability of the PHP code that they produce.
There are two roles that must be performed in a pair. The first role is the one who is at the keyboard and the other role is the one who looks at the PHP code that is written by the keyboard owner. The one without the keyboard has more time to think, and therefore will generate more ideas than the one with the key board. Over time, to avoid friction, it will be a good idea to switch these two roles too, on a regular basis. This will allow both members to have ample time to think as well as to work, so they can equally contribute with their brilliant ideas to the work at hand.
It is a common question to ask if it is worthwhile to spend two people to do the work that can be done by one. Note that it is not really true to say that two people are doing the work of one person in pair programming. Coding is not the most important part of the project. It is writing the right PHP code that syncs up with the correct design that is most important. In pair programming, while one is writing PHP code, the other is thinking ahead, looking for potential problems and corner cases. This will reduce bugs, increase system quality, and increase system acceptance by the end users.
Sustainable working style
Team members should work with passion and energy on the project. To make sure that the team members continue to work energetically, they need to have a room to recharge themselves on a daily basis. If this is not done, the team will not be able to work on the project with the same level of energy at all times. They will tear up, thus hindering the project's success towards the end of the project's life cycle.
To sustain the team's energy, the team needs to re-energize themselves. They should go home on time, take a break, take some time off from work, and spend time with family and friends.
If any team member is sick, they should be encouraged to stay at home. It is not productive for someone to work when they are sick. Going to work while suffering from an illness increases the risk of making other people in the team sick.
While at work, when team members feel tired, they should take a break. When team members make more mistakes than progress, then it is a clear indication that the folks are tired, and they should take a break. It is a good idea to have some coffee or tea, have some chit-chat, watch some TV, or play a game. Yes, you should have facilities in the office to facilitate those activities. It is not a good idea to only have a book shelf with some PHP books in the recreation area. There should be some activities that the team can enjoy.
All members of the team should be sensitive to the current status of the project. Wandering around the work area should provide ample information about what is going on with the project. There should be enough white boards to capture ideas around the workspace. Rather than worrying about the neatness and beauty of the drawn diagrams, it is more important to have the ideas captured then and there. Therefore, it is perfectly fine to hand-draw the design diagrams and charts. There should be no rush to computerize the stuff. We can always use digital cameras to capture the white boards and can transfer them as notes to the computer.
For a healthy project, everyone in the team should have free and ready access to the information. Rather than looking and trying to understand the design, team members should be able to sense the design and reinforce that within the workspace, as they do their day to day work.
Simple charts can help to feed information into the team, and can help to evaluate, and thereby reinforce, the health of the project.
Some simple charts that can help you to improve the process include the following:
- Amount of pairing, as percentages, where people were working in pairs versus where people were working alone. This chart can help us to evaluate if we really use pair programming.
- Paring combinations, showing who pared with whom over a period of time. These can help us to evaluate our effectiveness of paring.
- Tests per second, showing how many tests were executed over a day. Also, showing in how many tests we passed (versus failed). This helps us to gauge our coding quality.
- Tracking the time to fix the found issues and the number of issues opened versus number of issues resolved. Continuously tracking the number of outstanding issues. This will help us understand the efforts required to solve the problems along with our ability to solve the problems quickly.
Fixing the process
Things will go wrong. Mistakes will happen. We need to learn lessons from them and move on. To fix those problems and prevent them in the future, we need to understand those problems, and especially why they happened. Root-cause analysis helps us in understanding the problems and figuring out the way to fix them in the way we work so that things don't go wrong again.
Also, in root-cause analysis, collaboration can help us in dealing with fixing issues in the process. We can share our conclusions and reasoning with each other, and can get everyone's perspective to ensure that we reach the best possible decisions to fix the process.
To collaborate among the team members in an effective manner, it is a good idea to sit together. Sitting together facilitates rapid and accurate communication. This means everyone, including the experts in design, business, programming, and testing, sits together. In this way, you have more opportunity to communicate clearly with each other, you also have the opportunity to learn from each other.
Sitting together reduces time to solve the problems drastically. You just turn around and ask someone who knows the subject. It also encourages you to ask for help, and you can get help when you need the most because there is no need to postpone.
It is not a good idea to ask the team members to sit with each other, against their will. However at the same time, the setup and layout of the work area should encourage people to sit together. The free flow of communication will not be encouraged if the workspace was arranged in such a manner that people were confined to their personal cubicles. At least have some common working areas so that people can sit comfortably and work with the other people, as and when they want.
One of the arguments against sitting together would be the background noise. However, over a period of time, people will realize that the energy of the project's team is flowing across the room. Thus, they will get used to the new model of working in a shared workspace. On the other hand, if the need for privacy arises for some activities like, meetings or calls, meeting rooms could be used for those things.
Remember, it is important to ask more questions, rather than having the team members or pairs trying to guess the things for themselves.
When we develop software for business domains, we need to be able to communicate what we do, what others want, what the system is all about, and so on, to non-programmers and programmers.
Often, we are good at explaining the technical aspects related to the software and to the use of programmer's jargon. We are also capable of understanding what others tell us on the software and on the use of programmer's jargon. However, the challenge is to explain the system and what we are doing for non-programmers, and remember that system users are non-programmers. The idea is not to eliminate the use of technical terms, but rather to make sure that others also understand what we are talking about. The language that we use to describe things should be as close as possible to the real world domain (where the software is to be used).
Ubiquitous language reduces the risk of miscommunication among team members as well as between the team and the users. And note that even the PHP code that we write should reflect this language. Therefore, the function names, class names, and the names of the variables that we use should reflect this. Also, the language that we use should be in sync with the jargon used in the data and business models that we developed.
It is important to know what others are doing in the team on a regular basis. It is always a good practice to eliminate the need for assumptions with respect to the rest of the team. When someone is stuck, others will be able to help because others have already gotten over that hurdle. That way, we can save tons of time, rather reinventing the wheel.
Stand-up meetings are about people interaction and participation. It needs to feel open and free. Therefore, it is important to do that in an open area, rather than around a cramped area. The environment should set the feeling for energetic and comfortable discussion.
It is not required to wait for the stand-up meeting to start the day. However, it is useful to start the day with the stand-up meeting. Moreover, the meeting should be short and sweet. As short as thirty seconds of speaking time (per person) is recommended.
The points to discuss should be crisp and clear. What did each team member do yesterday, what each member will be doing today, and what are the hurdles, if there are any. Moreover, pairs should also be picked, based on past experiences that other members have, to overcome hurdles found on a given day.
Irrespective of the fact that there is benefit in having stand-up meetings, it should not be taken as an excuse for one not to raise problems. If a pair hits a road block in the middle of the day, they should not wait until the next morning's stand-up meeting to communicate about it to the rest of the team. Communicate issues as soon as the issues surface, irrespective of the fact that there will be a meeting the next morning. This is because others in the team might need to discard some work due to the issue, as they didn't know that earlier.
Demonstrate the iteration outcome
Until the product is run for real, we cannot be sure if it will run and solve the problems that we actually have in our hand.
We can conduct weekly iteration demos to ensure that we have a running product on a regular basis. This would cut down on integration pains by a great deal. It also makes the team honest. They will admit to the breaks and bugs in the code or weaknesses in the design. It is important that the team has an open mind regarding the issues in the product that they develop.
The team needs to be honest with the problems and with the way they handle those with the stakeholders. This will ensure that we build trust with stakeholders. If the stakeholders lose their trust in the team, then that will not help the project in the long run.
Weekly deployment of the product in the real deployment environment will help the team realize the real issues.
In this article, we discussed that the working software is at the heart of the agile processes. These teams need to collaborate among themselves, as well as with the system users, to ensure that the delivered software meets expectations. Short delivery cycles, regular increments, regular demos, and deployment of the software being developed are important traits of the agile processes.
We can use PHP effectively to capture the requirements in the initial phases. This can be done using PHP as an effective means of building prototypes to capture the users' feedback. PHP programmers can pair up to minimize the possibility of bugs, and to increase the design and code quality. Different perspectives brought in by the various team members and the users will ensure that we get the product right.
Several flavors of agile processes were discussed in this article. This was done to help you understand the various means of adopting agile concepts to the PHP project on which you are working. Rather than just playing by the rules, it is ideal to try and evolve the current process to suite the project needs in an evolutionary manner. A team will not be able to go agile over night. However, slow and steady adoption of agile principles can win the challenge.
About the Author :
Samisa Abeysinghe is Director, Engineering at WSO2. Samisa pioneered the Apache Axis2/C effort and architected the core of the Apache Axis2/C Web services engine. He continues to be an active contributor in the Apache Axis2/C project. His involvement in open-source projects began in 2004 when he started working with the Apache Axis C/C++ project.
Prior to his current role, Samisa played the project lead role for the WSO2 Web services Framework for PHP project, which provides comprehensive support for building both SOAP and REST services and clients.
Books From Packt