Ágil

Diga-me, por quantos anos consecutivos você não cumpriu as suas promessas de Ano Novo e os planos de longo prazo para o próximo ano? Os planos em longo prazo são apenas um meio para os seres humanos se sentirem menos incomodados com o desconhecido. Nós temos a sensação de que temos controle sobre coisas quando temos um plano de longo prazo.

O ponto é que, de repente, no dia 15 de janeiro, quando você acha que está no controle da sua vida, você recebe um e-mail com uma oferta de emprego pagando duas vezes mais do que seu emprego atual ou simplesmente é demitido.

O que não percebemos imediatamente é que uma oferta de emprego pagando duas vezes mais às vezes não é boa (o trabalho e as pessoas são chatas, não se importam com as melhores práticas de desenvolvimento, o ambiente não incentiva a comunicação, e assim por diante) e às vezes ser demitido não é ruim (seu próximo trabalho pode ser muito melhor). Isso acontece porque os seres humanos tendem a reagir sem pensar primeiro. Muitas vezes, nós nos sentimos gratos por algo que inicialmente achamos que seria ruim.

No contexto do desenvolvimento de software, o mesmo acontece quando o cliente pede uma mudança em algo que já foi entregue ou que está sendo desenvolvido. Às vezes, nossa primeira reação é ficar chateado e pensar “por que eles não pensaram nisso antes de perguntar? Esses caras não sabem o que querem!”.

No entanto, depois de um tempo, percebemos que a mudança é realmente o melhor e aumentará muito o valor para todo o produto; o cliente ficará mais satisfeito, e os usuários finais se beneficiarão. O segundo princípio ágil afirma: Receba bem os requisitos de mudança, mesmo tarde no desenvolvimento. Os processos ágeis aproveitam a mudança para a vantagem competitiva do cliente.

Agile não é sobre ser mais rápido. Trata-se de ser capaz de se adaptar bem a novas situações. Imagine que você está em um prédio em chamas. Você pode ser muito rápido e escapar dele jogando-se da janela, ou você pode encontrar a saída de incêndio e escapar por ela em segurança. A opção um é mais rápida, a opção dois é ágil.

As metodologias ágeis para o desenvolvimento de software, como Scrum e Extreme Programming, são baseadas no Manifesto Ágil, que afirma o seguinte:

1. Indivíduos e interações sobre processos e ferramentas
2. Software de trabalho sobre documentação abrangente
3. Colaboração do cliente em relação à negociação do contrato
4. Responder à mudança ao seguir um plano

Ou seja, enquanto houver valor nos itens à direita, valorizamos mais os itens da esquerda.

Além disso, vamos verificar os Doze Princípios do Software Ágil:

1. Nossa maior prioridade é satisfazer o cliente através da entrega precoce e contínua de software valioso.
2. Requisitos de mudança são bem-vindos, até mesmo em desenvolvimento. Os processos ágeis aproveitam a mudança para a vantagem competitiva do cliente.
3. Entregue software de trabalho com frequência, de algumas semanas a alguns meses, com uma preferência para o prazo mais curto.
4. Os empresários e os desenvolvedores devem trabalhar juntos todos os dias ao longo do projeto.
5. Construa projetos em torno de indivíduos motivados. Dê-lhes o ambiente e o suporte de que eles precisam, e confie neles para fazer o trabalho.
6. O método mais eficiente e eficaz de transmitir informações para dentro de uma equipe de desenvolvimento é uma conversa cara a cara.
7. O software de trabalho é a principal medida de progresso.
8. Os processos ágeis promovem o desenvolvimento sustentável. Os patrocinadores, os desenvolvedores e os usuários devem ser capazes de manter um ritmo constante indefinidamente.
9. A atenção contínua à excelência técnica e ao bom design aumenta a agilidade.
10. Simplicidade – a arte de maximizar a quantidade de trabalho não feito – é essencial.
11. As melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizadas.
12. Em intervalos regulares, a equipe reflete sobre como se tornar mais efetiva, então ajusta seu comportamento de forma apropriada.

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/