Scrum
O desenvolvimento de software de forma não iterativa é provavelmente a razão pela qual muitos projetos bons, com pessoas altamente qualificadas falharam nos últimos anos.
Como mencionei, o principal problema dessa abordagem é que quando você configura um plano de longo prazo e o segue estritamente, como o modelo Waterfall, você perde a capacidade de fazer mudanças e adaptar o produto ao que o cliente realmente precisa, o que a maioria das vezes passa a ser descoberto apenas durante a fase de desenvolvimento do projeto, e não nas primeiras conversações com o cliente.
Para evitar esse problema, a maneira atual recomendada para abordar a maioria dos projetos de software é por iterações, ou seja, períodos de tempo mais curtos (geralmente semanas) em que ocorre todo o processo (planejamento, desenvolvimento, testes, lançamento, feedback do cliente). Isso não só permite que o cliente comece a usar o software mais cedo (adicionando valor ao seu negócio), mas também oferece a oportunidade para ele fornecer feedback mais rápido, pedir alterações mais cedo, alterar as prioridades dos recursos, e assim por diante.
Um framework muito conhecido para o gerenciamento de software que implementa essa ideia é chamado de Scrum. Ele foi usado com sucesso ao longo de muitos anos em empresas em todo o mundo.
Claro que existem muitos outros fatores que influenciam o sucesso de um projeto de software, como a qualidade do código, o processo de lançamento, a arquitetura da aplicação, e assim por diante. O Scrum não define as melhores práticas de engenharia de software, ele trata de gerenciar o projeto de software.
Existe outra Metodologia Ágil chamada de Extreme Programming (XP) que aborda Pair Programming, Test Driven Development, Refactoring, Simple Design, Integração Contínua e outras práticas de engenharia de software. As equipes de desenvolvimento de software geralmente usam Scrum e XP juntas para aproveitar os dois mundos.
Faça o download da amostra gratuita do meu livro (Continuous Delivery for Java Apps: Build a CD Pipeline Step by Step Using Kubernetes, Docker, Vagrant, Jenkins, Spring, Maven, and Artifactory) para saber mais sobre Testes Automatizados (unidade, integração, aceitação e testes de desempenho), integração contínua, entrega contínua, deployment contínuo, Canary Release, Feature Branch, testes A/B, Feature Flag e muitos outros conceitos relevantes.
Os artefatos Scrum, são:
Backlog de produtos: uma lista de itens que representam a “lista de desejos” do cliente. Esses itens podem ser [histórias de usuários], correções de bugs, requisitos não funcionais, e assim por diante.
Sprint Backlog: uma lista de itens escolhidos no Sprint Planning a ser desenvolvido em um sprint específico.
Incremento de produto: a soma de todos os itens de backlog de produto concluídos durante um sprint, integrado ao trabalho de todos os sprints anteriores.
Uma Equipe Scrum consiste em:
Proprietário do produto: define e prioriza os itens que compõem o backlog de produtos, responde às questões comerciais que a equipe de desenvolvimento pode ter, etc.
Equipe de desenvolvimento: compõe as pessoas que são realmente técnicas, como desenvolvedores, administradores de sistemas, administradores de banco de dados, e assim por diante.
Scrum Master: remove os possíveis impedimentos que possam aparecer para a equipe de desenvolvimento durante a fase de desenvolvimento, facilita eventos Scrum, etc.
Em suma, o Scrum chama cada iteração como um Sprint. Um sprint deve sempre ter a mesma duração (pode variar de uma a quatro semanas) e é essencialmente composto por estes eventos (na ordem apresentada):
Daily Scrum: uma reunião rápida que acontece todos os dias para que os membros da equipe possam informar o que fizeram ontem, o que estão fazendo hoje e se eles têm algum impedimento.
Spring Planning: uma reunião que ocorre no início de cada sprint, onde a equipe de Scrum define quais itens do Spring Backlog devem ser desenvolvidos na fase de desenvolvimento. Basicamente, o proprietário do produto escolhe os itens mais prioritários e responde às dúvidas empresariais que surgem. Em seguida, os desenvolvedores estimam o esforço para desenvolver esses itens, opcionalmente usando o Planning Poker, e com base nos pontos médios, a equipe é usada para entregar em cada Sprint. O proprietário do produto decide se ele coloca alguns itens de volta ao seu backlog de produtos ou ele inclui mais itens no Sprint Backlog.
Sprint Review: uma reunião que envolve a equipe Scrum e qualquer stakeholder para revisar o trabalho que foi concluído e o trabalho planejado que não foi concluído juntamente com uma apresentação no trabalho concluído (por exemplo, uma demo). Também é um momento em que todos colaboram em relação ao que fazer em seguida, por isso fornece uma contribuição valiosa para o subsequente Planejamento de Sprint.
Retrospectiva Sprint: uma reunião em que a equipe Scrum discute o que foi bem no Sprint, o que poderia ser melhorado e o que eles se comprometerão a melhorar no próximo Sprint.
Este artigo deve dar uma visão geral sobre o Scrum, mas eu realmente o encorajarei a ler o Scrum Guide, que, por sinal, está disponível em vários idiomas gratuitamente.
***
Artigo traduzido com autorização do autor. Publicado originalmente em: https://www.linkedin.com/pulse/agile-scrum-overview-jorge-acetozi/
