Modelos de Desenvolvimento Ágil

Publicado por Dygransoft em

Que a agilidade no desenvolvimento de software sempre foi o sonho de equipes e clientes, isso não é segredo. O problema sempre esteve em como conseguir ser ágil com qualidade, entregando o que o cliente quer e o que o usuário necessita, possibilitando feedback da organização em seus projetos, dentre tantas das variáveis fundamentais. Por isso é necessário entender o que é a agilidade e como pode ser adaptada à realidade de cada equipe.

 

Agilidade

 

Figura 1: Agilidade

O conceito ágil busca agilidade e produtividade, sem comprometer a qualidade do produto.

A documentação, os problemas burocráticos, como hierarquia e coordenações, são deixados de lado, pois o foco principal esta em satisfazer o usuário final, atendendo suas necessidades e contando com o apoio de todos.

Esse conceito foi iniciado pelo Manifesto Ágil, que consistiu em uma mobilização que originou várias metodologias ágeis.

O manifesto ágil possui princípios claros, como:

1º – Focar em indivíduos e em interações mais do que em processos e ferramentas.

Indivíduos

Figura 2: Indivíduos

Buscando derrubar qualquer barreira de comunicação e processo burocrático que existir, permitindo uma interação entre todos os envolvidos.

2º – Focar mais em funcionamento do software do que em documentação.

Documentação

Figura 3: Documentação

Possibilitando maior agilidade e produtividade, buscando alinhar seus objetivos ao do negócio do cliente.

3º Permitir a colaboração de cliente e usuários no desenvolvimento, e não apenas na negociação de contratos.

Cliente na equipe

Figura 4: Cliente na equipe

Aproximando o cliente da equipe, possibilitando validações e acompanhamento do projeto.

4º – Possibilitar respostas a mudanças mais do que seguir um plano.

Respostas rápidas

Figura 5: Respostas rápidas

Oportunizando soluções rápidas e vindas de todos os envolvidos.

São esses princípios que norteiam metodologias ágeis, como SCRUM, ATDD, TDD, BDD e também a técnica de Estórias, as quais serão apresentadas nesse artigo.

SCRUM

É um processo de desenvolvimento iterativo e incremental para construir e gerenciar projetos de software, onde cada parte do software é concluída em curto espaço de tempo e entregue ao cliente.

A figura 6 apresenta a visão geral do Scrum.

Visão geral do Scrum

Figura 6: Visão geral do Scrum

Na figura 6 pode ser observado o fluxo de processo Scrum, que apresenta como principais componentes:

Product Backlog – Que representa a visão geral do produto. O Pacote de requisitos do produto. Sendo esse de responsabilidade do PO (Product Owner), o qual é o responsável por alimentar o backlog, definindo o que deve ser feito, assim como suas prioridades e a ordem em que deve ser realizado.

Sprint Backlog – São pacotes menores de requisitos, priorizados, vindos do Product Backlog. Destacando que a Sprint é definida na reunião de planejamento.

Sprint – As Sprint duram de 2 a 4 semanas, e possuem início e fim definidos. Resultam na entrega de um incremento do produto, planejado pelos requisitos definidos na Sprint Backlog. A Equipe de Scrum executa a Sprint e realiza reuniões diárias, discutindo o que foi realizado no dia anterior, o que será realizado no dia atual e as barreiras possíveis.

A cada Sprint concluída há uma reunião de Retrospectiva, que verifica se o que foi planejado foi realizado.

O fluxo se repete até o Product Backlog ser totalmente desenvolvido.

ESTÓRIAS DE USUÁRIO

As Estórias de usuários são fundamentais para a compreensão das necessidades do negócio e auxiliam a equipe na buscar de um objetivo comum, por simularem situações reais de usuários, como:

O vendedor quer cadastrar um cliente

As estórias podem ser registradas em cartões e terem prioridades associadas, como dos requisitos de negócio convencionais.

O vendedor quer cadastrar um cliente

Prioridade: 3 Pontos

As estórias podem ser detalhadas e posteriormente terem sua prioridade alterada, conforme exemplo abaixo:

O vendedor deve poder cadastrar um cliente. O sistema não poderá gravar um cliente já cadastrado. O CEP e CPF devem ser validados.

