Usabilidade no desenvolvimento de software

Usabilidade: é um termo usado para definir a facilidade que os indivíduos podem empregar uma ferramenta ou objeto a fim de realizar uma tarefa específica importante.

A usabilidade é uma metodologia científica, aplicada na criação e remodelação de interfaces de aplicações (sites, intranets, aplicativos, jogos e produtos no mundo Web), com a finalidade de torná-los fáceis de aprender e usar.

Um software cujo manuseio seja fácil e rapidamente aprendido, dificilmente será esquecido, que não provoque erros operacionais, ofereça um alto grau de satisfação para seus usuários e, resolva eficientemente as tarefas para as quais foi projetado, pode ser considerado um sistema com grande potencial de usabilidade. Ou seja, considerar o design de um produto não apenas pela sua engenharia óptica, mais primordialmente pela sua usabilidade e a viabilização da ‘Cultura de Uso’.

Dessa forma, percebe-se a importância do desenvolvimento de software baseado em práticas de usabilidade, visando assim uma melhor aceitabilidade destes sistemas por parte dos seus futuros usuários.

A usabilidade é entendida como uma categoria relacionada à qualidade do produto de
software e, é afetada por aspectos de outras categorias como funcionalidade, confiabilidade e eficiência.

Antigamente, a experiência do usuário (UX, de user experience), não tinha uma prioridade alta na maioria dos projetos de desenvolvimento, mas isso mudou. Hoje em dia, os usuários têm muita experiência com a Web e com software. Eles desejam um design que seja fácil de aprender e de usar e que se ajuste ao seu fluxo de trabalho.

O termo "experiência do usuário" descreve a experiência subjetiva de uma pessoa quando ela está interagindo com um produto. Diariamente discute-se a usabilidade informalmente quando relatamos uma ótima experiência em um restaurante ou uma péssima no cinema. Mas quando projetamos ou avaliamos a experiência do usuário de um produto interativo, precisamos de uma maneira mais estruturada de ver o produto e analisá-lo.

Para os designers de UX, o sucesso significa criar produtos que sejam úteis, utilizáveis e desejáveis. Para ser útil, o produto deve fornecer valor ao usuário, em termos de desenvolvimento, isso significa que o produto deve implementar a funcionalidade certa. E os produtos desejáveis são aqueles com que os usuários sonham. Quanto mais desejável for um produto, mais tempo e energia o usuário dedicará a ele.

Em geral as pessoas confundem UX com design visual, equiparando-a com cores, fontes e estética. Naturalmente, o design gráfico é um dos componentes da experiência do usuário, mas o processo de design de UX é muito mais profundo. Essencialmente, a UX consiste em como a funcionalidade é implementada em termos de interação usuário-sistema.

Enquanto o analista de negócios tende a se preocupar com o que o produto deve fazer, o designer de UX se concentra em como a função deve ser apresentada por meio da UI (user inteface). Como os usuários têm habilidades e necessidades diferentes, o designer de UX determina quais segmentos de usuários precisam ser atendidos. O designer vai reunir dados sobre os segmentos de usuários e pode criar “personas” (biografias fictícias de usuários com base em dados reais), que ajudam a concentrar as discussões durante o processo de design.

Usando entrevistas e observação, o designer de UX vai identificar as tarefas que são executadas pelos usuários, como eles abordam essas tarefas e as palavras que são usadas para descrevê-las. Esses dados podem ser resumidos como cenários, histórias dos usuários ou storyboards.
Design da interação: Define como o usuário interage com o produto. Determina o comportamento do produto em resposta às ações tomadas pelo usuário e enfoca a navegação do produto, bem como os controles específicos que são usados.

