Download - e X treme P rogramming

Transcript
Page 1: e X treme  P rogramming

eeXXtreme treme

PProgrammingrogramming Angelo Corsaro

(modified by G. Blank, with notes from Extreme Programming FAQ and Mike Rogers, BrainLoaf.com)

[email protected]://tao.doc.wustl.edu/~corsaro

Page 2: e X treme  P rogramming

2

Table of ContentsTable of ContentsSoftware Development Life Cycle (SWDLC).SWDLC Models.Cost Of Change.XP Introduction.XP’s Values.XP’s Principles.XP’s Practices.Putting it all Together.An XP Project Road-Map.References.

Page 3: e X treme  P rogramming

3

A Brief Overview…A Brief Overview…A Software Development Life Cycle (SWDLC) is an abstract representation of how software is developed.A SWDLC process can consist of

Sequential Phases/StepsParallel Phases/Steps

The Phases of a SWDLC process are typically1. Requirement Analysis2. Design Specification3. Coding and Unit Testing4. Test and Integration5. Acceptance Test6. System and Software Maintenance

Softw

are

Deve

lopm

ent L

ife C

ycle

Softw

are

Deve

lopm

ent L

ife C

ycle

Page 4: e X treme  P rogramming

4

Generic Waterfall ModelGeneric Waterfall ModelAssume a development process in which the step 1-6 outlined before are executed one after the other in sequential order.

SWDL

C M

odel

sSW

DLC

Mod

els

RequirementsRequirements

DesignDesign

CodingCodingUnit TestingUnit Testing

Test Test IntegrationIntegration

Acceptance TestAcceptance Test

MaintenanceMaintenance

Page 5: e X treme  P rogramming

5

Generic Waterfall ModelGeneric Waterfall Model

This model in not practical, it fails in capturing the inherent iterative nature of SW development.SW development has concurrent and iterative aspects that this model fail to capture.Does not encourage prototyping and software reuse.The DOD SWDLC uses a variation of the Waterfall-Model.NASA uses a SWDLC development model that is a minor variation of the DOD SWDLC.

SWDL

C M

odel

sSW

DLC

Mod

els

Page 6: e X treme  P rogramming

6

Risk: The Basic ProblemRisk: The Basic ProblemThe basic problem of SW development is risk.Sample of risks are

Schedule slipsProject CancelledSystem Goes SourDefect RateBusiness MisunderstoodFalse Feature-RichStaff Turnover

Commonly used SWDLC fall short in coping with the previously cited risks.

SWDL

C M

odel

s SW

DLC

Mod

els

Page 7: e X treme  P rogramming

7

Spiral Model 1/2Spiral Model 1/2Is a Risk-Driven approach to SW development.It encompass both the best features of both classic life cycles and prototyping.

PlanningPlanning Risk AnalysisRisk AnalysisPrototypingPrototyping

Client EvaluationClient EvaluationAnd InputAnd Input

DevelopmentDevelopmentPrototypingPrototyping

SWDL

C M

odel

sSW

DLC

Mod

els

Req AnalysisReq Analysis

Design Spec.Design Spec.

Test and Integration.Test and Integration.

Codi

ng

Codi

ng

Unit

Test

ing

Unit

Test

ing

Accptance TestAccptance Test

Page 8: e X treme  P rogramming

8

Spiral Model 2/2Spiral Model 2/2

The Spiral Model can be used effectively for both

System EnhancementSystem Development

Most SWDLC can be considered as a special case of the Spiral Model.The embedded Risk-Analysis built into the model avoids many of the difficulties that arise in other models.

SWDL

C M

odel

sSW

DLC

Mod

els

Page 9: e X treme  P rogramming

9

Cost of ChangeCost of ChangeOne Universal Assumption of SW Engineering is that the cost of changing a program rises exponentially over timeOne of the key assumption of XP is that the cost of changing a program, can be kept mostly constant over time. This assumption is based on real-world experience, and on the use of both better

Programming Practice Programming Environments

This assumption about the cost of change gives the opportunity of taking a totally different approach to SW development.

Page 10: e X treme  P rogramming

10

Extreme Programming Extreme Programming (XP)(XP)

