le bac à sable de Pierre

Get the best hardware you can .  Saving on hardware is stupid . One big screen is better than two . It is easier to look at the same thing .  Always talk out loud what you think . Your pair cannot read your mind . Switch roles frequently . At least every 25 minutes . It helps the pair stay focused. Take breaks . A day of pair programming can be exhausting! Use Test Driven Development . It helps you keep track of what your doing. It can improve the quality of your code. But do not forget the goal which is code that works, not test coverage . Recommended readings: http://www.extremeprogramming.org/rules/pair.html http://guide.agilealliance.org/guide/pairing.html http://www.wikihow.com/Pair-Program http://blog.xebia.com/2010/05/09/practical-styles-of-pair-programming

Recycling an article I wrote in French in 2010 . Following endless estimation sessions in the project I am working on, I have come to ask myself some questions about this practice. Why do we estimate? I think an estimation session should have two purposes. To share a common understanding of upcoming stories. To estimate upcoming work in order to plan the next steps and monitor the evolution of the project. Who should attend the estimation session? Anyone who can clarify upcoming stories and anyone who will carry these stories to completion. To improve your estimation session, you can try the following: divide the estimation session into two stages . Understanding upcoming stories. Estimating the work to be done. Understanding upcoming stories through discussion among project participants is the highlight of an estimation session . The shared vision emerging from these exchanges will facilitate future communications. Estimating should be more relevant and should be d