Por que Scrum: Processo Definido vs Processo Empírico

Existem projetos que são bastante diretos e relativamente previsíveis, onde podem ser aplicadas ferramentas racionais de planejamento e tomada de decisão. Outros projetos mais complexos ou imprevisíveis exigem uma abordagem diferente, mais baseada na auto-organização e inovação.

A maioria dos projetos de desenvolvimento de software são considerados complexos e imprevisíveis por natureza devido à convergência de três fatores: pessoas, requisitos e tecnologia. As várias abordagens usadas para entregar e gerenciar projetos podem ser mais facilmente compreendidas no contexto de modelos de controle de processos e complexidade do projeto.

Processo Definido — Uma Abordagem Tradicional Orientada a Planos

Tradicionalmente, uma vez que um projeto é iniciado, um pacote de requisitos é criado e então “assinado”. O gerente de projeto assume que essa aprovação resulta em um conjunto fixo de requisitos e que agora o planejamento pode começar. O gerente de projeto estima quanto tempo levará para concluir os requisitos e cria o plano do projeto. O plano prevê que o projeto será concluído em uma determinada data e essa data é comunicada de volta ao cliente.

A falha fundamental nessa abordagem é que o plano, que orienta tudo, é baseado na suposição de que os requisitos são fixos e não serão alterados. A experiência nos mostrou que esse nunca é o caso; os requisitos nunca são fixos — eles sempre mudam. Quando os requisitos mudam, o plano é afetado; e, como resultado, a data de conclusão também precisa mudar. Infelizmente, em muitos casos, isso é impossível, e a equipe precisa entregar na data em que se comprometeu. É quando ocorre uma grande crise e o projeto começa a sair do controle.

Processo Empírico — Abordagem Ágil Orientada ao Valor

A abordagem ágil orientada por valor é baseada no  empirismo  que muda toda a mentalidade. Ele assume desde o início que quaisquer requisitos existentes no início não são fixos e que eles serão alterados.

A mentalidade ágil também pressupõe que você deve entregar em uma determinada data. Essa abordagem fixa o tempo e os recursos e deixa os requisitos indeterminados. Para nós, essa abordagem se assemelha mais à realidade da criação de software. Agora, toda a noção de valor orientado faz todo o sentido. Quando você tem uma quantidade fixa de tempo em que não tem certeza se pode entregar todos os requisitos (porque eles vão mudar e, portanto, o tempo necessário para terminá-los mudará), a reação natural é priorizar os requisitos e terminar primeiro aqueles que agregam mais valor ao cliente.

Você pode estar pensando: “E os requisitos que não foram concluídos até a data de entrega?” Essa é a razão pela qual você usa a abordagem orientada por valor. Você reconhece o fato de que nem todos os requisitos serão concluídos até a data de entrega. A questão importante a ser feita é se você forneceu recursos suficientes para dar suporte a um sistema que agrega valor ao cliente.

Taxa de falha de projetos de software

O Relatório CHAOS 2015   foi lançado recentemente pelo  Standish Group . Os Relatórios CHAOS são publicados todos os anos desde 1994 e são um retrato do estado da indústria de desenvolvimento de software. Este ano, o relatório estudou 50.000 projetos em todo o mundo, variando de pequenas melhorias a implementações maciças de reengenharia de sistemas. Este ano, o relatório inclui uma definição aprimorada de sucesso, analisando alguns fatores adicionais que foram abordados em pesquisas anteriores.

Os resultados indicam que ainda há trabalho a ser feito para alcançar resultados bem-sucedidos de projetos de desenvolvimento de software. Esta tabela resume os resultados dos projetos nos últimos cinco anos usando a nova definição de fatores de sucesso (no prazo, dentro do orçamento com resultado satisfatório).

Com a adoção de métodos de desenvolvimento ágil nos últimos anos, foi possível comparar os resultados do projeto entre projetos em cascata ágeis e tradicionais. Em todos os tamanhos de projeto, as abordagens ágeis resultaram em projetos mais bem-sucedidos e menos falhas definitivas, conforme mostrado nesta tabela

Quais são os problemas da abordagem tradicional?

A abordagem tradicional baseada em planos não é falha em si mesma; simplesmente não é adequado para a indústria de software de hoje. A abordagem baseada em planos foi originalmente baseada em conceitos tradicionais de gerenciamento de projetos, originados da indústria da construção. Na indústria da construção, a abordagem baseada em planos é adequada: os projetos, que são os requisitos, são fixos e provavelmente não serão alterados enquanto o edifício estiver sendo construído. Você pode estimar quanto tempo levará para construir os pilares de aço, despejar o concreto e assim por diante.

A razão pela qual a abordagem tradicional baseada em planos é adequada para a indústria da construção, mas não para a indústria de software, está relacionada à diferença na maneira como controlamos sistemas empíricos (como desenvolvimento de software) e na maneira como controlamos sistemas definidos (como construção ou manufatura). ). A Tabela abaixo mostra as diferenças entre as características de um processo definido e as de um processo empírico.

Depois de ler a tabela, é fácil ver que o desenvolvimento de software é definitivamente um processo empírico, não um processo definido. O problema é que abordamos o desenvolvimento de software há anos como um processo definido — e essa abordagem não funciona.

Referências

1. Relatório de Caos do Standish Group 2015
2. Tornando-se ágil em uma palavra imperfeita — por Greg Smith & Ahmed Sidky

Outras leituras do Scrum

• Scrum em 3 minutos
• Quais são os 5 Valores do Scrum?
• Qual é a evolução do Scrum?
• Gerenciamento de Projetos Clássico x Gerenciamento de Projetos Ágil
• Por que o Scrum é difícil de dominar?
• O que é velocidade no Scrum?
• O que é Ágil? O que é Scrum?