XP - e X treme P rogramming

1. XP - eXtreme Programming A Brief Introduction ? Carl-Fredrik Sørensen, PhD Fellow mailto:carlfrs@idi.ntnu.no

2. Presentation Outline • XP/Agile SD: What and Why? • How to do XP? • Processes • Team practices • Programming • Rules and Practices

3. I: What Is Extreme Programming? • Deliberate and disciplined approach to software development. • Stresses customer satisfaction. • Deliver when needed. • Respond to changing requirements.

4. II: What Is Extreme Programming? • Emphasises team work. • Improves in Four essential dimensions: • Communication. • Simplicity. • Feedback. • Courage.

5. A Change in the Way We Program • Keep things simple and elegant. • Emphasises testing. • Automated tests. • Create tests before, when and after coding. • When bugs are found, new tests are added. • Embrace change. • Early feedback. • Acknowledges that requirements can/will change. • Constant integration.

6. Do We Need Yet Another Methodology? • XP - Based on observations of what improves/reduces the speed of programming. • Re-examination of software development practices. • Lightweight/Agile software methodology. • Reduce cost of software. • Simple and enjoyable.

7. What Is an Agile/lightweight Methodology? • Software Methodology: • Set of rules and practices. • Heavyweight. • many rules, practices and documents. • Lightweight. • few rules and practices or some that are easy to follow.

8. Agile Software Manifesto • XP, Scrum, DSDM, ASD, Crystal, Feature-driven Development, Pragmatic Programming: • 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 up a plan. • That is, while there is value in the items on the right, we value the items on the left more.

10. User Stories • Same purpose as use cases. • Used to create time estimates for release planning. • Replaces large requirements documents. • Written by customers. • Drives the creation of acceptance tests. • Developers create estimates in “ideal development time”. • A set of selected user stories form a release plan. • Focused on user needs.

11. User Story Examples Story: Handle overdraft When a transaction causes a customer’s account to go into overdraft, transfer money from the overdraft protection account, if any. For each account, compute the balance by adding up all the deposits, and subtracting all the deductions. Story: Compute balance

12. Architectural Spike • Spike solutions: • Figure answers to tough technical or design problems. • Reduce the risk of a technical problem. • Increase the reliability of estimate for a user story. • Simple program to explore potential solutions. • Address only one problem at a time.

13. Choose a System Metaphor • Establish a common vocabulary for the system. • Consistent naming of classes and methods. • Names should be easy to learn and relate to.

14. Naïve Assembly line Shared blackboard Subcontractors Workflow Editors: Card (Punched card imitation) Array of lines (vi) String (Emacs) Sequence of runs (Word) Tree (XML) Combinations Examples: System Metaphor

15. I: Release Planning Meeting • Establish a release plan. • The release plan is used to create iteration plans for each individual iteration. • Has a set of rules to balance technical and business decisions/forces to negotiate a schedule.

16. II: Release Planning Meeting • The release plan is based on developerestimates of a set of user stories and customerpriorities (time/scope). • Customer decides priorities of user stories. Most important first. • User stories are selected for an iteration based on either time or scope. Early deliverable with business value is desired.

17. Release Plan • Contains: • user stories to be implemented for each system release. • dates for those releases.

18. Release Planning Split a Story (Customer) Sort Stories by Value (Customer) “Too big” Write a Story (Customer) Estimate a Story (Programmer) Declare Velocity (Programmer) “Don’t know how” Choose Scope (Customer) Spike a Story (Programmer) Exploration Planning

19. I: Acceptance Test • Created from user stories. • Iteration: selected userstories are translated to acceptancetests. • Scenarios: specified by the customer to test for correct implementation of a user story. • A story may have one or many acceptance tests. • Is black-box system tests. • Customer verifies correctness and reviews test scores to decide priority of failed tests. • Used as regression tests prior to a production release.

20. II: Acceptance Test • User story is not complete before succeeding its acceptance tests. • New tests for each iteration, or the development will report zero progress. • Should be automated to be run often. • The XP team schedules time to fix any failed tests for each iteration.

21. Small Releases • Release iterative versions to the customers often. • Release planning meeting to discover small units of functionality that: • Make good businesssense. • Released into the customer's environment early in the project. • Critical to getting valuable feedback in time to have an impact on the system's development. • The longer you wait to introduce an important feature the less time you will have to fix it.

23. Iterative Development • Divideschedule into about a dozen iterations of 1 to 3 weeks in length. • Do not schedule programming tasks in advance. • Use iteration planning meetings before each iteration. • Do not implement anything ahead (not scheduled for this iteration). • Easier to handle changing requirements when: • never adding functionality early. • practice just-in-time planning.

24. Project Velocity • A measure of how fast work is getting done. • Number of user stories/programming tasks finished during an iteration. • Compare to estimates. • Used as input for estimating how many new stories to be done in next iteration.

