Re: [agile-usability] Valuing stories
- On Sun, Sep 6, 2009 at 3:52 AM, Biju vv<biju_v_v@...> wrote:
>The best practice is probably not to do wireframes. Or, at least, to
> Can anyone point the best practices followed in coming with wireframes with
> minimal re-work during the sprint.
spend very little time on very basic wireframes and let the design
evolve over time.
The problem with wireframes is analogous to the problem with UML
designs. They aren't working software, and there is a tendency to
over-design with them. e.g. The navigation goes here (What
navigation?) The help button goes here (What help button?) Etc.
The desire to create a complete design before you have working
software is similar to the desire of many programmers to design an
entire SOA/J2EE stack before creating a web page. As an Agile
programmer I know that I can just throw up a page, and if I need
SOA/J2EE I will be able to find it later.
To be successful in an Agile environment designers need to embrace the
same values that programmers do. It is only necessary or desirable to
develop the parts of the design that are specific to the story at
hand. So, in early stories designers will be thinking about what
colors to use, when should an alert pop up? What kind of control
should we use that will make sense to the user? Etc. Later, when the
system begins to evolve, they will be able to worry about how the new
pieces fit into the whole system.
As far as "rework," certainly as the product evolves old elements of
the design will be supplanted by new ones which means that things that
were written earlier may have to change. If you believe that this is
avoidable and/or that avoiding it is desirable, then I suggest you go
back to RUP, waterfall, or whence ye came. If, on the other hand, you
recognize that there is value in being able to change your mind to
meet the customer/market then you should call it what it is - it's not
"rework," it's refinement.
- On 6 Sep 2009, at 21:27, Hassan Schroeder wrote:
> On Sat, Sep 5, 2009 at 8:31 PM, William Pietri<william@...>I think that they're probably an orthogonal dimensions myself. I've
>> .... In fact, teams are doing design all the time. The choice
>> isn't between designing and not designing; it's between designing
>> and designing poorly.
> Or between designing consciously and designing unconsciously,
> the latter being fairly close to "not designing" :-)
met people who make very good decisions about the design of the code/
ux - but are not really able to articulate the reasoning behind them
This can be problematical since their decisions can sound arbitrary to
others - even when they're really good decisions.
http://quietstars.com - twitter.com/adrianh - delicious.com/adrianh