1. CSC 480 Software Engineering Extreme Programming

2. What is XP Extreme Programming (XP) is actually a deliberate and disciplined approach to software development. XP stresses customer satisfaction  respond to changing customer requirements XP emphasizes team work XP improves a project in four essential ways: communication, simplicity, feedback, and courage

3. The XP Way of Thinking Extreme Programming (XP) is based on the idea that software which is engineered to be simple and elegant is more valuable than software that is complex and hard to maintain.  Cost: typical projects spend about twenty times as much on people than on hardware  Bugs: emphasizes not testing, but testing well  Changing requirements: embrace changes

4. When to Use XP XP was created in response to problem domains whose requirements change. XP was set up to address project risk. XP was set up for small groups of programmers, and managers and customers. Testability: must be able to create automated unit and functional tests. The last thing on the list is productivity.

6. Rules & Practices – Planning User stories are written. User stories Release planning creates the schedule. Release planning Make frequent small releases.small releases The Project Velocity is measured.Project Velocity The project is divided into iterations.iterations Iteration planning starts each iteration. Iteration planning Move people around. Move people around A stand-up meeting starts each day.stand-up meeting Fix XP when it breaks. Fix XP

7. User Story User Stories are written by the customers as things that the system needs to do for them.by the customers  create time estimates (by developers) for the release planning meeting.  drive the creation of the acceptance tests.acceptance tests. Differences between user stories & traditional requirements specifications  in the level of detail. (the biggest one)  focus on user needs.

9. Release & Iteration Planning The release plan specifies exactly which user stories are going to be implemented for each system release and dates for those releases.user stories Tasks for an iteration ( of 1 to 3 weeks in length)  Selected user stories: important/of high priority  Failed unit tests  Refactoring

10. Project Velocity vs. Load Factor The load factor (2 to 5) equals actual calendar days to complete a task divided by the developer's estimated ideal days to do it. The project velocity is a measure of how fast work is getting done on your project.  # of user stories completed in an iteration  Use load factor to create an initial estimate  Sign up the same # of tasks equal to the project velocity measured in the previous iteration.

11. Moving People Around Move people around to avoid serious knowledge loss and coding bottle necks.  Cross training is often an important consideration.  A team is much more flexible if everyone knows enough about every part of the system to work on it.  Pair programming makes it possible without losing productivity and ensures continuity of thought. Pair programming

12. Rules & Practices – Designing Simplicity. Simplicity Choose a system metaphor.system metaphor Use CRC cards for design sessions.CRC cards Create spike solutions (or throw-away prototypes) to reduce risk.spike solution No functionality is added early.added early Refactor whenever and wherever possible. Refactor

13. Design Logic Do the simplest thing that could possibly work. Never try to implement anything that it is not scheduled for this iteration. Choose a system metaphor to keep the team on the same page  naming classes/methods consistently. Design is accomplished in three ways  CRC cards CRC cards  Refactoring Refactoring  Pair programming. Pair programming

14. Using CRC Card The biggest value of CRC cards is to allow people to break away from the procedural mode of thought and more fully appreciate object technology. A CRC session proceeds with someone simulating the system by talking about which objects send messages to other objects.

15. Refactor Mercilessly Refactor mercilessly to keep design simple  remove redundancy  eliminate unused functionality  rejuvenate obsolete designs Let go of that perfect design you have envisioned and accept the design that was serendipitously discovered for you by refactoring.  It was a good guide post, but is now obsolete.

17. Rules & Practices – Coding The customer is always available.always available Code must be written to agreed standards.standards Code the unit test first.unit test first All production code is pair programmed.pair programmed Only one pair integrates code at a time.integrates code at a time Integrate often. Integrate often Use collective code ownership.collective code ownership Leave optimization till last.optimization No overtime.overtime

18. Unit Tests First Creating a unit test helps a developer to really consider what needs to be done. Benefit for system design: your design will be influenced by a desire to test everything of value to your customer. The code you will create is simple and concise, implementing only the features you wanted.

19. Pair Programming Two people working together at a sigle computer.  The ideal way One person types and thinks tactically about the method being created The other thinks strategically about how that method fits into the class.  Cross training With increased quality comes big savings later in the project.

20. Frequent Sequential Integration Only one development pair integrates, tests and releases changes to the source code repository at any given moment. Integrate your own changes with the latest version at your own workstation any time you want. Continuous integration often avoids diverging or fragmented development efforts.

22. Collective Code Ownership Encourages everyone to contribute new ideas to all segments of the project.  Any developer can change any line of code to add functionality, fix bugs, or refactor.fix bugsrefactor  The entire team are responsible for the system's architecture. Architecture is actually distributed among the team Collective code ownership is actually more reliable than putting a single person in charge of watching specific classes.

23. Rules & Practices – Testing All code must have unit tests.unit tests All code must pass all unit tests before it can be released.unit tests When a bug is found tests are created.a bug is found Acceptance tests are run often and the score is published. Acceptance tests

24. Unit Testing XP Style Unit tests XP style is a little different.  create automated unit tests suites.  test all classes in the system.  create your tests first, before the code.tests first  Unit tests are released into the code repository along with the code they test. Unit tests enable collective code ownership and refactoring. Don’t try to omit or delay writing unit tests.

25. When a Bug is Found When a bug is found tests are created to guard against it coming back. A bug in production requires an acceptance test be written to guard against it. Given a failed acceptance test  developers can create unit tests towards the defectunit tests  run the failing acceptance test when the unit tests run at 100%

26. Acceptance Tests Acceptance tests are created from user stories.user stories. Acceptance tests are black box system tests. A user story is not considered complete until it has passed its acceptance tests. Acceptance tests should be automated so they can be run often.

28. Useful Links http://www.extremeprogramming.org/ http://www.martinfowler.com/articles/newM ethodology.html#N401