No meu último texto, falamos sobre diferentes modelos de ciclo de vida que podem ser adotados durante o desenvolvimento de software. Terminei falando sobre métodos ágeis, tema do texto de hoje!

O desenvolvimento ágil surgiu como um esforço para sanar algumas fraquezas da Engenharia de Software tradicional. Nele, os desenvolvedores assumem uma abordagem que permite permanecerem ágeis (isto é, adotando processos de software que são manipuláveis e sem excessos) e que se adequem a um mundo com grande necessidade de adaptação e competitividade.

Desenvolvimento tradicional vs. Desenvolvimento ágil

Sua origem remonta ao movimento iniciado por líderes da comunidade de Extreme Programming (o famoso ‘XP’), que visava a debater este e outros métodos leves (métodos de desenvolvimento que contrapunham métodos com formalização exagerada de documentação e regulamentações, muito influenciados pelo Modelo Cascata). Esse movimento culminou no manifesto ágil, um documento assinado em 2001, que descreve um conjunto de valores e princípios que são carregados por cada método ágil existente hoje.

Autores do manifesto ágil

Os autores desse documento elencaram 4 valores que são essenciais no desenvolvimento de software:

• Indivíduos e interações mais que processos e ferramentas
• Software em funcionamento mais que documentação abrangente
• Colaboração com o cliente mais que negociação de contratos
• Respostas a mudanças mais que seguir um plano

Ou seja, mesmo havendo muito valor nos itens à direita, devemos valorizar mais os itens à esquerda.

Como os modelos de ciclo de vida, existem diferentes métodos ágeis. Então, também vamos conhecer alguns deles!

Métodos ágeis

O eXtreme Programming (XP) é uma abordagem disciplinada que permite criar versões de software frequentemente e continuamente priorizando envolvidos. Em vez de entregar todas funcionalidades em algum momento no futuro, é feita entrega apenas do necessário no momento mais próximo. Ele baseia-se em valores como comunicação, simplicidade, feedback e coragem, tendo também algumas práticas de apoio que devem ser levadas “ao extremo” durante a condução do projeto:

• Fases pequenas (small releases): Dividir o projeto em ciclos curtos;
• Jogo de planejamento (planning game): Priorizar as funcionalidades que serão desenvolvidas antes de cada ciclo;
• Metáfora (metaphor): Entender a realidade do cliente, traduzindo necessidades em requisitos do projeto;
• Projeto simples (simple design): Entregar somente o que foi solicitado pelo cliente;
• Testes de aceitação (customer tests): Toda nova funcionalidade deve ser validada pelo cliente;
• Semana de 40 horas (sustainable pace): Não deve ser feito trabalho extra;
• Propriedade coletiva (colective ownership): O código-fonte é uma criação colaborativa e todos podem modificá-lo;
• Programação pareada (pair programming): A programação deve ser feita em duplas no mesmo computador, normalmente juntando um profissional iniciante e outro mais experiente;
• Padronização do código (coding standards): Devem ser definidos padrões para construção do código de forma que o código fique uniformizado e mais compreensível;
• Desenvolvimento orientado a testes (test driven development): Toda funcionalidade deve passar por rigorosos testes antes de ser validada, para evitar retrabalho da equipe;
• Refatoração (refactoring): O código deve ser revisado periodicamente para ser continuamente aperfeiçoado;
• Integração contínua (continuous integration): Toda funcionalidade testada deve ser imediatamente sincronizada entre a equipe, evitando conflitos.

XP

No Scrum, as atividades de desenvolvimento são organizadas em sprints, onde trabalho realizado em cada sprint varia de acordo com o tamanho e a complexidade do produto e pode ser modificado em tempo real, permitindo assim que o processo de desenvolvimento se adapte às necessidades do projeto. As pessoas envolvidas no projeto podem assumir três papéis:

