Quando um desenvolvedor de software ouve notícias sobre uma 'nova estrutura JavaScript' ou um 'novo IDE', ele não precisa fazer mais perguntas para esclarecer do que se trata. Mas se ele ouvir sobre uma 'nova estrutura ágil', ele provavelmente fará o aceno homero-simpsoniano, fingindo que sabe do que se trata, mas terá uma, e apenas uma, pergunta: O que diabos 'estrutura ágil' significa?

No ambiente de desenvolvimento de software moderno, cada vez mais ouvimos palavras como “ágil”, “scrum” e “kanban” e muitas vezes são usadas de forma inadequada. Neste artigo, tentarei explicar e esclarecer alguns desses termos.

Ágil

Se você quer ser o espertinho da multidão, deve usar a palavra “ágil” em todas as outras frases quando estiver falando sobre o processo de trabalho. Tem uma gama bastante ampla, não obriga você a saber muito sobre o assunto de que está falando e é um adjetivo ou advérbio muito bom: “pensamento ágil”, “abordagem ágil”, “de acordo com os princípios ágeis”. Mas o que “ágil” realmente significa?

“Agile” refere-se a “ desenvolvimento ágil de software , ”A abordagem de desenvolvimento que segue princípios ágeis. Mas o que diabos são 'princípios ágeis?' Dê uma olhada em o Manifesto Ágil e no 12 princípios de agile , que lançam as bases do desenvolvimento ágil. Do Manifesto:

Indivíduos e interações sobre processos e ferramentas
Software de trabalho sobre documentação abrangente
Colaboração do cliente sobre negociação de contrato
Respondendo à mudança sobre seguir um plano

Os princípios ágeis encorajam a entrega contínua de software funcional, comunicação próxima entre as equipes e alta adaptabilidade às necessidades em constante mudança. Se você seguir esses valores e princípios em seu trabalho, pode dizer que está trabalhando em um ambiente ágil. Portanto, o desenvolvimento ágil de software não é uma metodologia, é apenas um conjunto de diferentes metodologias, frameworks e técnicas que seguem os mesmos princípios. Pode-se dizer que “ágil” é uma estrutura para pensar e tomar decisões.

Agile é uma estrutura para pensar e tomar decisões.

Mas por que é tão importante seguir esses princípios em nosso trabalho?

O Manifesto e os princípios são o resultado da busca pelas melhores soluções que evoluíram ao longo das décadas em resposta aos desafios do desenvolvimento de software. Ao longo das décadas de 70, 80 e 90, diferentes desenvolvedores e equipes em todo o mundo experimentaram métodos de trabalho e abordagens para a solução de problemas, inventando diferentes estruturas e técnicas (como scrum e Extreme Programming) e até mesmo chegando ao mesmo ideias em paralelo. Finalmente, em fevereiro de 2001, dezessete desenvolvedores se reuniram e encontraram os denominadores comuns para todas essas ideias e experiências diversas. É assim que o manifesto foi criado.

O Manifesto Ágil é o resultado de diferentes experiências e soluções práticas que surgiram ao longo das décadas.

Scrum

Se você falar sobre métodos “ágeis” sem saber o que eles significam, você pode escorregar e dizer coisas que vão descobrir você na frente do interlocutor que conhece o assunto: “Scrum e outras metodologias ágeis”.

Scrum não é uma metodologia , embora todos nós já tenhamos ouvido isso ser chamado com mais frequência do que o número de assassinatos em A Guerra dos Tronos . O Scrum não dará uma resposta para todas as perguntas e não fornecerá o procedimento preciso para responder a cada situação que você enfrenta. E provavelmente como resultado dessa interpretação incorreta, a maioria das implementações do scrum também está errada: as equipes não obtêm valor. Isso resulta provavelmente na declaração mais tola sobre o scrum: 'Scrum não funciona.'

O que é scrum? O Guia Scrum define scrum como:

'Uma estrutura dentro da qual as pessoas podem resolver problemas adaptativos complexos, ao mesmo tempo que entregam produtos do mais alto valor possível de forma produtiva e criativa.'

Então é um estrutura , e como qualquer outra estrutura, pode ser, e regularmente é, usada da maneira errada. Usar o scrum de forma eficaz requer não apenas a adoção da estrutura definida pelo scrum, mas também um profundo entendimento e apreciação pelos princípios do Agile em toda a equipe.

Scrum consiste nas seguintes funções: Dono do Produto, Scrum Master, Equipe de Desenvolvimento.