25. Never Add Functionality Early • Code for today, leave tomorrow code until tomorrow. • Avoid guesses of what are needed in the future.

26. When a Bug Is Found • Create tests to stop it coming back. • Acceptance tests helps customers define and communicate the problem concisely. • Created before debugging helps developers to: • focus their efforts (create unit tests). • know when a problem is fixed.

27. Iteration Planning • Performed at the start of each iteration to: • Choose user stories (customer) and failed acceptance tests for the iteration. • Translate chosen user stories into programming tasks. • Sign up for tasks and estimate them (developers). • Use project velocity to determine if tasks can be accomplished in time. • Plan only programming tasks for the first (next) iteration.

28. Iteration Planning Game Phase 1: Brainstorming Phase 2: Accepting tasks Programmer 1 Select and Estimate Tasks Read Story Cards Programmer 2 “It’s too big” Or “I'm too busy” Programmer 3 Write Task Cards Unclaimed Tasks Programmer 4

30. Daily Stand Up Meeting • Every morning to communicate: • problems. • solutions. • promotes team focus. • Replaces project meetings.

32. I: Collective Code Ownership • Everyone contributes new ideas to all parts of a project. • Any developer can change any line of code to: • add functionality. • fix bugs. • refactor.

33. II: Collective Code Ownership • Avoids bottlenecks. • Unit tests guards (all code must include unit tests). • All code must pass the entire test suite 100%.

34. CRC Cards • Class, Responsibilities and Collaboration (CRC) Cards are used to design the system as a team. • Allows the whole team to participate. • Simulates the system by representing objects with responsibilities and collaborating objects.

35. CRC Cards • UML-tools can be used, but may be awkward when many people participate. • Round-trip engineering possible in many “CASE”-tools to UML’ify the CRC-design from source code.

36. Code the Unit Test First • Easier and faster to create code if the unit tests are created before the code. • Explicit about the scope of the implementation. • Helps to consider what is needed to be done. Requirements are representedbytests. • Gives immediately feedback, and we know when we are done (all unit tests run). • Grows confidence in the correct functioning of the system as it grows.

37. Code the Unit Test First • Benefit for system design by being easier to test. • Separates logical design from physical design from implementation. • Simplifies the design. • Always code as simple as possible to make the test(s) pass. • Only wanted features are coded.

38. I: Pair Programming • All production code are created by two people working together at a single computer. • Increases software quality without impact on delivery time. • Add as much functionality by coding individual by with muchhigher quality (saves time later in the project).

39. II: Pair Programming • One thinks tactically about the method to implement. • The other thinks strategically about how that method fits into the class. • More people learn more of the system. • Pairs are not constant, may switch many times a day.

40. Simplicity Is the Key • Simple design takes shorter time to complete than a complex one. • Always do the simplest thing that can possible work. • Replace complex code by simpler, it is cheaper to replace it now than use a lot of time on it later. • Never add functionality before it is scheduled. • Keeping design simple is a hard work!

41. Move People Around • Avoid serious knowledge loss and coding bottle necks. • Cross-training is achieved. • Everyone knows much of the code in each part of the system. • Makes team more flexible and increases productivity. • Encourage people to work on a new part in each iteration.

42. Refactor Mercilessly • Remove redundancy. • Everything should be expressed once and only once. • Eliminate unused functionality. • Replace complex and/or obsolete design with new simplerdesign. • Saves time and increases quality. • Keeps the code clean and concise.

43. I: Integrate Often • Integrate and release code into code repository as often as possible. • Never hold a change more a than day. • Avoids diverging and fragmented development efforts. • Makes code reuse and sharing more effective.

44. II: Integrate Often • Everyone is working with the latest version. • Compatibility issues are detected and/or avoided earlier. • Avoids integration problems late in the project.

45. Sequential Integration • Developers should integrate code to code repository sequential. Only one pair at a time. • Consistent repository. • Avoid obsolete versions. • Dedicated computer. • Integrate and release often.

46. I: Unit Tests • Create/download a unit test framework (i.e. JUnit). • Create automated test suites. • Test all classes in the system. • Create tests before code. • Unit tests part of the release. • Code without test should not be released.

47. II: Unit Tests • Missing unit tests should be created. • Enables collective code ownership. • Guards functionality to be accidentally harmed. • All code should pass all unit tests before released.

48. Fix XP When It Breaks • If there are practices that do not work, change them.

49. The Customer Is Always Available • One of few requirements. • Is part of the team. All phases requires communication with the customer. • User stories. • Release planning. • Acceptance tests. • Detailing user stories. • Try the system early.

50. XP Project Organisation • Customer • Programmers • (Project) Manager • Tracker • Coach