Arquitetura de informações: Define como as informações são organizadas e apresentadas.
Pesquisa de usuários: O processo de estudar os usuários a fim de desenvolver um design que atenda às suas necessidades, capacidades e preferências. Os métodos são variados e normalmente empregam algumas técnicas de entrevista junto com a observação. Também são usados registros de usuários e fontes secundárias. Pesquisas e grupos de foco também podem ser usados, embora muitos designers de UX os evitem.
Design visual: Os designers visuais podem ser artistas gráficos em vez de designers de UX. Embora o impacto visual seja importante, também é essencial que o design visual não prejudique a legibilidade ou a usabilidade.
Teste de usabilidade: O processo de observar os usuários executando determinadas tarefas em um protótipo ou uma imitação da UI. Tradicionalmente, o teste de usabilidade era realizado em um laboratório com os observadores atrás de um espelho. Contudo, cada vez mais, os testes de usabilidade estão usando tecnologia de webcast.

Sinergia com a metodologia ágil

Sob o ponto de vista conceitual, os motivos para a criação de uma boa UX são aumentar a eficácia e a eficiência, reduzir a sobrecarga e a reformulação do desenvolvimento e agregar o maior valor possível, seja para operações internas ou para clientes externos.

Não é eficaz pedir que os usuários determinem o que o sistema deveria fazer e de que modo. Essa abordagem coloca nos usuários a carga de traduzir suas próprias necessidades para o que eles acham que o software deveria fazer, restringindo a descoberta de alternativas melhores, que um designer ou um desenvolvedor seriam capazes de sugerir.

O design centrado no usuário (UCD, user-centered design) agrega valor ao enfocar o entendimento das pessoas — seus objetivos, suas tarefas e suas atividades — e usando esse valor como a base para a criação.

Sob o ponto de vista prático, existe muita sinergia com a metodologia ágil. Ambas são essencialmente iterativas. Ambas exigem a colaboração constante das pessoas.
Mas lembrem-se: quem desenvolve não está apto a testar a usabilidade da aplicação desenvolvida.

Em breve mais sobre usabilidade.

Aquele abraço.

Fonte:http://msdn.microsoft.com/
http://www.scriptfacil.com.br/
http://www.ufpa.br

Fixe o prazo e o orçamento, flexibilize o escopo

Olá amigos, estou lendo um livro chamado "Getting Real" (Caindo na Real), o livro aborda o desenvolvimento ágil de software. Vou compartilhar com vocês um trecho bem interessante.


Fixe o prazo e o orçamento, flexibilize o escopo


Lance dentro do prazo e do orçamento

Aqui vai uma maneira fácil de lançar dentro do prazo e do orçamento: mantenha-os fixos. Nunca jogue mais tempo ou dinheiro em um problema, apenas diminue o escopo.

Existe um mito que diz o seguinte: podemos lançar no prazo, no orçamento e no escopo. Isso quase nunca acontece e quando acontece a qualidade normalmente sofre.

Se não puder encaixar tudo dentro do prazo e orçamento planejados então não aumente o tempo e o custo. Em vez disso, puxe o escopo para trás. Sempre existe tempo para adicionar coisas mais tarde – o mais tarde é eterno, o agora está voando.

Lançar alguma coisa grande que está um pouco menor em escopo do que o planejado é melhor do que lançar alguma coisa medíocre e cheio de buracos porque precisou atingir uma janela mágica de prazo, orçamento e escopo. Deixe a mágica para Houdini. Você tem um negócio de verdade para administrar e um produto real para entregar.

Aqui vão os benefícios de fixar o prazo e orçamento e manter o escopo flexível:

Priorização
Precisaremos descobrir o que é realmente importante. O que vai chegar ao lançamento inicial? Isso força uma restrição que o pressionará a tomar decisões difíceis em vez de ficar hesitando.

Realidade
Configurar expectativas é a chave. Se tentar fixar o prazo, orçamento e escopo, não será capaz de entregar com um alto grau de qualidade. Claro, provavelmente poderá entregar alguma coisa, mas “alguma coisa” é o que realmente quer entregar?

