O método Moscow é uma técnica de priorização de requisitos usada em gerenciamento, análise de negócios, gerenciamento de projetos e desenvolvimento de software. Tem o objetivo de chegar a um entendimento comum com as partes interessadas sobre a importância que atribuem à entrega de cada requisito. Este método também é conhecido como priorização MoSCoW ou análise MoSCoW .
O termo Moscow é um acrônimo, vindo do inglês, derivado da primeira letra de cada uma das quatro categorias de priorização:
As letras O no acrônimo são adicionadas para tornar a palavra pronunciável. As letras Os podem estar minúsculas para indicar que eles não representam nada no método, mas a palavra capitalizada MOSCOW também é usada.
Este método de priorização foi desenvolvido por Dai Clegg[1] em 1994 para uso em Rapid Application Development (RAD). Foi usado extensivamente pela primeira vez com o framework ágil de gerenciamento de projetos Dynamic Systems Development Method (DSDM)[2] partir de 2002.
MoSCoW é frequentemente usado junto com uma priorização de tempo, onde um prazo é fixado para focar nos requisitos mais importantes e, como tal, é uma técnica comumente usada em abordagens de desenvolvimento ágil de software , como Scrum, desenvolvimento rápido de aplicativos (RAD) e DSDM .
Todos os requisitos são importantes, mas são priorizados para fornecer os maiores e benefícios mais imediatos no início. Os desenvolvedores tentarão inicialmente entregar todos os requisitos Must have, Should have e Could have, mas os requisitos Should and Could serão os primeiros a ser removidos se o prazo de entrega parecer ameaçado.
De forma simples, essas categorias de priorização são importantes para fazer com que os clientes entendam melhor o impacto da definição de uma prioridade, em comparação com alternativas como Alta, Média e Baixa.
As categorias são normalmente entendidas como: [3]
Às vezes, W é usado para significar Desejo (Would Have), ou seja, ainda possível, mas improvável de ser incluído (e menos provável do que Could Have). Isso é então diferenciado de X para Excluídos para itens que não estão explicitamente incluídos. No entanto, esse uso é incorreto, pois esta última prioridade está claramente declarando que algo está fora do escopo de entrega. (O BCS nas edições 3 e 4 do Livro de Análise de Negócios descreve 'W' como 'Quero ter, mas não desta vez'
No desenvolvimento de novos produtos, especialmente aqueles que seguem abordagens ágeis de desenvolvimento de software, sempre há mais a fazer do que tempo ou financiamento para permitir (daí a necessidade de priorização).
Por exemplo, se uma equipe tiver muitas estórias em potencial (ou seja, histórias de alto nível) para o próximo lançamento de seu produto, eles podem usar o método MoSCoW para selecionar quais estórias são obrigatórias, quais deveriam-se ter e assim por diante; o produto mínimo viável (ou MVP) seriam todas aquelas estórias marcadas como Must have.[4] Muitas vezes, uma equipe descobrirá que, mesmo depois de identificar seu MVP, ela tem muito trabalho para sua capacidade esperada. Em tais casos, a equipe poderia, então, usar o método MoSCow para selecionar quais recursos (ou estórias, se esse for o subconjunto de épicos em sua organização) são Must Have, Should Have, e assim por diante; as características mínimas comercializáveis (ou MMF) seriam todas aquelas marcadas como Obrigatórias.[5] Se houver capacidade suficiente após a seleção do MVP ou MMF, a equipe pode então planejar incluir os itens Should Have e até Could Have também.[6]
As críticas ao método MoSCoW incluem:
Outros métodos usados para priorização de produtos incluem: [9]