Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Extreme Programming (XP)
Post: #1


Extreme Programming (XP) is actually a deliberate and disciplined approach to software development. About six years old, it has already been proven at many companies of all different sizes and industries worldwide. XP is successful because it stresses customer satisfaction. The methodology is designed to deliver the software your customer needs when it is needed. XP empowers software developers to confidently respond to changing customer requirements, even late in the life cycle. This methodology also emphasizes teamwork. Managers, customers, and developers are all part of a team dedicated to delivering quality software. XP implements a simple, yet effective way to enable groupware style development.

XP improves a software project in four essential ways; communication, simplicity feedback, and courage. XP programmers communicate with their customers and fellow programmers. They keep their design simple and clean. They get feedback by testing their software starting on day one. They deliver the system to the customers as early as possible and implement changes as suggested. With this foundation XP programmers are able to courageously respond to changing requirements and technology. XP is different. It is a lot like a jig saw puzzle. There are many small pieces. Individually the pieces make no sense, but when combined together a complete picture can be seen. This is a significant departure from traditional software development methods and ushers in a change in the way we program.

If one or two developers have become bottlenecks because they own the core classes in the system and must make all the changes, then try collective code ownership. You will also need unit tests. Let everyone make changes to the core classes whenever they need to. You could continue this way until no problems are left. Then just add the remaining practices as you can. The first practice you add will seem easy. You are solving a large problem with a little extra effort. The second might seem easy too. But at some point between having a few XP rules and all of the XP rules it will take some persistence to make it work. Your problems will have been solved and your project is under control.

It might seem good to abandon the new methodology and go back to what is familiar and comfortable, but continuing does pay off in the end. Your development team will become much more efficient than you thought possible. At some point you will find that the XP rules no longer seem like rules at all. There is a synergy between the rules that is hard to understand until you have been fully immersed. This up hill climb is especially true with pair programming, but the pay off of this technique is very large. Also, unit tests will take time to collect, but unit tests are the foundation for many of the other XP practices so the pay off is very great.

XP projects are not quiet; there always seems to be someone talking about problems and solutions. People move about, asking each other questions and trading partners for programming. People spontaneously meet to solve tough problems, and then disperse again. Encourage this interaction, provide a meeting area and set up workspaces such that two people can easily work together. The entire work area should be open space to encourage team communication. The most obvious way to start extreme programming (XP) is with a new project. Start out collecting user stories and conducting spike solutions for things that seem risky. Spend only a few weeks doing this. Then schedule a release planning meeting. Invite customers, developers, and managers to create a schedule that everyone agrees on. Begin your iterative development with an iteration planning meeting. Now you're started.
Post: #2
Post: #3

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.

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 some is good, more is better. It is unrelated to "cowboy coding", which is more free-form and unplanned. It does not advocate "death march" work schedules, but instead working at a sustainable pace

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

for more read
Post: #4
lot of thnx for sharing information
Post: #5

Anu Gude
Syed Rahila

Presentation Outline
Overview of Extreme Programming
Key Practices of Extreme Programming
Advantages of XP
Disadvantages of XP
Extreme Programming (XP) was conceived and developed by Kent Beck to address the specific needs of software development conducted by small teams in the face of vague and changing requirements.
Extreme Programming nominates coding as the key activity.
The programmer is the heart of XP.
Why Extreme?
XP takes commonsense principles and practices to extreme levels.
If code reviews are good, we’ll review code all the time (pair programming).
If testing is good, everybody will test all the time (unit testing).
If design is good, we’ll make it part of everybody’s daily business (refactoring).
If integration testing is important, then we’ll integrate and test several times a day.
If short iterations are good, we will make the iterations really, really short – seconds, minutes and hours, not weeks, months and years.
This new lightweight methodology challenges many conventional tenets, including the long-held assumption that the cost of changing a piece of software rises dramatically over the course of time.
The cost of change curve for XP is a flat curve, which is achieved by simple design, tests, and an attitude of constant refinement of the design.
Historical Cost of Change Curve - The cost of change rising exponentially over time
XP Cost of Change Curve - The cost of change may NOT rise over time
Fundamentals of XP include:
Writing unit tests before programming and keeping all of the tests running at all times.
Integrating and testing the whole system--several times a day.
Producing all software in pairs, two programmers at one screen.
Starting projects with a simple design that constantly evolves to add needed flexibility and remove unneeded complexity.
Putting a minimal system into production quickly and growing it in whatever directions prove most valuable.
Why is XP so different?
XP doesn't force team members to specialize and become analysts, architects, programmers, testers, and integrators--every XP programmer participates in all of these critical activities every day.
XP doesn't conduct complete up-front analysis and design--an XP project starts with a quick analysis of the entire system, and XP programmers continue to make analysis and design decisions throughout development.
Develop infrastructure and frameworks as you develop your application, not up-front--delivering business value is the heartbeat that drives XP projects.
Don't write and maintain implementation documentation--communication in XP projects occurs face-to-face, or through efficient tests and carefully written code.
XP - What is involved: The four basic activities of Extreme Programming are coding, testing, listening, and designing.

Coding: You code because if you don't code, at the end of the day you haven't done anything.
Testing: You test because if you don't test, you don't know when you are done coding
Listening: You listen because if you don't listen you don't know what to code or what to test
Designing: And you design so you can keep coding and testing and listening indefinitely (good design allows extension of the system with changes in only one place)

Post: #6
to get information about the topic "extreme programming" full report ppt and related topic refer the link bellow

Important Note..!

If you are not satisfied with above reply ,..Please


So that we will collect data for you and will made reply to the request....OR try below "QUICK REPLY" box to add a reply to this page
Popular Searches: programming blog, email art extreme ru loc es, cs106b programming abstractions in c, rf programming for at89v51, blast extreme fun center, embedded c programming, http www seminarprojects com thread extreme programming seminar report,

Quick Reply
Type your reply to this message here.

Image Verification
Image Verification
(case insensitive)
Please enter the text within the image on the left in to the text box below. This process is used to prevent automated posts.

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Genetic Programming Seminar Report Information Technology 5 15,090 15-03-2012 01:16 PM
Last Post: seminar paper
  CONTEXT ORIENTED PROGRAMMING project topics 2 1,371 18-08-2011 10:04 AM
Last Post: seminar addict
  Socket Programming computer science crazy 3 3,486 30-04-2011 09:47 AM
Last Post: seminar class
Thumbs Up Linux Shell Programming projectsofme 0 1,387 07-10-2010 04:58 PM
Last Post: projectsofme