Starting Extreme


So, what is Extreme Maintenance? It is following the XP model while a product is in the mainstream of its product life cycle [Moore1999]. If we look at what the Orbix Generation 3 experience has shown us about Extreme Maintenance, we can highlight the following key elements.

The Stories

Solving the visibility problem was key to moving beyond the gains in productivity realized by the projects detailed in the section Initial History of Change. The stories and the tasks that were identified or created needed to be visible to everyone. The storyboard with the cards is an important element of the approach we have taken.

Discussing the stories and tasks is important, but the real value in the stand-up meeting is that it coaxes people to talk about what they are doing and about some of the approaches they are taking. It's an essential lead-in to a future conversation.

In general, bug-fixing tasks for teams should be completed as two-week pieces of effort. If, after analyzing an issue, an engineer gives an estimate of more than two weeks, they need to split the story into several tasks. Anything more is a refactoring project and should be structured more along the lines of an enhancement, with clear incremental delivery of functionality based on tasks extracted from the original customer stories.

Prioritization of the fixing and enhancement is managed from a highly visible queue from which everyone can take their next task. The customer should manage the work of prioritizing. In most maintenance situations, this is the customer services organization.

We use an online queue that is available globally across our development and customer services sites. Kent Beck has suggested having a Web-accessible digital camera positioned so that people can regularly look at and zoom in on the storyboards. We are thinking about that one.

Testing

Automation is essential. Any engineer must be able to build the entire product or system and run the test suite to get immediate feedback on changes made. Nightly builds are a reasonable intermediate step to this test-on-demand requirement.

A reproducible test case must be available before detailed analysis begins and a fix implementation is provided. Testing before you fix ensures that whatever you do, you have solved the problem.

Pairing

Pair programming in XP is critical to improving collaboration and greatly facilitates mentoring and improvements in engineering practice. However, it is also one of the hardest things to get engineers to agree that it is useful and that they should sign up to make it part of their work practices. We are currently trying to get that buy-in. Until we do, we have asked each engineer to take on one or two tasks each quarter, in which they pair with another team member. We'll note which ones they paired on and then show them the data at the end of the quarter. We think it will reinforce the results we got from our initial experiment with pairing.

Team Environment

A maintenance team environment should be a mixture of personal and team space to enhance the interactions and collaborations that should occur within the team. We suggest starting by simply eliminating some of the typical cubicles and moving tables and some casual furniture into the resulting space.

Community workstations should be of the highest specification possible and should be made available specifically for pair programming and code reviews.

Feedback and Refactoring

Analyzing bug statistics is essential to identifying areas of code that need to be refactored. This form of customer feedback is an important part of targeting improvements and stopping code entropy.

Refactoring should always be on an engineer's mind when analyzing a problem or an enhancement request. The engineer should wonder, "How can I make this area of the code work better?" as opposed to "How can I get this problem fixed quickly?" (the Band-Aid approach). We give our engineers a lot of freedom to replan an enhancement or bug fix and to turn it into a refactoring effort. For some customer issues, we cannot afford the time to do the refactoring effort because of commitments to restore times. However, it is part of the process that engineers, along with analyzing a problem, identify whether the area of code they are working on is a candidate for refactoring.



Extreme Programming Perspectives
Extreme Programming Perspectives
ISBN: 0201770059
EAN: 2147483647
Year: 2005
Pages: 445

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net