A Glossary of ExtremeProgramming Terms & Acronyms
Please keep entries in alphabetical order. Please keep discussion on the linked-to pages.
- AcceptanceTest
- a test written by the customer, (or QC on the customer's behalf) that tests the entire system to ensure that a specific piece of functionality is present and functions correctly.
- AT
- acronym for Acceptance Test
- BDUF
- "BigDesignUpFront"; part of WaterFall.
- BUFD
- Big, Up-Front Design. Variation on BDUF.
- Business
- ???
- Customer
- (The literature is thin on this one) The primary stakeholder (on-site, in-the-lab) of the system undergoing the XP methodology. Provides the final acceptance criteria for any behavior in the system. Sometimes a team instead of one person. Less optimally, but often likely, this is a Business Analyst who, while they may be a Domain Expert, does not have the final say, but acts as the advocate of the real Customer who is not on-site. (Beware the Customer who knows the Business but does not have the Final Say).
- DBC
- acronym for DesignByContract.
- DTSTTCPW
- "DoTheSimplestThingThatCouldPossiblyWork" A general XP heuristic on how complicated a design should be.
- DRY
- "Don'tRepeatYourself" From ThePragmaticProgrammer, a more general version of OAOO.
- EngineeringTask
- UserStory gets broken down into these smaller fragments by the developers.
- GangOfFour
- ErichGamma, RichardHelm, RalphJohnson, and JohnVlissides. Authors of the classic book "Design Patterns". See DesignPatternsBook.
- GoF
- Abbreviation for "Gang of Four".
- GreenBar
- What JavaUnit displays when all UnitTests run successfully. The bar is green, the code is clean.
- Green Book
- PlanningExtremeProgramming by KentBeck and MartinFowler.
- OAOO
- "OnceAndOnlyOnce" The state of a well designed program -- it says everything that currently needs to be said precisely once. Compare with DRY.
- PEP
- acronym for PlanningExtremeProgramming (the green book).
- Pink Book
- ExtremeProgrammingInstalled by RonJeffries, AnnAnderson, and ChetHendrickson.
- PP
- acronym for PairProgramming.
- RUP
- acronym for RationalUnifiedProcess.
- Spike
- a quick (typically minutes or hours) exploration by coding of an area the development team lacks confidence in. The spike is concluded when you learn what you needed to learn. So-called because a spike is "end to end, but very thin", like driving a spike all the way through a log. See SpikeSolution, ArchitecturalSpike, SpikeDescribed.
- TDD
- "TestDrivenDevelopment"
- TestInfected
- When you can't even go pee unless you have a GreenBar.
- TETCPB
- "TestEverythingThatCouldPossiblyBreak" I haven't seen the acronym in common usage. Reference?
UAT:"User Acceptance Testing", see Acceptance Testing. These are test done by the client every end of Iteration and/or every Release
- UnitTest
- a test that tests a single class, or a small cluster of classes in isolation.
- UserStory
- Broad description of a feature, created by the customer, estimated by developers, fits on a note card.
- UT
- acronym for UnitTest.
- White Book
- ExtremeProgrammingExplained by KentBeck.
- XPE
- ExtremeProgrammingExplained by KentBeck (the white book).
- XpValues
- Communication, Simplicity, Feedback, and Courage.
- YAGNI
- "YouArentGonnaNeedIt", said by XP coaches when developers get into overly baroque design territory.
Please keep entries in alphabetical ord er. Please keep discussion on the linked to pages.
CategoryExtremeProgramming
Xp Glossary