eXtreme ProgrammingGoalsRolesArtifactsActivitiesXP PracticesSlide 7Pair programmingProcessTestsContinuous IntegrationDesignSimple designXP Planning GameSlide 15ExamplePlanning XP ProjectEstimatingRevise planCharacteristics of XP PlanningNext timeCS427 3-1eXtreme ProgrammingLightweight software development process for small groups (<12)Extreme Programming Explained by Kent Beckhttp://www.xProgramming.comCS427 3-2GoalsMinimize unnecessary workMaximize communication and feedbackMake sure that developers do most important workMake system flexible, ready to meet any change in requirementsCS427 3-3RolesCustomerTesterDeveloperCoachTrackerBossCS427 3-4ArtifactsMetaphorStories, sorted into “iterations”.TasksUnit testsFunctional testsCodeCS427 3-5ActivitiesWriting storiesThe planning gameStandup meetingWriting testsMaking tests workRefactoringIntegratingStandup meetingCS427 3-6XP PracticesOn-site customerThe Planning GameSmall releasesTestingSimple designRefactoringCS427 3-7XP PracticesMetaphorPair programmingCollective ownershipContinuous integration40-hour weekCoding standardsCS427 3-8Pair programmingCS427 3-9ProcessCustomer produces sequence of “stories”.Developers break stories into “tasks”.Developers implement tasks one at a time, working in pairs.Developers implement tasks bywriting tests for itdoing “simplest thing” to make tests workrefactoring until design is simple againCS427 3-10TestsUnit testsTest each unit of software.Write code only if there is a unit test for it.All unit tests must always run.Written by developersFunctional testsTest entire packageWritten by customerCS427 3-11Continuous IntegrationIntegrate your work after each task.Start with official “release”Once task is completed, integrate changes with current official release.All unit tests must run after integration.CS427 3-12DesignDesign occurs when developersDevelop metaphorBreak story into tasksDecide how to implement a taskRefactorCS427 3-13Simple designDo the simplest thing that could workFor each design problem:What are some solutions?Will it work? (yes, no, maybe)Pick the simplest one that might workCS427 3-14XP Planning GameCS427 3-15XP Planning GameCustomer writes storiesDevelopers estimateeffort (in man-weeks)risk (high, medium, low)Budget for each iterationCustomer picks enough stories to fill iterations.CS427 3-16Example20 one-week stories, 25 two-week stories, 10 three-week stories6 developers, able to implement four weeks of stories each iteration100 weeks / 4 (weeks/iteration) = 25 iterationsCS427 3-17Planning XP ProjectWrite stories until they are “complete”EstimatePlanExecute and measureRevise planExecute and measureRevise plan...CS427 3-18EstimatingIf you can’t estimate a story, work on it until you can.Group design sessionPrototyping (Spike)If story is too long, break it into smaller storiesCS427 3-19Revise planMeasure actual number of story-weeks implemented. This is project velocity.Make sure next iteration is no more than project velocity of previous iteration.Customer canadd storiesrevise, remove, reschedule storiesOnly developers can estimate storiesCS427 3-20Characteristics of XP PlanningRequires a few iterations to make good estimatesNext iterations are easier to predict than iterations that are far awayEasy to change schedule by changing storiesCS427 3-21Next timeRead chapters 4,5 and 7 of Hamlet and Maybee, plus sections 2.3, 2.4, and
View Full Document