Mindomo Requires javascript and the latest version of the Adobe Flash Player Plugin.

After getting used to testing, you will code with much more confidence. When faced with a big refactoring, you have to take it in small incemental steps. In strict ownership code diverges from team's understanding. Discourage communication that doesn't help Things that have to be communicated, must get communicated when they need to be communicated, in the amount of detail they need to be communicated. Constant refactoring breaks the system into little objects and little methos, which will also lower the change that two pairs of programmers will change the same class or method at the same time. If several tasks each take an hour, combine them to form a larger task. If you accidently break something at a distance, you will know it in matter of hours, not in days, weeks or months. Trust in your own, your partner's and team's abilities. Prevents complex code from entering the system. Management Pares requirements and approaches? While partner is typing, the other one is thinking at a more strategic level. Have tools that support a fast integration/build/test cycle. Integration must not take couple of hours. Refactoring Structured communication Programming and testing together is faster than just programming. Fine tuning Do what is needed to do and feel relaxed while doing it. Good design organizes the logic. Coding Programmers must be able to tell where and what are the problems in the code, explain the consequences of other people's decisions, express their fears, get support and be free to deliver bad news without getting punished. Aim to quality. It will also sustain confortability and enjoyment toward the work. Too much, too early? Too much details in a discussion might conceal an important part of the communication. Fixing a major flaw might take a few days of concentrated effort and while doing that half of the tests might get broken. Customer Both, generating code and drawing diagrams is coding. To-do cards Increases your feeling of personal power on a project. Coach You will be less likely to break something. Communication You will have an entirely different discussion, if you are chewing at the same time. Food is a hallmark of XP projects. Each party believes that the other has their best interest at heart, and the interests of the larger community. Each party is willing to let the other do their job, joining the skills, experience and perspective of both. Too tight budget? Should be given two or three iterations of asking lots of questions, acting as a pair programming partner, and reading lots of tests and code. Collective ownership In-production Tests must not interact with each other as that way you avoid the problem that one test fails and causes hundred other failures. Coding together enables seeing the ideas in partner's mind taking shape on their way in finding a logically expressed form. Be prepared to change the team structure and consider rotating all the programmers to man the help desk as there are things to be learned from supporting the product that way. Turns easily into learning. Designing with pictures is suitable only till to the point, where a question can be answered with code. Pictures, which might be drawn on a whiteboard, aren't saved. Progress tracker When you need to refactor or fix a bug, write a test first. Test things that might break. Should be put into, as soon after it begins to make sense, as that way it can be felt what the system is like in action and discover how it can best be exploited. Information rapidly diffuses throughout the team just as the dye spreads throughout a pool. Should be available as development partner, particularly for new programmers beginning to take responsibility or for difficult technical tasks. Tests If the computers are in the wrong place, they are moved. If the partitions are in the way, they are taken down. If the lights are too bright, they are taken out. Instinct Team members need to be able to see each other, to hear shouted one-off questions, to accidently hear conversations to which they have vital contributions. Chaos would arise, if everyone would just be making changes that fit to their own purposes -- especially when related objects and lines of code have some kind of relationship. Environment Tasks that take more than a few days must be split . Throwing code away. Courage Until all the tests run, you aren't done. Generally the tasks are smaller than the whole story. Don't take your eyes off the road, even when things seem to be going perfectly. If something is best expressed as pictures, then it should definately be done and maintained as such. If you can't estimate a task at a few days, break it down into smaller tasks. Other roles Product Can also test nonfunctional requirements like performance and adherence of code standards. Code gives a change to communicate clearly and concisely. Be well rested, and you will have more courage and are less likely to make mistakes. Might arise from concurrent learning and implementing. One might wish to work with a particular partner, but more commonly you just find someone who is available. Frustration Reserve a little of the nicest space off to one side for a communal space. Put in an espresso maker, couches, some toys, something to draw people there. Play to win Watches the complemention of the tasks to give the whole team feedback. Budget and resources Reasonably complete test suite must run in a few minutes. Continuous integration Not all ideas can be justified for putting into the system for current release, and therefore you make a visible list so everyone can see where you will be going after this release. New team member Gap between partners will not be so noticeable after couple of months. eXtreme Programming Should review the schedule every two or three weeks to see if the team's overall velocity matches the plan. Pair-programming Perfect in the late of the game as you will have gathered more knowledge about design of the system and have realistic estimates about production load on the system. Overtime is a symptom of serious problem on the project. You must not work a second week of overtime. Playing to not lose would be Developing by the book for the reason of being able to say it wasn't my fault . Under stress, people revert and they will stop writing tests, put off refactoring and avoid integrating. Changes are that your programming partner is feeling himself more calm and can lead the progress more further. While shifting between old and new code, you might notice tendency in avoiding the old code, but this avoidance should be resisted and all the code brought forward. Making a decision without testing it, will increase the probability of the risks compound.