Agile and Extreme Programming

[arul_satish]

Introduction to Extreme Programming (XP):

Extreme programming (XP) was developed by Kent Beck during his work on the Chrysler Comprehensive Compensation System (C3) payroll project. Although extreme programming itself is relatively new, many of its practices are around for some time as it just takes "best practices" to extreme levels.
XP is an agile methodology which is predominantly intended to improve product quality and responsiveness to changing customer requirements. It advocates frequent "releases" in short development cycles called “timeboxing”.

Extreme programming includes paired programming or doing extensive code review, Test Driven development (TDD), last responsive moment, a flat management structure, simplicity and clarity (in code), waiting till the problem is clear, frequent communication with the customer and programmers. This methodology offers benefits that are taken "extreme" levels, on the theory that if a little is good, more is better. XP is still evolving, assimilating more lessons from experiences in the field, to use other practices and has added more values and practices.

XP reduces the cost of changes in requirements by executing multiple-incremental short development cycles, rather than a long one. XP looks at changes as natural, inescapable and desirable, and must be planned for instead of defining a stable set of requirements. XP uses a number of basic values, principles and practices on top of the agile framework.

Activities
XP has four basic activities within the development process e.g., like coding, testing, listening, and designing in software development process. Each of those activities is described below:

1. Coding (Development)
XP states that the only truly important outcome is the resulting product (service or software code) without the product (or code), there is no outcome of the development process.
Product (or code) can also be used to figure out the most suitable solution or to communicate problems. A complex development problem can be explained by using the product to demonstrate what he or she means, as it is always clear and concise. It cannot be interpreted in more than one way. Developers can also give feedback on the product by modifying the product or code.

2. Testing
XP believes that if a little testing can eliminate a few flaws, a lot of testing can eliminate many more flaws. Unit testing determines whether a given feature works as intended. A developer runs many automated tests and if all tests run successfully, then the product is complete. Acceptance tests verify that the requirements are met as per customer's satisfaction. These tests occur in the exploration phase of release planning.

To be continued...

[arul_satish]

3. Listening (Feedback)
Developer must listen to customer’s business logic and their requirements. They must explain the technological difficulties or abilities to the understanding of the customers.

4. Designing
Complexities and dependence of the system must be avoided. A good as well as a working design that eliminates dependencies and the complexities, of changes to product from time to time is important. This means that changing one part of the product will not affect other parts of the product.

Values of XP
Extreme Programming believes in its five core values as given below:

1. Communication
Product development requires a good deal of communication to understand the customer’s requirements. As the life cycle is short XP requires that product is built rapidly and knowledge is disseminated to all the development team rapidly as well. This gives them a shared view of the product as it is with the customers. Further, extreme programming favors simple designs, common metaphors, collaboration of users and programmers, frequent verbal communication, and feedback.

2. Simplicity
Extreme programming believes in starting with the simplest solution first and other functionalities can be added later. It focuses on designing and coding for the needs of today instead of those of tomorrow, next week, or next month with the help of good and efficient design.

3. Feedback
In XP feedback is required from three dimensions of product development:
1. Product Feedback: by writing unit test, or running periodic integration tests, the developers get direct feedback from the state of the product after every change.
2. Customer Feedback: The acceptance test written by the customer and the testers gives a considerable feedback on the current state of the product. This feedback is done every two or three weeks to let the customer easily steer the development.
3. Team Feedback: As the customers are involved in every aspect of the product development, when customers come up with new requirements in the planning game, the team directly gives an estimation of the time required to implement.
Any feedback is closely related to communication and simplicity. As Kent Beck says "Optimism is an occupational hazard of programming. Feedback is the treatment."

4. Courage
The XP practices advocates courage like doing design and code for today. This practice helps in avoiding getting bogged down in design and the effort that is being put in. Further courage is required for the team to refractor the code or to throw away code that doesn’t satisfy the requirements or to persistently working towards goal.

5. Respect
XP also believes respect for self and others. Developers should avoid anything that delays or hinders the work of others.
Adopting these values requires a high level of motivation and loyalty towards the team, and towards the goal of the project.

The rest in next article…

[arul_satish]

Continuation...

XP Rules
As per Mr. Don Wells, there are 29 rules in the categories of planning, managing, designing, coding, and testing. Planning, managing and designing are called out explicitly to counter claims that XP doesn't support those activities. Mr. Ken Auer states that XP is defined by its rules and not its practices.

XP Principles
The principles that form the basis of XP are based on the values that are intended to foster decisions in a product development project. The following principles are intended to be guidance in a practical situation.

1. XP Feedback
XP uses feedback as its most useful tool as if it is done rapidly and the time between an action and its feedback is critical to learning and making changes. In XP, contact with the customer occurs in more frequent iterations and as the customer has clear insight into his/her product he/she can give feedback and steer the development as needed. Unit tests also contribute to the rapid feedback principle.

2. XP Assuming simplicity
This is about having simple solutions for every problem that is simple or complex. XP says that making big changes all at once does not work. Extreme programming applies incremental changes: for example, a system might have small releases every three weeks. As the changes are made in many little steps, the customer has more control over the development process and the product that is being developed.

3. XP Embracing change
The principle of embracing change is about not against changes in product or requirements but embracing them as and when it surfaces as per it’s priority by the customers.

Rest in Next...

[arul_satish]

Continuation...

Practices
XP has 12 practices, grouped into following four areas:

Fine scale feedback
• Pair programming
• Planning game
• Test-driven development
• Whole team

Continuous process
• Continuous integration
• Refactoring or design improvement
• Small releases

Shared understanding
• Coding standards
• Collective code ownership
• Simple design
• System metaphor

Programmer welfare
• Sustainable pace

Coding
• The customer is always available
• Code the Unit test first
• Only one pair integrates code at a time
• Leave Optimization until last
• No Overtime

Testing
• All code must have Unit tests
• All code must pass all Unit tests before it can be released
• When a Bug is found tests are created before the bug is addressed (a bug is not an error in logic, it is a test you forgot to write)
• Acceptance tests are run often and the results are published

Rest in Next...

[arul_satish]

Controversial aspects of XP:

The practices in XP have been heavily debated. XP proponents claim that by having the on-site customer request changes informally, the process becomes flexible, and saves the cost of formal overhead. XP critics claim this can lead to costly rework and project scope creep beyond what was previously agreed or funded.

Other potentially controversial aspects of extreme programming include:
• Requirements are expressed as automated acceptance tests rather than specification documents.
• Requirements are defined incrementally, rather than trying to get them all in advance.
• Software developers are usually required to work in pairs.
• There is no Big Design Up Front.
• A customer representative is attached to the project.
• Dependence upon all other aspects of XP.

[arul_satish]

Scalability of XP:

Normally, XP only works on teams of twelve or fewer (max 20) people. One way to circumvent this limitation is to break up the project into smaller pieces and the team into smaller groups. It has been claimed that XP has been used successfully on teams of over a hundred developers and also has claimed reasonable success on distributed XP projects with up to sixty people.
Industrial Extreme Programming (IXP) was introduced as an evolution of XP and it is intended to bring the ability to work in large and distributed teams.

To be concluded...

[arul_satish]

Some of the criticism on XP:
Extreme programming's initial buzz and controversial tenets, such as pair programming and continuous design, have attracted many criticisms. However, they are believed by Agile practitioners to be misunderstandings of agile development.

Criticisms include:
• A methodology is only as effective as the people involved, Agile does not solve this
• 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 End of XP.

[LucasPato]

а чтоб отдых был по полной
Проститутки Москвы - Кристина