#3 REQUISITOS E AGILIDADE

   

Será que meus clientes gostarão de ler isso?! XD

   Estamos aqui em mais uma postagem e como deve ter percebido, ou não, sempre falo que aquilo que o cliente quer é o mais importante em todo um projeto de desenvolvimento do sistema. Se você faz parte de uma equipe e um cliente de pede um software X e no final do projeto é entregue Y então a satisfação do cliente não é nada boa e seu sistema não servirá para nada, o tempo gasto também não e o custo... Levando isso em consideração, mostrarei um pouco sobre metodologias e técnicas que são utilizadas no processo de desenvolvimento de projetos.

   Uma das formas de se realizar um projeto é através da documentação tradicional, onde busca registrar e definir todos os requisitos do cliente antes de desenvolver o projeto. Quando o projeto é finalizado é feito uma comparação para identificar se aquilo que foi realizado com aquilo que o cliente deseja. Essa metodologia não é muito eficaz em grande parte dos projetos, especialmente aqueles que a equipe deve ter um acompanhamento do cliente, pois requisitos e ferramentas mudam ao decorrer do projeto e a melhor forma de se resolver isso é simples: interação com o cliente.

Figura 2 - Representação da documentação.

   E aí vem as metodologias ágeis do sistema, cujo objetivo não é documentar mais ou menos ou até parar de documentar e sim saber quando documentar, ou seja, o momento em que o benefício de se documentar é melhor que o custo expendido em tal processo. Além disso é utilizado o mais importante de todos nessa metodologia, que é a comunicação mais direta com o cliente que define bem o rumo do projeto.

Figura 3 - Representação de metodologias ágeis.

   Daí vem uma das dessas metodologias rápidas chamada de História de Usuários, que se trata de descrição de forma simples, direta e clara das funcionalidades do sistema definidas pelo cliente, onde a equipe pode intervir para auxiliar naquilo que o cliente deseja. Segundo diversas fontes, geralmente são utilizados cartões/postites com linguagem simples de uma a duas frases. O importante a citar sobre História de Usuários é que ela não vai documentar nada, porém auxiliar muito em identificar aquilo que é necessário para o desenvolvimento eficaz do projeto. Abaixo está uma imagem esquemática de como funciona da técnica, porém quebrando ela em tarefas. Nela é abordada um sistema de divulgação de eventos, o qual a organização possui um sistema, onde os clientes interessados entram em contato para divulgar seus eventos através do sistema.

Figura 4 - Exemplo de História de Usuários.

   Percebe-se parte inferior da imagem as tarefas são quebradas de forma a facilitar no desenvolvimento do sistema e são inteiramente baseadas na funcionalidade que o cliente deseja. Através disso, nota-se a facilidade de usar o método, onde o cliente não precisa de experiência. Além disso, é uma técnica não demando muito tempo e eficaz, onde o cliente tem interação direta priorizando aquilo que é realmente necessário para desenvolver o sistema. A partir disso, a equipe consegue filtrar melhor as informações necessárias e criar uma documentação consistente e mais estável.

   Outra técnica importante em metodologias ágeis é a chamada MoSCoW. Com a utilização da técnica os clientes e equipe definem juntos uma lista de quais requisitos são mais importantes/críticos em um projeto, o que consequentemente ocasionará na entrega do projeto solicitado ao cliente, pois como os requisitos são divididos em prioridades a equipe terá um caminho a ser seguido. As prioridades são definidos exatamente pelo nome da técnica. Talvez você se pergunte: como assim? É exatamente isso, as letras maiúsculas do nome da técnica representa a primeira letra de cada uma das prioridades. Abaixo está uma imagem que identifica cada uma.

Figura 5 - Identificação do MoSCoW.

   Como se pode perceber, as prioridades em vermelho são as mais importante, especialmente a Must, que define a prioridade principal de todas, pois alguns requisitos sem ela não existe e nunca existirá um sistema que deseja ser desenvolvido. A outra prioridade é a Should, onde nela é algo muito importante ter para o sistema funcionar de forma eficaz do modelo que o cliente quer, porém sem ela o sistema funcionaria. Abaixo dessas duas prioridades temos a Could e Won't. A Could é algo que poderia ter no sistema, ou seja, desejável ao sistema, porém que só poderia ser implementado, caso as prioridades acima Must e Should estiverem concluídas. O sistema funciona de forma que o cliente quer, porém com ele o cliente poderia atingir o nível bom de satisfação. Já o Won't ou Would é algo que não impactaria em nada no sistema, mas pode futuramente trazer impacto. Entretanto, não se pode deixar ele de lado, pois ao decorrer do projeto pode ser que mude sua prioridade. E falando nisso, é importante lembrar que requisitos ao longo do tempo podem mudar de prioridades dependendo naquilo que cliente deseja, por isso é sempre bom ter um interação boa com ele. 

   O que faz ela ser mais eficaz que a priorização tradicional é por ela ser mais específica e clara no desenvolvimento do projeto identificando aquilo que realmente é importante/trivial para o cliente. Um exemplo disso é caso num projeto seja utilizado o modelo tradicional e a equipe define que dois requisitos são de alta prioridade. Paralelo a isso fosse utilizada no mesmo projeto a técnica MoSCoW e os dois requisitos, que são de alta prioridade, identifica que um deles é Must e outro é Should. Isso define de maneira mais específica aquilo que é mais trivial no sistema tanto para o cliente quanto para a equipe.

   A partir de tudo que foi apresentado, percebe-se que as metodologias ágeis traz uma maneira diferente de identificar aquilo que deve ser feito, de forma mais clara e objetiva. Além disso mantém uma maior interação com o cliente que é muito importante em fases de desenvolvimento do sistema, pois isso informa se o caminho tomado é o correto ou não. A seguir estão três características importantes que retirados de um vídeo no youtube chamado Métodos agéis e Documentação de Software do canal Eduardo Borges. São elas: desenvolvimento ágil reduz a necessidade de documentação, criar a documentação caso ela gere valor, documentação é resultado e não insumo. É muito importante manter isso em mente, pois irá auxiliar bastante a entregar aquilo que o seu cliente quer.