Breve Introdução

A prototipagem nos métodos ágeis vem como uma das principais ferramentas de auxilio ao levantamento de requisitos. Uma maneira rápida de identificar as principais funcionalidades que um cliente demanda junto com a simplificação da informação. User Stories ou (Histórias de Usuário) é uma das técnicas utilizadas em entrevistas com usuários ou product owners a fim de modelar as funcionalidades descritas em pequenas tarefas, que deixarão o processo de criação do product backlog mais claro e rápido. O Planning Poker é uma técnica de estimativa de tempo e grau de dificuldade para o desenvolvimento de uma tarefa, muito utilizado no desenvolvimento ágil.

Prototipagem

Devido ao fato da constante mudança e evolução em nossa sociedade, concomitantemente com a ausência do estabelecimento de especificações claras do projeto por parte dos clientes, é imprescindível o uso de ferramentas para auxiliar no esclarecimento e definição de tais questões, de forma a contribuir no fluxo do desenvolvimento do projeto e na entrega de um produto que atenda as reais necessidades dos clientes.

A prototipagem é um processo pertencente ao desenvolvimento de software, no qual se baseia na elaboração de um protótipo do sistema a ser desenvolvido. Esse processo pode ser realizado por meio de um rascunho, apresentação de slides ou uma implementação simples do software, desta última é mais comumente utilizada. Primeiramente, é criada uma versão inicial que atenda os requisitos de maior prioridade do projeto. Após isso, o protótipo do software passa por uma avaliação do cliente o qual retornará com o feedback. No feedback, baseando-se na versão do protótipo entregue, o cliente informará quais modificações serão necessárias e a possível implementação de novos requisitos. Os engenheiros de software e demais membros da equipe de desenvolvimento irão avaliar a viabilidade dessas alterações, observando algumas questões:

• A viabilidade financeira;

• Disponibilidade de recursos humanos e habilidade dos mesmos para a realização das tarefas;

• A não infração das políticas e normas que regem a empresa e se aplicam ao sistema;

• A persistência com a ideia inicial/meta do projeto;

• O comprometimento da arquitetura do sistema, introduzindo erros, caso as mudanças introduzidas confrontem com o que já foi estipulado e desenvolvido.

Concluindo-se a análise da viabilidade por parte da equipe, haverá um consenso próximo do que realmente deverá ser implementado no sistema por parte de todos, juntamente com os stakeholders (clientes), finalizando a etapa da prototipação. Alguns processos de desenvolvimento de software utilizam-se da prototipação em seu processo, como o desenvolvimento incremental, com a diferença de que o protótipo a ser desenvolvido deixa de ser um esboço para estabelecer o projeto do sistema e seus requisitos, e passa a ser uma versão do software a ser entregue sob a forma de releases, por meio de um processo iterativo.

Protótipo de Tela feito com Balsamiq

Por que prototipar?

A prototipagem nos auxiliará na construção de uma estrutura para o projeto no qual estaremos envolvidos, mas sem expor muitos detalhes técnicos, o que facilitará também ao usuário interpretar e opinar sobre qual seria a o modelo do projeto que mais lhe agrada, auxiliando os desenvolvedores no processo de criação de um sistema com boa usabilidade.

Ferramentas de Prototipagem.

Como entende-se pelo próprio nome o desenvolvimento ágil busca sempre a aprimoração e maior velocidade ao se gerar novos sistemas, dada essa necessidade podemos utilizar ferramentas de auxilio para modelagem de um protótipo, sem a necessidade de possuir uma técnica muito abrangente em relação a desenhos de telas, estrutura hierárquica de sites, navegabilidade, etc. As ferramentas de prototipação possuem templates de telas que tornarão a criação de um protótipo de forma mais simples e ágil, que é o principal objetivo.

