| By Troy Holmes |
Article Rating: |
|
| February 15, 2005 12:00 AM EST |
Reads: |
46,040 |
Key Concepts of XP
This methodology is designed around the typical common sense approach to development; however, these fundamentals are outlined in detail to ensure your understanding and to highlight their importance.
Planning
Planning is the cornerstone of any project's success. During the planning cycle, it is important to communicate with the customer to determine the scope and the schedule of the project. These two factors are used in your typical triangle approach (scope, schedule, resources) and will help to determine which elements have a higher priority. This information will then be used in laying out the release planning. One of the fundamental differences in the planning phase used in XP is the implementation of user stories as a way of capturing use cases. User stories are written by the customer and are simple requirements that must be met by the software. It is important to note that user stories captured during the planning phase should be high level and should not include any technical jargon. In addition, stories should be small enough to implement in no more than three weeks. These stories should not be longer than a few sentences and should provide enough detail for the developer to estimate the time required to implement. During development, the programmer should ensure the understanding of the user story by communicating his or her version of the implementation with the customer. This information will be used to generate acceptance test code, thus making sure that customer requirements are met.
Designing
The design phase should be a time to validate overall functionality while also focusing on the details of the individual user stories. One of the key concepts to keep in mind during the design phase is to keep it simple. It is extremely important that developers do not add unnecessary complexity during the initial design. XP promotes the idea of refactoring code; refactoring should be an integral process, shared by all developers during development of the software. Therefore, a simple approach is the best approach for initial design. It is also important to outline naming standards during the design phase. At this stage, it will be easier for developers to agree upon and understand the naming conventions. It is important to select names that all team members can relate to without learning detailed business rules. This will ensure a quicker understanding of the overall system.
One of the pillars of the XP design process is collaboration. It is critical that collaboration meetings are held. This is referred to as Use Class, Responsibilities, and Collaboration (CRC) sessions in XP speak. During this time, the developer of an individual component will explain how his or her object will communicate with other objects in the system. This will provide a means to quickly uncover problematic issues and shortcomings in the design. The CRC sessions are written on cards that can quickly be converted into collaboration diagrams if a more permanent record is required.
Coding
The key difference in coding with the XP methodology is communication with the customer. During the coding effort, developers should never try to guess or implement solutions they think meet the requirements of the user story. Instead, they should talk to the customer. This is why XP works. If the developer does not fully understand an implementation, he or she should feel confident in explaining and validating his or her understanding with the customer.
Another key difference is the priority placed on testing. During the coding phase, the developer should always build the test case first, even if the test case is only a written process that can be implemented into a testing tool. Creating the test case first makes it easier to write the code to pass the test case. In addition, because several of the test cases are captured in the user stories, the individual module should be very close to the customer requirements. Another benefit of creating test cases is that it provides an understanding of how the code works. This also means that other developers can ascertain how the code works by reading the test cases.
One of the problems people have with XP is pair programming. This is because it is different. Developers have a strange ownership issue when it comes to code, and XP tries to break that trend. Remember, the code is written to be rewritten, especially if the refactoring rule is upheld. Therefore, it should be natural for two people to work on the same module. Also, having two people per module will make the system better, because it is built using collaboration. Obviously, only one person can type at a single moment, but more thinking is involved during coding than in actual typing. When developers are having issues with a particular implementation, they have an extra brain to utilize. In addition, two developers are more likely to capture issues and voice concerns to each other, whereas single developers tend to make an educated guess and move forward.
The final component during the coding phase of XP is ensuring no overtime. Several articles have been written about the effects of overtime on a project. Using overtime to complete a project's task tends to tire the team and leave them more prone to making mistakes. Overtime brings down overall moral and provides little if any benefit to the final release. XP provides a mechanism by which to communicate with the customer. Instead of forcing overtime on the team, the release plan should be modified or the scope should be reduced for the current iteration.
Testing
Testing in the XP methodology is one of the main things that sets it apart from other methodologies. Of course, all methodologies require the testing phase. In XP, however, the team thinks about testing from the beginning straight through to the end of the system life cycle. Tests should be automated and included with the actual code. Testing should be completed before the code is integrated and test suites should be created that test all classes and methods within the entire system. The automation of testing is critical because as the system date approaches, manual tests will be cut short. By implementing testing automation, all tests can be replicated and regression testing can be completed quickly and easily in the maintenance phase of the system. By requiring that all code pass all tests before it is implemented, the development team is ensuring a higher-quality product. Any bugs found during testing should become additional unit tests. Another key difference in testing is that acceptance testing scores should be published. This enables a higher level of quality assurance. The customer will have the ability to review the test results and prioritize the issues found during testing.
Subscribe to JAVA Developer's Journal Email News Alerts
Subscribe via RSS
