Coming from a land where good design means: ease-of-use, thinking ahead, and making damn sure that an egg dropped from a five story building doesn't break, I've found a few challenges with the idea of Agile Development.
I understand the basic concept - reduce, reuse, recycle.
Reduce: the time it takes to have workable software, and unnecessary functionality, Reuse: user paradigms and code when appropriate, Recycle: hmmm... not sure how this one really fits, but I can stretch it to say - Cycle through the process over and over again with stakeholders.
Of course I'm oversimplifying the process. There's a complete philosophy that goes behind this. There's even a 42 point Agile test developed by Nokia that one can take to see if the team's in-line with Agile.
For me, it's like the land of OZ. Dorothy strutting down the yellow brick road of software development, not sure what direction it's headed, or who the man behind the curtain really is.
One of the main focuses of Agile states, “Business people and developers must work together daily throughout the project”. I'm not really sure where that leaves me - the designer. It's always been my job to find out what the client wants, and communicate it in a term that the developers can understand. I've had developers say to me outright "I don't actually like people". I don't mean to overgeneralize, but the personality type tends to fall into this space. I believe that programmers love programming, not chit-chatting with clients about how they feel about "this or that".
Let's face it, the clients are the ones that are going to be using the software, so there should be a good line of communication with them... and sometimes a picture is worth a thousand words (or a thousand lines of code). Good design is building to what a client needs. I'm not saying that we go down the path of the document heavy UCD process, but what I am saying is that high-level wireframes should be done to understand the flow of the software. We must understand the ultimate goal of what the client wants to achieve - that should not change throughout the course of development.
Agile is supposed to be aimed at giving the client a way of having "checks and balances" as the software is developed. It's meant to get something that is "deliverable" at each phase of its existence. It is an effective way of producing software. The problem that I see with clients driving, is that sometimes they are unsure of what they want, or how to explain it.
Most people are used to shopping for something they need and they don't know what that is until they see it. Some people value objects with good design, and some don't. I think that what we need to be aware of with Agile, is that we should use design where it is needed, and not simply throw it out the window because it uses too much documentation and is too focused on strategy.
Faster to market, quicker return on investment, less-expensive; let these not be the main foundations of Agile, lest we end up with the plastic chair from Walmart that breaks because it was rushed out of the factory before anyone did a study on how wide the American fanny is.
No comments:
Post a Comment