XP- eXtreme Programming

1. XP- eXtreme Programming Amit Shabtay

2. Software Development Process • SDP is essentially composed of: • Requirements->  Design-> Implementation->      Testing-> Documentation-> Maintenance • However, this is not descriptive enough. • Different organizations have different requirements for their processes, so there is not one "correct" process

3. Development Methodologies • The Software Crisis • 84% of software projects are not on time • 31% of software projects never complete • Most software is buggy, unstable and insecure • Lack of repeatability (engineering) • eXtreme Programming • For small projects: up to 12 people, 100 stories • Rational Unified Process • For large projects: a “heavy-weight” process • A commercial product

4. Rational Unified Process • By Rational, see http://www-306.ibm.com/software/awdtools/rup/ • Decompose large system to sub-systems • A team and development effort per system • Architects team does overall design, sharing • Five stages of each system’s life cycle • Business modeling, Requirements, Analysis & Design, Implementation, Test • Many artifacts are not code or tests • Iterative Development • Highly managed, highly automated process

5. The RUP platform includes • Tools for configuring RUP for a project’s specific needs. • Tools for developing your own internal knowledge into process components • Customizable Web-based deployment tools • Online community for exchanging best practices.

6. eXtreme Programming • By Kent Beck, see XProgramming.com • Embrace change • Simplicity • Customer involvement & rapid feedback • Incremental pay-as-you-go design • Test-first programming

7. The 12 XP Principles (I) • Planning Game • Simple Design • On-Site Customer • Pair Programming • Testing • Continuous Integration

8. The 12 XP Principles (II) • Small Releases • Collective Ownership • Coding Standard • Metaphor • 40-Hour Week • Refactoring

9. Planning Game, Simple Design • XP planning addresses two key questions in software development: • Predicting what will be accomplished at due date. • Determining what to do next (picking stories). • This is done every two weeks or so. • It provide steering control in the hands of the customer. • Design is kept simple design, knowing that in the next iterations it may change.

10. On-Site Customer • In a team, there exists a “customer”. • He is the business representative. • He provides the requirements, sets priorities and steers the project.

11. Pair Programming I • Two Programmers sit at one workstation • They take turns “driving” • Pairs are short lived • Pairing transmits knowledge to the team • Pairing train newbies

12. Pair Programming II • Laurie Williams, • http://collaboration.csc.ncsu.edu/laurie/ • Findings: • Pairs use no more manhours than singles. • Pairs create fewer defects. • Pairs create fewer lines of code. • Pairs enjoy their work more.

13. Testing • Write a test case. • Write the code that passes it. • Repeat until program does what you want. • It shows that the tested framework is functioning properly. • It also gives a working base to continue from. • We move, in tiny steps, from working base, to working base.

14. Continuous Integration • Build, end to end, at every check in. • Check in frequently. • Put resources on speeding build time. • Put resources on speeding test time.

15. Small Releases • First, the team releases running, tested software, delivering business value chosen by the Customer, every iteration • The customer can use it for evaluation or even release to end users • Second, XP teams release to their end users frequently as well. XP Web projects release as often as daily

16. Collective Ownership, Coding Standard • All the contributors to an XP project sit together, members of one team, including the customer. • There is no exclusive role of just one individual (except the customer) • On an Extreme Programming project, any pair of programmers can improve any code at any time. • Because of that, it is important to keep identical code standards.

17. Metaphor • To keep a common vision of how the program works, the team can define a “metaphor” for the project. • “This program works like a hive of bees, going out for pollen and bringing it back to the hive" as a description for an agent-based information retrieval system. • The metaphor Extreme Programming (XP) uses to describe software development is of driving a car- always in a need for steering.

18. 40-Hour Week • Extreme Programming teams are in it for the long term. • To get a quality work, you need to treat the team as human beings.

19. Refactoring • Improving the design of existing code, without changing its observable behavior • "Programs have two kinds of value: what they can do for you today and what they can do for you tomorrow." Kent Beck

20. Necessity

21. When? • When to refactor • Before adding functionality • Before fixing a bug • During code review • When not to refactor • During adding functionality • During fixing a bug • No good set of unit tests • Small programs (usually)

22. Code Smells • “If it stinks, change it” • Duplicate code • Switch statements • Long method • Data class • Long parameter list • Primitive obsession • Temporary field • …

23. For Conclusion • eXtreme programming is all about: • Fanatic testing • Preparing for unknown changes • Keeping it simple. • It is not always the best development process to choose- it must meet some requirements.