XP Flashcards
XP overview
1) extreme and focus dev method
2) some principles may be too rigid
3) high quality shortly and efficiently
XP structure
1) Activities (listening, design, coding, testing)
2) values (communication, simplicity, courage, feedback, respect)
3) Practices (12)
Practices group
1) Feedback
2) continuous processes
3) Shared understanding
Feedback practices
1) whole team
2) Pair programming
3) testing
4) planning game
continuous processes practices
1) Simple system
2) Collective code ownership
3) System metaphor
4) Coding standards
Shared understanding practices
1) Small releases
2) Continuous integration
3) Refactoring
4) Sustainable pace
XP roles
1) Customer
2) Coach
3) Programmer
4) Tracker
5) Tester
system metaphor
story about the system everybody can tell
xp tracker
traces the progress, provides feedback
planning game release
1) Exploration phase (requirements shortlist)
2) commitment phase (commit to the functionality to be included in release)
3) Steering phase (adjustment)
planning game iteration
1) Activities of programmer
2) Exploration - decomposed to task
3) Commitment- task assignment and estimation
4) Steering - performance task and test
Pair programming
1) All code produced two programmers
2) One programmer has control
3) Other programmer reviews the code
4) Roles and pair switch
CRC Card
Use Class, Responsibilities, and Collaboration (CRC) Cards to design the system as a team. The biggest value of CRC cards is to allow people to break away from the procedural mode of thought and more fully appreciate object technology
Planning
1) User stories are written.
2) Release planning creates the release schedule.
3) Make frequent small releases.
4) The project is divided into iterations.
5) Iteration planning starts each iteration.
Managing
1) Give the team a dedicated open work space.
2) Set a sustainable pace.
3) A stand up meeting starts each day.
4) The Project Velocity is measured.
5) Move people around.
6) Fix XP when it breaks.
Designing
1) Simplicity.
2) Choose a system metaphor.
3) CRC cards for design sessions.
4) Create spike solutions to reduce risk.
5) No functionality is added early.
6) Refactor whenever and wherever possible.
coding
1) The customer is always available.
2) Code must be written to agreed standards.
3) Code the unit test first.
4) All production code is pair programmed.
5) Only one pair integrates code at a time.
6) Integrate often.
7) Set up a dedicated integration computer.
8) Use collective ownership.
Testing
1) All code must have unit tests.
2) All code must pass all unit tests before it can
be released.
3) When a bug is found tests are created.
4) Acceptance tests are run often and the score
is published.
