Qual é a diferença? Agile vs Scrum vs Waterfall vs Kanban

Ao longo de um projeto, você tomará centenas de decisões. E uma das primeiras decisões que você tomará é escolher qual metodologia de gerenciamento de projeto seguir.

Do Agile a Scrum, de Waterfall a Kanban, existem várias estruturas diferentes de gerenciamento de projetos. Alguns, como Scrum, seguem uma metodologia mais rígida e estruturada. Outros, como Kanban, são mais fáceis de apresentar e implementar em cima de processos existentes. Todos eles têm prós e contras, então como você sabe qual escolher?

Este artigo abordará as diferenças entre Agile vs Scrum vs Waterfall vs Kanban. Falaremos sobre as vantagens, desvantagens, estágios e quando você deve usar cada uma delas.

Metodologia Agile

O que é Agile?

O desenvolvimento de software Agile é baseado em uma abordagem incremental e iterativa. Em vez de um planejamento aprofundado no início do projeto, as metodologias do Agile estão abertas a mudanças de requisitos ao longo do tempo e incentivam feedback constante dos usuários finais. Equipes interfuncionais trabalham em iterações de um produto ao longo de um período, e este trabalho é organizado em um backlog que é priorizado com base no valor da empresa ou do cliente. O objetivo de cada iteração é produzir um produto de trabalho.

Nas metodologias Agile, a liderança incentiva o trabalho em equipe, a prestação de contas e a comunicação presencial. As partes interessadas no negócio e os desenvolvedores devem trabalhar juntos para alinhar o produto com as necessidades do cliente e as metas da empresa.

Agile se refere a qualquer processo alinhado aos conceitos do Manifesto Agile. Em fevereiro de 2001, 17 desenvolvedores de software se reuniram em Utah para discutir métodos de desenvolvimento mais leves. Eles publicaram o Manifesto para o Desenvolvimento de Software Agile, que cobriu como eles encontraram "melhores maneiras de desenvolver software fazendo isso e ajudando os outros a fazê-lo" e incluíram quatro valores e 12 princípios. O Manifesto Agile é um contraste dramática com o texto tradicional A Guide to the Project Management Body of Knowledge (PMBOK^® Guide) e padrões.

12 Princípios da Metodologia Agile

O Manifesto Agile lista 12 princípios para orientar as equipes sobre como se desempenhar com agilidade. Estes são os princípios:

Nossa maior prioridade é satisfazer o cliente através da entrega antecipada e contínua de software valioso.
Acolha os requisitos em mudança, mesmo tarde no desenvolvimento. Processos ágeis aproveitam as mudanças para obter a vantagem competitiva do cliente.
Forneça software em funcionamento com frequência, de algumas semanas a alguns meses, com preferência pela escala de tempo mais curta.
Os empresários e desenvolvedores devem trabalhar juntos diariamente durante todo o projeto.
Construa projetos ao redor de indivíduos motivados. Dê a eles o ambiente e o apoio necessários e confie neles para que o trabalho seja realizado.
O método mais eficiente e eficaz de transmitir informações de e para uma equipe de desenvolvimento é a conversa presencial.
Software em funcionamento é a principal medida de progresso.
Processos ágeis promovem o desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente.
A atenção contínua à excelência técnica e ao bom design aumenta a agilidade.
Simplicidade - a arte de maximizar a quantidade de trabalho não feito - é essencial.
As melhores arquiteturas, requisitos e design emergem de equipes auto-organizadas.
Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz, depois ajusta e ajusta seu comportamento de acordo.

Vantagens do Agile

Agile evoluiu a partir de diferentes abordagens de software leve na década de 1990 e é uma resposta ao desagrado por parte de alguns gerentes de projeto sobre a metodologia rígida e inflexível de Waterfall. Ele se concentra na flexibilidade, na melhoria contínua e na velocidade.

Aqui estão algumas das principais vantagens do Agile:

A mudança é acolhida: Com ciclos de planejamento mais curtos, é fácil acomodar e aceitar mudanças a qualquer momento durante o projeto. Há sempre uma oportunidade de refinar e repriorizar o backlog, permitindo que as equipes apresentem mudanças no projeto em questão de semanas.
A meta final pode ser desconhecida: Agile é muito útil para projetos em que o objetivo final não é claramente definido. À medida que o projeto avança, as metas virão à tona e o desenvolvimento pode se adaptar facilmente a esses requisitos em evolução.
Entrega mais rápida e de alta qualidade: Dividir o projeto em iterações (unidades gerenciáveis) permite que a equipe se concentre em desenvolvimento, teste e colaboração de alta qualidade. Realizar testes durante cada iteração significa que os bugs são identificados e resolvidos mais rapidamente. E este software de alta qualidade pode ser entregue mais rapidamente com iterações consistentes e sucessivas.
Forte interação com a equipe: O Agile destaca a importância da comunicação frequente e interações presenciais. As equipes trabalham juntas e as pessoas podem assumir a responsabilidade e a propriedade de partes dos projetos.
Clientes são ouvidos: Os clientes têm muitas oportunidades para ver o trabalho sendo entregue, compartilhar sua entrada e ter um impacto real no produto final. Eles podem ter um senso de propriedade trabalhando tão de perto com a equipe de projeto.
Melhoria contínua: Projetos ágeis incentivam o feedback dos usuários e membros da equipe durante todo o projeto, para que as lições aprendidas sejam usadas para melhorar as iterações futuras.

Dicas e práticas recomendadas para seu próximo projeto usando a metodologia Agile.

Desvantagens do Agile

Embora o nível de flexibilidade no Agile seja geralmente positivo, ele também vem com algumas compensações. Pode ser difícil estabelecer uma data de entrega sólida, a documentação pode ser negligenciada ou o produto final pode ser muito diferente do planejado originalmente.

Eis algumas das desvantagens do Agile:

O planejamento pode ser menos concreto: Às vezes, pode ser difícil determinar uma data de entrega sólida. Como o Agile é baseado em entregas dentro do prazo e gerentes de projeto geralmente repriorizam tarefas, é possível que alguns itens programados originalmente para entrega não sejam concluídos a tempo. E sprints adicionais podem ser adicionados a qualquer momento do projeto, somando-se ao cronograma geral.
A equipe deve ter conhecimento: As equipes Agile geralmente são pequenas, portanto, os membros da equipe devem ser altamente habilidosos em várias áreas. Eles também devem entender e se sentir confortáveis com a metodologia Agile escolhida.
Compromisso de tempo dos desenvolvedores: Agile é o mais bem sucedido quando a equipe de desenvolvimento se dedica completamente ao projeto. O envolvimento ativo e a colaboração são necessários em todo o processo Agile, o que é mais demorado do que uma abordagem tradicional. Isso também significa que os desenvolvedores precisam se comprometer com toda a duração do projeto.
A documentação pode ser negligenciada: O Manifesto Agile prefere software de trabalho em vez de documentação abrangente, portanto, alguns membros da equipe podem se sentir menos importantes em focar na documentação. Embora a documentação abrangente por si só não leve ao sucesso do projeto, as equipes do Agile devem encontrar o equilíbrio certo entre documentação e discussão.
O produto final pode ser muito diferente: O projeto Agile inicial pode não ter um plano definitivo, então o produto final pode ser muito diferente do que o planejado inicialmente. Como o Agile é tão flexível, novas iterações podem ser adicionadas com base na evolução do feedback do cliente, o que pode levar a uma entrega final muito diferente.

O Ciclo de Desenvolvimento Agile

Eis as fases do ciclo de desenvolvimento do Agile. É importante observar que estas fases não devem acontecer sucessão; eles são flexíveis e estão sempre evoluindo. Muitas dessas fases acontecem em paralelo.

Planejamento: Quando uma ideia é considerada viável e inviável, a equipe do projeto se reúne e trabalha para identificar funções. O objetivo desta fase é dividir a ideia em pedaços menores de trabalho (os recursos) e priorizar cada recurso e atribuí-la a uma iteração.
Análise de requisitos: Esta fase envolve muitas reuniões com gerentes, partes interessadas e usuários para identificar os requisitos da empresa. A equipe precisa coletar informações como quem usará o produto e como o usará. Esses requisitos devem ser quantificados, relevantes e detalhados.
Design: O design do sistema e do software é preparado a partir dos requisitos identificados na fase anterior. A equipe precisa pensar em como será o produto ou a solução. A equipe de teste também tem uma estratégia de teste ou um plano para prosseguir.
Implementação, codificação ou desenvolvimento: Esta fase é toda sobre a criação e teste de recursos e o agendamento de iterações para implementação (seguindo a abordagem iterativa e incremental de desenvolvimento [IID]). A fase de desenvolvimento começa com a iteração 0, pois não há funções sendo entregues. Essa iteração estabelece as bases para o desenvolvimento, com tarefas como a finalização de contratos, a preparação dos ambientes e o financiamento.
de produtos: Depois que o código é desenvolvido, ele é testado de acordo com os requisitos para garantir que o produto esteja realmente resolvendo as necessidades do cliente e combinando histórias de usuários. Durante esta fase, testes unitários, testes de integração, testes de sistema e testes de aceitação são realizados.
Implantação: Após os testes, o produto é entregue aos clientes para que eles usem. No entanto, a implementação não é o fim do projeto. Uma vez que os clientes começam a usar o produto, eles podem encontrar novos problemas que a equipe de projeto precisará resolver.

