| Book | Introduction |
|---|---|
 |
XP is a style of software development focusing on excellent application of programming techniques, clear communication, and teamwork which allow us to accomplish things we previously could not even imagine. XP Includes: |
- A philosophy of software development based on the values of communication, feedback, simplicity, courage, and respect.
- A body of practices proven useful in improving software development, The practices complement each er, amplifying their effects. The are chosen as expressions of the values.
- It’s short development cycles, resulting in early, concrete, and continuing feedback.
- XP is a lightweight methodology for small-to-medium-sized teams developing software in the face of vague or rapidly changing requirements.
- XP Creates and maintains a comprehensive suite of automated tests, which are run and rerun after every change to ensure a quality baseline.
- XP always keeps the system in deployable condition. Problems are not allowed to accumulate.
- XP insists that only the highest priority task are addressed.
- XP asks programmers to accept responsibility for estimating and completing their own work, gives them feedback about the actual time taken so their estimates can improve, and respects those estimates.
- XP is like driving because: “Driving is not about getting the car going in the right direction. Driving is about constantly paying attention, making a little correction this way, a little correction that way.” This is the paradigm for XP, Stay aware. Adapt. Change.
- XP embraces five values to guide development: communication, simplicity, feedback, courage, and respect.
Communication: When you encounter a problem, ask yourselves if the problem was caused by a lack of communication.
Simplicity: Is the most intensely intellectual of the XP values.
Feedback: XP teams strive to generate as much feedback as they can handle as quickly as possible. They try to shorten the feedback cycle to minutes or hours instead of weeks or months. The sooner you know, the sooner you can adapt.
Courage: Is effective action in the face of fear. Sometimes courage manifest as a bias to action. If you know what the problem is, do something about it. Sometimes courage manifest as patience. If you there is a problem but you don’t know what it is, it takes courage to wait for the real problem to emerge distinctly.
Respect: If members of a team don’t care about each other and what they are doing, XP won’t work. If members of a team don’t care about a project, nothing can save it. For software development to simultaneously improve in humanity and productivity, the contributions of each person on the team need to be respected. I am important and so are you.
Principles
Humanity: People develop software, that’s the way because we need to pay attention to: Basic Safety, Accomplishment (Opportunity to contribute to their society), Belonging (The ability to identify with a group from which they receive validation and accountability and contribute to its shared goals), Growth (Opportunity to expand their skills and perspective). Intimacy (The ability to understand and be understood deeply by others).
Economics: Solving the highest priority business need first maximizes the value of the project.
Mutual Benefit: I write automated tests that help me design and implement better today, I leave these tests for future programmers to use as well. This practice benefits me now and maintainers down the road. I carefully refactor to remove accidental complexity, giving me both satisfaction and fewer defects and making the code easier to understand for those who encounter later. Mutual benefit is the most important XP principle.
Diversity: In order to think of multiple ways to solve problems, and to implement solutions. Development teams need diversity. Two ideas about design present an opportunity, not a problem. The principle of diversity suggest that the programmers should work together on the problem and both opinions should be valuated.
Opportunity: Choosing to transform each problem into an opportunity for personal growth, deepening relationships, and improved software.
Failure: If you’re having trouble succeeding, fail. Don’t know which of the three ways to implement a story? Try it all three ways. Even if they all fail, you’ll certainly learn something valuable.
Quality: Projects don’t go faster by accepting lower quality. The don’t go slower by demanding higher quality. Pushing quality higher often results in faster delivery; while lowering quality standards often results in later, less predictable delivery.
Responsibility: cannot be assigned; it can only be accepted, if someone tries to give you responsibility, only you can decide if you are responsible or if you aren’t.
Primary Practices
Whole Team: People need a sense of “team”:
- We belong.
- We are in this together.
- We support each other’s work, growth, and learning.
Stories: When your team are doing estimation be sure that your story has all constraints in that case the team can split in task and do it in a informed decision way.
Pair Programming
- Keep each other on task.
- Brainstorm refinements to the system.
- Clarify ideas.
- Take initiative when their partner is stuck, thus lowering frustration.
- Hold each other accountable to the team’s practices. In addition: Rotate pairs frequently, personal hygiene and health are important issues when pairing.