 |
|
|
|
| Michelle Davidson, Site Editor |
|
|
|
Requires Free Membership to View
When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.
Hannah Smalltree, Editorial Director
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.