Existem também quatro cerimônias de Scrum: Reunião de Planejamento, Daily Scrum, Revisão de Sprint, Retrospectiva de Sprint

E os três artefatos: Backlog do produto, Sprint Backlog, Incremento do produto.

Os projetos Scrum são organizados em intervalos de tempo regulares, que chamamos de sprints. Eles normalmente duram duas semanas.

PARA Proprietário do produto é responsável por orientar a direção do projeto. Conforme novas tarefas e recursos são determinados, o proprietário do processo os adiciona a uma lista de pendências do produto. Um sprint começa com uma reunião de planejamento onde a equipe de desenvolvimento seleciona as tarefas do backlog para trabalhar e planeja como elas serão implementadas. Em seguida, vem o desenvolvimento, durante o qual a equipe de desenvolvimento usa o backlog para acompanhar o andamento e se reúne para a reunião diária para sincronizar as atividades e ajustar o plano, se necessário. O resultado do desenvolvimento deve ser um incremento do produto, algo que pode ser aplicado ao produto e liberado imediatamente. No final do sprint, o incremento do produto é apresentado ao Product Owner na revisão do sprint, onde o backlog do produto é aumentado se outras mudanças forem necessárias. Em seguida, toda a equipe participa da retrospectiva do sprint onde falam sobre o processo de trabalho e como ele pode ser aprimorado.

É fácil aprender e entender o scrum, mas é difícil de adotar. Há muitos motivos pelos quais essa estrutura pode ou não ser adequada para um projeto. Freqüentemente, requer muitas mudanças, não apenas no desenvolvimento diário, mas também culturalmente. Scrum se adapta melhor ao desenvolvimento de produtos complexos, aqueles que duram muito tempo e que incluem diferentes tipos de especialistas.

Por que o scrum é tão popular e por que ele tem uma vantagem sobre o modelo tradicional em cascata? Simplificando, porque agrega mais valor a um produto e aos clientes. Com métodos “pesados” como a cascata, abundam as histórias de terror nas quais ninguém vê nada do projeto durante meses. Com o scrum, isso não é possível.

Scrum tem tudo a ver com valor que é entregue aos usuários finais. Se você realmente utiliza o scrum, precisa entregar algo de valor a cada sprint. O valor pode ser medido, e a equipe também é forçada a inspecionar impedimentos e se adaptar, com o objetivo de entregar mais valor na próxima iteração.

Na maior parte do desenvolvimento de software, não estamos construindo um arranha-céu; não precisamos ter todo o plano pronto antes de começar e segui-lo até o fim. Estamos desenvolvendo software e temos a capacidade de nos adaptar a diferentes situações e de alterar os requisitos do produto durante o desenvolvimento. Por muito tempo, muitos desenvolvedores viram isso como o oitavo pecado mortal, mas da perspectiva do produto é um grande benefício para otimizar a previsibilidade e controlar o risco. Scrum é desenvolvido em torno desta habilidade, e sua implementação oferece uma maneira confiável e eficiente de lidar com as mudanças necessárias.

Muitas técnicas são usadas em conjunto com o scrum: planning poker, pair programming, test-driven development (TDD), desenvolvimento orientado por comportamento (BDD) e outros. Eles não fazem realmente parte do scrum, mas sim de técnicas compatíveis. Um método frequentemente mencionado ao mesmo tempo que o scrum é o kanban, e há muita confusão sobre o que essas duas coisas significam em relação uma à outra.

Kanban

Quando você fala sobre scrum e kanban, uma pergunta frequente da multidão será: 'Qual é melhor, scrum ou kanban?' E você não saberá o que responder porque é como comparar maçãs e laranjas ou perguntar: 'Qual é melhor, panquecas ou cerveja?' Ambos são melhores.

Kanban é um método simples que visa a entrega just-in-time, sem sobrecarregar os membros da equipe. É semelhante ao scrum no sentido de que o objetivo é entregar o valor máximo no final, mas é muito mais flexível do que o scrum.

Kanban não foi inventado pela comunidade de desenvolvimento de software. Na verdade, ele tem sua origem nos processos de fabricação da Toyota e é amplamente utilizado em outras esferas. Não há procedimentos estritos que você deva seguir, e nenhuma maneira estrita de implementar e usar o kanban; é, sim, um conjunto de princípios e práticas, e você pode escolher entre essas práticas para atender às suas necessidades. Mas há uma implementação de kanban usada com mais frequência no desenvolvimento de software que inclui o uso de um quadro kanban , consistindo em colunas que representam estágios de trabalho e tarefas.