XP does not involve bungee cords! And it predates Windows XP.Developed by Kent Beck (also developed CRC cards)“A light-weight methodology for small to medium-sized teams developing software in the face of vague or rapidly changing requirements” -- Kent Beck"Extreme Programming turns the conventional software process sideways. Rather than planning, analyzing, and designing for the far-flung future, XP programmers do all of these activities a little at a time throughout development.”IEEE Computer October 1999

XP In

trodu

ctio

nXP

Intro

duct

ion

Page 11: e X treme  P rogramming

11

Main XP ConceptsMain XP ConceptsXP is a lightweight development process

Instead of lots of documentation nailing down what the customer wants up front, emphasize continuous communication and feedback between developers and programmersEmbrace change: iterate often, design and redesign, code and test frequently, keep the customer involved.Deliver software to the customer in short (2 week) iterationsSeeks to eliminate defects early, thus reducing costs

XP is made of a collection ofValuesRules/PrinciplesPractices

In XP values, principles and practices are often set to the extreme level, from here the name eXtreme Programming

XP In

trodu

ctio

nXP

Intro

duct

ion

Page 12: e X treme  P rogramming

12

The Four Core Values of The Four Core Values of XPXP

Communication.Simplicity.Feedback.Courage.XP

Val

ues

XP V

alue

s

Page 13: e X treme  P rogramming

13

CommunicationCommunication

Often problem that arise in SW project can be tracked back to lack of communication.XP enforces the Communication Value by employing many practice that could not be carried without communicating (e.g. pair programming, unit testing etc.).XP employs a Coach whose job is that of noticing when people are not communicating and reintroduce them.

XP V

alue

sXP

Val

ues

Page 14: e X treme  P rogramming

14

SimplicitySimplicity

''Do the simplest thing that could possibly work'' (DTSTTCPW) principle (elsewhere known as KISS).An XP coach may say DTSTTCPW when he sees an XP developer doing something that is needlessly complicated. YAGNI principle (''You ain’t gonna need it'')Simplicity and Communication support each other mutually.

XP V

alue

sXP

Val

ues

Page 15: e X treme  P rogramming

15

FeedbackFeedback

Feedback works in XP at different time scales.Programmers have feedback on a minutes time scale on the status of the system thanks to unit tests.When customers write new stories the programmers estimate those immediately to give prompt feedback to the customer about the quality of the stories.The customer review the scheduler every 2-3 weeks and provide prompt feedback to the developer.

XP V

alue

sXP

Val

ues

Page 16: e X treme  P rogramming

16

CourageCourage

XP team should have the courage of throwing code away.XP team should have the courage of mainly refactor the architecture of the system, if architectural flaw are detected.Courage has in XP the same role that mutation has in genetic algorithms. Takes you out of local maximum/minimum.

XP V

alue

sXP

Val

ues

Page 17: e X treme  P rogramming

17

Core XP PrinciplesCore XP Principles

Rapid Feedback.Assume Simplicity.Incremental Change.Embracing the Change.Quality Work.XP

Prin

ciple

sXP

Prin

ciple

s

Page 18: e X treme  P rogramming

18

Twelve XP PracticesTwelve XP Practices

The Planning Game.Small Releases.Metaphor.Simple Design.Testing.Refactoring.

Pair Programming.Collective Ownership.Continuous Integration.40-Hours a Week.On-Site Customer.Coding Standards.

XP P

ract

ices

XP P

ract

ices

Page 19: e X treme  P rogramming

19

XP Practices (1)XP Practices (1)

The Planning Game.Customer and developers cooperate to produce the maximum business value as rapidly as possible. Customer comes up with a list of desired features for the system.Each feature is written out as a User Story, giving each feature a name and describes in broad strokes what is required. User stories are typically written in 2-3 sentences on 4x6 story cards.Developers estimate how much effort each story will take, and how much effort the team can produce in a given time interval (iteration). Project velocity = how many days can be committed to project per week.Customer decides which stories to implement in what order, and when and how often to produce a production releases of the system.

XP P

ract

ices

XP P

ract

ices

Page 20: e X treme  P rogramming

20

XP Practices (2-4)XP Practices (2-4)

Small releases.Start with the smallest useful feature set. Release early and often, adding a few features each time. Releases can be date driven or user story driven.

System metaphor.Each project has an organizing metaphor, which provides an easy to remember naming convention.

