A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.

Overview of Extreme Programming (XP)

Extreme Programming (XP) is a software engineering 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.
XP utilizes four project control variables:
* Scope – If scope is reduced, you can get better quality or less time for the project.
* Cost – Need enough money to solve the problem.
* Time – More time can allow the scope or quality to be increased.
* Quality – Sacrificing quality can cost productivity and is not usually a good idea.
XP Values :
* Simplicity – It is better to implement the simplest solution.
* Communication – Increases cooperation, group productiveness, and decreases mistakes.
* Feedback – Keeps the project on track. Feedback should be almost continuous.
* Courage – To be able to throw code away when it is appropriate, or to re-factor late in the design to increase system performance.
The 12 original core practices of XP are :
– The Planning Game : Business and development cooperate to produce the maximum business value as rapidly as possible. The planning game happens at various scales, but the basic rules are always the same.
– Small Releases : Start with the smallest useful feature set. Release early and often, adding a few features each time.
– System Metaphor : Each project has an organizing metaphor, which provides an easy to remember naming convention.
– Simple Design : Always use the simplest possible design that gets the job done. The requirements will change tomorrow, so only do what’s needed to meet today’s requirements.
– Continuous Testing: Before programmers add a feature, they write a test for it. When the suite runs, the job is done. Tests in XP come in two basic flavors.
1. Unit Tests are automated tests written by the developers to test functionality as they write it. Each unit test typically tests only a single class, or a small cluster of classes. Unit tests are typically written using a unit testing framework, such as NUnit.
2. Acceptance Tests (also known as Functional Tests) are specified by the customer to test that the overall system is functioning as specified. Acceptance tests typically test the entire system, or some large chunk of it.
– Re-factoring : Refactor out any duplicate code generated in a coding session. You can do this with confidence that you didn’t break anything because you have the tests.
– Pair Programming : All production code is written by two programmers sitting at one machine. Essentially, all code is reviewed as it is written.
– Collective Code Ownership : No single person “owns” a module. Any developer is expected to be able to work on any part of the code base at any time.
– Continuous Integration : All changes are integrated into the code base at least daily. The tests have to run 100% both before and after integration.
– 40-Hour Work Week : Programmers go home on time. In crunch mode, up to one week of overtime is allowed. But multiple consecutive weeks of overtime are treated as a sign that something is very wrong with the process.
– On-site Customer : Development team has continuous access to a real live customer, that is, someone who will actually be using the system. For commercial software with lots of customers, a customer proxy (usually the product manager) is used instead.
– Coding Standards : Everyone codes to the same standards. Ideally, you shouldn’t be able to tell by looking at it which person on the team has touched a specific piece of code.

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>