| COLUMN |
Even Shatner says development needs to be flexible |
 |
By Michelle Davidson
09 Jun 2008 | SearchSoftwareQuality.com
|
|
|
|
Michelle Davidson,
Site Editor |
|
Last week I had the opportunity to attend the IBM Rational Software Development Conference where IBM rolled out parts of its Jazz platform for developer collaboration and disclosed an emerging effort to connect diverse development tools.
Attendees were also treated to a keynote address by William Shatner, one of the world's most beloved sci-fi actors. (His presence fit well with IBM's theme of "Where Teams R Heroes.") Can Shatner teach us anything about building quality software? Maybe not, but he (or his script writer) was able to draw some parallels between software development and movie creation in an entertaining way:
- Both software and movies can fail
- Both need good project management
- Both require skilled team members
- Both need those team members to work together
- And both need flexibility
>
The fact that software developers need to be flexible -- or agile -- was one of the main points I took away from the conference. Everyone is talking about Agile software development. (Heck, even Dilbert's pointy-haired boss knows about Agile.) People sing its praises for, among many things, being flexible. Through frequent iterations you can better adapt to what stakeholders really want.
But people also say that you need to be flexible when adopting Agile development. First, when starting out with Agile development, don't attempt to do all projects following an Agile method.
"Do some pilots -- some small projects," said Scott Ambler, Practice Leader for Agile Development, Rational Software. "Do something that's real, but don't bet the farm. And realize that it's a multi-year effort."
More than that, Agile practitioners say you need to be flexible when implementing practices. You don't need to follow the Scrum or XP process line for line -- especially if you're getting push back from your executive manager or stakeholders.
For example, stakeholders may insist that there be a strict signoff at the end of the requirements phase. But there are several agile practices you can apply from a development and testing perspective than from a planning perspective. Pick those practices that you can use and can demonstrate do indeed work.
That reasoning goes along with what Ivar Jacobson, founder of use cases and father of UML, says about adopting practices rather than full-blown processes. Ivar spoke with managing editor Jack Vaughan about this recently and also gave a presentation about it at the Rational conference.
"No one likes processes, but there are practices to help you," he said during his presentation. "Your process becomes what it is based on the practices you select. You need a practice architecture."
You should also be aware that agile practices on one project may not work on other projects. And not all agile projects are successful. Poor management can bring down Agile projects just as effectively as traditional projects. You may have to throw in the towel on a project that cannot be saved.
|
|
|
|
