CSC//ECE 517 Fall 2013/ch1 1w40 ao: Difference between revisions
No edit summary |
No edit summary |
||
(28 intermediate revisions by 2 users not shown) | |||
Line 17: | Line 17: | ||
The exact words of Kent Beck on starting with the development of a new methodology are as follows:[..................] | 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," | 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. | 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: | |||
Beck edited a series of books on XP, beginning with his own Extreme Programming Explained (1999, ISBN 0-201-61641-6) | * The original Wiki by Cunnigham [http://en.wikipedia.org/wiki/WikiWikiWeb 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''' == | == '''Current State''' == | ||
XP gained fame in 1990s and early 2000s.It was being incorporated into fields and environments much different to what it was made for initially. | |||
The original practices that were in existence in those days required a lot of high discipline and hence,where considered too rigid.As a result,they were often deprecated or left unfinished at times. | |||
A less rigid schedule like XP,allows complex features to be fully developed.XP,unlike other agile development methodologies,is still evolving and incorporating changes. | |||
== '''Concept''' == | == '''Concept''' == | ||
''' Goals''' | |||
The fundamental goal behind extreme programming is to produce higher quality software in shorter periods of time. These goals can be achieved by improving the overall productivity of the development team. | |||
Having multiple short term sprints facilitates this goal. That way the requirements are always unstable, and keep changing according to feedback received from the customer/s. The entire idea behind this is that change is good and should be embraced and not discouraged. | |||
''' Activities''' | |||
XP describes four activities that are done during the software development process. coding, testing, listening and designing. | |||
-Coding | |||
Code is considered to be the most important aspect of the software product. Code is clear, concise and is not subject to multiple interpretations. If there is some aspect of the programming problem that the programmer finds it difficult to explain to his teammates in words, he/she may simply use code to illustrate their point. Other programmers may make comments on this code or quite simply write code that suggests improvements over the current code. | |||
''' Testing''' | |||
Testing is a very important feature of Extreme Programming. In traditional software development, testing was an activity that was put off till the very end. However, extreme programming encourages the principles of test driven development. It is believed that some testing eliminates some flaws and a lot of testing eliminates many flaws. There are two major types of tests | |||
Unit tests are used to test whether some features of the code are working as was the intention. The programmer should incorporate as many automated tests as they can which they think might break the code. When all tests get completed then the coding is complete. Every piece of code must be tested before moving on to the next feature. | |||
Acceptance tests verify that the requirements have been understood correctly by the programmers. | |||
''' Listening''' | |||
Programmers should be mindful of what the customer wants the system to be like and the business logic when they are writing code. The flow of communication must be smooth and if there are any questions they must be resolved by careful discussions. | |||
''' Designing''' | |||
If you would like to keep things simple, you would think that good coding, testing and listening would result in a good software product. This doesn’t quite work that way though. Laying out a good design is one of the essential requirements of a good software product. Even though you might think that you can get by without good design in the initial stages of software development, there will come a time when one will get stuck. Such a state can be avoided by good software design which is well laid out and is logically sound. | |||
stuck. Such a state can be avoided by good software design which is well laid out and is logically sound. | |||
== '''Values of XP''' == | |||
Extreme Programming first had only four values till 1999 which are Communication,Simplicity,Feedback and Courage.The fifth value came in the second edition of Extreme programming Explained. | |||
'''Communication''' | |||
Communication was always handled through documentation in older software development practices.Extreme programming takes this to the extreme levels and incorporates simple designs,collaboration of users as well as programmers,frequent meetings and verbal communication and feedback from the customers as well as peers. | |||
'''Simplicity''' | |||
The simplicity in Extreme programming is that it stresses on starting with on the simplest task and reaching short term goals and then taking them to the extreme level as we progress. | |||
The aim is to focus on the tasks that should be completed in short-term and get done with it.The flaw here is that somethings that are ignored as of today may require more efforts as regards to design as well as implementation changes in the future.The design should be simple as well as the code so that everyone in the team can understand it and work with it. | |||
'''Feedback''' | |||
Feedback is a quintessential part of the Extreme programming methodology. | |||
Feedback can be from a person or can be from a system. | |||
e.g.Feedback received on account of writing tests like Unit tests,Performance tests,etc.On the other-hand,feedback from the customer can be obtain after doing functional tests by the customer/testers.This should be planned every one or two weeks. | |||
Feedback from the team is another form of feedback where the team as a whole reviews each others work and collaborates with the changing requirements of the customers. | |||
Kent Beck says the following about feedback "Optimism is an occupational hazard of programming. Feedback is the treatment." | |||
'''Courage''' | |||
Courage is a required thing in Extreme Programming and lies in the fact that code can be refactored as per the requirements.This requires a lot of review for the existing system and making changes to accommodate changes that will come in future. | |||
Another form of courage can be deciding on when to throw obsolete code away insoite of efforts neeeded to create the code in the first place. | |||
Corage is the second word for persistence.A coder should be persistent till he gets his problem solved completely. | |||
'''Respect''' | |||
Respect should be given to one0self i.e. self-respect as well as to all members of the team.One should respect his/her own work by looking to create the highest quality and seeking best solution by making use of refactoring as much as possible. | |||
Nobody should be ignored instead should be encouraged and respected. | |||
== '''Rules of XP''' == | |||
Every software development methodology comes bundled with some rules.In the case of XP,we have rules which were laid down by Don Wells in 1999.There were total 29 rules.XP rules were also proposed by Ken Auer.He proposed two categories 1)Rules of Engagement:Define the environment 2)Rules of play:Define the activities. | |||
'''Principles''' | |||
Principles are a step further than values.Principles are supposed to be more practical and applicable to real situations. | |||
'''Feedback''' | |||
Feedback is something that we get from the reviewers after something is delivered.Feedbacks should be done frequently and periodically.Feedbacks are a means for the customer to give his/her two cents while the development is in it's iterative stages.It can act as a way to give a direction to the development process of the software as per the customization of the customer.The testing perspective for feedback is Unit testing.In which for each iterative development,unit tests are performed to check how the system reacts.A suite can act as a feedback mechanism giving quick feedbacks to every iterative development and the developer can understand that his changes cannot be incorporated and need to be further developed. | |||
'''Assuming simplicity''' | |||
Assume that the problem at hand is simple and can be handled easily.Make iterative releases and involve the customer.This way,the customer will be involved and have more control. | |||
'''Embracing change''' | |||
Take account of the changes that are needed to be incorporated and make strategies to do so efficiently. | |||
== '''Practices in XP''' == | |||
Extreme programming has 12 practices which are grouped into 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 | |||
The unit test must be coded first | |||
Optimization must be done last | |||
Testing | |||
All code must have unit test | |||
Code must pass unit tests before continuing | |||
Acceptance tests should be run often and tests must be published | |||
== '''Controversial aspects''' == | |||
XP has been a topic of great discussion. People who support this programming methodology claim that extreme programming adds flexibility to the process and reduces costs associated with formal meetings. However, critics claim that extreme programming can lead to rework, which may cause costs to increase from what was previously agreed upon. | |||
Change-control boards are a sign that there might be some conflicts in project objectives and constraints between multiple users. Also, XP’s expedited method depends on the programmers being able to assume a unified client viewpoint to avoid time getting wasted in documentation and the programmer can focus on writing good code. | |||
Other controversial aspects include: | |||
* Requirements are expressed incrementally, so there is no requirement specification at the start. | |||
* Software developers are required to work in pairs and this causes problems when there are two opposite personalities who don’t like to work with each other. | |||
* Requirements are expressed as acceptance tests rather than documents. | |||
* There is just one customer representative which can cause a single point of failure | |||
Scalability | |||
The problem with XP is that it traditionally works with teams of 20 or so people which is not exactly tailored to every big organization. One way to overcome this is to work in smaller teams within the organization. |
Latest revision as of 01:06, 8 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 gained fame in 1990s and early 2000s.It was being incorporated into fields and environments much different to what it was made for initially. The original practices that were in existence in those days required a lot of high discipline and hence,where considered too rigid.As a result,they were often deprecated or left unfinished at times. A less rigid schedule like XP,allows complex features to be fully developed.XP,unlike other agile development methodologies,is still evolving and incorporating changes.
Concept
Goals
The fundamental goal behind extreme programming is to produce higher quality software in shorter periods of time. These goals can be achieved by improving the overall productivity of the development team.
Having multiple short term sprints facilitates this goal. That way the requirements are always unstable, and keep changing according to feedback received from the customer/s. The entire idea behind this is that change is good and should be embraced and not discouraged.
Activities
XP describes four activities that are done during the software development process. coding, testing, listening and designing. -Coding Code is considered to be the most important aspect of the software product. Code is clear, concise and is not subject to multiple interpretations. If there is some aspect of the programming problem that the programmer finds it difficult to explain to his teammates in words, he/she may simply use code to illustrate their point. Other programmers may make comments on this code or quite simply write code that suggests improvements over the current code.
Testing
Testing is a very important feature of Extreme Programming. In traditional software development, testing was an activity that was put off till the very end. However, extreme programming encourages the principles of test driven development. It is believed that some testing eliminates some flaws and a lot of testing eliminates many flaws. There are two major types of tests Unit tests are used to test whether some features of the code are working as was the intention. The programmer should incorporate as many automated tests as they can which they think might break the code. When all tests get completed then the coding is complete. Every piece of code must be tested before moving on to the next feature. Acceptance tests verify that the requirements have been understood correctly by the programmers.
Listening
Programmers should be mindful of what the customer wants the system to be like and the business logic when they are writing code. The flow of communication must be smooth and if there are any questions they must be resolved by careful discussions.
Designing
If you would like to keep things simple, you would think that good coding, testing and listening would result in a good software product. This doesn’t quite work that way though. Laying out a good design is one of the essential requirements of a good software product. Even though you might think that you can get by without good design in the initial stages of software development, there will come a time when one will get stuck. Such a state can be avoided by good software design which is well laid out and is logically sound. stuck. Such a state can be avoided by good software design which is well laid out and is logically sound.
Values of XP
Extreme Programming first had only four values till 1999 which are Communication,Simplicity,Feedback and Courage.The fifth value came in the second edition of Extreme programming Explained.
Communication
Communication was always handled through documentation in older software development practices.Extreme programming takes this to the extreme levels and incorporates simple designs,collaboration of users as well as programmers,frequent meetings and verbal communication and feedback from the customers as well as peers.
Simplicity
The simplicity in Extreme programming is that it stresses on starting with on the simplest task and reaching short term goals and then taking them to the extreme level as we progress. The aim is to focus on the tasks that should be completed in short-term and get done with it.The flaw here is that somethings that are ignored as of today may require more efforts as regards to design as well as implementation changes in the future.The design should be simple as well as the code so that everyone in the team can understand it and work with it.
Feedback
Feedback is a quintessential part of the Extreme programming methodology. Feedback can be from a person or can be from a system. e.g.Feedback received on account of writing tests like Unit tests,Performance tests,etc.On the other-hand,feedback from the customer can be obtain after doing functional tests by the customer/testers.This should be planned every one or two weeks. Feedback from the team is another form of feedback where the team as a whole reviews each others work and collaborates with the changing requirements of the customers. Kent Beck says the following about feedback "Optimism is an occupational hazard of programming. Feedback is the treatment."
Courage
Courage is a required thing in Extreme Programming and lies in the fact that code can be refactored as per the requirements.This requires a lot of review for the existing system and making changes to accommodate changes that will come in future. Another form of courage can be deciding on when to throw obsolete code away insoite of efforts neeeded to create the code in the first place. Corage is the second word for persistence.A coder should be persistent till he gets his problem solved completely.
Respect
Respect should be given to one0self i.e. self-respect as well as to all members of the team.One should respect his/her own work by looking to create the highest quality and seeking best solution by making use of refactoring as much as possible. Nobody should be ignored instead should be encouraged and respected.
Rules of XP
Every software development methodology comes bundled with some rules.In the case of XP,we have rules which were laid down by Don Wells in 1999.There were total 29 rules.XP rules were also proposed by Ken Auer.He proposed two categories 1)Rules of Engagement:Define the environment 2)Rules of play:Define the activities.
Principles
Principles are a step further than values.Principles are supposed to be more practical and applicable to real situations.
Feedback
Feedback is something that we get from the reviewers after something is delivered.Feedbacks should be done frequently and periodically.Feedbacks are a means for the customer to give his/her two cents while the development is in it's iterative stages.It can act as a way to give a direction to the development process of the software as per the customization of the customer.The testing perspective for feedback is Unit testing.In which for each iterative development,unit tests are performed to check how the system reacts.A suite can act as a feedback mechanism giving quick feedbacks to every iterative development and the developer can understand that his changes cannot be incorporated and need to be further developed.
Assuming simplicity
Assume that the problem at hand is simple and can be handled easily.Make iterative releases and involve the customer.This way,the customer will be involved and have more control.
Embracing change
Take account of the changes that are needed to be incorporated and make strategies to do so efficiently.
Practices in XP
Extreme programming has 12 practices which are grouped into 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 The unit test must be coded first Optimization must be done last
Testing All code must have unit test Code must pass unit tests before continuing Acceptance tests should be run often and tests must be published
Controversial aspects
XP has been a topic of great discussion. People who support this programming methodology claim that extreme programming adds flexibility to the process and reduces costs associated with formal meetings. However, critics claim that extreme programming can lead to rework, which may cause costs to increase from what was previously agreed upon.
Change-control boards are a sign that there might be some conflicts in project objectives and constraints between multiple users. Also, XP’s expedited method depends on the programmers being able to assume a unified client viewpoint to avoid time getting wasted in documentation and the programmer can focus on writing good code.
Other controversial aspects include:
- Requirements are expressed incrementally, so there is no requirement specification at the start.
- Software developers are required to work in pairs and this causes problems when there are two opposite personalities who don’t like to work with each other.
- Requirements are expressed as acceptance tests rather than documents.
- There is just one customer representative which can cause a single point of failure
Scalability The problem with XP is that it traditionally works with teams of 20 or so people which is not exactly tailored to every big organization. One way to overcome this is to work in smaller teams within the organization.