CSC//ECE 517 Fall 2013/ch1 1w40 ao: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 28: Line 28:


== '''Current State''' ==
== '''Current State''' ==
XP generated significant interest amongst software communities in the late 1990s and early 2000s, seeing adoption in a number of environments radically different from its origins.
The high discipline required by the original practices often went by the wayside, causing some of these practices, such as those thought too rigid, to be deprecated or reduced, or even left unfinished, on individual sites. For example, the practice of end-of-day integration tests, for a particular project, could be changed to an end-of-week schedule, or simply reduced to mutually agreed dates. Such a more relaxed schedule could avoid people feeling rushed to generate artificial stubs just to pass the end-of-day testing. A less-rigid schedule allows, instead, for some complex features to be more fully developed over a several-day period. However, some level of periodic integration testing can detect groups of people working in non-compatible, tangent efforts before too much work is invested in divergent, wrong directions.
Meanwhile, other agile development practices have not stood still, and XP is still evolving, assimilating more lessons from experiences in the field, to use other practices. In the second edition of Extreme Programming Explained (November 2004), five years after the first edition, Beck added more values and practices and differentiated between primary and corollary practices.


== '''Concept''' ==
== '''Concept''' ==

Revision as of 15:59, 5 October 2013

Xtreme Programming

Extreme Programming XP is a Software Development Methodology which is a type of agile software development[]. It has proved to be very successful at many companies of different sizes and scale. Frequent releases in short development cycles is one of the major fundamentals of extreme programming similar to agile software development.

The intention behind this is improved productivity and quality of software and higher customer satisfaction.

Pair programming, extensive code reviews and test driven development are some other important features of Extreme programming. It intends to create a flat management structure again like normal agile software development.

The name derives from the fact that normal principles of software engineering practices are taken to a level that would be categorized as extreme when it was put into use. 

Criticism around agile revolves around drawbacks such as unstable requirements and the lack of documentation as far as the design specification is concerned.

History

In 1990,there was a revolution in the domain of Software Development.Firstly,was the rise of object-oriented programming over procedural programming and secondly,was the rise of the internet.These factors demanded rapidly-changing requirements and shorter product life-cycles.The old software development strategies had begun to go obsolete. Extreme Programming was created by Kent Beck when he was asked to work on the Chrysler Comprehensive Compensation System (C3) payroll project. Chrysler Comprehensive Compensation System was a project started to determine as to what can be the best way to make use of object technologies with Smalltalk as the language and Gemstone as the data access layer.The motive was to use the payroll systems at Chrysler as the object of research.Kent Beck was a prominent practitioner of Smalltalk and hence, was chosen to lead this project.However,when he undertook the project,he noticed several shortcommings in the current development process.He formulated this and made use of this to make a new development methodology with the help of his colleague Ward Cunnigham. The exact words of Kent Beck on starting with the development of a new methodology are as follows:[..................]

The first time I was asked to lead a team, I asked them to do a little bit of the things I thought were sensible, like testing and reviews. The second time there was a lot more on the line.I thought,"Damn the torpedoes, at least this will make a good article,"and asked the team to crank up all the knobs to 10 on the things I thought were essential and leave out everything else."

Ron Jeffries was also asked to join the project by Beck.He acted as a coach to the project team.

Various sources for information about this new developing methodology published by the team itself are as follows:

  • The original Wiki by Cunnigham WikiWikiWeb
  • The XP website itself: "http://www.extremeprogramming.org" circa 1999.
  • Beck edited a series of books on XP, beginning with his own Extreme Programming Explained (1999, ISBN 0-201-61641-6).


Current State

XP generated significant interest amongst software communities in the late 1990s and early 2000s, seeing adoption in a number of environments radically different from its origins. The high discipline required by the original practices often went by the wayside, causing some of these practices, such as those thought too rigid, to be deprecated or reduced, or even left unfinished, on individual sites. For example, the practice of end-of-day integration tests, for a particular project, could be changed to an end-of-week schedule, or simply reduced to mutually agreed dates. Such a more relaxed schedule could avoid people feeling rushed to generate artificial stubs just to pass the end-of-day testing. A less-rigid schedule allows, instead, for some complex features to be more fully developed over a several-day period. However, some level of periodic integration testing can detect groups of people working in non-compatible, tangent efforts before too much work is invested in divergent, wrong directions. Meanwhile, other agile development practices have not stood still, and XP is still evolving, assimilating more lessons from experiences in the field, to use other practices. In the second edition of Extreme Programming Explained (November 2004), five years after the first edition, Beck added more values and practices and differentiated between primary and corollary practices.


Concept