Text 25580, 69 rader
Skriven 2006-12-20 22:07:04 av TOM WALKER (1:123/140)
Ärende: Religion and Technology
===============================
This from the Head of the IT Department for the Mormon Church.
Designing Software with the User in Mind!!!! WOW, What a concept.
MICROSOFT are you Listening!!

*****

Given the diverse nature of our work, we don’t take a “one size fits allö
approach to our software methodology. However, for the most part we
subscribe to some of the principles of Agile Software Development.

The misconception about Agile is that it is itself a software methodology.
It is not. Agile is a set of principles–or preferences. The basic
principles are these:

    * Individuals and interactions over processes and tools
    * Working software over comprehensive documentation
    * Customer collaboration over contract negotiation
    * Responding to change over following a plan

Many sling about the term “Agileö as an excuse to be reckless,
ill-prepared, or undisciplined in their development.

“We don’t talk about dates… we’re agile.ö
“The customer is right! If they want to grow scope they can do it… we’re
agile!ö

These are of course missing the point. “Agileö isn’t a methodology. It
isn’t a panacea. It isn’t a cure for disease. And it’s not an excuse. A
software methodology which is “Agileö will allow the developers to uncover
and solve problems in real time and will allow the flexibility to swap
scope as necessary. Delivery dates however can still be immutable, or at
least inflexible, in an Agile software methodology. Scope can still be
explored and agreed upon up front in an Agile software methodology.

I’ll give you an example. We just started working on a major revision of
one of the Church web sites. We plan to go live in Q1 of next year. We
could have spent days or weeks or even months writing detailed
specifications, getting contracts in place, negotiating, etc. But instead
we worked with the Church department to create a prototype of what they
wanted.

We employ a team of Interaction Designers who are just phenomenal. They can
sling xhtml and css with the best of them, but they are also terrific with
Photoshop. They will meet with a customer and talk through the workflow.
They’ll come back a few days later with a working prototype which allows
the customer to give feedback based on what they see and play with, not
what they read about in a 400 page document. Our interaction designers will
even dummy up data for reports giving the customer a feeling for what the
real deal will look like. When the prototype is all done, the customer can
see precisely what we will deliver to them.

The proto for this web site is now done. We’re currently working on a
schedule, and we will accurately be able to predict when we’ll be finished
and how much it will cost.

Granted, things change once users start using the system. But that kind of
change we can deal with. The changes that have been painful for us in the
past are when we get nearly done with a project only to find out we didn’t
actually understand the customer requiements in the first place. Using
protoypes as specs helps solve that problem.

I read about this approach in a book called The Inmates are Running the
Asylum a number of years ago, but wasn’t able to successfully implement the
ideas when I managed teams at Microsoft. We never seemed to have enough
Interaction Designers, or we were always in a hurry to keep developers busy
so we’d skimp on up-front Interaction Design, relegating our designers to
Photoshop technicians
--- Platinum Xpress/Win/WINServer v3.0pr5
 * Origin: Try Our Web Based QWK: DOCSPLACE.ORG (1:123/140)