Para quais tipos de projetos o SCRUM é considerado adequado?

Eu tenho usado o SCRUM em três projetos diferentes nos últimos quatro anos. Uma das vantagens da SCRUM parece ser sua flexibilidade e adaptabilidade, por exemplo, a mudança nas exigências dos clientes. Outra vantagem é que o gerenciamento pode acompanhar facilmente o progresso de um projeto.

A flexibilidade do SCRUM pode ser uma vantagem, por exemplo, ao implementar um aplicativo da Web, onde os requisitos mudam muito rapidamente e os clientes realmente entendem o que desejam depois de verem um protótipo.

Por outro lado, existem outros tipos de projetos de software (por exemplo, na indústria aeroespacial) em que os requisitos são bastante fixos: você obtém um documento de especificação de requisitos e precisa voltar seis meses depois com o software em funcionamento e a documentação completa. Para esse tipo de projeto, duvido que seja necessária a flexibilidade oferecida pelo SCRUM (no sentido de que você não precisa criar protótipos e mostrá-los ao cliente para obter feedback sobre os requisitos): você precisa de uma abordagem muito estruturada e sistemática , que provavelmente é repetido várias vezes para cada projeto com pouco espaço para surpresa.

Então, o SCRUM é considerado por seus proponentes uma metodologia de desenvolvimento de software de uso geral ou é especialmente adequado para determinadas categorias de projetos ou áreas de aplicação?

Por exemplo, recentemente visitei o site de uma empresa produtora de software para a indústria aeroespacial e notei que eles estavam usando o modelo V. Um proponente do SCRUM diria que o SCRUM é menos adequado para esse tipo de projeto ou sugeriria que essa empresa tentasse mudar para o SCRUM?

Observe que não estou pedindo a opinião dos leitores deste fórum, mas quero saber qual é a opinião estabelecida entre os proponentes do SCRUM: o SCRUM é considerado de uso geral ou adequado apenas para determinadas classes de projetos? Nos últimos casos, para que tipos de projetos?

O SCRUM é uma metodologia de uso geral que pode funcionar bem para a maioria dos projetos e tamanhos de equipe, mas é menos útil para equipes grandes que realizam projetos muito grandes. O grande número de pessoas envolvidas em alguns projetos torna qualquer metodologia ágil extremamente difícil ou quase impossível, porque é necessária uma estrutura mais rígida para manter a ordem. A indústria aeroespacial é um bom exemplo de uma indústria que tende a ter grandes projetos em que abordagens ágeis nem sempre são viáveis.

Qualquer tipo de projeto! Funciona bem para projetos grandes e pequenos.

As pessoas o usaram para planejar casamentos, mudar de casa etc. Portanto, nem mesmo apenas projetos de software.

Acredito firmemente que existem muitas operações comerciais que poderiam se beneficiar de uma abordagem semelhante ao Scrum.

Observe que o Scrum não é uma metodologia, mas uma estrutura.

O Scrum funcionará melhor em uma equipe multifuncional de 5 a 9 desenvolvedores trabalhando em um projeto de tamanho médio a grande (de 4 meses a vários anos). Se o seu projeto for maior, você poderá escalar com o Scrum of Scrums .

Não discutirei a coisa multifuncional aqui, mas aqui está o que o Guia Scrum oficial está dizendo para o tamanho da equipe:

O tamanho ideal da equipe de desenvolvimento é pequeno o suficiente para permanecer ágil e grande o suficiente para concluir um trabalho significativo. Menos de três membros da equipe de desenvolvimento diminuem a interação e resultam em menores ganhos de produtividade. As equipes de desenvolvimento menores podem encontrar restrições de habilidades durante o Sprint, fazendo com que a equipe de desenvolvimento não consiga fornecer um incremento potencialmente liberável. Ter mais de nove membros requer muita coordenação. As grandes equipes de desenvolvimento geram muita complexidade para um processo empírico gerenciar. As funções Dono do Produto e Scrum Master não estão incluídas nesta contagem, a menos que também estejam executando o trabalho do Backlog da Sprint

Um sprint é de cerca de um mês.

Sprints são limitados a um mês. Quando o horizonte de uma Sprint é muito longo, a definição do que está sendo construído pode mudar, a complexidade pode aumentar e o risco pode aumentar. Os sprints permitem a previsibilidade, garantindo a inspeção e a adaptação do progresso em direção a uma meta pelo menos a cada mês. Os sprints também limitam o risco a um mês civil de custo.

Eu acho que não faz sentido usar uma estrutura baseada em um processo iterativo com projetos menores que 4 meses. 4 meses = 4 sprints. Você também deve considerar que obtém uma velocidade mais precisa após 3 sprints.

Dito isto, eu pessoalmente uso uma versão limitada do Scrum para projetos menores. Mas você não pode realmente chamá-lo de Scrum então. Nesse caso específico, você está usando alguns princípios fundamentais do Scrum em sua própria implementação da estrutura.

para iniciantes, pense no SCRUM como apenas um conjunto de diretrizes para implementar práticas ágeis. Nunca pense nisso como um 'livro sagrado' de como fazer projetos. Para muitos projetos em que é necessário um fluxo constante de tarefas, o Kanbam é mais apropriado, por exemplo.

Projetos ágeis tendem a cair onde você está realizando projetos que exigem uma data de término fixa ou um custo fixo. Embora você ainda possa executar esses projetos usando métodos Agile, a necessidade de planejar tudo com antecedência para determinar se é provável que você atinja o alvo não é a maneira ágil usual - no ágil, você tende a continuar trabalhando até ficar sem coisas para fazer ou ficar sem tempo para fazê-lo. Para a maioria dos projetos, tudo está bem, pois os requisitos mudam de qualquer maneira durante o projeto.