Algumas ferramentas de auxilio são encontradas na sua versão gratuita, e também paga que trazem mais funcionalidades, entre elas temos o Balsamiq (http://balsamiq.com), Cacoo (http://cacoo.com), Creately (http://creately.com), entre outras.

User Stories

Primeiramente, o que são Histórias de usuários? Abordando conteúdos sobre Processos Ágeis, muitas vezes nos deparamos com um modelo chamado de Histórias de Usuários (User Histories), que nada mais é que uma maneira diferente, rápida, eficiente e até divertida de se fazer a especificação de requisitos para um determinado projeto. Mais especificamente, na área de Tecnologia da Informação utilizamos a Analise de Requisitos para englobar todas as funcionalidades que o projeto deverá conter para atender as necessidades de todos os usuários que se utilizarão deste projeto. Se a especificação do que deve ser feito for precária ou incompleta, pode prejudicar o andamento do projeto, levando a desentendimentos entre desenvolvedor-cliente, resultando em funcionalidades erradas, incompletas ou que executam de forma diferente do esperado.

Gráfico de Requisitos

Neste tipo de planejamento, o desenvolvedor não apenas recebe o “o que fazer”, mas também um complemento de informações para que ele possa tomar uma decisão correta. É importante entender a estrutura base de uma história de usuário, ou seja, as informações fundamentais que precisam constar numa boa especificação de requisitos. O uso das Histórias de Usuários é feito seguindo os seguintes parâmetros:

• Quem? Para quem estamos desenvolvendo a funcionalidade.

• O que? Uma descrição resumida da funcionalidade em si.

• Por que? O motivo pelo qual o cliente precisa desta funcionalidade.

Normalmente para responder as três perguntas citadas acima nós usamos o SENDO, POSSO e PARA QUE.

Exemplo:

SENDO um vendedor que realiza 50 visitas por dia

POSSO consultar as últimas compras de cada cliente

PARA QUE ao chegar no cliente eu possa consultar qual foi sua última compra, e assim conseguir negociar com ele estando melhor informado.

Para testar as Histórias de Usuários, são criados cenários (representando as funcionalidades):

Outro ponto importante é que as Histórias de Usuários são pequenas e simples e não capturam muitos detalhes. E exatamente por deixar de fora detalhes de implementação, como a navegação no sistema, as Histórias de Usuários requerem muito pouca manutenção, não se tornando um documento obsoleto rapidamente ou que exija muito esforço para mantê-lo atualizado. Acima de tudo, as Histórias de Usuários ajudam a transformar um grande problema (que o sistema irá resolver) em pequenas partes. Essas partes são utilizadas para guiar o desenvolvimento. Dessa forma, as Histórias de Usuários possibilitam o desenvolvimento iterativo, permitindo que a equipe do projeto faça pequenas entregas evolutivas enquanto interage e colabora com o cliente.

Relatos de “Bugs” de uma forma Ágil: Em uma tentativa de ajudar os administradores a retirarem ou diminuírem os erros nos sistemas, Rafael Helm e Daniel Wildt escreveram em seu livro “Histórias de Usuário – Por que e Como Escrever Requisitos de Forma Ágil”, uma maneira de relatar bugs. Os passos base para o processo são: 1 – mostrar como repetir o problema, 2 – detalhar o problema, 3 – apresentar o comportamento esperado. Relatos carregados de emoção, frustração ou cobrança não são efetivos. Com estes simples passos é possível identificar tanto a causa do erro como também apresentar sua solução, alcançando a situação desejada.

Ilustração de Planning Poker

Planning Poker

O Planning Poker é uma prática que tem como finalidade estimular as tarefas entre os desenvolvedores de um time, essa prática é aceita na maioria das empresas e em projetos que utilizem Scrum.

O Planning Poker funciona da seguinte forma, todos os desenvolvedores ficarão com as cartas que representam a sequência de Fibonacci (1,2,3,5,8,13,21,34,55,89), cada carta com um grau de complexidade, em uma reunião o time vai esclarecer as histórias do Product Owner, logo depois os desenvolvedores atribuirão o grau de complexidade para cada história (tarefa), as cartas devem ser jogadas ao mesmo tempo, e nenhum membro do time pode influenciar ao outro. Logo após que cada desenvolvedor atribuir um grau de complexidade as tarefas verificasse se houve ou não divergências no time, caso haja diferença no grau de complexidade cada membro do time pode argumentar por que atribuiu um grau de complexidade maior ou menor do que ao restante dos membros do time, logo depois das sugestões e da conversa entre o time cada membro pode solicitar uma nova votação para a mesma tarefa e mudar o grau de complexidade.

No Planning Poker só participam da votação das tarefas as pessoas que realmente irão codificar determinadas funcionalidades com determinada tecnologia, isso garante a melhor compreensão das tarefas e faz com que o time vá direto ao ponto, trazendo um aumento de produtividade para o projeto em questão.

O Planning Poker funciona com os projetos Scrum pois apresenta múltiplas opiniões de especialistas quanto a estimativa de um item, e pelo bom senso do Scrum é sempre muito importante ter conselhos sobre os diversos fatores e tarefas. O Planning Poker também gera conversa entre os membro do time, que por sua vez fazem um compartilhamento de conhecimento e informações, estimativas feitas em grupo são bem mais sucedidas do que estimativas feitas individualmente, e por fim, utilizar da prática do Planning Poker pode tornar uma tarefa muito divertida e prazerosa.

Conclusão

O principal objetivo dos métodos ágeis como sabemos é o desenvolvimento de sistemas de forma bem gerenciada, cumprindo prazos, garantindo a qualidade do produto tudo isso de uma forma rápida e que satisfaça as necessidades dos clientes envolvidos. As três abordagens apresentadas, unidas aos processos ágeis, como a gerencia de projetos Scrum, tornam o desenvolvimento de software um processo sólido e robusto capaz de ser estimado com maior facilidade. A prototipagem é uma das melhores formas de esclarecer as funcionalidades descritas pelos clientes, as histórias de usuário facilitam a definição e distribuição de atividades entre os membros do time de desenvolvimento, somados a técnica de planning poker fazem com que o desenvolvimento de um software se torne um cada vez mais um processo atomico, mudando a cultura conhecida de que um projeto de software demore muitos meses ate pouco mais de um ano para ser desenvolvido e entregue.

Texto escrito por:
Álex Tominaga
Ingrid Curimbaba
João Felipe
Pedro Souza