Extreme Programming: A Gentle Introduction.
Extreme Programming: A Gentle Introduction.Extreme Programming:A gentle introduction.The goal of this site is to provide anintroduction and overview of Extreme Programming(XP). For a guided tour of XP follow the trail of littlebuttons, starting here. Returning visitors canjump to recent changes to see what's new.Let's begin with a simple question:What is XP? As you will see, it is a deliberate anddisciplined approach to software development.Next we might wonder when to use XP.Risky projects with dynamic requirements areperfect for XP. These projects will experiencegreater success and developer productivity.But do we need yet another softwaremethodology? Actually we do. XP is a refreshingnew approach. XP is successful because itemphasizes customer involvement and promotesteam work.So how could this possibly work? The mostsurprising aspect of XP is its simple rules andpractices. They seem awkward and perhaps evennaive at first, but soon become a welcome change.Customers enjoy being partners in the softwareprocess and developers actively contribute regardlessof experience level.The rules and practices must support eachother. The XP Map shows how they work together toform a development methodology. Unproductiveactivities have been trimmed to reduce costs andfrustration.I want to try XP how do I start? Add a littleto your current methodology or try it all at once.There is much here of benefit to any project. Whathave other projects already learned about XP? Someimportant lessons learned.Where can I get more information? There areclasses, conferences, books, and web sites. The XPAgile Universe conference will be held in NewOrleans August 10-13, 2003.A Chinese Translation is available.What has changed here? XP Practices and Rules This site zipped Email the webmasterLast modified January 26, 2003. See recent changes.Copyright (c) 1999, 2000, 2001 Don Wells. All Rights reserved.http://www.extremeprogramming.org/ [10/17/2003 1:56:24 PM]
Extreme Programming Lessons LearnedWhat We Have LearnedAbout Extreme ProgrammingRelease PlanningThe Team owns the schedule.Optimize LastIt may not be as slow as you think.SimplicitySimplicity is easier to maintain.You aren't going to need it.Unit TestsWell worth the investment.Could have saved us some time.Testing first makes the code testable.System MetaphorA metaphor can simplify the design.Pair ProgrammingThe whole is greater than the parts.Some rules of thumb.Rein in the Cowboy Coders.Pairing reduces indecision.Make no mistake, pairing is hard work.Experimental evidence for pairing.Code reviews considered hurtful.Acceptance TestsThey give a feeling of stability.Create a tool to maintain them.If you have been using ExtremeProgramming (XP) or a component practice tell uswhat you have learned! If you have a story to tellabout something that saved you time please send itin. If you have a story about what doesn't work sendthat too. Please write a lesson learned about an XPpractice and send it to the webmaster.Integrate OftenXP and Databases.Integration can be reduced to seconds.ExtremeProgramming.org home XP Rules and Practices Email the webmasterCopyright 1999 Don Wells all rights html [10/17/2003 1:56:27 PM]
Lessons LearnedThe Team Owns the ScheduleThe right team can accomplish goalsbeyond one's wildest dreams! These teams arealso known as highly performing learningorganizations; they elicit effective projectmanagement practices through team ownership ofthe plan, and they demand software developmentprojects to be managed in two segments: a projectdeliverables schedule (release plan) and aniteration plan of programming (engineering)tasks.These two are not the same; most projectmanagers fail to let the engineering team work tothe beat of the engineering plan, instead theyassign work and force teams to use a project planfocused only on customer deliverables.In fact, we all know this erroneouspractice is contradictory to good object thinking,let alone reusable frameworks, testing,refactoring, Extreme Programming (XP), and soon. Thus, we achieved our successes when we usedextreme schedule negotiation [a.k.a releaseplanning].ExtremeProgramming.org home XP Lessons Learned Release Planning Email the webmasterCopyright 1998 Jeanine De Guzman. Logos Copyright 1999 Don Wells all rights /planninggame.html [10/17/2003 1:56:28 PM]
Commitment ScheduleRelease PlanAfter user stories have been written youcan use a release planning meeting to create arelease plan. The release plan specifies exactlywhich user stories are going to be implementedfor each system release and dates for thosereleases. This gives a set of user stories forcustomers to choose from during the iterationplanning meeting to be implemented during theThe release plan used to be called thenext iteration. These selected stories are thencommitment schedule. The name was changed totranslated into individual programming tasks tomore accurately describe its purpose and be morebe implemented during the iteration to completeconsistent with iteration plan.the stories.Stories are also translated into acceptancetests during the iteration. These acceptance testsare run during this iteration, and subsequentiterations to verify when the stories are finishedcorrectly and continue to work correctly.When the project velocity changesdramatically for a couple iterations or in any caseafter several iterations go ahead and schedule arelease planning meeting with your customersand create a new release plan.ExtremeProgramming.org home Release Planning Small Releases Email the webmasterCopyright 1999 Don Wells all rights ommit.html [10/17/2003 1:56:29 PM]
Extreme RulesRelease PlanningA release planning meeting is used tocreate a release plan, which lays out the overallproject. The release plan is then used to createiteration plans for each individual iteration.It is important for technical people tomake the technical decisions and business peopleto make the business decisions. Release planninghas a set of rules that allows everyone involvedwith the project to make their own decisions. Therules define a method to negotiate a scheduleeveryone can commit to.The essence of the release planningmeeting is for the development team to estimateeach user story in terms of ideal programmingweeks. An ideal week is how long you imagine itwould take to implement that story if you hadabsolutely nothing else to do. No dependencies, noextra work, but do include tests. The customerthen decides what story is the most important orhas the highest priority to be completed.User stories are printed or written oncards. Together developers and customers movethe cards around on a large table to create a setof stories to be implemented as the first (or next)release. A useable, testable system that makesgood business sense delivered early is desired.You may plan by time or by scope. Theproject velocity is used to determine either howmany stories can be implemented before a givendate (time) or how long a set of stories will take tofinish (scope). When planning by time multiplythe number of iterations by the project velocity todetermine how many user stories can becompleted. When planning by scope divide thetotal weeks of estimated user stories by theproject velocity to determine how many iterationstill the release is ready.Continued on page 2ExtremeProgramming.org home XP Rules Release Plan Email the webmasterCopyright 1999 Don Wells all rights lanninggame.html [10/17/2003 1:56:29 PM]
Extreme RulesIterative DevelopmentIterative Development adds agility to thedevelopment process. Divide your developmentschedule into about a dozen iterations of 1 to 3weeks in length. Keep the iteration lengthconstant through out the project. This is the heartbeat of your project. It is this constant that makesmeasuring progress and planning simple andreliable in XP.Don't schedule your programming tasksin advance. Instead have an iteration planningmeeting at the beginning of each iteration to planout what will be done. Just-in-time planning is aneasy way to stay on top of changing userrequirements.It is also against the rules to look aheadand try to implement anything that it is notscheduled for this iteration. There will be plentyof time to implement that functionality when itbecomes the most important story in the releaseplan.Take your iteration deadlines seriously!Track your progress during an iteration. If itlooks like you will not finish all of your tasks thencall another iteration planning meeting, reestimate, and remove some of the tasks.Concentrate your effort on completing the mostimportant tasks as chosen by your customer,instead of having several unfinished tasks chosenby the developers.It may seem silly if your iterations areonly one week long to make a new plan, but itpays off in the end. By planning out each iterationas if it was your last you will be setting yourselfup for an on-time delivery of your product. Keepyour projects heart beating loud and clear.ExtremeProgramming.org home XP Rules Iteration Planning Email the webmasterCopyright 1999 Don Wells all rights terative.html [10/17/2003 1:56:30 PM]
Extreme RulesLoad FactorThe load factor was how a project wastracked before project velocity became morepopular. The load factor equals actual calendardays to complete a task divided by the developer'sestimated "ideal" days to do it. That is, think of atask that would take you one day if you couldfocus completely on it. Now picture yourselftrying to get it done in the real world. Thenumber of days it actually takes is the load factor.Load factors from 2 to 5 are normal. Ifyou need to guess at a load factor to get startedyou should consider people's experience and thetechnology being used. A 2 is optimistic, a 3 istypical, while a 4 and 5 are for projects usingunfamiliar technology. Ron Jeffries recommendsjust simply using a 3 as an initial guess for newprojects.After making an initial guess you mustthen measure and track either the load factor, orbetter yet, the project velocity throughout theproject.The load factor can not be used tocompare two projects. Each project and team isunique and will have different load factors fordifferent reasons.Use a release planning meeting to reestimate and re-negotiate the release plan if theload factor changes dramatically. Expect the loadfactor to change again when the system is put intoproduction due to maintenance tasks.ExtremeProgramming.org home XP Rules Back to Project Velocity Email the webmasterCopyright 1999 Don Wells all rights oadfactor.html [10/17/2003 1:56:31 PM]
Extreme RulesProject VelocityThe project velocity (or just velocity) is ameasure of how much work is getting done onyour project. To measure the project velocity yousimply add up the estimates of the user storiesthat were finished during the iteration. It's justthat simple. You also total up the estimates for thetasks finished during the iteration. Both of thesemeasurements are used for iteration planning.During the iteration planning meetingcustomers are allowed to choose the same numberof user stories equal to the project velocitymeasured in the previous iteration. Those storiesare broken down into technical tasks and theteam is allowed to sign up for the same number oftasks equal to the previous iteration's projectvelocity.This simple mechanism allows developersto recover and clean up after a difficult iterationand averages out estimates. Your project velocitygoes up by allowing developers to ask thecustomers for another story when their work iscompleted early and no clean up tasks remain.A few ups and downs in project velocityare expected. You should use a release planningmeeting to re-estimate and re-negotiate therelease plan if your project velocity changesdramatically for more than one iteration. Expectthe project velocity to change again when thesystem is put into production due to maintenancetasks.Project velocity is about as detailed ameasure as you can make that will be accurate.Don't bother dividing the project velocity by thelength of the iteration or the number of people.This number isn't any good to compare twoproject's productivity. Each project team willhave a different bias to estimating stories andtasks, some estimate high, some estimate low. Itdoesn't matter in the long run. Tracking the totalamount of work done during each iteration is thekey to keeping the project moving at a steadypredictable pace.The problem with any project is the initialestimate. Collecting lots of details does not makeyour initial estimate anything other than a guess.Worry about estimating the overall scope of theproject and get that right instead of creating largedocuments. Consider spending the time youwould have invested into creating a detailedspecification on actually doing a couple iterationsof development. Measure the project velocityduring these initial explorations and make a muchbetter guess at the project's total size.ExtremeProgramming.org home XP Rules Iterative Development Email the webmasterCopyright 1999 Don Wells all rights elocity.html [10/17/2003 1:56:31 PM]
User StoriesUser StoriesUser stories serve the same purpose as usecases but are not the same. They are used to createtime estimates for the release planning meeting.They are also used instead of a large requirementsdocument. User Stories are written by the customersas things that the system needs to do for them. Theyare similar to usage scenarios, except that they arenot limited to describing a user interface. They are inthe format of about three sentences of text written bythe customer in the customers terminology withouttechno-syntax.User stories also drive the creation of theacceptance tests. One or more automated acceptancetests must be created to verify the user story has beencorrectly implemented.One of the biggest misunderstandings withuser stories is how they differ from traditionalrequirements specifications. The biggestdifference is in the level of detail. User stories shouldonly provide enough detail to make a reasonably lowrisk estimate of how long the story will take toimplement. When the time comes to implement thestory developers will go to the customer and receivea detailed description of the requirements face toface.Developers estimate how long the storiesmight take to implement. Each story will get a 1, 2 or3 week estimate in "ideal development time". Thisideal development time is how long it would take toimplement the story in code if there were nodistractions, no other assignments, and you knewexactly what to do. Longer than 3 weeks means youneed to break the story down further. Less than 1week and you are at too detailed a level, combinesome stories. About 80 user stories plus or minus 20is a perfect number to create a release plan duringrelease planning.Another difference between stories and arequirements document is a focus on user needs. Youshould try to avoid details of specific technology,data base layout, and algorithms. You should try tokeep stories focused on user needs and benefits asopposed to specifying GUI layouts.ExtremeProgramming.org home XP Rules Release Planning Email the webmasterCopyright 1999 Don Wells all rights erstories.html [10/17/2003 1:56:33 PM]
Extreme RulesThe Customer is Always AvailableOne of the few requirements of extremeprogramming (XP) is to have the customeravailable. Not only to help the development team,but to be a part of it as well. All phases of an XPproject require communication with thecustomer, preferably face to face, on site. It's bestto simply assign one or more customers to thedevelopment team. Beware though, this seems likea long time to keep the customer hanging and thecustomer's department is liable to try passing offa trainee as an expert. You need the expert.User Stories are written by the customer,with developers helping, to allow time estimates,and assign priority. The customers help makesure most of the system's desired functionality iscovered by stories.During the release planning meeting thecustomer will need to negotiate a selection of userstories to be included in each scheduled release.The timing of the release may need to benegotiated as well. The customers must make thedecisions that affect their business goals. A releaseplanning meeting is used to define smallincremental releases to allow functionality to bereleased to the customer early. This allows thecustomers to try the system earlier and give thedevelopers feedback sooner.Continued on page 2.ExtremeProgramming.org home XP Rules Coding Standards Email the webmasterCopyright 1997, 1999 Don Wells all rights reserved. Any resemblance to actual customers is purely es/customer.html [10/17/2003 1:56:34 PM]
Extreme RulesMake frequent small releasesThe development team needs to releaseiterative versions of the system to the customersoften. The release planning meeting is used todiscover small units of functionality that makegood business sense and can be released into thecustomer's environment early in the project. Thisis critical to getting valuable feedback in time tohave an impact on the system's development. Thelonger you wait to introduce an important featureto the system's users the less time you will have tofix it.ExtremeProgramming.org home XP Rules Project Velocity Email the webmasterCopyright 1997, 1999 Don Wells all rights eleaseoften.html [10/17/2003 1:56:35 PM]
Extreme RulesThe Rules and Practicesof Extreme Programming.PlanningCodingUser stories are written.Release planning creates the schedule.Make frequent small releases.The Project Velocity is measured.The project is divided into iterations.Iteration planning starts each iteration.Move people around.A stand-up meeting starts each day.Fix XP when it breaks.The customer is always available.Code must be written to agreed standards.Code the unit test first.All production code is pair programmed.Only one pair integrates code at a time.Integrate often.Use collective code ownership.Leave optimization till last.No overtime.DesigningTestingSimplicity.Choose a system metaphor.Use CRC cards for design sessions.Create spike solutions to reduce risk.No functionality is added early.Refactor whenever and wherever possible.All code must have unit tests.All code must pass all unit tests before itcan be released.When a bug is found tests are created.Acceptance tests are run often and the scoreis published.ExtremeProgramming.org home XP Map Email the webmasterCopyright 1999 Don Wells all rights ml [10/17/2003 1:56:36 PM]
XP flow ChartExtremeProgramming.org home Zoom in on Iteration. Starting with XP Email the webmasterCopyright 2000 Don Wells all rights ect.html [10/17/2003 1:56:36 PM]
Extreme RulesChoose a System MetaphorChoose a system metaphor to keep theteam on the same page by naming classes andmethods consistently. What you name yourobjects is very important for understanding theoverall design of the system and code reuse aswell. Being able to guess at what something mightbe named if it already existed and being right is areal time saver. Choose a system of names foryour objects that everyone can relate to withoutspecific, hard to earn knowledge about thesystem.For example the Chrysler payroll systemwas built as a production line. At another automanufacturer car sales were structured as a billof materials. There is also a
Extreme Programming: A Gentle Introduction. Extreme Programming: A gentle introduction. The goal of this site is to provide an introduction and overview of Extreme Programming (XP). For a guided tour of XP follow the trail of little buttons, starting here. Returning visitors can jump to recent changes to see what's new.
Extreme Programming John T. Bell Department of Computer Science University of Illinois, Chicago Prepared for CS 442, Spring 2017 2 Sources 1. Wikipedia: Extreme Programming 2. Wikipedia: Extreme Programming Practices 3. Wikipedia: Kent Beck 4. Kent eck and ynthia Andres, “Extreme Programming Explained: Embrace hange”, 2nd Edition 5.
Extreme Programming Extreme Programming (XP) takes commonsense software engineering principles and practices to extreme levels For instance “Testing is good?” then “We will test every day” and “We will write test cases before we code” As Kent Beck says extreme programming takes
Page 1 of 12 EXTREME PROGRAMMING 2.1 Extreme programming (XP) is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development,[1][2][3] it advocates frequent "releases" in short development cycles, which is intended to improve productivity
Advanced Gentle Yoga Teacher Training Manual GENTLE, SENIOR AND CHAIR YOGA TRAINING MANUAL - VOLUME 5 Chair and Senior Yoga, Gentle Yoga Therapy and Somatic Yoga Along with "Yoga Business" Guest Presenters With Sherry Zak Morris, E-RYT; Paula Montalvo, RYT; Justine Shelton, E-RYT500 and Certified Viniyoga Therapist
A majority ofArizona voters say that wildfires (84%), heat waves (79%), and drought (74%) have become at least somewhat more extreme in the past 3-5 years. 38% 36% 29% 36% 26% 43% 21% 55% 16% Drought Heat waves Wildfires Much more extreme Somewhat more extreme Not changed much at all Somewhat less extreme Much less extreme Perceptions of .
Extreme Programming Waterfall model inspired by civil engineering Civil engineering metaphor is not perfect – Software is more organic than concrete – You “grow the software” to meet changing requirements Extreme Programming (XP) addresses this – An iterative model – Recommended reading: “Extreme Software Engineering.
Programming? Extreme Programming (XP) is an agile software development methodology. It is a lightweight methodology combining a set of existing software development practices [5]. XP tends to rapidly develop high-quality software that provides the highest value for the customers in the fastest way possible. Extreme Programming is based on values
Love Map Questionnaire (1) By giving honest answer to the following questions, you will get a sense of the quality of your current love maps. For the most accurate reading of how your marriage is doing on the first principle, both of you should complete the following. 1. I can name my partner’s best friend. T or F 2. I can tell you what stresses my partner is currently facing. T or F 3. I .
