Extreme programming. Why XP?

Transcription

1 Extreme programming Timo Tuunanen YOMI 2004 Why XP? In the early 1990s a man named Kent Beck was thinking about better ways to develop software. He had recently spent some time working with Ward Cunningham. Ward and Kent together had experienced an approach to software development that made every thing seem simple and more efficient. Kent contemplated on what made software simple to create and what made it difficult. In March of 1996 Kent started a project at DaimlerChrysler using new concepts in software development. The result was the Extreme Programming (XP) methodology. What Kent came to realize is that there are four dimensions along which one can improve any software project. YOMI

2 Why XP? cont You need to improve communication. You need to seek simplicity. You need to get feedback on how well you are doing. You need to always proceed with courage. Communication Simplicity Feedback and Courage are the four values sought out by XP programmers YOMI Manifesto for Agile Software Development 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. YOMI

3 What is XP? Extreme Programming (XP) is actually a deliberate and disciplined approach to software development. XP is lot like a jig saw puzzle. There are many small pieces. Individually the pieces make no sense, but when combined together a complete picture can be seen. XP is a set of rules and a process that tells how to apply these rules. YOMI What XP is not? XP is not a light process model, it is agile XP is not something uncontrolled XP is not hacking XP is not simple process model for all developers XP is certainly not a silver bullet (I don t know if it s a bullet at all.. Maybe one in your foot. ) YOMI

4 Planning User stories are written. Release planning creates the schedule. Make frequent small releases. The Project Velocity is measured. The project is divided into iterations. Iteration planning starts each iteration. Move people around. A stand-up meeting starts each day. Fix XP when it breaks. YOMI Designing Simplicity. Choose a system metaphor. Use CRC cards for design sessions. Create spike solutions to reduce risk. No functionality is added early. Refactor whenever and wherever possible. YOMI

5 Coding The customer is always available. Code must be written to agreed standards. Code the unit test first. All production code is pair programmed. Only one pair integrates code at a time. Integrate often. Use collective code ownership. Leave optimizationtill last. No overtime. YOMI Testing All code must have unit tests. All code must pass all unit tests before it can be released. When a bug is found tests are created. Acceptance tests are run often and the score is published. YOMI

6 Lessons learned Release Planning The Team owns the schedule. Simplicity Simplicity is easier to maintain. You aren't going to need it. System Metaphor A metaphor can simplify the design. Pair Programming The whole is greater than the parts. Some rules of thumb. Rein in the Cowboy Coders. Pairing reduces indecision. Make no mistake, pairing is hard work. Experimental evidence for pairing. Code reviews considered hurtful YOMI Lessons learned. Cont. Integrate Often XP and Databases. Integration can be reduced to seconds. Optimize Last It may not be as slow as you think. Unit Tests Well worth the investment. Could have saved us some time. Testing first makes the code testable. Acceptance Tests They give a feeling of stability. Create a tool to maintain them. YOMI

7 Problems with XP. Why isn t XP used more? Customer is not usually available Project size mustbe right Project team size must be right (under 10 programmers) Highly skilled team is required to succesfully apply XP Collective code ownership might reduce motivation YOMI Applying XP rules XP rules are a collectionof best practices can be used as a part of any process/development model Rules that are especiallyinteresting Small releases Pair programming Spike solutions Unit testing practices Emphasis on communication YOMI

8 References YOMI Luentotehtävä Analysoi XP:n vahvuuksia ja heikkouksia. Miksi XP:tä kannattaa soveltaa ja miksi ei? Materiaalina tämä luentomoniste ja YOMI

9 Kommentteja? YOMI