Principles may guide your team´s practices, but these are the prinnciples that guide XP:
What do people need to be good developers?
- Basic safety: Freedom from hunger, physical harm, and threats to loved ones. Fear of job loss threatens this need.
- Accomplishment: The opportunity and ability to contribute to their society.
- Belonging: The ability to identify with a group from which they receive validation and accountability and contribute t its shared goals.
- Growth: The opportunity to expand their skills and perspective.
- Intimacy: The ability to undertand and be undertood deeply by others.
Part of the challenge of team software development is balancing the needs of the individual with the needs of the team.
Somebody has to pay for all this. Software development that doesn´t acknowledge eonomics risks the hollow victory of a technical success. Make sure what you ar doing has business value , meets business goals, and serves business needs.
The time vallue of money says that a dollar today is worth more than a dollar tomorrow.
- I write automated tests that help me design and implement better today. I leave these tests for future programmers and for team to use as well.
- I carefully refactor to remove complexity, giving me both satisfaction and fewer defects and making the code easier to understand for those who encounter it later.
- I choose names from a coherent and explicit set of metaphors which speeds my developent and makes the code clearer to new programmers.
If you want people to take your advice, you need to solve more problems than you create. Mutual benefit in XP is searching for practices that benefit me now, me later, and my customer as well. Win-win-win practices are easier to sell because they relieve some immediate pain.
Copy a structure that works in one context doesn´t mean it will work in another. It is a good place to start, though.
Having the syste-level tests before you begin implementation simplifies design, reduces stress, and improves feedback.
Best is the enemy of good enough, suggests that mediocrity is preferable to waiting. This phrase misses the point of XP, which is excellence in softwre development through improvement. The cycle is to do the best you can today, striing for the awareness and undertanding necessary to do better tomorrow. It doesn´t mean waiting for perfection in order to begin.
Put improvement to work by not waiting for perfection. Find a starting place, get started, and improve from there.
The principle of diversity suggests that the programmers should work together on the problem and both opinions should be valued.
What if the team isn´t good at conflict? Every team has conflict. The question is whether they resolve it productively. Respecting others and maintaining myself smooths comunication in times of stress.
Diversity is expressed in the practice of whole team.
Good teams don´t just do their work, they thik about how they are working and why thery are working. They analye why they succeeeded or faild. They don´t try to hide their mistakes, but xpose tem and learnn from them. No one stumbles into excellence.
Reflection comes after action. learning is action reflected. To maximize feedback, reflection in XP teams is mixed with doing.
Dificults problems should be solved several different ways.
You can´t solve the defect problem with a single practice. It is too complex, with too many facets, and it will never be solved completely. What you hope to achieve is few enough defects to maintain trust both within the tea ad with the customer.
While redudancy can be wasteful, be careful not to remove redundancy that serves a valid purpose.
The practices of XP are biased towards a continuous flow. Any time you move away from flow, resolve to return. Resolve the problems that disrupted your flow and get back to weekly deployment as soon as you can.
Learn to see problems as opportunities for change. This isn´t to say there are no problems in softare development. However, the attitude of survival leads to just enough problem solving to get by. To reach excellence, problems need to turn into opportunities for learning and improvement, not just survival.
As you begin practicing XP, you will certainly encounter problems. Part of being extree is consciously choosing to transform each problem into an opportunity: an opportunity for personal growth, deepening relationships, and improved software.
If you are having trouble succeeding fail. Don´t know which of three ways to implement a story? Try it all three wys. Even if they all fail, you will certainly learn something valuable.
Isn´t failure waste? No, not if it imparts knowledge. Knowledge is valuable and someties hard to come by. Failure may not be avoidable waste. If you knew the best way to implement the story you´d just implement it that way.
Sacrificing quality is not effective as a means of control. Quality is not a control variable. Quality isn´t a purely economic factor People need to do work they are proud of. If you can´t control projects by controlling quality, how can you control them? Tie and cost are most oftenn fixed. XP chooses scope as the prmary meas of planninng, tracking, and steering projects. Since scope is never known precisely in advance, it makes a good lever. The weekly annd quarterly cycles provide explicit points for tracking and choosing scope.
Make a big change efficiently in small, safe steps.
It´s always tempting to make big changes in bit steps. After all, there´s a long way to go ad shor time to get there. Momentous change taken all at once is dangerous. It is people who are being asked to change. Change is unsettling. People only change so fast.
Responsability cannot be assigned; it can only be accepted. If someonne tries to give you responsability, only you can decide if you are responsible or if you aren´t.
You can use the principles to understand the practices better and to improvise coplementary practices whe you don´t find one that suits your purpose.