Code Library: eXtreme Programming

Showing posts with label eXtreme Programming. Show all posts

Pair Programming Pair programming comes from the understanding that two heads are better than one. In pair programming, two developers share the duties of completing a user story task; the idea is that both developers have time at the keyboard. There’s a driver and a navigator. The driver is the one sitting at the keyboard typing in code, while the navigator is the one reviewing the code being written, thinking about how to code the next step, and guiding the driver down a focused path. At first, management is often skeptical of this idea. They think that productivity will be cut in half because you have two developers doing what one developer could do. In reality, productivity increases in the following areas:

1. Programmers stay focused: While we may not like to admit it, developers tend to be easily distracted. If they are stumped with a problem they typically go to the web to find some inspiration. This inspiration time typically slides into checking Twitter or Facebook or reading the latest blogs. With pair programming, each programmer is held accountable to the other to stay focused on the task at hand. Besides, it’s easier to bounce ideas off one another and come up with a solution quicker.

2. Increase the “bus factor:” When one developer works on a feature, he works in a silo. His knowledge is therefore “siloed,” leading to a “bus factor” of 1. This colorful term focuses attention on the question: If you get hit by a bus or leave the company, what happens? Typically someone else needs to get ramped up on the code, but that takes time. With pair programming, the “bus factor” is increased to 2, which makes maintaining the system easier because two people have the knowledge. Moreover, they can usually add new features more quickly than if they were siloed.

Pair programming is typically a developer practice, but it can be extended (for instance) to having a business analyst and a developer sitting down together. They can discuss the tests to be written, so questions and ideas can be answered quickly.

Source of Information : Pro Agile .NET Development with SCRUM

XP Coding Standards Traditionally the XP practice of coding standards focused on a set of rules that the development team agreed upon for the formatting and naming conventions of code. In our experience, coding standards go far beyond formatting and naming conventions. We are far more concerned with overly long methods and poorly named variables than the need to underscore local variables.

Coding standards dictate such things as keeping each method’s source code no longer than the height of your monitor, and having self-documenting code. That, in turn, entails properly naming variables—avoiding such mysterious names as i or j—and instead giving each variable a meaningful name so that the next programmer can quickly understand the role it plays. A good software craftsman will not program only for himself, but “program ahead” and write easily maintainable code for the next person coming in to add a new feature.

A standard code style throughout a project will certainly contribute to collective ownership and help people working on different parts of the system to recognize the style and formatting. Popular tools such as JetBrains’ ReSharper can highlight coding that does not adhere to a defined set of coding standards, so when a coding style is agreed upon it is easy to implement.

We feel it is important to ensure that code is well written and clearly conveys its intention. A great resource that can help with creating clean code is Clean Code: A Handbook of Agile Software Craftsmanship by Robert Martin (Prentice Hall, 2008). Another way to ensure coding standards are adhered to is to have all developers understand the SOLID set of design principles as catalogued in Agile Principles, Patterns, and Practices in C# by Robert Martin (Prentice Hall, 2006).

Briefly, the SOLID design principles are as follows:

• Single Responsibility Principle: An object should have only a single responsibility—a focused task.

• Open/Closed Principle: Software entities should be open for extension, but closed for modification.

• Liskov Substitution Principle: Objects in a program should have the ability to be replaced by instances of their subtypes without altering the correctness of that program. Typically, this is accomplished through design by contract.

• Interface Segregation Principle: Many client-specific interfaces are better than one general-purpose interface.

• Dependency Inversion Principle: Develop against abstractions and do not depend upon concretions.

Source of Information : Pro Agile .NET Development with SCRUM

XP Practices and Principles XP is made up of a set of twelve practices that can be used independently, but are far more powerful when used in concert.

Let's take a look at how these practices relate to the iterative development process.

1. Planning Game: The planning game captures the features of the system as user stories, and defines the releases of the project. During iteration planning, user stories selected for the iteration are broken down into development tasks.

2. System Metaphor: When communicating with the business, it helps to have a ubiquitous language so that complex systems can be explained easily.

3. Simple Design: High-level system design occurs at the start and during an iteration.

4. On-Site Customer: During an iteration, it is ideal for the customer to be on-site to aid in quickly answering details of a user story. While physical meetings are ideal, virtual meetings are better than no meeting at all. The important point is to have an available customer who can quickly provide answers as the developers explore the details of a user story.

5. Team Sitting Together: It’s important for all of the team committed to the project to be within shouting distance of each other. This improves communication and imparts a feeling of camaraderie.

6. Pair Programming: Pair programming is a development practice that pairs developers so that they can work on a problem together. A pair will share a development machine, and while one codes, the other will assist with design decisions and look ahead to the next feature. With pair programming, code reviews become “real time,” producing a level of quality that “inspection-only” cannot. With two people developing, it's highly unlikely that they will both overlook the same mistake.

7. Collective Code Ownership: Through sitting together and pair programming, the entire team shares a collective ownership of the code base. All developers are allowed to fix and work on any part of the code base.