Complexidade: 5 PONTOS

Como pode ser observado, quanto mais detalhada a estória, mais fácil ficam as fases posteriores, de desenvolvimento e testes, por exemplo.

TDD – DESENVOLVIMENTO DIRIGIDO POR TESTES

TDD é também uma prática ágil de desenvolvimento, que resulta em uma suíte automatizada de testes unitários e permite praticar um desenvolvimento orientado a testes, onde antes de desenvolver efetivamente, se define expectativas do software, buscando atender a necessidade do usuário, como apresentado no exemplo de estórias, antes de criar o requisito, foi identificada a necessidade de validar CEP e CPF, por exemplo, rotinas as quais podem ser automatizadas.

ATDD – DESENVOLVIMENTO DIRIGIDO Á TESTES DE ACEITAÇÃO

ATDD é uma variação do TDD, mas que dirige seu processo de construção baseado em testes de aceitação.

Para entender na prática, vamos definir antes o que são critérios de aceitação.

Trata-se de uma lista de regras para atender requisitos definidos, no caso, podem ser estórias definidas.

Baseado na estória do vendedor cadastrar um cliente, podemos exemplificar os critérios como sendo:

  • Não gravar um cliente já cadastrado;
  • CEP válido;
  • CPF válido.

Sendo esses os critérios básicos a serem atendidos. Destacando que esses são apenas exemplos, que podem ser detalhados e quebrados em estórias menores, conforme a necessidade identificada pela equipe ou pelo negócio.

BDD – DESENVOLVIMENTO ORIENTADO A COMPORTAMENTO

Como todos os modelos ágeis, o BDD é baseado em usuários, buscando agregar valor de negócio, através de um vocabulário comum, possibilitando comum entendimento entre TI (Tecnologia de Informação) e Negócio.

Cria-se comportamentos baseados no usuário, facilitando a compreensão de todos os envolvidos.

Esse modelo defende que o negócio e tecnologia devem “falar” a mesma língua, também que o valor de “negócio” deve estar claro e que nada deve ser construído precocemente, sem definir o comportamento do usuário.

Os pilares do BDD são “Dado” (Given), “Quando” (When) e “Então” (Then).

Para melhor entender, vamos exemplificar utilizando o exemplo anterior, baseado em um critério de aceitação (CA):

CA1 – Não gravar um cliente já cadastrado.

  • DADO: um cliente;
  • QUANDO o cliente já estiver com CPF cadastrado em outro cliente;
  • ENTÃO o sistema emite uma mensagem que já existe cliente cadastrado com esse CPF;
  • E não salva o cadastro;
  • E retorna a tela de edição.

Como pode ser observado, quando detalhado o CA, baseado no BDD, é possível visualizar o comportamento do usuário e mesmo não havendo sido descrito uma linha de código, a lógica fica nítida, o que facilita as fases posteriores.

CONCLUSÃO

Foram apresentados alguns conceitos básicos e a possível utilização, associando uns aos outros, mas o principal objetivo foi mostrar através de exemplos, de maneira prática, que é possível associar técnicas e modelos ágeis a realidade de equipes, que muitas vezes tem pouco tempo e recurso.

Os exemplos podem ser formalizados e documentados, servindo de feedback de projetos, e melhorando a interação e entendimento de todos os envolvidos.

REFERÊNCIAS

Ivânia Ramos Dos Santos

Bacharel em Sistemas de Informação pela Faculdade Mater Dei (2008), especialista em Engenharia de Software pela Faculdade Mater Dei (2011). Atua como analista de controle de qualidade de processos e configuração, professora na Universidade Tecnológica Federal do Paraná e consultora de processos e pr…

Fonte: http://www.devmedia.com.br/modelos-de-desenvolvimento-agil/27660


Dygransoft

Fazemos parte do grupo Dygran, fundado em 1986 sediado na cidade de Maringá – PR. Desde 1995 a Dygransoft acumula competência e experiência no desenvolvimento de softwares de gestão de empresas (ERP). Nossas soluções são distribuídas por todo o Brasil através de parceiros que atendem prontamente a necessidade de cada cliente.

Iniciar Conversa
Precisando de Ajuda
Olá!
Podemos de ajudar?