No desenvolvimento de software até a década de 1990, tudo era previsível e simples: uma sequência clara de processos de trabalho, planejamento passo a passo, documentação, testes e implementação do produto final.
Gestão de projetos era excessivamente rígida, e desvios de um plano estrito interrompiam todo o fluxo de trabalho.
Waterfall (modelo em cascata ou modelo “waterfall”) é um modelo de desenvolvimento de software inflexível com uma sequência clara de ações onde a transição para a próxima etapa é impossível até que a anterior esteja totalmente concluída.
O desenvolvimento em Waterfall se parece com um fluxo de processos movendo-se de etapa para etapa com requisitos claros. Nenhuma transição ocorre para a próxima etapa até que a atual esteja concluída.
Na década de 1990, uma família de métodos flexíveis substituiu os rígidos.
Estamos falando, é claro, de Agile (desenvolvimento ágil de software). Essa nova abordagem à metodologia de gestão de projetos entrou no mundo da TI e depois se espalhou para a manufatura, engenharia, desenvolvimento de inteligência artificial, e mais.
Os primeiros métodos flexíveis incluíam:
- RAD (focado em qualidade com um orçamento mínimo e cronograma limitado)
- XP (Extreme Programming com posse coletiva do código)
- Scrum (onde cada membro da equipe é responsável pelo resultado)
- Kanban (visualizando as etapas de desenvolvimento em um quadro), entre outros.
Quatro ideias ágeis que você deve conhecer:
- Pessoas e interações são mais importantes do que processos.
- A colaboração com o cliente é mais importante do que a negociação de contratos.
- Um produto funcional tem prioridade sobre a documentação.
- Responder à mudança é mais importante do que seguir um plano.
| Agile | Waterfall |
|---|---|
| Processos de trabalho flexíveis, permitindo mudanças a qualquer momento | Modelo de desenvolvimento em cascata com uma sequência rígida |
| Um produto funcional é mais importante do que a documentação | A documentação é mais importante do que o produto finalizado |
| Responsabilidade individual de cada membro da equipe pelo resultado | A responsabilidade pelo resultado geral recai sobre a equipe |
| Interação com o cliente durante o desenvolvimento | O cliente não está envolvido no processo |
| Máxima envolvimento do proprietário do produto no processo | Envolvimento mínimo do proprietário do produto |
| O fluxo de trabalho é dividido em sprints curtos, geralmente de 1 semana a 1 mês | Cada fluxo de trabalho é uma fase separada que dura até que os testes e aprovações estejam completos |
Sistemas de Gestão de Projetos Populares em Agile
Vamos explorar aqueles que “criaram raízes” e são mais comumente usados no desenvolvimento de software.
Scrum
Uma abordagem flexível para desenvolvimento de software onde uma tarefa equivale a um sprint. Um sprint no Scrum pode durar de 1 semana a 1 mês.
Para quem é o Scrum?
Para pequenas empresas ou departamentos onde o proprietário da empresa ou o chefe do departamento pode integrar fisicamente no processo de trabalho e participar ativamente. Este método também é ideal para startups.
Usar Scrum na gestão de projetos torna difícil identificar a responsabilidade por tarefas incompletas. Cada membro da equipe é responsável pelo resultado, priorizando a auto-organização para moldar os fluxos de trabalho.
A equipe que escolhe o Scrum para a gestão de projetos deve estar preparada para a máxima flexibilidade. Por exemplo, se um membro da equipe “sai do processo” temporariamente, outro deve assumir suas tarefas.
Scrum master – o gerente de projeto e uma figura chave na equipe, supervisionando a organização dos processos de negócios, reuniões, motivação da equipe, respostas rápidas a mudanças e resolução de problemas.
+ Prós
O software é desenvolvido mais rápido, com o máximo envolvimento da equipe, reduzindo os custos de desenvolvimento por meio da divisão do fluxo de trabalho em sprints curtos.— Contras
O Scrum não possui regras ou requisitos rígidos mas permite espaço para experimentação, mudanças de orçamento e cronogramas. Não é adequado para clientes que precisam de um plano claro e contrato formal.Por exemplo, se você precisa criar um produto para uma organização governamental onde a assinatura do contrato é uma prioridade, o Scrum não é adequado. A principal prioridade é o produto finalizado, seguida da documentação, relatórios de trabalho, etc.
Exemplo de Gestão de Projetos Usando Scrum
Suponha que a tarefa seja criar software no menor tempo possível. O fluxo de trabalho é dividido em sprints, cada um terminando com uma demonstração do resultado concluído. Reuniões são realizadas para revisar os resultados intermediários e passar para o próximo sprint.
Monitorar a velocidade de conclusão dos sprints é crucial no Scrum.
Para entender quanto tempo durará um sprint, a equipe pode iniciar um cronômetro no início. Rastrear o tempo gasto em cada tarefa fornece insights sobre a duração necessária para tarefas semelhantes.
Kanban
Uma representação visual do fluxo de trabalho e movimento passo a passo das tarefas de “Em Progresso” para “Concluído.” Entre esses dois estados, pode haver várias outras etapas: “Desenvolvimento,” “Teste,” “Otimização,” etc. O Kanban aparece como um quadro onde as tarefas são movidas de estação para estação. Quando uma tarefa atinge a última estação “Concluído”, ela é finalizada.
Scrum e Kanban são abordagens flexíveis para a gestão de projetos. No entanto, Kanban é ainda mais flexível porque:
- Permite tarefas novas súbitas e “trocas” entre elas.
- A responsabilidade coletiva pelo resultado aumenta a eficiência.
- Tarefas não planejadas vão para o backlog, um espaço de armazenamento para todas as tarefas que ainda não estão em progresso. O backlog se parece com qualquer outra etapa do processo de trabalho e contém tarefas prontas para trabalho quando outras etapas terminam antes do esperado.
+ Prós
Diferente do Scrum, o Kanban não exige reuniões regulares, discussões ou revisões de sprints, economizando tempo e aumentando a eficiência onde todas as etapas são visíveis no quadro.— Contras
O Kanban é desafiador para projetos grandes onde resultados intermediários são cruciais, partindo o processo em sprints, e é necessário a pré-aprovação de um plano de ação. O Kanban é mais adequado para projetos e tarefas de curto prazo.Exemplo de Gestão de Projetos Usando Kanban
A tarefa é gravar um vídeo instrucional para um cliente. Isso envolverá a criação de várias tarefas: “Escrita de Roteiro,” “Filmagem,” “Edição Bruta,” “Pós-Processamento.” Cada tarefa será uma coluna separada no quadro Kanban.
Kanban ou Scrum? Qual Sistema de Gestão de Projetos Você Precisa?
O Scrum proporciona mais controle e gerenciabilidade no início do desenvolvimento de um novo produto. Se Kanban oferece máxima flexibilidade, Scrum foca mais em controle e gestão. Quando os processos estão em andamento, o Kanban vem para o resgate. É perfeito para trabalhar com tarefas repetitivas.Como Escolher uma Ferramenta de Gestão de Projetos?
A ferramenta de gestão de tarefas certa é metade do sucesso. Depois de escolher um método de gestão de projetos, é crucial transitar o trabalho e as tarefas para o sistema escolhido.
6 Sinais de que Você Escolheu o Gerenciador de Tarefas Certo:
- A equipe migrou perfeitamente todos os fluxos de trabalho para a conta.
- A funcionalidade é intuitiva e utilizada pelos membros da equipe.
- A equipe usa facilmente uma das abordagens de gestão flexíveis: Scrum ou Kanban.
- A sistematização do fluxo de trabalho é estabelecida, aumentando a eficiência geral.
- A comunicação da equipe se torna mais coordenada: projetos, tarefas e comentários não são perdidos.
- O cliente recebe relatórios transparentes sobre tarefas e projetos, acompanhando os fluxos de trabalho se desejar.