Extreme Programming Notes
XP Programming focuses on delivering business value in every iteration.
Whole Team
- All contributors are members of one team
- Customer: business representative that provides requirements, sets priorities, and steers the project
- Best if it is a real end user who knows the domain and what is needed
- Programmers
- Testers
- Analysts: helpers to Customer, help define requirements
- Coach: keep team on track, facilitate process
- Manager: provide resources, handle external communication, coordinate activities
- These roles are exclusive to just one individual
- The best teams have no specialists, only general contributors with special skills
Planning Game
- Addresses 2 key problems
- Predict what will be accomplished by due date
- Determine what to do next
- Release Planning: Customer presents desired features to programmers, who estimate their difficulty
- With estimates in hand, Customer lays out a plan
- Initial release plans are necessarily imprecise: no solid priorities or estimates
- XP teams revise release plan regularly
- Iteration Planning: XP team builds software in 2-week iterations
- Customer presents features desired for the next two weeks
- Programmers break them down into tasks
- Estimates based on previous iteration
- Steers control into the hands of Customer
- There is no 90% done in XP: a feature was completed, or it was not
- Progress is visible
- Customer is in a position to cancel if not efficient
- But usually XP delivers more than needed with less pressure & stress
- The most important aspect is that the software is visible, and given to the customer, at the end of every iteration. This keeps everything open and tangible.
Pair Programming
- All software in XP is built by 2 programmers, sitting side by side, at the same machine
- As pairs switch, everyone gets the benefits of everyone’s specialized knowledge
Test-Driven
- Unit tests are collected together every time any programmer releases any code to the repo
- Programmers get immediate feedback
Refactoring
- Remove duplication
- Increase cohesion
- Lower coupling
Continuous Integration
- Frequent builds, not just daily, but multiple times a day
- Consequences of infrequent integration
- The team is not familiar with integration, even though it is critical to shipping good code
- Buggy code
- Long code freezes: programmers could be working on important shippable features but those features must be held back
Collective Code Ownership
- All code gets the benefit of many people’s attention: increase code quality
- Reduce feature duplication
- When working on unfamiliar code, pair with an expert
Coding standard
- Reduce friction when working on other developers’ code
Metaphor
- A common metaphor succinctly communicates the team vision
Sustainable Pace
- Programmers are in it to win, not to burnout