Extreme Programming(XP)

Slides:



Advertisements
Similar presentations
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 17 Slide 1 Rapid software development.
Advertisements

Rapid software development
1 Software Engineering Muhammad Fahad Khan Software Engineering Muhammad Fahad Khan University Of Engineering.
Alternate Software Development Methodologies
Agile Development.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 17 Slide 1 Chapter 17: Rapid software development November 3, 2008.
Extreme Programming Team Members Gowri Devi Yalamanchi Sandhya Ravi.
EXtreme Programming Quick Introduction Daniel Arraes Pereira Eduardo Lourenço Apolinário Ricardo de Oliveira Cavalcanti.
Extreme Programming Mark Steverson. What Is Extreme Programming? ● Extreme Programming (XP) is a lightweight, agile methodology developed by Kent Beck.
Computer Engineering 203 R Smith Agile Development 1/ Agile Methods What are Agile Methods? – Extreme Programming is the best known example – SCRUM.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 17 Slide 1 Rapid software development.
Xtreme Programming. Software Life Cycle The activities that take place between the time software program is first conceived and the time it is finally.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 17 Slide 1 Rapid software development.
Chapter 3 – Agile Software Development Lecture 1 1Chapter 3 Agile software development.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 17 Slide 1 Extreme Programming.
Chapter 3 – Agile Software Development Lecture 2 1Chapter 3 Agile software development.
Chapter 3 – Agile Software Development 1Chapter 3 Agile software development.
Chapter 3 – Agile Software Development Lecture 1 1Chapter 3 Agile software development That's been one of my mantras - focus and simplicity. Simple can.
Chapter 3 – Agile Software Development Lecture 1 1Chapter 3 Agile software development.
Dr. Tom WayCSC Software Processes CSC 4700 Software Engineering.
Chapter 3 Agile Software Development (2/2) Yonsei University 2 nd Semester, 2013 Sanghyun Park.
Software Engineering Lecture 5 – Agile Software Development
Agile Software Development Chapter 3 – Lecture 1 Adrián Susinos.
Agile and XP Development Dan Fleck 2008 Dan Fleck 2008.
Extreme Programming Daniel Baranowski 3/29/06. What is Extreme Programming? An agile development methodology Created by Kent Beck in the mid 1990’s A.
Coming up: What is Agile? XP Development Dan Fleck 2010 Dan Fleck 2010.
Extreme/Agile Programming Prabhaker Mateti. ACK These slides are collected from many authors along with a few of mine. Many thanks to all these authors.
Chapter 3 – Agile Software Development Lecture 2 1Chapter 3 Agile software development.
Rapid software development 1. Topics covered Agile methods Extreme programming Rapid application development Software prototyping 2.
Extreme Programming (XP). Agile Software Development Paradigm Values individuals and interactions over processes and tools. Values working software over.
Chapter 3 Agile Software Development (1/2) Yonsei University 2 nd Semester, 2015 Sanghyun Park.
University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 other methodologies 1 Method/Process = step-by-step description of the steps involved.
XP Overview Short Life cycle Risky / Dynamic Requirements Increase developer productivity.
Chapter 2 Software processes. Topics covered Software process models Process activities Coping with change.
AP-1 4. Agile Processes. AP-2 Agile Processes Focus on creating a working system Different attitude on measuring progress XP Scrum.
Traditional Process Models A quick overview. 2 Waterfall Model (Diagram) Communication Project initiation Requirements gathering Planning Estimating Scheduling.
Lecture 4 – XP and Agile 17/9/15. Plan-driven and agile development Plan-driven development A plan-driven approach to software engineering is based around.
Requirements Engineering Requirements Engineering in Agile Methods Lecture-28.
Extreme programming (XP) Variant of agile Takes commonsense practices to extreme levels © 2012 by Václav Rajlich1.
Agile Methods Presentation By: Jason Abbett. Definition A process to rapidly develop software Many kinds of agile methods but few are practiced.
Extreme Programming. Extreme Programming (XP) Formulated in 1999 by Kent Beck, Ward Cunningham and Ron Jeffries Agile software development methodology.
Agenda: Overview of Agile testing Difference between Agile and traditional Methodology Agile Development Methodologies Extreme Programming Test Driven.
CS223: Software Engineering Lecture 18: The XP. Recap Introduction to Agile Methodology Customer centric approach Issues of Agile methodology Where to.
Introduction to Software Engineering Muhammad Nasir Agile Software Development(2)
1 Introduction to eXtreme Programming Remko Popma Azzurri Ltd.
Extreme Software Engineering A Hands-On Approach From Extreme Software Engineering: A Hands-On Approach Daniel H. Steinberg Daniel W. Palmer.
Agile Software Development 1. Topics covered Agile methods Plan-driven and agile development Extreme programming 2.
Extreme programming (XP) Advanced Software Engineering Dr Nuha El-Khalili.
Coming up: What is Agile? XP Development Dan Fleck 2010 Dan Fleck 2010.
Chapter 3 – Agile Software Development 1Chapter 3 Agile software development.
Scuola Politecnica Dipartimento DITEN Università degli Studi di Genova An Introduction to Scrum and XP Prof. Riccardo Berta.
Project Management Software development models & methodologies
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 17 Slide 1 Rapid software development.
Chapter 3 – Agile Software Development Part 1a 1.
Chapter 3 Agile software development 1 Chapter 3 – Agile Software Development.
CS223: Software Engineering
CompSci 280 S Introduction to Software Development
Rapid Software Development
Extreme Programming.
CHAPTER 8: RAPID SOFTWARE DEVELOPMENT
EXtreme Programming BY R.V.Ramesh MCA II Semester.
Extreme Programming.
What do you need to know about XP?
Chapter 3 – Agile Software Development
Agile Development – a new way of software development?
Extreme Programming.
Extreme Programming (and Pair Programming)
Presentation 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

Extreme programming practices 1

Extreme programming practices 2

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

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

Test case description

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 Architectural design 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 !!!