seminário de engenharia de usabilidade desenho centrado no usuário (ucd) e extreme programming...

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