Some notes about book "Extreme Programming Explained: Embrace Change"

=== eXtreme Programming ===

-- VALUES --
-Comunication --> Open honest Comunication, hones measurement
- pair programming
- unit testing
- task estimation
programmners, managers, customers

-Simplicity
- writing tests gives you focus for just how simple the system can be

simple systems are easier to test

-Feedback
- sort term delivery 1 to 4 weeks
- puts the most value features in production as soon as possible
- writes tests gives you feedback about the state of the feature

The more feedback you have, the easier it is to communicate

-Courage

-- PRINCIPLES --
-Rapid feedback
-Assumed simplicity: YAGNI, DRY
-Incremental changes: smalll changes, step by step is better than on big change
-Embracing change
-Embracing change

-- PRACTICES --
-The planning game
-Small releases
-Metaphor
-Simple design
1 run all tests
2 has no duplicated logic
3 states every intention importan to the programmers
4 has the fewest possible classes and methods
-TEsting
-Refactoring
-Pair programming
-Collective ownership
-Continuous integration
-40 hours wekk
-On site customer
-Coding standards


Work with people´s instincts, not against them.
People like winning.
People like intercting with other people
People like being part of a team
people like being in control
People like being trusted
People like doing a good job
People like having their software work

activities: coding, testing, listening, designing

- The code must communicate everything yo want to communicate
- The system must contain no duplicate code (eliminate all the duplicated logic in the system)
- The system should have the fewest possible classes
- The system should have the fewest possible methods