Seminário de Engenharia de Usabilidade

Seminário de Engenharia de Usabilidade Desenho Centrado no Usuário (UCD) e Extreme Programming (XP) Alunos: Eduardo Gustini Flávia Fradico Ludmila Roizenbruch Tiago 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.

UCD Os 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;

UCD Alé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 de 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?

UCD Considere 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:

UCD • Alteraçã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;

UCD Alé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.

UCD Tudo é 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...

UCD A 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:

UCD • Usuá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?

UCD Nenhum 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

Seminário de Engenharia de Usabilidade