Comments on: Agile vs. Usability? http://blog.franktrindade.com/2008/11/25/agile-vs-usability/ Agile, software and some non-sense Thu, 17 Jun 2010 09:41:19 +0000 hourly 1 http://wordpress.org/?v=3.0 By: Does it Really Work? | Agile Software Development http://blog.franktrindade.com/2008/11/25/agile-vs-usability/comment-page-1/#comment-371 Does it Really Work? | Agile Software Development Thu, 05 Mar 2009 08:40:27 +0000 http://blog.franktrindade.com/?p=118#comment-371 [...] point goes back to the Agile Vs Usability discussion and it is very correct IMO, because it reiterates that development teams should not [...] [...] point goes back to the Agile Vs Usability discussion and it is very correct IMO, because it reiterates that development teams should not [...]

]]> By: jacksguides.com http://blog.franktrindade.com/2008/11/25/agile-vs-usability/comment-page-1/#comment-326 jacksguides.com Tue, 24 Feb 2009 10:51:57 +0000 http://blog.franktrindade.com/?p=118#comment-326 I think this article is true of waterfall as well. It is more about the people doing the work than the process surrounding. In an agile methodology you would finish the iteration and present to the customer for testing/comment. Wether waterfall or agile, running to the customer for clarification on any little thing is down to the individuals and probably a 'cover your backside' approach. Regards, David I think this article is true of waterfall as well. It is more about the people doing the work than the process surrounding. In an agile methodology you would finish the iteration and present to the customer for testing/comment. Wether waterfall or agile, running to the customer for clarification on any little thing is down to the individuals and probably a 'cover your backside' approach. Regards, David I think this article is true of waterfall as well. It is more about the people doing the work than the process surrounding. In an agile methodology you would finish the iteration and present to the customer for testing/comment.
Wether waterfall or agile, running to the customer for clarification on any little thing is down to the individuals and probably a ‘cover your backside’ approach.

Regards,
David
I think this article is true of waterfall as well. It is more about the people doing the work than the process surrounding. In an agile methodology you would finish the iteration and present to the customer for testing/comment.
Wether waterfall or agile, running to the customer for clarification on any little thing is down to the individuals and probably a ‘cover your backside’ approach.

Regards,
David

]]> By: lixo.org :: Balances between agile and usability http://blog.franktrindade.com/2008/11/25/agile-vs-usability/comment-page-1/#comment-230 lixo.org :: Balances between agile and usability Thu, 27 Nov 2008 23:05:13 +0000 http://blog.franktrindade.com/?p=118#comment-230 [...] second reason UI design and usability get overlooked, and this is the one Frank alludes to in his latest post, is that some agile teams rely a bit too heavily on the stakeholder’s descriptions of what is [...] [...] second reason UI design and usability get overlooked, and this is the one Frank alludes to in his latest post, is that some agile teams rely a bit too heavily on the stakeholder’s descriptions of what is [...]

]]> By: Rafael http://blog.franktrindade.com/2008/11/25/agile-vs-usability/comment-page-1/#comment-227 Rafael Wed, 26 Nov 2008 13:46:14 +0000 http://blog.franktrindade.com/?p=118#comment-227 Very good point! It's all about the old way people find to protect themselfs from their clients. How crazy! Very good point!
It’s all about the old way people find to protect themselfs from their clients. How crazy!

]]> By: marc http://blog.franktrindade.com/2008/11/25/agile-vs-usability/comment-page-1/#comment-226 marc Wed, 26 Nov 2008 04:51:48 +0000 http://blog.franktrindade.com/?p=118#comment-226 “let’s ask the client..”. Excellent stuff. The truth is that it is rare for the client to know what they really want. Their perception of the UI is clouded by either their current application or website, or their competitors products and a need to maintain functional parity. Ask the client how it should look and behave and the chances are you'll build another mediocre product with mediocre usability. “let’s ask the client..”.

Excellent stuff. The truth is that it is rare for the client to know what they really want. Their perception of the UI is clouded by either their current application or website, or their competitors products and a need to maintain functional parity. Ask the client how it should look and behave and the chances are you’ll build another mediocre product with mediocre usability.

]]>