Uma história do método Waterfall
O Waterfall é um padrão lógico a seguir: planejar, construir, testar e liberar em sequência. A história do Waterfall vem do artigo de Winston W. Royce de 1970 do Proceedings of IEEE WESCON, Managing the Development of Large Software Systems. O artigo de Royce foi provavelmente a primeira discussão sobre o Waterfall no desenvolvimento de software, embora a palavra "waterfall" não apareça em nenhum lugar do artigo. O termo formal foi introduzido em Thomas E. Bell's e T.A. O artigo de Thayer de 1976 da Proceedings a 2nd International Conference on Software Engineering, Software requirements: Are they really a problem?. Como tem sido observado em muitos lugares, no entanto, o artigo de Royce não elogiou o método. Na verdade, ele o descreveu em termos pouco lisonjeiros, chamando-o de falho e convidando o fracasso de muitas maneiras. Ele passou a discutir uma abordagem mais iterativa, talvez a base do que se tornaria uma abordagem ágil.
O artigo de Bell e Thayer discute uma mudança de abordagem de baixo cima e de cima para baixo no desenvolvimento de requisitos de software, referindo-se à adoção dessa abordagem em MIL STD 490/483 (MIL STD 490 discute práticas de especificações e MIL STD 483 discute Práticas de gerenciamento de configuração para sistemas). O artigo está mais preocupado em examinar as abordagens empiricamente para determinar quais funcionam melhor. Em última análise, o artigo declara que "nos últimos dez anos mais estrutura e disciplina foram adotadas, e os praticantes concluíram que uma abordagem de cima para baixo é superior à antiga abordagem de baixo para cima". O termo "waterfall" é usado em referência direta ao artigo de Winston Royce.
Apesar das falhas descritas pela Royce, Waterfall tornou-se um método preferido em 1985, quando o Departamento de Defesa emitiu o DOD-STD-2167A, Defense Systems Software Development. Ele descreveu o ciclo de desenvolvimento de software da seguinte forma:
- Análise de requisitos de software;
- Design preliminar;
- Design detalhado;
- Codificação e teste unitário;
- Integração e teste do componente de software de computador (CSC);
- Teste CSCI;
Afirma que "este padrão destina-se a ser dinâmico e responsivo ao campo de tecnologia de software em rápida evolução. Como tal, esse padrão deve ser aplicado seletivamente e adaptado para se adequar às características únicas de cada programa de aquisição de software." No entanto, a exigência foi estabelecida em termos claros e seguida religiosamente.
O método Waterfall começou a desaparecer do uso popular quando os líderes do setor ficaram frustrados com sua inflexibilidade e desenvolveram o Manifesto ágil. Desde então, cada vez mais empresas adotaram o método ágil, mas muitas empresas ainda preferem o Waterfall, e por um bom motivo. O Waterfall tem suas falhas, mas também tem seus benefícios e, no ambiente certo, pode ser a melhor prática.
Guia de gerenciamento de projetos
O seu balcão único para tudo sobre gestão de projetos
Tudo pronto para aproveitar melhor seus esforços de gerenciamento de projetos? Visite nosso guia abrangente de gerenciamento de projetos para obter dicas, práticas recomendadas e recursos gratuitos para gerenciar seu trabalho com mais eficiência.
Benefícios do gerenciamento de projetos Waterfall
Levando em conta as críticas ao Waterfall, há alguns benefícios reais em sua implementação:
- É uma abordagem simples e direta.
- É fácil desenvolver um plano para gerenciar um projeto Waterfall, já que cada fase tem um início e fim, e você sabe antes da programação o que deve ser desenvolvido, quando é devido, quando os testes devem começar etc.
- O planejamento inicial fornece uma boa base para projetar componentes que se integram a sistemas externos.
- É fácil planejar recursos para o Waterfall porque, novamente, você sabe quando tudo está para começar e terminar.
- Os clientes que desejam datas definitivas de início e de término podem achar o Waterfall reconfortante. Os clientes podem ser informados da data em que terão um produto em suas mãos e, se o projeto estiver certo para uma abordagem Waterfall, ele será entregue nessa data.
- O custo do desenvolvimento pode ser determinado com antecedência.
- Procedimentos detalhados podem ser usados para regular cada parte do processo.
- A abordagem pesada em design da Waterfall força uma abordagem disciplinada para o desenvolvimento e deixa as expectativas claras.
- Os membros da equipe podem participar de outros projetos antes de sua fase começar ou após o término de sua fase, retornando ao projeto conforme necessário.
- A dependência da documentação de design reduz o estresse do volume de negócios dos desenvolvedores.
- A abordagem pesada em design significa que erros podem ser vistos nessa fase. Há armadilhas óbvias nisso, e qualquer um que tenha trabalhado com o método Waterfall sabe que erros de design ocorrem. Mas reúna uma equipe experiente e elabore um plano e, muitas vezes, você terá um design sólido que pode ser executado de acordo com o plano.
Desvantagens do gerenciamento de projetos Waterfall
Aqui estão algumas das principais preocupações e críticas do Waterfall:
- O tempo de lançamento é excepcionalmente longo para projetos de grande porte. O artigo de Royce foi generoso com o Waterfall quando se tratava de projetos pequenos e internos, mas o considerava bastante falho para projetos maiores e mais complexos. Na verdade, esta é provavelmente a principal razão pela qual o método ágil se tornou tão popular. Projetos muito grandes foram cancelados antes que pudessem chegar à conclusão através do método Waterfall.
- A segunda crítica importante à Waterfall é que a mudança não é bem-vinda. Depois que os testes começam, é extremamente caro voltar ao desenvolvimento ou redesenhar o projeto. O design deve ser escrito de maneira correta e cuidadosa antes de ir longe demais.
- O software em funcionamento não aparece até o final do projeto.
- Bugs escritos no início do projeto podem criar grandes dores de cabeça para código posterior, mas nada disso se torna aparente até que os testes comecem, o que torna a fixação do código cara e demorada.
- Não é uma abordagem orientada a objetos. Os projetos Waterfall são altamente integrados. Este é outro aspecto do Waterfall que reduz a flexibilidade.
- Não é um bom método para manutenção e outros tipos de projetos de longo prazo.
- Lado a lado com as críticas anteriores está o fato de que os clientes, muitas vezes, não sabem o que querem antes do início do projeto.
- Se a equipe é inexperiente ou está trabalhando com algo totalmente novo, surgem obstáculos que podem ameaçar o projeto.
- Os testes podem ser alterados a fim de manter-se dentro do cronograma, o que deixa os bugs a serem descobertos pelo cliente após o produto ser entregue.
- Os eventos podem forçar o projeto inteiro a ser suprimido. Por exemplo, mudanças na indústria que ocorrem durante a fase de desenvolvimento podem tornar todo o projeto obsoleto. Outro evento pode ser a descoberta de uma falha de design tão grave que todo o projeto tem que voltar para a reformulação, o que pode ser tão caro que o cliente rejeita o projeto.
Comparando Waterfall com o método ágil
Waterfall se concentra na fase de design de um projeto, enquanto o método ágil envolve um tempo mínimo em design. Ambas as opções de gerenciamento de projetos visam fornecer software em funcionamento, mas os projetos Waterfall geralmente entregam um lançamento uma ou duas vezes por ano (ou até menos vezes), enquanto o método ágil pode fornecer software de trabalho com tanta frequência quanto uma vez por semana. As entregas em Waterfall podem ser grandes e requerem um longo período de testes, com muitas empresas também usando clientes para fornecer testes beta. O método ágil testa o software à medida que ele é construído, com o desenvolvedor realizando os testes frequentemente.
Uma diferença significativa entre Wo aterfall e o método ágil é que Waterfall é uma metodologia, mas ágil é um "movimento" com uma variedade de métodos derivativos que aplicam os princípios e valores ágeis. Scrum, eXtreme Programming (XP), Kanban, Scrumban e uma série de outros métodos oferecem as opções de equipe de desenvolvimento, para que se possa escolher o melhor entre eles.
Uma metodologia ágil é uma escolha superior quando o cliente está incerto sobre os requisitos ou quer estar intimamente envolvido no processo de desenvolvimento, e se os cronogramas são curtos e eles querem uma entrega rápida. O Waterfall será superior se houver dependências complexas, mas o método ágil é preferível quando as dependências são mínimas. O método ágil também é melhor se a velocidade for mais importante do que a qualidade.
Algumas desvantagens do método ágil são:
- Requer envolvimento do cliente;
- Custos e cronogramas são incertos;
- O planejamento é difícil;
- Falta de clareza sobre o resultado final;
- Documentação mínima;
- Os membros da equipe devem ser multifuncionais, aueles que são inexperientes em funções desconhecidas;;
- Os desenvolvedores se dedicam a um único projeto
- Scope creep é um risco; quando um projeto acolhe a mudança, ele pode crescer fora de controle e passar do prazo estipulado;
A ideia de que o método ágil é uma partida dramática do Waterfall não é inteiramente verdadeira. A abordagem ágil é, na verdade, mais uma abordagem ajustada do Waterfall, uma tentativa de abordar algumas das desvantagens do Waterfall em termos de resistência às mudanças e longas datas de entrega. A falta de flexibilidade e a alta taxa de projetos cancelados fizeram com que muitas equipes mudassem do Waterfall para o método ágil. No entanto, é importante entender que o método ágil ainda adota uma abordagem sequencial; ele só usa uma sequência mais curta. O método ágil ainda inclui alguns requisitos de análise e design no início, mas a codificação não começa até que os requisitos e design sejam concluídos, e você não pode testar um código que não foi escrito ou entregar um código que não foi testado e integrado. Portanto, o método ágil pode ser considerado como uma forma mais flexível e rápida de gerenciamento de projetos Waterfall.
Dicas e práticas recomendadas para seu próximo projeto usando a metodologia ágil.
Saiba tudo sobre o gerenciamento de projetos ágeis e dicas para ajudá-lo a começar a implementar as práticas recomendadas ágeis PM.
Obtenha o e-book gratuito para implementar as práticas recomendadas do método ágil
Quando usar o método Waterfall para gerenciamento de projetos
Decidir entre o Waterfall e o método ágil se resume a examinar as características do projeto e as necessidades do cliente. Em particular, preste muita atenção aos requisitos, à meta e ao objetivo do projeto. O Waterfall é, muitas vezes, a melhor escolha quando:
- Os requisitos são bem compreendidos e não podem mudar.
- O cliente não é propenso a mudanças exigentes.
- O cliente prefere não estar envolvido no desenvolvimento, mas quer ser consultado no início e receber um pacote de trabalho no final do projeto. O ágil funciona melhor quando o cliente está envolvido em todas as fases (revisando o produto em cada iteração), mas os clientes da Waterfall só precisam receber um lançamento e instalá-lo. (Observação: isso é uma simplificação. Os clientes também devem ser educados no uso do sistema e essa pode ser uma etapa longa e importante. Isso vale para todo o método usado, e pode ser que educar os usuários uma ou duas vezes por ano sobre novos recursos para um lançamento maior é menos intrusivo do que educar um cliente mensalmente ou até mesmo semanalmente em um conjunto menor de recursos. Além disso, tenha em mente que os clientes que desejam estar envolvidos podem estar em um projeto baseado em Waterfall. Ter o cliente em avaliações frequentes pode ser uma distração e pode levar a solicitações de mudança indesejadas, mas também pode manter o projeto focado em atender às necessidades dos clientes.)
- O projeto é pequeno.
- A velocidade de entrega não é importante.
- A entrega deve ser aplicada a um sistema legado que não é propenso a mudanças.
- Você terá projetos semelhantes no futuro, permitindo a reutilização do plano do projeto e pode obter lições da documentação pesada do projeto anterior.
Uma breve olhada nas principais metodologias de gerenciamento de projetos
Waterfall é apenas uma das muitas metodologias concorrentes. Ao tomar a decisão de implementar uma ou outra, ter uma ideia do que elas são ajuda. A seguir, confira uma breve olhada nas principais metodologias de gerenciamento de projetos atualmente em uso.
Waterfall
A metodologia Waterfall é geralmente considerada como uma abordagem tradicional para o gerenciamento de projetos. O Waterfall foi baseado na noção de tudo acontecendo em sequência, com uma fase de um projeto terminando antes de outro início. Isso criou muitas dependências e também resultou em algumas situações bastante desastrosas para o desenvolvimento de software. Os projetos estavam frequentemente atrasados e acima do orçamento, e em alguns casos, eram completamente cancelados quando a tecnologia mudava de forma muito rápida.
Método do caminho crítico (CPM)
O método CPM é outro método sequencial que pressupõe que cada etapa depende da conclusão da etapa anterior. A fase de planejamento de um projeto de CPM é mais sobre identificar as partes mais intensivas de recursos do projeto, a fim de alocar recursos e evitar obstáculos. A aplicação do método é feita ao:
- Identificar tarefas necessárias e definir a sequência para completá-las.
- Definir as dependências das tarefas necessárias.
- Determinar os relacionamentos que são e não são críticos entre as tarefas.
- Agendar o cronograma esperado para cada tarefa.
- Desenvolver um plano B para caminhos críticos.
O Gerenciamento de projetos de cadeia crítica (CCPM)
O Waterfall se concentra no design e o CPM se concentra em tarefas, mas o CCPM se concentra em recursos e alocação de recursos. O CCPM se concentra nos fatores que podem afetar cronogramas, custos, desempenho e o risco de subentrega. A abordagem do CCPM é definir a cadeia crítica, aplicar recursos que podem funcionar melhor e, finalmente, introduzir buffers de tempo nas tarefas críticas, a fim de garantir a entrega oportuna se surgirem problemas.
O Guia PMI PMBOK® O método de gerenciamento de projetos do Guia PMI PMBOK® aplica os cinco grupos de processo do PMI a partir do texto A Guide to Project Management Body of Knowledge.
Aqui está uma visão geral de alto nível desses grupos:
- Início — Defina a visão. Este também é o grupo de processo em que o gerente de projeto é selecionado.
- Planejamento — Defina o escopo. O PMBOK descreve 24 processos na fase de Planejamento.
- Execução — Coloque o plano em ação.
- Monitoramento e controle — Isso ocorre durante todo o projeto e não é uma fase sequencial que espera outra fase terminar.
- Fechamento — Ocorre quando o cliente concorda em aceitar o projeto.
Metodologias ágeis
O método ágil é definido como um movimento, não como uma metodologia, mas uma família de metodologias ágeis foi desenvolvida de acordo com os valores e princípios ágeis.
Scrum
O método Scrum tem uma pequena equipe ágil liderada por um Scrum Master. A função do Scrum Master é facilitar o trabalho da equipe. O planejamento é mínimo e é criada uma lista com as tarefas a serem trabalhadas. As tarefas são trabalhadas em "Sprints", que normalmente têm de duas a quatro semanas de duração. Breves reuniões diárias (chamadas de Daily Scrums) são realizadas para revisar as tarefas do dia e identificar obstáculos. Os membros da equipe realizam todas as tarefas tradicionais de um projeto, projetando à medida que vão e testando à medida que completam uma tarefa. O objetivo do Scrum é entregar um software em funcionamento. Quando um Sprint termina, o próximo começa, com a equipe desenhando um conjunto de tarefas do backlog do projeto. Quando os objetivos gerais do projeto foram atingidos e não há mais tarefas, o projeto é concluído.
Kanban
O método Kanban é mais adequado para projetos de manutenção. O núcleo do método Kanban é o quadro Kanban, uma lista de todas as tarefas (também chamadas de cartões Kanban) a serem realizadas que é continuamente atualizada e é facilmente visível para todos os membros da equipe. Quando um recurso (membro da equipe) fica disponível, esse membro da equipe pega uma tarefa do quadro e trabalha nela. As tarefas são adicionadas ao quadro e trabalhadas continuamente. Não há início ou término definidos para o projeto.
Sprints de Extreme Programming (XP)
geralmente têm uma semana de duração com muitas iterações. No XP, a mudança é a chave, e os programadores XP trabalham em estreita colaboração com as partes interessadas. O XP é ideal para ambientes onde os requisitos estão em constante mudança. As tarefas podem ser substituídas no meio do Sprint.
Adaptive Project Framework (APF)
O APF assume que os projetos de TI variam tão amplamente, que uma só abordagem jamais faz sentido. Os projetos de TI diferem em risco, custo, comprimento e complexidade e geralmente envolvem incertezas no mercado, valor do negócio, envolvimento do cliente e objetivos. Portanto, um projeto APF começa com a análise dos requisitos para definir metas estratégicas. O projeto é executado iterativamente e post-mortems são realizados após iterações a fim de melhorar o processo. A análise geralmente está em andamento, de modo que todo o projeto possa ser redefinido ou adaptado à medida que prossegue em resposta aos problemas de incerteza, a fim de manter ou aumentar o valor do negócio.
Lean
O Lean destina-se a reduzir o desperdício e maximizar o valor. Os valores centrais do Lean são a melhoria incremental contínua e o respeito pelas pessoas. O Lean se concentra em entregar o maior valor ao cliente, manter o fluxo, alocar o trabalho uniformemente e, acima de tudo, eliminar o desperdício.
Six Sigma
O Six Sigma é sobre eliminar defeitos no desenvolvimento por meio de processos eficientes e melhoria contínua de processos. Uma classificação do Six Sigma significa que o produto está 99,99966% livre de defeitos. Quando você tem um processo com uma classificação do Six Sigma, significa que se pode esperar que cada produto entregue por meio desse processo alcance o mesmo resultado.
Lean Six Sigma
O Lean Six Sigma tenta combinar as abordagens Lean e Six Sigma, eliminando desperdícios para tornar os processos mais eficientes e entregando alto valor e poucos defeitos ao cliente.
Gerenciamento de projetos baseado em processos
No gerenciamento de projetos baseado em processos, o foco é alinhar cada projeto com a missão e os valores corporativos. Os projetos são englobados na estratégia corporativa. Consequentemente, tais aspectos tradicionais da análise do projeto, como as métricas, são usados para determinar o quão próximo esse objetivo é atingido.
PRINCE2
O método PRINCE2 é baseado no método PRINCE menos bem sucedido. O Método PRINCE não foi amplamente adotado porque era muito complicado e foi revisado em 1996 para PRINCE2 por um comitê composto por 150 organizações europeias. Embora o PRINCE tenha tido o propósito de reduzir o custo de TI e os excessos de tempo, ele também foi desenvolvido como uma metodologia de gerenciamento de projetos para qualquer tipo de projeto. PRINCE2 fez uma grande revisão em 2009 que tornou o método mais simples e introduziu sete princípios básicos de sucesso do projeto.
PRiSM (Métodos Sustentáveis de Integração de Projetos)
O PRISM se concentra no gerenciamento de projetos socialmente responsáveis. Sua intenção é gerenciar projetos enquanto reduz os impactos negativos no meio ambiente e promove projetos socialmente benéficos.
Realização de benefícios
O método de realização de benefícios é todo sobre o cliente. Do início ao fim, o método busca garantir que o cliente tenha o máximo de benefícios do que pode ser entregue acima e além do custo e do cronograma.
Muitos métodos de gerenciamento de projetos é igual a muitas oportunidades
Existem muitos métodos no mundo do gerenciamento de projetos. A maioria cresceu em torno de novas abordagens e necessidades variadas que só se tornaram aparentes à medida que a indústria de software se tornou mais complexa (variedade de métodos e idiomas) e também mais fácil (maior facilidade de escrever código). Os métodos antigos de gerenciamento de projetos, no entanto, ainda mantêm seu valor nos ambientes certos, como é evidenciado pelas empresas que ainda desenvolvem projetos com o método Waterfall. Muitos clientes ainda querem saber quanto custará e quando terminará antes de concordarem com o desenvolvimento, e também querem saber o que estará no produto. Sem essas informações vitais, como eles saberiam se a entrega tem algum valor comercial?
Por que o Smartsheet é uma ferramenta útil para o gerenciamento de projetos Waterfall
Do gerenciamento de tarefas simples e planejamento de projetos à gestão de portfólio e recursos complexos, o Smartsheet ajuda a melhorar a colaboração e acelerar a velocidade do trabalho — aumentando sua produtividade. 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. Experimente o Smartsheet gratuitamente hoje mesmo.