XP Explained

XP ExplainedChapters 7-9

Primary PracticesSit togetherIdealResistanceMulti-siteWhole TeamAll the necessary skills in a single management structureThis is dynamicNo fractional staff

Primary PracticesInformative workspaceKey metrics as big graphs and chartsVisible planning and trackingRequirements groupsEnergized Work40 hour weekFocus time

Primary PracticesPair Programming (switch as needed, maybe multiple times per day)Keep each other on taskBrainstormClarifySwitch lead when one is stuckHold each accountable

Primary PracticesPair Programming and personal spaceSee figure 6 page 44We like our personal space!

Primary PracticesStoriesPlan using units of customer visible functionalityProvide a 2 click way for customers to dial frequently used numbersMake technical requirements visible with test casesRequirement is a misnomerValue cannot be determined with out cost estimates

Primary PracticesWeekly CycleWeekly meetingReview progressCustomer pick new weeks worth of storiesBreak stories into tasks, team members sign up for tasks and estimate themStart the week by writing automated test

Primary PracticesQuarterly CycleReflect on the team, project, progress. Process, and alignment with larger goalsQuarterly meetingIdentify bottlenecksInitiate repairsPlan themesBig picture where the project fits within stakeholder concerns

Primary PracticesSlackEverything cant be plannedInclude tasks in the plan that could be dropped

Primary PracticesTen Minute BuildAutomatically build and test in 10 minutes. What if you cantYou can more often that you think

Primary PracticesContinuous integrationIntegrate and test changes after no more than a couple of hoursIntegration can take more time that the original programmingSynchronous is better than Asynchronous

Primary PracticesTest first ProgrammingWrite the tests before the code and do it at a very fine level of granularity.If it is hard to write a test you have a design problem not a test problemRhythm

Primary PracticesIncremental DesignInvest in the design of the system every dayDefer design decisions to the last responsible momentThe most effective time to design is in the light of experienceThe closer the implementation of a design mechanism to the time it is actually needed, the more efficient

Chapter 8Getting Started

Getting StartedMake adopting XP an XP projectWrite storiesEducate managementAttending trainingAutomate the buildPrioritize the storiesEstimate their time and costCreate and track metrics

Chapter 9Corollary Practices

Corollary PracticesReal Customer InvolvementMake your stakeholders part of the team

Corollary PracticesIncremental DeploymentRun parallel systems if necessary

Corollary PracticesTeam ContinuityDont throw everyone back into the labor pool once a project is finished

Corollary PracticesShrinking TeamsAs a team grows in capability, keep its workload constant but gradually reduce its size

Corollary PracticesRoot Cause AnalysisWhen you find a defect, eliminate the defect and the causeThe goal is that the team wont ever make the same mistake againI expect that individuals will make mistakes, but my process should ensure that my team doesnt make mistakesFive whys

Corollary PracticesShared CodeAnyone can improve any part of the system at anytimeEliminates bottlenecksDoesnt work across team boundries

Corollary PracticesCode and TestsMaintain only the code and tests as permanent artifacts. Generate other documents from the code and tests. Rely on Social mechanisms for the rest.

Corollary PracticesSingle Code BaseDuplication is not fun and it is very expensiveFrameworks can help solve this

Corollary PracticesDaily DeploymentPut new software into production every night

Corollary PracticesNegotiated Scope ContractWrite contracts that fix time, costs, and quality but call for an ongoing negotiation of the scopeFix scope but leave specific requirement to ongoing negotiationSign a series of shorter contracts rather than one big one