8. Coding Standards: To help with collective ownership, best practices are used to keep a simple design and ensure all code is created in a consistent manner. This ensures that source code can be understood quickly when working on any part of the system and with any other developer.

9. Testing: To ensure quality is delivered to the customer, emphasis is placed on testing through the XP process. Testing starts by identifying acceptance criteria from user stories. These acceptance criteria are used to write unit tests and start development in TDD style. User acceptance testing also derives from the acceptance criteria and will be automated as much as possible.

10. Continuous Integration: To ensure that all of the code that the team is collectively developing actually works, the team integrates often and early. A continuous integration (CI) server will pull the code base from a source control repository, build it, and run all the automated tests to ensure the build is not broken. The publicly published output of the CI server can be notified instantly to developers, customers, and project managers. This report includes the number of tests that are pass/fail at this point. Daily tracking provides an indicator of progress in creating customer value. This quick feedback loop also
enables developers to fix the build. The sooner an issue is identified, the cheaper it is to fix.

11. Sustainable Pace: Because of the short release cycles and the iterative nature of XP, requirements gathering, design, development, testing, and deploying all happen often. This means that issues found after review and testing can be incorporated into the next iteration. This quick feedback model ensures that developers can work at a sustainable pace. Thus, they save long weeks compared to more traditional development methodologies that have clearly defined stages for the development life-cycle, leaving feedback and testing until the end. Sustainable pace also helps management to plan more efficiently for staff holidays, unplanned absences, and the occasional production “fire” that needs to be extinguished immediately.

12. Small Releases: XP is all about customer satisfaction and delivering business value through quality software. As far as the business is concerned, the more often this can happen, the better. XP promotes frequent releases, which may be relatively small, but highlights the features prioritized by the business. XP does not allow the development team to go into hiding for months on end, hoping that the project completes on time. This transparency of frequent releases encourages customers by showing them the team is adding value to the project all along the way.

Each of these twelve practices forms the practical application of XP, which realizes the five values discussed in the previous section.

The remainder of this chapter will take a more detailed look at the twelve XP practices, starting with project planning.

Source of Information : Pro Agile .NET Development with SCRUM

eXtreme Programming Values eXtreme Programming is based on the following five core values:

• Respect: Respect is a two-way street: it needs to be given to fellow teammates so that everyone feels respected as a valued team member; and it is also required from management so that the team owns and is responsible for what they have committed to. Respect is not attacking a fellow developer for the code that he has written. Respect implies criticizing the code, not the developer, and working with that developer to increase his level of code quality. Respect is being humble and leading by example to bring others on your team up, not disrespectfully tear them down.

• Communication: In order to develop quality software efficiently, clear and frequent communication is required between the customer and team members. If possible, sit down with the customer and flush out ideas, point to things, make communication highly visible and interactive, and avoid "pie in the sky" types of conversations. Stick figures and a whiteboard or pointing at the computer screen to bring across a point go a long way. Such methods often work better than trying to write a multi-page document attempting to get the same point across.

Clear and frequent communication is required by code as well as people. XP practices such as simple design, refactoring, pair programming, and test-driven development (TDD) help define a simple system architecture that is understood by the team and represents the domain that the model is based on.

• Simplicity: Albert Einstein had it right he said, "Make everything as simple as possible, but not simpler." Simplicity is an art form. Keeping the code simple means doing what is required and nothing more, rather than over-complicating things that may never be needed. The value of having a simple code base is that it enables developers to quickly understand and work with the code, which in turn enables features to be added and modified easily and quickly.

• Feedback: Feedback is an essential part of XP programming and it can come in various flavors. Feedback is important when working with the code base to ensure that it is not broken when making a modification. This is achieved through TDD and a continuous integration process. Feedback is also valuable when demoing working code to a customer. The customer’s feedback can be integrated into the code right away, or added to the next iteration. Having customers sit with the team allows constant feedback to happen. Finally, feedback from the rest of the development team is crucial in XP. Team feedback can help validate system design decisions and ensure the design remains simple. Feedback from the team via pair programming enables knowledge sharing and increased technical excellence; for when a member of the team learns a new technique, she can share it. Team feedback is enabled by the team sitting together, which is an XP practice that you will read more about later.

• Courage: Last, but certainly not least, courage is a must. The XP methodology empowers developers to self-organize and estimate their work; and to be honest and transparent with estimates and roadblocks. To have courage opens the possibility of failure; but the key is to fail early, change course, and continue along the path to success. Courage is needed for developers to leave preconceptions behind when they start a project. Thus they are able to embrace new ideas and come up with the simplest design for the project they are working on, rather than (for instance) trying to reuse a design that is familiar from a previous project.

The project management methodology of XP, as you’ll see, is very similar to Scrum; we will discuss similarities. Now let’s take a look at the practices of XP, which can help you achieve an agile software development process.

Source of Information : Pro Agile .NET Development with SCRUM

Code Library

Categories