Requisitos Ágeis – o que de fato agrega valor?

Atualmente, o desenvolvimento de novas tecnologias gera diferentes necessidades, que por sua vez levam a outras tecnologias, criando um ciclo inovativo. Portanto, empresas, equipes e colaboradores estão imersos num processo evolutivo rápido, demandando por respostas rápidas e adequadas. Assim, a equipe de desenvolvimento precisa estar preparada para as mudanças de requisitos solicitadas pelos clientes durante os projetos.  E, considerando a velocidade de mudanças a que os requisitos estão submetidos, devemos nos preocupar em como mantê-los atualizados. Dentro desse contexto, entra a abordagem de requisitos ágeis – conjuntos de práticas utilizadas no levantamento dos requisitos de forma holística, dando ênfase ao comportamento esperado do software focado no valor de negócio da aplicação.

O Manifesto Ágil valoriza software funcionando que agregue valor ao cliente. Isso requer um mínimo de documentação para o desenvolvimento do software. Portanto, desenvolvimento ágil também precisa de documentação, mas devemos ficar atentos sobre a forma como se está documentando. Segundo Angela Wick [2], se prioriza a documentação não é ágil; se prioriza a colaboração e usa o mínimo possível de documentos unicamente para lembrar do que foi conversado, então você está utilizando a abordagem de requisitos ágeis no seu projeto.

Em times ágeis, em vez de despender meses detalhando os requisitos do sistema, foca-se em realizar entregas mais rápidas de requisitos e software. O cliente do sistema não precisa mais aguardar meses para ver o resultado do sistema e descobrir se o que foi feito está certo. A cada ciclo, 3 semanas em média, o cliente recebe uma versão executável e pode testar em seu próprio ambiente. A entrega frequente de requisitos permite ao cliente tomar decisões mais assertivas sobre o produto final.

A abordagem ágil torna os requisitos muito mais flexível, temporal, interativo, adaptável e just-in-time. Essa, talvez, seja  a palavra que melhor se encaixa nesse contexto, just-in-time,  ou seja, entregar os requisitos de acordo com as necessidades do cliente e no tempo estabelecido.

Uma outra abordagem bem interessante e muito usada em times ágeis, é a participação de membros do cliente nas iterações (sprints). Com essa interação com o cliente, é possível detectar, durante o processo de desenvolvimento, possíveis falhas nos requisitos e então adequá-los em tempo real evitando o desperdício no processo de desenvolvimento.

Aquelas especificações de requisitos gigantes com dezenas de páginas, fluxos, diagramas, ilustrações, tudo muito detalhado, com índices de duas ou mais páginas agora tendem a ser mais simplificadas. No contexto ágil, as documentações costumam ser mais diretas e sucintas.

Fluxos, diagramas, imagens ainda são muito bem-vindas! Muitas vezes é quase que a documentação necessária para o pessoal do desenvolvimento conseguir implementar o software com a qualidade esperada. Basta um diagrama e uma boa conversa entre Requisitos e Desenvolvedor e pronto! É o suficiente. Com apenas isso, muitas vezes, é possível entregar o que o cliente deseja de forma correta e com o mínimo de documentação.

Como entregar requisitos mais rápido

Quando o Analista de Requisitos se vê sob pressão entre prazo e qualidade, o foco maior tende a ficar  concentrado no prazo. Então, o  mais comum é a pessoa responsável pelos requisitos se debruçar sobre a documentação sem muito diálogo e análise com a equipe. Usa-se um template de documento ou um checklist para confirmar se está tudo ali no documento. Porém, isso não ajuda a acelerar o processo de requisitos. Pelo contrário, quando a maior parte do tempo de requisitos é gasto com documentação e revisão e não com planejamento, elicitação e análises, mais longo e dolorido é o processo de requisitos.

Como mencionado por Priscilla Aguiar [1], de acordo com Ambler deve-se modelar com os desenvolvedores, para que eles entendam os requisitos e você entenda o que eles estão tentando construir.

Considere essas 5 atividades de levantamento de requisitos:
Planejamento, elicitação, análise, documentação e revisão.

Qual a dedicação do seu time para essas atividades?

imagem_1                                             
  Figura 1 –  Processo de Requisitos lento

image_2
Figura 2 – Processo de Requisitos rápido

Segundo Angela Wick [2], se o percentual investido do seu time se adequar mais ao primeiro gráfico, cuidado. Você pode estar despendendo muito esforço em documentar e revisar algo que pode ter mudança de escopo e, por conseguinte, retrabalho, ou seja, desperdício. Isso pode até resultar em mais problemas do que benefícios. Deve-se gastar menos tempo nas atividades de documentação e revisão. Essas atividades, além de demandar muito tempo dos stakeholders, podem ser desnecessárias. Mudanças podem ocorrer a qualquer momento, mesmo após longas reuniões ou durante testes em que novos requisitos podem ser identificados.

Ao contrário da Figura 1, o segundo gráfico (Figura 2) mostra como deve ser o processo de requisitos em uma equipe ágil. Como analistas de requisitos, ‘donos’ do negócio, devemos mudar o pensamento de forma a obter um diálogo crítico e construtivo na elicitação dos requisitos e análise. Num processo modelo do ponto de vista da ágil, elicitações de requisitos e análises bem feitas devem levar a um gasto de tempo entre 5-10 % nas etapas de documentação e revisão. Isso é uma considerável mudança de abordagem com economia de tempo no processo todo e diminuição do risco de retrabalho de desenvolvimento. Portanto, este processo deve estar completamente finalizado antes da etapa de documentação e a revisão.

O que de fato agrega valor é o conhecimento do negócio do seu cliente. Não importa a maneira como os requisitos são identificados ou documentados, e sim se a informação necessária para o entendimento da solução está clara para todos os stakeholders envolvidos no projeto.

O grande desafio de requisitos é documentar o conhecimento de forma útil para todos que precisem dele, e que possa ser atualizado para atender às constantes mudanças.

Lembre: Ágil não é um método, é uma maneira de pensar!

 

Agradeço aos comentários do Prof. MSc. Igor Muzetti Pereira da ICEA-UFOP

Referências:
[1] https://pt.slideshare.net/pricaguiar/especificar-requisitos-em-metodologias-ageis

[2]https://www.batimes.com/angela-wick/2-requirements-tasks-you-re-probably-spending-too-much-time-on.html?platform=hootsuite

[3] http://agilidade.org/

[4] http://www.devmedia.com.br/engenharia-de-requisitos-agil/31871

[5] https://pt.slideshare.net/andrefaria/requisitos-geis

[6] https://pdfs.semanticscholar.org/a963/8eaabbf358fb2e32eee12fe85129375ad6c6.pdf

[7] http://www.professores.uff.br/screspo/tc_pablo.pdf

Por MAGDA IOLANDA FARIA

Analista de Requisitos, MATERANA desde 2011, adepta a experimentar novidades e cervejas. Nas horas de lazer acha que é corredora.

Postado em: 03 de maio de 2017

Confira outros artigos do nosso blog

Vamos falar sobre métricas Kanban?

21 de maio de 2018

Ricardo Augusto Shikota

Método Kanban: primeiros passos

10 de maio de 2018

João Paulo Grabosque

Afinal, o que é Scrum Master?

20 de abril de 2018

Fernanda Rogge Barbosa

Agilidade: Soft skills x Hard skills

12 de abril de 2018

Ariane Ferreira Izac

Deixe seu comentário