Xp Glossary

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