Metodologias usadas para implementar o Agile

Agile é uma estrutura e existem vários métodos específicos no movimento Agile. Você pode pensar nisso como diferentes sabor do Agile:

Programação Extrema (XP): Também conhecido como XP, Extreme Programming é um tipo de desenvolvimento de software destinado a melhorar a qualidade e a resposta aos requisitos do cliente em constante evolução. Os princípios da XP incluem feedback, supondo simplicidade e adotar mudanças.
Desenvolvimento baseado em recursos (FDD): Este processo iterativo e incremental de desenvolvimento de software mistura as melhores práticas da indústria em uma abordagem. Existem cinco atividades básicas em FDD: desenvolva o modelo geral, crie uma lista de recursos, planeje por função, design por recurso e construa por função.
Desenvolvimento de sistema adaptativo (ASD): O desenvolvimento de sistemas adaptativos representa a ideia de que os projetos devem estar sempre em estado de adaptação contínua. O ASD tem um ciclo de três séries repetitivas: especular, colaborar e aprender.
Método de desenvolvimento de sistemas dinâmicos (DSDM): Esta estrutura de entrega de projetos Agile é usada para o desenvolvimento de software e soluções que não são de TI. Ele aborda as falhas comuns de projetos de TI, como passar por cima do orçamento, faltar prazos e falta de envolvimento do usuário. Os oito princípios do DSDM são: foque na necessidade de negócios, cumpra o prazo, colabore, nunca comprometa a qualidade, construa incrementalmente a partir de bases firmes, desenvolva iterativamente, comunique-se de forma contínua e clara e demonstrou controle.
Desenvolvimento de software lean (LSD): O Lean Software Development adota os princípios de manufatura lean e lean de TI e os aplica ao desenvolvimento de software. Ela pode ser caracterizada por sete princípios: elimine o desperdício, amplificar o aprendizado, decidir o mais tarde possível, entregar o mais rápido possível, capacitar a equipe, construir integridade e ver o todo.
Kanban: Kanban, que significa "sinal visual" ou "cartão" em japonês, é uma estrutura visual para implementar o Agile. Ele promove pequenas mudanças contínuas no seu sistema atual. Seus princípios incluem: visualize o fluxo de trabalho, limite o trabalho em andamento, gerencie e melhore o fluxo, explique as políticas e melhore continuamente.
Cristalina: Crystal Clear faz parte da família Crystal de metodologias. Ele pode ser usado com equipes de seis a oito desenvolvedores e se concentra nas pessoas, não em processos ou em artefatos. Crystal Clear requer o seguinte: entrega frequente de código utilizável aos usuários, melhorias refletivas e comunicação osmótica por serem co-localizados.
Scrum: O Scrum é uma das maneiras mais populares de implementar o Agile. É um modelo de software iterativo que segue um conjunto de funções, responsabilidades e reuniões que nunca mudam. Sprints, geralmente com duração de uma a duas semanas, permitem que a equipe forneça software regularmente.

Outras práticas no Agile

Existem muitas outras práticas e estruturas relacionadas ao Agile. Eles incluem:

Modelagem Ágil (AM): A modelagem Agile é usada para modelar e documentar sistemas de software e é um complemento a outras metodologias do Agile como Scrum, Extreme Programming (XP) e Rational Unified Process (RUP). AM não é um processo de software completo. Ele pode ajudar a melhorar os modelos com código, mas não inclui atividades de programação.
Processo Unificado Racional (RUP): Criada pela Rational Software Corporation, uma divisão da IBM, a RUP é uma estrutura iterativa e adaptativa para o desenvolvimento de software. De acordo com o Racionais, a RUP é uma mentora on-line que fornece diretrizes, modelos e exemplos para o desenvolvimento de programas. Os principais aspectos da RUP incluem um processo impulsionado pelo risco, o desenvolvimento focado em casos de uso e o design centrado em arquitetura.
Lean vs Agile: O desenvolvimento enxuto se concentra na eliminação e redução de resíduos (atividades que não agregam valor). O desenvolvimento enxuto tira os princípios da manufatura Lean e os aplica ao desenvolvimento de software. Esses princípios são muito semelhantes ao Agile, no entanto Lean leva um passo adiante. Na fase de desenvolvimento, você seleciona, planeja, desenvolve, testa e implanta apenas um recurso antes de repetir o processo para o próximo recurso.
Desenvolvimento baseado em teste (TDD): O desenvolvimento impulsionado por testes baseia-se em ciclos de desenvolvimento repetitivos e curtos. Primeiro, um desenvolvedor escreve um caso de teste automatizado (inicialmente falhando) para um novo recurso e rapidamente adiciona um teste com a quantidade mínima de código para passar nesse teste. Em seguida, ele reformula o novo código para padrões aceitáveis.
Estrutura Agile Em Escala (logotipo de marca registrada da SAFe): O Scaled Agile Framework é um método muito estruturado para ajudar grandes empresas a começar a adotar o Agile. A SAFe é baseada em princípios Lean e Agile e enfrenta problemas difíceis em grandes organizações, como arquitetura, integração, financiamento e funções em escala. O SAFe tem três níveis: equipe, programa e portfólio.
Desenvolvimento rápido de aplicativos (RAD): A abordagem da RAD para o desenvolvimento de software coloca mais ênfase no desenvolvimento do que em tarefas de planejamento. Segue um modelo incremental, onde cada componente é desenvolvido em paralelo. As fases no RAD são: modelo de negócios, modelagem de dados, modelagem de processos, geração de aplicativos e testes e volume de negócios.
Método de controle empírico: Com o desenvolvimento de software Agile, você pode usar um método de controle empírico, o que significa que você tomar decisões baseadas nas realidades que você observa no projeto real. O modelo empírico de controle do processo possui três partes: visibilidade, inspeção e adaptação.

Como estimar orçamentos no Agile

Sem um planejamento detalhado e indispensável, muitos gerentes de projeto não sabem como calcular o custo e o orçamento de um projeto Agile.

Estimar o custo antes mesmo de o projeto começar pode ser sempre um desafio, independentemente de qual metodologia de projeto você usa. No entanto, em um projeto Agile, você pode vincular a quantidade de tempo que o projeto levará com seu custo total.

Primeiro, crie um gráfico de burndown e use a taxa de burndown para estimar quantos sprints estarão em seu projeto e quando o projeto terminará. Então, calcule quanto a equipe custará com base em suas taxas horárias. Multiplique a taxa de cada pessoa pelo número de horas de trabalho por semana e, em seguida, multiplique-a pelo número de semanas em um sprint. Depois de estimar o orçamento inicial para sua equipe, você poderá adicionar outros custos, como tecnologia, viagens ou equipamentos.

Você também pode dividir a história de cada usuário em tarefas. Uma vez que você tenha uma idéia de quantas horas levará para concluir cada tarefa, você pode estimar o orçamento do projeto.

E por fim, você pode usar o planejamento poker para estimar o esforço necessário para as metas de desenvolvimento. O planejamento poker é uma técnica gamificada e baseada em consenso para estimar o esforço das metas de desenvolvimento. Cada membro da equipe faz estimativas jogando cartas numeradas de frente para baixo na tabela, em vez de dizer isso em voz alta. Os cartões são então revelados e as estimativas discutidas com toda a equipe.

Programação ágil e de pares

