MoSCoW method

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:

• M - Must have. Deve-se ter este requisito, é obrigatório.
• S - Should have. Deveria ter este requisito. Menos importante que Must Have.
• C - Could have. Poderia ter este requisito.
• W - Won't have. Não terá este requisito.

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.

História

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 .

Priorização de requisitos

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]

Must Have

Os requisitos rotulados como Obrigatório são críticos para o prazo de entrega atual para que o projeto seja um sucesso. Se ao menos um requisito obrigatório não for incluído, a entrega do projeto deve ser considerada uma falha (nota: os requisitos podem ser rebaixados de Deve ter, se todas as partes interessadas estiverem de acordo; por exemplo, quando novos requisitos são considerados mais importantes).

Should Have

Os requisitos identificados como deveria-se ter são importantes, mas não necessários para a entrega no planejamento atual. Embora os requisitos Should have possam ser tão importantes quanto os Must have, eles geralmente não são tão críticos em termos de tempo e pode-se haver outra maneira de satisfazer o requisito de forma ou possa ser retido até um futuro prazo de entrega.

Could Have

Requisitos rotulados como poderia-se ter são desejáveis, mas não necessários e podem melhorar a experiência do usuário ou a satisfação do cliente por um pequeno custo de desenvolvimento. Normalmente, eles serão incluídos se o tempo e os recursos permitirem.

Won't Have (desta vez)

Os requisitos rotulados como Não terá, foram acordados pelas partes interessadas como os itens menos críticos, de menor retorno, menor interesse ou não apropriados naquele momento. Como resultado, esses requisitos não estão planejados para serem entregues no próximo prazo. Esses requisitos eliminados são reconsiderados para inclusão em uma entrega posterior.

Variantes

À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'

Use no desenvolvimento de novos produtos

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]

Crítica

As críticas ao método MoSCoW incluem:

• Não ajuda a decidir entre vários requisitos com a mesma classificação.
• Falta de raciocínio em torno de como classificar requisitos concorrentes: por que algo é Must Have e não Should Have.
• Ambiguidade em relação ao tempo, especialmente na categoria Won't Have: se não está neste lançamento ou nunca será um requisito do projeto.^[7]
• Potencial para foco político na construção de novos recursos em vez de melhorias técnicas (como refatoração).^[8]

Outros métodos

Outros métodos usados para priorização de produtos incluem: ^[9]

• Modelo de pontuação RICE
• Custo do atraso
• Método PriX
• Mapeamento de história