MARC Record from marc_columbia

LEADER: 04235mam a22003494a 4500
001 2509851
005 20221012182927.0
008 990623t20002000maua b 001 0 eng
010 $a 99036995
020 $a0201616416 (alk. paper)$z201616416
035 $a(OCoLC)ocm41834882
035 $9AQG1708CU
035 $a2509851
040 $aDLC$cDLC$dTXA$dC#P$dNNC$dOrLoB-B
042 $apcc
050 00 $aQA76.76.D47$bB434 2000
082 00 $a005.1$221
100 1 $aBeck, Kent.$0http://id.loc.gov/authorities/names/n96072482
245 10 $aExtreme programming explained :$bembrace change /$cKent Beck.
260 $aBoston :$bAddison-Wesley,$c[2000], ©2000.
300 $axxi, 190 pages :$billustrations ;$c24 cm
336 $atext$btxt$2rdacontent
337 $aunmediated$bn$2rdamedia
504 $aIncludes bibliographical references (p. 167-176) and index.
505 00 $gSect. 1.$tThe Problem.$gCh. 1.$tRisk: The Basic Problem.$tOur Mission.$gCh. 2.$tA Development Episode.$gCh. 3.$tEconomics of Software Development.$tOptions.$tExample.$gCh. 4.$tFour Variables.$tInteractions Between the Variables.$tFocus on Scope.$gCh. 5.$tCost of Change.$gCh. 6.$tLearning to Drive.$gCh. 7.$tFour Values.$tCommunication.$tSimplicity.$tFeedback.$tCourage.$tThe Values in Practice.$gCh. 8.$tBasic Principles.$gCh. 9.$tBack to Basics.$tCoding.$tTesting.$tListening.$tDesigning.$tConclusion --$gSect. 2.$tThe Solution.$gCh. 10.$tQuick Overview.$tThe Planning Game.$tSmall Releases.$tMetaphor.$tSimple Design.$tTesting.$tRefactoring.$tPair Programming.$tCollective Ownership.$tContinuous Integration.$t40-Hour Week.$tOn-Site Customer.$tCoding Standards.$gCh. 11.$tHow Could This Work?$tThe Planning Game.$tShort Releases.$tMetaphor.$tSimple Design.$tTesting.$tRefactoring.$tPair Programming.$tCollective Ownership.$tContinuous Integration.$t40-Hour Week.$tOn-Site Customer.$tCoding Standards.$tConclusion.
505 80 $gCh. 12.$tManagement Strategy.$tMetrics.$tCoaching.$tTracking.$tIntervention.$gCh. 13.$tFacilities Strategy.$gCh. 14.$tSplitting Business and Technical Responsibility.$tBusiness.$tDevelopment.$tWhat to Do?$tChoice of Technology.$tWhat If It's Hard?$gCh. 15.$tPlanning Strategy.$tThe Planning Game.$tIteration Planning.$tPlanning in a Week.$gCh. 16.$tDevelopment Strategy.$tContinuous Integration.$tCollective Ownership.$tPair Programming.$gCh. 17.$tDesign Strategy.$tThe Simplest Thing that Could Possibly Work.$tHow Does "Designing Through Refactoring" Work?$tWhat Is Simplest?$tHow Could This Work?$tRole of Pictures in Design.$tSystem Architecture.$gCh. 18.$tTesting Strategy.$tWho Writes Tests?$tOther Tests --$gSect. 3.$tImplementing XP.$gCh. 19.$tAdopting XP.$gCh. 20.$tRetrofitting XP.$tTesting.$tDesign.$tPlanning.$tManagement.$tDevelopment.$tIn Trouble?$gCh. 21.$tLifecycle of an Ideal XP Project.$tExploration.$tPlanning.$tIterations to First Release.$tProductionizing.$tMaintenance.$tDeath.
505 80 $gCh. 22.$tRoles for People.$tProgrammer.$tCustomer.$tTester.$tTracker.$tCoach.$tConsultant.$tBig Boss.$gCh. 23.$t20-80 Rule.$gCh. 24.$tWhat Makes XP Hard.$gCh. 25.$tWhen You Shouldn't Try XP.$gCh. 26.$tXP at Work.$tFixed Price.$tOutsourcing.$tInsourcing.$tTime and Materials.$tCompletion Bonus.$tEarly Termination.$tFrameworks.$tShrinkwrap Products.$gCh. 27.$tConclusion.$tExpectation.
520 1 $a"Extreme Programming (XP) was conceived and developed to address the specific needs of software development conducted by small teams in the face of vague and changing requirements. This new lightweight methodology challenges many conventional tenets, including the long-held assumption that the cost of changing a piece of software necessarily rises dramatically over the course of time.
520 8 $aXP recognizes that projects have to work to achieve this reduction in cost and exploit the savings once they have been earned." "You may love XP or you may hate it, but Extreme Programming Explained will force you to take a fresh look at how you develop software."--BOOK JACKET.
650 0 $aComputer software$xDevelopment.$0http://id.loc.gov/authorities/subjects/sh85029535
650 0 $aeXtreme programming.$0http://id.loc.gov/authorities/subjects/sh99004731
852 00 $boff,eng$hQA76.76.D47$iB434 2000