A programação de pares (também conhecida como "emparelhamento") faz parte das práticas de Programação Extrema (XP. É quando dois programadores compartilham uma única estação de trabalho, que inclui o compartilhamento de uma tela, teclado e mouse. O objetivo desta técnica é incentivar uma melhor comunicação, apurar o problema e a compreensão da solução. A combinação é frequentemente usada em projetos Agile para entregar rapidamente produtos de alta qualidade, mas é sempre necessário?

A resposta depende de seus programadores, empresa e objetivos. Para alguns projetos e programadores, a combinação pode melhorar a produtividade. No entanto, pode nem sempre ser apropriado para cada projeto. A melhor coisa a fazer é experimentar e ver se funciona para você.

Como Agile aborda requisitos de software

O Agile ajuda as equipes de desenvolvimento a focar nos requisitos mais importantes dos clientes o mais rápido possível. Com feedback contínuo e interações presenciais frequentes, a equipe de projeto e as partes interessadas entendem e priorizam os requisitos certos.

Equipes Agile usam backlogs com histórias de usuários para gerenciar requisitos. Antes de uma iteração começar, a equipe concorda sobre quais requisitos devem cumprir com a próxima entrega. Essa abordagem colaborativa garante que as funções mais importantes sejam priorizadas. E os requisitos são atualizados continuamente em todo o projeto à medida que novas informações são exibidas.

Você pode usar o Agile para projetos fora do software?

Embora o Agile tenha sido tradicionalmente criado para o desenvolvimento de software, ele também pode ser usado em muitos outros projetos e setores.

É importante lembrar que o desenvolvimento de software Agile nasceu dos princípios da manufatura Lean e do aprendizado organizacional. Essas idéias não eram baseadas em software para começar. E muitas práticas no Agile, como reuniões de stand-up e gerenciamento visual, são tão comuns e podem ser aplicadas a qualquer setor.

Não existem muitos estudos de caso de equipes usando Agile para coisas fora de software, mas há alguns. Por exemplo, Kate Sullivan, uma advogado corporativa da equipe jurídica do The Lonely Planet, transformou a prestação do serviço de assuntos jurídicos com o Agile. A equipe usa quadros e cartões, reuniões de stand-up matinal, priorização, iterações semanais e retrospectivas regulares.

Agile pode definitivamente ser aplicado a projetos fora do desenvolvimento de software, você só tem que encontrar o método e abordagem certos para suas necessidades. Você pode começar com conselhos e cartões, um backlog de trabalho, reuniões de stand-up ou iterações (reuniões semanais de planejamento) para ver como sua equipe responde.

Como começar a usar o Agile

Uma maneira simples de começar com o Agile é incorporando reuniões diárias de stand-up em seu projeto. Reuniões diárias de stand-up são fáceis de incorporar a qualquer outra metodologia de projeto que você já esteja usando (mesmo a Waterfall) e não exigem treinamentos ou transferência de conhecimento. Encontre-se no mesmo local todos os dias por cerca de dez minutos e faça com que todos falem sobre o que trabalharam no dia anterior, no que trabalharão hoje, e sobre quaisquer obstáculos.

Se você deseja fazer a mudança completa para Agile de uma só vez, talvez queira começar a entender por que a equipe e a organização querem fazer essa mudança. O que está e não está funcionando? O que eles estão procurando melhorar? Então, você poderia realizar uma avaliação agile, obtendo uma visão completa das pessoas, habilidades e tecnologias usadas.

Seja qual for a rota escolhida, lembre-se que o Agile é flexível de sua própria natureza. Não há uma maneira errada ou certa de começar com o Agile. Faça o que funcionar para você e sua equipe.

A exibição mais recente do Smartsheet, a Exibição de Cartões, oferece às equipes do Agile uma maneira mais visual de trabalhar, se comunicar e colaborar no Smartsheet. A Exibição de cartões permite concentrar a atenção com cartões ricos, dar perspectiva com exibições flexíveis, priorizar e ajustar o trabalho de maneira mais visual. Concentre a atenção com cartões visuais: Exiba informações em cartões incluindo campos personalizados, imagens e códigos de cores para concentrar melhor a atenção de sua equipe. Categorize os cartões em raias para organizar seu trabalho de forma mais visual.

Saiba mais sobre o Smartsheet para desenvolvimento de software

Metodologia Scrum

Vantagens do Scrum

Scrum é uma estrutura altamente prescritiva com funções e funções específicas. Embora possa ser muito a aprender, essas regras têm muitas vantagens. Os benefícios do Scrum incluem:

Mais transparência e visibilidade do projeto: Com reuniões diárias de stand-up, toda a equipe sabe quem está fazendo o que, eliminando muitos desentendimentos e confusões. Os problemas são identificados com antecedência, permitindo que a equipe os resolva antes que saiam do controle.
Maior responsabilidade da equipe: Não há nenhum gerente de projeto dizendo ao Scrum Team o que fazer e quando. Em vez disso, a equipe decide coletivamente que trabalho eles podem completar em cada sprint. Todos trabalham juntos e ajudam uns aos outros, melhorando a colaboração e capacitando cada membro da equipe a ser independente.
Alterações fáceis de acomodar: Com sprints curtos e feedback constante, é mais fácil lidar e acomodar alterações. Por exemplo, se a equipe descobrir uma nova história de usuário durante um sprint, ele poderá facilmente adicionar esse recurso ao próximo sprint durante a reunião de refinamento do backlog.
Maior redução de custos: A comunicação constante garante que a equipe esteja ciente de todos os problemas e mudanças assim que surgirem, ajudando a reduzir despesas e aumentar a qualidade. Por meio de recursos de codificação e teste em pequenas partes, há feedback contínuo e os erros podem ser corretos no início, antes que sejam muito caros para corrigir.

Desvantagens do Scrum

Embora o Scrum ofereça alguns benefícios concretos, também tem algumas desvantagens. O Scrum requer um alto nível de experiência e comprometimento da equipe e projetos pode estar em risco de fluência no escopo.

Eis as desvantagens do Scrum:

Risco de fluência do escopo: Alguns projetos Scrum podem ter fluência no escopo devido à falta de data de término específica. Sem uma data de conclusão, as partes interessadas podem ficar tentadas a continuar solicitando funcionalidades adicionais.
Equipe requer experiência e comprometimento: Com funções e responsabilidades definidas, a equipe precisa estar familiarizada com os princípios do Scrum para ter sucesso. Como não há funções definidas no Scrum Team (todos fazem de tudo), isso requer membros da equipe com experiência técnica. A equipe também precisa se comprometer com as reuniões diárias do Scrum e permanecer na equipe durante a duração do projeto.
O Scrum Master errado pode arruinar tudo: O Scrum Master é muito diferente de um gerente de projeto. O Scrum Master não tem autoridade sobre a equipe; ele ou ela precisa confiar na equipe que estão gerenciando e nunca dizer o que fazer. Se o Scrum Master tentar controlar a equipe, o projeto falhará.
Tarefas mal definidas podem levar a imprecisões: Os custos e cronogramas de projeto não serão precisos se as tarefas não estiverem bem definidas. Se as metas iniciais não forem claras, o planejamento se torna difícil e os sprints podem levar mais tempo do que o estimado originalmente.

Funções no Scrum

Existem três funções específicas no Scrum. São eles:

Proprietário do produto: O proprietário do produto Scrum tem a visão do que ele ou ela quer construir e transmite essa visão para a equipe. O proprietário do produto se concentra nas necessidades comerciais e de mercado, priorizando todo o trabalho que precisa ser feito. Ele ou ela constrói e gerencia o backlog, fornece orientação sobre quais recursos enviar a seguir e interage com a equipe e outras partes interessadas para garantir que todos entendam os itens no backlog do produto. O proprietário do produto não é um gerente de projeto. Em vez de gerenciar o status e o progresso, seu trabalho é motivar a equipe com um objetivo e uma visão.
Scrum Master: Muitas vezes considerado o treinador da equipe, o Scrum Master ajuda a equipe a fazer o seu melhor trabalho possível. Isso significa organizar reuniões, lidar com obstáculos e desafios e trabalhar com o proprietário do produto para garantir que o backlog do produto esteja pronto para o próximo sprint. O Scrum Master também garante que a equipe siga o processo do Scrum. Ele ou ela não tem autoridade sobre os membros da equipe, mas ele ou ela tem autoridade sobre o processo. Por exemplo, o Scrum Master não pode dizer a alguém o que fazer, mas pode propor uma nova cadência de sprint.
Equipe Scrum: A Equipe Scrum é composta de cinco a sete membros. Todos os membros do projeto trabalham juntos, ajudam uns aos outros e compartilham uma profunda sensação de camaradagem. Ao contrário das equipes tradicionais de desenvolvimento, não há funções distintas como programador, designer ou testador. Todos completam o conjunto de trabalho juntos. A Equipe Scrum é dona do plano para cada sprint; eles antecipam o quanto de trabalho podem concluir em cada iteração.

Etapas do Processo Scrum

Existe um conjunto específico de etapas inalteradas no fluxo scrum. Eles incluem:

Backlog do produto: O proprietário do produto e a Equipe Scrum se reúnem para priorizar os itens no backlog do produto (o trabalho no backlog do produto vem de histórias e requisitos do usuário). O backlog do produto não é uma lista de coisas a serem concluídas, mas sim uma lista de todas as funções desejadas para o produto. A equipe de desenvolvimento então puxa o trabalho do backlog do produto para concluído durante cada sprint.
Planejamento de Sprint: Antes de cada sprint, o Proprietário do produto apresenta os principais itens do backlog à equipe em uma reunião de planejamento de sprint. A equipe então escolhe qual trabalho eles podem concluir durante o sprint e move o trabalho do backlog do produto para o backlog de sprint (que é uma lista de tarefas a serem concluídas no sprint).
Refinação/preparação de backlog: Ao final de um sprint, a equipe e o proprietário do produto se encontram para garantir que o backlog esteja pronto para o próximo sprint. A equipe pode remover histórias de usuários que não são relevantes, criar novas histórias, repensar a prioridade das histórias ou dividir histórias de usuários em tarefas menores. O objetivo desta reunião de "preparação" é garantir que o backlog contenha apenas itens relevantes e detalhados e que atendam aos objetivos do projeto.
Reuniões diárias do Scrum: O Daily Scrum é uma reunião de stand-up de 15 minutos onde cada membro da equipe fala sobre seus objetivos e quaisquer problemas que surgiram. O Daily Scrum acontece todos os dias durante o sprint e ajuda a manter a equipe no caminho certo.
Reunião de revisão de sprint: Ao final de cada sprint, a equipe apresenta o trabalho que concluiu em uma reunião de revisão de sprint. Esta reunião deve apresentar uma demonstração ao vivo, não um relatório ou uma apresentação do PowerPoint.
Reunião retrospectiva de sprint: Também no final de cada sprint, a equipe reflete sobre o quão bem o Scrum está trabalhando para eles e fala sobre quaisquer mudanças que precisam ser feitas na próxima sprint. A equipe pode falar sobre o que foi bem durante o sprint, o que deu errado e o que eles poderiam fazer diferente.

Ferramentas, artefatos e métodos no Scrum

Além de funções e funções, os projetos do Scrum também incluem ferramentas e ferramentas específicas. Por exemplo, a equipe usa um quadro Scrum para visualizar o backlog ou um gráfico de burndown para mostrar um trabalho excepcional. Os artefatos e métodos mais comuns são:

Quadro scrum: Você pode visualizar seu backlog de sprint com um quadro de tarefas do Scrum. O quadro pode ter formulários diferentes; tradicionalmente, envolve cartões de índice, notas pós-ti ou um quadro branco. O quadro Scrum geralmente é dividido em três categorias: a fazer, trabalhar em andamento e feito. O Scrum Team precisa atualizar o quadro durante todo o sprint. Por exemplo, se alguém aparecesse com uma nova tarefa, ela escreveria um novo cartão e o colocaria na coluna apropriada.
Histórias de usuários: Uma história de usuário descreve um recurso de software na perspectiva do cliente. Ele inclui o tipo de usuário, o que ele quer e por que ele quer. Esses contos seguem uma estrutura semelhante: como um , Eu quero para que eu possa A equipe de desenvolvimento usa essas histórias para criar código que atenderá aos requisitos das histórias.
Gráfico de Burndown: Um gráfico de burndown representa todo o trabalho excepcional. O backlog geralmente está no eixo vertical, com o tempo ao longo do eixo horizontal. O trabalho restante pode ser representado por pontos da história, dias ideais, dias de equipe ou outras métricas. Um gráfico de burndown pode avisar a equipe se as coisas não estão indo de acordo com o plano e ajuda a mostrar o impacto das decisões.
Scrum em larga escala (Less): Se você deseja escalar elementos do Scrum para centenas de desenvolvedores, a estrutura scrum (LeSS) de grande escala ajuda a estender as regras e diretrizes sem perder o núcleo principal do Scrum. Os princípios são tirados diretamente do Scrum, no entanto, concentra-se em escalar sem adicionar despesas adicionais (como adicionar mais funções, artefatos ou processos).
Caixa de hora: Uma caixa de tempo é um período definido durante o qual uma equipe trabalha para completar uma meta. Em vez de deixar uma equipe trabalhar até que a meta seja atingida, a abordagem da caixa de tempo interrompe o trabalho quando o limite de tempo é atingido. Iterações com caixas de tempo são frequentemente usadas em Scrum e Programação Extrema.
Geladeira: Todas as histórias de usuário gravadas, mas não movidas para o desenvolvimento, são armazenadas na caixa de gelo.
O termo "icebox" foi criado pela Pivotal Tracker, uma ferramenta de gerenciamento de projetos Agile.
Scrum vs RUP: Enquanto o Scrum e o Processo Unificado Racional (RUP) seguem a estrutura do Agile, a RUP envolve uma definição mais formal de escopo, marcos importantes e datas específicas (O Scrum usa um backlog de projeto em vez de escopo). Além disso, a RUP envolve quatro fases importantes do ciclo de vida do projeto (início, concepção, construção e transição), enquanto Scrum determina que todo o "ciclo de vida tradicional" se encaixa em uma iteração.
Lean vs Scrum: Scrum é uma estrutura de desenvolvimento de software, enquanto Lean ajuda a otimizar esse processo. O principal objetivo do Scrum é com as pessoas, enquanto Lean se concentra no processo. Ambos são considerados técnicas Agile, mas Lean apresenta dois conceitos importantes: eliminando o desperdício e melhorando o fluxo.

Como começar a usar o Scrum

Trabalhar com Scrum com frequência significa mudar o hábito da equipe. Eles precisam assumir mais responsabilidade, aumentar a qualidade do código e aumentar a velocidade de entrega. Esse nível de comprometimento funciona como um agente de mudança; à medida que as equipes se comprometem a executar metas, elas estão cada vez mais motivadas para melhorar e mais rapidamente entregar um produto de qualidade.

Um bom lugar para começar com Scrum é falar sobre as funções. Todo projeto deve ter um Scrum Master, proprietário do produto e Equipe Scrum. Você pode querer falar sobre quem deve ser o Mestre e o Proprietário do Produto Scrum, ou se essas funções já estiverem atribuídas, talvez você queira esclareça suas funções e responsabilidades.

Dependendo do quão familiar sua equipe esteja com o Scrum, você também pode querer analisar as sessões de treinamento. Treinadores e treinadores Scrum certificados e provedores de educação registrados da Scrum Alliance podem ajudar sua equipe a aprender e adotar o Scrum.

Use a Exibição de cartões do Smartsheet durante sua próxima reunião do Scrum.

Saiba mais sobre o Smartsheet para desenvolvimento de software

Metodologia Waterfall

O que é Waterfall?

A metodologia Waterfall segue um processo sequencial e linear e é a versão mais popular do ciclo de vida do desenvolvimento de sistemas (SDLC) para projetos de engenharia de software e TI. Às vezes, é planejado usar um gráfico de Gantt, um tipo de gráfico de barras que mostra as datas de início e término de cada tarefa. Quando um dos oito estágios é concluído, a equipe de desenvolvimento passa para a etapa seguinte. A equipe não pode voltar a um estágio anterior sem iniciar todo o processo desde o início. E, antes que a equipe possa passar para a próxima etapa, os requisitos podem precisar ser revistos e aprovados pelo cliente.

O modelo Waterfall teve origem nas indústrias de manufatura e construção, ambos ambiente altamente estruturados, onde as mudanças podem ser muito caras ou às vezes impossível. A primeira descrição formal de Waterfall é atribuída a Winston W. Royce em um artigo de 1970 onde descreveu um modelo de software defeituoso.

Vantagens da Waterfall

Ele é melhor usado para projetos simples e imutá-los. Sua natureza inflexionável e rígida facilita o uso e permite a documentação detalhada.

As vantagens da Waterfall incluem:

Fácil de Usar e Aprender: Como o modelo de Waterfall segue o mesmo padrão sequencial para cada projeto, é fácil de usar e entender. A equipe não precisa de conhecimentos ou treinamentos prévios antes de trabalhar em um projeto de Waterfall. A Waterfall também é um modelo rígido; cada fase possui produtos e revisões específicos, por isso é fácil gerenciar e controlar.
A disciplina é aplicada: Toda fase da Waterfall tem um ponto de início e término, e é fácil compartilhar o progresso com as partes interessadas e os clientes. Ao se concentrar em requisitos e design antes de escrever código, a equipe pode reduzir o risco de um prazo perdido.
Requer uma abordagem bem documentada: Ele requer documentação para cada fase, o que resulta em uma melhor compreensão da lógica por trás do código e dos testes. Ele também deixa um rastro de papel para quaisquer projetos futuros ou se as partes interessadas precisam ver mais detalhes sobre uma determinada fase.

Desvantagens da Waterfall

A maior desvantagem da Waterfall é como ela lida com as mudanças. Como a Waterfall de Waterfall é um modelo linear e sequencial, você não pode saltar entre fases, mesmo que mudanças inesperadas ocorram. Depois de terminar uma fase, é isso.

Aqui estão mais informações sobre as desvantagens da Waterfall:

As alterações não podem ser facilmente acomodadas: Quando a equipe concluir uma fase, elas não poderão voltar. Se eles chegarem à fase de teste e perceberem que faltava um recurso na fase de requisitos, é muito difícil e caro voltar atrás e corrigi-lo.
Software não é entregue até tarde: O projeto tem que concluir de duas a quatro fases antes que a codificação realmente comece. Como resultado, as partes interessadas não verão software de trabalho até o final do ciclo de vida.
Reunir requisitos precisos pode ser um desafio: Uma das primeiras fases de um projeto da Waterfall é conversar com clientes e interessados e identificar seus requisitos. No entanto, pode ser difícil identificar exatamente o que eles querem neste início de projeto. Muitas vezes, os clientes não sabem o que querem desde cedo e, em vez disso, aprendem e identificam requisitos à medida que o projeto avança.

Estágios da Waterfall

Existem oito estágios em Waterfall e todos devem acontecer em ordem sequencial. Por exemplo, a equipe de desenvolvimento não poderá voltar à fase de análise se estiver em fase de teste.

Concepção: Esta fase começa com uma idéia. A fase do conceito envolve uma avaliação aproximada do projeto, por que é benéfico e analisa quaisquer estimativas de custo iniciais.
Iniciação: Depois que a ideia é formada, você precisa contratar a equipe de projeto e definir objetivos, escopo, propósito e produtos.
Coleta e análise de requisitos: Os requisitos são coletados e analisadas para ver se o projeto é realmente inviável. Todas essas informações são documentadas em um documento de especificação de requisito.
Design: As especificações de design criadas nesta fase são usadas na fase de codificação para realmente escrever o código. Os requisitos são estudos e avaliados e o design do sistema é preparado. O objetivo da equipe é entender quais ações precisam ser tomadas e como elas devem ser.
Implementação/codificação: A codificação real do software começa. Quaisquer fluxogramas ou algoritmos criados na fase de design são traduzidos para uma linguagem de programação.
de produtos: Depois que o código é concluído, o software precisa ser testado para qualquer erro. Quando o teste é concluído, o software é entregue ao cliente. Algumas equipes podem optar por incluir os testes de aceitação do usuário (UAT), onde os usuários testam o software antes que ele seja implantado para o público em geral.
Manutenção: Uma vez que os clientes têm usado o software no mundo real, eles podem encontrar problemas adicionais. A equipe de desenvolvimento precisará resolver, alterar ou modificar o software para continuar a ser eficaz.

Desenvolvimento iterativo de Waterfall

No modelo tradicional de Waterfall, a equipe passa por cada fase para todo o projeto. Por exemplo, eles fazem a análise de todo o projeto, depois fazem o design de todo o projeto, etc.

Em um modelo iterativo de Waterfall, ainda é necessário muito planejamento inicial. Depois que o plano está em vigor, a equipe segue o mesmo padrão da tradicional Waterfall, mas faz isso para cada história. Eles fazem a análise de uma história, depois todo o design de uma história, depois toda a codificação e teste para uma história. Em seguida, eles repitam o processo para outra história. O trabalho é dividido em partes que beneficiam a equipe de desenvolvimento.

Como a Waterfall lida com requisitos de software

Projetos em Waterfall definem todos os requisitos de software iniciais. O projeto não pode prosseguir a menos que esses requisitos tenham sido identificados e documentados.

Alguns projetos de Waterfall podem ter uma equipe dedicada para capturar, coletar e coletar esses requisitos. Eles podem usar questionários, entrevistas presenciais ou telefônicas, quadros brancos e ferramentas de modelo para capturar as necessidades das partes interessadas e do cliente.

Depois que os requisitos iniciais são definidos, a equipe deve produzir um documento de especificação de requisitos (às vezes, eles podem criar mais de um). Este documento define o que precisa ser entregue para que todos entendam o escopo do projeto.

Kanban

O que é Kanban?

Kanban é japonês para "sinal visual" ou "cartão.” É uma estrutura visual usada para implementar o Agile que mostra o que produzir, quando produzi-la e quanto produzir. Ele incentiva pequenas mudanças incrementais no seu sistema atual e não requer uma determinada configuração ou procedimento (o que significa que você pode sobrepor Kanban em cima de outros fluxos de trabalho existentes).

Kanban foi inspirado no sistema de produção da Toyota e na manufatura enxuta. Na década de 1940, a Toyota melhorou seu processo de engenharia ao modelá-lo após a forma como os supermercados estocam as plataformas. O engenheiro Taiichi Ohno percebeu que os supermercados estocam produto suficientemente para atender à demanda, otimizando o fluxo entre o supermercado e o cliente. O inventário só seria reabastecido quando houvesse espaço vazio na plataforma (uma sugestão visual). E como o inventário correspondia ao consumo, o supermercado melhorou a eficiência no gerenciamento de estoques.

A Toyota trouxe esses mesmos princípios para os andares de sua fábrica. Diferentes equipes criariam um cartão (ou Kanban) para comunicar que tinham capacidade extra e estavam prontos para puxar mais materiais. Como todas as solicitações de partes foram retiradas da ordem, Kanban às vezes é chamado de "sistema pull”

Essas mesmas ideias se aplicam a equipes de software e projetos de TI hoje. Nesse contexto, o trabalho de desenvolvimento em andamento (WIP) toma o lugar do inventário, e novos trabalhos só podem ser adicionados quando houver um "espaço vazio" no quadro visual kanban da equipe. Kanban corresponde à quantidade de WIP com a capacidade da equipe, melhorando a flexibilidade, a transparência e os resultados.

De acordo com o blog sobre Kanban, "Kanban é uma técnica para gerenciar um processo de desenvolvimento de software de maneira altamente eficiente. Kanban sustenta o sistema de produtos "just-in-time" (JIT) da Toyota. Embora a produção de software seja uma atividade criativa e, portanto, diferente dos carros produtores de massa, o mecanismo subjacente para gerenciar a linha de produção ainda pode ser aplicado.”

Ao olhar para Kanban vs Agile, é importante lembrar que Kanban é um sabor do Agile. É uma das muitas estruturas usadas para implementar o desenvolvimento de software Agile.

Sobre o Conselho kanban

Um quadro kanban é uma ferramenta para implementar o método Kanban para projetos. Tradicionalmente, esta ferramenta tem sido um quadro físico, com ímãs, chips plásticos ou notas pegajosas em um quadro branco para representar itens de trabalho. No entanto, nos últimos anos, cada vez mais ferramentas de software de gerenciamento de projetos criaram painéis kanban on-line.

Um quadro kanban, seja físico ou on-line, é composto por diferentes raias ou colunas de natação. Os quadros mais simples têm três colunas: a fazer, em andamento e feito. As colunas de um projeto de desenvolvimento de software podem ser compostas por backlog, ready, codificação, teste, aprovação e colunas feitas.

Os cartões Kanban (como notas pegajosas) representam o trabalho e cada cartão é colocado no quadro da raia que representa o status daquela obra. Esses cartões comunicam o status rapidamente. Você também pode usar cartões de cores diferentes para representar detalhes diferentes. Por exemplo, os cartões verdes podem representar um recurso e os cartões laranjas podem representar uma tarefa.

Vantagens do Kanban

A natureza visual de Kanban oferece uma vantagem única ao implementar o Agile. O quadro de Kanban é fácil de aprender e entender, melhora o fluxo de trabalho e minimiza o tempo do ciclo.

As vantagens do Kanban incluem:

Aumenta a flexibilidade: Kanban é um modelo fluido em evolução. Não há durações de fase definidas e as prioridades são reavaliadas à medida que novas informações entram.
Reduz o desperdício: Kanban gira em torno da redução de desperdício, garantindo que as equipes não passem tempo fazendo trabalhos que não são necessários ou fazendo o tipo errado de trabalho.
Fácil de entender: A natureza visual de Kanban ajuda a torná-lo incrivelmente intuitivo e fácil de aprender. A equipe não precisa aprender uma metodologia completamente nova, e Kanban pode ser facilmente implementado em cima de outros sistemas em vigor.
Melhora o fluxo de entrega: As equipes kanban otimizam o fluxo de trabalho para os clientes. Assim como a entrega contínua (CD), a Kanban concentra-se na entrega just-in-time de valor e na entrega de trabalho aos clientes em uma cadência regular.
Minimiza o tempo do ciclo: O tempo do ciclo é a quantidade de tempo que o trabalho leva para percorrer o fluxo de trabalho da equipe. Nos projetos de Kanban, toda a equipe ajuda a garantir que o trabalho esteja se movendo de maneira rápida e bem-sucedida através do processo.

Desvantagens de Kanban

Muitas das desvantagens associadas a Kanban vêm com o uso incorreto ou má manipulação do quadro kanban. Um quadro desatualizado ou muito complicado pode levar a confusão, imprecisões ou falhas de comunicação.

Aqui está mais sobre as desvantagens de Kanban:

Quadro desatualizado pode levar a problemas: A equipe deve estar comprometida em manter o quadro kanban atualizado, caso contrário eles estarão trabalhando com informações imprecisas. E uma vez que o trabalho é concluído com base em um quadro desatualizado, pode ser difícil colocar as coisas de volta nos trilhos.
As equipes podem complicar demais a diretoria: O quadro de Kanban deve permanecer claro e fácil de ler, no entanto, alguns membros da equipe podem aprender "novos truques" que podem aplicar ao seu quadro. Adicionar esses tipos de sinos e assobios ao quadro de Kanban apenas enterra as informações importantes.
Falta de tempo: Uma reclamação frequente sobre Kanban é que você não sabe quando as coisas serão feitas. As colunas no quadro kanban são marcadas apenas por fase (para fazer, em andamento, concluída), não há cronogramas associados a cada fase, então você realmente não sabe quanto tempo a fase de fazer pode durar.

Práticas e princípios fundamentais de Kanban

Todo projeto kanban deve seguir esses princípios fundamentais:

Visualize o fluxo de trabalho: Uma representação visual do seu trabalho permite que você entenda a visão geral e veja como o fluxo de trabalho proceda. Ao tornar todo o trabalho visível, incluindo bloqueadores e filas, você pode identificar problemas logo no início e melhorar a colaboração.
Limitar o trabalho em andamento (WIP): Os limites de trabalho em andamento (limites de WIP) determinam a quantidade mínima e máxima de trabalho para cada coluna no quadro ou para cada fluxo de trabalho. Ao colocar um limite no WIP, você pode aumentar a velocidade e a flexibilidade e reduzir a necessidade de priorizar tarefas.
Gerencie e melhore o fluxo: O fluxo de trabalho (o movimento do trabalho) por todo o quadro kanban deve ser monitorado e aprimorado. O ideal é que você queira um fluxo rápido e suave, o que mostra que a equipe está criando valor rapidamente. A equipe deve analisar os problemas no fluxo e implementar alterações.
Tornar as políticas de processo explicitas: Para que mudanças colaborativas ocorram no sistema Kanban, os processos precisam ser explicitados. Todo mundo precisa entender como as coisas funcionam ou o que "feito" realmente significa. Você pode modificar o quadro para deixar esses processos mais claros; Por exemplo, você pode reprojetá-lo para especificar como o trabalho deve fluir.
Melhore continuamente: O método Kanban incentiva pequenas mudanças contínuas que se mantêm. Depois que o sistema Kanban estiver em vigor, a equipe poderá identificar e entender os problemas e sugerir melhorias. As equipes medirão sua eficácia acompanhando o fluxo, medindo o tempo do ciclo e aumentando a qualidade do trabalho.

Perguntas comuns sobre Kanban

Q: Como você organiza reuniões e mantém o foco sem um Scrum Master?

Alguém da equipe precisa tomar iniciativa para colocar a reunião no calendário e garantir que a conversa permaneça no caminho certo. Mesmo sem um Scrum Master, normalmente não é um problema muito grande.

O conselho de Kanban ajuda a manter o foco durante a reunião. Durante a reunião, você pode passar pelo conselho da esquerda para a direita e procurar histórias que não se moveram desde a última reunião. Em vez de falar sobre realizações, você pode apenas olhar para os cartões no quadro. A única pergunta que você precisa fazer durante uma reunião é sobre os obstáculos ou os desafios para terminar um item.

Você também pode tentar uma reunião com Kaizen, onde você só convida pessoas envolvidas na tarefa. Cada pessoa discute problemas e desafios e como seu trabalho poderia ser feito com mais eficiência. Então, todo o grupo fala sobre soluções para esses problemas.

Kaizen também pode incluir um facilitador kaizen, que incentiva a equipe a discutir abertamente questões críticas.

Q: Como Kanban pode satisfazer o desejo da gerência de uma entrega previsível?

Em certa medida, Kanban negocia previsibilidade por eficiência. Não há restrições ou planejamento de caixa de tempo, no entanto, uma vez que uma equipe otimizou o fluxo de trabalho e pode ter uma noção de quanto tempo certas tarefas levam, haverá algum nível de previsibilidade.

Se o gerenciamento ainda precisar de previsibilidade mais definida (o que não é a abordagem kanban), talvez você precise tentar gerenciar as expectativas. Em um modelo tradicional, você tem uma data previsível de entrega, mas na realidade ninguém vai entregar um produto até essa data se ele não estiver concluído. A gerência sempre vai esperar o produto ser concluído, independentemente da data original definida. No modelo Kanban, as expectativas precisam ser ajustadas para focar no fornecimento do produto quando ele estiver pronto e concluído.

Q: Como você usa Kanban quando está em um prazo limite?

Existem algumas maneiras diferentes de lidar com prazos em um modelo Kanban. Você pode simplesmente escrever os prazos nos cartões Kanban, certificando-se de que esses prazos atuem mais como diretrizes em vez de datas de vencimento difíceis e rápidas (em Kanban, você não deve sacrificar qualidade para o tempo).

Você também pode mudar a forma como você e sua equipe abordam os prazos. Na forma mais verdadeira de Kanban, não há necessidade para eles. O sistema Kanban garantirá que todas as tarefas sejam concluídas o mais rápido possível, de modo que não seja mais necessário um prazo.

Q: O Kanban pode ser usado para outros projetos além do desenvolvimento de software?

Sim, Kanban pode melhorar os resultados do processo, reduzir o tempo de produção e ajudar a gerenciar o fluxo de trabalho em praticamente qualquer indústria. Por exemplo, na indústria de desenvolvimento de jogos, Kanban ajuda a abreviar o cronograma do processo de vídeo e reduzir o desperdício. No setor imobiliário, ele traz mais eficiência ao acompanhar contratos, perspectivas e listagens em vários conselhos. E em finanças, Kanban pode identificar rapidamente obstáculos e aumentar a velocidade de entrada no mercado.

Q: O WIP é impulsionado pela disponibilidade de recursos?

Sim. Ao definir limites de WIP, você precisa ver quantas pessoas você tem em sua equipe e quantas tarefas você deseja que elas trabalhem ao mesmo tempo.

Q: Como você sabe se o limite de WIP está correto?

Não há fórmula para definir os limites corretos de WIP. É muito comum que limites estejam errados no início, mas você só precisa ajustá-los à medida que o projeto avança. Um bom lugar para começar é 1.5 para recursos disponíveis, mas você deve estar constantemente reavaliando esse número e fazendo alterações conforme necessário.

Agile vs Scrum

Diferenças e semelhanças entre Agile e Scrum

Enquanto Agile e Scrum seguem o mesmo sistema, existem algumas diferenças ao comparar Scrum vs Agile. Agile descreve um conjunto de princípios no Manifesto Agile para a construção de software por meio do desenvolvimento iterativo. Por outro lado, Scrum é um conjunto específico de regras a seguir ao praticar o desenvolvimento de software Agile. Agile é a grande estratégia e Scrum é a metodologia para implementar o Agile.

Como o Scrum é uma maneira de implementar o Agile, ambos compartilham muitas semelhanças. Ambos se concentram em fornecer software cedo e com frequência, são processos iterativos e acomodam mudanças. Eles também incentivam a transparência e o aprimoramento contínuo.

Como o Scrum se encaixa com o Agile?

O Scrum é uma das várias estruturas usadas para implementar um processo Agile. Agile é um termo que inclui outros processos, como Extreme Programming, Kanban, Crystal e Scrum. Scrum é Agile, mas Agile não é Scrum.

Quando usar o Scrum

Recomendamos usar o Scrum se:

Os requisitos do projeto mudarão e evoluirão
Feedback contínuo é necessário
Você tem que descobrir como fazer uma grande parte do trabalho, porque você não fez isso antes
Você não precisa se comprometer com uma data de liberação fixa
A equipe do projeto quer autonomia
Você precisa entregar software regularmente

Scrum funciona bem para projetos que têm muitas incógnitas ou que evoluem ao longo do tempo. Scrum lida com essas mudanças de maneira muito eficaz, para que você possa acomodar facilmente novas informações ou recursos durante todo o processo.

Quando usar o Agile

A linha entre quando usar Agile versus quando usar Scrum é indefinida. Scrum é uma estrutura no processo Agile, então ambos têm muito em comum. Um bom lugar para começar é primeiro entender se você deve usar o Agile em geral. Então, se uma metodologia Agile parece funcionar para você, você pode escolher qual estrutura do Agile usar (Scrum sendo uma estrutura).

Recomendamos usar o Agile se:

O produto final não está claramente definido
Os clientes/partes interessadas precisam ser capazes de alterar o escopo
As mudanças precisam ser implementadas durante todo o processo
Os desenvolvedores são adaptáveis e podem pensar de forma independente
Você precisa otimizar para uma implementação rápida

Abordagem híbrida

Se uma abordagem scrum pura não funciona para o seu projeto, você também pode experimentar um modelo híbrido. Existem várias metodologias que combinam os princípios do Agile ou Scrum e adaptam a estrutura para escalar com mais eficácia.

Por exemplo, o Disciplined Agile Delivery (DAD) baseia-se nas práticas do Agile, Scrum e Lean para fornecer uma base sólida de onde escalar. O DAD foi desenvolvido para fornecer uma abordagem mais coesa ao Agile, adotando estratégias do Scrum, Kanban, Extreme Programming, entre outros. Ao invés de aproveitar o tempo para aprender uma dessas estruturas existentes e juntá-las conforme necessário, a DAD já combina todas as técnicas relevantes.

Outros métodos híbridos incluem Scrum (LeSS) em larga escala, que estende o Scrum com regras e diretrizes de escala, e o Scaled Agile Framework (SaFE), baseado nos princípios subjacentes Lean e Agile.

Kanban vs Scrum

Diferenças e semelhanças: Scrum vs Kanban

Scrum e Kanban são ambos sabor de Agile, mas eles têm algumas diferenças distintas.

O Scrum requer funções específicas, enquanto Kanban não possui funções obrigatórias.
O Scrum é baseado em iterações com caixasde tempo, combinando planejamento, melhoria de processo e liberação. Em Kanban, você pode optar por fazer essas atividades em uma cadência regular ou sempre que precisar.
Scrum limita o trabalho em andamento (WIP) em cada iteração, enquanto Kanban limita o WIP em cada fluxo de trabalho.
Scrum resiste à mudança, enquanto Kanban acomoda e abraça facilmente as mudanças. No Scrum, uma vez que a equipe tenha cometido histórias em um sprint, você não poderá adicionar histórias adicionais mais tarde. Em Kanban, você pode adicionar ou alterar histórias como quiser, supondo que esteja dentro dos limites do WIP.
Uma placa Scrum é redefinida após cada sprint. Um quadro kanban é continuamente usado.
Uma equipe Scrum é multifuncional e uma equipe é dona do quadro Scrum. Em Kanban, as equipes não precisam ser multifuncionais e ninguém pode ser proprietário do quadro kanban.
As equipes Scrum exigem estimativa, enquanto Kanban não.

E Scrum e Kanban também têm algumas semelhanças:

Eles são empíricos. Você tem que experimentar o processo para ver o que funciona para você.
Ambos permitem que membros da equipe trabalhem em vários produtos de uma só vez.
Eles são Lean e Agile.
Ambos limitam o WIP (embora a maneira como cada WIP limite é diferente)
Eles usam o inventário pull
Eles se concentram em fornecer software cedo e com frequência
Ambos usam transparência para melhorar o processo

Como Kanban e Scrum se relacionam uns com os outros?

Kanban e Scrum são ambas estruturas para o desenvolvimento de software Agile. Ambos pegam tarefas grandes e complexas e as dividem em pedaços menores. Kanban e Scrum também trabalham no sentido de melhoria contínua e otimização do processo, e querem manter o trabalho altamente visível.

Embora kanban e Scrum sejam muito adaptativos, Scrum é mais rígido que Kanban. Scrum tem mais restrições, enquanto Kanban é mais flexível.

Quadro Scrum vs Kanban

Embora um quadro Scrum e um quadro de Kanban possam ser parecidos visualmente, eles são baseados em princípios muito diferentes.

Para criar um quadro Scrum, a equipe Scrum deve primeiro criar sprints, atribuir pontos às histórias do usuário e planejar quais histórias vão para as quais sprint. Em seguida, o quadro scrum visualiza o sprint, mostrando quais histórias estão no modo de plano ou modo de trabalho. O quadro Scrum é redefinido entre cada sprint e pertence a uma equipe específica.

Um quadro Kanban tem o mesmo layout baseado em colunas que um quadro Scrum, mas não requer um planejamento antecipado. Você pode começar a trabalhar e mover pelo fluxo do quadro kanban sem ter um plano estruturado. O quadro kanban pode ser compartilhado por várias pessoas e é persistente; você não precisa redefinir o quadro. E, ao contrário do quadro Scrum, o quadro de Kanban tem um número máximo de histórias permitido em cada coluna de cada vez. Isso continuará a fluir enquanto o projeto continuar, com novas histórias adicionadas e histórias concluídas sendo reavaliadas, se necessário.

Quando usar Kanban

Recomendamos usar Kanban se:

Você precisa adicionar histórias ou mudar sprints em tempo real
Você não precisa de iterações
Estimativa não é necessária
Você quer a capacidade de soltá-lo a qualquer momento
Melhorias contínuas já estão sendo destacadas
Sua equipe não responde bem a grandes mudanças
Você quer melhorar o fluxo de entrega
O sistema precisa ser fácil de entender

Scrum pode ser menos flexível que Kanban. O tempo gira em torno de sprints, com cada sprint durando de duas a quatro semanas. Em cada sprint, a equipe tem funções específicas e segue atividades específicas.

O que é Scrumban?

Scrumban combina os princípios do Scrum e do Kanban em um sistema baseado em pull. A equipe planeja o trabalho que foi estabelecido durante a iniciação e continuamente prepara o backlog. As mesmas reuniões do Scrum devem ocorrer, mas a frequência pode mudar dependendo do contexto e da necessidade. A parte mais importante do Scrumban é garantir que o trabalho nos limites de progresso (limites de WIP) seja seguido.

Scrumban leva pedaços de Scrum e Kanban. Por exemplo, ele inclui as funções definidas, Scrum diário e outras reuniões do Scrum. E de Kanban, é preciso o quadro kanban, fluxo contínuo e capacidade de adicionar alterações conforme necessário ao quadro.

Scrumban pode se parecer mais com Scrum no nível técnico, mas no nível cultural, ele se parecerá mais com Kanban. Em vez de grandes mudanças de uma só vez, Scrumban incentiva mudanças incrementais. Se a sua equipe deseja migrar do Scrum para Kanban, o Scrumban pode proporcionar uma transição suave.

Qual é melhor? Kanban vs Scrum

Ao comparar Kanban com Scrum, não há vencedor definitivo. A melhor estrutura depende de seu projeto, equipe e seus objetivos. Como tanto Kanban quanto Scrum são metodologias Agile flexíveis, você poderia facilmente pegar os princípios de cada um e aplicá-los conforme necessário.

É importante lembrar que o scrum verdadeiro é uma mudança muito maior do que Kanban. A equipe terá que aprender sobre as atividades, as funções específicas e as iterações. Por outro lado, Kanban incentiva melhorias incrementais. Você pode aplicar princípios Kanban a qualquer processo que você já tenha em vigor, até mesmo ao Scrum. Nada precisa mudar significativamente para começar com Kanban.

Como regra geral, se sua equipe ou organização estiver realmente presa e precisar de uma grande mudança, o Scrum pode ser mais apropriado. Se você já tem um processo em andamento com o qual está satisfeito, mas quer implementar algumas pequenas mudanças, Kanban pode ser uma escolha melhor.

Agile vs Waterfall

Diferenças e semelhanças: Waterfall vs Agile

As diferenças entre a metodologia Waterfall versus Agile podem ser resumidas em duas palavras: rígido vs flexível. O Agile é um processo muito mais rigoroso e rígido, enquanto o Agile é flexível e em constante evolução. Aqui está mais sobre suas diferenças:

Ele é um processo estruturado , onde não é possível iniciar uma nova fase até que a anterior tenha sido concluída. Por outro lado, o Agile é um processo flexível, que permite que você passe pelo projeto da maneira que quiser.
A Waterfall de cascatas é sequencial e o Agile não impossibilidades a um processo linear.
Os projetos do Agile geralmente incluem requisitos definidos com antecedência, enquanto os requisitos devem mudar e evoluir em projetos Agile.
Em projetos do Agile, você não pode mudar as coisas que foram feitas em estágios anteriores, enquanto o Agile é muito acomodado com as mudanças.

Não existem muitas semelhanças entre Agile e Waterfall; Agile foi criado especificamente para ser o oposto de Waterfall. No entanto, você pode dizer que tanto o Agile quanto o Agile têm o mesmo objetivo. Ambos querem entregar produtos de qualidade de maneira eficiente. Se você tem alguma outra semelhança entre Agile e Waterfall para compartilhar, deixe-nos um comentário!

Quando você deve usar Waterfall e Quando Usar Agile

Recomendamos usar a Waterfall se:

Você não espera mudanças no escopo e está trabalhando com contratos de preço fixo
O projeto é muito simples ou você já fez isso muitas vezes antes
Os requisitos são muito conhecidos e fixos
Os clientes sabem exatamente o que querem com antecedência
Você está trabalhando com projetos ordenados e previsíveis

E você deve usar o Agile se:

O produto final não está claramente definido
Os clientes/partes interessadas precisam da capacidade de modificar o escopo
Você prevê qualquer tipo de mudança durante o projeto
Implementação rápida é o objetivo

Ao decidir entre Agile versus Waterfall, tudo pode se resumir a isso: se você antecipar ou esperar qualquer mudança ao longo do projeto, vá com Agile. Se você souber que o projeto está fixo, imutável e previsível, a Waterfall pode ser uma escolha melhor.

Qual é melhor? Agile vs Waterfall

Agile e Waterfall são opostos que é difícil dizer qual é melhor. Isso realmente depende do projeto, do nível de clareza em torno dos requisitos e de quão flexível você pode ser.

Se você tem uma visão clara do que deve ser o produto final, você tem requisitos fixos que não mudarão, e você está trabalhando em um projeto relativamente simples, alguns argumentam que A Waterfall é uma escolha melhor do que Agile. Se você não espera lidar com mudanças, a Waterfall de Waterfall é um processo simples e eficiente. Os problemas com a Waterfall vêm quando você precisa acomodar as alterações.

Se você não tem uma visão clara do produto final, você antecipa as mudanças e está trabalhando em um projeto complexo, o Agile é superior. Agile foi projetado para acomodar novos requisitos em evolução a qualquer momento durante o projeto, enquanto a Waterfall não permite que você volte para uma fase concluída e faça alterações.

Híbrido: Agifall ou WAgile

Se você ainda está pensando em Waterfall versus Agile, você sempre pode combinar princípios de ambos e usar um modelo híbrido.

Agi>, por exemplo, aumenta a velocidade e a qualidade adicionando metodologias Agile ao processo de Waterfall. Em um projeto de Agisheet, você dividiria as fases de pesquisa, estratégia e planejamento em tarefas e prosseguiria com sprints para completá-las. A fase de desenvolvimento seria como qualquer outro projeto Agile, com mais informações adiantadas. Você também não precisa esperar uma fase terminar para iniciar a fase a seguir, que é tradicional em pura Waterfall. Com Agisheet, quando o projeto pode começar, ele deve começar.

Ele tem uma conotação mais negativa do que Agifall. A definição da Wagile sobre a Wikipédia é: "um grupo de metodologias de desenvolvimento de software que resultam do deslizamento do Agile de volta para a Waterfall, fazendo um monte de pequenas Cascatas e pensando que é Agile, modelo Da> mascarado como desenvolvimento de software Agile.”

A Wagile adota práticas ágeis como iterações curtas, stand-ups diários ou integração contínua em cima do modelo Da Waterfall, sem realmente mudar o modelo tradicional de Waterfall.

Kanban vs Agile

Diferenças e semelhanças: Agile vs Kanban

Enquanto Kanban é uma maneira visual de implementar o Agile, eles têm muitas diferenças:

Kanban defende o fluxocontínuo, enquanto Agile trabalha em iterações.
Kanban pode trabalhar igualmente bem para qualquer tipo de trabalho, enquanto Agile pode ser mais adequado para alguns projetos em vez de outros.
Qualquer um pode pegar Kanban, mas algumas metodologias agile requerem conhecimento ou treinamento.
Kanban requer uma representação visual do fluxo de trabalho, enquanto o Agile não.
Alguns projetos Agile exigem equipesinterfuncionais, enquanto Kanban não.
Agile é uma lógica enquanto Kanban é um método.

E Agile e Kanban também têm semelhanças:

Ambos dividem os projetos em partes menores.
Eles enfatizam a melhora contínua.
Eles valorizam muito a transparência.
Nenhum deles requer um grande planejamento inicial.
Eles trabalham para uma entrega mais rápida.

Quando você deve usar Kanban e Quando usar o Agile

Recomendamos usar Kanban se:

Seu projeto não requer iterações
Você quer a capacidade de soltá-lo a qualquer momento
Sua equipe prefere mudanças incrementais
Sua equipe trabalha bem com visual
Você quer melhorar o fluxo de entrega
Você está procurando um sistema fácil de entender

E recomendamos usar o Agile se:

O produto final não está claramente definido
As mudanças precisam ser implementadas durante todo o processo
Os desenvolvedores são adaptáveis e podem pensar de forma independente
Você está procurando fazer uma mudança substancial

Qual é melhor? Agile vs Kanban

Como em qualquer metodologia de gerenciamento de projetos, não há uma estrutura melhor em 100% das vezes. Você pode escolher Kanban para alguns projetos, mas quer implementar o Agile para outros.

Considere o nível de mudança que deseja apresentar à sua equipe. Se você quiser adicionar algo em cima de uma estrutura existente com pequenas alterações incrementais, Kanban é uma escolha melhor. Se você deseja fazer uma mudança maior no processo, implementar o Agile (como o Scrum) seria melhor.

E, se você deseja que sua equipe de projeto comece imediatamente com um novo método, Kanban é mais fácil de entender. Não há necessidade de treinamento e ele pode ser usado em cima de qualquer processo existente. Por outro lado, alguns métodos Agile exigem mais conhecimento da equipe. Por exemplo, podem ser necessários aprender funções,práticas e terminologia.

Recursos e Postagens Relacionadas

Baixe um modelo gratuito do gráfico de Excel ou aprenda a criar um gráfico do zero. Também compartilharemos quando usar um gráfico de Waterfall e as funções de um gráfico de Waterfall no Excel.

Encontre oito modelos de gerenciamento de projetos Agile no Excel, que vão desde o modelo de backlog de produtos Agile até o modelo de charter de projeto Agile. Você também aprenderá como usar modelos Agile no Smartsheet

Cursos:

PMI Agile Certified Practitioner (PMI ACP): Oferecida pelo Project Management Institute (PMI), essa certificação abrange as diversas abordagens do Agile, como Scrum, Kanban, Lean, Extreme Programming (XP) e Test-Driven Development (TDD). Os pré-requisitos incluem 2.000 horas de experiência geral do projeto trabalhando em uma equipe, 1.500 horas trabalhando em equipes de projeto Agile e 21 horas de contato de treinamento em práticas Agile.
ScrumMaster certificado (CSM): Esta certificação da Scrum Alliance ajuda as equipes a usarem o Scrum corretamente, entender os valores e proteger a equipe contra distrações. Como CSM, você poderá preencher a função de Membro da equipe Scrum Master ou Scrum. Para obter seu certificado CSM, você deve fazer um curso de CSM de um Treinador Autorizado da Scrum Alliance e demonstrar o progresso com um teste on-line.
Proprietário certificado de produto Scrum (CSPO): Um Proprietário certificado de produto Scrum aprende Scrum, práticas e princípios a fim de cumprir o papel de Proprietário de Produto em uma equipe Scrum. Ele ou ela é o mais próximo do lado empresarial do projeto, mantém o backlog do produto e garante que todos conheçam as prioridades. Para obter esta certificação da Scrum Alliance, você deve participar de um curso CSPO presencial de dois dias ministrado por um Treinador Scrum certificado.
Scrum Profissional Certificado (CSP): Os Profissionais Scrum certificados desafiam suas equipes Scrum a melhorar a maneira como o Scrum é implementado para cada projeto. Para se inscrever em um CSP, você deve atualmente possuir uma credencial CSM, CSPO ou CSD, ter um mínimo de 36 meses de experiência Agile/Scrum e reunir e enviar 70 Unidades de ensino Scrum dos últimos três anos.
Praticante de Kanban credenciado (FIREWALL): Os praticantes Kanban credenciados são profissionais que provaram conhecimentos e especialização na implementação de Kanban para desenvolvimento de software. A certificação é oferecida pelo Agile Certification Institute, Inc. e exige que você tenha treinamento prévio em práticas agile e que você passe em um exame de certificação ZIP.

Gerencie qualquer projeto à sua maneira com o Smartsheet

Capacite seu pessoal para ir além com uma plataforma flexível desenvolvida para atender às necessidades da sua equipe e se adaptar conforme essas necessidades mudam. Com a plataforma Smartsheet fica fácil planejar, coletar informações, gerenciar e criar relatórios sobre o trabalho de qualquer lugar, ajudando sua equipe a ser mais eficiente e mostrar resultados. Crie relatórios sobre as principais métricas e obtenha visibilidade do trabalho em tempo real, à medida que ele acontece, através de relatórios, painéis e fluxos de trabalho automatizados criados para manter sua equipe conectada e informada. Quando as equipes têm clareza sobre o trabalho que está sendo realizado, elas podem ser muito mais produtivas durante o mesmo período de tempo. Experimente o Smartsheet gratuitamente hoje mesmo.

Recursos e Postagens Relacionadas

Como Criar um Gráfico de Gantt em Excel

Melhores modelos ágeis de gerenciamento de projetos em Excel

Planejamento Agile: Práticas recomendadas para gerentes de projeto

Recurso ágil de gerenciamento de projeto de uma parada

Cursos:

PMI Agile Certified Practitioner (PMI ACP): Oferecida pelo Project Management Institute (PMI), essa certificação abrange as diversas abordagens do Agile, como Scrum, Kanban, Lean, Extreme Programming (XP) e Test-Driven Development (TDD). Os pré-requisitos incluem 2.000 horas de experiência geral do projeto trabalhando em uma equipe, 1.500 horas trabalhando em equipes de projeto Agile e 21 horas de contato de treinamento em práticas Agile.
ScrumMaster certificado (CSM): Esta certificação da Scrum Alliance ajuda as equipes a usarem o Scrum corretamente, entender os valores e proteger a equipe contra distrações. Como CSM, você poderá preencher a função de Membro da equipe Scrum Master ou Scrum. Para obter seu certificado CSM, você deve fazer um curso de CSM de um Treinador Autorizado da Scrum Alliance e demonstrar o progresso com um teste on-line.
Proprietário certificado de produto Scrum (CSPO): Um Proprietário certificado de produto Scrum aprende Scrum, práticas e princípios a fim de cumprir o papel de Proprietário de Produto em uma equipe Scrum. Ele ou ela é o mais próximo do lado empresarial do projeto, mantém o backlog do produto e garante que todos conheçam as prioridades. Para obter esta certificação da Scrum Alliance, você deve participar de um curso CSPO presencial de dois dias ministrado por um Treinador Scrum certificado.
Desenvolvedor de Scrum certificado (CSD): Os Desenvolvedores Scrum certificados aprendem habilidades especializadas de engenharia Agile e demonstram seus conhecimentos por meio de treinamento formal e uma avaliação de habilidades técnicas. O curso de CSD é voltado para desenvolvedores de software que estão trabalhando em um ambiente Scrum. Para obter um CSD da Scrum Alliance, você deve ter cinco dias de treinamento formal ministrados por um provedor de educação registrado da Scrum Alliance e um instrutor autorizado da Scrum Alliance.
Scrum Profissional Certificado (CSP): Os Profissionais Scrum certificados desafiam suas equipes Scrum a melhorar a maneira como o Scrum é implementado para cada projeto. Para se inscrever em um CSP, você deve atualmente possuir uma credencial CSM, CSPO ou CSD, ter um mínimo de 36 meses de experiência Agile/Scrum e reunir e enviar 70 Unidades de ensino Scrum dos últimos três anos.
Praticante de Kanban credenciado (FIREWALL): Os praticantes Kanban credenciados são profissionais que provaram conhecimentos e especialização na implementação de Kanban para desenvolvimento de software. A certificação é oferecida pelo Agile Certification Institute, Inc. e exige que você tenha treinamento prévio em práticas agile e que você passe em um exame de certificação ZIP.

Gerencie qualquer projeto à sua maneira com o Smartsheet

Ligue os seus colaboradores, processos e ferramentas com uma plataforma simples e fácil de utilizar.

Experimente o Smartsheet gratuitamente Get a Free Smartsheet Demo