Flexibilidade
A habilidade de mudar é a chave. Ter tudo fixado torna as mudanças difíceis. Injetar flexibilidade de escopo apresentará opções baseadas em sua experiência real de construir o produto. Flexibilidade é seu amigo.

Nossa recomendação: abaixo o Escopo. É melhor fazer meio-produto do que um produto meia-boca (mais sobre isso depois).

Um, dois, três...

"Como um projeto chega estar um ano atrasado? Um dia de cada vez." - Fred Brooks

Trecho do livro: Getting Real - 37signals

Versão completa em português.

Kanban no desenvolvimento ágil de software by Dilbert.

Fonte: Universitários de POA

WORKSHOP - SCRUM

Olá, gostaria de convidá-lo a participar de um evento que vamos ministrar referente a SCRUM.

O treinamento tem como principal propósito, introduzir os profissionais ao mundo dos métodos ágeis e prepará-los para a curva de aprendizado que envolve esse meio. Entender porque os métodos ágeis têm recebido tanto destaque nos últimos anos, e como aplicar de forma prática a teoria em ação.

Durante o curso, os participantes irão entender de forma simples e direta como uma framework pode transformar os resultados de uma empresa, além de aprender como aplicar SCRUM em diversos tipos de projetos independente da segmentação e área de negócio.

Por fim, com este treinamento o aluno terá uma clara percepção da essência dos métodos ágeis: seus valores e princípios.

Inscreva-se: Clique aqui

Papéis no SCRUM.

No Scrum existem 3 papéis principais:

Product Owner

Comumente o cliente ou o gerente de um projeto maior. As suas principais responsabilidades são definir as funcionalidades, os prazos, estabelecer as prioridades de entrega, ajustar prioridades e funcionalidades e, por fim, aceitar o produto entregue.

Scrum Master

Responsável pela aplicação do Scrum na equipe. Remove obstáculos à conclusão dos trabalhos, controla o bom andamento das atividades e acompanha a aplicação das funcionalidades e a qualidade do que está sendo produzido. Atua como ponto de contato entre a equipe, os clientes e a gerência do projeto.

Equipe

Geralmente entre 5 a 10 membros. Inclui perfis multidisciplinares e auto-gerenciáveis (desenvolvedores, designers, testadores, analistas, arquitetos), que atuam em tempo integral no sprint.

O pontapé inicial para a definição de um sprint é o seu planejamento. Itens como capacidade de equipe, o backlog, tecnologia atual e funcionalidades são levadas em consideração por toda a equipe.

Nesse processo, é gerada a priorização do backlog e o plano, as diretrizes de como a equipe irá chegar ao seu objetivo final. O principal artefato gerado por essa etapa é o sprint backlog. Já formatado e com as devidas priorizações, responsáveis, tempos e datas de entrega.

Com o sprint backlog gerado, a equipe já pode começar a trabalhar nos produtos. Diariamente e feita uma reunião informal (preferencialmente com todos de pé) de cerca de 15 a 20 minutos, onde a equipe pode colocar ao Scrum Master os obstáculos que encontraram para a conclusão de suas atividades do dia anterior.

É importante salientar que essa reunião não deve servir para discussão de funcionalidades ou problemas alheios às atividades do dia anterior em si, para não perder sua essência e foco.

O gerenciamento de cada sprint é feito pelos próprios membros da equipe. Qualquer membro dela pode modificar, incluir ou eliminar tarefas e cada um fica responsável por escolher quais tarefas irá executar e atualizar diariamente as horas gastas e a estimativa de horas restantes para conclusão das atividades.

Ao final do sprint é celebrada uma reunião de revisão, onde a equipe apresenta os resulatados obtidos durante o sprint. Nessa reunião, que é informal e sem grandes apresentações, todo o time participa e discute os progressos e os problemas encontrados, onde pode-se planejar de forma mais efetiva para atingir os resultados do próximo sprint.

Fonte: http://webinsider.uol.com.br

Quer aprender mais sobre o tema? Clique aqui