• Product owner: Responsável por gerenciar o conjunto de funcionalidades e características que o produto deve ter (product backlog), atuando como representante do cliente.
• Scrum master: Responsável por disseminar o scrum pela organização e garantir que ele esteja sendo aplicado de forma correta
• Development team: Equipe de desenvolvedores responsável por entregar as funcionalidades do produto.

O funcionamento do Scrum se dá da seguinte forma: as funcionalidades a ser desenvolvidas são mantidas no product backlog. No início de cada sprint, é feita a reunião de planejamento (sprint planning), em que o product owner prioriza um conjunto de funcionalidades e a equipe de desenvolvimento seleciona aquelas que podem ser implementadas durante a sprint, distribuindo-as entre seus membros. Diariamente são realizadas breves reuniões (daily scrum) para compartilhar conhecimento (como dificuldades e riscos identificados) e alinhar as atividades realizadas na sprint. Ao final de cada sprint, é realizada uma reunião (sprint review) para verificar se o que foi feito está alinhado com os requisitos do produto, podendo também ser realizada reunião para identificar lições aprendidas e pontos do processo que podem ser melhorados (sprint retrospective). Essas etapas acontecem até que produto esteja pronto.

Scrum

Outro método é o FDD (Feature Driven-Development ou Desenvolvimento dirigido a funcionalidade), que estimula a decomposição do projeto em funcionalidades (a) que possam ser implementadas em 2 semanas ou menos e (b) que sejam entendidas como úteis pelos usuários. Para isso, é executada uma fase de concepção e planejamento, onde é criado um modelo que especifica as principais informações sobre o projeto, além de organizar a lista de funcionalidades a serem desenvolvidas. Após isso, inicia-se a construção, momento em que as funcionalidades são desenvolvidas de forma iterativa (em ciclos) e incremental (cada ciclo gera um novo incremento, isto é, uma nova funcionalidade). É importante ressaltar que a equipe de desenvolvimento das funcionalidades deve ter entre 3 e 6 programadores. Além disso, ao final de cada iteração, são realizadas inspeções para eliminar erros e consolidar as lições aprendidas.

FDD

Independentemente do método ágil selecionado, alguns benefícios podem ser obtidos pela sua aplicação:

• Assertividade: O foco na entrega de valor para o cliente é mais evidente do que na maioria dos modelos clássicos de desenvolvimento. O cliente é envolvido diversas vezes na construção do projeto e, a divisão do projeto em ciclos curtos, permite a validação mais rápida das entregas.
• Flexibilidade: As metodologias ágeis advogam pela maior flexibilidade às mudanças, entendo-as como parte do gerenciamento do projeto e precisam ser atendidas para gerar valor.
• Colaboração: As metodologias ágeis estimulam a organização de pequenas equipes multidisciplinares, facilitando assim a criação de um ambiente colaborativo e motivador. Além disso, o cliente passa a ser um parceiro dessa equipe, sendo envolvido durante todo o desenvolvimento do produto.
• Comunicação: O estabelecimento de uma boa comunicação entre as partes interessadas no projeto também é essencial nas metodologias ágeis. O recomendado é que as conversas sejam feitas cara a cara, pois a presença física da outra pessoa permite uma melhor interpretação do que está sendo colocado. Isso evita ambiguidades que podem comprometer o resultado do projeto.
• Simplicidade: O planejamento e documentação gerada por um projeto que utiliza metodologia ágil é bem simples, focando apenas no suficiente para se ter um backlog com as entregas do projeto e que permita reavaliar prioridades e fazer mudanças.

Agora que você conhece alguns métodos de desenvolvimento existentes, me responda: seguiria por uma abordagem tradicional ou ágil? E, se trabalha em alguma equipe de desenvolvimento, qual método utiliza? É algum dos que discuti nesses textos ou outro que não foi mencionado?

Nota da Editora:

Aproveito para lembrar a todos da #desafioredatoresdeviante, pelo twitter ou pelo e-mail [email protected], para enviar perguntas para os redatores do Portal responderem!