Extreme Programming Daniel Baranowski 32906 What is Extreme

Extreme Programming Daniel Baranowski 3/29/06

What is Extreme Programming? An agile development methodology n Created by Kent Beck in the mid 1990’s n A set of 12 key practices taken to their “extremes” n A mindset for developers and customers n A religion? n

What is agile? n Any methodology that subscribes to the Agile Manifesto: We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.

What else is agile? Adaptive Software Development n Crystal Methodologies n Dynamic Systems Development Method n Feature-Driven Development n SCRUM n And others n

The 12 Practices n n n 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 n Uses stories provided by the customer n Technical persons determine schedules, estimates, costs, etc n A result of collaboration between the customer and the developers n

The Planning Game – Advantages Reduction in time wasted on useless features n Greater customer appreciation of the cost of a feature n Less guesswork in planning n

The Planning Game – Disadvantages Customer availability n Is planning this often necessary? n

2 - Small Releases Small in terms of functionality n Less functionality means releases happen more frequently n Support the planning game n

Small Releases – Advantages Frequent feedback n Tracking n Reduce chance of overall project slippage n

Small Releases – Disadvantages Not easy for all projects n Not needed for all projects n Versioning issues n

3 – Metaphor The oral architecture of the system n A common set of terminology n

Metaphor – Advantages Encourages a common set of terms for the system n Reduction of buzz words and jargon n A quick and easy way to explain the system n

Metaphor – Disadvantages Often the metaphor is the system n Another opportunity for miscommunication n The system is often not well understood as a metaphor n

4 – Simple Design K. I. S. S. n Do as little as needed, nothing more n

Simple Design – Advantages Time is not wasted adding superfluous functionality n Easier to understand what is going on n Refactoring and collective ownership is made possible n Helps keeps programmers on track n

Simple Design – Disadvantages What is “simple? ” n Simple isn’t always best n

6 – Testing Unit testing n Test-first design n All automated n

Testing – Advantages Unit testing promote testing completeness n Test-first gives developers a goal n Automation gives a suite of regression test n

Testing – Disadvantages Automated unit testing isn’t for everything n Reliance on unit testing isn’t a good idea n A test result is only as good as the test itself n

6 – Refactoring Changing how the system does something but not what is done n Improves the quality of the system in some way n

Refactoring – Advantages Prompts developers to proactively improve the product as a whole n Increases developer knowledge of the system n

Refactoring – Disadvantages Not everyone is capable of refactoring n Refactoring may not always be appropriate n Would upfront design eliminate refactoring? n

7 – Pair Programming Two Developers, One monitor, One Keyboard n One “drives” and the other thinks n Switch roles as needed n

Pair Programming – Advantages Two heads are better than one n Focus n Two people are more likely to answer the following questions: n ¨ 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 http: //www. cenqua. com/pairon/ n Many tasks really don’t require two programmers n A hard sell to the customers n Not for everyone n

8 – Collective Ownership The idea that all developers own all of the code n Enables refactoring n

Collective Ownership – Advantages Helps mitigate the loss of a team member leaving n Promotes developers to take responsibility for the system as a whole rather then parts of the system n

Collective Ownership - Disadvantages Loss of accountability n Limitation to how much of a large system that an individual can practically “own” n

9 – Continuous Integration New features and changes are worked into the system immediately n Code is not worked on without being integrated for more than a day n

Continuous Integration Advantages Reduces to lengthy process n Enables the Small Releases practice n

Continuous Integration – Disadvantages The one day limit is not always practical n Reduces the importance of a well-thoughtout architecture n

10 – 40 -Hour Week The work week should be limited to 40 hours n Regular overtime is a symptom of a problem and not a long term solution n

40 -Hour Week – Advantage Most developers lose effectiveness past 40 -Hours n Value is placed on the developers wellbeing n Management is forced to find real solutions n

40 -Hour Week - Disadvantages The underlying principle is flawed n 40 -Hours is a magic number n Some may like to work more than 40 Hours n

11 – On-Site Customer Just like the title says! n Acts to “steer” the project n Gives quick and continuous feedback to the development team n

On-Site Customer – Advantages Can give quick and knowledgeable answers to real development questions n Makes sure that what is developed is what is needed n Functionality is prioritized correctly n

On-Site Customer – Disadvantages Difficult to get an On-Site Customer n The On-Site customer that is given may not be fully knowledgeable about what the company n May not have authority to make many decisions n Loss of work to the customer’s company n

12 – Coding Standards All code should look the same n It should not possible to determine who coded what based on the code itself n

Coding Standards – Advantages Reduces the amount of time developers spend reformatting other peoples’ code n Reduces the need for internal commenting n Call for clear, unambiguous code n

Coding Standards – Disadvantages n Degrading the quality of inline documentation

Manager and Customer Bill of Rights n n n You have the right to an overall plan, to know what can be accomplished, when, and at what cost. You have the right to get the most value out of every programming week. You have the right to see progress in a running system, proven to work by passing repeatable tests that you specify. You have the right to change your mind, to substitute functionality, and to change priorities without paying exorbitant costs. You have the right to be informed of schedule changes, in time to choose how to reduce scope to restore the original date. You cancel at any time and be left with a useful working system, reflecting investment to date.

Programmer Bill Of Rights n n n You have the right to know what is needed, with clear declarations of priority. You have the right to produce quality work at all times. You have the right to ask for and receive help from peers, superiors, and customers. You have the right to make and update your own estimates. You have the right to accept your responsibilities instead of having them assigned to you.

XP – Advantages Built-In Quality n Overall Simplicity n Programmer Power n Customer Power n Synergy Between Practices n

XP – Disadvantages Informal, little, or no documentation n Scalability n Contract Issues n Misconception on the cost of change n Tailoring n

Application – Advantageous Highly uncertain environments n Internal projects n Joint ventures n

Application – Disadvantageous Large, complex environments n Safety critical situations n Well understood requirements n Distant or unavailable customer n

Final Thoughts Why XP succeeds n Why XP is popular n Why XP fails n Why XP is not the “silver bullet” n

Questions?