Seminário de Engenharia de Usabilidade
Desenho Centrado no Usuário (UCD) e Extreme Programming (XP)
Alunos:Eduardo GustiniFlávia FradicoLudmila RoizenbruchTiago Alberione
Práticas do XP
XP
A equipe está bastante entusiasmada com as
melhorias que obtivemos no nosso processo de
desenvolvimento com o uso do XP. Porém, os usuários
nem tanto. Estamos com os serviços de suporte técnico
sobrecarregados.
UCDOs processos ágeis estão muito
focados em tornar as coisas melhores para a equipe, mas não
têm muito a oferecer aos usuários. Apesar de utilizar conceitos que
facilitam o trabalho de desenvolvedores (como orientação a objetos), não há muito esforço em entender as reais necessidades do usuário e nada é falado a respeito
de testes de usabilidade.
XP
Mas nós temos um representante de usuário na nossa
equipe. Isso não ajuda?
UCD
Isso é melhor do que não ter contato com os usuários, mas não significa entender as reais necessidades deles. Para isso,
nós usamos a análise de contexto. Os usuários que vocês
possuem nas equipes quase nunca são representativos. Eles
podem:
UCD
Ser especialistas no domínio da aplicação;
Não possuirem bom relacionamento entre os colegas
e a gerência;Ser os mais competentes
tecnicamente;Ser os mais bem localizados
geograficamente;
UCDAlém disso, depois de algumas
semanas na equipe, mesmo que fossem representativos deixariam
de ser,porque:Ficariam muito familiarizados com os aspectos técnicos do
projeto;Seus interesses pessoais
poderiam influenciar na solução proposta;
Poderiam se esquecer como seria utilizar o software sem
ajuda e com pouco conhecimento.
UCD
Com a Análise de Contexto Análise de Contexto de Usode Uso, garantimos entender quem são os usuários, suas
motivações, responsabilidades, tarefas, frequência, importância,
ambiente físico e social, etc.
XP
Como esse tipo de informação influenciaria
no que estamos desenvolvendo?
UCDConsidere por exemplo um ambiente com interrupções frequentes. Existem várias
soluções potenciais:Garantir constante feedback para que o usuário possa continuar de
onde parou;Permitir que informações incompletas sejam salvas;
Permitir que muitas atualizações possam ser feitas ao mesmo
tempo;
XP
Mas você não está falando de
interfaces? Por que não podemos nos
preocupar com isso mais tarde?
UCD
O que geralmente acontece é que a equipe só percebe que a interface está muito complexa
em uma fase avançada do desenvolvimento, o que poderia
ser evitado com os testes de usabilidade. Isso poderá causar várias alterações na arquitetura
e gerar muito retrabalho.
XP
Nós usamos um processo ágil para permitir que mudanças
sejam absorvidas com facilidade. E você está
dizendo que a interface deve estar bem definida o quanto
antes.
UCD
O refactoring do código, utilizado por vocês, só causa
impacto para a própria equipe. Porém, alterações na
interface em uma fase em que ela já foi liberada para os
usuários deve ser feita com cuidado, pois causa um
grande impacto. Os primeiros efeitos colaterais dessas
alterações são:
UCDAlteração de documentação e
helps;Tempo despendido pelos usuários tentando achar ou entender a funcionalidade
alterada;Tempo gasto pelos usuários
com erros devidos às mudanças;Aumento de chamadas de
suporte técnico;
UCDAlém disso, existem as
consequências intangíveis, como:
Frustração e stress dos usuários;
Falta de confiança e medo da mudança;
Perda do controle pelo usuário;Resistência às mudanças.
XP
Mas nós permitimos que a equipe altere as interfaces de usuários quando necessário,
sem maior planejamento. Não sei se podemos controlar isso utilizando um processo ágil.
UCD
Uma forma de fazer isso é, uma vez determinado o contexto de
uso do software, identificar atores e construir um modelo
conceitual a partir das estórias de usuários. Definir atores é um
caminho poderoso para identificar tipos de usuários do
sistema e caracterizá-los de forma que a equipe possa
gerenciar suas necessidades e expectativas.
XP
Vale mesmo a pena o esforço de definir atores? Isso parece burocrático.
UCDTudo é uma questão de
perspectiva. Se a equipe não tem problemas em se colocar no lugar
do usuário, isso pode ser dispensável. Porém, o que acontece
geralmente é que a equipe desenvolve sistemas para “usuários
perfeitos”.
O usuário perfeito...
UCDA tentação é acreditar que os
usuários:Estão trabalhando em um
ambiente silencioso, organizado, sem interrupções ou distrações;Vão se lembrar de tudo que já
fizeram em um computador;Não precisam de intervalos;
Só cometem erros por desaprovação em relação à
interface;Entendem o funcionamento interno do sistema como os
desenvolvedores.
XP
Uma coisa eu não entendo. Nós já fazemos estórias de usuários, então por que os
usuários ainda reclamam do software?
UCD
As estórias de usuários descrevem o que o software
deve fazer, mas não tratam das necessidades do usuários para realizar tal tarefa. Ao escrevê-las, você deve se perguntar:
UCDUsuários reais fariam isso?
Como eles saberiam?De onde vem a informação ou o
entendimento para fazer isso?O comportamento requerido é
consistente?A estória se encaixa no fluxo de
tarefas?É razoável esperar que a estória
possa ser completada sem interrupção ou é necessário flexibilidade quanto a isso?
XP
Como fazer com a grande quantidade de
pedidos de novas funcionalidades que surgem ao longo do desenvolvimento?
UCDNenhum produto pode fazer tudo por todos os usuários e toda funcionalidade tem um
custo em termos de complexidade e usabilidade.
Adicionar dezenas de funcionalidades pode tornar a vida do usuário difícil. Por isso, a inclusão deve ser feita com cuidado e deve ser avaliado o
valor agregado e o quando isso vai afetar o modelo conceitual.
XP
Podemos economizar em outras formas de teste se fizermos o teste de
usabilidade?
UCD
Apenas indiretamente. Há muitos benefícios que você
poderá perceber, mas teste de software e teste de usabilidade são coisas separadas. Teste de software tenta garantir que o sistema faz o que a equipe
pretendia. Teste de usabilidade procura garantir que o sistema faz o que o usuário necessita.
A diferença pode ser surpreendente.
Conclusão
É importante incorporar práticas visando a Usabilidade nos processos ágeis, para garantir melhor qualidade e aceitação do software. Dentre elas, pode-se considerar:
Testes de Usabilidade; Análise de Contexto de Uso; Modelagem Conceitual.
Referências Bibliográficas Hudson, W.: Adopting User-Centered-Design within
a Agile Process: a Conversation. Abingdon, UK. Constantine, L.: Process Agility and Software
Usability: Toward Lightweight Usage-Centered Design. University of Technology, Sydney.
Kane, D.: Finding a Place for Descount Usability Engineering in Agile Development: Throwing Down the Gauntlet. SRA International