Simple design.Always use the simplest possible design that gets the job done. The requirements will change tomorrow, so only do what's needed to meet today's requirements (remember, YAGNI).

XP P

ract

ices

XP P

ract

ices

Page 21: e X treme  P rogramming

21

XP Practices (5)XP Practices (5)

Continuous TestingBefore programmers add a feature, they write a test for it. When the suite runs, the job is done. Tests in XP come in two basic flavors. Unit Tests automate testing of functionality as developers write it.

Each unit test typically tests only a single class, or a small cluster of classes. Unit tests typically use a unit testing framework, such as JUnit.

Acceptance Tests (or Functional Tests) are specified by the customer to test that the overall system is functioning as specified.

When all the acceptance tests pass for a given user story, that story is considered complete.

Could consist of a script of user interface actions and expected results that a human can run.

Ideally acceptance tests should be automated, either using the unit testing framework, or a separate acceptance testing framework.

XP P

ract

ices

XP P

ract

ices

Page 22: e X treme  P rogramming

22

XP Practices (6)XP Practices (6)Pair programming.

Two programmers work together at one machine.Driver enters code, while navigator critiques it.Periodically switch roles.

XP P

ract

ices

XP P

ract

ices

Research results:Pair programming increases productivity.Higher quality code in about half the time.Increased satisfaction/decreased frustration).Williams, L., Kessler, R., Cunningham, W., & Jeffries, R. Strengthening the case for pair programming. IEEE Software, 17(3), July/August 2000.Requires proximity in lab or work environment.

Page 23: e X treme  P rogramming

23

XP Practices (7-9)XP Practices (7-9)

Refactoring.Refactor out any duplicate code generated in a coding session.You can do this with confidence that you didn't break anything because you have the tests.

Collective code ownership.No single person "owns" a module. Any developer can work on any part of the code base at any time.

Continuous integration.All changes are integrated into the codebase at least daily. Tests have to run 100% both before and after integration.

XP P

ract

ices

XP P

ract

ices

Page 24: e X treme  P rogramming

24

XP Practices (10-12)XP Practices (10-12)

40-hour work week.Programmers go home on time. In crunch mode, up to one week of overtime is allowed. More than that and there’s something wrong with the process.

On-site customer.Development team has continuous access to a real live customer, that is, someone who will actually be using the system, or a proxy.

Coding standards.Everyone codes to the same standards. Ideally, you shouldn't be able to tell by looking at it who on the team has touched a specific piece of code.

XP P

ract

ices

XP P

ract

ices

Page 25: e X treme  P rogramming

25

Putting it all TogetherPutting it all Together

PlanningUser StoriesRelease PlanningRelease PlanMake Frequent Small ReleasesProject VelocityIterative DevelopmentIteration PlanningMove People AroundDaily Stand Up MeetingFix XP When it Breaks

DesigningSimplicity is the KeyChoose a System MetaphorCRC CardsSpike SolutionNever add Functionality EarlyRefactor Mercilessly

Page 26: e X treme  P rogramming

26

Daily Standup MeetingDaily Standup MeetingGoal: Identify items to be accomplished for the day and raise issues

• Everyone attends, including the customer• Not a discussion forum• Take discussions offline• Everyone gets to speak• 15 minutes

Page 27: e X treme  P rogramming

27

XP ProjectXP Project

Page 28: e X treme  P rogramming

28

XP Project IterationXP Project Iteration

Page 29: e X treme  P rogramming

29

XP Project DevelopmentXP Project Development

Page 30: e X treme  P rogramming

30

XP Project CodingXP Project Coding

Page 31: e X treme  P rogramming

31

XP vs. Rational Unified XP vs. Rational Unified ProcessProcess

XP RUPPrimary Communication Medium

Short Daily Face to Face meetings, Pair Programming

Client Status Meetings, Design Meetings

Development Methodology

Code, Refine, Test Design, Document, Code, Test

Focuses on Delivering software quickly

Following the process to develop good software

Quality Focus Eliminate Defects as early as possible in the process using whole team

Eliminate defects on a scheduled basis with a separate team

Page 32: e X treme  P rogramming

32

ReferencesReferences

Extreme Programming Explained, Kent Beck Addison Wesley 1999.http://www.extremeprogramming.orghttp://BrainLoaf.comhttp://Wiki.comhttp://www.xp2001.org