PHP Agile Method

Extracted from: http://www.leftontheweb.com/message/agile-php-how-do-we-do-it

Since a few weeks we've really truely implemented some agile methods in our biggest project (Jongeren in Beeld). Since others may benefit from knowing how we have approached this, I want to share our implementation of the agile approach of software development in a PHP project with the world.

First of all, I actually wrote a document to outline these guidelines, as in our company (and I guess a lot of other companies) as long as it's not documented, it won't be followed. So I guess you could call that tip #1

Iterations

An iteration is a certain set period of time during which the developers work on implementation a set of features and/or fixing bugs. An iteration always results in a release. The definition of "release" here is a stable enough codebase in the development branch to deploy safely on the testserver. More on this later. The length of iterations for us is three weeks, where one week overlaps. So the last week of iteration 1 is the first week of iteration 2. During the first two weeks of an iteration, the developers work on implementing the features. The third week is for testers to test the release, and (when the choice is made to do this) deploy the release to the production environment. So basically, the developers are always busy with implementing new features, but once the testers are working on testing the application, they may need to fix minor bugs so as to get a truely stable version that can be deployed to the production environment.

Meetings

There are two very important meetings during an iteration, and aside from that every morning has a short morning stand-up meeting. Let's first have a look at the important meetings:

• On the first monday of an iteration at 9:30, all stakeholders gather for the planning meeting. During this meeting, all stakeholders gather around a PC on which our Trac installation is open, and discuss which features should be planned for the upcoming iteration. The list of planned features should be a little too long to be realistic. Since the rule is to always be able to deliver a stable version, it is not bad if some features won't actually be done this iteration. It's better to have too much planned than too little planned, or the developers might be sitting around doing nothing
  
• On the second thursday afternoon, at 15:00, the closing progress meeting is being held. During this meeting, all stakeholders should gather to have a look at what progress is actually made during the past two weeks. Also, based on the list of implemented features, the testers may now be able to write their test plans. Based on the list of implemented features, during this meeting already the decision may be made that this release should end up on production.

The short morning stand-up meetings are just that: A max of 15 minutes is set for this meeting, and during this meeting, everybody will tell what has been done since the last stand-up meeting, what is planned until the next stand-up meeting, and if there are any issues that might block the developer from making that planning. This meeting is held while standing, so as not to get comfortable and have endless meetings talking on things that are not relevant. Save that for the coffee machine

Whiteboards, sticky notes and Trac

The list of tickets to work on is being tracked in several ways. In our room, we have a whiteboard that is divided into sections very similar to the drawing on the cover of this book. Each ticket is then written on a sticky note: That is, it's ticket number and short description. Aside from that, all tickets are in Trac. For each new version, a "Version" in Trac is created that is named [version number]-TODO. All tickets that are being planned for a certain version are assigned this version number. As someone is working on a feature, the sticky note is moved to the "In Progress" section of the whiteboard, and the ticket is "accepted" in Trac. As a feature is done, the sticky note is moved to the "Finished" section of the whiteboard, and the ticket is closed.

Version and Release Control

First, let's talk about the procedures concerning version and release control, and after that have a look at the technical infrastructure supporting these procedures. A developer should test his own code while developing. At this point, we are not (yet) too strict on the existence of unit tests or functional tests, but the developer should definitely try out the new functionality he implements. In theory, ONLY STABLE CODE SHOULD END UP IN OUR VERSION MANAGEMENT SYSTEM. The reason for this is simple: Since the holy aim of an iteration is to have a stable release after two weeks of development, you never ever want to have unstable code in your repository. If you have, you may not have the time to fix this before the end of the two week period. And at the end of such a two week period, the release should be stable enough for testing. So, ONLY COMMIT STABLE CODE.

