XP- e Xtreme Programming Amit Shabtay 1

XP- e. Xtreme Programming Amit Shabtay 1

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

Development Methodologies l The Software Crisis l e. Xtreme Programming l Rational Unified Process • 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) • For small projects: up to 12 people, 100 stories • For large projects: a “heavy-weight” process • A commercial product 3

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

The RUP platform includes l l 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. 5

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

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

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

Planning Game, Simple Design l XP planning addresses two key questions in software development: • Predicting what will be accomplished at due date. • Determining what to do next (picking stories). l l l 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. 9

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

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

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

Testing • Write a test case. • Write the code that passes it. • Repeat until program does what you want. l l l 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. 13

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

Small Releases l l 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 15

Collective Ownership, Coding Standard l l 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. 16

Metaphor l l l 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 caralways in a need for steering. 17

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

Refactoring l l 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 19

Necessity 20

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

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

For Conclusion l l e. Xtreme 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. 23