Metodologias de desenvolvimento de software

Olá. Nas duas últimas entrevistas fui questionado sobre metodologias. Esta não é a pergunta mais importante ou difícil, mas seria bom ter uma folha de dicas para a resposta. Neste artigo tentarei dar uma ideia do que é uma metodologia de desenvolvimento e comparar aquelas que conheci pessoalmente ou sobre as quais fui questionado. A metodologia de desenvolvimento de software é um processo de descrição de como um produto específico será desenvolvido, ou seja, uma das formas de organizar o desenvolvimento da equipe. Existem muitos modelos diferentes desse processo, cada um dos quais descreve sua abordagem, e não se pode dizer que entre eles haja um que precise ser utilizado em cada projeto, tudo é puramente situacional. Proponho considerar três deles com mais detalhes.

Cachoeira

Cascata (cascata, cachoeira) é uma das metodologias mais antigas e implica a execução sequencial estrita de todas as etapas, cada uma das quais deve ser concluída antes do início da próxima. Ou seja, a transição para a próxima etapa significa a conclusão completa dos trabalhos da anterior. A imagem mostra que primeiro analisamos a tarefa (documentamos as tarefas, discutimos as dificuldades), depois ocorre o design (nesta fase a estrutura do projeto é formada), depois a codificação e o teste. Não há reembolso para etapas subsequentes. Recomenda-se a utilização de tal sistema em pequenos projetos onde os requisitos são conhecidos antecipadamente e há pouca probabilidade de que mudem. Vantagens:

• Documentação completa e consistente em todas as etapas;
• Fácil de usar;
• Requisitos estáveis.
• Orçamento e prazos são pré-determinados

Imperfeições:

• Grande quantidade de documentação;
• Não é um sistema muito flexível;
• O cliente não pode visualizar a versão demo do produto;
• Não há como voltar um passo.

Scrum

Scrum é um sistema de desenvolvimento de software baseado na divisão de todo o processo em iterações, onde ao final de cada uma delas a equipe está pronta para fornecer uma versão demo do produto. A imagem mostra que a equipe passa por todas as etapas de desenvolvimento em paralelo, o que nos permite ter uma parte finalizada do projeto ao final de cada iteração. Tentarei explicar brevemente em palavras simples a essência da metodologia, mas há muitos termos aqui. Acho que o mais importante é entender a essência, e os termos serão lembrados com a experiência. Todo o desenvolvimento é dividido em sprints (geralmente de 2 a 3 semanas). Existe um backlog (lista de tarefas) para todo o período de desenvolvimento e para cada sprint separadamente. Cada tarefa tem seu próprio ponto de história (classificação de dificuldade). Cada participante do processo tem uma função:

• Uma equipe Scrum é uma equipe que trabalha em um projeto (desenvolvedores, testadores, designers).
• Um Scrum Master é uma pessoa que garante que os princípios do Scrum sejam seguidos.
• Dono do produto – cliente.

Como neste sistema a ênfase está na comunicação, há um grande número de comícios:

• Stand-up é uma reunião curta, realizada todos os dias, onde todos os membros da equipe participam e cada participante responde a 3 perguntas: o que você fez? O que isso fará? E quais são os bloqueadores?
• Planejamento – realizado no início do sprint e nesta reunião são determinadas quais tarefas devem ser concluídas no próximo sprint.
• A retrospectiva é realizada ao final do sprint e sua essência é descobrir o que foi bem feito e o que pode ser melhorado.

Vantagens:

• O cliente pode observar o resultado durante o processo de desenvolvimento.
• Controle diário sobre o processo de desenvolvimento.
• Capacidade de fazer ajustes durante o desenvolvimento.
• Comunicações bem estabelecidas com todos os membros da equipe.
• Pequena quantidade de documentação.

Imperfeições:

• É difícil estimar a mão de obra e o custo necessários para o desenvolvimento
• É difícil determinar os maiores gargalos antes do início do desenvolvimento.
• A necessidade de envolver todos no desenvolvimento dos demais membros da equipe.

Kanban

Kanban é um sistema baseado na visualização do processo de conclusão de tarefas da equipe. A ideia principal deste sistema é reduzir o número de tarefas em andamento (na coluna “em andamento”). No Scrum, a equipe está focada em concluir os sprints com sucesso; no Kanban, as tarefas vêm em primeiro lugar. Bom para projetos que estão em fase de suporte, onde as funcionalidades principais já foram desenvolvidas e restam melhorias mínimas e correção de bugs. No Kanban, as tarefas são enviadas individualmente. A tarefa, independente de outras tarefas, passa por todas as etapas do quadro e assim que concluída pode ser mostrada ao cliente. Um quadro Kanban consiste em colunas, cada uma representando um processo de desenvolvimento separado. Algumas colunas (por exemplo, em andamento) impõem restrições ao número de tarefas que podem estar presentes. Isso ajuda a encontrar áreas problemáticas na distribuição de tarefas de maneira fácil e rápida. A imagem mostra um exemplo de um quadro tão simples. O número de colunas e nomes podem variar, mas vou citar os mais comuns:

• To do – uma lista de tarefas que precisam ser feitas
• Em andamento – tarefas que estão sendo trabalhadas atualmente
• Revisão de código – tarefas que foram concluídas e enviadas para revisão
• Em teste – tarefas prontas para teste
• Concluído – tarefas concluídas.

Vantagens:

• Fácil de usar.
• Visualização (ajuda a encontrar gargalos, simplifica a compreensão)
• Alto envolvimento da equipe no próprio processo.
• Alta flexibilidade no desenvolvimento.

Imperfeições:

• Lista de tarefas instável.
• Difícil de usar em projetos de longo prazo.
• Sem prazos rígidos.

Concluindo sobre a metodologia de desenvolvimento de software

Na minha opinião, as pessoas que ocupam cargos de gestão ou aspiram a eles precisam ter um conhecimento profundo das metodologias de desenvolvimento de software, mas é aconselhável que todos entendam pelo menos o básico. Isso é parte integrante do processo de desenvolvimento e não é usado apenas na área de TI. Obrigado por reservar um tempo para ler meu artigo, espero que você tenha achado útil. Tentei descrever apenas os pontos-chave da forma mais clara e resumida possível, para que o artigo não seja exaustivo. Ficarei feliz em ouvir sua opinião sobre isso e responder suas perguntas. Tudo de bom!