Ir para o conteúdo

Metodologias

Neste documento está descrito todo o processo utilizado para desenvolver o projeto AMIS e para isso foi utilizado metodologias ágeis de software; sendo elas: Scrum e XP.

Lean Inception

O Lean Inception é uma maneira eficaz de alinhar a equipe em torno do planejamento de um MVP, buscando alinhar os conhecimentos técnicos e de negócio que os membros do time detém sobre o produto. Se trata exatamente de uma metodologia que ajuda a acelerar a oferta de soluções de forma contínua e consistente, sempre englobando dois eixos fundamentais: os objetivos do negócio e as necessidades dos usuários.

Scrum

Scrum é um framework, onde as decisões são baseadas na observação, experiência e experimentação. O Scrum possui três pilares: transparência, inspeção e adaptação. Isso suporta o conceito de trabalhar de forma iterativa. Pense neste framework como um trabalho por meio de pequenos experimentos, aprendendo com o mesmo e adaptando tanto o que você está fazendo quanto o que está sendo feito conforme necessário.

Durante o projeto AMIS, estes ritos ágeis foram utilizados: Product Backlog, Sprints, Sprint Planning, Sprint Review.

Product Backlog

Na metodologia Scrum, o termo Backlog é uma lista priorizada que contém uma breve descrição da funcionalidade necessária no projeto.

O Product Backlog do projeto AMIS pode ser visualizado aqui, o qual foi criado com base nas histórias de usuários e é utilizado para a criação das issues.

Sprint

Sprint no Scrum, é um período de tempo de até um mês, no qual é feito uma quantidade determinada de issues pela equipe. No projeto AMIS, as Sprints foram criadas com base nos épicos do projeto. As Sprints podem ser visualizadas aqui.

Sprint Planning

A Sprint Planning é um rito ágil de planejamento onde é decidido quais issues do Product Backlog serão feitas na próxima Sprint.

No projeto AMIS as Sprints são realizadas no tempo de uma ou duas semanas. Nas reuniões com os Product Owners são apresentados os avanços no produto que foram implementadas durante a Sprint.

Daily Meeting

O Daily Meeting é uma reunião diária de acompanhamento da equipe com objetivo de de cada participante relatar sobre o seu status e possíveis impedimentos na realização do projeto.

Na equipe de desenvolvimento do AMIS as Dailys duram até no máximo 15 minutos e ocorrem de segunda à sexta.

Sprint Review

A Sprint Review é um reunião de revisão da sprint, no qual é feita uma validação das entregas e desempenho dos integrantes da equipe, de forma que é decidido quais tarefas entrarão para dívida técnica e pontos de melhorias para a próxima sprint.


XP

Extreme Programming (XP) é uma estrutura ágil de desenvolvimento de software que visa produzir um produto mais eficiente com uma maior qualidade de vida para a equipe de desenvolvimento. O XP é o mais específico dos frameworks ágeis em relação às práticas de engenharia apropriadas para o desenvolvimento de software.

No projeto AMIS foram adotados algumas práticas do XP, sendo elas: Planning Poker, Design Incremental, Cliente Presente, Releases Curtas, Código Coletivo, Testes Automatizados, Programação em Pares e Integração Contínua, descritas abaixo.

Planning Poker

O planning poker, traduzido como Poker do planejamento, visa auxiliar a equipe com votações, em que cada pessoa que faz parte da equipe de desenvolvimento indica um valor dentro de uma sequência de números que representa o esforço e capacidade da equipe em executar a tarefa dentro de um prazo específico. A sequência de número utilizada é similar a encontrada nos números de Fibonacci (1, 2, 3, 5, 8, 13...). Então, nessa votação, o valor representa o esforço que será gasto para desenvolver um determinado item do backlog. A partir disso, todo o time participante realiza discussões sobre o jogo a fim de avaliar os diferentes pontos de vista e chegar a um senso comum de resposta.

Design Incremental

O Design incremental consiste em definir o design do sistema que está sendo desenvolvido de uma forma contínua e incremetal, em vez de estar concentrada no início do projeto, antes de qualquer codificação. Pois, quando o design é confinado no início do projeto, correm-se diversos riscos, pois os requisitos ainda não estão totalmente claros para o time, e nem mesmo para o representante dos clientes. Além da possibilidade do surgimento de novos requisitos ao longo do projeto, tornando o design inicial desatualizado e menos eficiente.

Cliente Presente

O cliente deve participar ativamente do processo de desenvolvimento. Tudo precisa da comunicação e aprovação com o cliente. Ele deve receber o melhor resultado possível a cada semana, ver o progresso no sistema, ser informado de mudanças de planos, para que saiba qual é o problema a ser resolvido.

Releases Curtas

As releases são pequenos pedaços do produto que serão entregues ao cliente antes do prazo, assim o cliente não precisa esperar o produto ficar pronto para vê-lo. Releases curtas são liberações de pequenas versões funcionais do projeto, que auxiliam no processo de aceitação por parte do cliente, para que já possa testar uma parte do sistema.

Código Coletivo

Propriedade de código coletiva é a idéia de que todos são igualmente responsáveis por todas as partes. Com isso, os desenvolvedores ganham tempo, pois não precisam esperar a autorização de um colega para editar uma área do código e há maior disseminação de conhecimento. Além disso, quando diversas pessoas têm a chance de olhar uma mesma área do código, torna-se mais frequente a identificação de oportunidades de melhoria, levando frequentemente à refatoração em áreas que precisam das mesmas e correções de bugs.

Testes Automatizados

A ideia é que testes manuais — um ser humano executando o programa, fornecendo entradas e checando as saídas produzidas — é um procedimento custoso e que não pode ser reproduzido a todo momento. Logo, XP propõe a implementação de programas — chamados de testes — para executar pequenas unidades de um sistema, como métodos, e verificar se as saídas produzidas são aquelas esperadas.

Programação em Pares

A programação em pares é uma técnica na qual dois desenvolvedores se unem em um computador. As duas pessoas trabalham juntas para projetar, codificar e testar histórias de usuários. Idealmente, as duas pessoas seriam igualmente habilidosas e cada uma teria o mesmo tempo no teclado.

Integração Contínua

A Integração Contínua é uma prática utilizada para construir ou integrar as etapas do desenvolvimento de um software, de modo que o código principal permaneça sem bugs ao final de cada uma das sprints. No nosso contexto, utilizamos o GitFlow no GitHub para fazer o versionamento do sistema e, a cada nova construção ou integração de diferentes funcionalidades, é realizada a revisão dos seus critérios de aceitação e caso aprovado é feito um Pull Request para a branch principal.


Referências


Versionamento

Data Versão Descrição Autor(es)
16/11/2022 1.0 Adiciona a descrição das metodologias do projeto Thiago Luiz, Caio Sulz
16/11/2022 1.1 Correção gramatical Thiago Luiz, Caio Sulz
30/12/2022 1.2 Complementando as metodologias do projeto Fabrício de Queiroz, Caio Sulz