Agile or Extreme development model

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

Agile methods break tasks into small increments with minimal planning and do not directly involve long-term planning. Iterations are short time frames (timeboxes) that typically last from one to four weeks. Each iteration involves a team working 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 minimizes overall risk and allows the project to adapt to changes quickly. Stakeholders produce documentation as required. An iteration might not add enough functionality to warrant a market release, but the goal is to have an available release (with minimal bugs) at the end of each iteration. Multiple iterations might 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 an iteration requires. They decide individually how to meet an iteration's requirements.

Agile methods emphasize face-to-face communication over written documents when the team is all in the same location. Most agile teams work in a single open office (called a bullpen), which facilitates such communication. Team size is typically small (5-9 people) to simplify team communication and team collaboration. Larger development efforts can be delivered by multiple teams working toward a common goal or on different parts of an effort. This might require a coordination of priorities across teams. When a team works in different locations, they maintain daily contact through videoconferencing, voice, e-mail, etc.

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 (ROI) and ensuring alignment with customer needs and company goals.

Most agile implementations use 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 the previous day, what they intend to do today, and what their roadblocks are. This face-to-face communication exposes problems as they arise. "These meetings, sometimes referred as daily stand-ups or daily scrum meetings, are held in at the same place and same time every day and should last no more than 15 minutes. Standing up usually enforces that rule."

Agile development emphasizes working software as the primary measure of progress. This, combined with the preference for face-to-face communication, produces less written documentation than other methods. The agile method encourages stakeholders to prioritize "wants" with other iteration outcomes, based exclusively on business value perceived at the beginning of the iteration (also known as value-driven).

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.

Extreme Programming (XP) is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development, it advocates frequent "releases" in short development cycles (timeboxing), which is intended to improve productivity and introduce checkpoints where new customer requirements can be adopted.

Other elements of Extreme Programming include: programming in pairs or doing extensive code review, unit testing of all code, avoiding programming of features until they are actually needed, a flat management structure, simplicity and clarity in code, expecting changes in the customer's requirements as time passes and the problem is better understood, and frequent communication with the customer and among programmers. The methodology takes its name from the idea that the beneficial elements of traditional software engineering practices are taken to "extreme" levels, on the theory that if a little is good, more is better.

Critics have noted several potential drawbacks, including problems with unstable requirements, no documented compromises of user conflicts, and a lack of an overall design specification or document.

Extreme Programming (XP) is a lightweight process
Ground rules:

• small team (2 to 12)
• continuous access to customers
• OO design and code (Smalltalk, Java)
• change management system (code and tests)
• the system is always “working” (growing functionality over time)
• overall development cycle – between 4 and 12 months
• new release to customer every 2-3 months
• internal iterations every two weeks
• not for life-critical systems (heart monitor, nuclear power plant, avionics systems, etc.)

Some Rules of Extreme Programming

Planning rules

• do project planning via “user stories”
• plan a series of very small internal releases
• start each day with a “stand-up meeting”

Design rules

• keep the design simple (use the simplest thing that could work)
• refactor as needed

Coding rules

• talk with the customer throughout the coding process
• always code in pairs
• code unit tests first
• follow coding standards

Testing rules

• unit tests for all code
• acceptance tests for each user story

Agile Processes

“Agile” is a generalization of XP
Examples of agile processes:

• Crystal Clear
• Scrum
• Adaptive Software Development
• DSDM [Dynamic Systems Development Model]
• Lean Development

Agile Manifesto

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

Agile principles

Agile software development follows a small number of basic principles:

• customer needs come first – so keep listening for changes in requirements, don't reject new requirements just because “the requirements are already signed off”
• deliver software (and other artifacts) often – don’t wait for months to get feedback
• in the development world, people are more valuable than computer tools – and face-to-face communication is the most efficient way to convey
• complex information (both with other developers and with customers)
• working software is the primary measure of progress

Agile characteristics

Most of the agile processes are “controlled chaos”:

• short development iterations, with product “shipped” to either a customer or a pseudo-customer at regular intervals
• continuous testing – such as daily regression tests
• collecting customer requirements using scenarios or use cases
• small team sizes
• informal modeling techniques – CRC cards, simple drawings on whiteboards
• adaptive planning techniques – plans are updated based on intermediate results and reprioritization by the customers

Agile versus XP

Most agile process are less radical than XP:

• don’t require pair programming
• multiple roles, not just “general-purpose developer”
• various methods of iteration planning
• existing heavyweight processes can be adapted to be more “agile”
•  

--Wikipedia,ACM