Introdução
O desenvolvimento ágil de software refere-se a metodologias de desenvolvimento de software centradas na ideia de desenvolvimento iterativo, em que requisitos e soluções evoluem através da colaboração entre equipes multifuncionais auto-organizadas. O valor final no desenvolvimento Agile é que ele permite que as equipes agreguem valor mais rapidamente, com maior qualidade e previsibilidade, e maior aptidão para responder às mudanças. Scrum e Kanban são duas das metodologias Agile mais amplamente usadas. Mais abaixo estão cinco erros comuns na metodologia ágil.
O que é ágil?
O desenvolvimento ágil de software refere-se a um grupo de metodologias de desenvolvimento de software baseadas no desenvolvimento iterativo, em que requisitos e soluções evoluem através da colaboração entre equipes multifuncionais auto-organizadas. Métodos ágeis ou processos ágeis geralmente promovem um processo disciplinado de gerenciamento de projetos que incentiva a inspeção e adaptação frequentes, uma filosofia de liderança que incentiva o trabalho em equipe, a auto-organização e a responsabilidade, um conjunto de práticas recomendadas de engenharia destinadas a permitir a entrega rápida de software de alta qualidade, e uma abordagem de negócios que alinha o desenvolvimento às necessidades do cliente e aos objetivos da empresa. Desenvolvimento ágil refere-se a qualquer processo de desenvolvimento alinhado com os conceitos do Manifesto Ágil. O Manifesto foi desenvolvido por um grupo de catorze figuras de destaque na indústria de software e reflete sua experiência sobre quais abordagens funcionam e não funcionam no desenvolvimento de software. Leia mais sobre o Manifesto Ágil. Você sabia que o Agile também pode ser aplicado a quaisquer tipos de projetos? Aprenda sobre a revolucionária estrutura Agile com a FM2S.
Cinco erros comuns na metodologia ágil
À medida em que o Agile se torna mais popular, parece que o número de concepções errôneas em torno dele aumenta e não diminui. Em um esforço para resolver alguns dos erros comuns cometidos ao integrar o Agile em suas práticas diárias de trabalho, construímos este post, na esperança de que ele dê a você um pensamento. Aqui estão alguns dos erros mais comuns que eu vi como instrutor profissional de Scrum:
Erro 1: Pensar em fazer um scrum diário faz com que você seja ágil
Assim como ir à igreja uma ou duas vezes não o torna religioso, o simples fato de você estar realizando reuniões do Scrum não significa que agora você é ágil. O Daily Scrum é uma parte vital do Scrum, mas apenas mantê-lo para o efeito não ajuda ninguém. Para tirar o máximo proveito do Daily Scrum, é importante seguir os princípios básicos do evento, por mais difícil que pareça. O objetivo do Daily Scrum é que a equipe de desenvolvimento revise e planeje seu progresso em direção ao objetivo da sprint. É também um fórum para permitir identificar problemas em potencial e lidar com eles rapidamente ou posteriormente. Ele foi projetado para ser curto para resolver problemas e garantir (no mínimo) um nível contínuo de comunicação e planejamento da equipe de desenvolvimento à medida que o Sprint progride. Raramente é suficiente por si só e foi projetado para resolver as coisas que a equipe de desenvolvimento precisa para gastar mais tempo conversando e lidando com fora do Daily Scrum.
Erro 2: Pensar que um Scrum Master deve ser o gerente de projeto
Vamos examinar o papel de um Scrum Master por um momento. É esse papel talvez mais do que qualquer outro com o qual as pessoas lutam ao implementar o Scrum em suas práticas de trabalho. Algumas pessoas assumem que um Scrum Master é o mesmo que um gerente de projeto. Outros assumem o mesmo papel de desenvolvedor líder. Nem é preciso. Um Scrum Master provavelmente é um papel que você nunca viu antes. Isso não significa que um gerente de projeto não possa fazer o trabalho, mas certamente não é um fato consumado. Um Scrum Master é alguém que está lá para treinar e facilitar. Tecnicamente, eles não gerenciam a equipe. O Scrum Master oferece orientação e aconselhamento à equipe e ao proprietário do produto, especialmente em questões relacionadas à estrutura do Scrum. Você pode deixar sua equipe decidir quem deve ser o Scrum Master. Não precisa ser ninguém em particular.
Erro # 3: Tornando a equipe Scrum muito grande
Idealmente, uma equipe Scrum deve ser uma pequena unidade dedicada trabalhando de perto e se organizando. Para que isso aconteça, não pode ser muito grande ou pesado. Jeff Bezos (co-fundador da Amazon.com) postulou que a equipe ideal é do tamanho de duas pizzas - ou seja, apenas o número de pessoas que podem ser alimentadas por duas pizzas. Cabe a você determinar o nível de fome e, portanto, a extensão da pizza.
Erro # 4: Obtendo o Backlog Errado do Produto
O quarto dos cinco erros comuns na metodologia ágil está relacionado com o Backlog. Backlogs de produtos vêm de várias formas. A fase inicial de coleta de requisitos estabelece as bases para tudo o que se segue. Entenda isso errado e você poderá desviar todo o seu desenvolvimento. Se você estiver usando histórias de usuário, é melhor que elas sejam escritas pela pessoa mais próxima que você pode encontrar com o cliente. Muitas vezes, esse é o proprietário do produto, mas eles podem obter ajuda se a tarefa terminar. Como regra geral, procure as seguintes informações: Pessoa específica/ função que necessita um de novo recurso / problema que precisa ser tratado porque traz benefício específico para o consumidor + critérios de aceitação (usado para confirmar que um Item do Backlog do Produto foi concluído e funcionando conforme o planejado). Sem nenhum desses critérios, suas histórias de usuário estão incompletas e você deve pensar cuidadosamente antes de tentar iniciar o trabalho de desenvolvimento técnico nelas.
Erro nº 5: pensando que você não precisa documentar nada.
Sim, o manifesto Agile diz que valorizamos a funcionalidade concluída em vez de uma documentação abrangente, MAS não é o mesmo que supor que você não precisa documentar nada. Enquanto nos dias pré-ágeis, você provavelmente tinha que documentar tudo, desde requisitos e especificações técnicas até planos de teste (tudo além das medições internas das pernas), agora você só precisa documentar aquilo que é realmente valioso. Isso pode incluir seu código-fonte, por exemplo, e/ou um pequeno documento sobre sua arquitetura. Tudo o que você decidir documentar, lembre-se dos princípios do Agile e verifique se ele é útil para o produto de alguma forma. Se não for valioso, é provável que você não precise escrevê-lo. Este foi o quinto dos cinco erros comuns na metodologia ágil. Como observação final, deixe-me dizer o seguinte: sinta-se à vontade para rejeitar qualquer um dos conselhos acima (e quaisquer outras dicas que você receber) se não funcionar para você, sua equipe, seu cliente ou sua empresa. O Agile não é uma solução única para todos, por isso não pense que você precisa se envolver com os aspectos que não funcionam para você. Não tenha medo de jogar fora o livro (em vez de jogar a toalha) de vez em quando, se necessário. Um dos mais populares ramos do Agile é a metodologia Scrum. Acesse a nossa plataforma EAD e confira nosso curso Especialista Scrum.