At the end of the two-week period, a release is made by tagging the code that is in the development branch at that time, with a '-test1' postfix. As new releases are made during the third week after bugfixing, the number at the end of the postfix may get higher. As the testers sign off the latest test-release, this latest test-release is then tagged as [version number]-final. This -final release is exported, then deployed to the production environment according to strict planning guidelines (I'll discuss this later). Development is always being done in a development branch. This branch is created from the trunk on the second friday of an iteration (basically, the last workday before a new iteration starts). This branch is named as [next version number]-dev, and all developers should commit to this development branch. These are exceptions to this: If during the planning meeting it is decided to implement a feature that will take more than the two-week span of development during an iteration, a seperate development branch for *only* this specific features is created from trunk. The new development branch is not created before the old development branch has been merged back to the trunk, the get the trunk updated with all the new functionality.

Version and Release infrastructure

For ticket tracking, we use the Trac software. Reason for this is the tight integration with our version management system, enabling us to have a simple overview of which changesets are related to which tickets, as well as easily seeing which files have been changed for which reasons. For version control we use Subversion. We heavily rely on it's branching, tagging and merging techniques.

Deployment planning

We have very simple but effective rules concerning deployment to the production machine:

• No deployment will happen after 14:00. If something goes wrong with deploying, you may be working into the night if you start deployment after this time.
  
• No deployment will happen on friday. If something goes wrong with deploying, you may be working into the weekend if you deploy on friday
  
• No deployment will happen of big features if there is no extensive deployment plan and rollback scenario. For deployment of bugfix releases or minor updates, a short rollback scenario as well as a database changeset is required.
  
• Deployment should always be planned at least a day ahead. The latter rule is not strictly enforced, but it is a good guideline to prevent surprises and allow for good planning and preparation.
  

Deployment to the test server is not affected by these rules, since the test server (even though important) is not critical to have down during a night/weekend.

That's about it

I hope this is of any use to people out there. If you have any questions, feel free to contact me. I'd gladly give some advice where needed. I know for a fact that ever since we started working in this pretty strict way, the quality of our code as well as our external communication have improved bigtime. Clients will love you for this.

4 Ace Technologies

Agile web development

Extracted From Wikipedia

Agile web development is a model for development of web applications. Its concept is similar to Agile software development, but is limited to web applications. It is more efficient and powerful within a short timeline than other models,^{[citation needed]} incorporates face-to-face communication, and includes technical personnel as well as customers as part of the team. Agile web development uses project managers, business analysts, emphases on clear goals, planning, and iterative delivery. Agile web development ensures the successful completion of product at the end of each iteration.

The agile web development model follows planning, requirement analysis, designing, coding, testing, and documentation developing stages parallel. Successful interaction reaches toward to successful completion of application because of customer involvement hence we never met with the condition where we have to change the product due to changes in requirements, correct decision has to be taken by keeping customers confidence and informed choice, minimizing delays of the product. All the tasks are performed at given period, with just enough documentation to be effective.

• Small time line.
• Refined Team.
• Clear planning.
• Concise Documentation.

Due to the regular involvement and feedback of the customer, the application tends to be more error free, more requirement oriented, and more user friendly. Also, tasks such as planning, development, design, coding, testing, etc. are done simultaneously, driven by the customer’s demands. It also reduces the development cycle time. The documentation of the application is less formal, to reduce the time taken and to be more human friendly.

Agile methodology is similar to the iterative, RAD Prototype model, but it has its own principles for developing a web application and it has introduced concepts that overcome the problems associated with existing models.

For instance, the waterfall model frequently changes requirements during the development life cycle, which means it fails whenever the requirements are changed at the end or not properly understood or implemented according to the customer's current feedback. In the iterative incremental model, the development process moves according to the iterations. Requirements analysis, designing, and functional modification must be added at each version or iteration of a system to satisfy the customer feedback, and at last it is integrated into the system. Agile development adopted the key points from an iterative model but differs from iterative in relation to the timeboxes. An agile development life cycle devotes attention to a shorter time duration for completion of the project. With the help of timeboxes, developers can easily estimate the problem and correct it in a given time, so that at the end of each iteration, it is modified.

Companies are moving towards Agile as it results in more Customer Satisfaction and hence there business - Says Amit Bathla.

4 Ace Technologies

Agile Software Development

From Wikipedia, the free encyclopedia

Agile software development is a group of software development methodologies that are based on similar principles. Agile methodologies generally promote a project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices that allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals. Conceptual foundations of this framework are to be found in modern approaches to operations management and analysis such as Lean manufacturing, Soft Systems Methodology, Speech act Theory (Network of conversations approach), and Six Sigma.


Introduction
There are many specific agile development methods. Most promote development iterations, teamwork, collaboration, and process adaptability throughout the life-cycle of the project.

Agile methods choose to do things in small increments with minimal planning, rather than long-term planning. Iterations are short time frames (known as 'timeboxes') which typically last from one to four weeks. Each iteration is worked on by a team through a full software development cycle, including planning, requirements analysis, design, coding, unit testing, and acceptance testing when a working product is demonstrated to stakeholders. This helps to minimize the overall risk, and allows the project to adapt to changes quickly. Documentation is produced as required by stakeholders. An iteration may not add enough functionality to warrant releasing the product to market, but the goal is to have an available release (with minimal bugs) at the end of each iteration. Multiple iterations may be required to release a product or new features.

Team composition in an agile project is usually cross-functional and self-organizing without consideration for any existing corporate hierarchy or the corporate roles of team members. Team members normally take responsibility for tasks that deliver the functionality of an iteration. They decide for themselves how they will execute during an iteration.

Agile methods emphasize face-to-face communication over written documents. Most agile teams are located in a single open office to facilitate such communication. Team size is typically small (5-9 people) to help make team communication and team collaboration easier. Larger development efforts may be delivered by multiple teams working toward a common goal or different parts of an effort. This may also require a coordination of priorities across teams.

No matter what development disciplines are required, each agile team will contain a customer representative. This person is appointed by stakeholders to act on their behalf and makes a personal commitment to being available for developers to answer mid-iteration problem-domain questions. At the end of each iteration, stakeholders and the customer representative review progress and re-evaluate priorities with a view to optimizing the return on investment and ensuring alignment with customer needs and company goals.

Most agile methodologies include a routine and formal daily face-to-face communication among team members. This specifically includes the customer representative and any interested stakeholders as observers. In a brief session, team members report to each other what they did yesterday, what they intend to do today, and what their roadblocks are. This standing face-to-face communication prevents problems being hidden.

Agile methods emphasize working software as the primary measure of progress. Combined with the preference for face-to-face communication, agile methods usually produce less written documentation than other methods. In an agile project, documentation and other project artifacts all rank equally with working product. Stakeholders are encouraged to prioritize them with other iteration outcomes based exclusively on business value perceived at the beginning of the iteration.

Specific tools and techniques such as continuous integration, automated or xUnit test, pair programming, test driven development, design patterns, domain-driven design, code refactoring and other techniques are often used to improve quality and enhance project agility.

Principles behind agile methods
See also: Agile Manifesto
Agile methods are a family of development processes, not a single approach to software development. In 2001, 17 prominent figures[4] in the field of agile development (then called "light-weight methods") came together at the Snowbird ski resort in Utah to discuss ways of creating software in a lighter, faster, more people-centric way. They created the Agile Manifesto, widely regarded as the canonical definition of agile development and accompanying agile principles. The Agile Manifesto states:
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.
Some of the principles behind the Agile Manifesto[5] are:
• Customer satisfaction by rapid, continuous delivery of useful software
• Working software is delivered frequently (weeks rather than months)
• Working software is the principal measure of progress
• Even late changes in requirements are welcomed
• Close, daily cooperation between business people and developers
• Face-to-face conversation is the best form of communication (Co-location)
• Projects are built around motivated individuals, who should be trusted
• Continuous attention to technical excellence and good design
• Simplicity
• Self-organizing teams
• Regular adaptation to changing circumstances

The manifesto spawned a movement in the software industry known as agile software development.
The functioning principles of Agile can be found in lean manufacturing and six sigma. These concepts include error proofing, eliminating waste, creating flow, adding customer value, and empowering workers. The concepts were first formally espoused in the 14 principles of the Toyota Way, the two pillars of the Toyota Production System (Just-in-time and smart automation), the 5S methodology, and Deming’s 14 points. These have been summarized in the seven points of lean software development.

Contrasted with the waterfall model
Agile development has little in common with the waterfall model. As of 2009, the waterfall model is still in common use.[7] The waterfall model is the most structured of the methods, stepping through requirements-capture, analysis, design, coding, and testing in a strict, pre-planned sequence. Progress is generally measured in terms of deliverable artifacts: requirement specifications, design documents, test plans, code reviews and the like.

The main problem with the waterfall model is the inflexible division of a project into separate stages, so that commitments are made early on, and it is difficult to react to changes in requirements. Iterations are expensive. This means that the waterfall model is likely to be unsuitable if requirements are not well understood or are likely to change in the course of the project.[8]
Agile methods, in contrast, produce completely developed and tested features (but a very small subset of the whole) every few weeks. The emphasis is on obtaining the smallest workable piece of functionality to deliver business value early, and continually improving it and adding further functionality throughout the life of the project.

In this respect, agile critics may assert that these features are not placed in context of the overall project, concluding that, if the sponsors of the project are concerned about completing certain goals with a defined timeline or budget, agile may not be appropriate. Proponents of agile development counter that adaptations of Scrum[9] show how agile methods are augmented to produce and continuously improve a strategic plan.
Some agile teams use the waterfall model on a small scale, repeating the entire waterfall cycle in every iteration.[10] Other teams, most notably Extreme Programming teams, work on activities simultaneously.


Suitability of agile methods
There is little if any consensus on what types of software projects are best suited for agile methodologies. Many large organizations have difficulty bridging the gap between a more traditional waterfall method and an agile one.
Large scale agile software development remains an active research area.[11][12]
Agile development has been widely documented (see Experience Reports, below, as well as Beck[13] pg. 157, and Boehm and Turner[14] pg. 55-57) as working well for small (<10 developers) co-located teams.
Some things that can negatively impact the success of an agile project are:

• Large scale development efforts (>20 developers), though scaling strategies[15] and evidence to the contrary[16] have been described.
• Distributed development efforts (non-co-located teams). Strategies have been described in Bridging the Distance[17]and Using an Agile Software Process with Offshore Development[18]
• Command-and-control company cultures
• Forcing an agile process on a development team
Barry Boehm and Richard Turner suggest that risk analysis be used to choose between adaptive ("agile") and predictive ("plan-driven") methods.[14] The authors suggest that each side of the continuum has its own home ground as follows:

Agile home ground:
• Low criticality
• Senior developers
• Requirements change very often
• Small number of developers
• Culture that thrives on chaos
Plan-driven home ground:
• High criticality
• Junior developers
• Requirements don't change too often
• Large number of developers
• Culture that demands order

Project management tools for agile development teams
A number of project management tools are specifically aimed at agile development. They are designed to help plan, track, analyse and integrate work. These tools play an important role in agile development, as a means of Knowledge Management.
Common features include: Version control integration, progress tracking, easy work allocation, integrated release and iteration planning, discussion forums, and reporting and tracking of software defects.
Earned Value Management is a PMI (Project Management Institute) approved project management technique to objectively measure the success of a project.

Agile methods
Some of the well-known agile software development methods:
• Agile Modeling
• Agile Unified Process (AUP)
• Agile Data Method
• DSDM
• Essential Unified Process (EssUP)
• Extreme programming (XP)
• Feature Driven Development (FDD)
• Getting Real
• Open Unified Process (OpenUP)
• Scrum

Agile practices
• Test Driven Development (TDD)
• Behavior Driven Development (BDD)
• Continuous Integration
• Pair Programming
• Planning poker
Note: Although these are often considered methodologies in and of themselves, they are simply practices used in different methodologies.


Criticism
Extreme Programming's initial buzz and controversial tenets, such as pair programming and continuous design, have attracted particular criticism, such as McBreen[25] and Boehm and Turner.[14] Many of the criticisms, however, are believed by Agile practitioners to be misunderstandings of agile development.[26]
In particular, Extreme Programming is reviewed and critiqued by Matt Stephens's and Doug Rosenberg's Extreme Programming Refactored.[27]
Criticisms include:
• Often used as a means to bleed money from customers through lack of defining a deliverable
• Lack of structure and necessary documentation
• Only works with senior-level developers
• Incorporates insufficient software design
• Requires meetings at frequent intervals at enormous expense to customers
• Requires too much cultural change to adopt
• Can lead to more difficult contractual negotiations
• Can be very inefficient—if the requirements for one area of code change through various iterations, the same programming may need to be done several times over. Whereas if a plan were there to be followed, a single area of code is expected to be written once.
• Impossible to develop realistic estimates of work effort needed to provide a quote, because at the beginning of the project no one knows the entire scope/requirements
• Can increase the risk of scope creep due to the lack of detailed requirements documentation
• Agile is feature driven, non-functional quality attributes are hard to be placed as user stories
The criticisms regarding insufficient software design and lack of documentation are addressed by the Agile Modeling method, which can easily be tailored into agile processes.
Agile software development has been criticized because it may not bring about all of the claimed benefits when programmers of average ability use this method.[28]


4 Ace Technologies