SIGIA-L Mail Archives: RE: SIGIA-L: Extreme Programming v. Inte
RE: SIGIA-L: Extreme Programming v. Interaction Design
From: William Pietri (william_at_scissor.com)
Date: Fri Jan 18 2002 - 14:16:17 EST
Howdy, folks. I'm not a regular follower of this list; a friend forwarded
me this thread and I thought I'd drop in to give a geek's perspective on
why I think XP and a focus on usability are not incompatible.
For those who don't know much about XP, I should explain that it is a
short-cycle iterative process, depending mainly on communication and
feedback (as opposed to documents and ritual). One important difference
from most other methods is that it explicitly focuses on getting the
developers to work as a team. The "short-cycle iterative" part means that
at the end of every 1-3 week iteration, a working system will result
(although at first, of course, it will be minimal).
At the end of every iteration, the developers and the customer sit down and
negotiate what work will be done in the next iteration. It is a firm rule
that the business folks (collectively called 'the customer') get to make
all business decisions (especially what to make); the geeks get to make all
technical decisions (especially their estimates of how much work a
requirement will take). Both sides are expected to support and advise one
another to achieve the common goal.
In this thread I've noticed a few objections to XP. Let me tackle them first:
o "XP is focused on coding, and ignores a lot of important things necessary
for business success."
This is basically true. If you are looking for a holy grail, this is a
black mark against XP. Personally, I think it's a plus; experience has
taught me suspicion of of all-encompassing solutions. For the issues that
XP addresses, I think it handles them very well.
o "XP gives the customer what they want, but what customers want is often
different then what they need."
Again, this is true. Figuring out this difference between what somebody
wants and what they truly need is outside the scope of XP. (Indeed, it
strikes me as one of the core challenges in life.)
This doesn't mean, however, that developers are supposed to mindlessly
build garbage; the expectation is that the developers will advise the
business folk to the best of their abilities. But it does mean that the
final authority (and the final responsibility) for the requirements lies
with the business. Wise customers will make sure that what they order has a
reasonable chance of being what they need.
XP's iterative nature also allows for quick feedback to help the customer
tell the difference, and it reduces the cost when they are wrong. One of
the biggest problems with the traditional waterfall process is that
developers can spend 18 months building something that is theoretically
appealing but useless in practice. With new versions delivered every couple
of weeks, it's much easier to tell bad ideas from good ones.
o "There's no explicit place for usability in XP!"
This is certainly true, but I think there's an implicit place. Or rather,
several implicit places. I'll discuss that below.
o "There's no design in XP!"
This is false. There is no design *phase*; design happens all the time.
Like quality, good design is a pervasive concern, and therefore deserves
continuous attention. As a practical matter, people who practice XP are
very interested in good design.
Full disclosure: There is a hidden philosophical assumption at the heart of
XP. It's that it is in practice impossible for a perfect design to spring,
like Athena, fully formed from the forehead of its designer. Instead, the
implicit belief is that any good design is the result of persistent
evolution. XP's short iterations allow the feedback necessary for that
evolution.
o "We must design up front, because once programmers start going, changing
direction is impossible!"
This is true with most traditional processes. XP, like all the other
methods known as "agile processes", starts with the assumption that
continuous change is a given. XP has a number of geeky techniques to make
sure the code stays flexible.
Since most people have been burned by the rigidity of code produced with
traditional techniques, the amount of flexibility you get from XP is
literally inconceivable at first. My personal experience is that using
traditional methods code becomes less flexible over time; with XP, it
becomes more flexible, more accommodating to new requirements. Had somebody
told me this before I had tried XP, I would have though them a raving lunatic.
o "XP doesn't produce documentation!"
This one is also false. Developers are encouraged to document anything that
they think needs documenting. (Personally, I document quite a bit.)
Customers are allowed to require any documentation that they want. But XP
doesn't mandate any particular documentation.
Once you've tried XP for a while, you discover that a lot of the
documentation you thought was vital to success really isn't. If you have
the customer on-site (an XP requirement) then you don't need a big
requirements document; you just turn and ask what you need to know. If the
customer can see working software delivered weekly, ornate GANTT charts to
demonstrate progress become less helpful. And for a number of reasons, the
code produced by XP teams needs relatively little internal documentation,
and what it needs it tends to get without an artificial requirement for it.
o "Extreme Programming is a silly name!"
Amen, brother. It's really a very disciplined process, and has nothing to
do with Mountain Dew, bungie jumping, or saying "dude!" I wish Kent had
called it something perfectly boring, like "Feature Driven Development."
So now that I've gotten those out of the way, here's how I think XP and a
focus on usability go together:
Although I don't know that my thinking relates much to how you experts view
it, when I'm concerned with usability, I tend to break efforts into two
pieces. One is the skill of building usable interfaces. The other is the
pursuit of feedback from actual users on how usable the interfaces really are.
The first part is a skill that developers have in varying amounts. Because
of XP's pervasive team focus, substantial amounts of crosstraining and
knowledge sharing go on; even if you have just one developer who is very
focused on the user, his influence will be much more broad than with most
other methods. Since XP also forbids territoriality, the user-centered
developer is also free to go and improve the interfaces anywhere in the
product, whether or not he initially wrote that code.
The other part, the collection and analysis of feedback from actual users
can happen in three ways in XP. Because the XP 'customer' is often a
committee, including a representative user as part of the customer allows
developers to ask questions (not just verbally, but also via sketches,
prototypes, and any other tools that aid communication) both 1) during
requirements gathering, and 2) throughout the iteration as they build the
feature in question.
But even with the best efforts and feedback before and during construction,
non-optimal interfaces will still get built. That's why if usability is
important, the customer will 3) take the software and try it on real users
and use that information to create new requirements for the next version.
On a waterfall, this wouldn't be sufficient. But since XP produces working
versions every couple of weeks, there are plenty of opportunities to detect
and repair usability issues. The extent to which the customer decides to
take these opportunities is a business decision, not a technical one; again
that's outside the scope of XP.
So in sum, I think that given the right conditions, XP is an excellent way
to get a team of developers to build whatever you want with low risk, high
quality, and high efficiency. And if "whatever you want" includes wanting
something that's very usable, XP can work well with that. Make sure that
the development team has the appropriate usability skills, and make sure
the customer knows that they will need to test the product on real users,
not on executives.
People who treat XP as a tool, rather than a silver bullet or a religion,
will likely be happy with it. I sure am.
William
P.S. I've left out a lot of the things about XP that are very interesting
to developers, but boring to those not of my ilk. If you're left with
questions, please drop me a line.
-----
William Pietri <william_at_scissor.com>
brains for sale - http://www.scissor.com/
This archive was generated by hypermail 2.1.2
: Sun Nov 23 2003 - 22:54:59 EST
|
