Ágil versus cascata

• A documentação e os requisitos detalhados do produto permitem que novos programadores façam a integração de forma rápida e fácil.
• A documentação fornece um escopo claro para o projeto, permitindo que os gerentes de projeto comuniquem orçamentos, cronogramas e marcos importantes às partes interessadas.

• Os clientes podem achar difícil delinear todos os seus requisitos no início do projeto, levando a lacunas na documentação.
• A colaboração mínima do cliente durante o processo de desenvolvimento pode levar a mudanças dispendiosas se o produto não atender às expectativas.
• Os testadores relatam problemas e bugs mais tarde no processo, o que poderia ter informado uma arquitetura alternativa de programa.

Em contraste com o desenvolvimento em cascata, o ágil é definido por sua abordagem iterativa ao gerenciamento de projetos. Em vez de elaborar requisitos longos do projeto no início, uma equipe ágil divide o produto em funcionalidades específicas e lida com cada um sob uma restrição de tempo específica, conhecida como sprint.

O gerenciamento ágil de projetos requer uma equipe multifuncional e auto-organizada, que normalmente consiste de cinco a nove membros. Juntos, eles desenvolvem um software viável durante cada sprint, que combina com outro código funcional de iterações anteriores. No final do tempo do sprint, a equipe demonstra seu trabalho aos stakeholders para feedback, permitindo que elas sejam flexíveis em sua abordagem ao desenvolvimento de software. Como a equipe tem acesso a feedback frequente, pode adaptar o roteiro do produto durante o ciclo de vida de desenvolvimento para garantir que a funcionalidade realmente atenda às expectativas do usuário. Na abordagem em cascata, o envolvimento do cliente normalmente coincide com a entrega do produto final, o que pode ser custoso quando os requisitos são mal interpretados ou documentados de forma incorreta.

Houve 17 indivíduos que acharam o sistema de gerenciamento de projetos em cascata altamente ineficaz e, em 2001, suas ideias sobre o processo de desenvolvimento de software culminaram em um trabalho conhecido como o “Manifesto Ágil”. Este documento destaca valores e princípios específicos a serem priorizados nos fluxos de trabalho de desenvolvimento de software e resultou em vários frameworks ágeis populares, como Scrum, Kanban, Desenvolvimento Dirigido por Funcionalidade (FDD) e Programação Extrema. Desde então, a popularidade do desenvolvimento de software ágil aumentou, especialmente quando comparado ao modelo de cascata.

Inspirado no jogo de rúgbi, o scrum ágil enfatiza o trabalho em equipe para cumprir as entregas, semelhante à maneira como os atacantes precisam trabalhar juntos em um scrum para obter a posse de uma bola de rúgbi. O conjunto de habilidades da equipe scrum ágil scrum varia, mas geralmente inclui as seguintes funções:

• Proprietário do produto:  esse membro da equipe representa as necessidades do cliente e da empresa. Ao criar histórias de usuários, a equipe pode entender como uma solicitação de funcionalidade pode ajudar a resolver um problema específico, e essas histórias formulam a lista de pendências de tarefas para a equipe resolver. Essa pessoa também prioriza as histórias de acordo com seu valor para o cliente, o que deve, em teoria, se traduzir em valor para o negócio. Embora o product owner lidere a equipe dessa forma, ele não define prazos ou instrui a equipe sobre como o trabalho deve ser entregue.
• Scrum master : este membro da equipe facilita o processo geral de desenvolvimento ágil. Semelhante a um gerente de projeto, essa pessoa mantém a equipe na tarefa, garantindo que a equipe permaneça focada durante o projeto. Eles também podem atuar como uma parte neutra para mediar desacordos entre os membros da equipe. Por exemplo, os membros da equipe podem discordar sobre quanto assumir em um determinado sprint. Os proprietários de produtos, em particular, podem pressionar as equipes a se comprometerem com mais do que podem entregar dentro de um determinado período de tempo. Nesses casos, os scrum masters podem lembrar os membros da equipe do escopo de sua função na equipe.

Os outros membros da equipe de uma equipe ágil podem variar, mas normalmente incluem usuários de uma variedade de disciplinas, como projeto, análise de dados, QA e desenvolvimento. Esses indivíduos colaboram para decidir quanto trabalho assumir e como vão completá-lo.

As metodologias ágeis também são definidas pelas formas pelas quais a equipe se reúne. Há reuniões específicas que ajudam a facilitar o fluxo de trabalho em toda a equipe. Algumas delas incluem o seguinte:

• Planejamento do sprint: durante essa reunião, a equipe se reúne para determinar quais histórias farão parte do sprint atual. O proprietário do produto priorizará as histórias de usuário, mas o resto da equipe precisará concordar sobre quantas e quais histórias de usuários eles podem concluir durante esse período de tempo definido.
• Standups diárias: essas breves reuniões também são conhecidas como reuniões diárias. Durante esses check-ins, cada membro da equipe comunica seu progresso individual, como tarefas concluídas, as próximas e quaisquer empecilhos ou dependências que possam resultar em atrasos.
• Demonstração: essa reunião apresenta o software funcional que a equipe concluiu ao longo do sprint, que pode variar entre incrementos de duas a quatro semanas. O proprietário do produto determinará se a história de um usuário atendeu à definição de "pronto". Caso contrário, o backlog do produto pode ser preparado para dar conta de qualquer coisa que esteja faltando. Essa também é uma oportunidade para a equipe apresentar aos stakeholders para feedback.
• Retrospectiva: esse tempo é reservado para a introspecção da equipe, onde a equipe identifica como poderia melhorar seu fluxo de trabalho para alcançar melhores resultados no futuro

• O design da equipe facilita mais colaboração.
• O desenvolvimento de produtos adota uma abordagem de projeto adaptativo.
• Como o código é testado a cada iteração na fase de desenvolvimento, os defeitos do código podem informar o projeto futuro do software.
• Tende a gerar maior satisfação do cliente, já que o feedback frequente leva a uma maior priorização das necessidades do cliente.
• Permite integração contínua, pois cada funcionalidade é seu próprio software viável.
• Esse tipo enxuto de desenvolvimento de software pode levar a custos mais baixos, pois há menos risco de desalinhamento entre clientes e produtos.

• Uma abordagem ágil pode não ter documentação abrangente. Isso dificulta a integração de novos desenvolvedores, cronogramas de projetos para stakeholders e fornecimento de estimativas de custos precisas.
• Pode ser difícil de escalar.

Embora as equipes de desenvolvimento tenham sido bem-sucedidas em qualquer uma das abordagens de gerenciamento de projetos, certamente há mais ímpeto em torno dos processos ágeis. Não é difícil entender o porquê quando observamos os benefícios que isso pode oferecer às empresas hoje. Embora haja uma série de ferramentas de gerenciamento de projetos que podem ajudar as equipes a acompanhar o progresso, a IBM também pode fornecer sistemas para permitir que os desenvolvedores codifiquem de forma mais ágil.