É muito comum ouvirmos falar sobre metodologia ágil em TI nos dias de hoje. Realmente é bem raro encontrar alguém envolvido com desenvolvimento de software que nunca tenha ao menos ouvido falar em termos como XP, Scrum, Histórias de Usuário, Pair programming e etc. O conceito de agilidade surgiu por volta dos anos 2000 com a criação do Manifesto Ágil, que possui entre seus doze princípios os objetivos de satisfazer o cliente por meio da entrega contínua e adiantada de valor agregado, além de aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Este artigo visa comparar de maneira geral o papel dos requisitos no Modelo Cascata, utilizado antigamente, com os Modelos Ágeis tão amplamente difundidos nos dias atuais. Vamos lá?

Modelo Cascata x Requisitos Ágeis

No passado, quando uma empresa era contratada para desenvolver um software, o processo de desenvolvimento passava por quatro etapas básicas:

Requisitos
Planejamento
Desenvolvimento
Entrega

A fase de requisitos era determinada pela forte concepção da ideia do produto que estava sendo desenvolvido e o levantamento de todos os desejos e necessidades das partes envolvidas no projeto. Ao final desta fase era necessário entregar uma documentação chamada “especificação”, que funcionava como uma espécie de nota promissória de tudo aquilo que seria construído nas fases seguintes e entregue ao cliente na última etapa do desenvolvimento. Deveria expressar com exatidão e detalhar ao máximo todo o comportamento do software que estaria sendo desenvolvido, pois caso houvessem falhas na definição, todo o planejamento e desenvolvimento estariam comprometidos. Isso acabava gerando ainda mais custos ao projeto, deixando as partes envolvidas descontentes. Como é sabido, por mais que se faça um trabalho de levantamento e análise de requisitos muito bem feito, é um pouco difícil de garantir que falhas não ocorram. Por exemplo, as “necessidades” que o cliente expressou como sendo cruciais, ao decorrer do desenvolvimento, podem se mostrar dispensáveis ou sofrer alterações que impactam todo o plano de projeto criado inicialmente. Nesse contexto, o Modelo Ágil surge com a proposta de reduzir essa documentação. O foco é voltado para a colaboração e comunicação entre as partes envolvidas, buscando entregar valor de forma contínua e responder rápido às mudanças que surgirem no meio do caminho. Ao invés de uma documentação extensa e exaustiva, podemos lançar mão de algumas ferramentas mais sucintas e que cumprem muito bem o objetivo quando bem aplicadas. Uma delas é a escrita de histórias de usuário. Vejamos:

Histórias de Usuário (User Stories)

As Histórias de Usuário comumente se baseiam no template: COMO UM <USUARIO> DESEJO <NECESSIDADE> PARA QUE <OBJETIVO> Não é a única ferramenta que podemos usar para escrever requisitos ágeis, mas as Histórias de Usuário são muito interessantes por gerar alinhamento entre os clientes e o time de desenvolvimento. Elas fazem com que todos conversem na mesma linguagem e a necessidade possa ser transmitida com clareza. Para isso, devemos lembrar sempre que as histórias precisam ser criadas seguindo o conceito INVEST, ou seja:

Independent (Independente): pode ser implementada em qualquer ordem
Negotiable (Negociável): pode ser removida a qualquer instante se descobrir que não é útil
Valuable (Valorosa): entregar valor
Estimable (Estimável): capaz de ser estimada
Small (Pequena): caber em uma Sprint (duas a quatro semanas)
Testable (Testável): possível de ser validada

Ainda que sejam interessantes, claras aos usuários e sucintas o suficiente para que todos consigam rapidamente ler e entender do que se tratam, as histórias geralmente não fornecem subsídios suficientes para que o time de desenvolvimento possa de fato codificar e desenvolver a solução. Neste ponto surgem os Critérios de Aceitação, que são uma lista de itens que expressam como o comportamento do negócio é validado, maximizando o entendimento do mesmo.

O desafio de garantir valor percebido

Ok, até aí tudo parece muito simples e fácil de ser feito, não é verdade? Pois é, na realidade não é tão simples assim. Por mais que estejamos diminuindo a quantidade de papel “inútil” para estimular a colaboração entre os envolvidos e tentando responder rapidamente às mudanças, ainda precisamos garantir que o valor esteja sendo entregue e percebido pelos nossos clientes. É aí que mora o problema, pois para que você saiba o que gera valor ao seu cliente, você precisa perguntar isso a ele, e nem sempre tudo aquilo o que ele te apresentar como sendo algo que ele deseja em seu sistema, é de fato uma real necessidade. É necessário saber fazer as perguntas corretas às pessoas certas para só então começarmos a pensar em gerar valor percebido. Ellen Gottesdiener, que é Coach de Produtos Ágeis e Presidente da EBG Consulting, também é especialista na área de descobrir o valor do produto através da colaboração. Ela aponta que existem três partes interessadas, as quais ela dá o nome de Parceiros do Produto, que possuem interesses distintos no sucesso do nosso produto. É a estes que devemos direcionar nossas perguntas se quisermos que o software que entregamos de fato gere valor aos nossos clientes. Estes, são:

Parceiro Cliente: aquela pessoa que está buscando resolver um problema específico com produto que estamos criando.
Parceiro de Negócios: alguém que tem interesse em nosso software, porém focado no mercado e em geração de receita ou posicionamento estratégico que o nosso sistema pode fornecer a ele.
Parceiro de Tecnologia: quem tem interesse na qualidade, desempenho ou algo do tipo relacionado ao nosso sistema.

Bom, mas agora que já temos uma ideia de para quem fazer as perguntas, resta dizer quais são as perguntas que devemos fazer. Ellen acredita que para que pensemos em nossos requisitos, devemos ter em mente sete dimensões do produto para escrevermos requisitos simples, mas completos. Estas, são:

Usuário
Interface
Ações
Dados
Controle
Ambiente
Atributos de qualidade

Se relacionarmos os parceiros do produto com as dimensões propostas por Ellen, podemos criar uma espécie de Template que pode servir de norte para criação das nossas perguntas. Vamos a um exemplo:

Seguindo essas diretrizes, a equipe de desenvolvimento poderá criar produtos de valor com mais segurança e menos retrabalho. Concluindo: Requisitos ágeis são complexos, mas valem a pena Com tudo o que foi exposto no artigo, vimos que existem técnicas para tornar o levantamento de requisitos ágeis um processo mais fluido e estruturado. Levando em conta as necessidades reais do cliente e do usuário, e alinhando-as com o que é possível desenvolver, os requisitos ágeis são organizados para que o produto seja capaz de entregar o tão estimado valor percebido. Espero que o conteúdo seja útil para seus projetos. Se você tem mais dicas de estudo sobre métodos ágeis aplicados à Análise de Requisitos, deixe seu comentário com sugestões. Até a próxima!

Fonte

EBG Consulting – The 7 product dimensions – a guide to asking the right questions

Luiz Eduardo Feitosa