extreme programming(xp). waterfall methodology(revision)
TRANSCRIPT
Extreme Programming(XP)
Waterfall Methodology(Revision)
Introduction
Most Software projects Fail It cost huge amount of money before it fails
Introduction
Extreme Programming is one of several popular Agile Processes.
It has already been proven to be very successful at many companies of all different sizes and industries world wide.
Extreme Programming is successful because it stresses customer satisfaction.
Instead of delivering everything you could possibly want on some date far in the future this process delivers the software you need as you need it.
What is Extreme Programming?
An agile development methodology Created by Kent Beck in the mid 1990’s A set of 12 key practices taken to their
“extremes”
Extreme programming (XP) is a software development 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, which is intended to improve productivity and introduce checkpoints at which new customer requirements can be adopted.
Extreme programming(Sommerville)
Perhaps the best-known and most widely used agile method.
Extreme Programming (XP) takes an ‘extreme’ approach to iterative development. New versions may be built several times per day; Increments are delivered to customers every 2
weeks; All tests must be run for every build and the build
is only accepted if tests run successfully.
The XP release cycle
Break downstories to tasks
Select userstories for this
releasePlan release
Releasesoftware
Evaluatesystem
Develop/integrate/test software
Extreme programming practices 1
Incremental planning Requirements are recorded on Story Cards and the Stories to beincluded in a release are determined by the time available andtheir relative priority. The developers break these Stories intodevelopment ÔTasksÕ.
Small Releases The minimal useful set of functionality that provides businessvalue is developed first. Releases of the system are frequent andincrementally add functionality to the first release.
Simple Design Enough design is carried out to meet the current requirementsand no more.
Test first development An automated unit test framework is used to write tests for a newpiece of functionality before that functionality itself isimplemented.
Refactoring All developers are expected to refactor the code continuously assoon as possible code improvements are found. This keeps thecode simple and maintainable.
Extreme programming practices 2
Pair Programming Developers work in pairs, checking each otherÕs work andproviding the support to always do a good job.
Collective Ownership The pairs of developers work on all areas of the system, so thatno islands of expertise develop and all the developers own all thecode. Anyone can change anything.
Continuous Integration As soon as work on a task is complete it is integrated into thewhole system. After any such integration, all the unit tests in thesystem must pass.
Sustainable pace Large amounts of over-time are not considered acceptable as thenet effect is often to reduce code quality and medium termproductivity
On-site Customer A representative of the end-user of the system (the Customer)should be available full time for the use of the XP team. In anextreme programming process, the customer is a member of thedevelopment team and is responsible for bringing systemrequirements to the team for implementation.
Requirements scenarios
In XP, user requirements are expressed as scenarios or user stories.
These are written on cards and the development team break them down into implementation tasks. These tasks are the basis of schedule and cost estimates.
The customer chooses the stories for inclusion in the next release based on their priorities and the schedule estimates.
Story card for document downloading
Downloading and printing an article
First, you select the article that you want from a displayed list. Youthen have to tell the system how you will pay for it - this can eitherbe through a subscription, through a company account or by creditcard.
After this, you get a copyright form from the system to fill in and,when you have submitted this, the article you want is downloadedonto your computer.
You then choose a printer and a copy of the article is printed. Youtell the system if printing has been successful.
If the article is a print-only article, you canÕ t keep the PDF versionso it is automatically deleted from your computer .
XP and change
Conventional wisdom in software engineering is to design for change. It is worth spending time and effort anticipating changes as this reduces costs later in the life cycle.
XP, however, maintains that this is not worthwhile as changes cannot be reliably anticipated.
Rather, it proposes constant code improvement (refactoring) to make changes easier when they have to be implemented.
Testing in XP
Test-first development. Incremental test development from scenarios. User involvement in test development and
validation. Automated test harnesses are used to run all
component tests each time that a new release is built.
Task cards for document downloading
Task 1: Implement principal workflow
Task 2: Implement article catalog and selection
Task 3: Implement payment collection
Payment may be made in 3 dif ferent ways. The userselects which way they wish to pay. If the userhas a library subscription, then they can input thesubscriber key which should be checked by thesystem. Alternatively , they can input an or ganisationalaccount number. If this is valid, a debit of the costof the article is posted to this account. Finally , theymay input a 16 digit credit card number and expirydate. This should be checked for validity and, ifvalid a debit is posted to that credit card account.
Test case description
Test 4: Test credit card validity
Input:A string representing the credit card number and two integers representingthe month and year when the card expiresTests:Check that all bytes in the string are digitsCheck that the month lies between 1 and 12 and theyear is greater than or equal to the current year .Using the first 4 digits of the credit card number ,check that the card issuer is valid by looking up thecard issuer table. Check credit card validity by submitting the cardnumber and expiry date information to the cardissuerOutput:OK or error message indicating that the card is invalid
Test-first development
Writing tests before code clarifies the requirements to be implemented.
Tests are written as programs rather than data so that they can be executed automatically. The test includes a check that it has executed correctly.
All previous and new tests are automatically run when new functionality is added. Thus checking that the new functionality has not introduced errors.
Pair programming
In XP, programmers work in pairs, sitting together to develop code.
This helps develop common ownership of code and spreads knowledge across the team.
It serves as an informal review process as each line of code is looked at by more than 1 person.
It encourages refactoring as the whole team can benefit from this.
Measurements suggest that development productivity with pair programming is similar to that of two people working independently.
What is Extreme Programming?
An agile development methodology Created by Kent Beck in the mid 1990’s A set of 12 key practices taken to their
“extremes” A mindset for developers and customers A religion?
The 12 Practices
The Planning Game Small Releases Metaphor Simple Design Testing Refactoring Pair Programming Collective Ownership Continuous Integration 40-Hour Workweek On-site Customer Coding Standards
1 - The Planning Game
Planning for the upcoming iteration Uses stories provided by the customer Technical persons determine schedules,
estimates, costs, etc A result of collaboration between the
customer and the developers
The Planning Game – Advantages
Reduction in time wasted on useless features Greater customer appreciation of the cost of a
feature Less guesswork in planning
The Planning Game – Disadvantages
Customer availability Is planning this often necessary?
2- Small Releases
Small in terms of functionality Less functionality means releases happen
more frequently Support the planning game
Small Releases – Advantages
Frequent feedback Tracking Reduce chance of overall project slippage
Small Releases – Disadvantages
Not easy for all projects Not needed for all projects Versioning issues
3 – Metaphor
The oral architecture of the system A common set of terminology
Metaphor – Advantages
Encourages a common set of terms for the system
A quick and easy way to explain the system
Metaphor – Disadvantages
Often the metaphor is the system Another opportunity for miscommunication The system is often not well understood as a
metaphor
4 – Simple Design
K.I.S.S. Do as little as needed, nothing more
Simple Design – Advantages
Time is not wasted adding not required functionality
Easier to understand what is going on Refactoring and collective ownership is made
possible Helps keeps programmers on track
Simple Design – Disadvantages
What is “simple?” Simple isn’t always best
6 – Testing
Unit testing Test-first design All automated
Testing – Advantages
Unit testing promote testing completeness Test-first gives developers a goal Automation gives a suite of regression test
Testing – Disadvantages
Automated unit testing isn’t for everything confidence on unit testing isn’t a good idea A test result is only as good as the test itself
6 – Refactoring
Changing how the system does something but not what is done
Improves the quality of the system in some way
Refactoring – Advantages
Prompts developers to proactively improve the product as a whole
Increases developer knowledge of the system
Refactoring
Refactoring is the process of code improvement where code is reorganised and rewritten to make it more efficient, easier to understand, etc.
Refactoring is required because frequent releases mean that code is developed incrementally and therefore tends to become messy.
Refactoring should not change the functionality of the system.
Automated testing simplifies refactoring as you can see if the changed code still runs the tests successfully.
Refactoring – Disadvantages
Not everyone is capable of refactoring Refactoring may not always be appropriate Would upfront design eliminate refactoring?
7 – Pair Programming
Two Developers, One monitor, One Keyboard One “drives” and the other thinks Switch roles as needed
Pair Programming – Advantages
Two heads are better than one Focus Two people are more likely to answer the
following questions: Is this whole approach going to work? What are some test cases that may not work yet? Is there a way to simplify this?
Pair Programming – Disadvantages
Many tasks really don’t require two programmers
A hard sell to the customers Not for everyone
8 – Collective Ownership
The idea that all developers own all of the code
Enables refactoring
Collective Ownership – Advantages
Helps mitigate the loss of a team member leaving
Promotes developers to take responsibility for the system as a whole rather then parts of the system
Collective Ownership - Disadvantages
Loss of accountability Limitation to how much of a large system that
an individual can practically “own”
9 – Continuous Integration
New features and changes are worked into the system immediately
Code is not worked on without being integrated for more than a day
Continuous Integration - Advantages
Reduces to lengthy process Enables the Small Releases practice
Continuous Integration – Disadvantages
The one day limit is not always practical Reduces the importance of a well-thought-out
architecture
10 – 40-Hour Week
The work week should be limited to 40 hours Regular overtime is a symptom of a problem
and not a long term solution
40-Hour Week – Advantage
Most developers lose effectiveness past 40-Hours
Value is placed on the developers well-being Management is forced to find real solutions
40-Hour Week - Disadvantages
40-Hours is a magic number Some may like to work more than 40-Hours
11 – On-Site Customer
Just like the title says! Acts to “steer” the project Gives quick and continuous feedback to the
development team
On-Site Customer – Advantages
Can give quick and knowledgeable answers to real development questions
Makes sure that what is developed is what is needed
Functionality is prioritized correctly
On-Site Customer – Disadvantages
Difficult to get an On-Site Customer The On-Site customer that is given may not
be fully knowledgeable about what the company
May not have authority to make many decisions
Loss of work to the customer’s company
12 – Coding Standards
All code should look the same It should not possible to determine who coded
what based on the code itself
Coding Standards – Advantages
Reduces the amount of time developers spend reformatting other peoples’ code
Reduces the need for internal commenting Call for clear, unambiguous code
Coding Standards – Disadvantages
Degrading the quality of inline documentation
XP – Advantages
Built-In Quality Overall Simplicity Programmer Power Customer Power Synergy Between Practices
XP – Disadvantages
Informal, little, or no documentation Scalability Contract Issues Misconception on the cost of change
Problems with XP Customer involvement
This is perhaps the most difficult problem. It may be difficult or impossible to find a customer who can represent all stakeholders and who can be taken off their normal work to become part of the XP team. For generic products, there is no ‘customer’ - the marketing team may not be typical of real customers.
Architectural design The incremental style of development can mean that
inappropriate architectural decisions are made at an early stage of the process.
Problems with these may not become clear until many features have been implemented and refactoring the architecture is very expensive.
Thank You !!!