Pair Programming Benefits and Rules

Pair programming is one of the more successfull technique from the agile movement. However it may require a cultural change in traditional software shops. Paying attention to explain the benefits and giving some guidance will help:

General benefits:

• Produces better code coverage. By switching pairs, developers understand more of the system.
• Minimizes dependencies upon personnel.
• Results in a more evenly paced, sustainable development rhythm.
• Can produce solutions more rapidly.
• Moves all team members to a higher level of skills and system understanding.
• Helps build a true team.

Specific benefits from a management standpoint:

• Reduces risk
• Shorter learning curve for new hires
• Can be used as interviewing criteria ("can we work with this guy?")
• Problems are far less hidden
• Helps ensure adherence to standards
• Cross-pollination/resource fluidity.

Specific benefits from an employee perspective:

• Awareness of other parts of the system
• Resume building
• Decreases time spent in review meetings
• Continuous education. Learn new things every day from even the most junior programmers.
• Provides the ability to move between teams.
• More rapid learning as a new hire.

Rules:

1. all production code must be developed by a pair.
2. it's not one person doing all the work and another watching.
3. switch keyboards several times an hour. The person without the keyboard should be thinking about the bigger picture and should be providing strategic direction.
4. don't pair more than 75% of your work day. Make sure you take breaks! Get up and walk around for a few minutes at least once an hour.
5. switch pairs frequently, at least once a day.

Read the complete article with good advice in 'Pair Programming Observations, by Jeff Langr, StickyMinds.com'.

For more in-depth knowledge of cost and benefits read:
Pair Programming Illuminated - by Laurie Williams, Robert Kessler

Most Useful Requirements Processes

Understand and communicate requirements that align yout IT priorities
with your business needs.

No process is more fundamental than the process of defining and managing business and technical requirements. It's no surprise that studies cite inaccurate, incomplete, and mismanaged requirements as the primary reason for project failure.

The Requirements-engineering process consists of two major domains: definition and management.

Best practices:

Elicit Requiremements:

• Define the vision and project scope.
• Identify the appropriate stakeholders.
• Select champions (Voice of the customer).
• Choose elicitation techniques (workshops, questionnaires, surveys, individual interviews).
• Explore user scenarios.

Analyse Requirements: verify they are complete and achievable

• Create analysis models.
• Build and evaluate prototypes.
• Prioritize requirements.

Specify Requirements:

• Look for ambiguities.
• Store requirements in a database.
• Trace requirements into design, code, and tests.

Validate Requirements:

• Review the requirements through a formal peer review.
• Create test cases from requirements.

Manage Requirements:

• Manage versions.
• Adopt a change control process.
• Perform requirements change impact analysis.
• Store requirements attributes.
• Track the status of each requirement.

Applying requirements best practices lead to higher satisfaction for your customers.

These are highlights from Matts Klassen's article: Achieve Useful Requirements Processes.