Quando recebi o convite para começar a escrever no BdB fiquei muito feliz por dois motivos. Primeiramente, sempre tive vontade de escrever sobre o meu trabalho na área de UX. Compartilhar um espaço junto com as feras que aqui escrevem só tornou esse desejo ainda mais prazeroso. Em segundo lugar, escrever uma coluna de UX num blog com colunas em testes representou (e ainda representa) um desafio interessante tanto do ponto de vista de designer como de colunista.
Antes de mais nada, gostaria de contar um pouco minha trajetória. Trabalhei um pouco mais de três anos com testes de software em projetos para a Motorola. Na época UX e outras siglas bonitas não eram tão conhecidas (pelo menos aqui no Brasil) e o grande boom tinha ocorrido justamente na área de testes. Hoje, a nova moda é falar de arquitetura de informação, usabilidade, acessibilidade e mais um monte de “ades” que permeiam os blogs, revistas e conversas de TI. É verdade que uma área – testes, no caso – não tem a mesma abordagem da outra – UX – mas, até que ponto as duas são diferentes ou iguais entre si?
Testes e design podem caminhar juntos
A princípio elas não se encontram seja quando falamos de disciplinas, métodos ou técnicas mas, se começarmos a pensar, vemos que ambas existem para melhorar a qualidade e entregar um produto final melhor. Ainda mais, quando falamos de User Acceptance Testing estamos na verdade mesclando elementos das duas áreas. Na abordagem do UAT temos um ou mais indivíduos validam o sistema com requisitos do usuário que como podemos imaginar, não necessariamente coincidem com os requisitos do sistema. Normalmente eles avaliam aspectos não-funcionais que podem ser muitas vezes desconhecidos por parte dos testadores. O UAT normalmente funciona como uma verificação final em um ambiente e com condições mais próximas do que os usuários finais utilizarão e por isso, é colocado como uma das fases finais do processo de testes. É importante ter em mente que esse tipo de testes foca mais em detalhes e do que em erros mais graves (erros esses que devem ser capturados em fases anteriores de testes).
Testes de aceitação - o usuário define o que está certo ou não
Em resumo, é importante termos em mente de que normalmente uma atividade que aparentemente não tem correlação com uma outra área pode influenciar não somente o jeito de se trabalhar, como também o tipo de artefato que geramos ou técnicas que utilizamos. As vezes, podemos aprender mais com alguém que aparentemente não tem nada a compartilhar conosco do que nosso colega da mesa ao lado.
Espero que de alguma forma, nosso exemplo, possa ser útil a vocês, para que possam tentar aplicá-lo em seus projetos ou que ao menos possa servir de referência para que apliquem suas ideias em seu ambiente de trabalho e com a cooperação dos colegas possam construir soluções para seus problemas. Se você ainda não conhece bem o Scrum, consulte os seguintes links: Scrum em 10 minutos e Histórias de Usuário
O que descrevemos nas próximas linhas, como uma abordagem, surgiu naturalmente durante o projeto e foi sendo aprimorado, com o simples intuito de garantir que as estórias selecionadas para a próxima sprint fossem compreendidas de maneira uniforme por toda a equipe, e atingindo esse objetivo outros benefícios eram proporcionados, como: Diminuição do número de defeitos, maior satisfação do cliente, melhor comunicação entre os membros da equipe, entregas realizadas no prazo correto, além de poder servir como guia para novos integrantes da equipe, entre outras vantagens.
A partir do momento em que as estórias haviam sido selecionadas para a nova sprint, os seguintes passos eram iniciados:
Detalhar estórias da sprint
Discutir o PPT com toda equipe
Implementação da estória
No passo 1, as estórias selecionadas eram descritas através de slides, seguindo a prioridade estabelecida entre as mesmas. Desse modo as mais importantes eram liberadas com maior antecedência para as etapas seguintes. O slides deveriam ser simples e diretos, descrevendo o objetivo central da estória, geralmente continham esboço da interface e informações a respeito do escopo.
Abaixo, exemplificamos o uso dos slides para uma estória fictícia, descrita da seguinte forma: “Como um administrador do blog eu quero saber quais os posts mais acessados para que possa analisar o perfil dos visitantes.”
Já o passo 2, consistia de uma reunião com todo o time, onde o responsável pela elaboração do PPT explicava o funcionamento da estória. Sendo este o momento mais importante da nossa abordagem, o qual permitia um entendimento mais profundo da necessidade do cliente. Durante a reunião todos interagiam procurando esclarecer os detalhes que envolviam a estória, seus possíveis impactos em outras funcionalidades previamente implementadas, além de como a mesma deveria se comportar em determinados cenários.
Ao final da reunião, normalmente algumas mudanças no PPT eram realizadas em razão dos pontos levantados, e a partir desse momento o passo três podia ter continuidade, tendo agora como base também as informações disponíveis no PPT, facilitando o trabalho de desenvolvedores e testadores, através da diminuição da quantidade de retrabalho causado pelo diferente entendimento das estórias.
A abordagem utilizada por nós, atingiu o objetivo do projeto, garantindo que as necessidades do cliente fossem compreendidas pelo time e desse modo proporcionando entregas de maior qualidade. É importante, também, ressaltarmos que o fundamental para o sucesso da abordagem está diretamente ligado a troca de ideias e ao comprometimento com a qualidade, sendo o PPT apenas uma forma rápida e ágil para apoiar essa comunicação.
E o que não podemos nos esquecer, é que a utilização, melhoria e adaptação dos processos deve ser um ato contínuo, onde as características do projeto e das pessoas que fazem o mesmo precisam ser levadas em consideração.
Ficou interessado na abordagem proposta? Caso haja qualquer dúvida ou dificuldade ao tentar aplicá-la em seu ambiente de trabalho, entre em contato conosco.
Todo analista de sistemas sabe da importância da correta identificação e gerenciamento dos requisitos de uma aplicação, e o papel fundamental que os mesmos representam durante todo ciclo de vida de um projeto.
Com o crescimento na utilização de metodologias ágeis, muitos dos problemas em relação aos mesmos foram minimizados, porém o problema está longe de ser considerado resolvido. Muito pelo contrário, não é preciso ter muita experiência em projetos de TI para perceber que diversas vezes os problemas encontrados no software têm origem nos requisitos(ou estórias) ou na falta deles e diversas são as causas para tais problemas. Onde, a principal causa talvez seja o fato do gerenciamento dos mesmos, durante um projeto, continuar sendo frequentemente menosprezado.
Apesar de impactar o trabalho de todos envolvidos em projetos de software (desenvolvedores, testadores, designers e até mesmo dos gerentes) os requisitos ainda são comumente relegados a segundo plano. Até o próprio assunto não é debatido com muita freqüência nas empresas e na internet, e com esse post tentaremos trazer um pouco mais o referido tema para o BDB.
Abaixo tentamos listar alguns dos problemas comumente encontrados por nós, focando, nesse primeiro momento, nos projetos que utilizam metodologias ágeis e versões adaptadas das mesmas:
Isso não funciona:
– Analista de requisitos inexistente:
É comum e até indicado pelas metodologias ágeis que os profissionais tenham perfis multidisciplinares e possam atuar em diferentes papéis durante o projeto, porém isso muitas vezes é confundido e acaba gerando a eliminação de alguns especialistas, onde o caso dos requisitos é um bom exemplo de atividade, que cada vez mais é realizada por pessoas não dedicadas inteiramente a função e que não possuem os atributos requeridos para a mesma, assim temos engenheiros sobrecarregados e muitas vezes executando tarefas que não os agrada.
– Product Owner distante:
No scrum o product owner é muitas vezes o responsável pela definição das estórias e por apoiar a equipe no esclarecimento de eventuais dúvidas a respeito do comportamento esperado das estórias escolhidas para a sprint. Porém, essa comunicação nem sempre funciona de maneira eficiente, fatores como a distância física, dificuldade em entender as responsabilidades do papel ou até mesmo os conflitos naturais que podem surgir da relação cliente X equipe podem criar barreiras que dificultam o trabalho da equipe.
– Entendimento das estórias:
Mesmo quando temos uma comunicação eficiente com o product owner, ainda precisamos nos preocupar com a garantia de uma boa comunicação entre os membros da equipe, evitar ao máximo que as pessoas tenham entendimento diferente das estórias selecionadas, garantir que os mesmos compreendam a extensão e os detalhes que envolvem cada estória.
– Projetos longos:
A medida que o tempo de vida de um projeto aumenta, diversos outros pontos começam a surgir e que podem dificultar o desenrolar das atividades, por exemplo, a necessidade por algum tipo de rastreabilidade entre os requisitos, atividade que dificilmente pode ser executada de maneira eficiente sem dedicação plena.
– Turnover:
A chave do sucesso dos projetos ágeis está na comunicação entre os membros da equipe, o conhecimento a respeito das funcionalidades do projeto passa diretamente pelos integrantes, onde alguns por possuírem determinadas habilidades, acabam se tornando referenciais técnicos, quando tratamos do comportamento correto da aplicação. Porém, frequentemente enfrentamos a rotatividade de pessoal, o que consequentemente leva a perda desse conhecimento, aumentando o grau de dificuldade para novas tarefas e realização de correções e melhorias.
– Cliente imediato não é o cliente final, logo como não documentar tudo?
Muitas vezes confundimos também a idéia de evitar o excesso de documentação encorajada pelas metodologias ágeis com documentação zero, o que para alguns projetos específicos pode fazer sentido e não gerar nenhum tipo de problema, porém de maneira geral dificulta a entrada de novos integrantes ou a correção de defeitos relacionados a estórias implementadas a algum tempo. Esse problema pode ainda se tornar maior quando nosso cliente imediato não é o cliente final, quase que eliminando a possibilidade de trabalhar focado nas necessidades imediatas e feedbacks do usuário final.
– Todo mundo quer ser ágil:
A adaptação da metodologia ágil selecionada para as características da equipe de trabalho é essencial, porém ocorre também o erro comum de tentar aplicar métodos ágeis em todos os projetos, no entanto nem sempre eles são os mais indicados. Com isso surgem situações como projetos ágeis sendo guiados por um imenso documento de requisitos tradicional, repleto de casos de uso e quase nenhuma flexibilidade.
P.S. A partir dos 2 minutos o vídeo exibe apenas propaganda dos produtos da IBM.
Por enquanto, é melhor nem falarmos dos requisitos não funcionais, onde os problemas e dificuldades são ainda maiores.
No próximo post descreveremos algumas soluções que tem ajudado em nossos projetos. Participe comentando sobre problemas relacionados a requisitos enfrentados por você e sua empresa.
Bytes don't Bite! 