As colunas representam o estado de uma tarefa no processo de desenvolvimento. O exemplo mais simples consiste em três colunas: 'Tarefas', 'Em andamento' e 'Concluído'. Portanto, as tarefas são adicionadas a “To Do”, movidas para “In Progress” quando o desenvolvimento começa e consideradas “Concluídas” quando movidas para a última coluna. Mas, claro, pode ser mais complexo:

Backlog → Definindo especificação → Pronto para desenvolvimento → Desenvolvimento → Revisão de código → Teste → Implantado (→ Ninguém realmente usa → Removido completamente).

Cada coluna pode ter subcolunas; por exemplo, “Desenvolvimento” pode ser dividido em “Planejamento” e “Codificação”; “Teste” pode ser dividido em “Teste de unidade” e “Teste de integração” e assim por diante. As colunas podem ser dedicadas a especialistas, se apropriado. A equipe define as colunas e etapas de acordo com suas necessidades. De acordo com a filosofia “puxar”, as tarefas só devem entrar no fluxo de trabalho quando a demanda por elas for imediata.

O objetivo deste conselho é visualize o fluxo de trabalho , que é a primeira prática-chave no kanban. Na verdade, o kanban pode ser feito sem placa alguma! Pode ser uma simples lista de tarefas em uma planilha do Google com diferentes cores de fundo indicando o estado da tarefa, ou pode ser gráficos de Gantt, diagramas, tabelas ... Pode até ser um conjunto de baldes em seu escritório, onde cada um representa o estado da tarefa e onde as bolas são usadas como tarefas. Basta visualizar o workflow e dar transparência a todo o processo.

Outro princípio importante é reduza o tamanho do lote de seus esforços . Simplificado, isso significa evitar multitarefa. Isso pode significar reduzir o volume de tarefas nas quais você trabalha ao mesmo tempo. Se você tiver três designers em uma equipe, a equipe pode definir o número máximo de tarefas na coluna “Projetando” para três.

Assim como o scrum, o kanban também vê a equipe como a figura mais importante no processo. Mas não sugere funções como o scrum, e você pode manter as funções existentes para evitar fazer alterações em seu processo existente. O mesmo significa melhoria contínua: Kanban geralmente encoraja você a aprender e melhorar continuamente, mas não prescreve um evento específico apenas para aquele processo, como faz a Retrospectiva Sprint do scrum.

Qual devo usar?

Scrum e kanban não são mutuamente exclusivos e não são realmente comparáveis. No scrum, existem funções definidas, enquanto o kanban diz: 'Que diabos, mantenha suas funções e responsabilidades atuais.' Scrum o forçará a mudar sua maneira de trabalhar; O kanban permite que você comece com o processo existente. No scrum, uma programação clara para eventos é prescrita pela estrutura; no kanban você não tem eventos. No entanto, eles têm muitas semelhanças: ambos são centrados em valores, os membros da equipe são respeitados como “chefes” do sistema e, essencialmente, têm a mesma missão: eliminar continuamente o desperdício e remover obstáculos.

Mas a pergunta: “O que devo usar em meu projeto específico e com minha equipe específica?” faz muito mais sentido. Kanban não exige tanto do processo e mudanças culturais e, na maioria dos casos, será mais fácil de adotar do que o scrum. O Scrum, por outro lado, oferece muito mais estrutura para orientar o processo, o que pode eliminar uma grande quantidade de overhead, desde que todos estejam na mesma página.

Mas a beleza de ambos é que nenhum dos dois é um conjunto estrito de regras. Não há nada que o impeça de selecionar e escolher os melhores elementos do scrum para você, como uma reunião diária ou revisão. E não há nenhuma razão pela qual você não pode incorporar um quadro kanban ao scrum.

Scrum provou ser um framework altamente eficaz quando toda a equipe o entende bem. No entanto, em minha experiência, acho difícil trabalhar em scrum com alguns clientes. O processo e as mudanças culturais necessárias para a implementação adequada do scrum podem ser excessivos (especialmente ao lidar com alguém que acredita estar fazendo um novo Google!). Por outro lado, o kanban é mais flexível e não força as pessoas a mudar. Alguns autores também dizem que o kanban é um bom caminho para a agilidade e oferece uma implementação mais fácil do scrum. Outros dizem que o uso de scrum deve levar ao kanban no final.

A verdade é que cada projeto é diferente e não existe uma solução única para todos. Como gerente de projeto, cabe a você determinar o que funciona melhor para sua equipe.