Gerenciamento de projetos em cascata - Hoje, a maioria das equipes de TI está adotando os sistemas de gerenciamento ágil de projetos. Mas o que eles acabam fazendo é adotar os sistemas Agile Project Management em seus projetos. Isso significa uma combinação dos sistemas tradicionais de gerenciamento de projetos (chamados de sistemas de gerenciamento de projetos em cascata), combinados com os princípios de gerenciamento ágil, conforme detalhado no Manifesto ágil original.
À medida que mais projetos em todo o mundo incorporam práticas de Gerenciamento Ágil de Projetos, isso significa o fim do gerenciamento de projetos em cascata? Todos os projetos de TI acabarão sendo Agile Project Management?
Para entender os diferentes modelos, incluindo o Agile, e usar o mais adequado à sua situação, é importante entender primeiro o que é o sistema tradicional de gerenciamento de projetos, chamado Modelo de Gerenciamento de Projetos em Cascata.
O Modelo de gerenciamento de projeto Waterfall, assim chamado por causa da natureza do processo de fluxo de trabalho, é caracterizado pelo seguinte:
- O produto final é visualizado pela primeira vez em grandes detalhes.
- Em seguida, os estágios do fluxo de trabalho são implementados em sequência:
- Requisitos e análise
- Projeto
- Implementação
- Teste
- Instalação
- Manutenção
- O plano do projeto deve ser infalível porque, uma vez concluída uma etapa na sequência, os desenvolvedores não podem revisar o mesmo sem iniciar o planejamento novamente.
- Há pouco espaço para alterações ou erros e o plano do projeto deve ser seguido diligentemente.
Origem do modelo de gerenciamento de projetos em cascata:
Nos estágios iniciais do setor de TI, não havia modelo específico para o desenvolvimento de software.
Portanto, a indústria adotou o modelo de fluxo de trabalho seqüencial usado nas indústrias de fabricação e construção. Essas indústrias tinham estágios de trabalho bem definidos e desenvolveram um modelo que atendia à necessidade de um rígido controle de custos. Portanto, o modelo da indústria de hardware foi aplicado à indústria de software.
Winston W Royce apresentou esse modelo pela primeira vez em 1970, mas ele não usou o termo "Gerenciamento de projetos em cascata". De fato, ele apresentou o modelo como falho. A representação pictórica do modelo parecia uma cascata. Thomas E. Bell e TA Thayer mais tarde usaram o termo "cascata" em seu artigo de 1976, "Requisitos de software: eles são realmente um problema?" E o termo veio para permanecer.
Existem várias variantes deste modelo. As seis fases distintas comumente usadas no Modelo de gerenciamento de projetos Waterfall são explicadas abaixo. No entanto, dependendo do projeto, duas etapas podem ser combinadas.
Vamos considerar o exemplo da construção de uma escola como um exemplo para entender melhor o modelo de gerenciamento de projetos em cascata.
-
Requisitos e fase de análise:
Primeiro, precisamos saber exatamente o que estamos projetando. Para isso, podemos querer:
- Conduza discussões detalhadas com o cliente
- Tente visualizar claramente o produto com os mínimos detalhes
- Analisar quais componentes de hardware e software são necessários
- Liste os detalhes que incluem: o problema que o produto deve resolver, as restrições do cliente, o nível de desempenho e a compatibilidade com os sistemas já existentes.
- Conduza estudos de caso de um produto similar.
- Considere os requisitos de cada parte interessada
- Liste as especificações no documento de requisitos do produto, que forma a entrada para a próxima etapa.
Em nosso exemplo de construção de uma escola, nesta etapa, listamos o número de salas de aula, o material a ser usado para a construção, as pessoas necessárias e a infraestrutura já existente. Além disso, anotamos o que a administração da escola exige (sala de escritório, sala da equipe) e o que os alunos precisam (banheiros melhores, playgrounds)
-
Projeto:
No estágio de design, tudo o que foi visualizado no primeiro estágio é transformado em um modelo.
Nos projetos de TI, isso consiste em definir:
- O hardware que será usado
- A plataforma de software a ser usada, incluindo implantação local ou na nuvem
- A arquitetura do software, incluindo os diferentes componentes e módulos a serem criados
- Entradas necessárias para o projeto funcionar com sucesso
- Resultados esperados (idealmente, isso será sincronizado com os Requisitos detalhados no estágio anterior)
Existem dois tipos de design que entram em jogo em um projeto de software:
- Design lógico
- Projeto físico
Projeto lógico:
Isso inclui os dados e processos básicos que serão incluídos no projeto. Ele detalha o design de formulários e relatórios, o design da interface e o design do banco de dados. Por exemplo, para um site de bilhetes de trem, esse design determinará como todo o processo funcionará: a tela na qual o viajante insere seus detalhes e como esses dados fluirão para o banco de dados e também que tipo de banco de dados armazenará esses detalhes.
Projeto físico:
Isso está relacionado ao design do banco de dados físico, aos programas e processos e aos sistemas distribuídos. Isso é feito após o Design Lógico e incluirá "como" o projeto será realizado: o hardware, a plataforma na qual será desenvolvido, os vários bancos de dados, telas e formulários que serão usados, etc.
-
Implementação:
- É aqui que o desenvolvimento real do software / sistema ocorre.
- A entrada para este estágio são as especificações de design fornecidas pelo estágio anterior.
- A saída é um ou mais dos componentes do produto criados de acordo com as especificações, depurados, testados e integrados para satisfazer a arquitetura do sistema.
- Esse estágio geralmente é resolvido pela equipe de desenvolvimento, que consiste em programadores, designers de interface e outros especialistas, e as ferramentas utilizadas são compiladores, depuradores, intérpretes e editores de mídia.
- Esse estágio geralmente leva o tempo máximo e é importante acompanhar diligentemente os processos e o design. Mudanças no design nesse estágio são difíceis no Gerenciamento de projetos em cascata.
- Para um projeto grande que envolve várias equipes, o controle de versão é recomendado para rastrear alterações na árvore de códigos e reverter para as capturas instantâneas anteriores para tratamento de erros.
- No nosso exemplo: A construção real do edifício usando mão de obra e materiais é feita nesta fase.
-
Teste:
Os testes podem ser feitos para o produto como um todo ou para componentes individuais. Os "casos de teste" podem ser verificados para ver se o produto pode ser entregue como prometido. Pode haver testes de módulos, testes de sistema do produto integrado e testes de aceitação. O teste de aceitação envolve testar o produto quanto a brechas pelo usuário final ou pelo cliente. Os defeitos são anotados para a equipe de implementação corrigir. Depois que as correções são feitas, uma documentação formal do produto é preparada.
No exemplo, a infraestrutura da escola é testada, provavelmente por uma equipe de auditoria. Em alguns casos, os professores são convidados a entrar e usar as instalações para fornecer feedback.
-
Instalação:
Após a conclusão do teste do produto em todos os aspectos, ele pode ser liberado no mercado ou instalado nas instalações do cliente. Nesta fase, a documentação completa do produto também é entregue.
No caso de nossa escola, ela é formalmente inaugurada (de preferência por um figurão!) E a escola inicia suas operações!
-
Manutenção:
Nesse estágio, a equipe de TI corrige quaisquer problemas que possam surgir quando o cliente realmente começar a usar o produto ou quando houver um aprimoramento do produto. Uma boa documentação é a espinha dorsal da manutenção. Os problemas são corrigidos através da modificação de códigos, chamados "patches".
Se grandes mudanças forem necessárias, o projeto poderá retornar à equipe de desenvolvimento como um novo projeto.
Em nosso exemplo, a escola precisa de manutenção regular, principalmente de infraestrutura, por exemplo, fiação elétrica defeituosa ou vazamento de banheiros. Esses problemas precisam ser resolvidos de tempos em tempos.
Como você pode ver até agora, os estágios no Gerenciamento de projetos de desenvolvimento em cascata são distintos e, embora geralmente haja uma interação constante com o cliente, é principalmente discutir o progresso do projeto, não o design ou os requisitos. No entanto, o modelo de gerenciamento de projetos em cascata serviu adequadamente o setor de TI por muitos anos e, para a maioria dos projetos, os estágios ainda são bons, embora não sejam tão rígidos.
Existem, no entanto, vários projetos para os quais o Modelo de gerenciamento de projetos Waterfall é altamente adequado.
Em que tipo de projeto o Waterfall Project Management é adequado?
Definição do produto:
Primeiro, o resultado final (produto) deve ser capaz de ser bem definido no início. Projetos nos quais o proprietário do produto não tem muita certeza sobre as especificações exatas do produto desejado podem fazer bem em seguir as práticas de gerenciamento ágil.
Documentação:
O projeto deve ser aquele que pode ser documentado. A documentação é um requisito importante do modelo de gerenciamento de projeto Waterfall. Os requisitos do produto, o design e o código-fonte devem ser claramente documentados em todas as etapas. Se os membros originais da equipe sairem, isso formará o guia para a continuidade do projeto.
Tempo e recursos:
Não deve haver urgência imediata para liberar o produto. Os cronogramas são definidos no início do projeto e a equipe deve poder aderir a eles. Além disso, deve haver amplos recursos disponíveis em termos de mão de obra e tecnologia.
Risco e incerteza:
As Ferramentas de Gerenciamento de Projetos Waterfall não funcionam bem em um ambiente de risco e incerteza. Por exemplo, o aplicativo Mobile é um tipo de produto que enfrenta incerteza constante em termos de aceitação do cliente e concorrência de aplicativos semelhantes.
Estágios claramente definidos:
Os estágios do sistema devem ser bem definidos, pois precisam ser concluídos em sequência e não pode haver sobreposição.
Quando uma nova versão do software existente está sendo criada.
Fora do domínio de TI, o Modelo de gerenciamento de projetos Waterfall foi usado com sucesso em grandes projetos, como
- Construção de avião
- Projetos de infraestrutura, como pontes
- Fabricação de equipamentos de defesa
- Sistemas de saúde em hospitais
Nos projetos de TI, o Waterfall Project Management é especialmente adequado para os projetos nos quais é necessário hardware externo. As especificações disso não podem ser alteradas no meio do caminho, pois isso resultaria em perda de milhões de dólares.
Quando as insuficiências no gerenciamento de projetos em cascata se tornaram aparentes no setor de software, houve uma grande reflexão sobre como as equipes de TI podem oferecer o máximo valor aos clientes, garantindo flexibilidade no processo de fluxo de trabalho.
E, assim, nasceu o Sistema Ágil de Gerenciamento de Projetos, que está sendo adotado pela maioria das empresas de software.
Gerenciamento de projetos em cascata vs sistemas ágeis:
O sistema Agile Project Management é um modelo flexível que se tornou popular nos anos 90. Envolve dividir o projeto em “miniprojetos” chamados sprints e trabalhar de forma independente em cada um deles. Esse tipo de modelo permite que os desenvolvedores incorporem as alterações necessárias mais rapidamente e é muito eficaz quando o ambiente do cliente é variável.
Os aspectos positivos das etapas do Gerenciamento de projetos em cascata são:
- Como o produto final é conhecido em sua totalidade, o planejamento e o design são inequívocos.
- Os possíveis problemas que podem surgir no projeto podem ser resolvidos durante a própria fase de design; antes que qualquer código tenha sido escrito.
- Medir o progresso do trabalho é fácil, pois as etapas são bem definidas.
- A estabilidade da equipe existe desde que a equipe permaneça até o final do projeto. No caso do Agile, a equipe muda constantemente e isso requer uma certa quantidade de ajuste.
- A documentação é extensa, facilitando o gerenciamento das equipes se um membro for embora.
- Os desenvolvedores acham esse modelo mais fácil de trabalhar, pois é fácil de entender,
- Após a fase de Requisitos, a participação ativa do cliente final é necessária apenas na fase de teste. Isso ocorre porque todos os requisitos foram discutidos esfarrapados, sem deixar ambiguidade.
- O produto pode ser desenvolvido como um todo, em vez de desenvolvê-lo em partes.
- Os problemas de gerenciamento de contratos e clientes são melhor tratados no Modelo de gerenciamento de projetos Waterfall.
Os aspectos positivos do Gerenciamento Ágil de Projetos são:
- O cliente pode interagir com a equipe do projeto durante todo o ciclo e fazer alterações no produto de tempos em tempos para se adequar ao ambiente em mudança.
- Se o produto precisar ser lançado muito em breve devido a circunstâncias do mercado, a equipe do Agile Project Management poderá lançar uma versão básica que poderá ter versões avançadas posteriormente.
- O sistema é bastante transparente do ponto de vista do cliente e ele tem uma boa idéia do estágio em que está seu produto.
- Como o cliente fornece a prioridade dos recursos, a equipe sabe que precisa se concentrar nos recursos que oferecem o maior valor comercial.
- O processo tem seu próprio momento.
- As equipes são fluidas e flexíveis, permitindo a ideação de todos os membros
- A documentação é mínima e, portanto, o tempo é liberado dessas tarefas.
Após muitos anos de ambos os modelos existentes lado a lado, é evidente que:
O Modelo de gerenciamento de projetos Waterfall é eficaz para o gerenciamento de projetos, onde, uma vez concluído o projeto, há mudanças mínimas.
O Gerenciamento Ágil de Projetos é mais adequado ao Gerenciamento de Produtos, onde é importante ser flexível às mudanças.
Independentemente disso, o sistema de gerenciamento de projetos Waterfall continua sendo um componente importante da maioria dos projetos de TI. Não se pode dizer com certeza que um projeto em particular segue estritamente as Práticas de Gerenciamento Ágil. Geralmente, os princípios do Agile são "incorporados" nos projetos de TI.
Alguns Gerenciamento Ágil de Projetos têm Gerentes de Projeto, enquanto estritamente um modelo Agile possui apenas Scrum Masters. Trata-se de combinações híbridas de modelos de gerenciamento de projetos Agile e Waterfall que alguns chamam de projetos "Agifall" ou "Agency Agile".
A popularidade do sistema de gerenciamento de projetos Waterfall também se deve ao fato de que os problemas de gerenciamento de contratos e clientes são melhor tratados pelos métodos de gerenciamento de projetos Waterfall.
Enquanto mais e mais projetos estão sob a dobra Agile Project Management e mais empresas estão vendo os benefícios de um modelo de gerenciamento flexível, a popularidade do modelo de gerenciamento de projetos Waterfall certamente está diminuindo.
No entanto, é difícil prever um futuro para projetos de TI que sejam completamente ágeis, em um futuro próximo. E o Waterfall Project Management, que ajudou a indústria de software desde a sua infância, continuará vivendo em alguns componentes do gerenciamento de projetos pelo menos por mais alguns anos.
Primeira fonte da imagem: picjumbo.com
Artigos relacionados
- 6 etapas úteis do fluxo de trabalho no gerenciamento de projetos em cascata
- Dicas eficazes para discussão em grupo (consultoria especializada)
- Os 10 principais mitos sobre gerenciamento de projetos
- 6 razões eficazes para que todos precisem de um projeto de paixão no trabalho
- Os 5 principais tipos de ferramenta de relatório de gerenciamento de projetos
- Gerenciamento de Produto x Gerenciamento de Marca - Diferenças Úteis