Download PDF
ads:
FUNDAÇÃO EDSON QUEIROZ
UNIVERSIDADE DE FORTALEZA – UNIFOR
David Falcão Barbosa
UMA ESTRATÉGIA DE APOIO À INSTITUCIONALIZAÇÃO DA
USABILIDADE EM AMBIENTES DE DESENVOLVIMENTO ÁGIL
Fortaleza
2008
ads:
Livros Grátis
http://www.livrosgratis.com.br
Milhares de livros grátis para download.
FUNDAÇÃO EDSON QUEIROZ
UNIVERSIDADE DE FORTALEZA – UNIFOR
David Falcão Barbosa
UMA ESTRATÉGIA DE APOIO À INSTITUCIONALIZAÇÃO DA
USABILIDADE EM AMBIENTES DE DESENVOLVIMENTO ÁGIL
Dissertação apresentada ao Curso de
Mestrado em Informática Aplicada da
Universidade de Fortaleza – UNIFOR,
como requisito parcial para obtenção do
Título de Mestre em Informática Aplicada.
Orientadora: Profª. Drª. Maria Elizabeth Sucupira Furtado
Fortaleza
Junho / 2008
ads:
_______________________________________________________________________
B238e Barbosa, David Falcão.
Uma estratégia de apoio à institucionalização da usabilidade em
ambientes de desenvolvimento ágil / David Falcão Barbosa. - 2008.
180 f.
Cópia de computador.
Dissertação (mestrado) – Universidade de Fortaleza, 2008.
“Orientação : Profa. Dra. Maria Elizabeth Sucupira Furtado.”
1. Usabilidade de software. 2. Melhoria de processo. 3. Engenharia
de software. I. Título.
CDU 681.3.06
______________________________________________________________________
2
David Falcão Barbosa
UMA ESTRATÉGIA DE APOIO À INSTITUCIONALIZAÇÃO DA
USABILIDADE EM AMBIENTES DE DESENVOLVIMENTO ÁGIL
Data de Aprovação: 13 de junho de 2008
Banca Examinadora:
_______________________________________________________
Profa. Maria Elizabeth Sucupira Furtado, D.Sc.
Orientadora – Universidade de Fortaleza (UNIFOR)
_______________________________________________________
Professora Lúcia Vilela Leite Filgueiras, D.Sc.
Universidade de São Paulo - Escola Politécnica (Poli-USP)
_______________________________________________________
Professor Nabor das Chagas Mendonça, PhD.
Universidade de Fortaleza - UNIFOR
Dedico este trabalho a minha família e
amigos, que me apoiaram em todas as
dificuldades, e em especial à Nara
Barreto.
AGRADECIMENTOS
A minha mãe Beth, minha avó Zulmar e meu irmão Daniel, pela paciência, apoio e
carinho prestados durante todas as etapas da minha vida.
A minha namorada, Nara, por ser minha motivação nos momentos mais difíceis. Por
não me deixar desistir e sempre me motivar a seguir em frente, com o seu amor.
Ao meu amigo Daniel Gonçalves, pela amizade e apoio desde os tempos de graduação
e até o fim da vida. À minha amiga Ana Rafaela, pela ajuda inestimável nas traduções e pela
sua amizade de grande valia.
À minha professora e orientadora Elizabeth Furtado, por ter me apresentado a pesquisa
em 2003. Tive o prazer de ser seu orientando na época da graduação e repetir esta parceria no
mestrado. Sem suas considerações, este trabalho perderia consideravelmente sua qualidade.
Pelo exemplo de dedicação e profissionalismo. Pela paciência, pelas correções realizadas
sempre de forma tão assertiva. Por acreditar no meu potencial e no meu trabalho.
Ao SERPRO, em especial a minha gerente Sâmia Solany, pela compreensão e apoio
durante a escrita deste trabalho.
À Fortes Informática, em especial ao gerente de desenvolvimento Clavius Tales, por
acreditar na estratégia deste trabalho e não medir esforços para realização do estudo de caso
em sua organização.
Aos colegas do LUQS, em especial ao Albert e Fabrício, pelo apoio na definição da
estratégia do trabalho e participação no estudo de caso, além da parceria em todas as
atividades voltadas para a usabilidade.
À professora Lúcia Filgueiras e ao professor Nabor Mendonça, por terem aceitado o
convite de participar da banca deste trabalho.
À Josy, Marcinha e Karol, pelas horas de estudo durante as disciplinas do mestrado.
À FUNCAP, por aceitar meu projeto de pesquisa e patrocinar o meu mestrado com a
concessão de uma bolsa de pesquisa.
Por fim, a todas as pessoas que, direta ou indiretamente, contribuíram para a
realização desta dissertação, incentivando-me e acreditando ser possível a conclusão deste
trabalho.
Resumo da Dissertação apresentada ao MIA/UNIFOR como parte dos requisitos necessários
para a obtenção do título de Mestre em Informática Aplicada.
UMA ESTRATÉGIA DE APOIO À INSTITUCIONALIZAÇÃO DA
USABILIDADE EM AMBIENTES DE DESENVOLVIMENTO ÁGIL
David Falcão Barbosa
Junho / 2008
Orientadora: Profa. Dra. Maria Elizabeth Sucupira Furtado
Programa: Mestrado em Informática Aplicada
As organizações de software, buscando continuamente por um bom posicionamento no
mercado, cada vez mais tendem a identificar que o esforço desprendido para seguir seus
processos pode ser insuficiente para garantir a qualidade de um produto. Tal situação é
especialmente válida quando se considera a realidade das organizações de desenvolvimento
ágil, onde se encontram dificuldades na definição de quais atividades devem ser realizadas
sem comprometer a produtividade característica desta abordagem de desenvolvimento.
Este trabalho propõe uma estratégia de institucionalização da usabilidade, com o objetivo de
apoiar a organização na realização de uma melhoria de seus processos, baseando-se em uma
integração dos conceitos de desenvolvimento e gestão ágil, maturidade em usabilidade e
gestão de pessoas. Um estudo de caso foi realizado com intuito de aplicar esta integração na
prática. Nele, incluíram-se novas atividades na rotina das equipes de desenvolvimento e
gerentes de uma organização com foco de trabalho no desenvolvimento ágil. Os resultados
atingidos com esta experiência foram avalidados e contribuíram para uma mudança na cultura
de desenvolvimento da organização.
PALAVRAS-CHAVE: Institucionalização da Usabilidade; Melhoria de Processo;
Desenvolvimento Ágil; Maturidade em Usabilidade; ISO TR 18529; P-CMM.
Abstract of Dissertation presented to MIA/UNIFOR as a partial fulfillment of the
requirements for the degree of Master of Applied Informatics.
A STRATEGY TO SUPPORT THE INSTITUTIONALIZATION OF
USABILITY IN AGILE SOFTWARE DEVELOPMENT
ORGANIZATIONS
David Falcão Barbosa
Junho / 2008
Adviser: Profa. Dra. Maria Elizabeth Sucupira Furtado
Program: Master in Applied Informatics
Software organizations, reaching continuously for a good market position, are more likely to
realize that the effort spent to follow its processes may be insufficient to assure the quality of
a product. Such situation is specially useful when the reality from the agile development
enterprises is taken into account. In these cases, there are difficulties to define which activities
shall be carried through without jeopardizing the productivity inherent to this development
approach. This work proposes a strategy for the usability institutionalization. Its purpose is to
help organizations to perform improvement on their processes, based on the integration of
agile development and management concepts, usability maturity models and human resources
management. A study case was carried out in order to apply this integration in practice. In this
study, new activities were included on the routine of the development teams and managers of
the agile development organization. The results achieved with this experience were evaluated
and contributed for a change in the development culture of the organization.
PALAVRAS-CHAVE: Institutionalization of Usability; Process Improvement; Agile
Development; Usability Maturity; ISO TR 18529; People-CMM.
LISTA DE ILUSTRAÇÕES
Figura 2.1 - Fases do Extreme Programming, retirado de Ambler (2007) ............................... 36
Figura 2.2 - Exemplo de Cartão representando uma Estória, retirado de Nargler (2005) ....... 37
Figura 2.3 - Ciclo de vida e stakeholders do SCRUM, retirado de Demer et al. (2007) .......... 40
Figura 2.4 – Visão geral da metodologia AGILEUSE, retirada de Bernardino & Gomes
(2007). ...................................................................................................................................... 45
Figura 2.5 - Visão geral do processo CRUISER, retirada de Memmel et al. (2007) ............... 47
Figura 3.1 - Importância em Considerar Objetivos de Negócio, adaptado de Nadel (2005) ... 66
Figura 3.2 - Processos para Design Centrado no Usuário na ISO 13407 ................................. 68
Figura 3.3. Formatos de Processos da ISO TR 18529, traduzido de Jokela (2002) ................. 70
Figura 3.4 - Níveis de Maturidade x Áreas de Interesse, adaptado de Freitas (2006) .............. 74
Figura 4.1 - Estratégia de Apoio à Institucionalização da Usabilidade .................................... 94
Figura 4.2 - Resultados Esperados da etapa de Investigação Organizacional .......................... 97
Figura 4.3 - Resultados Esperados da Análise e Planejamento das Atividades. ...................... 98
Figura 4.4 - Mapeamento de Competências e Práticas versus Treinamentos ........................ 101
Figura 4.5 - Template do Plano de Melhoria em Usabilidade ................................................ 102
Figura 4.6 - Resultados Esperados da Execução do Plano de Melhoria em Usabilidade ....... 105
Figura 4.7 - Resultados Esperados da Avaliação dos Resultados .......................................... 109
Figura 5.1 - Processo de Desenvolvimento Ágil Identificado na Organização ...................... 122
Figura 5.2 - Ordem de Prioridade das Soluções para Adoção de Usabilidade ....................... 124
Figura 5.3 - Práticas de Usabilidade, Competências Requeridas e Treinamentos ................. 128
Figura 5.4 - Nova Macro-Visão, com Inclusão de Práticas de Usabilidade ........................... 132
Figura 5.5 - Uso de Cartões para Considerar Requisitos de Usabilidade ............................... 133
Figura 5.6 - Construção e Avaliação de Protótipos de Baixa Fidelidade ............................... 133
Figura 5.7 - Cartão de Desenvolvimento versus Cartão de IHC ............................................ 134
Figura 5.8 - Observação do Uso das Interfaces do Sistema ................................................... 135
LISTA DE TABELAS
Tabela 2.1 - Comparativo entre Abordagens de Desenvolvimento Tradicional e Ágil ........... 29
Tabela 2.2 - Comparativo das Integrações da Usabilidade em Processos Ágeis ..................... 51
Tabela 3.1 - Estágios de Maturidade de Produtos, adaptado de Olsen (2002) ......................... 58
Tabela 3.2 - Taxonomia dos Níveis de Pesquisa em IHC, traduzido de Parush (2006) ........... 63
Tabela 3.3 - Níveis de Capacidade dos Processos, segundo a ISO TR 18529:2000 ................ 71
Tabela 3.4 - Critérios para Classificação da Análise de Aderência dos Conceitos .................. 80
Tabela 3.5 - Análise da Aderência entre ISO TR 18529 versus SCRUM. ............................... 83
Tabela 3.6 - Análise da Aderência entre ISO TR 18529 e práticas do XP. .............................. 86
Tabela 3.7 - Análise da Aderência entre ISO TR 18529 e Estratégias de Apoio. .................... 88
Tabela 4.1 - Análise de Viabilidade de Aplicação de uma Prática de Usabilidade ................ 100
Tabela 4.2 - Sugestões de Métricas para Avaliação do Plano de Melhoria............................ 104
Tabela 4.3 - Análise de Aderência entre Práticas da Estratégia versus ISO TR 18529 ......... 113
Tabela 4.4 - Análise Comparativa entre Práticas da Estratégia versus Treinamento e
Desenvolvimento do P-CMM ................................................................................................. 115
Tabela 4.5 - Análise Comparativa entre Práticas da Estratégia versus Cultura Participatória do
P-CMM ................................................................................................................................... 117
Tabela 5.1 - Objetivos de Negócio versus Objetivos de Usabilidade .................................... 126
Tabela 5.2 - Práticas de Usabilidade Escolhidas .................................................................... 127
Tabela 5.3 - Atividades do Plano de Melhoria ....................................................................... 129
Tabela 5.4 - Atividades de Capacitação Realizadas na Organização ..................................... 130
Tabela 5.5 - Análise da Maturidade com Uso da ISO TR 18529 ........................................... 138
SUMÁRIO
LISTA DE ILUSTRAÇÕES ............................................................................. IX
LISTA DE TABELAS ........................................................................................ X
1. INTRODUÇÃO ........................................................................................... 17
1.1. Visão Geral ................................................................................................................ 17
1.2. Motivação .................................................................................................................. 19
1.3. Escopo do Trabalho ................................................................................................... 23
1.4. Objetivos do Trabalho ............................................................................................... 23
1.5. Metodologia ............................................................................................................... 23
1.5.1. Vertente Teórica ................................................................................................. 24
1.5.2. Vertente Prática .................................................................................................. 24
1.6. Organização do Conteúdo do Trabalho ..................................................................... 24
2. DESENVOLVIMENTO ÁGIL E SUA INTEGRAÇÃO COM OS
CONCEITOS DE USABILIDADE E DESIGN PARTICIPATIVO ............ 26
2.1. Introdução .................................................................................................................. 26
2.2. Comparativo entre métodos tradicionais e métodos ágeis ......................................... 28
2.3. Abordagens de Desenvolvimento Ágil ...................................................................... 30
2.3.1. Extreme Programming ........................................................................................ 30
2.3.2. SCRUM .............................................................................................................. 38
2.4. Potenciais Obstáculos entre Usabilidade e os Métodos Ágeis .................................. 41
2.5. Propostas de Integração da Usabilidade em Processos Ágeis ................................... 43
2.5.1. Agile Usage-Centered Design (AUCD) ............................................................. 43
2.5.2. Design Interativo em Processos Ágeis (AGILEUSE) ........................................ 45
2.5.3. Agile Human Centered Software Engineering (CRUISER)............................... 47
2.5.4. Análise Comparativa Entre os Trabalhos Apresentados .................................... 50
2.6. Design Participativo e sua Integração com os Métodos Ágeis .................................. 53
2.6.1. Similaridades e Diferenças entre o Design Participativo e as Práticas das
Metodologias Ágeis........................................................................................................... 54
2.7. Considerações Finais do Capítulo .............................................................................. 55
15
3. USABILIDADE COMO INSTRUMENTO DE MUDANÇA
CULTURAL E ESTRATÉGICA NAS ORGANIZAÇÕES ......................... 57
3.1. Introdução .................................................................................................................. 57
3.1.1. O Cenário Atual e os Desafios dos Profissionais de Usabilidade ...................... 59
3.1.2. Academia x Mercado: Gap de Conhecimento em Usabilidade .......................... 62
3.2. Usabilidade como Componente Estratégico nas Organizações ................................. 63
3.2.1. Comparando Objetivos de Negócio, de Usabilidade e de Usuário..................... 64
3.2.2. A Importância de se Buscar a Maturidade em Usabilidade e a Conformidade
com Normas ISO ............................................................................................................... 67
3.3. People CMM (P-CMM) ............................................................................................. 72
3.4. Estratégias de Apoio à Institucionalização da Usabilidade ....................................... 76
3.4.1. Treinamento em Usabilidade .............................................................................. 76
3.4.2. Promovendo a Usabilidade para a Organização ................................................. 77
3.4.3. Medir para Justificar os Investimentos em Usabilidade ..................................... 78
3.5. Análise de Aderência ................................................................................................. 80
3.5.1. Métodos Ágeis versus norma ISO TR 18529:2000 ............................................ 81
3.5.2. Estratégias de Apoio x ISO TR 18529 ............................................................... 87
3.6. Considerações Finais do Capítulo .............................................................................. 89
4. ESTRATÉGIA DE APOIO À INSTITUCIONALIZAÇÃO DA
USABILIDADE EM AMBIENTES ÁGEIS ................................................... 91
4.1. Introdução .................................................................................................................. 91
4.2. Papéis ......................................................................................................................... 92
4.3. Artefatos de Apoio ..................................................................................................... 93
4.4. Estrutura e Características da Estratégia .................................................................... 94
4.5. Descrição das Etapas e Atividades da Estratégia ....................................................... 96
4.5.1. Etapa 1: Investigação Organizacional ................................................................ 96
4.5.2. Etapa 2: Análise e Planejamento das Atividades................................................ 98
4.5.3. Etapa 3: Execução do Plano de Melhoria em Usabilidade ............................... 105
4.5.4. Etapa 4: Análise das Ações Realizadas ............................................................ 109
4.6. Análise de Aderência – ISO TR 18529:2000 .......................................................... 111
4.6.1. Práticas da Estratégia versus ISO TR 18529 .................................................... 111
4.7. Análise Comparativa – P-CMM x Práticas da Estratégia ........................................ 114
4.7.1. Análise da Área de Desenvolvimento das Capacidades Individuais ................ 114
16
4.7.2. Análise da área de Construção de Grupos de Trabalho e Cultura .................... 116
4.8. Considerações Finais do Capítulo ............................................................................ 119
5. ESTUDO DE CASO – APLICAÇÃO DA ESTRATÉGIA ................... 120
5.1. Contexto de Aplicação ............................................................................................. 120
5.2. Fatores Críticos de Sucesso da Aplicação da Estratégia .......................................... 121
5.3. Aplicação da Estratégia ........................................................................................... 121
5.3.1. Investigação Organizacional............................................................................. 121
5.3.2. Análise e Planejamento das Atividades ............................................................ 126
5.3.3. Execução do Plano de Melhoria em Usabilidade ............................................. 130
5.3.4. Análise das Ações Realizadas .......................................................................... 136
5.4. Considerações Finais do Capítulo ............................................................................ 139
6. CONCLUSÕES ......................................................................................... 141
6.1. Conclusões ............................................................................................................... 141
6.2. Contribuições da Pesquisa ....................................................................................... 142
6.3. Dificuldades Encontradas ........................................................................................ 143
6.4. Trabalhos Futuros .................................................................................................... 144
REFERÊNCIAS .............................................................................................. 145
APÊNDICES .................................................................................................... 154
APÊNDICE A - Perfis de Gerentes e Estratégias de Convencimento ................................ 154
APÊNDICE B - Descrição dos Processos da ISO TR 18529:2000 .................................... 158
APÊNDICE C - Questionário Investigativo e Resultados Encontrados ............................. 165
APÊNDICE D – Plano de Melhoria de Processo ............................................................... 176
APÊNDICE E – Questionário Pós-Treinamento ................................................................ 178
17
1. Introdução
Este capítulo inicial apresenta as razões que motivaram a realização desta pesquisa,
define o escopo e os resultados que se objetivou alcançar, a abordagem metodológica aplicada,
e, finalmente, especifica a organização dos capítulos, seções e subseções subseqüentes, com
uma breve explicação de cada uma delas.
1.1. Visão Geral
É notório que o mercado de software demonstra o desejo por qualidade não
apenas de seus processos, mas também percebe a importância em um aumento da
qualidade de seus produtos ofertados. As organizações, em busca contínua por um bom
posicionamento no mercado e pela consolidação da confiança de seus produtos ante aos
seus consumidores, começam a identificar que o esforço desprendido para seguir seus
processos pode ser insuficiente para garantir a qualidade de um produto.
Somada a esta realidade, verifica-se a adoção de uma nova abordagem de
desenvolvimento de software - a abordagem ágil - que trata os problemas das mudanças
rápidas: mudanças nas forças de mercado, requisitos de sistemas, tecnologia de
implementação e equipes de projeto em período de desenvolvimento [Highsmith &
Cockburn, 2001].
Todavia, a iniciativa supracitada deixa de considerar atividades relacionadas à
melhoria da qualidade de interação dos seus produtos. Ou seja, embora exista um desejo
por parte das organizações em construir produtos melhores, estas possuem dificuldades
em definir, de maneira precisa e completa, quais atividades (tais como: identificação das
necessidades dos usuários, análise de viabilidade de suas expectativas, dentre outras)
devem ser realizadas e como elas devem ser executadas e monitoradas, sem
comprometer a eficácia dos demais processos existentes.
Ao invés de investir-se numa maior participação, e desta forma num maior
comprometimento dos usuários na construção destes sistemas, certas organizações
optam por focar o processo em atividades de desenvolvimento e implementação das
funcionalidades do sistema.
18
Outro motivo a ser citado para a pouca importância dada a aspectos de Interação
Humano Computador (IHC), é que para muitos desenvolvedores, a interface ainda é
vista como parte secundária de um sistema interativo, isto é, ela é um acessório do
aplicativo. Isto pode levar ao limitado conhecimento da organização sobre o que pode
ser feito com intuito de melhorar seus processos para produzir sistemas com
usabilidade.
Estudos de IHC têm provado que a interface é um fator chave para o sucesso de
um projeto de software, pois para a maioria dos usuários este instrumento de interação
lhes dá a noção do sistema como um todo (“o sistema é a interface”). Dentre estes
estudos, esta pesquisa foca uma atenção especial nas ISO 13407 [ISO 13407, 1999] e
ISO TR 18529, normas de qualidade para processos centrados no usuário.
A ISO 13407 apresenta características baseadas na engenharia da usabilidade,
sugerindo como os profissionais que venham a utilizá-la devem considerar os resultados
dos trabalhos ergonômicos, em especial durante o desenvolvimento de protótipos. A
ISO TR 18529 [ISO TR 18529, 2000] trata-se de uma evolução da ISO 13407, onde seu
conjunto de sete práticas apóia a especificação, avaliação e melhoria de processos
centrados no humano na construção de software.
Entretanto, pesquisas [Nielsen, 2005] [Schaffer, 2004] demonstram que incluir
práticas que promovam uma maior qualidade na interação, em um processo de
desenvolvimento existente na organização, não se trata de algo trivial, pois envolvem
uma série de iniciativas como:
Mudança de foco das organizações: o foco da organização em concentrar
esforços no desenvolvimento de funcionalidades deve ser repartido com a
importância em considerar as necessidades dos usuários.
Conscientização da equipe e alta direção: é preciso realizar um trabalho de
convencimento dos executivos, gestores de processos e gerentes de projetos da
organização, demonstrando o valor de negócio da usabilidade.
Melhoria do processo de software existente: deve-se definir um plano de
melhoria para o processo de desenvolvimento de software existente, visando
incluir, de forma sistemática, práticas de usabilidade neste processo.
Esta dificuldade de integração se acentua quando se trata especificamente de
ambientes de desenvolvimento de software onde se utilizem metodologias ágeis.
19
Existem estudos de casos publicados descrevendo experiências da combinação do
desenvolvimento ágil com envolvimento do usuário [Hansson et al, 2004].
Os resultados apresentam-se favoráveis, onde se verifica que a cooperação
constante do usuário no processo torna-se um efeito motivador na equipe de
desenvolvimento. Além disso, a confiança desta mesma equipe aumenta, devido a uma
melhora na comunicação e conseqüente cumprimento das expectativas dos usuários. Por
fim, esta combinação promoveu uma maior visibilidade (interna e externa) do processo
entre os stakeholders.
Entretanto, as diferenças existentes nas filosofias destas duas áreas podem
ocasionar potenciais conflitos que impactariam, em especial, no processo de
desenvolvimento de uma organização [Lee & McCrickard, 2007].
As metodologias ágeis possuem, em sua essência, ciclos de desenvolvimento
iterativos e incrementais, entretanto não provém nenhum esforço para a realização de
uma avaliação compreensiva da estrutura de suas interfaces, comprometendo, dessa
forma, a construção de interfaces consistentes e usáveis [Sharp et al, 2006]. Ou seja,
aspectos de design de interfaces são considerados apenas como sendo de caráter
evolutivo. Além disso, a participação do usuário é estimulada por esta abordagem,
porém o seu papel necessita ser melhor definido dentro do processo de desenvolvimento
Sendo assim, vislumbra-se um cenário onde a integração entre os conceitos da
abordagem ágil e de interação humano-computador propicie um novo conjunto de
mudanças a serem tratadas pelas organizações, originadas pela falta de amadurecimento
em usabilidade da organização aliada ao curto tempo desprendido no desenvolvimento
ágil de sistemas interativos. Tais mudanças, se realizadas sem uma sistemática definida,
podem gerar falhas na comunicação entre o sistema e o usuário podendo comprometer,
conseqüentemente, a facilidade de uso do software e a satisfação no uso do produto.
1.2. Motivação
A motivação para este trabalho surgiu a partir de um projeto de melhoria de
processo requisitado (e posteriormente realizado neste trabalho) em uma organização
que utilizava em seu ambiente de desenvolvimento duas das principais metodologias
relacionadas à abordagem ágil: o Extreme Programming [Beck & Andres, 2004] e o
SCRUM [Demmer & Benefield, 2007].
20
Neste projeto, foi requisitado que as atividades de melhoria de processo previstas
se concentrassem em incluir características relacionadas à usabilidade, de maneira que
pudessem ser adaptadas às práticas atuais de desenvolvimento e gerência ágil de
projetos de software, sem aportar impactos consideráveis na produtividade das equipes.
Dessa forma, durante a elaboração deste trabalho, investigaram-se estratégias que
guiassem a execução de melhorias em processos de software [Kulpa & Johnson, 2003].
Encontraram-se vários trabalhos sobre aplicação de conceitos de usabilidade em
metodologias ágeis, como [Bernardino & Gomes, 2005], [Constantine & Lockwood,
2001] e [Memmel et al, 2007], além das diretrizes de conformidade internacionais ISO
13407 [ISO 13407, 1999] e ISO TR 18529 [ISO TR 18529, 2000].
Estas abordagens, cada qual com sua contribuição específica, se propuseram a
promover a integração de práticas de usabilidade em um processo de desenvolvimento
(ágil ou convencional), com a intenção de melhorar tal processo e conseqüentemente os
produtos construídos pela organização. Outras abordagens existentes na comunidade
acadêmica
1
da área de IHC promovem alternativas, visando suprir os obstáculos
definidos na seção anterior.
Atualmente, grande parte das iniciativas para a execução de práticas de IHC
(inclusive as relatadas no nesta seção) é realizada por especialistas (ou consultores) em
usabilidade de maneira esporádica, sendo geralmente despercebidas pela alta direção e
gestores de processo [Schaffer, 2004].
Um problema observado nestes trabalhos é a existência de um gap entre as
contribuições dos especialistas e a capacidade das organizações em absorver o
conhecimento oferecido por estes profissionais. Ou seja, a aplicabilidade prática dos
conceitos definidos pela academia fica comprometida, pelo fato de inexistir uma
estratégia que oriente as organizações a transformar o conhecimento tácito em
usabilidade em práticas rotineiras na organização.
Esta afirmação acima requer uma explicação sobre o que se quer dizer por
“aplicabilidade prática” e “levar as organizações a transformar o conhecimento tácito de
usabilidade em práticas rotineiras na organização”.
1
ACM SIGCHI: Grupo de Interesse Especial em Interação Humano-Computador da ACM (Association for
Computing Machinery)
21
Tal explicação exige a diferenciação entre os termos “aplicar” e
“institucionalizar”: (i) entende-se por “aplicar” como sendo o experimento de combinar
práticas de usabilidade com práticas de um processo de desenvolvimento, sendo
realizado de maneira esporádica e por qualquer pessoa que possua certo conhecimento
em usabilidade na organização; (ii) entende-se por institucionalizar como sendo a
transformação do conhecimento em usabilidade em práticas repetíveis e customizáveis,
estimuladas por um conjunto de atividades, e em sintonia com os demais processos
existentes na organização.
Constantine e Lockwood (2001) apresentram uma proposta de aplicação da
usabilidade no desenvolvimento ágil, onde o processo se iniciava com o design da
interface e logo após continuava com as práticas de desenvolvimento. Um potencial
problema desta abordagem era que o processo de design da usabilidade da interface
tornava-se uma atividade onerosa dentro do processo de desenvolvimento, violando
alguns dos princípios aceitos na filosofia de desenvolvimento ágil [Nelson, 2002].
Schaffer (2004) propôs uma estratégia de institucionalização da usabilidade, onde
descreveu uma metodologia que integrava práticas de engenharia da usabilidade e
desenvolvimento de software e as transformava em práticas rotineiras da organização.
Entretanto, esta metodologia pecava por sua complexidade e pelo alto custo de
implementação [Schaffer, 2004]. Ela fugia da realidade de pequenas e médias
organizações, em especial àquelas onde se utilizava uma estratégia de desenvolvimento
ágil, foco deste trabalho.
A partir da problemática identificada acima, este trabalho passou a investigar
possíveis estratégias que poderiam auxiliar a organização na condução dos seus planos
de melhoria criados com o intuito de institucionalizar a usabilidade em seus processos.
Chegou-se à conclusão que, dentro do escopo de institucionalização da
usabilidade em uma organização desenvolvedora de software, não se identificava
nenhuma abordagem que reunisse, em uma única estratégia e de forma integrada, os
seguintes itens fundamentais:
Foco nas experiências da organização: Antes de se iniciar quaisquer
atividades para aplicar práticas de usabilidade na organização, é necessário
prepará-la para receber este conhecimento e, além disso, alinhar tais práticas
com os objetivos estratégicos e as necessidades de negócio da organização,
22
evitando que esta iniciativa seja um insucesso. Os objetivos estratégicos
consistem das metas estabelecidas pela organização a serem atingidas com o
advento da usabilidade. As necessidades de negócio são os aspectos existentes
no mercado que motivam a organização a realizar uma melhoria na qualidade
de seus produtos. [Schaffer, 2004].
Garantia (contínua) da qualidade: Não basta apenas realizar a integração de
práticas de usabilidade. É de fundamental importância o constante
acompanhamento da implantação destas práticas, avaliando a eficácia do
processo e promovendo atividades de melhoria contínua.
Foco na maturidade em usabilidade da organização: Com o advento das
práticas de usabilidade pelas organizações, estas acabam por evoluir e
amadurecer seus processos [Nielsen, 2003]. Sendo assim, é importante que
ocorra uma avaliação do nível de maturidade em usabilidade da organização.
Capacitação e colaboração das equipes: um estudo sobre as competências
em usabilidade e a realização de capacitações em usabilidade deveria ser
realizado. Assume-se que os profissionais, estando bem capacitados, poderão,
a medida que forem amadurecendo, realizar as práticas de usabilidade sem a
presença obrigatória de um consultor de usabilidade, sendo este requisitado
apenas em situações de conflito ideológico ou para novas atividades.
Comprometimento da organização: Tanto o comprometimento da alta
organização (no sentido de absorver e disseminar internamente a importância
da estratégia) quanto o da própria equipe envolvida no projeto piloto
(responsável por executar as atividades na prática) devem ser avaliados e
estimulados, com o objetivo de se comprovar sua eficácia e o nível de
envolvimento da organização.
Produtividade das equipes e projetos: por se tratar de metodologias ágeis, a
preocupação maior das organizações que lidam com esta abordagem está em
não aportar impactos na produtividade dos projetos. Acredita-se que as
organizações aceitem realizar melhorias em seus processos caso: não haja um
adicional considerável nos custos, se houver uma melhoria comprovada na
qualidade do produto e se as integrações forem simples.
23
1.3. Escopo do Trabalho
O escopo deste trabalho está concentrado nas organizações que utilizem em seus
processos uma estratégia de desenvolvimento ágil e que possuam pequenas e/ou médias
equipes de desenvolvimento.
1.4. Objetivos do Trabalho
O principal objetivo deste trabalho é propor uma estratégia que servirá como um
guia para profissionais (consultores de usabilidade, executivos, gestores de processo,
gestores de projeto, etc.) interessados em institucionalizar práticas de usabilidade em
seus processos de desenvolvimento de sistemas interativos.
Este trabalho visa contemplar os seguintes objetivos específicos:
Propor a institucionalização de um conjunto de práticas de usabilidade em
ambientes de desenvolvimento ágil, utilizando-se de atividades previstas em
um plano de melhoria de processo, onde serão incluídas novas atividades na
rotina das equipes de desenvolvimento e dos gerentes destas equipes;
Demonstrar a aplicação de tais práticas em um estudo de caso. Tal estudo se
refere a uma experiência realizada em uma organização que utiliza um
processo de desenvolvimento ágil, onde se aplicou a proposta deste trabalho;
Realizar estudos comparativos e de aderência entre os conceitos relacionados à
abordagem ágil (XP e SCRUM), gestão de competências e pessoas (P-CMM)
e estratégias de apoio à institucionalização da usabilidade.
Promover uma reflexão sobre a importância em aplicar novas práticas ao seu
processo de maneira esporádica, e em torná-las parte da cultura de
desenvolvimento de seus sistemas interativos.
1.5. Metodologia
A elaboração deste trabalho foi fundamentada em estudos e pesquisas que
seguiram os seguintes passos:
24
1.5.1. Vertente Teórica
Estudos sobre abordagens de desenvolvimento (XP) e gerenciamento
de projetos ágeis (SCRUM);
Análise comparativa de trabalhos relacionados à aplicação de práticas
de usabilidade em processo ágeis;
Reflexão sobre o cenário atual e os desafios dos profissionais de
usabilidade e estudos sobre estratégias de apoio à institucionalização da
usabilidade;
Investigação da norma ISO TR 18529, responsável pela definição
atividades que compõem um modelo de maturidade em usabilidade;
Investigação das práticas do modelo de gestão e desenvolvimento da
força de trabalho People-CMM;
Realização de análises comparativas e de aderência entre os conceitos
investigados acima, visando a integração com a abordagem ágil;
1.5.2. Vertente Prática
Realização de estudo de caso em uma organização desenvolvedora de
software, onde foram aplicadas todas as etapas previstas neste trabalho.
Com a execução desta atividade, foi possível gerar resultados reais,
identificar possibilidades de melhorias, além de experimentar na prática
o funcionamento da estratégia.
1.6. Organização do Conteúdo do Trabalho
Os tópicos abordados neste trabalho foram distribuídos em 6 (seis) capítulos e
organizados como segue:
Os capítulos dois e três apresentam o estado da arte obtido a partir da pesquisa
bibliográfica. O capítulo dois descreve as contribuições da literatura obtidas sobre as
abordagens de desenvolvimento ágil, traçando um comparativo entre as práticas
existentes neste modelo e nos métodos tradicionais. Além disso, realiza uma análise
comparativa de três propostas de integração entre processos ágeis e práticas de IHC. Por
25
fim, demonstra as similaridades existentes entre os conceitos acima e as práticas de
Design Participativo.
O capítulo três apresenta um conjunto de estratégias corporativas propostas com o
intuito de auxiliar as organizações a institucionalizar a usabilidade em seus processos.
Logo após, investiga-se com mais detalhes as normas ISO TR 18529 e o People CMM,
suas respectivas contribuições para o amadurecimento dos processos da organização e
qualificação de mão-de-obra, além de uma avaliação da aderência com os métodos ágeis
e as estratégias corporativas propostas neste capítulo.
O capítulo quatro apresenta a proposta deste trabalho. Neste capítulo são descritos
os objetivos, a fundamentação teórica, além dos papéis, artefatos e atividades existentes
durante as etapas da estratégia. Após, é realizada uma avaliação da aderência da
estratégia com conceitos da norma ISO TR 18529 e uma análise comparativa com
práticas do P-CMM.
O capítulo cinco apresenta o estudo de caso no qual foi aplicada a estratégia de
apoio à institucionalização da usabilidade descrita neste trabalho. São relatados os
desafios encontrados, a aplicação dos passos da estratégia definidos no capítulo anterior,
as lições aprendidas e os resultados atingidos com esta experiência.
Por fim, o capítulo seis descreve as contribuições obtidas durante o
desenvolvimento deste trabalho, as considerações finais do estudo e sugestões para
trabalhos futuros.
2. Desenvolvimento Ágil e sua Integração com os
Conceitos de Usabilidade e Design Participativo
Este segundo capítulo descreve as contribuições da literatura obtidas sobre as
abordagens de desenvolvimento ágil, um comparativo entre as práticas existentes neste modelo
e nos métodos tradicionais, além da análise de propostas de integração entre processos ágeis e
práticas da Interação Humano-Computador, destacando os pontos em comum e as diferenças
identificadas entre os trabalhos investigados. Por fim, demonstra as similaridades existentes
entre os conceitos acima e as práticas de Design Participativo.
2.1. Introdução
Durante a década de noventa, alguns pesquisadores [Highsmith & Cockburn,
2001] questionaram as estruturas das metodologias de desenvolvimento tradicionais,
onde seus ciclos de vida geralmente se iniciavam com a elicitação e documentação de
todos os requisitos do sistema, seguidos por uma análise e projeto da arquitetura,
desenvolvimento das funcionalidades e inspeção de código.
Eles duvidavam da eficácia destes modelos para satisfazer a realidade de diversos
projetos vivenciados, onde os requisitos de um sistema (afetados pelas mudanças de
tecnologia) em desenvolvimento mudavam rapidamente, e os usuários tornavam-se mais
exigentes com relação às expectativas, necessidades e funcionalidades de seus sistemas.
No mesmo período, Hawrysh e Ruprecht (2000) afirmaram que uma simples
metodologia de desenvolvimento não funcionava para todo um conjunto de diferentes
projetos dentro de uma organização. Era atribuição do processo de gerenciamento de
projetos identificar a natureza específica de cada projeto, e então selecionar a
abordagem de desenvolvimento mais apropriada.
Nesse contexto, as metodologias de desenvolvimento ágil foram criadas como
uma alternativa às abordagens de desenvolvimento tradicionais existentes. Através dos
seus conjuntos de técnicas e atividades específicas, elas surgiram para estimular a
criatividade e responsabilidade da equipe em condições de mudanças freqüentes,
enfatizando a participação do usuário durante o processo, uma rápida reação às
27
mudanças de requisitos do sistema e releases contínuos durante seu ciclo de vida
[Cohen et al, 2003].
Diversas metodologias foram definidas desde então, cada qual com suas práticas
específicas sugeridas. Em 2001, foi criada a Aliança Ágil, uma união de dezessete
especialistas em desenvolvimento de software, representando métodos como Extreme
Programming (XP) [Beck, 2000] e [Beck & Andres, 2004], SCRUM [Schwaber &
Beedle, 2002], FDD (Feature Drive Development) [Coad et al, 1999] dentre outros,
onde foi definido um conjunto de princípios em comum que seriam seguidos por todos,
representados pelo Manifesto Ágil [Manifesto, 2001]:
Indivíduos e iterações ao invés de processos e ferramentas.
Software executável ao invés de documentação.
Colaboração do cliente ao invés de negociação de contratos.
Respostas rápidas a mudanças ao invés de seguir planos.
Vale ressaltar que estes princípios não rejeitam processos e ferramentas,
documentação, planejamento ou negociação de contratos. A filosofia deste manifesto
consiste em colocá-los em uma importância secundária. Estes conceitos aproximam-se
melhor com a forma que pequenas e médias organizações trabalham e respondem às
mudanças [Soares, 2004].
Highsmith e Cockburn (2001) também perceberam que a mudança no ambiente de
negócios do mercado de software influenciava diretamente o comportamento dos
processos de desenvolvimento de software. De acordo com os mesmos, satisfazer o
cliente no momento da entrega de um produto tornava-se mais prioritário do que
durante o início do projeto. Sendo assim, os autores relacionaram um conjunto de
esforços necessários para que os métodos ágeis lidem com as mudanças inevitáveis que
venham a acontecer durante o ciclo de vida de um projeto, esforços estes citados abaixo:
Produzir uma primeira versão do sistema em poucas semanas, com intuito de
receber um rápido feedback por parte do usuário;
28
Projetar soluções simples, pois dessa forma diminui-se a necessidade e a
complexidade no momento de se realizar mudanças;
Melhorar a qualidade do design continuamente, tornando dessa forma as
próximas iterações mais rápidas de implementar;
Testar constantemente, objetivando antecipar-se a problemas que seriam
detectados apenas no futuro ou durante o uso do sistema.
Dentre as metodologias mais disseminadas no mercado atual, encontramos a
Extreme Programming (XP) [Beck, 2000] e a SCRUM [Schwaber & Beedle, 2002], que
serão detalhadas na seção 2.3.
2.2. Comparativo entre métodos tradicionais e métodos ágeis
Dentre os diversos métodos de desenvolvimento existentes na literatura de
Engenharia de Software [Sommerville, 2003], destacam-se duas abordagens: as
metodologias tradicionais, orientadas à documentação e ao planejamento, e as
metodologias ágeis (definidas na seção anterior), que são orientadas ao
desenvolvimento colaborativo e com pouca documentação.
As metodologias tradicionais tratam-se das abordagens mais utilizadas atualmente
pelas organizações [Ferreira & Lima, 2006]. Dentre elas, podemos destacar a conhecida
metodologia RUP (Rational Unified Process). Elas se caracterizam essencialmente pela
separação rígida das fases de projeto, que consistem em: Levantamento de Requisitos,
Análise, Projeto, Implementação, Testes e Implantação. Cada fase possui suas
particularidades e são interdependentes, ou seja, a próxima fase só começa quando a
anterior estiver pronta. Isto significa que o processo é seqüencial e linear, no qual cada
fase deve ser concluída antes de passar para a próxima etapa.
A tabela abaixo (Tabela 2.1) apresenta um comparativo entre as características
existentes nas metodologias ágeis e tradicionais, onde são ilustradas suas principais
diferenças, baseadas em aspectos de desenvolvimento em comum, retiradas de estudos
realizados por [Nerur et al, 2005], [Rusk, 2006] e [Boehm, 2002] e adaptados pelo autor
deste trabalho.
29
Tabela 2.1 - Comparativo entre Abordagens de Desenvolvimento Tradicional e Ágil
Aspectos principais
Ágil
Filosofia
Sistemas de alta qualidade,
baseados em design incremental,
testes, rápidos feedbacks e
mudanças.
Controle
Centrado em pessoas
Gerenciamento
Lidere-e-colabore
Gestão do
Conhecimento
Tácito (comunicação intensiva,
código fonte legível)
Atribuição de papéis
Rotatividade de papéis
Comunicação
Informal
Participação do
Usuário
Crítica
Ciclo do Projeto
Guiado por características do
produto
Modelo de
Desenvolvimento
Modelo de entrega evolucionária
(iterações)
Estrutura
Organizacional
Orgânica (flexível, participativa,
estímulo ao trabalho colaborativo)
Qualidade de
Requisitos
Largamente emergentes, mudanças
rápidas
Melhoria de Processo
Baseado nas pessoas envolvidas
Tamanho da Equipe
Pequenos times, mesmos produtos
Analisando o conjunto de características exposto acima, percebem-se as principais
diferenças existentes entre as duas abordagens. Alguns itens da tabela merecem especial
atenção e maior detalhamento, como visto nos próximos parágrafos.
Filosofia, Controle, Gerenciamento e Melhoria de Processo - a proposta
tradicional de desenvolvimento de software é centrada em processos, ou seja, guiada
pela crença de que todos os desvios que venham a ocorrer devem ser identificados e
eliminados por atividades contínuas de refinamento e medição. O foco desta abordagem
30
é realizar um processo otimizado ao máximo e repetível. Atividades de planejamento e
controle do projeto passam por um gerenciamento firme e disciplinado. A proposta ágil
lida com a imprevisibilidade apoiando-se na equipe em e sua criatividade, ao invés de se
concentrar em atividades processuais. As decisões são tomadas de maneira colaborativa,
sendo conduzidas por um gerenciamento que estimula a participação.
Ciclo do Projeto e Papéis – o desenvolvimento de sistemas nos métodos
tradicionais guia-se por um modelo de ciclo de vida (cascata, espiral ou alguma
variação), que define um conjunto de fases que seguem uma ordem, cada qual com suas
atividades específicas. Além disso, define papéis específicos para cada membro da
equipe (como exemplo: programador, analista, líder de projeto etc). Na abordagem ágil,
o desenvolvimento guia-se por ciclos de iteração menores que os tradicionais, mais
flexíveis, onde ao final de cada ciclo é entregue uma parte do produto ao cliente. Os
papéis dentro da equipe são rotativos, ou seja, um membro pode possuir papéis
diferentes durante o projeto.
Comunicação e Gestão do Conhecimento – no modelo tradicional, a
comunicação entre os participantes é formalizada em documentos, que garantem a
gestão do conhecimento sobre os processos e o produto. Na abordagem ágil, a
comunicação é informal e a documentação formaliza apenas o que for estritamente
necessário. A gestão do conhecimento baseia-se na rotatividade da equipe, onde seus
membros acabam por conhecer o processo e o produto como um todo.
Participação do Usuário – o modelo tradicional estimula a participação do
usuário principalmente no começo do projeto, durante a fase de especificação.
Decorrida esta fase, a participação do usuário é mínima. Na abordagem ágil, a
participação do usuário (ou cliente representando o usuário) é fundamental durante todo
o ciclo de vida, sendo o usuário tratado como um membro ativo da equipe.
2.3. Abordagens de Desenvolvimento Ágil
2.3.1. Extreme Programming
A metodologia XP (eXtreme Programming) [Beck, 2000], [Beck & Andres,
2004] pode ser considerada a metodologia ágil mais disseminada na comunidade de
31
desenvolvimento [Cohen et al, 2003], dentre as existentes até o momento. É coesa,
composto de um conjunto de práticas que a tornam uma alternativa válida na busca por
maiores taxas de sucesso nos projetos de software [Teles, 2005].
Um dos poucos (mas fundamentais) requisitos existentes nesta metodologia trata
da disponibilidade do cliente dentro do processo, não apenas com a função de auxiliar a
equipe de desenvolvimento, mas também com o intuito de participar da estratégia como
um todo. Todas as fases de um projeto XP requerem constante comunicação com o
cliente ou um contato do mesmo, que possua um bom conhecimento do negócio.
A metodologia XP, em sua essência, consiste de um conjunto de Valores,
Princípios e Práticas [Beck & Andres, 2004] detalhados a seguir. Os Valores
representam um nível mais abstrato de conhecimento e compreensão, funcionando
como orientações em nível estratégico, para julgar o que se vê, pensa e faz. Tais
conceitos devem ser disseminados em toda a organização, pois se comportam como o
instrumento motivacional para se entender os Princípios e realizar as Práticas.
Comunicação: um dos principais valores envolvidos no desenvolvimento de
software. Grande parte dos problemas identificados durante a execução de um
projeto se sucede devido a uma falha de comunicação ou por uma
comunicação não efetiva entre desenvolvedores, usuários, gerentes de projeto,
dentre outros stakeholders. Deve-se implantar a cultura de que, sempre que
ocorra um problema, este seja verificado e identificado se foi causado por um
problema de comunicação.
Feedback: é uma parte crítica da comunicação, principalmente entre
desenvolvedores e usuários. Através dele é possível obter a capacidade de
adaptação e mudança defendida pelo Manifesto Ágil [Manifesto, 2001].
Dificilmente num projeto de software as circunstâncias permanecerão estáveis
por muito tempo [Teles, 2005].
Simplicidade: preconiza a realizar apenas o trabalho que for realmente
necessário no começo de um projeto, e melhorar gradativamente quando
necessário. A idéia não é ser simplista, mas eliminar toda a complexidade e
burocracia desnecessária, evitando possíveis retrabalhos no futuro.
32
Coragem: ter confiança nos mecanismos de segurança utilizados para proteger
o projeto. Ao invés de acreditar que os problemas não ocorrerão e fazer com
que a coragem se fundamente nesta crença, projetos XP partem do princípio
de que problemas irão ocorrer, inclusive, aqueles mais temidos. Os
desenvolvedores empregam mecanismos sérios de proteção para poderem ter
confiança, por exemplo, para acolher mudanças nos requisitos a qualquer
momento [Cavalcanti, 2006].
Respeito: este valor é a base para todos os demais supracitados. Se os
membros de uma organização não se importarem com os outros e com as
atividades que estão realizando no processo, este estará fadado ao insucesso.
Analisando os conceitos definidos acima, verifica-se que eles podem ser
considerados conotativos em demasia, dificultando sua implementação. Dessa forma,
foram definidos os conceitos de Princípios e Práticas, com intuito de incrementar sua
aplicabilidade prática.
Os conceitos de Princípios surgem como um guia de como os Valores definidos
acima são contemplados pelas Práticas. Tais conceitos se subdividem em: Humanidade,
Economia, Benefício Mútuo, Auto-semelhança, Aprimoramento, Diversidade, Reflexão,
Fluxo, Oportunidade, Redundância, Falha, Qualidade, Pequenos Passos e
Responsabilidade Aceita. Tais conceitos não serão detalhados, haja vista que o foco
deste trabalho se concentra nas Práticas, podendo ser encontrados em [Cavalcanti,
2006].
Os conceitos de Práticas do XP surgem como um conjunto de possibilidades de
implementação dos Valores e Princípios na rotina da organização. As Práticas
subdividem-se em duas: primárias e corolárias. As práticas primárias, consideradas o
núcleo do processo, são mais simples e devem ser adotadas inicialmente. As práticas
corolárias tendem a ser mais complexas de serem incluídas no processo, sem antes
colocar em uso as práticas primárias. Cada prática sozinha promove melhorias no
processo de desenvolvimento que podem ser observadas rapidamente. À medida que se
introduzem mais práticas no dia-a-dia da equipe, também se pode notar como elas
influenciam positivamente umas às outras.
33
A seguir, serão descritas, de maneira sucinta, as treze práticas primárias propostas
por [Beck & Andres, 2004] e traduzidas por [Cavalcanti, 2006], e uma visão geral sobre
as práticas corolárias, também propostas pelos mesmos.
Sentando Juntos: toda a equipe de desenvolvimento deve se acomodar em um
mesmo espaço físico, como forma de estimular a colaboração e comunicação
de seus integrantes. Caso isto seja inviável, deve-se promover um espaço em
comum onde possam ser realizadas reuniões de desenvolvimento em conjunto.
Equipe Completa: a equipe deve possuir integrantes com habilidades
diferenciadas, de preferência complementares, e dispostos a assumirem
diferentes funções durante um projeto. Ressalta-se a figura do Coach, que
consiste de um membro da equipe com funções de liderança, visando
mudanças e melhorias.
Ambiente de Trabalho Informativo: o ambiente de trabalho deve estar
disposto de maneira que propicie a comunicação e permita à equipe obter
rápidas informações sobre o progresso do trabalho, pendências, atividades,
resultados de testes, entre outras informações.
Trabalho Energizado: o horário de trabalho deve ser regular, seguindo a
carga horária pré-definida pela organização. Segundo Demarco (2001), as
horas extras devem ser evitadas, pois comprometem a produtividade. Os
prazos para realização das atividades são fixos, devendo ser respeitados. Caso
o prazo não possa ser alcançado, o escopo do projeto é ajustado e renegociado
com o cliente, para que o prazo seja cumprido.
Programação em Par: consiste, basicamente, em reunir dois membros de uma
equipe e realizar (além de revezar) as atividades de codificação, revisão de
código e testes. Enquanto um dos membros realiza a atividade, o outro
observa, corrige desvios e toma a iniciativa quando achar pertinente.
Estórias de Usuário: instrumentos utilizados para auxiliar na elicitação dos
requisitos. Consistem na descrição sucinta de funcionalidades,
comportamentos e características do sistema em construção, devendo ser
escritas e priorizadas pelos próprios clientes que as definiram [Jeffries et al,
34
2001]. Comumente são registradas em cartões, artefatos estes a serem
detalhados posteriormente.
Ciclo Semanal: cada iteração do processo deve durar o tempo de uma semana.
Preferencialmente, deve-se disponibilizar, ao final de cada semana, uma
versão funcional do software que possa ser entregue ao cliente para teste. Ou
seja, as estórias definidas e priorizadas pelo cliente devem ser contempladas
durante este prazo. Caso seja inviável, deve-se dividi-las em estórias menores.
Ciclo Trimestral: momento para avaliar os marcos do projeto e realizar
retrospectivas e reflexões sobre os problemas existentes no processo e no
projeto, buscando alternativas de solução.
Folga: incluir no planejamento uma margem de segurança dentro do
cronograma, caso o mesmo não possa ser cumprido, devido a algum erro de
estimativa.
Build em dez minutos: O Build do sistema completo, juntamente com a
execução de todos os testes não deve exceder dez minutos. O primeiro passo é
automatizar o processo de compilação e testes do sistema. Quando o processo
exige intervenção manual ele tende a ser executado com menos freqüência
(Beck & Andres, 2004) apud (Cavalcanti, 2006).
Integração contínua: consistem de um conjunto de atividades simples (como
manter um repositório único de código-fonte, por exemplo) que visem
transformar a atividade de integração, normalmente caótica e imprevisível, em
um processo contínuo.
Programação Orientada a Testes: conduzir a produção de códigos de testes
antes mesmo de se codificar o sistema em si, trazendo à atividade de
desenvolvimento uma cadência característica: escrever um teste que falha,
fazê-lo passar e refatorar o código. Dessa forma, o desenvolvedor sempre sabe
o que fazer após terminar uma tarefa.
Design incremental: baseia-se no valor da simplicidade, ou seja, recomenda
que o design seja realizado em passos pequenos, evoluindo junto com a
35
compreensão da equipe e do cliente sobre os problemas tratado pelo sistema
em desenvolvimento.
As práticas corolárias possuem como meta observar os efeitos causados pela
adoção de uma prática. São práticas mais avançadas, que possuem como pré-requisito
para realização a aplicação das práticas primárias anteriormente. Beck e Andres (2004)
descrevem as onze práticas existentes:
Envolvimento real com o cliente – estimular todos os envolvidos cujas
vidas e negócios sejam afetados pelo sistema a ser desenvolvidos, a
participarem do projeto.
Implantação incremental – ao substituir um sistema legado por um mais
moderno, realizar a substituição das funcionalidades de maneira gradual.
Continuidade do time – manter times eficientes trabalhando juntos.
Redução do time – verificar a distribuição de tarefas e ociosidade da
equipe, realocando recursos humanos quando necessário.
Análise de causa inicial – sempre buscar a causa raiz para um problema
que venha a aparecer no produto. Ao corrigi-lo, eliminar a causa raiz.
Código compartilhado – qualquer membro da equipe pode melhorar
qualquer parte do sistema, a qualquer momento.
Códigos e Testes – inicialmente, devem ser os únicos artefatos a serem
mantidos pela equipe de desenvolvimento.
Repositório de Código Único - utilizar um repositório único para toda a
equipe de desenvolvimento.
Implantação Diária – se possível, disponibilizar um software novo em
ambiente de produção diariamente.
Contrato de Escopo Negociável – contratos devem fixar tempo, custo e
qualidade, mas a negociação de escopo deve ser aberta.
36
Pague Pelo Uso - cobrar por cada vez que o produto for utilizado,
tornando o dinheiro o feedback principal.
A seguir, são descritas as cinco fases básicas de um ciclo de vida da metodologia
XP: exploração, planejamento, iterações para entrega, produção e manutenção. Beck
(2000) descreve cada uma destas etapas, como se relata na Figura 2.1.:
Figura 2.1 - Fases do Extreme Programming, retirado de Ambler (2007)
Na fase de Exploração (Exploration), os clientes costumam relatar, em cartões, as
estórias que desejam incluir na primeira entrega. Cada estória representa uma
funcionalidade a ser incorporada ao sistema. Em paralelo, a equipe de desenvolvimento
se familiariza com as ferramentas, tecnologia e práticas que serão utilizadas durante o
projeto. A tecnologia a ser utilizada é investigada e as possibilidades de arquitetura do
sistema são testadas com a elaboração de protótipos. Esta fase pode demorar o período
de alguns dias ou poucas semanas, dependendo da familiaridade dos desenvolvedores
com a tecnologia e da complexidade do sistema.
O exemplo da Figura 2.2 consiste de um cartão similar ao utilizado nos primeiros
projetos que envolveram a metodologia ágil XP, liderados por Kent Beck. Atualmente,
esta estrutura de cartão vem sendo substituída dentro dos projetos ágeis por versões
mais simplificadas, com foco nas descrições das estórias [Goebel, 2003].
37
Figura 2.2 - Exemplo de Cartão representando uma Estória, retirado de Nargler (2005)
Detalhando um pouco mais sobre este artefato, os cartões são constantemente
utilizados na metodologia XP, especialmente durante esta fase de Exploração. Como
características especiais dos cartões citam-se: (i) refletem as necessidades do cliente; (ii)
o escopo de cada cartão limita-se ao tempo no qual o mesmo pode ser desenvolvido
durante uma iteração do processo; (iii) podem ser testados e divididos em sub-tarefas e
(iv) idealmente, devem ser independentes uns dos outros.
Na fase de Planejamento (Planning), define-se a ordem de prioridade das estórias
definidas na fase anterior, além de um acordo entre o cliente e a equipe de
desenvolvimento sobre quais funcionalidades estarão presentes na primeira entrega. Em
seguida, os desenvolvedores estimam o esforço necessário para implementar cada
estória, e um cronograma é estabelecido. Geralmente, define-se que o tempo para
realizar esta primeira entrega não ultrapasse um mês. Recomenda-se que esta fase, por
si mesma, tenha duração máxima de uma semana, aproximadamente.
A fase de Iterações para Entrega (Iterations to Release) inclui todas as iterações
que serão realizadas para desenvolver o produto, desde a sua especificação da
arquitetura até o desenvolvimento da última estória especificada pelo cliente. O início e
fim de cada ciclo devem ser de preferência semanais, como exposto anteriormente.
Cada iteração deve produzir uma versão do sistema que possa ser entregue ao cliente
para teste. Cabe ao cliente priorizar quais estórias devem ser desenvolvidas durante as
iterações.
38
Na fase de Produção (Productionizing), a versão desenvolvida do sistema deve ser
integrada e passar por testes extras, verificação de performance, antes de ser entregue
para aceitação do cliente. Durante esta fase, novas mudanças podem ser necessárias e
uma decisão deve ser tomada pela organização se as mesmas serão incluídas dentro na
entrega atual ou apenas na próxima.
A fase de Manutenção (Maintenance) consiste de um estado natural pelo qual o
processo deve passar. Ela engloba as fases de Planejamento, Iterações para Entrega e
Produção, pois em todas estas existe a possibilidade de evolução dos aspectos
envolvidos no projeto e na ocorrência de mudanças que devem ser tratadas pela equipe.
2.3.2. SCRUM
A metodologia SCRUM [Schwaber & Beedle, 2002], formalizada há
aproximadamente onze anos por Ken Schwaber e Jeff Sutherland, trata-se de uma
abordagem de desenvolvimento ágil iterativa e incremental. Seu foco concentra-se em
realizar atividades que apóiem o desenvolvimento de maneira flexível, dentro de um
ambiente de constantes mudanças.
SCRUM é baseada em princípios semelhantes aos da XP: equipes pequenas,
requisitos pouco estáveis ou desconhecidos e iterações curtas para promover
visibilidade para o desenvolvimento [Bernardino & Gomes, 2005].
No entanto, as dimensões em SCRUM diferem de XP. Diferentemente da
abordagem XP, a metodologia SCRUM não requer ou provê nenhuma prática de
desenvolvimento específica a ser utilizada. Ao invés, ela fornece práticas envolvendo o
gerenciamento do trabalho realizado, durante suas fases, com o objetivo de evitar o caos
causado pela imprevisibilidade e complexidade [Schwaber & Beedle, 2002].
Segundo Demmer e Benefield (2007), seis papéis principais fazem parte desta
abordagem, sendo descritos abaixo:
Gerente do produto (Product Owner): responsável por gerenciar e coletar
todas as informações relevantes ao produto que será desenvolvido, extraindo
tais informações de todos os stakeholders relevantes do projeto e formalizando
em uma lista de prioridades (Backlog List), a ser detalhada posteriormente.
39
Equipe de desenvolvimento (The Team): responsável pela construção do
software a ser utilizado pelo cliente. Tipicamente, é uma equipe
multidisciplinar, consistindo de cinco a dez membros, cada qual com sua
atribuição específica.
Especialista SCRUM (ScrumMaster): um dos mais importantes papéis dentro
do processo. O especialista não é considerado o gerente do projeto, mas
também é responsável por garantir o bom andamento das atividades do
processo, estimular a produtividade da equipe de desenvolvimento e resolver
quaisquer pendências que comprometam o projeto.
Cliente (Customer): participa nas tarefas relacionadas principalmente à
elaboração da lista de prioridades (Product Backlog), onde são coletadas suas
necessidades e expectativas.
Gerência (Management): responsável pela tomada de decisão final dentro do
projeto. Exerce papel fundamental na definição dos objetivos, requisitos e
escopo do projeto, além da definição dos papéis fundamentais dentro da
equipe, Especialista SCRUM e Gerente do Produto.
Schwaber e Beedle (2002) definem três fases como sendo as básicas do ciclo de
vida de um projeto com uso do SCRUM. São as seguintes: Pré-Planejamento,
Desenvolvimento e Pós-Planejamento.
A fase de Pré-Planejamento inicia-se com a definição da visão do produto. Neste
momento, são coletados do cliente os requisitos, necessidades e características desejadas
para o sistema, e uma prioridade é associada a cada um destes itens. Tais informações
são formalizadas em uma lista de tarefas, organizada por ordem de prioridade (Product
Backlog), artefato a ser utilizado durante todo o ciclo de vida do projeto.
Este artefato pode conter variadas informações, como características do sistema,
requisitos de desenvolvimento e outras atividades pertinentes de serem realizadas pela
equipe de desenvolvimento. Ele é de responsabilidade do Gerente do Produto, que deve
acompanhar e atualizá-lo, sempre que existirem mudanças nas informações
disponibilizadas pelos usuários e pela equipe de desenvolvimento. Os requisitos, assim
como na metodologia XP, geralmente são formalizados em “estórias”, como visto
40
anteriormente. A Product Backlog será utilizada como entrada para a próxima atividade
desta fase inicial, que é a reunião de planejamento.
Figura 2.3 - Ciclo de vida e stakeholders do SCRUM, retirado de Demer et al. (2007)
A reunião de planejamento (ver Sprint Planning Meeting, figura 2.3) inicia-se
com a revisão do artefato Product Backlog pelo Gerente do Produto e a equipe de
desenvolvimento. Neste momento, são discutidos os objetivos e o contexto dos itens
existentes no artefato em análise. Logo após, a equipe de desenvolvimento percorre a
Product Backlog e escolhe os itens pelos quais ela se compromete a concluir no
primeiro ciclo de desenvolvimento (Sprint). Ou seja, é de responsabilidade da equipe
decidir a quantidade de trabalho que a mesma se compromete a completar dentro de um
ciclo. Ao final da reunião, o Gerente de Produto comunica os resultados ao cliente.
Após a escolha, os itens selecionados são subdivididos em tarefas (ver Task
Breakout, na figura 2.3) a serem realizadas pela equipe e formalizadas em outro
artefato, chamado de Sprint Backlog. Tal artefato contém todas as tarefas a serem
realizadas por cada membro da equipe, assim como estimativas de conclusão.
A fase de Desenvolvimento estrutura a construção dos produtos em ciclos
chamados Sprints. Os Sprints possuem duração fixa, ou seja, eles terminam em uma
data específica, mesmo que as atividades previstas não tenham sido completadas.
Ressalta-se a participação do Especialista SCRUM, apoiando a equipe em todas as
atividades desta fase.
41
A figura 2.3 detalha uma iteração do SCRUM, ou seja, um Sprint. No começo de
cada Sprint, a equipe de desenvolvimento, de posse dos itens definidos na reunião de
planejamento (Sprint Planning Meeting) inicia o desenvolvimento do software. Convém
ressaltar que os itens definidos não podem ser alterados, ou seja, o que foi definido é o
que será construído e entregue ao cliente. Ao final de cada dia de trabalho, a equipe se
reúne e constata o progresso atingido, atualizando o artefato que a orienta a conduzir o
trabalho, o Sprint Backlog. Geralmente, um ciclo Sprint possui a duração entre uma a
quatro semanas, a ser definida pela organização.
A fase de Pós-Planejamento se inicia logo após o término de um Sprint, com
uma atividade de Revisão do Ciclo (Sprint Review). Nesta atividade, a equipe demonstra
o que foi construído e recebe um feedback do cliente e dos demais stakeholders
envolvidos sobre o que será incorporado no próximo ciclo. Após esta atividade, a
equipe de desenvolvimento pode optar (algumas organizações pulam esta atividade,
segundo [Demmer & Bennefield, 2006]) por realizar uma análise geral do ciclo em
questão, chamada de Retrospectiva do Sprint (Sprint Retrospective). Neste momento, a
equipe discute os pontos positivos e negativos identificados durante o ciclo e promove
sugestões de melhorias. Ao final desta atividade, o ciclo é reiniciado, com equipe
consciente sobre as lições aprendidas no ciclo anterior.
2.4. Potenciais Obstáculos entre Usabilidade e os Métodos Ágeis
Funcionalidade x Usabilidade
Um dos princípios dos métodos ágeis é o foco em medir o progresso de um
projeto de desenvolvimento de software a partir da quantidade de funcionalidades
construídas e validadas pelo usuário durante os ciclos semanais. Entretanto, um
software funcional não garante um software usável [Bankston, 2003][Nielsen, 2005].
No desenvolvimento ágil, as atividades concentram-se na qualidade no código, o que
pode diminuir a motivação da equipe em considerar aspectos de usabilidade.
Usuário x Cliente
Os métodos ágeis costumam, em suas práticas, representar o usuário pelo termo
“cliente”. Por exemplo, as estórias dos usuários geralmente são escritas por uma
representação do usuário, que possivelmente não conseguirá expressar as necessidades
42
do usuário [Constantine & Lockwood, 2001]. Este obstáculo pode levar o produto a
possuir características que serão subutilizadas pelos usuários finais, podendo causar
uma insatisfação no uso do produto [Patton, 2002].
Além disso, mesmo que exista um esforço em se incluir os usuários finais no
processo, existe a possibilidade de envolver pessoas que não consigam representar as
necessidades comuns de todos os usuários [Hudson, 2003]. Dessa forma, percebe-se que
mesmo que exista um esforço de colaboração entre os usuários e os desenvolvedores,
este fato por si só não garante um produto usável, haja vista que os métodos ágeis não
abordam as práticas de usabilidade de maneira sistemática.
Coleta de requisitos
As atividades de coleta de requisitos dentro dos métodos ágeis acontecem através
da elaboração de estórias dos usuários (na metodologia XP) e da lista priorizada de
requisitos (SCRUM). Entretanto, tais atividades podem vir a não contemplar
plenamente os requisitos de usabilidade de um software [Jokela & Abrahamsson, 2004].
Construção das Interfaces
A Engenharia da Usabilidade é uma disciplina da Interação Humano-Computador
que estimula a realização das atividades de design e avaliação das interfaces antes da
implementação em código das mesmas [Baranauskas & Rocha, 2003]. Já nos métodos
ágeis, é costume iniciar o desenvolvimento de um produto sem uma definição da
estrutura geral do produto (incluindo suas interfaces).
Como se trata de uma metodologia de desenvolvimento em pequenos ciclos,
existe a real possibilidade das características atribuídas às interfaces passarem por
mudanças durante o tempo. Dependendo do impacto das mudanças nas interfaces, elas
podem se tornar um fator complicador para os usuários que já venham utilizando o
sistema entregue em ciclos anteriores.
Realização de Testes
Embora as atividades de testes sejam enfatizadas nas metodologias ágeis, não
existem práticas de específicas para avaliar a usabilidade do produto desenvolvido
43
[Bankston, 2003]. Os ciclos de desenvolvimento curtos acabam por motivar a equipe a
realizar apenas atividades de inspeções de código e testes unitários.
2.5. Propostas de Integração da Usabilidade em Processos Ágeis
Pesquisas (ainda em pequeno número) vêm sendo realizadas com o objetivo de
propor uma integração entre as práticas existentes dentro da área de IHC e nos métodos
ágeis. Dentre estas, pode-se citar [Memmel et al., 2007], [Chamberlain et al., 2004],
[Constantine & Lockwood, 2001] e [Patton, 2002].
2.5.1. Agile Usage-Centered Design (AUCD)
Constantine (2001), levando em consideração alguns dos obstáculos apresentados
na seção 2.4, definiu um conjunto de práticas de usabilidade, que enfatizam a
modelagem das tarefas e papéis dos usuários, com o intuito de criar cenários de tarefas e
protótipos de interfaces. Ele sugere que o seu processo seja integrado à prática de Jogo
do Planejamento do XP, sendo executado no começo de cada ciclo e completado antes
da implementação das interfaces. O processo não requer documentação, haja vista que
os protótipos construídos seriam validados e/ou evoluídos conforme feedback do
cliente. Dessa forma, Constantine e Lockwood (2001) definem as seguintes atividades:
Os stakeholders (especialistas, usuário representante, desenvolvedores,
clientes, gerentes, etc) são definidos e reunidos em uma reunião;
O contexto para desenvolver o produto é detalhado pelos usuários
representantes e/ou usuários finais;
Funções esperadas para o produto são deliberadas através de brainstorming;
Os papéis dos usuários são definidos em cartões indexados (índex cards),
também em uma sessão de brainstorming;
Os papéis definidos são priorizados, baseando-se na relevância que cada um
destes tem para o sucesso do projeto;
As descrições (casos de uso) das tarefas a serem realizadas por cada papel
dentro do sistema são definidas em sessão de brainstorming e formalizadas em
cartões indexados;
44
Após a definição, as tarefas (casos de uso) são priorizadas, primeiro pela
freqüência antecipada ou pela sua comunalidade e, por último, pela
importância total para o sucesso do projeto. Subdividem-se em três classes:
requeridas, desejadas e deferidas;
Os cartões devem ser classificados em alguma das três categorias: necessário
(“faça na primeira versão”), desejado (“faça se tiver tempo durante essa
versão”) e descartável.
As tarefas são organizadas em grupos de afinidade, baseando-se em suas
semelhanças e interdependência.
Um protótipo de papel deve ser criado, onde cada protótipo deve representar
uma tarefa do grupo. O foco da prototipação deve se concentrar nos cartões
“necessários”, lembrando-se de manter uma mesma consistência na interface
para todos os protótipos;
Os protótipos de papel criados são testados com os usuários, baseando-se nos
cenários criados a partir das descrições das tarefas;
Patton (2002) apresenta um estudo de caso onde relata as experiências obtidas
usando o processo definido acima. As sessões de brainstorming no começo do projeto
proveram valiosas informações sobre o contexto do produto e os resultados obtidos
foram armazenados e consultados no fim de um ciclo de desenvolvimento, visando
verificar se todas as características definidas para o produto foram contempladas.
A criação de protótipos de papel a partir das descrições das tarefas foi considerada
uma maneira fácil e eficiente de transferir o conhecimento de “o que precisa ser feito”
para aspectos visuais de interface. Além disso, o processo ajudou a criar um
entendimento comum entre os desenvolvedores e o cliente. Um dos obstáculos
encontrados foi a ausência de algo que documentasse melhor as informações
relacionadas aos protótipos construídos, pois os designers responsáveis pela construção
dos mesmos nem sempre se encontravam disponíveis para solucionar dúvidas
existentes.
45
2.5.2. Design Interativo em Processos Ágeis (AGILEUSE)
A metodologia AgileUse [Bernardino & Gomes, 2005] surgiu da necessidade de
viabilizar, de forma simples e eficaz, a inserção do design interativo, e conseqüente
valorização da usabilidade, em empresas de pequeno e médio porte. Ela baseia-se na
estrutura básica de processos de desenvolvimento unida a especificações das normas
ISO 13407 e ISO TR 18529, bem como em práticas e valores das metodologias ágeis de
desenvolvimento de software.
Esta estratégia divide-se em seis fases básicas: Planejamento, Especificação,
Captura, Prototipação, Testes e Implantação. O foco desta metodologia concentra-se em
apresentar as atividades que um especialista em usabilidade (Designer Interativo) pode
realizar durante um ciclo de vida ágil. Tais etapas serão descritas nos parágrafos abaixo.
Convém ressaltar que esta metodologia, juntamente com a XPU [Vasconcelos et
al., 2004], foram as duas únicas estratégias identificadas em âmbito nacional que propõe
a integração entre os conceitos vistos nas áreas de Interação Humano-Computador
(IHC) e Desenvolvimento Ágil. Optou-se por detalhar a metodologia AgileUse, haja
vista sua similaridade de características com a proposta deste trabalho.
Figura 2.4 – Visão geral da metodologia AGILEUSE, retirada de Bernardino & Gomes (2007).
A fase de Planejamento tem como objetivo especificar a maneira como as
atividades de design interativo são incluídas no projeto (ciclo de vida, recursos etc.) e
formalizá-las através de um plano de projeto. Atividades realizadas:
1. Reunião de planejamento com o cliente;
2. Identificação e planejamento do envolvimento do usuário dentro do projeto;
3. Escolha das práticas de interação humano-computador que serão utilizadas
durante o projeto; e
4. Planejamento das atividades escolhidas em cronograma.
46
Técnica sugerida: Entrevista com o cliente.
A fase de Especificação consiste em estabelecer os requisitos dos stakeholders,
levando em conta as tarefas e contexto de uso do software. Atividades realizadas:
1. Definição dos stakeholders envolvidos no projeto;
2. Entendimento sobre o sistema (tarefas, usuários e contexto de uso), com
auxílio de um especialista do domínio do software a ser produzido; e
3. Geração de requisitos de usabilidade, que consiste em uma reunião com o
analista de sistemas para tratar dos requisitos identificados e desejados para o
software a ser desenvolvido.
Técnicas sugeridas: Entrevistas e brainstorming.
A fase de Captura consiste em esclarecer as características identificadas na fase
anterior (usuários, tarefas e contexto de uso), validando e identificando novos requisitos
do usuário. Atividade realizada: observar e/ou interagir com o usuário, com o objetivo
de validar ou encontrar novos requisitos.
Técnicas sugeridas: Etnografia rápida [Millen, 2000] e entrevistas com usuários.
A fase de Prototipação consiste na criação de potenciais soluções de projeto da
interface. Atividades realizadas:
1. Reunião com a equipe de designers, de forma a entrar em consenso sobre o
conteúdo das interfaces e os requisitos especificados anteriormente e;
2. Desenvolvimento dos protótipos de interface do usuário, após finalização da
atividade anterior.
Técnicas sugeridas: prototipação em papel (baixa fidelidade) ou em HTML.
A fase de Testes consiste em uma avaliação da interação do usuário e fontes
representativas (ex: Especialista em Usabilidade e Especialista no Domínio) com o
sistema ou protótipo. Atividade realizada: validação dos protótipo/sistema pelos
usuários finais, sob supervisão do Designer Interativo.
Técnicas sugeridas: avaliação heurística [Nielsen, 1993], grupos focados [Caplan,
1990] e testes de usabilidade [Nielsen, 1993].
A fase de Implantação consiste em obter um feedback dos stakeholders após a
implantação do software. Atividades realizadas:
47
1. Investigar e documentar, junto ao usuário final, o impacto do sistema no
contexto de uso, questionando aspectos sobre sua usabilidade, e
2. Apoio ao usuário em situações em que exista dificuldade de uso do
protótipo/sistema desenvolvido.
Técnicas sugeridas: questionário de satisfação e entrevistas com os usuários.
2.5.3. Agile Human Centered Software Engineering (CRUISER)
Memmel et al. (2007) definiram um ciclo de vida ágil e multidisciplinar,
envolvendo os conceitos de engenharia de software e design de interface. A estratégia
CRUISER é baseada nas características e práticas do modelo XP, e objetiva promover
um trabalho colaborativo entre o engenheiro de software e o engenheiro de usabilidade.
O termo “Human” existente no título da estratégia diz respeito à preocupação
desta em levar em consideração as experiências e emoções relatadas pelo usuário
durante a utilização do produto.
A Figura 2.5 ilustra uma visão geral da estratégia CRUISER, composta por cinco
fases principais: Requisitos Iniciais de Interface (Initial Requirements Up-Front),
Concepção Inicial (Initial Conceptual Phase), Construção e Teste (Construction & Test
Phase), Implantação (Deployment Phase) e Produção (Production Phase). Cada uma
destas fases será explorada com maiores detalhes a seguir.
Figura 2.5 - Visão geral do processo CRUISER, retirada de Memmel et al. (2007)
48
O processo inicia-se com a Definição dos Requisitos Iniciais de Interface,
realizando as atividades de análise da metodologia XP e objetivando reunir modelos
ágeis que descrevam as necessidades dos usuários e os objetivos das tarefas do sistema.
Neste momento são executadas as atividades de análise das necessidades dos usuários,
investigação de papéis e tarefas dentro do sistema, além dos objetivos em usabilidade
dentro do sistema (“Quão usável necessita ser o meu produto?”).
Esta etapa reúne práticas existentes nos métodos ágeis, na área de IHC e design.
Sendo assim, esta fase segue as atividades definidas em [Constantine & Lockwood,
2001] e vistas na seção 2.5.1. Ou seja, faz uso dos métodos de cartões indexados para
reunir os requisitos do sistema. Os papéis dos usuários e as tarefas a serem realizadas
também são vislumbrados e priorizados.
Pode-se destacar uma técnica desta fase: o uso de cenários. Eles são utilizados
para modelar os mais diferentes aspectos da interface (usuários, tarefas, interações),
visando um consenso no entendimento destes aspectos pelos desenvolvedores e uma
melhor comunicação com os demais stakeholders.
Outras técnicas também são utilizadas durante esta etapa: brainstorming
(definição de tarefas), grupos focais (durante o jogo do planejamento) e uso de guias de
estilo “leves” (conjunto de recomendações ergonômicas).
Outros dois aspectos são importantes de serem considerados nesta fase: (i)
constante preocupação desta metodologia em considerar os usuários que realmente
utilizarão o sistema, ao invés de representantes do usuário ou clientes, como descrito em
outras estratégias, e (ii) vislumbram-se alternativas de design de interfaces antes mesmo
dos requisitos terminarem de serem definidos, onde o trabalho do designer de interface
pode influenciar nas metas desejadas para o software (performance, qualidade etc).
A próxima etapa da metodologia trata-se da fase de Concepção Inicial, que
objetiva a geração de protótipos do sistema mais bem detalhados e interativos,
separando a prototipação de interfaces da prototipação arquitetural sempre que possível,
objetivando acelerar o processo e auxiliar no detalhamento dos cenários definidos
anteriormente.
A metodologia CRUISER sugere a realização de um trabalho paralelo, ou seja,
enquanto a arquitetura do sistema está sendo definida, uma especificação comum das
interfaces é gerada e as interfaces necessárias são definidas. As dependências existentes
49
entre a arquitetura do sistema e as interfaces definidas podem ser consultadas em uma
análise das tarefas e cenários definidos na fase anterior.
A atividade de prototipação gera dois tipos de produtos, os protótipos de baixa
fidelidade, caracterizados por serem rapidamente elaborados, mas em alguns momentos
sua simples demais em especificação; e os protótipos de alta fidelidade, mais
rebuscados, utilizados para exploração e testes iniciais de como irá proceder a interação
do usuário, assim como um artefato de entrada para o início da construção do sistema.
Outras importantes atividades também são sugeridas para esta fase, visando
avaliar o conteúdo dos protótipos, evitando assim que a elaboração dos mesmos seja
feito na base da tentativa e erro. As atividades consistem em:
Revisões dos Protótipos - prefere-se, neste momento, realizar atividades de
revisão das interfaces elaboradas ao invés de testes de usabilidade. As revisões
são mais rápidas e mais baratas de serem realizadas. Devem ser propostos
critérios para a avaliação e os defeitos encontrados devem ser registrados em
cartões de defeito.
Inspeção Colaborativa de Usabilidade – trata-se de outra atividade de revisão,
dessa vez de maneira colaborativa. Designers, desenvolvedores, usuários
finais e especialistas em usabilidade podem colaborar com sugestões e
potenciais erros.
Aplicação de Questionários – execução de um questionário definido pela
metodologia (AttrakDiff), que avalia a atratividade de um sistema utilizando
critérios de usabilidade e design. Um diferencial deste questionário consiste
em avaliar critérios relacionados as experiências e a emoções do usuário ao
utilizar o produto.
A próxima etapa da metodologia trata-se da fase de Construção e Teste, que
consiste do início da construção do produto. Nesta fase, o ciclo de vida da CRUISER
praticamente segue os passos definidos pelo ciclo de vida do XP. Uma característica
importante da construção é que os componentes de interface de maior impacto devem
ser desenvolvidos inicialmente e refinados nas próximas iterações.
Uma diferença existente nessa fase consiste na criação de testes de aceitação logo
após o planejamento da iteração, a fim de avaliar as interfaces de usuário, verificando se
seus aspectos contemplam as metas de usabilidade esperadas para o produto. Como no
50
XP, esta fase se encerra com o desenvolvimento de uma parte entregável do produto.
Antes de se iniciar outro ciclo, cada parte entregável do produto pode ser novamente
avaliada usando-se métodos rápidos e baratos, como sugerido em [Gellner & Forbig,
2003].
Caso algum defeito seja encontrado, este é formalizado em cartões de defeito,
recebendo uma prioridade de acordo com seu problema identificado. Uma prática
recomendada pela metodologia nesta fase é a presença de um especialista em
usabilidade acompanhando a prática de programação em pares.
As duas últimas fases da metodologia CRUISE dizem respeito à Implantação e
Produção do produto desenvolvido. Enquanto os usuários estão utilizando o produto,
novas funcionalidades podem ser requisitadas, ou questões emocionais e de usabilidade
podem ser elucidadas pelos usuários durante a interação com o sistema. O ciclo de vida
permite retornar a fases anteriores de forma que estes novos requisitos sejam tratados.
2.5.4. Análise Comparativa Entre os Trabalhos Apresentados
Após a apresentação das propostas de integração acima, este trabalho faz uma
análise comparativa entre as propostas, destacando os pontos em comum e as diferenças
identificadas. A análise comparativa foi realizada reunindo-se os critérios definidos por
Chamberlain et al. (2006) e por este trabalho como os pontos-chave de interseção entre
os métodos ágeis e as práticas de usabilidade.
São eles: (i) envolvimento do usuário; (ii) método ágil associado; (iii)
colaboração; (iv) modelagem de usuários e tarefas; (v) prototipação e (vi) realização de
testes; (vii) ciclo de vida e (viii) gerenciamento das atividades.
51
Tabela 2.2 - Comparativo das Integrações da Usabilidade em Processos Ágeis
Critérios
Propostas Apresentadas
AUCD
AGILEUSE
CRUISER
Envolvimento do usuário
Representante do
usuário, usuários
finais, cliente
Representante do usuário,
cliente
Cliente, usuário final.
Método ágil associado
XP
XP
XP
Colaboração
Reuniões,
brainstorming,
Grupos focais,
entrevistas, brainstorming
Grupos focais, reuniões,
brainstorming.
Modelagem de Usuários
e Tarefas
Cenários, Cartões
indexados
Brainstorming,
Etnografia rápida
Cenários, Cartões
indexados
Prototipação
Protótipos de baixa
fidelidade (papel)
Protótipos em papel ou
HTML.
Protótipos de baixa e
alta fidelidade, guias de
estilo, alternativas de
design
Realização de Testes
Avaliação dos
protótipos pelos
usuários.
Avaliação Heurística,
Testes de Usabilidade
Inspeção Colaborativa,
Questionários,
Avaliação de Protótipos,
Testes de Aceitação
Ciclo de Vida
Foco na fase de
Planejamento do
XP
Ciclo de vida próprio.
Atividades realizadas em
paralelo ao ciclo de vida
do XP.
Ciclo de vida próprio.
Foco em atividades
anteriores à fase de
codificação do XP.
Gerência das Atividades
Especialista,
Gerente de Projeto
e Equipe do Projeto
Sob responsabilidade do
Designer Interativo
Especialista em
Usabilidade e Gerente
de Projetos
Envolvimento do usuário – verifica-se que a maneira como o usuário é
envolvido dentro do processo sofre variações. Em todas as estratégias a presença do
cliente é um consenso (seguindo filosofia do XP), mas em algumas ainda verifica-se a
possibilidade de participação de um representante do usuário e não o usuário final em si,
fatos este que podem comprometer, principalmente, a definição das reais necessidades
em usabilidade do produto.
Métodos ágeis associados – em todas as metodologias pesquisadas, o XP se
mostrou como a melhor alternativa para integração com as práticas de usabilidade. Em
nenhuma delas foram citadas práticas do Scrum.
52
Colaboração – o ambiente de colaboração das propostas acima compartilha, de
formal geral, das mesmas práticas: reuniões com o usuário (ou cliente), brainstorming e
grupo focais. Tais práticas são baratas e simples de serem implementadas.
Modelagem de usuários e tarefas – neste critério, as propostas AUCD e
CRUISER utilizam-se das mesmas atividades de cenários e cartões indexados.
Entretanto, os cenários são utilizados com mais freqüência pela estratégia CRUISER,
utilizados como instrumento de comunicação e consenso entre desenvolvedores,
usuários e demais stakeholders.
Prototipação – a atividade de prototipação é considerada de maneira diferente
pelas três estratégias. AUCD considera apenas a realização de protótipos em papel, pois
considera os protótipos de alta fidelidade muito caros de elaborar. AGILEUSE sugere o
uso de ambos os tipos de protótipos, mas não informa o nível de detalhamento dos
protótipos de alta fidelidade (HTML). CRUISER sugere protótipos em papel e
protótipos de alta fidelidade (onde se possa avaliar a navegação e outros itens de
design), que podem ser evoluídos durante os ciclos de desenvolvimento. Além dos
protótipos, guias de estilos “leves” (pouca documentação) e a criação de alternativas de
design para cada protótipo também são sugeridas pela CRUISER.
Realização de Testes – as atividades de avaliação diferem em todas as três
propostas. AUCD sugere uma rápida avaliação dos protótipos em papel elaborados
pelos usuários finais, o que pode ser insuficiente para garantir uma maior usabilidade do
produto. AgileUse sugere a realização de práticas conhecidas da Engenharia da
Usabilidade, a avaliação heurística [Nielsen, 1994] e os testes de usabilidade. Não são
detalhadas como tais práticas são realizadas, mas este trabalho acredita que elas
funcionam se forem adaptadas para a realidade ágil. CRUISER propõe práticas já
adaptadas para o modelo ágil, como a inspeção colaborativa, o questionário próprio
(AttrackDiff), além de se utilizar da estratégia de avaliação de protótipos em papel de
AUCD.
Ciclo de Vida – Das três propostas, duas possuem seu próprio ciclo de vida, que
caminha em paralelo com o ciclo de vida de desenvolvimento ágil. AGILEUSE separa
por completo suas atividades do ciclo de vida ágil, concentrando-as ao Designer
Interativo, um papel dentro da equipe responsável pelo conhecimento em usabilidade.
CRUISER possui uma filosofia diferente, incluindo as fases do ciclo de vida do XP
dentro do seu ciclo de vida. Ou seja, as práticas de desenvolvimento ágil e usabilidade
53
estão integradas em um único ambiente. AUCD possui uma idéia oposta a CRUISER,
onde suas atividades estão incluídas dentro da fase de planejamento do XP.
Gerência das Atividades – a responsabilidade pela integração dos conceitos
discutidos até então é um compromisso de cada membro da organização. Entretanto, é
necessário que existam papéis definidos para promover esta integração. O sucesso da
aplicação de todas as propostas acima está condicionado à existência de uma pessoa ou
equipe que promova as práticas e o conhecimento em usabilidade e a um apoio do corpo
gerencial da organização, de forma a desburocratizar o processo.
2.6. Design Participativo e sua Integração com os Métodos Ágeis
Design Participativo, ou Participatory Design, trata-se de uma área de pesquisa
composta de diversos métodos, com o objetivo principal de promover o envolvimento
do usuário final nas diferentes fases de um processo de desenvolvimento de software.
Técnicas de DP visam promover a atuação direta do usuário em várias etapas do
processo de design, como na identificação e definição do problema, requisitos e análise,
design de alto nível, design detalhado, avaliação, customização pelo usuário e redesign.
Além disso, podem auxiliar os usuários a pensarem sobre e a analisarem seu próprio
processo de trabalho [Melo & Baranauskas, 2006].
Dentre as técnicas existentes, podemos citar brevemente:
Personas: prática de criar pessoas fictícias (personas) que possuam nome,
ocupação, família, amigos etc. Os defensores desta técnica argumentam que
pessoas fictícias exercem atração sobre as reais, permitindo que aspectos
comportamentais sejam analisados [Pruitt & Grudin, 2003].
Cenários: descrição de uma seqüência de ações e eventos envolvendo os
atores de um sistema. Podem ser expressos de diversas maneiras, como
narrativas textuais e storyboards [Simon, 2000]. Além disso, podem ser
descritos em uma linguagem formal, semi-informal ou informal.
Etnografia: técnica utilizada para observar o cotidiano de trabalho dos
usuários e registrar anotações sobre como são realizadas suas tarefas, com o
intuito de melhorar o entendimento dos requisitos organizacionais e sociais
[Millen, 2000].
54
Protótipos: versões iniciais do sistema, utilizadas para demonstrar conceitos,
descobrir e validar requisitos, vislumbrar opções de interface gráfica e
antecipar possíveis problemas de interação entre o usuário e o sistema. O
desenvolvimento rápido de protótipos auxilia no controle de gastos (evitando
manutenções futuras) e permite que o usuário tenha contato com o sistema no
início de construção do mesmo.
2.6.1. Similaridades e Diferenças entre o Design Participativo e as Práticas
das Metodologias Ágeis
Percebe-se que as técnicas expostas acima se assemelham a algumas já
apresentadas durante este capítulo e expostas na Tabela 2.2. Dessa forma, é possível
vislumbrar integrações entre as práticas de design participativo e de desenvolvimento
ágil, em especial as pertencentes à metodologia XP.
Rittenbruch et al. (2002) demonstram, de modo geral, algumas diferenças e
características em comum mais importantes, levando em consideração a metodologia
XP e as práticas de design participativo definidas anteriormente.
Envolvimento do usuário – dentro de um projeto participativo existem diversos
níveis de participação e escolha dos usuários, levando em consideração aspectos como
tamanho da organização, limitações de tempo e recursos, dentre outros. No XP, não
existe uma especificação para o processo de escolha dos usuários. Geralmente, o usuário
escolhido é uma pessoa que supostamente trabalha para uma área em que o sistema está
sendo desenvolvido.
Jogo do Planejamento – descreveu-se nas seções anteriores que o jogo do
planejamento é o momento onde são confrontadas as expectativas e necessidades dos
usuários perante o sistema, com o retorno da equipe de desenvolvimento sobre a
viabilidade de construção destes aspectos no sistema. O resultado desta prática é a
geração de cartões, onde estes aspectos são definidos e priorizados para o
desenvolvimento. Apesar de promover a participação de diversos atores (equipe,
representante do usuário, gerentes etc), esta prática difere da existente no design
participativo, chamada apenas de Jogos [Iacucci et al., 2000]. Nesta última, há uma
representação mais complexa e participativa do ambiente, onde os atores são
convidados a participar de uma dinâmica que explora situações de trabalho e
55
identificação de necessidades. Uso de cenários, definição de personas e etnografia
podem ser realizadas neste momento.
Estórias de usuário – a metodologia XP costuma definir as estórias de usuários
em cartões, como descrito no item acima, como artefatos de entrada para a equipe de
desenvolvimento. Em um projeto que utilize práticas de design participativo, utiliza-se
do mesmo recurso, entretanto, o conceito é estendido. Estórias podem ser utilizadas para
refletir as experiências de designers em projetos anteriores, servindo como um
instrumento de comunicação entre os 7ers e usuários [Beck, 2000].
Prototipação – os conceitos de prototipação iterativa são similares. Em ambos os
casos, é estimulado o envolvimento contínuo do usuário (no caso, representante do
usuário) no projeto e avaliação constante dos protótipos em construção, promovendo
dessa forma uma evolução dos protótipos de maneira colaborativa.
2.7. Considerações Finais do Capítulo
Este capítulo apresentou um estudo sobre os métodos ágeis e sua integração com
conceitos e práticas de usabilidade e de design participativo. Durante o estudo,
percebeu-se que tais métodos surgem como uma interessante alternativa aos métodos
tradicionais, em especial para as organizações que não desejam (ou não podem) investir
recursos e tempo em atividades comuns de engenharia de software, mas que se
preocupam com a qualidade dos seus processos e produtos entregues aos usuários.
Viu-se também que, para se obter melhores resultados com esta abordagem de
desenvolvimento, é necessário promover um ambiente de colaboração e participação do
usuário final do produto durante todas as fases de um ciclo de vida do projeto. Este é um
aspecto que deve ser integrado à característica dos métodos ágeis, que focam suas
atenções em um representante do usuário ou o próprio cliente.
As práticas de usabilidade auxiliam as organizações a extrair, com maior
produtividade, um conjunto de informações sobre os usuários, tarefas e o contexto de
uso que, se bem utilizadas, contribuem para a construção de produtos mais usáveis. As
práticas de design participativo auxiliam as organizações a promover um ambiente de
colaboração do usuário com a organização, gerando credibilidade ao projeto.
56
Como visto nas últimas seções, esforços vêm sendo realizados para promover a
integração de práticas de usabilidade dentro do ambiente de desenvolvimento ágil, e os
primeiros resultados já começam a ser observados nas propostas apresentadas. Ressalta-
se a importância da existência de um especialista em usabilidade dentro da equipe,
como forma de orientar e estimular os demais integrantes sobre as práticas de
usabilidade, haja vista que o foco da equipe de desenvolvimento se concentra na
construção do produto.
3. Usabilidade como Instrumento de Mudança
Cultural e Estratégica nas Organizações
Este terceiro capítulo apresenta o conceito de usabilidade como instrumento de mudança
organizacional. A partir de contribuições obtidas na literatura, são propostas estratégias com o
intuito de auxiliar as organizações a institucionalizar a usabilidade em seus processos de
trabalho. Logo após, investiga-se as normas ISO 13407, ISO TR 18529 e o People CMM, suas
respectivas contribuições para o amadurecimento dos processos da organização e qualificação
de mão-de-obra, além de uma avaliação da aderência com os métodos ágeis.
3.1. Introdução
Com o advento da Web, as práticas e conceitos de usabilidade começaram a serem
experimentados em projetos reais de mercado, devido principalmente à crescente oferta
dos mais variados serviços on-line, situação esta que coloca o usuário em constante
interação com diversas estruturas diferentes de interface.
Durante os últimos vinte anos, a área de pesquisa de Interação Humano–
Computador (IHC) vem acompanhando a evolução dos dispositivos computacionais,
desenvolvendo e aprimorando uma considerável quantidade de técnicas e conceitos,
sempre tratando como objetivo principal uma evolução da interação entre o usuário e
seus sistemas interativos.
Entretanto, as práticas de IHC existentes continuam a ser subutilizadas e de difícil
entendimento pelas organizações e suas equipes de desenvolvimento, especialmente se
considerada a realidade do mercado brasileiro. Seffah e Metzker (2004) justificam esta
situação, relatando que o principal motivo pela existência dessa resistência condiz no
fato de que estas técnicas foram desenvolvidas de maneira independente às práticas
existentes na área de Engenharia de Software.
Outra resistência encontrada na literatura condiz à maturidade das organizações.
Na tabela 3.1, Olsen (2002) ilustra quatro estágios de maturidade dos produtos
desenvolvidos pelas organizações, agrupados pelas expectativas de mercado. Quanto
maior o estágio, maior deve ser o conjunto de características que satisfaçam às
58
expectativas de seus usuários. Dessa forma, percebe-se que para chegar a um nível onde
sejam considerados aspectos de usabilidade, uma organização precisa realizar atividades
que visem tornar o seu produto mais fácil de ser utilizado.
Tabela 3.1 - Estágios de Maturidade de Produtos, adaptado de Olsen (2002)
Estágio 1:
Introdução
Estágio 2:
Extensão
Estágio 3:
Utilização
Estágio 4:
Refinamento
Diferenças-chave
Inovação
Funcionalidade
Usabilidade
Preço
Comportamentos
do cliente
Clientes
ansiosos para
experimentar
novos
produtos são
tolerantes às
imperfeições
e problemas
de usabilidade
Clientes esperam
um produto
completo e
escolhem os que
possuem mais
funcionalidades
Clientes esperam
funções
avançadas e
escolhem o
produto que seja
de maior
facilidade de
utilização.
Clientes esperam
um produto
impecável e
escolhem aquele
que apresente o
menor preço.
Ponto Focal de
Desenvolvimento
Fazer o
produto ser
funcional
Adicionar novas
características e
corrigir erros
Tornar o produto
fácil de ser
utilizado
Reduzir custos de
desenvolvimento
e manutenção
Soma-se a este cenário o uso do conceito de usabilidade com diferentes
significados, dificultando o entendimento principalmente por parte das equipes de
desenvolvimento de software. Seffah e Metzker (2004) apresentam um exemplo, que
ilustra a conceituação do termo usabilidade, de três maneiras distintas.
A capacidade do produto de software de ser entendido, aprendido, usado e
atrativo para o usuário, quando utilizado em condições específicas [ISO 9126,
1991];
Medida na qual um produto pode ser utilizado por usuários específicos, para
atingir objetivos específicos com eficiência, eficácia, e satisfação em um
contexto de uso específico [ISO 9241, 1996];
A facilidade com que um usuário pode aprender a operar, preparar entradas e
interpretar saídas de um sistema ou componente [IEEE 1601, 1998].
59
Dessa maneira, percebe-se a necessidade de um profissional que apóie a
organização a tornar seu produto mais usável, desmistificando os conceitos e práticas de
usabilidade em seus processos de trabalhos.
3.1.1. O Cenário Atual e os Desafios dos Profissionais de Usabilidade
Investigando as contribuições da literatura, verifica-se que desde o início da
disseminação dos conceitos de usabilidade no mercado, o profissional (seja ele um
especialista em usabilidade ou não) interessado em aplicar estes conhecimentos,
necessita desprender esforços para conseguir convencer uma organização
desenvolvedora de software sobre a importância em considerar aspectos de usabilidade
durante a construção de seus produtos.
Brown (1997) já relatava o não cumprimento das especificações de usabilidade
definidas para projetos de software. Shneiderman e Kreitzberg (2000) reforçaram este
fato, citando experiências nas quais eles conseguiam convencer a alta direção de
organizações, mas não obtinham apoio de gerentes de projeto e desenvolvedores, sendo
esta falta de apoio justificada pelos prazos curtos e orçamentos limitados para
construção de seus produtos.
Nos últimos anos, intensificaram-se uma variedade de estudos realizados por
profissionais de usabilidade nos Estados Unidos, Europa, Ásia e Austrália. Eles
desejavam, além de traçar um perfil do profissional de usabilidade, descobrir quais os
principais obstáculos encontrados e experiências de sucesso em usabilidade que
existiam em casos reais de mercado.
Ji e Yun (2003) realizaram duas diferentes pesquisas no mercado coreano, uma
com profissionais de tecnologia e outra com profissionais de usabilidade. O principal
problema identificado foi a diferença encontrada entre os resultados de um produto e os
requisitos definidos pelos usuários. Outras questões importantes identificadas incluíam:
resistência da organização em aceitar atividades de usabilidade durante o projeto, a
necessidade da existência de uma maior quantidade de profissionais e de uma maior
maturidade em usabilidade das organizações.
Gulliksen e colegas (2004) realizaram uma pesquisa com profissionais na Suécia,
onde investigaram os possíveis obstáculos que levariam os projetos a criarem produtos
com pouca usabilidade. Critérios como processos de desenvolvimento, métodos de
usabilidade, envolvimento do usuário e comportamento organizacional foram
60
considerados. Dentre os resultados atingidos, destacam-se a falta de compromisso e
apoio aos profissionais de usabilidade, frutos do baixo envolvimento da organização.
Iivari (2006) descreve o papel do profissional de usabilidade como um
representante do usuário no projeto, afirmação que destoa dos princípios dos métodos
ágeis (onde é requisitada a presença constante do usuário). Ele também afirma que a
função deste profissional é a de garantir que o conhecimento sobre as necessidades dos
usuários seja levado em consideração durante todas as fases de construção de um
produto, ressaltando a importância em considerá-las desde o início do projeto.
Bruno e Dick (2007) realizaram pesquisas com profissionais de usabilidade do
mercado australiano de software, onde encontraram deficiências relacionadas,
principalmente, à inclusão de atividades de usabilidade em processos de
desenvolvimento e ao relacionamento dos objetivos de usabilidade e requisitos durante
o início do projeto, em conjunto com os requisitos de usuário e negócio.
Analisando os trabalhos acima, conclui-se que o quadro recente de
desenvolvimento de software não se encontra favorável à existência de um profissional
de usabilidade que estimule, oriente e valide a qualidade de interação de produtos
desenvolvidos. Fazendo-se um resumo do que foi citado até agora, as lições aprendidas
da literatura indicam os principais desafios a serem conquistados por estes profissionais:
Os usuários necessitam ser representados durante todo o projeto, seja por
envolvimento próprio ou por envolvimento do profissional de usabilidade;
É imperativo o apoio de todos os stakeholders do projeto às atividades de
usabilidade, incluindo a gerência e a equipe executora do projeto;
A inclusão de atividades de usabilidade no ciclo de vida de um projeto é de
fundamental importância para tornar possível a institucionalização da
usabilidade nos processos da organização;
Torna-se necessário um esforço para incrementar a credibilidade e maturidade
da usabilidade em projetos de software da organização;
O profissional de usabilidade deve ser flexível e inovador durante a realização
de suas atividades.
61
Os objetivos a serem atingidos com a usabilidade em um projeto devem ser
associados aos requisitos do sistema o mais cedo possível, em conjunto com
os objetivos dos usuários e os objetivos de negócio.
Todos os desafios acima buscam um objetivo em comum: promover uma
mudança na cultura organizacional. Qualquer profissional interessado em introduzir
práticas de usabilidade em uma organização com processos estabelecidos deve,
inicialmente, realizar uma auto-reflexão e perceber a importância do seu papel como um
agente de mudanças.
Caldas (2002) é partidário desta teoria, ao comentar que a falha na adoção dessa
visão de mudanças pelo profissional (seja ele um especialista em usabilidade ou gerente,
por exemplo) significa aumentar as chances de falha em introduzir, de maneira
integrada e eficaz, a usabilidade nas práticas de uma organização. Todas as boas
intenções envolvidas, toda a competência técnica e todas as argumentações lógicas a
favor dos usuários reais podem não causar necessariamente as mudanças
organizacionais indispensáveis e desejadas.
Ou seja, deve-se compreender o que realmente motiva e faz com que as
organizações realizem mudanças em seus processos. Esta linha de pensamento, apoiada
por Mayhew e Bias (2005), deve receber uma prioridade semelhante à destinada às
demais atividades de integração da usabilidade em processos de desenvolvimento.
Tal quadro, descrito nos parágrafos acima, se torna mais preocupante quando é
feita uma reflexão sobre sua repercussão dentro do mercado brasileiro, onde se
identificam raros casos onde os conceitos de usabilidade são considerados parâmetros
críticos de negócio.
Com exceção de um relato de experiências apresentado por Endler e Pimenta
(2004), não se encontram evidências de pesquisas sendo realizadas no país que tratem
de identificar o perfil do profissional de usabilidade brasileiro, suas experiências de
mercado e o impacto de suas atividades no negócio. Algumas iniciativas voluntárias
visam apoiar os pesquisadores da academia e o profissional de usabilidade no Brasil,
onde se pode citar os capítulos nacionais da UPA
2
(Usability Professional Association)
2
UPA Brasil: Associação Brasileira dos Profissionais de Usabilidade, disponível em:
http://www.wud.com.br/sobre/upa_brasil
62
e da ACM SIGCHI (Associaton for Computing Machinery – Special Interest Group of
Computer Human Interaction), chamado BR-CHI
3
.
3.1.2. Academia x Mercado: Gap de Conhecimento em Usabilidade
Um importante cenário identificado na literatura e que merece destaque, condiz à
existência de um gap entre as contribuições obtidas a partir de teorias de pesquisadores
em IHC e a capacidade das organizações (através de seus especialistas e/ou
profissionais) de absorver este conhecimento.
Compreende-se melhor este cenário, analisando o conceito da disciplina de IHC
disseminado por uma de suas principais comunidades, encontrado em [SIGCHI, 1996].
Nele, identifica-se uma dualidade: conceitualmente, a disciplina deve se preocupar, por
um lado, com aplicação de suas práticas e por outro lado, com a pesquisa sobre os
fenômenos associados com as suas práticas.
Entretanto, se forem avaliados os benefícios da aplicabilidade prática de grande
parte dos trabalhos científicos, verifica-se que poucos benefícios são aproveitados em
projetos de mercado. Além disso, não existe uma preocupação, por grande parte dos
projetos de pesquisa em IHC, em avaliar a relação entre os resultados obtidos com seus
trabalhos e as práticas de IHC utilizadas em demais projetos de mercado [Parush, 2006].
Partindo deste princípio, Parush (2006) delineia diferentes níveis da pesquisa
existente em IHC e define uma taxonomia para estes conceitos. Visualizando a Tabela
3.2, observa-se a definição da pesquisa em IHC como uma estrutura multinível, onde
cada nível representa um tipo diferente de pesquisa. Estes níveis indicam a
profundidade teórica a ser trabalhada com conceitos de IHC, onde esta varia de um
(menos teórico, com menor amplitude de conhecimentos) a quatro (mais teórico, com
maior amplitude de assuntos relacionados à IHC).
Portanto, a habilidade de utilizar e se beneficiar dos diferentes tipos de pesquisas
existentes, e por conseqüência, minimizar o gap de conhecimento existente, depende da
capacidade do profissional realizar a associação definida no parágrafo acima. Dessa
forma, o profissional terá, potencialmente, uma maior facilidade em buscar e encontrar
resultados de pesquisas cujos benefícios possam ser aplicados na prática.
3
BR-CHI: Brazilian Computer-Human Interaction, disponível em: http://ead.unifor.br/brchi.
63
Tabela 3.2 - Taxonomia dos Níveis de Pesquisa em IHC, traduzido de Parush (2006)
Nível
Objetivo
Questões Associadas
Resultados Esperados
1
Investigar usabilidade de um
produto específico
O produto é
satisfatório ao
usuário? Consegue-se
utilizá-lo?
Informações relacionadas à
usabilidade do produto.
2
Explorar/comparar vários produtos
e o impacto da usabilidade no
contexto
Quando, onde e
comparado a que o
produto é utilizado?
Análise comparativa entre
produtos e seus contextos de
uso
3
Desenvolver guidelines a serem
aplicados em designs existentes
Como deve se aplicar
IHC em designs,
contextos e sistemas
similares?
Guidelines de design
baseados em métodos de
pesquisa comportamental.
4
Desenvolver implicações teóricas
para melhor compreensão do
comportamento humano perante
sistemas interativos
Qual a razão de sua
existência? Por que o
produto se comporta
dessa maneira?
Princípios gerais, modelos
e/ou teorias buscando
explicações para fenômenos
identificados.
3.2. Usabilidade como Componente Estratégico nas Organizações
Na medida em que as organizações reúnem esforços para evoluir seus produtos, a
usabilidade torna-se naturalmente um objetivo estratégico. Nielsen (2003) já citava que
organizações que não conseguem entregar produtos que possuam como atributo a
facilidade no uso, potencialmente encontram dificuldades em competir dentro de um
mercado cada vez mais competitivo.
Esta competição não se restringe apenas a organizações estabelecidas no mercado,
mas também inclui novas empresas que são criadas cientes da importância do
desenvolvimento com foco no usuário. Este, por sua vez, cada vez mais se sente
frustrado e culpado quando não consegue utilizar um produto.
Um dos grandes desafios encontrados por uma organização que deseja incluir
atividades de desenvolvimento centrado no usuário trata-se de conseguir alinhar as
expectativas dos usuários com seus objetivos de negócio.
64
3.2.1. Comparando Objetivos de Negócio, de Usabilidade e de Usuário
Objetivos de negócio podem ser definidos como as metas a serem atingidas pela
organização, que venham a caracterizar o sucesso de seu negócio. Bloomer e Wolfe
(2006) e Porter (2006) subdividem este conceito em dois:
Objetivos Externos (business goals): consistem das metas a serem atingidas
visando o sucesso, visibilidade e conseqüente crescimento de uma organização
em relação aos seus concorrentes de mercado. Exemplo: em um call center,
uma meta a ser definida seria um aumento do orçamento da organização em
10% em relação ao ano anterior.
Objetivos Internos (business objectives): metas que, se alcançadas, resolvem
os obstáculos internos que a impede uma organização de alcançar seus
objetivos externos. Exemplo: no mesmo call center, um obstáculo identificado
pode ser a quantidade de tempo de espera do usuário para ser atendido. O
objetivo interno consistiria em diminuir este tempo de espera.
Dessa forma, observa-se que os objetivos internos contribuem, mesmo que de
forma indireta, para a contemplação dos objetivos externos. Geralmente, ambos os
objetivos acima podem ser simples e diretos, porém difíceis de serem atingidos, pois
cada negócio possui seus obstáculos e dificuldades particulares a serem superadas.
Objetivos de usuário podem ser definidos como aqueles que formalizam aos
stakeholders de um projeto as tarefas, atitudes, sentimentos ou quaisquer outras
informações que identificam o que os usuários de um sistema necessitam e desejam
obter com o uso do produto. Portanto, estes objetivos devem ser levados em
consideração quando forem definidos os requisitos de usabilidade de um produto. Como
exemplo, pode-se citar: reduzir a frustração do usuário, mantê-lo informado sobre o que
ocorre no sistema, dentre outros.
Objetivos de usabilidade visam identificar o que deve ser feito em termos de
usabilidade pela organização, para que seus produtos e processos sejam melhorados.
Eles visam apoiar os objetivos de negócio e de usuário definidos, permitindo que exista
um consenso entre todos os envolvidos no projeto sobre os conceitos de usabilidade.
Assim como os objetivos de usuário, estes objetivos devem ser levados em consideração
ao se estabelecerem os requisitos de usabilidade do sistema.
65
Retornando ao exemplo do call center definido por Porter (2006), supõe-se a
identificação um objetivo de negócio como sendo a redução da fila de espera das
ligações recebidas. Um objetivo de usabilidade que poderia ser alinhado a este
objetivo consistiria de uma melhoria na produtividade dos operadores do call center.
Um objetivo de usuário identificado consistira de tornar a navegação do sistema mais
simples, pois os usuários relatavam dificuldade no uso. Ou seja, projetando as interfaces
de um sistema com intuito de prover uma eficiência no uso pelos operadores, resultaria
em uma diminuição do tempo que os mesmos levariam para atender as ligações em
espera. Conseqüentemente, o problema do tempo de espera seria amenizado e o objetivo
de negócio seria alcançado.
Um dos grandes obstáculos encontrados em associar objetivos de usabilidade com
objetivos de negócio é a propensão dos profissionais em usabilidade serem
inexperientes no conhecimento sobre o negócio da organização, ou seja, estes não
conseguem enxergar os benefícios de suas atividades em termos de benefícios para o
negócio [Mayhew & Bias, 2005].
Ou seja, é necessário um esforço por parte do profissional de usabilidade, em
conjunto com o analista de negócios da organização, para que seja possível um
alinhamento entre os objetivos de negócio definidos anteriormente e práticas de
planejamento e design. Berkun (2002) sugere algumas atividades, vistas abaixo:
Realizar uma análise do modelo de negócios da organização. Quais são as
áreas com maior importância estratégica e competitiva para a organização, e
como um aumento na qualidade do produto destas áreas pode auxiliá-las a
obter sucesso?
Vislumbrar todas as possíveis conexões lógicas entre as características de
negócio e práticas de usabilidade que devem ser realizadas, identificando os
recursos (pessoal, tempo, custo) necessários para execução;
Adquirir conhecimento sobre o negócio da organização, além de buscar um
bom relacionamento com os tomadores de decisão sobre os negócios e
projetos em andamento, visando aproveitar oportunidades de alinhamento e
apoio para realizar suas atividades.
Nadel (2005) demonstra na Figura 3.1 um exemplo de uma visão geral dos
componentes estratégicos envolvidos em um projeto de um website (Estratégia de um
66
Site) e sua inter-relação com práticas de usabilidade (Elementos de Contrato de
Design). Além dos objetivos de negócio, observa-se que os fatores críticos de sucesso
(onde podem ser incluídos os objetivos de usuários e de usabilidade) e definições de
layout também possuem relevante importância.
Figura 3.1 - Importância em Considerar Objetivos de Negócio, adaptado de Nadel (2005)
Dessa forma, à medida que o profissional de usabilidade for conseguindo alinhar
os objetivos de usabilidade e dos usuários com os objetivos de negócio, maior será a
capacidade deste profissional de conseguir convencer o restante da organização [Souza,
2001]. Os stakeholders terão uma maior facilidade em entender o valor que estas
atividades adicionam ao projeto e ao negócio, passando a considerar como uma das
variáveis a serem levadas em consideração em processo de tomada de decisão
estratégica.
67
3.2.2. A Importância de se Buscar a Maturidade em Usabilidade e a
Conformidade com Normas ISO
Geralmente, executivos ou gerentes possuem conhecimento apenas sobre os
efeitos de um bom design, além de uma pequena idéia de práticas, profissionais e
desafios de usabilidade que são necessários para se obter uma maior qualidade na
interação de um produto [Berkun, 2002]. Ou seja, estes não possuem a maturidade em
usabilidade suficiente para incluir este conceito em seus processos e projetos.
Cabe ao profissional de usabilidade desmistificar estes conceitos na organização,
além de identificar oportunidades de melhoria das práticas de usabilidade, quando estas
estiverem sendo utilizadas. Uma maneira de avaliar a situação em que a organização se
encontra em nível de atitude, preparação, estrutura, conhecimento e recursos necessários
para conduzir atividades de usabilidade consiste em realizar uma verificação da sua
maturidade em usabilidade, baseando-se em modelos definidos pela literatura e normas
ISO estabelecidas pelo mercado [Lundmark & Toresson, 2007].
Uma maneira de se adquirir uma visão geral da maturidade em usabilidade de uma
organização consiste em se avaliar modelos de maturidade, verificar suas características
e compará-las com a realidade da organização.
ISO 13407 – Processo Centrado no Usuário para Sistemas Interativos
A ISO 13407 [ISO 13407, 1999] trata-se de um modelo de referência que provê
instruções sobre como obter qualidade de interação, incorporando atividades de projeto
centrado no usuário (UCD) em um ciclo de vida de sistemas interativos computacionais.
De maneira prática, ela retrata os principais pontos do projeto centrado no usuário, sem
entrar em muitos detalhes. Outra característica dessa norma consiste em descrever
princípios e atividades ao invés de diferentes métodos de usabilidade, deixando a cargo
do profissional de usabilidade este aspecto.
Ela considera esta categoria de projeto como uma atividade multidisciplinar, na
qual se incorporam fatores humanos, conhecimento ergonômico e técnicas com o
objetivo de acentuar a efetividade e a produtividade. Os quatro princípios definidos pela
norma e interpretados por Jokela (2008) consistem dos seguintes:
68
Envolvimento do usuário: a eficácia do envolvimento do usuário aumenta à
medida que a interação entre os desenvolvedores e os usuários aumenta;
Alocação de função: deve-se realizar uma especificação apropriada sobre o
que deve ser conduzido pelos usuários e pela tecnologia em um sistema
interativo;
Iteração: devem-se realizar iterações das soluções de design, buscando
melhoria contínua deste design;
Projeto Multidisciplinar: diferentes competências são necessárias para se
realizar um bom projeto centrado no usuário.
Figura 3.2 - Processos para Design Centrado no Usuário na ISO 13407
O foco da ISO 13407 concentra-se nas fases iniciais de desenvolvimento, onde
são sugeridas cinco atividades, como vistas na figura 3.2: quatro estão relacionadas
substancialmente ao projeto centrado no usuário e uma atividade (“Identificar a
necessidade por usabilidade”) diz respeito ao planejamento das quatro primeiras citadas.
Identificar a necessidade por usabilidade – planejar o esforço necessário
para realizar a adoção das práticas de UCD. Ressalta-se importância em
promover o trabalho em equipe e a comunicação intensiva.
69
Entender e especificar o contexto de uso – o contexto de uso deve especificar
os usuários envolvidos, tarefas e ambientes de uso em detalhes suficientes
para prover apoio às atividades de design.
Especificar os stakeholders e requisitos organizacionais – a especificação
destes requisitos deve identificar um conjunto de tarefas a serem realizadas
pelos usuários a serem identificados e os demais membros da organização;
Produzir soluções de design – fazer uso de guias de estilos, padrões de
interface, conhecimento sobre o produto e informações de marketing que
possam ser úteis para se realizar, de maneira multidisciplinar, o design do
sistema interativo;
Avaliar as soluções ante os requisitos definidos – realizar avaliação dos
designs construídos, com intuito de se obter um feedback do que pode ser
melhorado e, além disso, verificar se os objetivos dos usuários e da
organização foram alcançados.
Sendo assim, o profissional de usabilidade, em parceria com o gestor de processos
de desenvolvimento de software, pode utilizar-se desta norma para auxiliá-lo a
identificar, planejar atividades de projeto centrado no usuário de maneira efetiva e
tempestiva e avaliar como elas podem coexistir com os demais processos existentes.
ISO TR 18529:2000 - Processo de Ciclo de Vida Centrado no Humano
A ISO TR 18529 [ISO TR 18529, 2000] surgiu como resultado de uma evolução
da ISO 13407. Sua intenção é tornar o conteúdo da ISO 13407 acessível aos
especialistas em avaliação de processos de software e aos familiarizados com ou
envolvidos na modelagem de processos. Ela pode ser usada na especificação, avaliação
e melhoria de processos centrados no humano, se comportando como um modelo de
avaliação da capacidade e maturidade em usabilidade de uma organização.
O modelo consiste de sete processos (mais detalhes, vide apêndice B), dos quais
quatro destes processos são baseados na ISO 13407, possuindo, inclusive, descrições
semelhantes. Eles são divididos da seguinte maneira:
HCD
4
1 – Garantir o conteúdo de UCD na estratégia do sistema;
4
HCD: Processo de Design Centrado no Humano (Human Centered Design).
70
HCD 2 – Planejar e gerenciar o processo de UCD;
HCD 3 – Especificar os stakeholders e os requisitos organizacionais;
HCD 4 – Compreender e especificar o contexto de uso;
HCD 5 – Produzir soluções de design;
HCD 6 – Avaliar designs ante os requisitos;
HCD 7 – Introduzir e operar o sistema.
Resumidamente, o processo HCD 1 visa integrar as atividades do processo
centrado no usuário com os processos estratégicos da organização, além de definir o
escopo e os objetivos de usabilidade dos projetos. HCD 2 tem o propósito de planejar e
controlar as atividades de usabilidade que serão utilizadas no processo da organização,
definidas nos processos HCD 3 a 6. Estes processos possuem atividades mais técnicas,
com foco na integração com o processo de desenvolvimento existente. Por fim, HCD 7
preocupa-se com o uso do sistema após sua construção, considerando atividades de
usabilidade no suporte ao usuário final.
Na ISO TR 18529 cada um destes processos é definido com um propósito, sendo
posteriormente alcançado com a execução de em um conjunto de práticas básicas, como
visto na Figura 3.3. O propósito do processo é tipicamente alcançado com a
implementação das práticas base, específicas para cada processo. A descrição destas
práticas encontra-se detalhada no apêndice B.
Figura 3.3. Formatos de Processos da ISO TR 18529, traduzido de Jokela (2002)
As práticas existentes nestes processos descrevem o que deve ser feito para
representar e incluir os usuários de um sistema durante o ciclo de vida. O modelo usa o
71
formato comum de modelos de avaliação de processos definido pela ISO 15504 [ISO
15504, 1998], que descrevem os processos que devem ser executados por uma
organização para alcançar objetivos técnicos definidos. Na Tabela 3.3, podem ser
observados os seis níveis de capacidade da ISO TR 18529, baseados no modelo de
escala de capacidade da ISO 15504.
Tabela 3.3 - Níveis de Capacidade dos Processos, segundo a ISO TR 18529:2000
Nível de Capacidade
Descrição
Nível 5: Otimizável
A organização pode, de maneira segura, ajustar o seu processo para
requisitos em particular.
Nível 4: Previsível
A performance do processo possui limites de qualidade e recursos
previstos.
Nível 3: Estabelecido
O processo é conduzido de uma maneira especificada pela organização
e pelos recursos definidos.
Nível 2: Gerenciado
Os requisitos de qualidade, prazos e recursos do processo são
conhecidos e controlados.
Nível 1: Realizado
O processo atinge seu propósito. Tais processos são conduzidos por
indivíduos.
Nível 0: Incompleto
A organização não é capaz de conduzir um processo com práticas de
usabilidade.
Para se atingir os níveis de capacidade (a partir do nível 1) vistos na tabela 3.3,
deve-se proceder com uma avaliação de cada processo. Ou seja, cada um dos sete
processos (HCD 1 a 7) é avaliado de maneira individual, podendo possuir diferentes
níveis de capacidades (de zero a cinco). As atividades de analise destes níveis estão
definidas dentro da ISO 15504 [ISO 15504, 1998] e fora do escopo deste trabalho.
Por exemplo, o processo “Produzir soluções de design (HCD 5)” pode situar-se no
nível 1 – Realizado, enquanto o processo “Avaliar designs ante os requisitos (HCD 6)”
pode situar-se no nível 2 - Gerenciado. Um resultado comum de uma análise deste tipo é
um gráfico apresentando os níveis de capacidade de cada processo.
Bernardino & Gomes (2005) citam que embora o uso primário de um modelo de
avaliação de processo seja para a medição de quão bem uma organização cumpre com
72
os processos incluídos no modelo, estes podem ser usados como uma descrição do que é
requerido com o intuito de projetar e desenvolver processos de design com eficiência.
Voltando ao contexto deste trabalho, na última seção deste capítulo serão
descritos possíveis cenários de integração entre as normas apresentadas e algumas
práticas comuns das metodologias ágeis, investigando suas aderências. Sabe-se que
pode ser inviável para uma organização que trabalhe com processos ágeis adotar todas
as atividades de um ciclo de vida específico para avaliação de projetos de design.
3.3. People CMM (P-CMM)
Ao considerar modelos de capacidade em usabilidade (como vistos na seção
3.2.1), a associação com modelo CMMI (Capability Maturity Model) foi inevitável.
Após uma investigação de modelos associados ao CMMI, encontrou-se o P-CMM.
Diferentemente do CMMI, que concentra sua atenção em processos, o modelo P-CMM
visa concentrar suas atividades em pessoas (profissionais da organização). Verificou-se
sua aplicabilidade neste trabalho, por considerar que as práticas de processos ágeis têm
uma forte influência na forma como os profissionais trabalham. Antes de apresentar que
parte deste modelo motivou esta abordagem, descreve-se a seguir tal modelo.
O People CMM (Modelo de Maturidade de Capacidade de Pessoas) trata-se de um
guia para a implementação de práticas de mão de obra, tendo como principal objetivo
modelar e integrar as melhores práticas para gestão e desenvolvimento da mão-de-obra
da organização para melhorar sua capacidade, isto é, seu nível de conhecimento,
habilidades pessoais e habilidades de processo [P-CMM, 2001].
Este modelo é composto de cinco níveis de maturidade, cada um responsável em
produzir uma transformação na cultura da organização, para equipá-la com práticas cada
vez mais maduras para atrair, desenvolver, organizar, motivar e reter sua mão de obra.
A partir das práticas instaladas, torna-se mais fácil integrá-las com outras atividades de
melhoria de processo da organização [Freitas, 2006].
Os cinco níveis de maturidade consistem dos seguintes:
Nível 1 (Inicial): Gestão de Inconsistência – organizações nesse nível de
maturidade normalmente desempenham suas práticas de gestão de pessoas de
maneira incongruente ou ritualística e apresentam, geralmente, gestores
73
despreparados para desempenharem atividades de gestão de pessoas,
enfrentando dificuldades para reter talentos.
Nível 2 (Gerenciado): Gestão de Pessoas – ao atingir este nível as
organizações já devem executar um conjunto básico de práticas de gestão de
pessoas de maneira disciplinada. Ou seja, o gerente, ou o responsável por
executar atividades gerenciais, começa a tratar as atividades de mão de obra
como de mais alta prioridade em seu trabalho, assumindo a responsabilidade
pelo desempenho e desenvolvimento da equipe executora do projeto.
Nível 3 (Definido): Gestão da Competência - neste nível, a organização
desenvolve a capacidade de gerenciar sua força de trabalho como um ativo
estratégico capaz de sustentar a busca dos seus objetivos de negócio [Josko &
Cortes, 2005]. Uma vez que as competências de mão de obra foram definidas,
o treinamento e o desenvolvimento das práticas devem, de forma mais
consistente, apoiar e motivar o desenvolvimento dos conhecimentos, das
habilidades e das habilidades de processos que as compõem [Freitas, 2006].
Nível 4 (Previsível): Gestão da Capacidade - a organização utiliza a infra-
estrutura de desenvolvimento de competências para quantificar e gerenciar a
capacidade de sua força de trabalho e de seus processos baseados em
competência, possibilitando-a determinar a aptidão para realizar um trabalho.
Nível 5 (Otimizado): Gestão de Mudança - neste estágio, toda a organização
está mobilizada para o desenvolvimento contínuo e para a criação de uma
cultura de produtos e serviços de excelência. Grupos e indivíduos também se
dedicam ao aprimoramento de seus métodos de trabalho e, conseqüentemente,
dos processos baseados em competência.
Uma organização alcança um novo nível de maturidade quando um conjunto de
práticas foi estabelecido ou transformado para fornecer capacidades e resultados na
organização, que não existiam no nível anterior. O foco principal do P-CMM, tratado
em seus níveis de maturidade, é alcançar os objetivos que constituem as seguintes áreas
de interesse [PCMM, 2001]:
Desenvolvimento da capacidade individual;
Construção dos grupos de trabalho e da cultura;
74
Motivação e gestão do desempenho;
Homologação da força de trabalho;
Figura 3.4 - Níveis de Maturidade x Áreas de Interesse, adaptado de Freitas (2006)
Freitas (2006) representa a estrutura conceitual do P-CMM em seu trabalho (como
visto na figura 3.4), onde apresenta uma matriz que relaciona as áreas de interesse acima
com os níveis de maturidade. Este trabalho faz uso desta matriz, focando suas atenções
nas áreas referentes à Construção de Grupos de Trabalho e Cultura e
Desenvolvimento das Capacidades Individuais.
O objetivo principal da área de interesse de Construção de Grupos de Trabalho e
Cultura consiste em promover um ambiente de uma cultura participatória na
organização. Este é um dos cenários que fundamenta as premissas deste trabalho. A
área de Desenvolvimento das Capacidades Individuais visa garantir à organização que
as competências necessárias para realização das atividades de seus processos estão
institucionalizadas.
75
A figura 3.4 destaca em azul as áreas de processo que fazem parte do escopo deste
trabalho. A escolha das áreas descritas abaixo se deveu ao fato das mesmas possuírem
objetivos similares aos de algumas atividades da estratégia deste trabalho (descrita no
capítulo 4).
Cada área de processo possui um conjunto de objetivos, compromissos e
habilidades a serem conquistados, além de práticas a serem executadas, e métricas e
critérios de verificação utilizados para avaliar a maturidade do processo.
Essencialmente, os objetivos das áreas de processo relacionadas ao escopo deste
trabalho são os seguintes [PCMM, 2001]:
Treinamento e Desenvolvimento: garantir que todos os integrantes das
equipes possuam as competências necessárias para realizar suas tarefas, removendo o
gap que possa existir suas competências e as competências requeridas pela organização.
Uma vez que este gap seja controlado, a organização pode direcionar esforços em outras
atividades visando o desenvolvimento profissional de seus integrantes.
Cultura participatória: organizar grupos de trabalho, de forma que os
profissionais trabalhem juntos em tarefas que possua interdependência, com intuito de
se atingir os objetivos compartilhados; compartilhar informações sobre as atividades de
negócio da organização; além disso, promover a existência de um ambiente no qual o
profissional competente exercita suas capacidades e colabora com o seu conhecimento
para a organização.
Analisando as informações descritas nos parágrafos anteriores, percebe-se que as
práticas de gestão de pessoas do P-CMM fortalecem um relacionamento mais
simbiótico entre pessoas e organização, bem como são adequadas à realidade de
organizações que utilizam intensivamente o conhecimento humano como fator de
produção [Curtis et al., 2003].
Josko e Cortes (2005) citam em seu trabalho que a modernização na forma de
gerir pessoas permitirá à organização avaliar o poder de contribuição de todos os seus
colaboradores face às adaptações que essa necessita em cenários voláteis de negócio,
bem como possibilitará a conciliação de expectativas entre a organização e as pessoas
de maneira mais dinâmica.
Observa-se que o cenário supracitado vai de encontro ao cenário de mudanças
identificado nos ambientes de desenvolvimento ágil, face sua volatilidade de requisitos
76
e dinamicidade das equipes de desenvolvimento, com seus processos e respectivas
práticas ágeis, além de seu relacionamento com os usuários/clientes.
Nas próximas subseções, serão apresentadas algumas estratégias identificadas na
literatura que visam auxiliar o profissional de usabilidade e apoiar a organização na
busca pela institucionalização da usabilidade em seus processos e em sua cultura.
3.4. Estratégias de Apoio à Institucionalização da Usabilidade
Até o momento foram vistas normas, modelos e algumas estratégias propostas
para considerar a usabilidade como um elemento estratégico e de negócio, além de
equalizar as contribuições existentes na academia com as práticas de mercado. Viu-se
também a importância em considerar não apenas os processos, mas também as pessoas
da organização envolvidas dentro destas iniciativas.
Como visto nas seções acima, três das principais atividades dos profissionais que
promovem os conhecimentos e práticas de usabilidade das organizações consistem de:
(i) realizar atividades que incluam conceitos de usabilidade em processos da
organização; (ii) avaliar o andamento destas atividades e (ii) convencer e comunicar a
importância do seu trabalho para o restante da organização.
Esta seção pretende descrever, a partir de pesquisas realizadas em casos de
sucesso publicados, um conjunto de melhores práticas que podem ser levadas em
consideração ao se aplicar alguma dessas atividades, objetivando estimular a mudança
de cultura organizacional em usabilidade.
3.4.1. Treinamento em Usabilidade
Em um processo de institucionalização da usabilidade de uma organização, a
atividade de treinamento surge como uma interessante alternativa para promover a
usabilidade e garantir que a organização adquira a competência necessária para executar
atividades que envolvam esse conceito. Schaffer (2004) diferencia dois tipos de
treinamentos que podem ser realizados: treinamento em conhecimento e treinamento em
competências.
Treinamento em Conhecimentos: seu objetivo consiste em capacitar os
participantes sobre as atividades que envolvam usabilidade e a necessidade de executá-
77
las na organização. Deve-se fazer com que eles compreendam a importância dessas
atividades para se obter um aumento na qualidade e competitividade de seus produtos
no mercado. Dessa forma, cria-se uma baseline de aceitação em usabilidade por toda a
organização.
Um treinamento neste formato costuma ter uma duração rápida, de poucas horas.
Pelo fato dele não requerer uma interação e mentoring constantes entre o instrutor e os
participantes e nem envolver atividades práticas, recomenda-se envolver o maior
número de pessoas possíveis, de forma a garantir que os conceitos sensibilizem toda a
organização. Entretanto, para três grupos em especial, o benefício deste treinamento
será percebido com mais facilidade: executivos, membros das equipes de
desenvolvimento e novos funcionários.
Treinamento em Competências: o objetivo desta categoria de treinamento
consiste em capacitar os participantes a executar atividades de usabilidade, durante o
ciclo de vida de um projeto. Existe um conjunto de iniciativas a serem realizadas em
cada estágio de desenvolvimento, e este treinamento deve prover o apoio necessário
para que estas atividades sejam experimentadas pelos seus potenciais praticantes,
preferencialmente, antes do início do projeto.
Treinamentos neste formato costumam ser divididos em módulos e possuem uma
duração maior do que os treinamentos em conhecimentos. Dessa forma, o público-alvo
de cada uma destas capacitações varia conforme o assunto envolvido, sendo em menor
quantidade se for comparado com o treinamento anterior. Entretanto, um papel deve
estar presente durante a maior quantidade de treinamentos possíveis – o gerente ou um
representante – de forma que este possa conhecer as atividades, suas filosofias de
utilização e assim adquirir maior segurança para apoiar tais iniciativas em usabilidade.
Diante do exposto, podem surgir vários questionamentos, dos tipos: (i) como
planejar estes treinamentos; (ii) quais assuntos devem ser considerados e priorizados,
dentre outros. No próximo capítulo este trabalho apresentará sua estratégia, onde uma
das etapas consiste em tentar apresentar respostas relacionadas a estas questões.
3.4.2. Promovendo a Usabilidade para a Organização
Como já mencionado anteriormente, antes de se iniciar qualquer iniciativa de
usabilidade em uma organização, é necessário convencê-la da importância e
78
necessidade de considerar atividades de usabilidade em seus processos. Além dos
mecanismos de treinamentos, existem outras estratégias presentes na literatura que
podem ser utilizadas pelo profissional de usabilidade, de maneira a promover a
usabilidade dentro da organização.
Travis (2006) define um conjunto de três passos que devem ser realizados, de
forma que se consiga convencer a alta direção de uma organização. Este assume que,
conseguindo apoio da alta direção, as demais práticas a serem utilizadas serão aceitas
com maior facilidade. Os passos consistem dos seguintes:
Passo 1: Reúna os principais benefícios com foco na usabilidade: ele
considera quatro em especial: aumento das vendas e do orçamento, fidelização
de clientes, valorização do produto e melhoria de processo.
Passo 2: Personifique os gerentes da organização: quando se deseja vender
algo, é necessário antes se conhecer o perfil do usuário-alvo. A mesma
situação ocorre com os gerentes de uma organização. Antes de se conseguir
convencê-los, deve-se investigar qual perfil os mesmos possuem.
Travis (2006) e Brock (1994) apresentam um modelo de investigação baseado
no modelo de personalidade denominado MBTI (Myers-Briggs Type
Indicator), onde ele personifica os prováveis perfis a serem encontrados,
realizando dois questionamentos.
o Como o gerente prefere receber informações?
o Como o gerente prefere tomar decisões?
Passo 3: Adeqüe os argumentos de acordo com o perfil de gerente: após
conhecer a personalidade do gerente, deve-se adequar seu comportamento de
acordo com a personalidade do mesmo. Travis (2006) cita quatro diferentes
combinações de gerentes, que podem ser vistas com detalhes no apêndice A.
3.4.3. Medir para Justificar os Investimentos em Usabilidade
Um princípio comum do gerenciamento de projetos cita que “se não é possível
medir, não se pode gerenciar” [Cavalcante, 2001]. Ao medir os atributos de qualidade
de um produto, pode-se ter uma idéia mais concreta de que o investimento realizado
está sendo coerente com as expectativas de negócio. Além disso, pode-se medir o
79
desempenho relacionado aos processos da organização, identificando desvios e
deficiências em atividades realizadas pelas equipes.
Sendo assim, o profissional de usabilidade necessita definir um conjunto de
métricas de usabilidade para avaliar seu trabalho. Dessa forma, ele terá uma noção de
quais áreas e produtos desenvolvidos pela organização necessitam de um maior esforço
em usabilidade e conseqüente melhoria no processo.
Para que uma métrica receba a devida importância pela organização, esta deve ser
simples e fácil de ser coletada [Sauro & Kindlund, 2005]. Quando se tratam de métricas
de usabilidade, estes atributos ganham uma importância ainda maior, pois, caso
possuam uma complexidade incomum, o custo para coletá-las será rejeitado pela
organização.
Essencialmente, existem duas estratégias diferentes a serem seguidas pelo
profissional, na coleta de métricas de usabilidade:
Coletar métricas de produto, ou seja, indicadores relacionados a atributos
do software desenvolvido, performance e satisfação do usuário, já
conhecidos e disseminados em normas como a ISO 9241-11 e ISO 9126-4.
Como exemplo, cita-se: tempo de duração de tarefas, quantidade de erros
encontrados, grau de satisfação do usuário, dentre outras.
Coletar métricas de processo, relacionadas às atividades de design
centrado no usuário, estas ainda pouco exploradas. Apesar de existirem
normas como a ISO TR 18529, que ditam como realizar estas atividades
(como visto na subseção 3.2.2), não há um relacionamento definido entre
as atividades e métricas de processo.
Schaffer (2004) cita algumas sugestões de métricas de processo interessantes de
serem acompanhadas, tais como: número de projetos que aplicam (ou não aplicam)
atividades de usabilidade, quantidade de profissionais capacitados, quantidade de
membros da organização que aplicam conhecimentos em usabilidade em suas
atividades, dentre outras.
Uma provável dificuldade encontrada por parte do profissional de usabilidade
consiste em identificar quais métricas devem ser levadas em consideração nos projetos
que o mesmo irá acompanhar. Esta dificuldade se acentua quando se leva em
80
consideração as limitações de tempo e custos, existentes nas organizações que utilizem
metodologias ágeis de desenvolvimento, foco deste trabalho.
Neste caso, caberá ao profissional de usabilidade identificar quais métricas
deverão ser utilizadas, preferencialmente unindo métricas de produto e processo. O
critério de escolha das métricas dependerá do contexto da organização. No próximo
capítulo será detalhada a estratégia deste trabalho, que visa auxiliar o profissional a
conseguir identificar este contexto e as respectivas métricas.
3.5. Análise de Aderência
Nas seções anteriores, diversos conceitos foram abordados, tais como: normas
ISO e diversas estratégias de apoio à institucionalização da usabilidade. Dessa forma,
torna-se essencial a realização de uma avaliação da aderência entre tais conceitos, haja
vista que este trabalho os considera complementares e passíveis de potencial integração
e coexistência em uma organização.
Diferentemente da análise comparativa realizada no capítulo dois, nas próximas
subseções serão apresentados os resultados das análises de aderência entre os conceitos.
Os objetivos são investigar e refletir sobre quais os principais pontos de sinergia que
podem ser explorados e os potenciais obstáculos a serem encontrados com a integração
dos conceitos.
Esta análise segue um formato de classificação similar ao utilizado em Marçal et
al (2007), de acordo com a tabela 3.4. Os critérios que guiarão a análise de aderência
entre os conceitos envolvidos serão classificados seguindo três tipos: Aderido,
Parcialmente Aderido e Não Aderente.
Tabela 3.4 - Critérios para Classificação da Análise de Aderência dos Conceitos
Critério
NA
Não Aderente
Não existe aderência entre os conceitos envolvidos.
PA
Parcialmente Aderido
Existem evidências da aderência, mas não de forma plena.
A
Aderido
Os conceitos estão plenamente aderentes entre si.
81
Inicialmente, irá se investigar a aderência dos métodos ágeis (XP e SCRUM) aos
processos da ISO TR 18529:2000. Em seguida, se investigará a aderência das
Estratégias de Apoio identificadas aos processos desta mesma ISO. Maiores detalhes
sobre a descrição dos processos estão incluídos no apêndice B.
3.5.1. Métodos Ágeis versus norma ISO TR 18529:2000
No capítulo 2, foram expostas algumas semelhanças e obstáculos existentes entre
os métodos ágeis e alguns conceitos de práticas de usabilidade (ver seções 2.4 e 2.5). A
análise abaixo se propõe a aprofundar esta relação, realizando uma avaliação da
aderência das práticas de desenvolvimento ágil do XP e de gerenciamento ágil do
SCRUM aos processos da ISO TR 18529:2000, evidenciando as lacunas existentes.
Esta análise visa evidenciar que as práticas existentes nos métodos ágeis
supracitados já satisfazem (mesmo que de maneira indireta), em parte, alguns processos
da norma ISO em questão. Além disso, as lacunas identificadas na análise surgem como
uma motivação para a definição de uma estratégia (que será detalhada no próximo
capítulo) que contenha atividades que visem reduzir tais lacunas, contribuindo para que
os processos ágeis sejam melhorados e acabem por proporcionar um aumento da
capacidade e maturidade em usabilidade da organização.
A análise foi dividida da seguinte forma: as atividades de gestão do SCRUM
serão relacionadas ao processo de definição de requisitos e contexto de uso da ISO TR
18529:2000, e as práticas de desenvolvimento ágil do XP serão relacionadas aos
processos desta ISO com foco nas atividades de design centrado no usuário.
a) ISO TR 18529 versus SCRUM
O propósito do processo HCD 3 (exposto na tabela 3.5), composto de seis
práticas-base, consiste em estabelecer os requisitos organizacionais e dos stakeholders,
levando em consideração suas necessidades, competências e ambientes de trabalho. As
práticas 3.1 a 3.3 determinam o requisitos de alto nível do sistema. As práticas 3.3 a 3.6
definem o detalhamento destes requisitos.
As práticas-base do processo HCD 4 visam auxiliar na identificação das
características dos stakeholders e do ambiente de uso do produto a ser construído.
Segundo a própria ISO, elas podem ser utilizadas como práticas de apoio para se atingir
82
as práticas do processo HCD 3. Como exemplo, para se atingir as práticas 3.3 a 3.6, é
necessário compreender e especificar o contexto de uso, presente nas práticas 4.1 a 4.5.
A atividade de definição do escopo inicial do SCRUM ocorre durante sua fase de
pré-planejamento, no momento de criação da Product Backlog. Durante esta atividade
colaborativa, todos os stakeholders (neles incluem-se os usuários) são formalizados pelo
Gerente de Produto. Após definidos, estes contribuem com informações sobre suas
necessidades, características, e tarefas que desejam realizar para atingir seus objetivos
com o uso do sistema.
A partir da coleta destas informações, o Gerente de Produto possui uma definição
de alto nível das funcionalidades do sistema. De posse destes requisitos de alto nível, ele
então identifica em conjunto com os stakeholders um detalhamento destes requisitos e
os documenta dentro da Product Backlog, por ordem de importância.
Caso sejam identificadas questões relativas ao ambiente de uso do sistema, como
restrições técnicas (como exemplo, a equipe pode necessitar de um treinamento sobre a
tecnologia) ou físicas (ambiente precisa ser modificado para se adequar a solução), tais
informações podem ser consideradas dentro da Product Backlog.
Uma vez firmada, a ordem de importância dos itens da Product Backlog reflete o
compromisso entre a organização e seus stakeholders. Quanto maior a importância,
maior o compromisso em atender o item específico. A Product Backlog delineia o
trabalho que a equipe desenvolverá, em várias iterações (Sprints).
Além disso, a Product Backlog pode ser continuamente atualizada pelo Gerente
de Produto, sempre que ocorra uma mudança nas necessidades dos usuários, novas
idéias por parte das equipes ou quaisquer barreiras tecnológicas que venham a surgir.
Mais detalhes sobre os requisitos (inclusive sobre as tarefas dos usuários) podem
ser incluídos na Sprint Backlog, um artefato que informa os requisitos que serão
desenvolvidos pela equipe em cada ciclo (Sprint) de desenvolvimento.
A cada novo ciclo, novos requisitos são desenvolvidos ou os requisitos anteriores
podem ser modificados e, portanto, necessitam ser verificados pelo Gerente de Produto
em conjunto com os stakeholders.
Porém, antes da execução dos ciclos descritos no capítulo anterior, a atividade de
Reunião de Planejamento do Sprint (Sprint Planning Meeting) é prevista, onde o
83
Gerente de Produto, juntamente com a equipe de desenvolvimento, revisa a Product
Backlog, discutindo os objetivos e o contexto de aplicação dos itens contidos na mesma.
Neste momento, aspectos relacionados ao contexto de uso (como características dos
usuários, suas tarefas e o ambiente físico e organizacional de utilização do sistema)
podem ser identificados pelos envolvidos e levados em consideração posteriormente.
Tabela 3.5 - Análise da Aderência entre ISO TR 18529 versus SCRUM.
Processo
Prática – Base
Prática do SCRUM
Classificação
HCD 3 –
Especificar os
stakeholders e
os requisitos
organizacionais
3.1. Esclarecer e documentar as
metas do sistema.
Construção da Product
Backlog
A
3.2. Definir stakeholders.
3.3. Impor riscos aos stakeholders.
-
NA
3.4. Definir o sistema.
Construção da Product
Backlog
PA
3.5. Gerar os requisitos dos
stakeholders e da organização.
A
3.6. Definir os objetivos de
qualidade no uso.
-
NA
HCD 4 –
Compreender e
especificar o
contexto de
uso
4.1. Identificar e documentar as
tarefas do usuário.
Construção da Product
Backlog
PA
4.2. Identificar e documentar
atributos significantes do usuário.
-
NA
4.3. Identificar e documentar o
ambiente organizacional.
Reunião de Planejamento do
Sprint (Sprint Planning
Meeting)
PA
4.4. Identificar e documentar o
ambiente técnico.
PA
4.5. Identificar e documentar o
ambiente físico.
PA
Não há no SCRUM uma definição formal de objetivos relacionados à qualidade
no uso do sistema, envolvendo aspectos como satisfação, produtividade e eficiência do
usuário. Esta lacuna visa ser preenchida pela estratégia deste trabalho. Além disso, não
existe nenhuma avaliação dos riscos relacionados à segurança, saúde ou bem estar dos
stakeholders na utilização do sistema, como preconiza a prática-base 3.3 desta ISO.
84
b) ISO TR 18529 versus XP
O propósito das práticas-base existentes no HCD 5 consiste em criar potenciais
soluções de design, levando em consideração a experiência e conhecimento dos
participantes, visando: uma melhor comunicação entre os stakeholders, possibilidade da
equipe de desenvolvimento refletir sobre o design antes de construir o produto e
inclusão do feedback dos stakeholders e usuários no sistema no começo do projeto.
Como já visto no capítulo 2, a metodologia XP estimula a constante participação
do usuário (ou um representante do mesmo), considerando-o como um membro da
equipe. Durante a fase de Planejamento, no início do projeto, uma reunião (Jogo do
Planejamento) envolvendo todos os stakeholders é realizada e nela podem ser discutidos
aspectos como o contexto de uso do sistema, requisitos e definição de quais tarefas
serão realizadas pelos usuários e pelo sistema. Uma técnica colaborativa comumente
utilizada é a de grupos focais. Tais atividades ocorrem diversas vezes durante o projeto,
haja vista que em cada ciclo de um projeto XP elas se repetem.
A norma ISO preconiza a definição de um modelo de tarefas para representar
estas informações, entretanto, devido à volatilidade dos métodos ágeis como o XP, esta
informação geralmente é obtida através de brainstorming, sendo documentada
juntamente com os demais requisitos em formato de estórias contidas em cartões (como
visto na figura 2.2 do capítulo 2).
Comumente, um processo de desenvolvimento XP faz uso de protótipos com o
objetivo de explorar o design do produto, investigando possibilidades de design. Além
disso, durante o Jogo do Planejamento, os protótipos podem ser utilizados como
instrumento de comunicação com o usuário para elicitação e validação de requisitos,
apoiando a especificação do sistema (definida nas estórias e seus cartões). Entretanto,
necessita-se de um amadurecimento do XP sobre como representar a usabilidade em
boas práticas, guias de estilo, dentre outros conceitos.
O processo HCD 6 auxilia o processo supracitado, visando coletar os feedbacks
dos usuários e de outras fontes representativas e utilizá-lo para melhorar o design do
produto e deixá-lo em conformidade com os requisitos de usuário definidos nos
processos anteriores. O último processo definido pela norma ISO (HCD 7) visa
estabelecer as atividades relacionadas ao suporte e implementação do sistema durante
85
seu uso, visando controlar as mudanças no produto decorrentes das necessidades e
reações identificadas pelos usuários.
As atividades de validações existentes na metodologia XP concentram-se em dois
momentos: durante a especificação do sistema e durante o seu uso. Assim como as
atividades de especificação, a validação ocorre diversas vezes em um projeto XP, a cada
novo ciclo. Quando o sistema está sendo especificado, os protótipos desenvolvidos (no
caso, protótipos de baixa fidelidade) são imediatamente avaliados pelos stakeholders,
que podem sugerir mudanças no design.
Além disso, cabe ao Gerente de Produto averiguar se os protótipos aprovados
estão compatíveis com os requisitos definidos. Observa-se que a prática de protótipos
não é algo institucionalizado dentro do XP. Portanto, podem existir projetos onde não se
faça uso dessa prática, o que pode comprometer a qualidade do produto.
Durante o uso do produto, as validações são realizadas pelo usuário final, sempre
ao final de um ciclo de desenvolvimento, quando uma parte do produto é entregue. Caso
este perceba disparidades entre os requisitos definidos para o sistema e sua
implementação na prática, ele pode solicitar uma revisão do produto no começo do
próximo ciclo de desenvolvimento. Esta atividade será internalizada dentro da
organização como uma estória, que será codificada pela equipe.
O esforço desprendido pelo XP em verificar o produto antes da entrega ao usuário
consiste na execução de testes de aceitação, baseados nas estórias definidas no Jogo do
Planejamento. São definidos testes funcionais para cada estória implementada, e
dependendo da especificação realizada pelos stakeholders, também são levadas em
consideração suas necessidades.
Após a entrega completa do produto, a metodologia XP prevê a realização de
atividades de suporte ao usuário, mantendo contato com o usuário sobre definições do
produto construído. Caso sejam necessárias mudanças, um novo ciclo é iniciado e as
alterações são realizadas, seguindo os passos do ciclo de vida de um projeto XP. As
demais atividades previstas no processo HCD7 não são identificadas dentro da
metodologia XP.
86
Tabela 3.6 - Análise da Aderência entre ISO TR 18529 e práticas do XP.
Processo
Prática – Base
Práticas do XP
Classificação
HCD 5 –
Produzir
soluções de
design;
5.1. Alocar funções.
Jogo do Planejamento
PA
5.2. Produzir um modelo de tarefas
composto.
-
NA
5.3. Explorar o design do sistema
Prototipação rápida
PA
5.4. Usar conhecimento existente para
desenvolver soluções de projeto.
Guia de estilos
PA
5.5. Especificar o sistema.
Estórias (cartões)
PA
5.6. Desenvolver protótipos.
Prototipação rápida
A
5.7. Desenvolver o treinamento do
usuário.
-
NA
5.8. Desenvolver o suporte ao usuário.
-
NA
HCD 6 –
Avaliar
designs ante
os requisitos;
6.1. Especificar e validar o contexto de
validação.
-
NA
6.2. Validar protótipos recentes a fim de
definir requisitos para o sistema.
Jogo do Planejamento
PA
6.3. Validar protótipos a fim de melhorar
o design.
Jogo do Planejamento
PA
6.4. Validar o sistema a fim de checar se
os requisitos do sistema foram satisfeitos.
Testes de Aceitação com
uso de Estórias (cartões)
A
6.5. Validar o sistema a fim de checar se
as práticas necessárias foram seguidas.
-
NA
6.6. Validar o sistema em uso
Jogo do Planejamento
PA
HCD 7 –
Introduzir e
operar o
sistema.
7.1. Controle de mudanças
-
NA
7.2. Determinar o impacto na
organização e nos stakeholders.
-
NA
7.3. Design local e customizado.
-
NA
7.4. Realizar o treinamento do usuário.
-
NA
7.5. Apoio aos usuários nas atividades
planejadas.
Testes de Aceitação com
uso de Estórias (cartões)
A
7.6. Garantir conformidade com a
legislação sobre a ergonomia do
ambiente de trabalho.
-
NA
87
Por fim, percebe-se que os processos HCD 1 – “Garantir o conteúdo de UCD na
estratégia do sistema” e HCD 2 – “Planejar e gerenciar o processo de UCD” não foram
citados em nenhuma das análises até então. Suas ausências justificam-se pelo fato deste
trabalho não ter identificado nenhuma aderência entre as práticas-base contidas entre
estes dois processos e as práticas do SCRUM e do XP.
O primeiro processo visa estabelecer e manter o foco nos usuários e stakeholders
relevantes, enquanto o segundo, apesar de ser um processo gerencial, visa especificar a
maneira como as atividades de design centrado no usuário serão incluídas no processo
de desenvolvimento da organização.
3.5.2. Estratégias de Apoio x ISO TR 18529
Outra análise a ser realizada condiz em verificar a aderência das estratégias
apresentadas neste capítulo (ver seções 3.2 e 3.4) à ISO TR 18529:2000. O objetivo
desta análise é verificar de que maneira as estratégias de apoio identificadas podem
auxiliar a organização ou o profissional de usabilidade a institucionalizar os conceitos
de usabilidade através da aplicação da norma ISO. Como o conteúdo apresentado é de
cunho estratégico, a análise dará especial atenção a práticas-base específicas de variados
processos da norma ISO em questão que focam no conteúdo das estratégias.
A definição e distinção dos objetivos de usabilidade, negócio e de usuário pela
organização auxiliam consideravelmente na garantia da existência do conteúdo de UCD,
como visto no processo HCD 1, dentro da estratégia de uma organização. Para definição
dos objetivos de negócio, levam-se em consideração aspectos externos à organização
(como tendências de mercado, produtos concorrentes, perfis de consumidores) que
influenciam em aspectos internos da organização (contexto de uso dos produtos, relação
com usuários/clientes, qualidade dos produtos).
Os objetivos de usabilidade, após definidos, podem contribuir para um
direcionamento nas atividades de planejamento e gerenciamento do processo de UCD
(HCD 2), pois se terá uma definição de que maneira a usabilidade deve ser utilizada
pela organização para se atingir uma maior qualidade nos seus produtos. Os objetivos de
usuário devem fazer parte da definição do sistema e estarem em sincronia com os
objetivos de qualidade no uso definidos para o produto (vistos no processo HCD 3).
88
As atividades de treinamento em usabilidade podem contribuir em vários
processos da ISO em questão, haja vista suas duas modalidades de treinamento. Os
treinamentos em conhecimentos auxiliam a organização a compreender a importância
em se planejar, gerenciar e executar um processo de UCD. Os treinamentos em
competências podem auxiliar a organização a se capacitar em diversas práticas
existentes na ISO em questão, como vistas na tabela 3.6, em especial nas práticas
definidas nos processos HCD 3 e 4, onde técnicas de usabilidade são aplicadas aos
processos da organização.
Tabela 3.7 - Análise da Aderência entre ISO TR 18529 e Estratégias de Apoio.
Processo
Práticas – Base
Estratégia de apoio
Classificação
HCD 1 –
Garantir o
conteúdo de
UCD na
estratégia do
sistema;
1.2. Coletar a inteligência do
marketing.
Definição dos objetivos de
negócio e de usabilidade
PA
1.3. Definir e planejar uma
estratégia de sistema.
A
1.4. Coletar o feedback do
marketing.
A
1.5. Analisar as tendências do
usuário.
PA
HCD 2 –
Planejar e
gerenciar o
processo de UCD
2.1. Consultar stakeholders.
Promoção da usabilidade;
PA
2.7. Disseminar a abordagem
centrada no humano.
Treinamento em
conhecimentos;
Promoção da usabilidade;
A
HCD 3 -
Especificar os
stakeholders e
requisitos da
organização
3.1 Esclarecer e documentar as
metas do sistema.
Definição dos objetivos dos
usuários
A
3.6. Definir os objetivos de
qualidade no uso.
Coleta de métricas de produto
e processo;
A
HCD 4 -
Compreender e
especificar o
contexto de uso
4.1. Identificar e documentar as
tarefas do usuário.
Treinamentos em
competências
PA
4.2. Identificar e documentar
atributos significantes do
usuário.
Treinamentos em
competências;
PA
As estratégias apresentadas de promoção da usabilidade contribuem de maneira
pontual em algumas práticas-base da ISO, mais precisamente nas práticas 2.7 e 3.6. A
89
maneira como a abordagem centrada no usuário é disseminada na organização
dependerá de um apoio da alta direção. Sendo assim, a estratégia definida por Travis
(2006) é importante para auxiliar no convencimento da alta direção e do restante da
organização sobre as atividades de usabilidade.
A definição de métricas pode auxiliar na formalização dos resultados obtidos com
uso de práticas design centrado no usuário, podendo definir níveis de qualidade de uso
(HCD 3) como: satisfação, produtividade, eficiência, eficácia, dentre outros.
Percebe-se que, diferente das demais análises de aderência realizadas neste
capítulo, esta última concentra em exibir apenas os resultados onde houve uma
aderência plena ou parcial, com intuito de facilitar a leitura da tabela.
3.6. Considerações Finais do Capítulo
Este capítulo iniciou-se com uma representação do cenário dos conceitos de
usabilidade relacionados ao mercado de software. Inicialmente, destacou-se a
dificuldade encontrada pelo profissional de usabilidade dentro das organizações, além
da dificuldade destas em absorver contribuições originadas por trabalhos científicos.
Em seguida, descreveu-se como a usabilidade poderia ser utilizada como
componente estratégico e de diferencial competitivo dentro das organizações e algumas
estratégias de apoio à institucionalização da usabilidade. Normas como o People CMM
e a ISO TR 18529:2000 foram descritas e a última, em especial, foi destacada devido à
sua importância na institucionalização das práticas de design centrado no usuário em
uma organização. A integração com práticas do People CMM será detalhada no capítulo
seguinte, quando forem apresentadas as estratégias do trabalho proposto, que foca
algumas atividades na gestão das pessoas envolvidas na organização.
O capítulo procedeu com uma análise da aderência dos conceitos de métodos
ágeis XP e SCRUM definidos no capítulo anterior aos processos definidos na ISO em
questão. Concluiu-se a partir dos resultados dessa análise que algumas práticas, tanto do
SCRUM quanto do XP, possuem aderência total ou parcial a alguns processos da ISO,
podendo existir uma integração entre ambos. Além disso, as estratégias de apoio
descritas no capítulo foram analisadas e foi identificado como as mesmas poderiam
também ser integradas aos processos da ISO em questão, contribuindo para
90
institucionalização da usabilidade. Estas estratégias também serão utilizadas pela
proposta deste trabalho, no capítulo seguinte.
Ao mesmo tempo em que as integrações apresentadas demonstraram a
possibilidade de existência de um ambiente onde um processo de desenvolvimento ágil
esteja em conformidade com uma norma ISO de usabilidade, as lacunas existentes entre
estes conceitos foram identificadas e foram utilizadas como motivação para a definição
da estratégia deste trabalho, a ser apresentada no próximo capítulo.
4. Estratégia de Apoio à Institucionalização da
Usabilidade em Ambientes Ágeis
Este capítulo apresenta a proposta deste trabalho, que consiste de uma estratégia de
apoio para a institucionalização da usabilidade em ambientes de desenvolvimento ágil. Neste
capítulo são descritos os objetivos, a fundamentação teórica, além dos papéis, artefatos e
atividades existentes durante as etapas da estratégia. Por fim, é realizada uma avaliação da
aderência da estratégia com conceitos das normas ISO TR 18529 e uma análise comparativa
com práticas do P-CMM.
4.1. Introdução
A partir de experiências obtidas com atividades de consultoria em usabilidade em
organizações desenvolvedoras de software, constatou-se que empresas de pequeno e
médio porte desejavam realizar uma estratégia de melhoria de usabilidade em seus
processos de desenvolvimento, contanto que esta iniciativa possuísse as seguintes
características [Souza et al., 2005]:
Para a equipe de desenvolvimento:
o Ser facilmente aprendida e aplicada nos processos de trabalho da
equipe; e
o Oferecer benefícios claros para uma melhoria na produtividade do
desenvolvimento.
Para gerentes e usuários:
o Aportar pequenos impactos nos prazos do projeto devido à curva de
aprendizagem necessária;
o Possuir técnicas que facilitassem a comunicação entre a equipe de
desenvolvimento e os usuários; e
o Demonstrar impactos claros na qualidade final do produto.
Geralmente, a equipe de desenvolvimento não se sente motivada a aprender um
processo complexo, fato este reforçado em ambientes de desenvolvimento ágil [Sy,
92
2007]. Por complexo, entenda-se um processo com uma grande quantidade de artefatos
e técnicas que necessitam ser aprendidas. Com isto em mente, percebe-se a necessidade
em se prover à equipe uma quantidade mínima de artefatos e técnicas, e que estas
tragam resultados sólidos para a construção do produto final.
A estratégia deste trabalho surgiu da necessidade de se viabilizar, de forma
simples e eficaz, a adoção de práticas de usabilidade em empresas de pequeno e médio
porte, que utilizem abordagens de desenvolvimento ágil. Ela baseia-se na compilação de
um conjunto de melhores práticas coletadas tanto em pesquisas em nível de mercado,
quanto em trabalhos existentes no âmbito acadêmico.
Desta forma, esta estratégia objetiva se comportar como um guia de melhores
práticas para consultores de usabilidade, executivos, gestores de processo, gestores de
projeto e/ou demais profissionais interessados, auxiliando-os a realizar uma melhoria de
seus processos de desenvolvimento ágil, concentrando seus esforços em uma evolução
na qualidade do uso de seus sistemas interativos desenvolvidos.
4.2. Papéis
Antes de se investigar a estrutura da estratégia, são apresentados os papéis
envolvidos durante as etapas da proposta deste trabalho. Eles consistem dos seguintes:
Usuários: responsáveis pela utilização dos sistemas interativos desenvolvidos
pela organização. Cabe aos mesmos relatar suas necessidades e expectativas,
dificuldades de utilização das ferramentas, dentre outros aspectos. Em último
caso, podem ser representados por stakeholders relevantes que relatem seus
interesses, apesar desta prática não ser recomendada.
Consultor de Usabilidade: responsável por orientar a organização sobre
como proceder para realizar os passos da estratégia, além de monitorar todas
as ações de melhoria que devem ser realizadas, reportando os resultados
obtidos à alta direção. Este papel pode ser representado tanto por um consultor
de usabilidade externo contratado pela organização, quanto por um
profissional da própria organização que possua o perfil adequado.
Gestor de Usabilidade: responsável direto pela aplicação das práticas de
usabilidade (sob monitoração inicial do Consultor em Usabilidade) na
93
organização, interagindo com a equipe de desenvolvimento, os usuários e a
alta direção. A atribuição deste papel é feita pela Alta Direção em conjunto
com o Consultor de Usabilidade, que identificam um membro da organização
que possua o perfil necessário para realizar as atividades de usabilidade. Este
papel deve ter apoio total da Alta Direção para realização de suas atividades.
Equipe de Desenvolvimento: responsável pela construção dos sistemas
interativos utilizados pelos usuários. Trabalha em conjunto com o Gestor de
Usabilidade, associando suas atividades corriqueiras de desenvolvimento com
as práticas de usabilidade propostas.
Alta Direção: responsável pelas tomadas de decisão relacionadas às
atividades propostas na estratégia. Auxilia na identificação dos objetivos
estratégicos. Aprova o planejamento realizado para a estratégia. Deve ser
informada do andamento de todas as atividades e de seus posteriores
resultados, além de poder exigir um maior comprometimento da organização.
4.3. Artefatos de Apoio
Devido ao caráter ágil dos processos de desenvolvimento, a estratégia preocupou-
se em limitar a quantidade de artefatos definidos para fazer parte deste trabalho. Estes
foram escolhidos com a finalidade de servir como um instrumento de apoio rápido ao
gestor e consultor de usabilidade, objetivando tornar seu trabalho mais eficaz.
Os seguintes artefatos foram utilizados como instrumento de apoio gerencial
durante a realização da estratégia:
Questionário de investigação: artefato útil para a coleta de informações
relacionadas à organização, tanto internas quanto externas.
Plano de melhoria do processo: um dos principais artefatos da estratégia.
Nele, é especificado como se adequar as atividades relacionadas à usabilidade
aos processos de trabalho da organização.
Questionário pós-treinamento: artefato utilizado com intuito de apoiar na
avaliação dos conhecimentos da organização em usabilidade. Seus resultados
indicarão um feedback da organização sobre o grau de conhecimento de cada
94
integrante. Dessa forma, ele contribui para a tomada de decisão sobre a
definição do papel de Gestor de Usabilidade.
4.4. Estrutura e Características da Estratégia
Segundo Kulpa e Johnson (2003), as principais atividades relacionadas à melhoria
de um processo consistem de: i) preparação: prepare a infra-estrutura do grupo, inicie o
planejamento e angarie recursos; ii) projeto: descreva as políticas e procedimentos, e
identifique e escreva os padrões a serem utilizados; iii) experiência: treine os
participantes e experimente os procedimentos em algumas áreas da organização,
modificando os passos sempre que sentir necessidade; e iv) implementação: siga os
procedimentos especificados anteriormente nos demais projetos.
Com base nestes conceitos e nos demais vistos nos capítulos dois e três, definiu-se
uma estratégia de apoio à institucionalização da usabilidade, conforme ilustrada na
figura 4.1. Esta estratégia propõe um processo cíclico, composto de quatro etapas, que
possui um conjunto de atividades que também podem ser realizadas de maneira cíclica,
ou seja, podem ocorrer várias vezes numa mesma etapa.
Figura 4.1 - Estratégia de Apoio à Institucionalização da Usabilidade
95
Pode-se dividir a estratégia em quatro etapas básicas: Investigação, Análise e
Planejamento das Atividades, Execução das Atividades e Avaliação. Essencialmente, as
duas primeiras são responsáveis por preparar a organização para integrar novos
conhecimentos de usabilidade em seu processo, enquanto as duas últimas focam suas
atividades na aplicação destes conhecimentos na prática, monitoração dos resultados e
promoção de melhorias nos processos.
Esta estratégia fundamenta as etapas propostas a partir dos seguintes três
conceitos: a ISO TR 18529:2000, o People-CMM e a metodologia ágil SCRUM. Dessa
forma, é possível citar algumas de suas características levando em consideração os
conceitos supracitados:
Baseada na ISO TR 18529:2000
A base da estratégia deste trabalho concentra-se nos conceitos definidos pela ISO
TR 18529. O conhecimento existente nos processos desta norma serve de insumo para
quase todas as etapas da estratégia. Ambas compartilham do mesmo objetivo: guiar a
organização na realização de atividades relacionadas à qualidade do uso.
Destacam-se dois conceitos: (i) a execução de um conjunto de atividades de
investigação organizacional (como visto na seção 4.5.1), visando conhecer a
organização, seus integrantes, contexto de atuação, dentre outros fatores, formando uma
base de conhecimento organizacional; (ii) além disso, a estratégia inclui atividades
visando o planejamento e acompanhamento de atividades de usabilidade a serem
aplicadas na organização, que também são previstas por esta norma.
Baseada no SCRUM
Na estratégia deste trabalho, todas as necessidades para a implantação de práticas
de usabilidade são definidas e refinadas em um plano de melhoria (visto com mais
detalhes na seção 4.4.2), sendo este construído seguindo uma filosofia de construção
similar a de uma Product Backlog, presente no SCRUM. Dessa forma, a execução e o
acompanhamento das atividades previstas neste plano de melhoria possuem suas
atividades integradas às demais existentes em um processo de desenvolvimento e
gerenciamento ágil.
96
Baseada no P-CMM
Outra importante característica desta estratégia foca em capacitar as equipes, antes
que as mesmas executem ou participem de quaisquer atividades relacionadas à
usabilidade. Leva-se em consideração o P-CMM, que possui uma área de processo
específica para o tratamento de questões relativas ao treinamento e desenvolvimento das
equipes. As necessidades de capacitação dos envolvidos e os treinamentos envolvidos
são considerados como itens do plano de melhoria.
A cultura participativa é outra área de processo do P-CMM considerada nesta
estratégia. Seus conceitos são utilizados, principalmente, durante as tomadas de decisão
realizadas de maneira colaborativa e durante a execução das atividades previstas no
plano de melhoria, onde são definidas atividades visando um esforço de melhoria
contínua das atividades realizadas. Ao final deste capítulo, a integração entre a
estratégia deste trabalho e os conceitos citados será analisada com maiores detalhes.
4.5. Descrição das Etapas e Atividades da Estratégia
Nas próximas subseções serão detalhados os objetivos, atividades, atores
envolvidos e sugestões de técnicas a serem utilizadas em cada etapa. A ordem de
apresentação das atividades traduz a seqüência de execução da estratégia proposta.
4.5.1. Etapa 1: Investigação Organizacional
Esta etapa consiste na obtenção de maiores informações a respeito da organização,
seus processos e quaisquer experiências anteriores em que houve participação direta ou
indireta do usuário.
As informações coletadas serão utilizadas como base para se realizar um
convencimento inicial da organização sobre a necessidade de se investir recursos em
usabilidade, além de servirem como subsídio para posteriores tomadas de decisão sobre
como as práticas de usabilidade serão aplicadas na organização, sempre preconizando os
fatores críticos de custo do projeto e tempo de desenvolvimento.
Como visto nos capítulos anteriores, a presença constante do usuário é uma
premissa para um bom funcionamento dos processos ágeis, sendo o mesmo
considerado, em algumas situações, como um membro da equipe. Portanto, além da
97
organização, sugere-se investigar os usuários (ou representantes dos usuários)
associados às equipes.
Figura 4.2 - Resultados Esperados da etapa de Investigação Organizacional
a) Atividades:
Investigação sobre o perfil da organização: o consultor de usabilidade deve
investigar informações relacionadas ao funcionamento e estrutura da organização. São
elas: fatores externos (tais como: clientes, competidores de mercado, mercados-alvos),
fatores internos (tais como: tamanho, composição e perfil das equipes, estrutura,
finanças, serviços oferecidos e produtos construídos), processos de trabalho, além de
outras informações que considere pertinentes sobre a organização.
Investigação sobre o perfil da alta direção: após os primeiros contatos com a
organização, o consultor de usabilidade pode identificar qual o perfil dos gestores da
organização. Esta atividade torna-se fundamental para definir qual abordagem de
convencimento o consultor de usabilidade deve utilizar com a alta direção, de forma a
conseguir apoio irrestrito da mesma. Para isso, segue o modelo de definição de
personalidade MBTI [Brock, 1994], descrito no capítulo anterior (ver subseção 3.4.2)
e contido com mais detalhes no apêndice A.
Investigação sobre iniciativas em usabilidade e/ou qualidade em geral:
para se traçar um perfil da cultura existente em usabilidade dentro da organização,
sugere-se investigar fatores como: histórico (o que foi feito em usabilidade, e por
quem?), atitudes (o que os membros da organização pensam sobre usabilidade?),
necessidades (como se encontram os produtos da organização em relação à
usabilidade) e usuários (qual o envolvimento dos usuários com a organização?).
Identificação dos objetivos de negócio e de usabilidade: cabe também ao
consultor de usabilidade, auxiliar a alta direção (com possível apoio de um gestor ou
analista de negócio) a refletir e identificar quais os objetivos de negócio da
organização e como alcançá-los com a institucionalização da usabilidade. Além disso,
98
deve-se realizar entrevistas com os usuários, visando definir quais os resultados
esperados pelos mesmos.
Apresentação dos resultados da investigação: é fundamental que os dados
coletados pelo consultor de usabilidade sejam comunicados à organização de maneira
convincente.
b) Ator principal: Consultor de Usabilidade.
c) Atores envolvidos: Alta Direção e Equipe de Desenvolvimento.
4.5.2. Etapa 2: Análise e Planejamento das Atividades
Baseando-se nas informações obtidas na etapa anterior, a etapa de análise e
planejamento visa especificar como serão realizadas as atividades de melhoria de
processo em usabilidade na organização. Durante esta etapa, são realizadas, de maneira
colaborativa, atividades de tomada de decisão sobre todos os itens do plano.
Esta etapa se divide em duas macro-atividades: definição de um plano de melhoria
e detalhamento do plano definido. A figura 4.3 explicita os resultados esperados ao final
desta etapa, onde se espera obter um plano de melhoria detalhado sobre as atividades de
desenvolvimento da organização, sendo as atividades deste plano categorizadas em
ordem de prioridade e aprovadas para execução pela alta direção.
Figura 4.3 - Resultados Esperados da Análise e Planejamento das Atividades.
a) Atividades:
Macro-Atividade 1 - Definição de um plano de melhoria: a definição do
plano de melhoria se inicia a partir de análises dos dados coletados na etapa de
investigação organizacional, como descrito abaixo:
Análise sobre os objetivos de negócio e de usabilidade: após a
identificação, na etapa anterior, destes objetivos, os mesmos atores envolvidos devem
realizar um esforço para associar os objetivos de negócio aos objetivos de usabilidade.
99
Dessa forma, será planejada a forma como a usabilidade será utilizada como
componente estratégico e diferencial competitivo.
Análise de um conjunto de práticas a serem institucionalizadas: com
base nas informações colhidas na etapa anterior, o consultor define um conjunto inicial
de práticas que serão aplicadas dentro do ambiente produtivo.
Além destas informações, o consultor pode fazer uso de um conjunto de
práticas de usabilidade que mais se adequam ao perfil e aos objetivos estratégicos da
organização. Sugerem-se algumas, mas não se limitando a estas, que foram definidas a
partir dos resultados encontrados nas análises comparativas envolvendo práticas de
usabilidade, projetos ágeis e design participativo, realizadas no capítulo 2 deste
trabalho. São as seguintes:
Brainstorming e Grupos Focais – úteis durante discussões internas, com
usuários e tomadas de decisão durante o projeto. Podem ser utilizadas em
atividades que requeiram colaboração entre os participantes.
Personas, Cenários de Uso e Protótipos - podem ser utilizados como
métodos de representação dos usuários, tarefas e interfaces do sistema.
Guias de estilo - podem ser utilizados como apoio para construção de
protótipos executáveis, tomando-se a preocupação em não comprometer
a produtividade das atividades de desenvolvimento;
Inspeções de Usabilidade – úteis para verificar, mesmo que de maneira
rápida, os protótipos construídos pela equipe;
Etnografia rápida – pode ser utilizada para observação do uso de uma
interface ou conjunto de interfaces por parte do usuário. Útil porque
métodos ágeis privilegiam a codificação. Desta forma protótipos podem
ser disponibilizados para usuários mostrarem como se apropriariam da
tecnologia na sua vida.
De posse das potenciais práticas a serem incluídas no plano de melhoria, o
consultor de usabilidade deve seguir um processo de tomada de decisão, realizando
uma análise de viabilidade (ver Tabela 4.1) de aplicação de cada prática ao processo
produtivo da organização, seguindo critérios vistos na tabela abaixo.
100
Tabela 4.1 - Análise de Viabilidade de Aplicação de uma Prática de Usabilidade
Item de Decisão
Questionamentos
Envolvimento do usuário
Como o usuário será envolvido durante a realização das
práticas?
Competência das equipes
Quais as habilidades necessárias às equipes para executarem as
atividades?
Associação com a
estratégia de usabilidade
Quais objetivos de negócio e de usabilidade podem ser
associados?
Processo de
Desenvolvimento
Em que fase ou atividade do processo será executada cada
prática escolhida?
Práticas Semelhantes
Existem práticas além das sugeridas pela estratégia do
trabalho que possam ser aplicadas na organização?
A partir desta avaliação, são escolhidas as práticas que farão parte das
atividades previstas dentro do plano de melhoria em usabilidade, a ser detalhado pelo
consultor de usabilidade na próxima atividade desta etapa. Ressalta-se que nesta
estratégia não são realizados estudos detalhados levando em consideração critérios
relacionados a custos financeiros.
Análise das necessidades de treinamento: tomando como base as
competências identificadas pelo consultor de usabilidade durante a fase de
investigação, este deve confrontar tais habilidades com as competências requeridas à
organização, para tornar possível a execução do plano de melhoria.
Após esta análise, será possível tomar conhecimento de quais competências em
usabilidade estão deficientes (ou inexistentes) nas equipes e necessitam,
conseqüentemente, de um esforço de capacitação. Uma estratégia recomendada
consiste em realizar um mapeamento entre as práticas de usabilidade escolhidas e as
competências necessárias para integração ao processo de desenvolvimento, com os
treinamentos a serem realizados.
A relação entre práticas, competências e treinamento em usabilidade (como
visto na figura 4.4) comporta-se da seguinte maneira: para se aplicar corretamente as
práticas de usabilidade escolhidas durante etapa de análise e planejamento, a equipe
necessita adquirir as competências específicas.
101
Figura 4.4 - Mapeamento de Competências e Práticas versus Treinamentos
Como forma de suprir esta necessidade, treinamentos em usabilidade podem
ser oferecidos, tornando a equipe capacitada a realizar as atividades. Eles podem
ocorrer de duas maneiras distintas: (i) sensibilização sobre a importância de adoção do
conhecimento em usabilidade pela organização, visando uma melhor qualidade na
interação do usuário com o produto e (ii) repasse de informações à organização sobre
o conhecimento técnico em usabilidade necessário para realizar a sua
institucionalização.
Dessa forma, após realização das atividades acima, é possível reunir os dados
das análises em um plano de melhoria. Este trabalho definiu um artefato (ver figura
4.5) que visa contemplar todas as informações necessárias para execução de um plano
de melhoria. Sua estrutura é dividida em seções, como visto a seguir. Cada seção
especifica um elemento que pode influenciar na melhoria do processo da organização.
Neste momento, o consultor de usabilidade pode incluir os objetivos
identificados, as práticas de usabilidade que serão utilizadas e as necessidades de
treinamento identificadas.
102
Plano de Melhoria em Usabilidade
Projeto: < nome do projeto real da organização onde serão aplicadas as atividade de
melhoria>
Executor: <nome do executor do projeto>
Objetivos:
Externos
< lista dos objetivos externos de negócio associados ao plano de melhoria>
o Internos
<lista dos objetivos internos de negócio associados aos objetivos externos>
Usabilidade
<lista dos objetivos de usabilidade associados aos objetivos de negócio>
Atividades Previstas de Melhoria:
Ordem
Atividade*
Executor
Participantes
Tempo Previsto
<ordem de
execução>
< descrição da
atividade>
<executor da
atividade>
<stakeholders
envolvidos na
atividade>
<tempo previsto
para atividade>
<ordem de
execução>
< descrição da
atividade>
<executor da
atividade>
<stakeholders
envolvidos na
atividade>
<tempo previsto
para atividade>
* Tipos de Atividades:
Atividades de Capacitação
Atividades de Aplicação de Técnicas de Usabilidade
Atividades de Coleta de Métricas
Atividades de Acompanhamento do Plano
Atividades de Promoção dos Resultados
Figura 4.5 - Template do Plano de Melhoria em Usabilidade
103
Macro-Atividade 2 - Detalhamento do plano de melhoria de processo:
nesta atividade, o consultor de usabilidade compila os dados encontrados e passa a
detalhar o plano de melhoria, em conjunto com a organização, realizando as seguintes
atividades:
Planejamento dos atores envolvidos e suas atuações no processo: após a
definição das práticas, cabe ao consultor de usabilidade definir quais são os atores a
serem envolvidos em cada atividade do plano e de que maneira estes atuarão no
momento de execução das práticas.
Planejamento dos treinamentos a serem aplicados na organização: a
partir das necessidades de treinamento identificadas na atividade anterior, devem ser
definidos quais treinamentos serão necessários de serem aplicados à equipe durante a
execução do plano de melhoria.
Definição do grau de importância das atividades previstas no plano:
após a definição das atividades previstas no plano de melhoria, estas devem ser
listadas (seguindo mesmas características da Product Backlog do SCRUM) e
priorizadas pela alta direção. Cabe à mesma decidir o que deve ser executado
inicialmente, pois tem uma prioridade maior, assim como o que pode ser realizado em
segundo plano.
Escolha de métricas para avaliação do plano de melhoria: os critérios de
avaliação do plano de melhoria devem ser definidos com intuito de verificar a
eficiência do mesmo. Como esta estratégia foca em melhoria de processo, as métricas
definidas verificam, essencialmente, a performance da organização perante as
atividades previstas no plano de melhoria.
Este trabalho faz uso de uma metodologia de definição de métricas que foi
definida em [Sousa et al., 2005]. A metodologia tem o objetivo de verificar a
eficiência de cada atividade de usabilidade dentro de um processo. Para isso, define
métricas (como: tempo gasto para realizar uma tarefa) relacionadas às atividades do
processo, com intuito de avaliar o nível de contribuição.
Cada métrica deve possuir uma fórmula, um objetivo e a freqüência de coleta.
A fórmula é importante para permitir que todas as coletas sejam realizadas seguindo o
mesmo procedimento. O objetivo é a razão pela qual a métrica está sendo coletada, e a
freqüência de coleta indica periodicidade de realização das atividades de coleta.
104
Seguindo esta mesma estrutura de definição de uma métrica, esta estratégia
sugere na tabela 4.2, um conjunto de métricas que podem ser utilizadas inicialmente
pelo gestor de usabilidade:
Tabela 4.2 - Sugestões de Métricas para Avaliação do Plano de Melhoria
Métrica
Fórmula
Objetivo
Freqüência
Grau de satisfação das
equipes relacionado aos
treinamentos realizados
Somatório (notas das
avaliações pós-
treinamentos) / Total
participantes
Avaliar a satisfação da
equipe com as
capacitações realizadas
A cada novo
ciclo
Freqüência de utilização
das técnicas sugeridas
pelo plano de melhoria
(Número de práticas
utilizadas) / (Número de
práticas previstas) * 100
Avaliar a adoção das
práticas de usabilidade.
A cada novo
ciclo
Duração das atividades
previstas no plano
Para cada atividade:
(Tempo de realização) -
(Tempo previsto)
Avaliar as atividades que
tiveram duração de tempo
maior que o previsto no
plano.
A cada novo
ciclo
Quantidade de mudanças
aplicadas ao plano de
melhoria
Somatório (Mudanças
aplicadas ao plano)
Avaliar quantas vezes o
plano de melhoria
necessitou ser revisto.
A cada novo
ciclo
As métricas relacionadas ao produto em si estão fora do escopo deste trabalho.
Ressalta-se que, neste momento, as métricas são apenas definidas, podendo ser
modificadas em outros ciclos do projeto, baseando-se na experiência obtida durante a
execução do plano de melhoria. As informações de métricas são coletadas durante a
execução do plano (através da atividade de Coleta de Métricas) e consolidadas durante
a etapa de Avaliação.
Obter aprovação da alta direção: após o detalhamento do plano, o
consultor de usabilidade deve comunicar à organização sobre a elaboração do plano de
melhoria e novamente será necessário um esforço do mesmo para obter um
convencimento da mesma sobre a necessidade de execução do plano.
b) Ator principal: Consultor de Usabilidade
c) Atores envolvidos: Alta Direção e Equipe de Desenvolvimento
105
4.5.3. Etapa 3: Execução do Plano de Melhoria em Usabilidade
Após a realização das etapas anteriores, considera-se que a organização esteja
preparada para aplicar as práticas de usabilidade em seus processos. Sugere-se a
execução de um projeto piloto, a fim de observar a atuação das equipes ante as práticas
de usabilidade definidas no plano de melhoria do processo.
Outra característica encontrada nesta etapa trata-se de sua agilidade. Diferente das
demais atividades, que são realizadas sem uma integração direta com o processo de
desenvolvimento ágil da organização, as atividades constituintes desta etapa devem ser
realizadas de maneira ágil, de forma a acompanhar o ritmo das atividades da equipe de
desenvolvimento. Caso contrário, não serão utilizadas pela organização, por
considerarem um obstáculo à produtividade das atividades de desenvolvimento.
Figura 4.6 - Resultados Esperados da Execução do Plano de Melhoria em Usabilidade
a) Atividades:
Capacitação das equipes: a execução do plano de melhoria inicia-se com a
realização das atividades de capacitação, visando suprir as necessidades de
treinamento identificadas. Devido ao suporte às características ágeis, recomenda-se
que os treinamentos escolhidos sejam realizados sempre que uma nova prática de
usabilidade deseje ser utilizada pela equipe. Caso os recursos de tempo do projeto
estejam escassos, deve-se estimular que este treinamento ocorra de maneira informal,
em uma reunião ou palestra explicativa.
Após a realização dos treinamentos, cabe ao consultor de usabilidade realizar
uma rápida avaliação dos resultados. Um artefato de apoio pode ser utilizado neste
momento (questionário pós-treinamento) pelo consultor de usabilidade, de maneira a
auxiliá-lo na coleta do feedback da equipe sobre os treinamentos realizados. Tais
informações serão avaliadas com maiores detalhes durante a etapa de Avaliação.
106
Além disso, os resultados do questionário podem auxiliar o consultor de
usabilidade a indicar um integrante da equipe para ser escolhido como um potencial
disseminador de conhecimento para o restante da organização, como visto a seguir.
Atribuição do papel de Gestor de Usabilidade: a próxima atividade da etapa
consiste em selecionar um membro do projeto para que este exerça o papel de Gestor
de Usabilidade. A escolha do Gestor de Usabilidade do projeto é definida a partir de
uma avaliação do seu perfil e interesse, realizada em conjunto pelo consultor de
usabilidade e a alta direção.
Sua função principal consiste em executar as atividades definidas dentro do
plano de melhoria, contando com o apoio e monitoração constantes do consultor de
usabilidade. Além disso, o Gestor deve promover a usabilidade dentro de seu projeto,
estimulando a participação de todos os integrantes da equipe envolvidos no plano de
melhoria.
Assim como ocorre nas metodologias ágeis, este papel pode ser direcionado a
outro membro da organização, caso os resultados não sejam satisfatórios, ou
simplesmente por opção estratégica do gestor do projeto. Se assim for, é de
fundamental importância que este papel seja atribuído a um integrante da equipe que
se comprometa a realizar suas atividades previstas para a execução do plano.
Execução e monitoração do plano de melhoria de processo: nesta atividade,
o plano de melhoria de processo definido durante a etapa de análise e planejamento é
executado. Esta estratégia sugere a execução de um projeto piloto, sob
responsabilidade do gestor de usabilidade e monitoração do consultor de usabilidade.
Entende-se por projeto-piloto um projeto real em execução na organização,
onde são aplicadas as atividades previstas no plano de melhoria e observados os
efeitos na prática. Algumas características são importantes de serem analisadas
durante a escolha do projeto-piloto, tais como vistas abaixo:
Tamanho da equipe: esta estratégia sugere que o primeiro projeto-piloto a
ser realizado envolva uma quantidade pequena de pessoas, algo entre cinco a dez
pessoas. Dessa forma, o gestor de usabilidade terá um maior controle sobre as
atividades realizadas e os resultados obtidos.
107
Experiência dos envolvidos: sugere-se envolver os usuários e/ou clientes
de projetos nos quais exista um bom relacionamento e disponibilidade dos mesmos. A
equipe de desenvolvimento e o gerente de produto envolvidos nas atividades de
melhoria devem ter sido capacitados e estarem conscientes da importância da
realização das atividades.
Complexidade do produto e do projeto real envolvido: sugere-se que
seja evitada a escolha de um projeto real cujo produto em desenvolvimento possua
funções demasiadamente complexas. Deve-se buscar, inicialmente, a escolha por
projetos de pequeno a médio porte, mas que possuam uma boa visibilidade dentro da
organização. À medida que a organização for amadurecendo em usabilidade, projetos
com maior complexidade podem ser escolhidos.
Duração do projeto-piloto: a duração do projeto depende da
disponibilidade da equipe para realizar as atividades previstas no plano de melhoria.
Caso observe-se que as atividades não estejam sendo realizadas da maneira
pretendida, a duração do projeto-piloto pode ser incrementada. Geralmente, a duração
de um ciclo de vida definido para o projeto piloto difere da duração do ciclo de vida
do processo de desenvolvimento. Ou seja, a duração de um projeto-piloto dependerá
da quantidade de ciclos de desenvolvimento avaliados, informação esta definida
durante a elaboração do plano de melhoria. Um projeto pode ser avaliado do começo
ao fim, assim como apenas durante certo período de tempo.
Ainda durante a execução o projeto piloto, o gestor de usabilidade deve
promover reuniões informais com o Gerente de Produto e/ou gestores de processo da
organização, visando coletar mais informações sobre o impacto das atividades nas
atividades rotineiras de desenvolvimento e possíveis feedbacks recebidos durante
reuniões com o cliente e/ou usuário.
Além disso, dependendo das práticas previstas a serem aplicadas no processo
da organização, estas podem ser acompanhadas de artefatos de apoio (como exemplo,
um formulário para preenchimento dos resultados de uma inspeção de usabilidade).
A monitoração do projeto piloto deve ser realizada desde a primeira atividade,
sob supervisão do consultor de usabilidade durante os ciclos iniciais. Basicamente, as
atividades de monitoração do projeto piloto consistem de: (i) observação da execução
108
das atividades previstas no plano de melhoria e (ii) coleta de métricas relacionadas ao
plano de melhoria, definidas na etapa anterior e descritas a seguir.
Coletar métricas de processo: outra atividade que ocorre em paralelo à
execução do projeto piloto e está sob responsabilidade do gestor de usabilidade, trata-
se da coleta de métricas. Cabe ao mesmo, durante a monitoração das atividades em
execução, guiar suas observações sobre as mesmas a partir das métricas definidas no
plano de melhoria para o projeto em questão.
Sugere-se que estas métricas sejam coletadas em todos os ciclos do projeto.
Caso durante a execução do plano de melhoria sejam identificadas necessidades de
novas métricas, o gestor de usabilidade pode considerar esta necessidade como um
item de mudança a ser levado em discussão com o restante da organização.
Melhoria contínua de processo: como visto no capítulo 2, as estratégias de
desenvolvimento ágil lidam com constantes mudanças de requisitos de um produto, de
uma nova tecnologia de desenvolvimento, sejam elas durante ou após um projeto.
Dessa forma, devido ao caráter ágil da estratégia, o plano de melhoria pode sofrer
modificações durante sua execução.
Caso o gestor de usabilidade (ou algum integrante da equipe) perceba alguma
alteração que possa ser realizada e que venha a contribuir para a execução das
atividades do plano de melhoria pela organização, este pode sugerir uma mudança no
plano, que deve ser avaliada por todos os envolvidos, verificando-se a possibilidade de
realizá-la no próximo ciclo do projeto.
Alguns exemplos de modificações que podem ocorrer durante a execução do
plano são as seguintes:
Mudança das práticas de usabilidade previstas: este tipo de mudança
pode acontecer quando se observa que uma prática não foi executada com sucesso pela
equipe, devido a diversos fatores, tais como: tempo hábil para realizar a prática, baixo
comprometimento da equipe, dentre outros.
Mudança dos tipos de treinamentos: o gestor de usabilidade ou os
próprios membros da organização que foram capacitados podem sugerir mudanças no
formato de treinamento utilizado durante a atividade de capacitação. Inclusive, podem
requisitar novos treinamentos, caso seja necessário.
109
Mudanças nos requisitos dos produtos: um produto desenvolvido por
um processo de desenvolvimento ágil freqüentemente passa por mudanças em seus
requisitos. Em alguns casos, pode ser necessário alterar o plano de melhoria para
incluir uma atividade de usabilidade não prevista anteriormente e que sua realização
possa impactar diretamente na qualidade de interação do produto.
A metodologia SCRUM sugere uma atividade de retrospectiva das atividades
da equipe, sempre ao final de um ciclo do projeto de desenvolvimento. Portanto,
sugere-se que esta atividade de melhoria contínua seja realizada neste mesmo
momento. Ressalta-se que, pelo fato desta atividade ser rápida, não há uma avaliação
detalhada dos resultados obtidos. Tal detalhamento será feito na próxima etapa.
b) Ator principal: Gestor de Usabilidade.
c) Atores envolvidos: Equipe de Desenvolvimento, Usuários, Alta Direção e
Consultor de Usabilidade.
4.5.4. Etapa 4: Análise das Ações Realizadas
Após a execução dos esforços para incorporar práticas de usabilidade aos
processos da organização, através das atividades previstas no plano de melhoria, a
estratégia deste trabalho concentra suas atividades na reflexão sobre os resultados
obtidos até então e seus impactos para a organização.
As atividades previstas (ver Figura 4.7) para etapa dividem-se em duas: avaliação
da capacidade e maturidade em usabilidade da organização, e melhoria contínua da
estratégia. Cabe ao Gestor de Usabilidade, em conjunto com o Gerente de Produto do
projeto, definir o melhor momento, passado certo tempo após o a etapa de execução do
projeto, para realizar esta reflexão com os demais integrantes da equipe, dessa vez com
mais detalhes.
Figura 4.7 - Resultados Esperados da Avaliação dos Resultados
110
a) Atividades:
Avaliação da Capacidade e Maturidade em Usabilidade da Organização: a
avaliação se inicia com uma reunião entre todos os stakeholders do projeto (em
especial, os integrantes da equipe que foram capacitados) para realizar uma
retrospectiva dos fatos, enfatizando a discussão entre os pontos fortes e fracos
identificados durante a aplicação da estratégia.
Vários questionamentos devem ser postos em discussão, tais como:
Quais as principais dificuldades encontradas?
Quais os benefícios obtidos com uso do processo com usabilidade?
Como replicar o conhecimento obtido para outros projetos?
Em seguida, o gestor de usabilidade deve traçar um comparativo entre os
objetivos de negócio e usabilidade definidos no início do projeto com os resultados
encontrados após a execução do plano de melhoria. Além disso, ele deve avaliar se os
objetivos identificados pelos usuários aos produtos da organização estão em sincronia
com os demais objetivos.
Logo após, o gestor de usabilidade apresenta os dados coletados a partir das
métricas definidas para o plano de melhoria, onde pode ser discutida a atuação dos
stakeholders durante todos os ciclos que foram avaliados.
Por fim, cabe ao gestor de usabilidade, a partir de todos os resultados coletados
até então sobre o projeto, realizar uma rápida investigação com intuito de identificar o
nível de maturidade em usabilidade da organização, baseando-se em dois modelos de
avaliação existentes e definidos no capítulo 3: o Modelo Corporativo de Maturidade
em Usabilidade [Nielsen, 2004] e a ISO TR 18529.
Para avaliar o nível de maturidade utilizando-se do modelo corporativo
proposto por Nielsen, o gestor de usabilidade deve estudar a documentação existente
do modelo e verificar em qual a nível a organização se encontra. No caso da ISO TR
18529, uma avaliação comum da norma consiste em verificar, como a organização se
comporta em relação cada processo (HCD 1 a 7). As deficiências encontradas podem
se transformar em sugestões de melhoria para a estratégia.
111
Melhoria contínua da estratégia: após a avaliação de todos os dados
referentes à capacidade e maturidade da organização em usabilidade, podem ser
definidas sugestões de melhoria para a estratégia apresentada neste trabalho, tais
como: (i) definição de novas métricas de avaliação; (ii) definição de novos artefatos de
apoio; (iii) definição de novas atividades dentro de alguma das etapas da estratégia,
dentre outras possibilidades.
Percebe-se que esta atividade difere da atividade de melhoria contínua descrita
ao final da etapa de Execução do Plano de Melhoria. A atividade em questão foca a
realização de suas melhorias nas atividades da estratégia como um todo, enquanto a
atividade anteriormente descrita foca suas melhorias no plano de melhoria em
execução.
b) Ator Principal: Gestor de Usabilidade.
c) Atores Envolvidos: Alta Direção e Equipe de Desenvolvimento.
4.6. Análise de Aderência – ISO TR 18529:2000
Após a definição da estratégia deste trabalho, torna-se necessário avaliar até que
ponto esta estratégia contempla as lacunas identificadas no capítulo 3, ao se integrar os
métodos ágeis e estratégias de apoio à usabilidade (vistos na seção 3.4) ante a ISO TR
18529:2000. O método utilizado para análise segue o mesmo formato de classificação
definido na seção 3.5 do capítulo 3.
4.6.1. Práticas da Estratégia versus ISO TR 18529
O foco desta avaliação consiste em investigar como as atividades definidas na
estratégia deste trabalho estão aderentes às práticas-base dos processos HCD 1 e HCD 2
da ISO TR 18529. O escopo de avaliação limitou-se a estes dois processos, devido à sua
associação com práticas de cunho gerencial e estratégico. Os demais processos são
avaliados de acordo com as atividades realizadas em cada projeto específico, durante a
etapa de Análise (ver seção 4.4.5).
A análise se inicia com a avaliação do processo HCD 1. Na estratégia proposta,
um dos principais objetivos relacionados às atribuições dos consultores e gestores de
usabilidade é o de promover as atividades de usabilidade na organização. Este objetivo é
compatível com a prática-base HCD 1.1, que sugere que a organização esteja sempre
112
relembrando suas equipes sobre a importância em construir produtos com qualidade no
uso.
O conjunto de atividades existente na etapa de investigação organizacional (seção
4.5.1) deste trabalho contempla parcialmente as práticas (HCD 1.2 a 1.5) previstas para
o processo HCD 1. Durante a etapa citada, são realizadas investigações sobre fatores
externos à organização, que incluem informações sobre produtos concorrentes,
aceitabilidade dos usuários ante os produtos desenvolvidos pela organização, contextos
de uso dos produtos, dentre outros. Fatores internos também são considerados, dentre
eles a forma como o usuário é incluído no processo. Estas informações contribuem para
a definição e/ou manutenção dos objetivos estratégicos da organização.
Entretanto, certas atividades previstas na norma ISO em questão não são
contempladas nesta estratégia, como o controle de custos das atividades de usabilidade e
uma análise profunda das tendências dos usuários, como citado na prática HCD 1.5.
Analisando-se o processo HCD 2, verifica-se que a estratégia deste trabalho
encontra-se aderente a sete práticas-base e parcialmente aderente em apenas uma das
práticas-base da ISO. A atividade de escolha das práticas, realizada na etapa de Análise
e Planejamento, contempla a prática base HCD 2.3, quando decide quais métodos de
usabilidade serão incluídos nos processos da organização.
O plano de melhoria, também definido e detalhado durante a etapa de Análise e
Planejamento, inclui boa parte das informações requisitadas pela norma ISO. Ele
especifica o envolvimento do usuário durante o projeto piloto (HCD 2.2), um plano de
como os métodos de usabilidade escolhidos são integrados aos processos (HCD 2.5),
além de como cada ator envolvido deve se comportar no processo (HCD 2.1).
As atividades de capacitação visam iniciar uma nova cultura na organização, com
foco na qualidade de uso. As necessidades de conhecimento em usabilidade das equipes
são identificadas e treinamentos são realizados. A definição do papel de gestor de
usabilidade, após estes treinamentos, torna-se mais uma atividade realizada para garantir
que o conhecimento em usabilidade seja utilizado pela equipe (de acordo com HCD
2.4).
113
Tabela 4.3 - Análise de Aderência entre Práticas da Estratégia versus ISO TR 18529
ISO TR 18529:2000
Estratégia
Classificação
HCD. 1 –
Garantir o
conteúdo de
UCD na
estratégia
do sistema;
1.1. Representar o usuário final.
Definição/detalhamento do
plano de melhoria
A
1.2. Coletar a inteligência do mercado.
Investigação do perfil da
organização
PA
1.3. Definir e planejar uma estratégia
de sistema.
Identificação dos objetivos de
negócio e de usuários
PA
1.4. Coletar o feedback do mercado.
Investigação do perfil da
organização
A
1.5. Analisar as tendências do usuário.
Identificação dos objetivos de
negócio e de usuários
PA
HCD. 2 –
Planejar e
gerenciar o
processo de
UCD
2.1. Consultar stakeholders.
Definição/detalhamento do
plano de melhoria
A
2.2. Identificar e planejar o
envolvimento do usuário.
2.3. Selecionar métodos e técnicas
centrados no usuário.
Análise de conjunto de
práticas de usabilidade
A
2.4. Assegurar que o time de projeto
segue abordagem centrada no humano.
Análise das necessidades de
treinamento;
Capacitação das equipes;
Atribuição do papel de gestor
de usabilidade;
A
2.5. Planejar as atividades de projeto
centrado no humano.
Definição/detalhamento do
plano de melhoria
A
2.6. Gerenciar as atividades centradas
no humano.
Execução/monitoração do
plano de melhoria
A
2.7. Promover a abordagem centrada
no humano.
2.8. Prover suporte ao projeto centrado
no humano.
Escolha/Coleta de métricas;
Avaliação da capacidade;
PA
As atividades previstas pela estratégia ao gestor de usabilidade podem ser
comparadas às atividades das práticas-base HCD 2.6 e 2.7. Cabe ao gestor de
usabilidade ter controle sobre as questões relativas os usuários durante o projeto,
gerenciando as atividades relacionadas aos mesmos (HCD 2.6).
114
A promoção das atividades de usabilidade (HCD 2.7) na organização também é de
responsabilidade do gestor de usabilidade, com apoio do consultor e da alta direção que
deve apoiar as iniciativas e, no futuro, estabelecer políticas organizacionais relacionadas
à usabilidade.
Uma das limitações desta estratégia condiz às atividades previstas na prática-base
HCD 2.8, que sugere a inclusão dos elementos de usabilidade em outros procedimentos
de apoio da organização, como de garantia da qualidade, controle de mudanças,
gerenciamento de recursos, dentre outros. A estratégia limita-se a realizar uma rápida
avaliação das mudanças ocorridas durante a fase de Avaliação. Não foram previstas
atividades de integração entre a estratégia e os demais projetos de apoio ao
gerenciamento da organização.
4.7. Análise Comparativa – P-CMM x Práticas da Estratégia
Outra análise deste capítulo consiste em investigar como algumas atividades da
estratégia deste trabalho encontram-se compatíveis às práticas para gestão e
desenvolvimento da mão-de-obra da organização para melhorar sua capacidade, isto é,
seu nível de conhecimento, habilidades pessoais e habilidades de processos. O escopo
de avaliação refere-se às áreas de interesse do P-CMM de Construção de Grupos de
Trabalho e Cultura e Desenvolvimento das Capacidades Individuais.
A estratégia de avaliação escolhida foi a análise comparativa, onde são ressaltados
os pontos de integração entre as práticas das áreas de interesse supracitadas e as práticas
da estratégia deste trabalho.
4.7.1. Análise da Área de Desenvolvimento das Capacidades Individuais
O escopo de avaliação desta subseção concentra-se nas oito práticas associadas à
área de processo de Treinamento e Desenvolvimento. Esta faz parte do nível de
maturidade 2 (Gerenciado) do P-CMM. Analisando a estratégia proposta neste capítulo,
percebe-se que as atividades previstas para capacitação da organização possuem
atividades em comum às áreas de processo citadas. A tabela 4.4 ilustra os principais
cenários de integração entre os conceitos.
115
Tabela 4.4 - Análise Comparativa entre Práticas da Estratégia versus Treinamento e
Desenvolvimento do P-CMM
Área de Processo – Treinamento e Desenvolvimento
Práticas Associadas ao P-CMM
Práticas da Estratégia Proposta
Em cada equipe, as competências críticas para
realização das tarefas específicas a cada
membro da equipe são identificadas.
Durante a etapa de investigação organizacional,
são coletadas informações a respeito da equipe e
suas respectivas competências atuais.
As necessidades de treinamentos nas
competências identificadas são definidas para
cada membro.
Identificação das necessidades de treinamento
em usabilidade.
Cada equipe define e mantém um plano para
satisfazer suas necessidades de treinamento.
Plano de melhoria de processo em usabilidade
contém informações sobre quais treinamentos
realizados e quais competências associadas.
Equipes inteiras, ou indivíduos em particular
recebem o treinamento requisitado para que
possam realizar suas tarefas.
Realização de treinamentos em conhecimento ou
treinamentos em competências em usabilidade.
Os treinamentos realizados seguem as
definições traçadas no plano de treinamento.
O plano de treinamento encontra-se incluído
dentro do plano de melhoria de processo da
organização.
Discussões sobre o desenvolvimento da
equipe são realizadas de maneira periódica,
com cada membro.
Ao final de cada treinamento, são realizadas
avaliações para se medir o conhecimento em
usabilidade dos envolvidos. Além disso, durante
a fase de Avaliação, estas informações também
são levadas em consideração.
Observando a tabela acima, percebem-se as similaridades entre as práticas
propostas pelo P-CMM e as práticas desta estratégia. Basicamente, esta área de interesse
é explorada durante todas as etapas da estratégia. Durante a investigação organizacional,
são identificados os perfis das equipes de desenvolvimento da organização. Cada
membro da organização responde um questionário investigativo, no qual informa as
suas competências atuais em usabilidade.
Durante a etapa de análise e planejamento, são identificadas as necessidades de
treinamento em organização, levando em consideração as informações obtidas durante a
investigação. Devido ao objetivo da estratégia deste trabalho de manter conformidade
com os princípios ágeis, tais informações são incluídas no plano de melhoria do
processo, evitando a existência de um artefato específico para as práticas de
116
treinamento. Dessa forma, o plano de treinamento previsto pelo P-CMM torna-se parte
integrante do plano de melhoria.
Discussões sobre o desenvolvimento da equipe a partir dos treinamentos
realizados podem ser realizadas durante três momentos da estratégia. Após os
treinamentos, uma avaliação sobre os conhecimentos disseminados é realizada com
cada participante, e estes têm a oportunidade de relatar dificuldades e verificar
conhecimentos obtidos.
Outro momento ocorre ao final de um ciclo de desenvolvimento, durante a etapa
de Execução. Após o encerramento, a equipe pode se reunir visando realizar uma
retrospectiva do ciclo, podendo avaliar se conhecimento obtido durante os treinamentos
possui aplicabilidade prática, ou se serão necessários novos treinamentos.
Um feedback sobre a eficiência dos treinamentos também pode ser obtido ao final
do projeto piloto, durante a fase de Avaliação, quando todos os envolvidos se reúnem e
discutem as lições aprendidas durante a execução do projeto.
Ressalta-se que apenas duas práticas (7 e 8) pertencentes à área de interesse em
questão não foram incluídas na análise comparativa, pois não se vislumbraram
atividades da estratégia que contemplassem estas práticas.
4.7.2. Análise da área de Construção de Grupos de Trabalho e Cultura
O escopo de avaliação desta subseção concentra-se nas práticas associadas à área
de processo de Cultura Participatória (como visto na figura 3.4, no capítulo 3). Esta faz
parte do nível de maturidade 3 (Definido) do P-CMM.
Como visto no capítulo 3, a existência de uma cultura participatória é importante
para organizar grupos de trabalho, de forma que os profissionais trabalhem juntos em
tarefas que possuam interdependência, promovendo a existência de um ambiente no
qual o profissional competente exercita suas capacidades, compartilhe e colabore com o
seu conhecimento para a organização.
117
Tabela 4.5 - Análise Comparativa entre Práticas da Estratégia versus Cultura Participatória do
P-CMM
Área de Processo – Cultura Participatória
Práticas Associadas do P-CMM
Práticas da Estratégia Proposta
Informações sobre a performance da organização
e das equipes são disponibilizadas aos membros
e grupos de trabalho.
Ao final das etapas de investigação e de
análise e planejamento, o consultor em
usabilidade apresenta dados relacionados ao
perfil da organização, habilidades
identificadas e quaisquer outras informações
que auxiliem a estimular a equipe a participar
de atividades de melhoria de seus processos.
Membros da organização são conscientizados de
como suas performances nas atividades
impactam na performance da organização.
A estrutura de processos de tomada de decisão na
organização é analisada.
Durante a etapa de investigação
organizacional, o consultor em usabilidade
investiga o perfil da alta direção.
Processos e papéis relacionados à tomada de
decisão são definidos.
Durante a elaboração do plano de melhoria do
processo, na etapa de análise e planejamento,
o consultor em usabilidade define os papéis e
processos envolvidos nas tomadas de decisão
relacionadas às atividades de usabilidade.
Membros e grupos de trabalho usam o processo
de tomada de decisão definido.
As decisões tomadas pelos membros
responsáveis são apoiadas pela organização.
As decisões tomadas pelo gestor de
usabilidade, durante a execução do projeto
piloto, devem ser respeitadas pelos demais
membros e apoiadas pela alta direção.
Membros e grupos de trabalho são envolvidos
em tomadas de decisão que afetem seus
processos de trabalho.
Em todas as etapas da estratégia, existe um
momento onde os membros da organização
podem sugerir mudanças ou contestar
quaisquer atividades.
Durante o capítulo 2, observou-se que em organizações de desenvolvimento ágil,
os processos de desenvolvimentos existentes são compostos de práticas que, em grande
parte, estimulam a colaboração entre seus executantes. Esta filosofia adequa-se às
práticas previstas na área de processo de Cultura Participatória. Conseqüentemente, a
estratégia deste trabalho alinha-se às práticas desta área de processo.
Analisando as doze práticas definidas, sete estão compatíveis com as atividades da
estratégia deste trabalho. Estas práticas indicam como deve se proceder a participação
de um membro ou um grupo durante as tomadas de decisão da organização. Alinhando
118
com o contexto deste trabalho, investiga-se como a estratégia trata as tomadas de
decisão referentes à usabilidade. A tabela 4.5 apresenta os resultados.
Percebe-se que, assim como nos métodos ágeis, a estratégia estimula a
participação dos usuários em seus processos decisórios. Antes disso, porém, o consultor
de usabilidade investiga o comportamento das equipes com relação à usabilidade e
demonstra os resultados. Neste momento, ele conscientiza a organização sobre suas
limitações, além de ressaltar a importância da realização de atividades de
desenvolvimento visando a qualidade no uso.
Além disso, o consultor de usabilidade deve investigar a maneira como as
tomadas de decisão são realizadas na organização. Para isso, investiga o perfil da alta
direção, como forma de conseguir identificar qual estratégia deve utilizar para
convencer sobre a importância de atividades de usabilidade nos processos.
A construção do plano de melhoria do processo contribui para a definição dos
processos e papéis responsáveis por possíveis tomadas de decisão que venham a ocorrer
durante as etapas da estratégia. O papel do gestor de usabilidade se evidencia, pois ele
será responsável pela condução das atividades de usabilidade, dentre elas a execução do
projeto piloto. Decisões relacionadas às mudanças na definição e execução do plano de
melhoria devem ser respeitadas pelos demais membros da organização.
Entretanto, tais decisões podem ser colocadas em discussão. Caso algum membro
da organização identifique sugestões de melhoria, desvios de especificação ou execução
do plano, este pode sugerir modificações, que devem ser discutidas com os demais
integrantes da equipe, onde todos participam de uma tomada de decisão colaborativa.
A estratégia provê apoio à tomada de decisão em todas as etapas, mais
precisamente durante as atividades de apresentação dos resultados da investigação
organizacional, apresentação do plano de melhoria, ao final dos treinamentos, durante a
execução do plano (ao final de um ciclo) ou durante a fase de avaliação do projeto
piloto.
119
4.8. Considerações Finais do Capítulo
Este capítulo apresentou uma estratégia de apoio à institucionalização da
usabilidade, com foco em ambientes de desenvolvimento ágil. Durante o capítulo,
descreveram-se os atores e artefatos envolvidos, e todas as atividades que compõem
cada etapa da estratégia.
Dentre os artefatos citados, destaca-se o plano de melhoria do processo. Este
artefato pode ser considerado o cerne desta estratégia. Sua construção influencia grande
parte das atividades definidas neste trabalho. Dentre os atores envolvidos, destaca-se o
papel do gestor de usabilidade. Sua atuação perante as equipes de desenvolvimento e de
gerenciamento de projetos será de fundamental importância para o sucesso da estratégia,
em especial durante a execução do projeto-piloto.
Neste trabalho, houve uma preocupação por parte do autor em tornar as atividades
simples, porém eficientes, levando em consideração os princípios das metodologias
ágeis. Mesmo assim, cabe à organização decidir a melhor forma de aplicar esta
estratégia em seus processos específicos. Entretanto, recomenda-se que todas as
atividades sejam realizadas em todas as etapas, haja vista suas interdependências.
Acredita-se que as etapas definidas sejam suficientes para se iniciar uma
preparação e monitoração dos conceitos em usabilidade em organizações com processos
de desenvolvimento e/ou gerenciamento de projetos ágeis, escopo deste trabalho.
Análises de aderência e compatibilidade com normas ISO TR 18529 e P-CMM foram
realizadas, respectivamente, visando demonstrar que atividades da estratégia podem
satisfazer tais normas.
Uma estratégia aderente à ISO TR 18529 auxilia a resolver as lacunas existentes
entre os conceitos dos métodos ágeis e de design centrado no usuário (como visto no
capítulo passado), promovendo uma melhoria de processo e conseqüente aumento da
maturidade em usabilidade na organização. Além disso, as práticas avaliadas do P-
CMM visam demonstrar que as atividades da estratégia podem auxiliar na existência de
um ambiente no qual o profissional competente exercite suas capacidades e colabore
com o seu conhecimento para a organização.
5. Estudo de Caso – Aplicação da Estratégia
Este capítulo apresenta o cenário no qual foi aplicada a estratégia de apoio à
institucionalização da usabilidade descrita neste trabalho. Serão relatados, de forma
detalhada, os desafios encontrados, a aplicação dos passos da estratégia definidos no capítulo
anterior, as lições aprendidas e os resultados atingidos com esta experiência.
5.1. Contexto de Aplicação
O estudo de caso ocorreu durante o período de agosto a dezembro de 2007. O
local no qual este trabalho foi aplicado chama-se Fortes Informática, uma organização
especializada no desenvolvimento de produtos de software contábeis, administrativos,
financeiros e jurídicos, além de soluções na área de conectividade (voz sobre IP e
segurança de redes).
Nesta organização identificaram-se três papéis: a alta direção, dois consultores em
usabilidade (consultores externos, um destes o autor deste trabalho) e a equipe de
desenvolvimento, cada um com suas responsabilidades específicas.
Esta última possuía, durante o período de realização do estudo de caso, vinte e um
funcionários, diferenciados pelas seguintes atribuições: um gerente de desenvolvimento,
quatro gerentes de projeto, um gerente de produto e quinze programadores. Destes vinte
e um funcionários, doze tiveram participação expressiva, contribuindo com valiosas
informações e participando do projeto escolhido como piloto.
Convém observar que não foi necessário procurar por uma organização que se
dispusesse a realizar um projeto piloto com a estratégia deste trabalho. A oportunidade
surgiu da própria organização, que após participar de algumas palestras sobre Interação
Humano-Computador promovidas pelos membros do BR-CHI (Brazilian Human-
Computer Interaction), resolveu incrementar seu processo de desenvolvimento rápido
com práticas de interação humano-computador.
121
5.2. Fatores Críticos de Sucesso da Aplicação da Estratégia
Após uma avaliação da estratégia e definição do projeto piloto, foram definidos os
fatores-chave que seriam decisivos para o sucesso de aplicação da estratégia:
Adaptação das práticas de usabilidade ao processo de desenvolvimento
ágil da organização: foi necessário existir uma constante preocupação para
que a integração de práticas de usabilidade ao processo da organização não
impactasse na produtividade das equipes. Dessa forma, as técnicas e artefatos
a serem adotados teriam que ser eficientes (simples e rápidos de usar).
Comprometimento da organização: por se tratar de uma organização que
utiliza uma política de desenvolvimento ágil de software, foi necessário um
comprometimento tanto da alta organização (no sentido de disseminar
internamente a importância da estratégia) como da própria equipe envolvida
no projeto (que executaria as atividades na prática), para tornar possível a
aplicação deste trabalho.
5.3. Aplicação da Estratégia
As subseções a seguir detalham como foi realizada a aplicação da estratégia aqui
proposta seguindo os passos previamente definidos no capítulo 4.
5.3.1. Investigação Organizacional
a) Investigação sobre o perfil da organização, alta direção e iniciativas em
usabilidade
Nesta etapa inicial, os consultores de usabilidade iniciaram o processo de
conhecer a organização, seus processos e quaisquer experiências anteriores em que
havia participação direta ou indireta do usuário. Este processo, que durou uma semana,
teve início com uma reunião de abertura entre os consultores e a alta direção, com uma
duração aproximada de duas horas. Durante a oportunidade, foram expostas (pela alta
direção) as necessidades de melhoria de seus produtos, que já se encontravam em
ambiente de produção ou em prateleira.
122
Para que a problemática ficasse melhor identificada, a organização apresentou seu
processo e relatou que o mesmo era baseado nas metodologias ágeis eXtreme
Programming e SCRUM. Tal processo era utilizado por todos os projetos em
andamento, mas padecia de uma documentação que detalhasse suas entradas, saídas e
ciclo de vida. A justificativa dos gestores do processo era que, pelo fato do mesmo ser
dinâmico, era suscetível a constantes mudanças, inclusive dentro de um mesmo projeto.
Figura 5.1 - Processo de Desenvolvimento Ágil Identificado na Organização
O processo de desenvolvimento da organização era composto de quatro etapas
principais: Jogo do Planejamento, Desenvolvimento, Deploy e Entrega (como visto na
Figura 5.1). O ciclo era semanal, ou seja, em uma semana todas as atividades citadas
eram realizadas, o que demonstrava o caráter ágil do processo.
A fase de Jogo do Planejamento consistia em especificar as “estórias” que seriam
desenvolvidas durante a semana. Esta fase contava com a participação do cliente, que
semanalmente era convidado pela equipe de desenvolvimento para participar desta
atividade de especificação, até o momento, apenas funcional. Sua função concentrava-se
em expor os requisitos funcionais e como o sistema devia se comportar para tratar estes
requisitos. Tais informações eram registradas em formato de cartões. Vale ressaltar que,
inicialmente, a participação era restrita apenas ao cliente, sem considerar o usuário final
do sistema, fato este que foi modificado posteriormente.
A próxima fase consistia do Desenvolvimento, quando eram realizadas as
atividades de codificação das estórias (ou cartões) especificadas na fase anterior. A
equipe de desenvolvimento utilizava a técnica de programação em pares, como vista no
capítulo 2. As estórias então eram entregues à dupla, que codificava e realizava um
123
rápido teste. A equipe utilizava uma biblioteca de componentes para acelerar o
desenvolvimento.
Na fase de Deploy, todas as estórias desenvolvidas durante a semana eram
reunidas, passavam por um processo de integração e eram avaliadas pelo gerente de
produto, que realizava testes funcionais para garantir que o produto daquele ciclo não
apresentasse desvios, estando, dessa forma, em conformidade com os requisitos
definidos pelo cliente.
Por fim, a fase de Entrega consistia em apresentar ao cliente as “estórias” que
haviam sido desenvolvidas durante a semana. Geralmente, esta fase ocorria na mesma
ocasião em que ocorria a fase do Jogo do Planejamento, sendo executada logo após a
conclusão do mesmo. Era neste momento que o ciclo semanal considerava-se concluído.
Ainda analisando a figura 5.1, percebe-se que não existia, no momento da
entrevista, uma definição formal dos papéis e sua participação dentro das fases do
processo. Este aspecto foi observado pelos consultores em usabilidade e levado em
consideração pela organização.
Após a entrevista inicial de apresentação do processo, aplicou-se um questionário
(desenvolvido pelos consultores) com toda a equipe (vinte e uma pessoas), incluindo o
corpo gerencial envolvido, para levantamento de informações funcionais e diagnóstico
da percepção da organização perante os conceitos de usabilidade. O questionário (ver
apêndice C) continha vinte perguntas relacionadas a dados profissionais e pessoais,
familiaridade com processos, conhecimento sobre práticas de usabilidade, dentre outros
itens.
A Figura 5.2 ilustra uma pergunta existente no questionário aplicado com a
equipe. Indagou-se, a partir de uma lista de estratégias, qual seria considerada a
principal solução para auxiliar a promover maior integração de usabilidade nos projetos,
e, por conseqüência, uma mudança cultural desejada pela organização.
A mesma figura ilustra o resultado da pergunta acima. Os funcionários
classificaram que a prioridade principal da equipe era ser capacitada através de
treinamentos, fossem eles práticos ou teóricos (52%). Logo em seguida, a segunda
prioridade definida era a de receber consultoria nos projetos e avaliações de interfaces
(33%), solução esta considerada uma forma alternativa de capacitação.
124
Por fim, a solução definida com menor prioridade pela organização foi a de
aumento da equipe de usabilidade (12%). Em uma posterior conversa com os membros
da organização, estes relataram que o conhecimento a ser absorvido pela equipe seria
disseminado para o resto da organização por todos os envolvidos no projeto piloto, fato
este que eliminava a existência de uma equipe específica de usabilidade.
Figura 5.2 - Ordem de Prioridade das Soluções para Adoção de Usabilidade
Neste mesmo questionário, também foram investigadas quais iniciativas em
usabilidade a organização já havia aplicado (mesmo que esporadicamente) ou possuía
conhecimento. Além destas informações, foram questionados também aspectos
relacionados ao perfil da alta direção. Tais resultados podem ser vistos com mais
detalhes no apêndice C.
b) Identificação dos objetivos de negócio e de usabilidade
Ainda durante as reuniões iniciais (no total, foram três) os consultores em
usabilidade auxiliaram a alta direção a estabelecer objetivos de negócio relacionados à
intenção da organização em aumentar sua participação no mercado. Estes objetivos
foram subdivididos em dois (seguindo classificação definida no capítulo 3, seção 3.2.1):
Objetivos externos:
o Aumentar satisfação dos seus clientes no uso de seus produtos:
visando a fidelização dos seus atuais clientes, a organização buscava
melhorar a satisfação dos clientes com os produtos desenvolvidos.
Objetivos internos:
o Propiciar maior envolvimento do usuário durante o processo: a
organização já possuía a cultura de envolver um representante do cliente
125
em atividades dos seus processos, como prega a filosofia ágil. Entretanto,
ela necessitava considerar a participação do usuário final nas atividades,
visto que os produtos necessitavam ser desenvolvidos e/ou evoluídos em
conformidade com as necessidades destes usuários.
o Capacitar a organização nos conceitos de usabilidade: para construir
produtos com maior qualidade de uso, a organização acreditava que seria
necessário capacitar suas equipes (em especial a de desenvolvimento)
com conhecimento em usabilidade.
o Evoluir os produtos existentes e o processo de desenvolvimento: os
atributos de qualidade existentes nos produtos, além das atividades
existentes no processo de desenvolvimento da organização necessitavam
se adequar com as atividades de usabilidade que seriam realizadas.
Sendo assim, os consultores de usabilidade sugeriram alcançar os objetivos
estabelecidos, com a definição e execução de um plano de melhoria em usabilidade no
processo de desenvolvimento atual. Dessa forma, os objetivos de usabilidade que a
organização buscou foram os seguintes:
Tratar requisitos de usabilidade: considerar requisitos de sistemas
relacionados à usabilidade, durante a especificação e evolução de um produto;
Envolver os usuários reais dos produtos: conhecer com maiores detalhes os
usuários de seus produtos, com intuito de desenvolver soluções compatíveis
com suas necessidades;
Investigar potenciais problemas de interação: diagnosticar possíveis erros
de interação entre o usuário e a interface, antes que estes ocorressem em
ambiente de produção.
Prover consistência e uso de padrões: promover uma padronização das
interfaces de seus produtos construídos ou em desenvolvimento, visando uma
maior segurança no uso por parte dos usuários.
Portanto, após esta análise inicial, foi possível entender as intenções da
organização pelas práticas de usabilidade, conhecer a familiaridade dos envolvidos com
os conceitos de usabilidade, fazer uma reflexão sobre o que deveria conter o processo de
melhoria de desenvolvimento de software.
126
5.3.2. Análise e Planejamento das Atividades
Passada a primeira etapa, os consultores de usabilidade iniciaram o planejamento
de um conjunto de atividades visando a definição e detalhamento do plano de melhoria
a ser aplicado na organização.
a) Definição do Plano de Melhoria
A partir dos objetivos de negócio e usabilidade estabelecidos, os consultores em
usabilidade se reuniram com a alta direção e realizaram uma associação entre estes
objetivos (ver tabela 5.1.).
Tabela 5.1 - Objetivos de Negócio versus Objetivos de Usabilidade
Objetivos de Negócio
Objetivos de Usabilidade Associados
Externos
Internos
Aumento da
satisfação dos
usuários
Incrementar o envolvimento do
usuário final
- Envolver os usuários reais dos produtos
Capacitar a organização em
usabilidade
- Prover consistência e uso de padrões;
- Investigar potenciais problemas de interação;
- Tratar requisitos de usabilidade.
Evoluir os produtos e o processo
de desenvolvimento
Logo após, os consultores realizaram uma análise de quais práticas de usabilidade
poderiam ser aplicadas na organização. Com base nas informações colhidas e seguindo
os passos definidos no capítulo 4, eles definiram um conjunto inicial de práticas que
foram aplicadas no ambiente produtivo da equipe de desenvolvimento.
As práticas escolhidas pelos consultores visavam criar uma constante preocupação
da organização com a qualidade de uso de seus sistemas, durante todo o ciclo de vida do
processo, causando o menor impacto possível no tempo de desenvolvimento do projeto.
Dessa forma, foram escolhidas práticas que se relacionassem com todas as fases do
processo de desenvolvimento.
Além disso, buscou-se escolher as práticas nas quais a organização já possuía
alguma competência. A tabela 5.2 explicita as práticas selecionadas, suas justificativas
de escolha e viabilidades de suas aplicações na prática, além de relacionar as práticas às
fases do processo de desenvolvimento.
127
Tabela 5.2 - Práticas de Usabilidade Escolhidas
Prática
Justificativa
Viabilidade
Fases
Relacionadas
Elicitação de
Requisitos de
Usabilidade
Necessidade da
organização em coletar
requisitos não
funcionais, até então
inexistentes.
Possível de ser realizada
logo após a coleta dos
requisitos funcionais.
Viável, mas necessita
capacitação.
- Jogo do
Planejamento
- Entrega
Prototipação
Rápida
(baixa
fidelidade)
Rápida, feita em papel e
com intuito de melhorar
a comunicação cliente-
desenvolvedor.
Prática já realizada pela
equipe, bastando capacitá-
la a identificar aspectos de
usabilidade.
- Jogo do
Planejamento
Distribuição de
Cartões
Útil para estruturar
idéias, definir requisitos
e orientar
desenvolvimento rápido.
Prática já realizada pela
equipe, bastando a
considerar aspectos de
usabilidade.
- Jogo do
Planejamento
- Desenvolvimento
Recomendações
Ergonômicas
Recomendações
utilizadas para
conscientizar a equipe e
promover melhoria na
qualidade de uso.
Possível artefato de apoio,
contendo um conjunto de
melhores práticas a serem
levadas em consideração
pela equipe.
- Desenvolvimento
- Deploy
Guias de Estilo
Definições de design
com intuito de
padronizar as interfaces
dos sistemas.
Artefato de apoio,
utilizado durante a
construção/avaliação dos
protótipos.
- Desenvolvimento
- Deploy
Avaliação
Heurística
Utilizada para avaliar as
interfaces desenvolvidas
pela equipe, utilizando-
se das heurísticas de
usabilidade definidas.
Possível de ser realizada
desde a criação dos
protótipos iniciais até
momentos antes da
entrega ao cliente.
Necessita de capacitação
da equipe.
- Desenvolvimento
- Entrega
Observação do
Uso
Técnica utilizada com
intuito de averiguar o
contexto de uso do
sistema e sua influência
no comportamento do
usuário.
Prática destinada apenas
para interfaces mais
complexas, onde fosse
exigido maior esforço
cognitivo por parte do
usuário
- Deploy
- Entrega
Baseando-se na escolha das práticas descritas acima, os consultores iniciaram uma
análise sobre as competências em usabilidade necessárias à organização para aplicá-las.
Seguindo a estratégia deste trabalho, os consultores traçaram um mapeamento, como
visto na figura 5.3.
128
Figura 5.3 - Práticas de Usabilidade, Competências Requeridas e Treinamentos
Como resultado do mapeamento realizado na figura 5.3, os consultores de
usabilidade realizaram um brainstorming, onde foram definidas as possibilidades de
treinamento a serem incluídas no plano de melhoria em usabilidade. Algumas
necessidades de treinamento (padrões de design e metas de usabilidade) foram
contempladas por diferentes treinamentos.
b) Detalhamento do Plano de Melhoria
Definidas as práticas (além do momento de aplicação das mesmas) e as
possibilidades de treinamento, os consultores de usabilidade iniciaram o planejamento
das atividades de melhoria. Inicialmente, foram definidos os atores envolvidos e suas
129
respectivas participações nas práticas de usabilidade (definidas na tabela 5.2) a serem
realizadas no plano de melhoria. Em seguida, os consultores de usabilidade reuniram-se
com a alta direção e a equipe de desenvolvimento e realizaram uma atividade similar à
construção de um Product Backlog do SCRUM. A definição das práticas de usabilidade
e dos treinamentos foi considerada fundamental para o plano de melhoria. Em conjunto,
eles classificaram as atividades do plano de melhoria, ordenando-as por prioridade de
execução, como visto na tabela 5.3.
Tabela 5.3 - Atividades do Plano de Melhoria
Ordem
Atividade
Executor
Participantes
1
Capacitação em conceitos fundamentais
da usabilidade
Consultor
Gerentes e Equipe
Desenvolvimento
2
Capacitação em Elicitação de Requisitos
de Usabilidade
Consultor
Gerentes e Equipe
Desenvolvimento
3
Capacitação em Uso de Protótipos
Consultor
Gerentes e Equipe
Desenvolvimento
4
Capacitação em Inspeção da Usabilidade
Consultor
Gerentes e Equipe
Desenvolvimento
5
Elicitação de Requisitos considerando
critérios de usabilidade
Gerente de
Produto
Usuários e Equipe de
Desenvolvimento
6
Construir protótipos de baixa fidelidade
Gerente de
Produto
Usuários e Equipe de
Desenvolvimento
7
Desenvolver estórias de usuários
envolvendo aspectos de usabilidade
Gerente de
Produto
Usuários e Equipe de
Desenvolvimento
8
Fazer uso de recomendações
ergonômicas e guias de estilo durante a
construção de interfaces.
Equipe de
Desenvolvimento
-
9
Realizar uma avaliação heurística das
interfaces construídas
Gerente de
Produto
Equipe de
Desenvolvimento
10
Observar o uso da interface pelos
usuários
Gerente de
Produto
Usuários
11
Coletar métricas estabelecidas
Gerente de
Produto
Consultor
12
Reunir equipe e discutir resultados
atingidos, a cada ciclo
Gerente de
Produto
Equipe de
Desenvolvimento
13
Divulgar os resultados atingidos em cada
ciclo
Gerente de
Produto
Clientes, Usuários e,
Alta Direção
130
Analisando a tabela 5.3, destaca-se a importância do consultor de usabilidade no
início das atividades de melhoria. Ele foi o responsável por disseminar o conhecimento
em usabilidade na organização. Percebe-se também a importância da participação dos
gerentes (especificamente, o Gerente de Produto) nas atividades previstas.
Ressalta-se também a participação dos usuários em atividades previstas de serem
realizadas tanto no início quanto no fim de um ciclo do processo de desenvolvimento.
As informações necessárias ao plano de melhoria estão detalhadas no apêndice C.
5.3.3. Execução do Plano de Melhoria em Usabilidade
a) Capacitação da Organização
A execução do plano iniciou-se com as atividades de capacitação das equipes de
desenvolvimento e dos gerentes da organização. Os treinamentos escolhidos (ver tabela
5.4) tiveram por objetivo despertar a organização para o conhecimento em usabilidade.
Tabela 5.4 - Atividades de Capacitação Realizadas na Organização
Capacitação
Objetivo
Workshop Motivacional
- Apresentação dos conceitos gerais de IHC;
- Sensibilização sobre a importância das práticas de IHC no
desenvolvimento de sistemas mais usáveis e sobre a
possibilidade de Retorno de Investimento (ROI) ao aplicar
estas técnicas nos projetos.
Especificação de Requisitos
de Usabilidade
- Sensibilização sobre a importância de coletar requisitos não
funcionais, incluindo os de usabilidade;
- Apresentação de estratégias para coleta.
Uso de Protótipos
- Apresentação dos conceitos de prototipação rápida;
- Sensibilização sobre uso de protótipos no Jogo do
Planejamento.
Inspeção da Usabilidade
- Apresentação das práticas de inspeção da usabilidade e
artefatos de apoio;
- Sensibilização sobre importância de realizar inspeção da
usabilidade para se antecipar a problemas durante uso da
interface.
Após a realização dos treinamentos, um questionário pós-treinamento (ver modelo
no apêndice E) foi aplicado com os envolvidos, visando identificar a reação da equipe
com os novos conceitos. Além disso, serviu como base para alta direção e os
consultores de usabilidade identificarem membros da equipe com o perfil de
disseminador em potencial da usabilidade dentro da organização.
131
b) Atribuição do papel de Gestor de Usabilidade
O próximo passo consistiu em definir um responsável para executar o papel de
Gestor de Usabilidade e suas atribuições específicas. Neste estudo de caso, este papel foi
exercido pelo Gerente de Produto do projeto. Este foi escolhido por sua afinidade com os
conhecimentos disseminados e, principalmente, pelo seu objetivo estratégico dentro do
projeto, que consistia em garantir que os módulos do produto entregues semanalmente ao
cliente estivessem de acordo com os requisitos pré-estabelecidos.
Dentre as suas atividades realizadas durante a execução do plano de melhoria,
constam as seguintes:
- Participação no Jogo do Planejamento, auxiliando e estimulando a equipe a
coletar requisitos de usabilidade;
- Inspeção dos protótipos de baixa fidelidade e nas versões liberadas durante o
ciclo semanal, fazendo uso de listas de verificação (checklist);
- Monitoramento do uso dos artefatos específicos de usabilidade pela equipe de
desenvolvimento (protótipos, guias de estilo, padrões gráficos);
- Condução do plano de melhoria (no caso, realizado em um projeto piloto)
c) Execução de um projeto piloto
Após a realização das atividades de capacitação da equipe e da escolha do gestor
de usabilidade, foi iniciada a etapa de aplicação dos conhecimentos adquiridos dentro do
processo de desenvolvimento da organização.
Os consultores se reuniram com os gestores do processo e o gestor de usabilidade
e definiram uma nova macro-visão (ver figura 5.4) do processo incluindo práticas de
usabilidade (destacadas em cor mais escura na figura 5.4), assim como escolheram qual
projeto real da empresa seria utilizado como projeto piloto. Este projeto seria executado
pela equipe, em conjunto com o Gestor de Usabilidade, e sob monitoramento da alta
direção e dos consultores de usabilidade.
Fazendo uma análise comparativa entre as duas macro-visões (figuras 5.1 e 5.4),
nota-se a evolução pretendida para o processo. Percebe-se também a participação dos
usuários, em especial, a participação do Gestor de Usabilidade. Foram incluídos três
conjuntos de práticas (Prototipação Executável, Inspeção de Usabilidade e Testes de
132
Usabilidade), onde cada um destes conjuntos possuía um conjunto de atividades que
estão detalhadas nos próximos parágrafos.
Figura 5.4 - Nova Macro-Visão, com Inclusão de Práticas de Usabilidade
O projeto escolhido como piloto tratou-se de um projeto responsável pelo
desenvolvimento de um sistema de controle de tráfego urbano, requisitado por uma
empresa de transporte urbano local, cliente da organização deste estudo de caso. O
objetivo deste sistema era de substituir outro já em produção, que vinha se comportando
de maneira instável e com constantes relatos de dificuldade de uso. Tais problemas
geravam insatisfações por parte dos usuários que o utilizavam (no caso, funcionários da
empresa de transporte urbano), impactando em suas rotinas de trabalho e comprometendo
a qualidade do serviço prestado à população.
Ressalta-se que alguns dos resultados do estudo de caso visto neste capítulo já
haviam sido publicados em trabalho realizado pelo mesmo autor [Barbosa et al, 2007]. A
execução do projeto piloto continuou com a execução dos passos especificados na
proposta e detalhados nos próximos parágrafos.
Na etapa de Jogo do Planejamento, realizada durante a primeira semana, foi
definido, em consenso com o cliente, que seria destinado um momento para
levantamento de requisitos não funcionais com foco em requisitos de usabilidade (tais
como: personalização e persuasão). Foi explicado brevemente ao cliente o significado
daquela iniciativa, que foi prontamente aceita pelo mesmo.
133
Dessa forma, enquanto a equipe obtinha informações funcionais e as especificava
em cartões (ver figura 5.5), o Gestor de Usabilidade preocupava-se em gerar cartões
com informações não-funcionais e em validá-los com o usuário. Desta atividade surgiu
o conceito de “Cartão de IHC” (ver mais detalhes na figura 5.7), uma evolução dos
cartões utilizados pela equipe, destinado a detalhar os objetivos dos usuários.
Figura 5.5 - Uso de Cartões para Considerar Requisitos de Usabilidade
Ainda nesta fase, foram avaliados, rapidamente, os protótipos de baixa fidelidade
(ver figura 5.6) definidos em conjunto com o cliente. Coube ao Gestor de Usabilidade
também assumir esta função. É válido ressaltar que neste momento a participação ficou
restrita apenas ao cliente do projeto, sem levar em consideração o usuário final do
sistema, fato este que foi alertado pelos consultores e modificado na semana seguinte.
Figura 5.6 - Construção e Avaliação de Protótipos de Baixa Fidelidade
134
Durante a fase de Desenvolvimento e Deploy, os protótipos de alta fidelidade
foram construídos pela equipe de desenvolvimento. Estes foram verificados pelo Gestor
de Usabilidade, que utilizou a prática de avaliação heurística.
Nesta prática, ele averiguava se as interfaces desenvolvidas estavam em
conformidade com as regras definidas em um artefato de apoio, denominado lista de
verificação, disponibilizado pelos consultores. O Gestor de Usabilidade conduziu a
inspeção utilizando-se deste artefato e caso encontrasse algum desvio, gerava um novo
Cartão de IHC (ver figura 5.7) e o encaminhava à equipe, que buscava uma correção.
Figura 5.7 - Cartão de Desenvolvimento versus Cartão de IHC
Outro artefato de apoio disponibilizado pelos consultores ao Gestor de
Usabilidade foi o chamado Guia de IHC (ver apêndice F). Este guia reunia informações
sobre atributos de design (layout, posicionamento) e comportamento das interfaces,
além de recomendações ergonômicas, a serem utilizadas pela equipe durante todo o
processo de desenvolvimento, em especial durante as atividades de prototipação
executável, onde seriam construídas as interfaces a serem utilizadas pelos usuários. Este
artefato acabou por substituir o lista de verificação, como visto acima.
Para encerrar o ciclo do processo de desenvolvimento, a atividade de avaliar a
usabilidade do sistema interativo com o próprio usuário como um todo ainda precisava
ser realizada. Nesta oportunidade, o usuário foi convidado a realizar um teste rápido do
sistema [Krug, 2005] e, após esta atividade, realizar uma avaliação qualitativa, onde
seria questionada a sua satisfação no uso do sistema.
Enquanto realizava o teste, o Gestor de Usabilidade observava a utilização (ver
figura 5.8) das interfaces que haviam sido construídas pela equipe de desenvolvimento
135
com o auxílio das práticas de usabilidade definidas no plano de melhoria. Os usuários
convocados eram instruídos a navegar pelas interfaces e realizar tarefas básicas.
Figura 5.8 - Observação do Uso das Interfaces do Sistema
Na medida em que as dificuldades de entendimento ou de uso fossem sendo
identificadas, os usuários compartilhavam estas informações com o gestor de
usabilidade. Tais informações eram registradas e discutidas posteriormente com a
equipe, com a possibilidade das mesmas se transformarem em novas estórias de
usuários (cartões). Ao final desta atividade, uma rápida avaliação subjetiva foi realizada
com o usuário, de maneira a questioná-lo sobre sua satisfação com o uso do produto.
d) Melhoria Contínua
No total, o plano de melhoria teve a duração de oito ciclos de desenvolvimento
(dez semanas). Ao final de cada ciclo, a equipe de desenvolvimento se reunia a fim de
realizar uma retrospectiva das atividades realizadas no ciclo específico. O Gerente de
Produto, por acumular a função de Gestor de Usabilidade, tinha então a possibilidade de
colocar em discussão as atividades de melhoria realizadas no projeto piloto. Seguem
abaixo algumas mudanças realizadas nas atividades previstas no plano de melhoria:
Avaliação heurística em pares: pelo fato de utilizarem a programação em
pares, o gestor de usabilidade sugeriu a realização de uma rápida inspeção da
usabilidade, logo após a construção da interface. Esta atividade foi
incorporada da seguinte maneira: após a construção de uma interface por um
membro da equipe, outro membro era escolhido para avaliar a interface e
encaminhava as sugestões de mudança para o gestor de usabilidade.
136
Tempo curto para examinar artefatos: membros da equipe de
desenvolvimento afirmaram que possuíam pouco tempo disponível para
estudar as recomendações ergonômicas e guias de estilos definidos. O Gerente
de Produto então aumentou o tempo previsto para essa atividade.
Sugestão de nova atividade: durante a fase de desenvolvimento do produto, o
Gestor de Usabilidade sentiu a necessidade de realizar uma nova atividade
com os usuários. A atividade consistia em validar a estrutura de menus da
aplicação. Como não havia atividade prevista com este intuito dentro do plano
de melhoria, ele decidiu convidar alguns usuários (experientes e novatos) e
realizou um brainstorming com os mesmos. Os resultados desta atividade
foram novos cartões de IHC a serem codificados pela equipe de
desenvolvimento, visando modificar a aplicação com os resultados obtidos.
5.3.4. Análise das Ações Realizadas
Como visto acima, ao final de cada ciclo de desenvolvimento, um momento de
reflexão sobre possibilidades de melhoria era realizado. Entretanto, tais melhorias
concentravam-se apenas em sugerir mudanças para o plano de melhoria de um projeto
específico. Era necessário existir um momento onde as atividades da estratégia como
um todo fossem avaliadas, buscando identificar pontos que pudessem evoluir a
estratégia, a fim de servirem como lições aprendidas e aproveitadas nos demais projetos
da organização.
Análise da Capacidade e Maturidade em Usabilidade da Organização
A avaliação iniciou-se com uma reunião entre todos os envolvidos do projeto.
Nela foram discutidos os sucessos e falhas encontradas durante a aplicação do projeto
piloto, como visto nos resultados abaixo.
Pontos Positivos:
Prototipação em papel demonstrou ser um instrumento simples e eficiente para
apoiar a comunicação entre os usuários e a organização durante o
desenvolvimento dos requisitos.
137
Foi formalizada a presença do usuário final dentro do processo, que antes não
diferenciava os termos cliente (geralmente, apenas um especificador) e usuário
(aquele(a) que irá utilizar a ferramenta).
A criação de Cartões de IHC surgiu como outra melhoria do processo. A
equipe já utilizava este recurso como entrada para o desenvolvimento. Foram
incluídas algumas informações para diferenciar este cartão do modelo
convencional (como: prioridade, sugestão de melhoria ou correção de
problema de usabilidade) e priorizar as necessidades dos usuários.
Antes da aplicação deste trabalho, quando algum requisito gerava dúvida entre
os participantes e o protótipo desenvolvido não facilitava seu entendimento, o
protótipo era descartado e substituído por um relato dos usuários, geralmente
dispendiosos e sem objetividade. Com a geração de várias alternativas de
protótipos, considerando opiniões de todos os participantes envolvidos, esta
prática tornou-se mais eficiente. Avaliando os protótipos era possível
esclarecer possíveis desvios de comunicação entre o usuário e a organização.
Pontos Negativos (e passíveis de melhoria da estratégia):
A concentração das atividades de melhoria de processo (através do papel de
Gestor de Usabilidade) e de gerência do desenvolvimento pelo Gerente de
Produto deveria ser acompanhada pelos consultores de usabilidade, evitando-
se a sobrecarga de atividades.
A identificação das práticas a serem incluídas não foi simples. Considerando o
aspecto ágil do processo, teve-se que provar (inicialmente) baseado nas nossas
experiências em projetos anteriores que os resultados poderiam ser
promissores [Barbosa et al, 2006].
A atividade de coleta de métricas, definida pela estratégia, não foi realizada. O
Gestor de Usabilidade relatou que teve dificuldade no entendimento das
mesmas. Uma sugestão de melhoria definida pelos envolvidos foi a de definir
uma atividade de capacitação em medição e análise, com foco em usabilidade.
O comprometimento da equipe deixou a desejar, principalmente durante o uso
de recomendações ergonômicas e guias de estilo. Sugeriu-se revisar estas
atividades, tentando torná-las mais eficientes.
138
Após esta avaliação, o gestor de usabilidade reexaminou os objetivos de negócio e
de usabilidade definidos durante a estratégia e compararam com os resultados obtidos.
Todos os resultados obtidos buscavam como objetivo principal a satisfação dos usuários
de seus produtos, estando, portanto, em sincronismo como os objetivos de negócio.
Por fim, os consultores de usabilidade, em conjunto com os gestores de
usabilidade, realizaram uma avaliação da maturidade em usabilidade da organização,
após a realização das atividades de melhoria. Para isso, fizeram uma análise
comparativa entre os resultados encontrados e as características do modelo proposto
pela ISO TR 18529:2000, visto com detalhes no capítulo 3 (seções 3.2.2 e 3.2.4).
Tabela 5.5 - Análise da Maturidade com Uso da ISO TR 18529
Resultados do Trabalho para um
projeto piloto
Práticas da ISO beneficiadas
Objetivos de negócio e usabilidade
alinhados
HCD 1.3 - Definir e planejar uma estratégia de sistema.
Equipes capacitadas com conhecimento
e práticas de usabilidade.
HCD 2.4 - Assegurar que o time de projeto segue
abordagem centrada no humano.
HCD 2.7 - Promover a abordagem centrada no humano.
Aumento da participação dos usuários
finais, ao invés de um representante.
HCD 1.1 - Representar o usuário final;
HCD 2.2 - Identificar e planejar o envolvimento do
usuário.
Uso de protótipos de baixa fidelidade
no apoio à definição de requisitos de
usabilidade e comunicação entre a
equipe de desenvolvimento e o usuário.
HCD 5.3 - Explorar o design do sistema;
HCD 5.6 - Desenvolver protótipos;
HCD 6.2 - Validar protótipos recentes a fim de definir
requisitos para o sistema.
Criação de cartões de IHC
HCD 4.1 - Identificar e documentar as tarefas do usuário.
HCD 5.5 – Especificar o sistema;
HCD 6.4 - Validar o sistema a fim de checar se os
requisitos do sistema foram satisfeitos
Interfaces inspecionadas com o uso de
recomendações ergonômicas e guias de
estilo
HCD 6.3 - Validar protótipos a fim de melhorar o design.
Interfaces avaliadas quanto à
usabilidade, após construção das
mesmas, pelos usuários.
HCD 6.4 - Validar o sistema a fim de checar se os
requisitos do sistema foram satisfeitos.
139
Para cada resultado obtido com as atividades realizadas no plano de melhoria, foi
feita uma associação das práticas da ISO que se beneficiaram destes resultados, como
visto na Tabela 5.5.
Desta forma, o gestor de usabilidade pôde observar como cada resultado atingido
satisfazia uma ou mais práticas da ISO, contribuindo para a maior maturidade em
usabilidade da organização. Dos resultados encontrados na Tabela 5.5, destacam-se
dois, a criação de cartões de IHC e o uso de protótipos de baixa fidelidade.
Estas duas novas atividades do processo, apesar de serem simples, contribuíram
para que a organização executasse na prática seis práticas-base previstas na ISO em
questão. Além disso, foram rapidamente aceitas pela equipe e incorporadas ao processo
de desenvolvimento da organização (ver figura 5.4), tornando-se as práticas de
usabilidade de maior utilização pela equipe de desenvolvimento.
Percebe-se, portanto, que a realização das atividades de avaliação da capacidade e
maturidade em usabilidade contribuiu para que todos os envolvidos (em especial o
Gestor de Usabilidade) conseguissem adquirir uma visão geral do impacto das
mudanças realizadas na organização com a aplicação desta estratégia.
5.4. Considerações Finais do Capítulo
Este capítulo apresentou a aplicação de um estudo de caso relacionado aos
conceitos definidos na proposta deste trabalho (capítulo 4) em um projeto real, dentro de
uma organização foco no desenvolvimento ágil. Houve a preocupação em descrever a
experiência tentando sempre traçar um comparativo com a estratégia proposta. Dessa
forma, resultados do estudo de caso eram descritos à medida que eram encontrados.
Assim como no capítulo anterior, o plano de melhoria ganhou atenção especial
neste capítulo. Demonstrou-se todo o ciclo de vida do mesmo, desde a coleta das
informações que fariam parte, passando pelas atividades de definição do plano de
melhoria e logo após o detalhamento e a avaliação deste mesmo plano.
A partir dos resultados encontrados, concluiu-se que a execução do estudo de caso
atingiu seus objetivos esperados. Com exceção das atividades relacionadas à coleta de
métricas, que não foram realizadas, as demais atividades proporcionaram uma quebra de
paradigma existente na maneira da organização de desenvolver produtos de software.
140
Para o Gestor de Usabilidade, a experiência foi importante para que o mesmo
analisasse a maneira como a organização reagiria ao seu trabalho, haja vista que grande
parte das atividades realizadas foi conduzida pelo mesmo. No caso da alta direção, a
execução de um estudo de caso foi importante para que a mesma pudesse se convencer
sobre a importância em considerar a usabilidade como um componente estratégico. Os
consultores de usabilidade também se beneficiaram dos resultados obtidos, pois
puderam identificar novas possibilidades de melhoria da estratégia.
6. Conclusões
Este capítulo finaliza o trabalho, apresentando as contribuições da pesquisa, algumas
dificuldades encontradas e perspectivas futuras para o trabalho.
6.1. Conclusões
O principal objetivo deste trabalho consistiu em propor uma estratégia que
servisse como um guia para profissionais (consultores de usabilidade, executivos,
gestores de processo, gestores de projeto, etc.) interessados em institucionalizar práticas
de usabilidade em seus processos de desenvolvimento com foco na abordagem ágil.
Para tornar possível a definição desta estratégia, foi necessário refletir sobre
possíveis mudanças nos paradigmas de desenvolvimento e gerenciamento de projetos
ágeis investigados neste trabalho (Extreme Programming e SCRUM, respectivamente)
além de práticas de Design Participativo, de maneira a incluir atividades relacionadas à
usabilidade, sem que isto comprometesse a produtividade das equipes.
Logo após, refletiu-se sobre o papel do profissional de usabilidade e algumas
estratégias de apoio à institucionalização da usabilidade demonstraram como a
usabilidade poderia ser utilizada como componente estratégico e de diferencial
competitivo dentro das organizações. Além disso, refletiu-se sobre como a organização
deveria gerenciar as competências em usabilidade
Concluiu-se, a partir dos resultados obtidos com a realização de análises de
aderência, que algumas práticas tanto do SCRUM quanto do XP possuíam aderência
total ou parcial a alguns processos da ISO TR 18529, sendo possível uma integração
entre ambos. Além disso, as estratégias de apoio descritas no capítulo foram analisadas
e foi identificado que as mesmas poderiam também ser integradas aos processos da ISO
em questão, contribuindo para a institucionalização da usabilidade.
Portanto, a estratégia deste trabalho baseou suas atividades em uma integração de
três conceitos fundamentais: as abordagens de desenvolvimento ágil (XP e SCRUM),
um modelo de gestão de pessoas (People-CMM) e um modelo de maturidade em
usabilidade (ISO TR 18529).
142
O estudo de caso realizado comprovou a viabilidade de integração destes
conceitos na prática, realizando atividades que passaram a fazer parte da rotina de
desenvolvimento de software e contribuíram para uma mudança na cultura de
desenvolvimento da organização.
6.2. Contribuições da Pesquisa
Pode-se elencar as seguintes contribuições obtidas a partir da definição da
estratégia do trabalho e da realização do estudo de caso:
Mudança de foco das organizações: o foco da organização em concentrar
esforços no desenvolvimento de funcionalidades foi repartido com a
importância em considerar atividades relacionadas a uma melhoria da
qualidade de uso de seus produtos;
Integração de práticas de usabilidade e design participativo em um processo de
desenvolvimento ágil de software. As práticas de usabilidade auxiliaram as
organizações a extrair, com maior produtividade, um conjunto de informações
sobre os usuários, tarefas e o contexto de uso que contribuíram para a
construção de um melhor produto. As práticas de design participativo
auxiliaram as organizações a promover um ambiente de colaboração do
usuário com a organização, gerando credibilidade ao projeto.
A aderência da estratégia deste trabalho à ISO TR 18529 auxiliou a resolver as
lacunas existentes entre os conceitos dos métodos ágeis e de design centrado
no usuário, promovendo uma melhoria de processo e conseqüente aumento da
maturidade em usabilidade na organização.
A integração de práticas existentes no P-CMM na estratégia deste trabalho
contribuiu na definição de um ambiente no qual o profissional competente
exercitou e desenvolveu suas capacidades em usabilidade, além de colaborar
com o seu conhecimento para a organização.
A definição de um plano de melhoria de processo, com atividades estruturadas
e dividas por etapas, artefatos e atores, foi uma das principais contribuições
deste trabalho. Dessa forma, foi possível guiar a organização na condução das
143
atividades de melhoria de processo que deveriam ser realizadas, sempre com
preocupação em não aportar impactos na produtividade das equipes.
A existência de um especialista em usabilidade dentro das equipes foi
importante como forma de orientar e estimular os demais integrantes sobre as
práticas de usabilidade, haja vista que o foco da equipe de desenvolvimento se
concentrava na construção do produto.
A partir dos resultados encontrados no estudo de caso, concluiu-se que a
execução do mesmo atingiu seus objetivos esperados. Com exceção das
atividades relacionadas à coleta de métricas, que não foram realizadas, as
demais atividades proporcionaram uma quebra de paradigma existente na
maneira da organização de desenvolver produtos de software.
Ainda comentando sobre o estudo de caso, para o gestor de usabilidade, a
experiência foi importante para que o mesmo analisasse a maneira como a
organização reagiria ao seu trabalho, haja vista que grande parte das atividades
realizadas foi conduzida pelo mesmo. No caso da alta direção, a execução de
um estudo de caso foi importante para que a mesma pudesse se convencer
sobre a importância em considerar a usabilidade como um componente
estratégico. Os consultores de usabilidade também se beneficiaram dos
resultados obtidos, pois puderam identificar novas possibilidades de melhoria
da estratégia proposta.
6.3. Dificuldades Encontradas
As dificuldades de realização deste trabalho resumem-se a:
O comprometimento da equipe durante a realização do estudo de caso deixou a
desejar, especialmente nos dois primeiros ciclos de desenvolvimento. Foram
necessárias contínuas intervenções dos consultores de usabilidade, com o
intuito de relembrar a equipe das atividades e da importância de realização das
mesmas. Após os primeiros resultados obtidos, o comprometimento melhorou.
A realização das atividades de análise de aderência, existentes nos capítulos
três e quatro foi onerosa, devido à quantidade de práticas existentes nos
modelos do P-CMM e da ISO TR 18529. Porém, os resultados obtidos
144
auxiliaram a identificar os cenários de integração dos conhecimentos
estudados e embasar o conteúdo teórico deste trabalho.
6.4. Trabalhos Futuros
Disseminar a estratégia deste trabalho aos demais projetos da organização,
assim como em outras organizações que possuam foco no desenvolvimento ágil. Dessa
forma, novas experiências e resultados serão obtidos, contribuindo para uma melhoria
deste trabalho.
Dentre as atividades a serem realizadas em novos estudos de caso, destaca-se a
execução coleta de métricas (já especificadas na estratégia), como forma de quantificar
os resultados do plano de melhoria de processo.
Investigar alternativas de realizar uma avaliação mais aprofundada do
comprometimento da equipe perante as atividades previstas no plano de melhoria,
preferencialmente definindo métricas relacionadas a estas atividades;
Investigar com mais detalhes a aplicabilidade do People-CMM dentro da
estratégia e seus benefícios.
Coletar mais dados sobre a satisfação da organização durante a execução do
plano de melhoria e sobre a satisfação do produto por parte dos usuários.
Desenvolvimento de uma ferramenta com o intuito de dar suporte à estratégia,
contribuindo para uma maior agilidade dos consultores e gestores de usabilidade
envolvidos com a execução das atividades, técnicas e artefatos previstos.
REFERÊNCIAS
ABRAHAMSSON, P.; SALO, O.; RONKAINEN, J.; WARSTA, J.; Agile software
development methods. Review and analysis. ESPOO 2002. VTT Publications 478. 2007.
AMBLER, S.A.; Agile Modeling Throughout the XP Lifecycle. White Paper. Disponível em:
<http://www.agilemodeling.com/essays/agileModelingXPLifecycle.htm>. Acesso em: 08
Fev. 2008.
BANKSTON, A.; Usability and User Interface Design in XP. 2003. Disponível em:
<http://ccpace.com/Resources/documents/UsabilityinXP.pdf>. Acesso em 05 Fev. 2008
BARANAUSKAS, Maria C.; ROCHA, Heloísa V.; Design e Avaliação de Interfaces
Humano-Computador, NIED – Núcleo de Informática Aplicada à Educação, UNICAMP –
Universidade Estadual de Campinas, 2003.
BARBOSA, D.F., FURTADO, E.S., GOMES, A.S. Uma Proposta de Institucionalização da
Usabilidade alinhada com práticas do modelo CMMI e foco nas necessidades da
organização. In: IHC 2006 – Simpósio sobre Fatores Humanos em Sistemas
Computacionais. Natal, 2006.
BARBOSA, D.F., SCHILLING, A., FURTADO, M. E.S. ; TALES, C. Aplicação de Práticas
de Design de Interação em um Processo de Desenvolvimento Ágil. In: SIMPROS -
Simpósio Internacional de Melhoria de Processo de Software, 2007, São Paulo. Simpósio
Internacional de Melhoria de Processo de Software, 2007.
BARNUM, C. Usability Testing and Research. New York, Longman, 2002.
BECK, K.; eXtreme Programming Explained: embrace change, Addison Wesley, 2000.
BECK, K.; ANDRES, C.; Extreme Programming Explained: Embrace Change. 2nd. ed.
Boston: Addison-Wesley, 2004. 224 p., ISBN 0-321-27865-8.
BERKUN, S. Strategic Usability: Partnering Business, Engineering and Ease of Use. White
Paper. 2002. Disponível em: < http://www.scottberkun.com/essays/essay20.htm>. Acesso
em: 20. Fev. 2008.
BERNARDINO, C. B.; GOMES, A. S.; Design Interativo em Processos Ágeis de
Desenvolvimento de software. Trabalho de Conclusão de Curso. (Graduação em Ciência da
Computação) - Universidade Federal de Pernambuco. 2005.
146
BLOOMER, S., WOLFE, S. Building and Managing a Successful User Experience Team -
Interview with Christine Perfetti. 2006. Disponível em:
<www.uie.com/events/uiconf/2006/articles/bloomer_wolfe_interview/>. Acesso em: 20.
Fev. 2008.
BOEHM, B.; Get Ready for Agile Methods, with Care. IEEE Computer, 35(1): Pág. 64-69
2002.
BROCK, S. Using type in selling: Building customer relationships with the Myers-Briggs
Type Indicator (Introduction to type series). Consulting Psychologists Press, 1994.
BROWN, J. Exploring Human-Computer Interaction and Software Engineering
Methodologies for the Creation of Interactive Software. SIGCHI Bulletin, vol. 29,no. 1,
Jan. 1997, p. 32-35.
BRUNO, V., DICK, M. Making Usability Work in Industry: an Australian Practitioner
Perspective. In: Proceedings of the 2007 Conference of the Computer-Human Interaction
Special Interest Group (CHISIG) of Australia on Computer-Human Interaction: Design:
Activities, Artifacts and Environments. ACM International Conference Proceeding Series;
Vol. 251, p. 261-264. 2007.
BUCHENAU, M; SURI, J.F.; Experience prototyping. In: Proceedings of the Conference on
Designing Interactive Systems. New York City, New York, United States: ACM Press. pp.
424-33. 2000.
CALDAS, L. C. A. Otimização do Diálogo Usuários-Organizações na World Wide Web:
Estudo de caso e Avaliação Ergonômica de Usabilidade de Interfaces Humano-
Computador. Rio de Janeiro, 513 p. Dissertação de Mestrado. Pontifícia Universidade
Católica do Rio de Janeiro (PUC - Rio), 2002.
CAPLAN, S: Using Focus Groups Methodology for Ergonomic Design. Ergonomics 33, 527-
533, 1990.
CAVALCANTE, A.L.S. Sistema para aquisição de métricas de usabilidade em interfaces
baseadas na Web. Dissertação de Mestrado. Belo Horinzonte: UFMG/DCC, 2001.
CAVALCANTI, R.O.; O Toyota Way e o Desenvolvimento Ágil de Software. Trabalho de
Conclusão de Curso. Universidade Federal de Pernambuco (UFPE), 2006.
CHAMBERLAIN, S.; SHARP, L.; MAIDEN, N.: Towards a Framework for Integrating
Agile Development and User-Centred Design. XP 2006: Pág. 143-153. Disponível em: <
147
www.dcs.warwick.ac.uk/modules/cs321/presentations/two/Chamberlainetalfinal.pdf>.
Acesso em 02 Fev. 2008.
COAD, P., DELUCA, J., LEFEBVRE, E., Java Modeling in Color with UML, Prentice Hall,
1999.
COHEN, D.; LINDVALL, M.; COSTA, P.; Agile Software Development: A DACS State-of-
the-Art Report. Technical Report, 2003. Disponível em:
<http://www.thedacs.com/techs/agile/agile.pdf>. Acesso em: 18 de out. 2007.
CONSTANTINE, L.; LOCKWOOD, L. Process Agility and Software Usability Toward
Lightweight Usage-Centered Design, The Management Forum, Software Development,
Vol. 9, No. 6, June (2001).
CURTIS, B., HEFLEY, W.E., MILLER, S.A. People Capability Maturity Model. Pittsburg:
Software Engineering Institute, 2001. 735 p. Disponível em:
<http://www.sei.cmu.edu/pub/documents/01.reports/pdf/01mm001.pdf>.
DEMARCO, T; Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency.
New York: Broadway Books. 227 pag. 2001.
DEMMER, P.; BENEFIELD, G.; SCRUM Primer: An Introduction to Agile Project
Management with Scrum. Version 1.04. 2007.. Disponivel em:
<http://www.goodagile.com>. Acesso em 10 Jan. 2008.
ENDLER, A; PIMENTA, M. S. Inserindo IHC em Empresas Brasileiras de Informática:
Relato, Discussão e Lições Aprendidas. In: VI SIMPÓSIO SOBRE FATORES
HUMANOS EM SISTEMAS COMPUTACIONAIS (IHC2004), 2004, Curitiba. Anais do
VI Simpósio sobre Fatores Humanos em Sistemas Computacionais (IHC2004). Curitiba:
SBC, 2004. v. 1, p. 101-109. Disponível em: <http://www.serg.inf.puc-
rio.br/ihc/papers/IHC2004/091-100-IHC2004-.pdf> Acesso em 18. Fev. 2008.
FERREIRA, R.B.; LIMA, F.P.A; Metodologias Ágeis: Um Novo Paradigma de
Desenvolvimento de Software. In: II Workshop Um Olhar Sociotécnico sobre a Engenharia
de Software – WOSES. 2006.
FREITAS, S.F. Análise de Aspectos Motivacionais que Influenciam os Atores no Processo de
Software. 2006. 170f. Dissertação (Mestrado em Informática Aplicada) – Universidade de
Fortaleza (UNIFOR). Fortaleza, 2006.
148
GELLNER, M.; FORBIG, P.; Extreme Evaluations: Lightweight Evaluations for Software
Developer. In: IFIP Working Group 2.7/13.4, editor, INTERACT 2003 Workshop on
Bridging the Gap Between Software Engineering and Human-Computer Interaction, 2003.
GOEBEL, C. J., Extreme Programming Practices Used to Facilitate Effective Project
Management, Menlo Institute LLC, 2003. Disponível em: <http://www.stc-
sm.org/07speakersbios/Assets/XPforEffectivePM.pdf>. Acesso em: 15. Jan. 2008.
GULLIKSEN, J., BOIVIE, I., PERSSON, J., HEKTOR, A. e HERULF, L.; Making a
difference: a survey of the usability profession in Sweden. In: Proceedings of the Third
Nordic Conference Human-Computer Interaction, Finland, 2004, ACM Press, p. 207 - 215.
GUNDELSWEILER, F., MEMMEL, T. and REITERER, H. Agile Usability Engineering. In:
Allgegenwärtige Interaktion September 5-8, 2004, Paderborn, Germany.
HANSSON, C. DITTRICH, Y. & RANDAL, D. (2004) Agile Processes Enhancing User
Participation for Small Providers of Off-the-Shelf Software. In: Proceedings of XP2004,
eds J. Eckstein & H. Baumeister, 175-183, 2004.
HAWRYSH, S.; RUPRECHT, J.; Light Methodologies: It’s Like Déjà Vu All Over Again.
Cutter IT Journal 13. Pag 4-12. 2000.
HIGHSMITH, J.; COCKBURN A.; Agile Software Development: The Business of
Innovation, IEEE Computer (Setembro 2001), páginas. 120–122. 2001.
HUDSON, W.; Adopting User-Centered Design within an Agile Process: A conversation.
2003. Disponível em: <http://www.syntagm.co.uk/design/articles/ucd-xp03.pdf>. Acesso
em 05 Jan. 2008.
IACUCCI, G., KUUTTI, K. and RANTA, M., On the Move with a Magic Thing: Role
Playing in Concept Design of Mobile Services and Devices. In: DIS 2000, Brooklyn, New
York, 2000, ACM press.
IEEE Std. 1061. Software Quality Metrics Methodology, 1998.
IIVARI, N. Understanding the work of an HCI practitioner. In: Proceedings of the 4th Nordic
Conference on Human-Computer Interaction: Changing Roles, Norway, 2006, ACM
International Conference Proceeding Series, p. 185 - 194.
ISO 13407. Human-centred design processes for interactive systems. International Standards
Organization, 1999.
149
ISO TR 18529. Ergonomics of human system interaction – human centered lifecycle process
descriptions. International Standards Organization, 2000.
ISO 9126. Software Product Evaluation: Quality Characteristics and Guidelines for their Use.
1991.
ISO 9241-11. Guidance on Usability. Ergonomic Requirements for Office Work with Visual
Display Terminals (VDT). 1996.
JEFFRIES, R.; ANDERSON, A.; HENDRICKSON, C. Extreme Programming Installed.
Boston: Addison-Wesley, 2001. 265 p., ISBN 201-70842-6
JI, Y.G.; YUN, M.H. Enhancing the Minority Discipline in the IT Industry: A Survey of
Usability and User-Centered Design Practice. International Journal of Human-Computer
Interaction, 20 (2). 117-134. 2003.
JOKELA, T. Making User-Centred Design Common Sense: Striving for An Unambiguous
and Communicative UCD Process Model. In: NordiCHI 2002. 2002. Aarhus, Denmark.
JOKELA, T.; ABRAHAMSSON, P.; Usability Assessment of an Extreme Programming
project: Close Co-Operation with the Customer does not equal to Good Usability. In 5th
International Conference, PROFES 2004, Kansai Science City, Japan, pp. 393–407.
Springer Berlin / Heidelberg. 2001.
JOKELA, T. Characterizations, Requirements, and Activities of User-Centered Design—the
KESSU 2.2 Model. Human-Computer Interaction Series: Maturing Usability - Quality in
Software, Interaction and Value. ISBN: 978-1-84628-940-8, p. 168-195. Springer, 2008.
JOSKO, J.M.B.; CORTES, M.L.; P-CMM e Outros Modelos na Gestão de Pessoas. In: VII
Simpósio Internacional de Melhoria de Processos (SIMPROS), 2005, São Paulo – SP.
KRUG, S. Não me Faça Pensar – Uma Abordagem de Bom Senso à Usabilidade na Web. Ed.
Alta Books. 2ª edição, 2006.
KULPA, M. K.; JOHNSON, K. A. Interpreting the CMMI: A Process Improvement
Approach. Auerbach Publications, 2003.
LEE, J. C.; McCRICKARD, D.S.: Towards Extreme(ly) Usable Software: Exploring Tensions
Between Usability and Agile Software Development. In: Proceedings of the 2007
Conference on Agile Software Development (Agile 2007). Washington DC, August 2007,
pp. 59-70.
150
LUNDMARK, M., TORESSON, J. Assessing Usability Maturity - Effective Strategies for
Enhancing Usability in Projects. Master Thesis in HCI / Interaction Design. Chalmers
Department of Computer Science, Gothenburg, Suécia, 2007. Disponível em: <
http://www.toresson.nu/files/Mattias & Johan - Master Thesis Short.pdf>. Acesso em: 10.
Fev. 2008.
Manifesto for Agile Software Development, 2001. Disponível em:
<http://www.agilemanifesto.org>. Acesso em 14 jan. 2008.
MARÇAL, A. S. C.; FREITAS, B. C. C.; SOARES, F. S. F.; MACIEL, T. M. M.;
BELCHIOR, A. D. Estendendo o SCRUM segundo as Áreas de Processo de
Gerenciamento de Projetos do CMMI. CLEI Electronic Journal, 2007.
MAYHEW, D.J., BIAS, R.G. Cost-Justifying Usability: An Update for the Internet Age. 2nd
ed. San Francisco, CA: Morgan Kaufmann Publishers. 2005.
MELO, A. M.; BARANAUSKAS, M. C. C. Design para Inclusão: Desafios e Proposta. In:
VII Simpósio sobre Fatores Humanos em Sistemas Computacionais, 2006, Natal. Anais do
Simpósio sobre Fatores Humanos em Sistemas Computacionais, 2006. p. 11-20.
MEMMEL, T.; GUNDELSWEILER, F.; REITERER, H.: Agile Human-Centered Software
Engineering. In: Proceedings of HCI 2007 - The 21st British HCI Group Annual
Conference University of Lancaster, UK. 2007. Disponível em: <
http://www.bcs.org/upload/pdf/ewic_hc07_lppaper17.pdf>. Acesso em 01 Fev. 2008.
MILLEN, D. Rapid Ethnography: Time Deepening Strategies for HCI Field Research.
Proceedings of the ACM 2000 Conference for Designing Interactive Systems: Processes,
Practices, Methods, and Techniques. New York, NY: ACM Press, 2000, pp. 280-286.
NADEL, J. The Institutionalization of Usability. Human Factors International, November 3rd,
2005. Disponível em: <http://www.nycupa.org/docs/wud-nyc-2005-nadel.ppt>. Acesso
em: 25 Fev. 2008.
NARGLER, R. Extreme Programming in Perl. E-Book. Disponível em: <
http://www.extremeperl.org/f/extremeperl.pdf>. 2005. Acesso em 20. Fev. 2008.
NELSON, E.; eXtreme Programming versus Interaction Design. An interview with Alan
Cooper and Kent Beck, Fawcette Technical Publications, January 15, 2002.
NERUR, S.; RADHAKANTA, M.; MANGALARAJ, G.; Challenges of Migrating to Agile
Methodologies. Communications of the ACM ,Volume 48, Número 5, Pag. 72-78. 2005.
151
NIELSEN, J.; Usability Engineering. Morgan Kaufmann, San Diego, 1993.
NIELSEN, J.; Heuristic Evaluation. In: Usability Inspection Methods. John Wiley, New
York, 1994.
NIELSEN, J. Enterprise Usability. J. Nielsen's Alertbox. 2003. Disponível em:
<http://useit.com/alertbox/enterprise.html>. Acesso em: 15. Fev. 2008.
NIELSEN,J.;.Evangelizing Usability: Change Your Strategy at the Halfway Point, Jakob
Nielsen's Alertbox. 2005. Disponível em <http://www.useit.com/alertbox/enterprise.html>.
Acesso em 05.out.2005.
NIELSEN, J.; NORMAN, D. Usability Return on Investment Report. Nielsen/Norman Group,
2003. Disponível em < http://www.nngroup.com/reports/roi/>. Acesso em 01.nov.2007.
OLSEN, H. Competitive Usability: How Usability Will Be the Key Differentiator of
Tomorrow’s Internet. The Interaction Designer‟s Coffee Break, Issue 01 – Q1 2002.
Disponível em: < http://www.guuui.com/issues/01_02.php> Acesso em: 01. Mar. 2008.
PARUSH, A. Toward a Common Ground: Practice and Research in HCI. Interactions, 2006,
p. 61-62.
PATTON, J.; Hitting the Target: Adding Interaction Design to Agile Software Development.
In: OOPSLA 2002 Practitioners Reports. ACM Press. 2002. Disponível em: <http://
oopsla.acm.org/extra/pracreports/HittingTheTargeReport.pdf>. Acesso em 01 Fev. 2008.
PORTER, J. Linking Usability Goals to Business Goals. User Interface Engineering
Newsletter 2006. Disponível em: <http://www.uie.com/brainsparks/2006/10/09/ui11-
linking-usability-goals-to-business-goals/>. Acesso em: 28 Fev.2008.
PRUITT, J.; GRUDIN, J. Personas: Practice and Theory, Proc. of the Conference on
Designing for User Experiences, ACM Press, p.1-15. 2003.
RITTENBRUCH, M., MCEWAN, G., WARD, N., MANSFELD, T., BARTENSTEIN, D.
Extreme Participation - Moving Extreme Programming Towards Participatory Design. In:
Binder, T., Gregory, J. and Wagner, I. (eds.) PDC '02, Proceedings of the Participatory
Design Conference. Malm, Sweden, June, 23-25, 2002, pp.29-41. CPSR. ISBN 0-
9667818-2-1
RUSK, J. Comparison of Agile to Traditional Development. 2006. Disponível em:
<http://www.agilekiwi.com/comparison.htm>. Acesso em 22 Jan. 2008.
152
SAURO, J., KINDLUND, E. A Method to Standardize Usability Metrics Into a Single Score.
In: Proceedings of the Conference in Human Factors in Computing Systems (CHI 2005)
Portland,OR (p 401 – 409), 2005.
SCHAFFER, E. Institutionalization of Usability, Addison-Wesley Professional, 2004.
SCHWABER, K.; BEEDLE, M.; Agile Software Development with SCRUM, Prentice Hall,
2002.
SEFFAH, A.; METZKER, E. The Obstacles and Myths of Usability and Software
Engineering. Communications of the ACM, Volume 47, Issue 12 (December 2004), p.71-
76. 2004.
SIGCHI. Learn About HCI: Definition of HCI. Special Interest Group on Computer-Human
Interaction. 2006. Disponível em: <http://sigchi.org/cdg/cdg2.html> Acesso em: 15. Fev.
2008.
SIMON, M. Storyboards: Motion in Art. 2nd Ed., Focal Press, 2000.
SHARP, H., BIDDLE, R., GRAY, P., MILLER, L., and PATTON, J.; Agile development:
opportunity or fad?, In: Extended Abstracts CHI ‟06, 2006, 32-35.
SHNEIDERMAN, B. Designing the User Interface: Strategies for Effective Human-
Computer Interaction. Estados Unidos: Addison-Wesley, 1998.
SOARES, M. S: Comparação entre Metodologias Ágeis e Tradicionais para o
Desenvolvimento de Software. 2004. Disponível em:
<http://www.dcc.ufla.br/infocomp/artigos/v3.2/art02.pdf>. Acesso em: 30 de dez. 2007.
SOMMERVILLE, I. Engenharia de Software, 6ª edição, Editora Addison-Wesley, São Paulo,
ISBN: 85-88639-07-6, 2003.
SOUSA, K.; FURTADO, E.; MENDONCA, H. UPi - A Software Development Process
Aiming at Usability, Productivity and Integration. In: CLIHC 2005 - Congresso Latino-
Americano de IHC, 2005, México. 2005
SOUZA, R., MANNING, H., SONDEREGGER, P., ROSHAN, S. Get ROI From Design.
(Forrester Research Report). Cambridge, MA: Forrester Research Inc., June 2001.
SY, D; Adapting Usability Investigations for Agile User-centered Design. Journal of Usability
Studies. Usability Professionals Association(UPA). Vol. 2, Issue 3, May 2007, pp. 112-
132. 2007.
153
TELES, V. M. Um Estudo de Caso da Adoção das Práticas e Valores do Extreme
Programming. Rio de Janeiro, 2005. Dissertação (Mestrado em Informática) - Núcleo de
Computação Eletrônica, Universidade Federal do Rio de Janeiro.
TRAVIS, D. Selling Usability to Your Manager. White Paper. 2006. Disponível em:
<http://www.userfocus.co.uk/articles/sellingusability.html>. Acesso em: 20. Mar. 2008.
VASCONCELOS, C.; GARCIA, F.; TURNELL, M.: XPU – Um Modelo para o
Desenvolvimento de Sistemas Centrado no Usuário, Dissertação de Mestrado, Campina
Grande – PB, Brasil. 2004. Disponível em: <http://copin.ufcg.edu.br/twiki-
public/pub/COPIN/DissertacoesMestrado/Dissertacao_CesarRochaVasconcelos.doc>.
Acesso em: 5 de Fev. 2008.
APÊNDICES
APÊNDICE A - Perfis de Gerentes e Estratégias de
Convencimento
155
PERFIS DE GERENTES E ESTRATÉGIAS DE
CONVENCIMENTO
Passo 1 - Reúna os principais benefícios com foco na usabilidade
Aumento das vendas e orçamento - (i) o envolvimento cedo e contínuo do
usuário ajuda a reduzir custos de desenvolvimento; (ii) Usuários costumam
utilizar todas as funcionalidades do sistema, não apenas um conjunto delas e
(iii) um produto fácil de usar implica em diminuição de gastos com
treinamentos e suporte técnico.
Fidelização de clientes – (i) os clientes já valorizam a qualidade do produto
desde a primeira entrega; (ii) clientes fiéis tornam-se pré-dispostos a aplicar
recursos financeiros com maior facilidade, pois sentem-se seguros do retorno;
(iii) clientes fiéis tornam-se imunes a demais produtos existentes no mercado,
que competem com o produto desenvolvido.
Valorização do produto – (i) com um produto usável, os usuários aprendem a
utilizar o sistema mais rapidamente; (ii) melhoria de usabilidade torna-se uma
vantagem competitiva; (iii) uma maior qualidade no serviço prestado
condiciona uma maior satisfação do usuário; e (iv) um produto usável
condiciona um aumento da produtividade do usuário.
Melhoria de processo – (i) uma menor carga de retrabalho será necessária
para atingir os requisitos estabelecidos com o usuário e (ii) um processo com
usabilidade pode auxiliar a organização sincronizar as expectativas e
necessidades de seus clientes / usuários com seus objetivos de negócio.
Passo 2 - Personifique os gerentes da organização:
Como o gerente prefere receber informações?
o Caso ele prefira lidar com fatos, práticas ou com o conhecimento que
ele possua ou obtenha, então a preferência deste gerente é por
consenso (denotado pela letra „S‟);
156
o Caso a preferência dele seja lidar com idéias, descobrir fatores incertos,
gerar novas possibilidades ou se antecipar a situações não óbvias,
então sua preferência é por intuição (ou “N”).
Como o gerente prefere tomar decisões?
o Caso ele prefira decidir com base em um objetivo lógico, utilizando-se
de uma estratégia analítica, então a preferência é por reflexão (ou „T‟);
o Caso ele prefira tomar suas decisões baseando-se em crenças ou valores
pessoais, além de refletir sobre o impacto de suas decisões sobre seus
usuários, produtos e a organização, então sua preferência é por
sensibilização (ou „F‟).
Passo 3 - Adeqüe os argumentos de acordo com o perfil de gerente
Gerente “ST” (consenso e reflexão)
o Expor os fatos – gerentes desse tipo gostam de ouvir sobre detalhes e
fatos, sendo detalhistas com relação ao planejamento definido para
institucionalizar a usabilidade, questionando o conhecimento do
profissional responsável sobre fatos e detalhes do projeto.
o Ser prático, mas detalhista – sugere-se mostrar todos os passos que
serão realizados, enfatizando a eficiência das práticas a serem
aplicadas. Além disso, expor os custos e benefícios do projeto,
mantendo sempre a objetividade.
Gerente “SF” (consenso e sensibilização)
o Personalizar os fatos – gerentes com essa personalidade desejam
conhecer como a usabilidade irá afetar os demais membros da
organização.
o Ressaltar os benefícios da usabilidade – sensibilizar o gerente sobre os
benefícios a serem obtidos tanto pelos clientes e/ou usuários dos
produtos desenvolvidos, como pela equipe que desenvolverá os
produtos.
157
Gerente “NF” (intuição e sensibilização)
o Personalizar as possibilidades – gerentes com foco na intuição e
sensibilização são os menos interessados em detalhes, concentrando
suas atenções no impacto das ações das atividades de usabilidade sobre
a rotina das pessoas em geral.
o Estimular idéias - pelo seu foco no idealismo, gerentes deste tipo
costumam não ser suscetíveis a análises de cunho financeiro ou
estatístico. Deve-se esperar e estimular novas idéias vindas dos
mesmos.
o Estabelecer um cenário – ilustrar um cenário ideal, onde o gerente
possa visualizar as mudanças que ocorreriam como conseqüência da
usabilidade: satisfação das pessoas, qualidade dos produtos, dentre
outros.
Gerente “NT” (intuição e reflexão)
o Expor as possibilidades – assim como o perfil anterior, gerentes deste
tipo deixam de lado os detalhes e concentram-se na idéia principal.
Entretanto, estes dão maior atenção aos critérios lógicos envolvidos,
como prós e contras das atividades a serem realizadas.
o Ser dinâmico e específico – descrever, sem muitos detalhes, o processo
e de que forma as atividades de usabilidade serão executadas dentro
dos projetos geridos por este gerente.
o Envolver o gerente na solução – definir os prós e contras envolvidos
nas iniciativas de usabilidade, envolvendo o gerente na busca pela
solução dos problemas identificados.
158
APÊNDICE B - Descrição dos Processos da ISO TR 18529:2000
159
ISO TR 18529 - Design centrado no humano – Descrição dos Processos
O design centrado no usuário é obtido por meio do desempenho de processos que se dirigem à
consideração de usuário finais e outros "stakeholders" na especificação, desenvolvimento e
operação de um sistema. Esses processos sempre estão relacionados com todo o sistema em
desenvolvimento, não apenas os detalhes do software. Os processos abordam atividades
centradas no usuário durante toda a vida de um sistema.
Garantir conteúdo HCD na estratégia do sistema. (HCD.1)
O objetivo do processo Garantir conteúdo HCD na estratégia do Sistema é estabelecer e
manter um foco nas necessidades dos stakeholders e usuários em cada parte da organização
que lida com os mercados, conceito, desenvolvimento e suporte do sistema. Esse processo
compreende as práticas base seguintes.
Representar o usuário final (HCD.1.1)
Agir como defensor do usuário final na empresa de desenvolvimento do sistema e equipe de
desenvolvimento.
NOTA – O defensor do usuário final relembra a equipe na empresa de desenvolvimento de sistemas que o
sistema tem a intenção de ser usado por pessoas reais e tem que alcançar qualidade no uso. Esse papel inclui
liderar abordagens centradas em humanos, providenciando o envolvimento do usuário final nos estudos
conceituais, investigação e disseminação das questões de contexto de uso.
Coletar inteligência de Mercado (HCD.1.2)
Execute uma pesquisa preventiva em grupos de usuário em potencial a fim de identificar
necessidades por vir de sistemas e novos usuários ou organizações de usuário. Identifique
contextos de uso previstos de futuros sistemas. Crie procedimentos para elicitar as entradas
dos usuários em relação a sistemas futuros em seus contextos previstos.
Definir e planejar uma estratégia de sistema. (HCD.1.3)
Apresente a informação de Mercado como uma visão. (por exemplo, para a aprovação da
gerencia sênior). Operacionalize uma estratégia de visão para implementação. Estabeleça
contagem de custos por ciclo de vidas para os sistemas a fim de assessorar o custo de uma
abordagem HCD.
Coletar o feedback de Mercado. (HCD.1.4)
Execute pesquisas para refinar e consolidar estratégias de sistema, baseadas em feedbacks de
usuários e não usuários no nicho de Mercado do sistema.
Analisar tendências nos usuários (HCD.1.5)
Procure por mudanças em: usuários (por ex. suas habilidades e treinamentos para
organizações de usuários, assim como suas necessidades e desejos para produtos de
consumo), tarefas ( por ex. mudanças no tipo de trabalho ou volume do mesmo), contexto
(por ex. mudanças nos ambientes de trabalho e moradia, novas tecnologias, morais sociais e
políticas e expectativas). Analise essas informações para prever necessidade futuras.
160
Planeje e gerencie o processo de HCD (HCD.2)
O objetivo do processo de Planejar e gerenciar o design centrado no usuário é de especificar
como as atividades centradas nos usuários se encaixam no processo do ciclo de vida do
sistema e na empresa. Esse processo compreende as seguintes práticas básicas:\
Consultar os stakeholders (HCD.2.1)
Estabeleça estruturas, mecanismos e processos para garantir que os stakeholders relevantes
estejam efetivamente envolvidos e foram consultados sobre cada aspecto significante do
desenvolvimento e implementação do sistema.
Identificar e planejar o envolvimento do usuário (HCD.2.2)
Decida qual a maneira mais eficiente de elicitar a entrada do usuário em cada fase do projeto,
tirando a melhor proveito das boas práticas estabelecidas no trabalho em equipe e
envolvimento do usuário apropriado.
Selecionar métodos e técnicas centrados no usuário. (HCD.2.3)
Decida quais métodos serão incluídos e como eles vão se relacionar no processo de
desenvolvimento. Defina como será a interface disso com a metodologia do ciclo de vida
usada no desenvolvimento do sistema.
Garanta uma abordagem centrada no usuário dentro da equipe de projeto. (HCD.2.4)
Estabeleça uma cultura multidisciplinar na equipe de projeto Mantenha o foco do pessoal
numa abordagem centrada no usuário. Identifique as habilidades especialistas requisitadas e
planeje como providenciá-las.
Planejar atividades de design centrado no humano (HCD.2.5)
Desenvolva um plano especificando como as atividades centradas no usuário integram o
processo de desenvolvimento do sistema como um todo.
Gerenciar atividades centradas no usuário (HCD.2.6)
Tenha controle especifico das questões relacionadas aos usuários no gerenciamento de
projetos e departamentos de desenvolvimento. Garanta que o processo de desenvolvimento do
sistema leva em consideração as considerações dos usuários. Leve em consideração as
questões de usuário e stakeholders nas atividades de suporte.
Difundir abordagem centrada no humano. (HCD.2.7)
Promover uma abordagem centrada no usuário dentro da empresa. Estabelecer e comunicar
uma política para a centralização no usuário dentro da empresa.
Forneça suporte para o design centrado no humano (HCD.2.8)
Inclua elementos centrados no usuário nos procedimentos de suporte (por ex. Garantia de
qualidade, controle de mudanças, gerenciamentos de processos e métodos, gerenciamento de
recursos). Garanta que isso tudo seja realizado como uma parte integral do gerenciamento de
infra-estrutura da empresa.
161
Especifique os requisitos dos stakeholders e da organização. (HCD.3)
O objetivo do processo Especificar os requisitos dos stakeholders e da organização é
estabelecer os requisitos organizacionais e de outras partes interessadas do sistema. Esse
processo toma plena responsabilidade pelas necessidades, competências e ambiente de
trabalho de cada stakeholder relevante no sistema. Esse processo compreende as seguintes
praticas bases.
Esclarecer e documentar os objetivos do sistema (HCD.3.1)
Descreva os objetivos que o usuário ou sua organização quer conseguir através do uso do
sistema.
Defina stakeholders (HCD.3.2)
Identifique e analise os papeis de cada grupo de stakeholders possivelmente afetados pelo
sistema. Avalie a importância do sistema para cada grupo de stakeholders.
Avaliar o risco para os stakeholders (HCD.3.3)
Revise os riscos de segurança, saúde e bem estar para os stakeholders do sistema. Relacione-
os na avaliação geral de riscos do sistema.
Definir o sistema (HCD.3.4)
Ajuste e acorde as funções requisitadas e desempenho do sistema em termos do total de
experiência dos stakeholders relevantes e/ou organização usuária com o sistema (por ex.
Objetivos de adequação, aceitação e eficiência para o usuário final). A experiência completa
abrange cada aspecto da relação de um stakeholder relevante com o sistema, desde sua
comissão à sua “descomissão”.
Gerar os requisitos do stakeholder e da organização. (HCD.3.5)
Desenvolva uma indicação explícita dos requisitos dos stakeholders e da organização para o
sistema.
NOTA - A geração dos requisitos é um processo interativo e muitas vezes iterativo.
NOTA - Requisitos podem ser classificados em ordem de importância.
Definir os objetivos de qualidade no uso. (HCD.3.6)
Gere e acorde critérios mensuráveis para a qualidade de uso requerida no sistemas.
Entenda e especifique o contexto de uso. (HCD.4)
O propósito do processo Entenda de especifique o contexto de uso é identificar, esclarecer e
registrar as características dos stakeholders, suas tarefas e o ambiente organizacional e físico
no qual o sistema irá operar. Esse processo compreende as seguintes práticas base.
Identificar e documentar as tarefas do usuário. (HCD.4.1)
Descreva as atividades as quais os usuários executam para conseguir as metas do sistema.
Identificar e documentar atributos significantes do usuário (HCD.4.2)
Descreva as características relevantes dos usuários finais do sistema. Isso irá acrescentar
conhecimento, linguagem, capacidades físicas, níveis de experiência, etc.
162
Identificar e documentar ambientes organizacionais. (HCD.4.3)
Descreva o meio social e organizacional, estrutura de gerenciamento e práticas relevantes.
Identificar e documentar o ambiente técnico. (HCD.4.4)
Descreva as características relevantes de qualquer equipamento sendo usado.
Identificar e documentar o ambiente físico. (HCD.4.5)
Descreva a locação, equipamentos no ambiente de trabalho e condições ambientes.
Desenvolva soluções de design. (HCD.5)
O propósito do processo Desenvolva soluções de design é criar soluções de design em
potencial por meio de desenhos em cima de práticas avançadas estabelecidas, a experiência e
conhecimento dos participantes e os resultados da análise do contexto de uso. Esse processo
compreende as seguintes práticas base.
Alocar funções (HCD.5.1)
Analise o contexto de uso e as funções e desempenho requeridos pelo sistema, para distribuir
as funções entre humanos, máquinas e componentes organizacionais do sistema mais aptos a
cumprir cada função.
Produzir um modelo de tarefas composto. (HCD.5.2)
Desenvolva um modelo viável das novas tarefas do usuário a partir de conhecimento prévio
da melhor prática, requisitos, contexto de uso, alocação de funções e restrições de design para
o sistema.
Explorar o design de sistema. (HCD.5.3)
Gere e analise o leque de opções de design para cada aspecto do sistema relacionado a seu uso
e seus efeitos nos stakeholders.
Usar conhecimento existente para desenvolver soluções de design. (HCD.5.4)
Aplique informações relevantes de ciência humana no design do sistema. Inclua requisitos
organizacionais e do stakeholder, contexto de uso, padrões internacionais, requisitos
legislativos, patentes existentes, boas práticas, guias de estilo e padrões de projeto, etc.. no
design.
Especificar o sistema (HCD.5.5)
Produza um design para os componentes relacionados a usuário do sistema. Mude o design de
acordo com o feedback das avaliações.
Desenvolver protótipos (HCD.5.6)
Torne a solução de design mais concreta usando simulações, modelos, etc. Desenvolva uma
simulação ou implementação para avaliação dos aspectos chave do sistema, no intuito de
testar com usuários ou representantes de usuários.
Desenvolver o treinamento do usuário (HCD.5.7)
Identifique, especifique e produza o treinamento requisitado para permitir stakeholder
relevantes de realizar tarefas efetivamente usando o novo sistema.
163
Aborde ou inclua qualquer mudança proposta nos processos do negócio, design de trabalho e
tarefas.
Desenvolver suporte ao usuário. (HCD.5.8)
Identifique, especifique e produza serviços de suporte ao usuário para o sistema. Leve em
consideração as mudanças propostas nos processos de negócio e design de trabalho.
Avalie designs frente os requisitos (HCD.6)
O objetivo do processo Avalie designs frente os requisitos é coletar feedbacks sobre o design
em desenvolvimento. Esse feedback será coletado de usuários finais e outras fontes
representativas. No caso de avaliação para identificar melhorias no sistema (avaliação
formativa) uma implementação bem sucedida do processo irá refletir:
- problemas potenciais com melhoria em: tecnologia, material de apoio, ambiente
organizacional, físico e treinamento.
- qual opção de design melhor se encaixa nos requisitos de funcionalidades e dos
usuários.
- feedback e requisitos aprofundados do usuário
No caso de avaliação para avaliar se os objetivos foram alcançados, uma implementação bem
sucedida irá demonstrar:
- que um design particular preenche os requisitos centrados no humano.
- conformidade nos requisitos internacionais, nacionais e/ou estatais.
Esse processo compreende as seguintes práticas base.
Especificar e validar o contexto de avaliação. (HCD.6.1)
Descreva e verifique as condições sob as quais um sistema é testado ou avaliado. Descreva a
relação, e especialmente discrepâncias, entre o contexto de avaliação e o contexto de uso.
Avaliar protótipos a fim de definir os requisitos do sistema. (HCD.6.2)
Nivele por desempenho sistemas apropriados utilizando critérios relevantes. Teste a
usabilidade de sistemas alternativos/concorrentes e /ou conceitos de sistema. Use protótipos
para estimular entrada de stakeholders nos requisitos do sistema. Teste a estabilidade dos
requisitos..
Avaliar protótipos a fim de melhorar o design (HCD.6.3)
Colete informações do usuário sobre a qualidade de uso no sistema em desenvolvimento.
Apresente os resultados para a equipe de design no formato mais apropriado.
Avaliar o sistema a fim de checar que os requisitos do sistema foram implementados
corretamente (HCD.6.4)
Teste o sistema em desenvolvimento ou final para garantir que preencheu os requisitos do
usuário, as tarefas e o ambiente, como definido na sua especificação. (veja também HCD 3.5 e
3.6)
164
Avaliar o sistema a fim de verificar que as práticas requisitadas foram seguidas.
(HCD.6.5)
Verifique no sistema por aderências a conhecimentos de ciência humana aplicáveis, guias de
estilo, padrões, regras, e legislação.
Avaliar o sistema em uso a fim de garantir que ele continua a satisfazer as necessidades
do usuário e da organização. (HCD.6.6)
Verifique no sistema em uso se existem mudanças nas necessidades do usuário, stakeholders e
usabilidade e garanta que ele continue a satisfazer essas necessidades. (veja também HCD 3.5
e 3.6)
Introduza e opere o sistema. (HCD.7)
O objetivo do processo Introduza e opere o sistema é estabelecer os aspectos humanos do
suporte e implementação do sistema. Como resultado de uma implementação bem sucedida
desse processo:
Controle de mudanças (HCD.7.1)
Facilite, supervisione e garanta aspectos de HCD na implementação do sistema.
Determinar o impacto na organização e nos stakeholders. (HCD.7.2)
Avalie o impacto humano e organizacional do sistema sendo introduzido.
Design local e customizado (HCD.7.3)
Forneça suporte para customização do sistema para que satisfaça necessidades culturais locais
ou necessidades operacionais. Forneça suporte para customização e configuração para
satisfazer as necessidades de usuários específicos. Forneça detalhes de customização para o
gerenciamento de configuração.
Realizar o treinamento de usuário (HCD.7.4)
Disponibilize treinamentos e workshops para usuários para satisfazer necessidades de
treinamento identificadas e facilitar a transição para novos designs de trabalho e novos
trabalhos em equipe.
Apoiar os usuários em atividades planejadas. (HCD.7.5)
Mantenha contato com os usuários e a organização cliente através da definição,
desenvolvimento e introdução de um sistema.
Garantir a conformidade com a ergonomia do ambiente de trabalho. (HCD.7.6)
Questionários de ambientes de trabalho, usuários e programas de treinamento para garantir
que o software, hardware e ambiente de trabalho satisfaçam os requisitos de ergonomia (ver
também HCD.6.5).
165
APÊNDICE C - Questionário Investigativo e Resultados
Encontrados
166
TERMO DE CONSENTIMENTO
Questionário disponível em: http://luqs.unifor.br/pesquisaUsabilidade/index.php?sid=6
Investigação IHC - FORTES
Este questionário objetiva investigar como a organização trata o termo IHC e sua implicação nas
práticas de desenvolvimento atuais.
Bem vindo!
Você foi convidado pelo LUQS - Laboratório de estudo do Uso e da Qualidade de Sistemas,
pertencente à Universidade de Fortaleza (UNIFOR), para participar do processo de
"Institucionalização da Usabilidade", como parte da dissertação de mestrado de autoria de David
Falcão Barbosa. Desta forma, solicitamos seu consentimento para a realização desta pesquisa. É
importante ressaltar que:
1) As informações contidas neste questionário destinam-se estritamente às atividades de
pesquisa e desenvolvimento.
2) A equipe do LUQS tem o compromisso de divulgar o resultado de suas pesquisas em foros
científicos. A divulgação destes resultados pauta-se no respeito à privacidade dos usuários, e o
anonimato dos mesmos é preservado em quaisquer documentos que forem posteriormente
elaborados. Desta forma, seus dados estarão sempre anônimos.
3) A realização da pesquisa pode ser interrompida e reiniciada a qualquer momento, segundo a
disponibilidade do participante. Neste caso, a equipe se compromete a descartar a pesquisa para
fins de avaliação, caso o questionário não seja finalizado.
Observação: Este questionário é composto de 20 questões, todas obrigatórias. Os resultados
serão consolidados e apresentados a todos posteriormente.
167
PERGUNTAS DO QUESTIONÁRIO
Investigação IHC - FORTES
Este questionário objetiva investigar como a organização trata o termo IHC e sua implicação nas
práticas de desenvolvimento atuais.
Dados pessoais e profissionais
Nesta seção serão questionados alguns dados pessoais e profissionais do entrevistado. Vale ressaltar
que informações pessoais (tais como nome da organização) serão omitidas dos resultados a serem
divulgados.
1: * Qual o seu sexo?
Feminino
Masculino
2: * Qual sua faixa etária?
18 - 24
25 - 30
31 - 40
41 - 50
51 em diante
3: * Qual sua formação acadêmica?
Ensino Técnico
Graduação Incompleta
Graduação Completa
Pós-Graduação (Especialização)
Pós-Graduação (Mestrado)
Pós-Graduação (Doutorado)
Pós-Doutorado
4: * Que função você desempenha em sua organização? (Escolha mais de uma, caso você
desempenha mais de uma destas funções).
Designer
Programador
Analista de Requisitos
Analista de Qualidade
Líder de Projeto
Gerente de Projetos
168
Analista de Sistemas
Analista de Testes
Outro:
Investigação IHC - FORTES
Este questionário objetiva investigar como a organização trata o termo IHC e sua implicação nas
práticas de desenvolvimento atuais.
Questões sobre IHC (Interação Humano-Computador) - parte 1/2
5: * A organização possui um processo de desenvolvimento de software? (Caso a resposta
seja SIM, favor especificar em qual modelo ele se baseia, tais como RUP, XP, etc).
Favor escolher uma das seguintes:
Favor escrever aqui seu comentário:
Sim
Não
6: * Como a organização considera as informações coletadas sobre o usuário no processo
de desenvolvimento?
Documentos são gerados especificando o perfil dos usuários, sendo estes documentos próprios para
cada projeto.
Uma biblioteca de características de usuários já existe e é utilizada em qualquer projeto.
Nenhuma consideração é feita nas interfaces, considerando o perfil do usuário
7: * Em que momentos, do processo de desenvolvimento, existe a preocupação com as
necessidades de usabilidade dos sistemas?
Planejamento do Projeto
Elicitação de Requisitos
Análise/Projeto do sistema
Implementação
169
Testes do Sistema
Pós-Entrega do software
Nenhum
Outro:
8: * Como a organização leva em consideração a participação do usuário no processo de
desenvolvimento?
O usuário participa de pelo menos uma reunião de levantamento de suas características e experiências.
O usuário acompanha continuamente o desenvolvimento do sistema
O usuário é convocado a participar apenas quando algum problema ocorre durante o desenvolvimento.
Não existe nada formalizado sobre o envolvimento do usuário.
9: * A organização utiliza-se de algum dos métodos abaixo para analisar as tarefas que
serão executadas no sistema?
Cenários de uso
Modelagem de caso de uso
Storyboards
Distribuição de cartões
Outro:
10: * Qual a experiência da organização com a utilização de padrões de usabilidade?
(Exemplos de padrões: Migalha de pão, Menu retrátil, Navegação sequencial, Hints, entre
outros.)
Existe uma base de padrões que é utilizada em vários projetos.
Os padrões utilizados são soluções coletadas em outros sistemas existentes, não exclusivos da organização.
A organização não faz uso de padrões, recriando suas soluções de design em todos os projetos.
11: * Quais práticas de usabilidade listadas abaixo a organização aplica ou possui algum
conhecimento?
170
ISO 13407
Análise do contexto
Entrevistas com o usuário
Modelagem de caso de uso
Observação do usuário
Brainstorming
Avaliação de sistemas existentes
Organização de cartões (Card Sorting)
Cenários de Uso
Guias de estilo
Análise de tarefas
Uso de protótipos
Avaliação Heurística
Design participativo
Storyboarding
Testes de usabilidade
Outro:
12: * É realizada alguma avaliação qualitativa com os usuários sobre a qualidade do uso
do sistema, em algum momento? (Ex: Checklist, questionários de satisfação, entrevista,
enquetes, etc) Caso a resposta seja SIM, informe qual estratégia é utilizada. Caso a
resposta seja NÃO, dê sua opinião sobre a importância desta questão.
Favor escolher uma das seguintes:
Favor escrever aqui seu comentário:
Sim
Não
Investigação IHC - FORTES
Este questionário objetiva investigar como a organização trata o termo IHC e sua implicação nas práticas
de desenvolvimento atuais.
Questões sobre IHC (Interação Humano-Computador) - parte 2/2
13: * Enumere, por ordem de prioridade, que soluções você acha que seriam as mais
importantes de serem adotadas para lidar com os fatores de IHC, em sua organização?
Clique num elemento da lista da esquerda, começando pelo
Elemento com mais alta classificação até chegar ao elemento com mais baixa classificação.
Suas Opções:
aumentar a equipe de usabilidade
treinar a equipe
melhorar a comunicação com a equipe de desenvolvimento
receber consultoria nos projetos e avaliação das interfaces
definir uma estratégia de envolvimento do usuário nos projetos
Sua
Classificação:
1:
2:
3:
171
4:
5:
Clique na tesoura à direita de cada elemento
Para eliminar a última captura da sua classificação
14: * Informe os tipos de treinamento que a organização utiliza para disseminar o
conhecimento:
Workshops
Treinamentos Práticos
Cursos Externos
Palestras
Ensino à distância
15: * A organização já recebeu algum treinamento em IHC? (Se sim, informe quais os
principais tópicos abordados.)
Favor escolher uma das seguintes:
Favor escrever aqui seu comentário:
Sim
Não
16: * Na sua opinião, qual a importância para a organização em integrar práticas de
usabilidade em seus processos organizacionais?
Muito importante (usabilidade é uma prioridade estratégica, deve ser disseminada e posteriormente
implantada na organização)
Importante (usabilidade é importante, e o conhecimento sobre ela deve ser disseminado na organização).
Razoavelmente importante (usabilidade interessa, mas para um futuro próximo)
Pouco importante (usabilidade não é considerada uma prioridade para a organização)
Não possui importância.
17: * Durante a elaboração das interfaces do sistema, que tipos de protótipos são
construídos?
172
Protótipos em papel
Protótipos visuais
Protótipos executáveis
Nenhum
18: * A organização costuma investir em atividades de pesquisa & desenvolvimento? (Caso
a resposta seja Sim, informe algumas atividades de P&D que são realizadas.)
Favor escolher uma das seguintes:
Favor escrever aqui seu comentário:
Sim
Não
Não sei informar
19: * A organização realiza estudos em que avalia o retorno de seus investimentos? (Caso a
resposta seja SIM, informe em que áreas da organização esse estudo ocorre. Exemplos:
área financeira, área de desenvolvimento, etc)
Favor escolher uma das seguintes:
Favor escrever aqui seu comentário:
Sim
Não
Não sei informar
20: * Na sua opinião, qual a capacidade da organização de realizar mudanças em sua
cultura organizacional? (Justifique rapidamente, independente da resposta.)
Favor escolher uma das seguintes:
Favor escrever aqui seu comentário:
A organização possui facilidade em realizar mudanças em sua cultura
organizacional.
A organização possui dificuldade em realizar mudanças em sua cultura
organizacional.
Não sei responder
173
RESULTADOS ENCONTRADOS
Seguem abaixo os principais resultados do questionário e as conclusões obtidas a partir das
respostas.
Analisando o gráfico acima, evidencia-se que a organização possuía consciência da
importância em se considerar necessidades de usabilidade em um projeto de software, em
especial nas fases de análise e projeto e implementação. Entretanto, não sabia como proceder
para coletar estas necessidades durante o contato com o usuário. Ressaltam-se as baixas
porcentagens obtidas nos testes do sistema e na pós-entrega do software, momentos onde a
participação do usuário é fundamental.
174
Examinando o gráfico acima, percebe-se que a organização considerava a presença
contínua do usuário durante os seus projetos de desenvolvimento de software. Este resultado
não deixou de ser surpreendente, apesar da metodologia XP, base do processo de
desenvolvimento da organização, já preconizar este comportamento.
Entretanto, após conversa com os gestores de projeto e análise do processo de
desenvolvimento, percebeu-se que o papel do usuário estava incompleto. As contribuições
obtidas dos usuários limitavam-se apenas à obtenção de requisitos funcionais e uma pequena
participação na validação das funcionalidades desenvolvidas pela organização.
Um dos objetivos com a aplicação deste questionário era medir quais práticas de
usabilidade já eram conhecidas pela equipe de desenvolvimento. O gráfico acima exibe os
resultados obtidos. Dentre as opções escolhidas, destacaram-se as práticas de Análise de
Tarefas, Organização de Cartões e Entrevistas com Usuários. As duas últimas práticas
consistiam de práticas que a organização já realizava em seu processo. A primeira prática, mais
votada, causou surpresa aos especialistas. Posteriormente, em conversa com a equipe,
descobriu-se que a mesma foi escolhida de maneira equivocada. A equipe pensou que esta
atividade era similar à coleta de requisitos funcionais.
Outro importante aspecto avaliado durante o questionário foi a receptividade com que a
organização receberia a proposta de melhoria do seu processo. Analisando os dois gráficos
abaixo, verificou-se que a grande maioria da equipe acreditava estar disposta a participar de
175
uma mudança de paradigma, além de considerar o tema importante de ser disseminado na
organização.
Observa-se que uma pequena minoria (14%) que respondeu que a organização poderia
possuir dificuldade em realizar esta mudança teceu alguns comentários interessantes:
“As mudanças são implementadas de forma razoavelmente fácil (não é nada
instantâneo, nem o poderia ser). Mas existe grande empenho por parte dos
responsáveis da implementação, tanto justificando a mudança, como
acompanhando sua evolução.”
“Dependendo da mudança podemos ter facilidade ou dificuldade. Caso a
mudança seja significativa e traga bons retornos, não encontrará barreiras. Mas a
empresa não arrisca muito, sempre com um pé atrás no que condiz a mudanças.”
“O legado de softwares é muito grande e isso acaba por ser o "motivo" que
impede que mudanças sejam realizadas de forma mais rápida e eficiente.”
176
APÊNDICE D – Plano de Melhoria de Processo
177
Plano de Melhoria de Processo em Usabilidade
Projeto: < nome do projeto real da organização onde serão aplicadas as atividade de melhoria>
Executor: <nome do executor do projeto>
Objetivos:
Externos
< lista dos objetivos externos de negócio associados ao plano de melhoria>
o Internos
<lista dos objetivos internos de negócio associados aos objetivos externos>
Usabilidade
<lista dos objetivos de usabilidade associados aos objetivos de negócio>
Atividades Previstas de Melhoria:
Ordem
Atividade*
Executor
Participantes
Tempo Previsto
<ordem de
execução>
< descrição da atividade>
<executor da
atividade>
<stakeholders
envolvidos na
atividade>
<tempo previsto
para atividade>
<ordem de
execução>
< descrição da atividade>
<executor da
atividade>
<stakeholders
envolvidos na
atividade>
<tempo previsto
para atividade>
* Tipos de Atividades:
Atividades de Capacitação
Atividades de Aplicação de Técnicas de Usabilidade
Atividades de Coleta de Métricas
Atividades de Acompanhamento do Plano
Atividades de Promoção dos Resultados
178
APÊNDICE E – Questionário Pós-Treinamento
179
QUESTIONÁRIO PÓS-TREINAMENTO
180
Livros Grátis
( http://www.livrosgratis.com.br )
Milhares de Livros para Download:
Baixar livros de Administração
Baixar livros de Agronomia
Baixar livros de Arquitetura
Baixar livros de Artes
Baixar livros de Astronomia
Baixar livros de Biologia Geral
Baixar livros de Ciência da Computação
Baixar livros de Ciência da Informação
Baixar livros de Ciência Política
Baixar livros de Ciências da Saúde
Baixar livros de Comunicação
Baixar livros do Conselho Nacional de Educação - CNE
Baixar livros de Defesa civil
Baixar livros de Direito
Baixar livros de Direitos humanos
Baixar livros de Economia
Baixar livros de Economia Doméstica
Baixar livros de Educação
Baixar livros de Educação - Trânsito
Baixar livros de Educação Física
Baixar livros de Engenharia Aeroespacial
Baixar livros de Farmácia
Baixar livros de Filosofia
Baixar livros de Física
Baixar livros de Geociências
Baixar livros de Geografia
Baixar livros de História
Baixar livros de Línguas
Baixar livros de Literatura
Baixar livros de Literatura de Cordel
Baixar livros de Literatura Infantil
Baixar livros de Matemática
Baixar livros de Medicina
Baixar livros de Medicina Veterinária
Baixar livros de Meio Ambiente
Baixar livros de Meteorologia
Baixar Monografias e TCC
Baixar livros Multidisciplinar
Baixar livros de Música
Baixar livros de Psicologia
Baixar livros de Química
Baixar livros de Saúde Coletiva
Baixar livros de Serviço Social
Baixar livros de Sociologia
Baixar livros de Teologia
Baixar livros de Trabalho
Baixar livros de Turismo