freeCodeCamp/guide/portuguese/agile/moscow/index.md

3.6 KiB

title localeTitle
Moscow Moscou

Moscou

Método MoSCoW

Um dos significados dessa palavra é o método MoSCoW - uma técnica de priorização usada em gerenciamento, análise de negócios, gerenciamento de projetos e desenvolvimento de software para alcançar um entendimento comum com os stakeholders sobre a importância que eles atribuem à entrega de cada requisito - também conhecido como Priorização MoSCoW ou análise MoSCoW.

Priorização dos requisitos MoSCoW

Todos os requisitos são importantes, mas eles são priorizados para oferecer os maiores e mais imediatos benefícios comerciais no início. Inicialmente, os desenvolvedores tentarão entregar todos os requisitos Deve ter, Dever e Poder, mas os requisitos Deve e Poder serão os primeiros a serem removidos se a escala de tempo da entrega parecer ameaçada.

O simples significado inglês das categorias de priorização tem valor em 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 geralmente entendidas como:

Deve ter

Requirements labeled as Must have are critical to the current delivery timebox in order for it to be a success. If even one Must have requirement is not included, the project delivery should be considered a failure. MUST can also be considered an acronym for the Minimum Usable SubseT. 

Deveria

Requirements labeled as Should have are important but not necessary for delivery in the current delivery timebox. While Should have requirements can be as important as Must have, they are often not as time-critical or there may be another way to satisfy the requirement, so that it can be held back until a future delivery timebox. 

Poderia ter

Requirements labeled as Could have are desirable but not necessary, and could improve user experience or customer satisfaction for little development cost. These will typically be included if time and resources permit. 

Não terá

Requirements labeled as Won't have have been agreed by stakeholders as the least-critical, lowest-payback items, or not appropriate at that time. As a result, Won't have requirements are not planned into the schedule for the next delivery timebox. Won't have requirements are either dropped or reconsidered for inclusion in a later timebox. 

O MoSCoW é um método de granulação grossa para priorizar (categorizar) os itens do Backlog do Produto (ou requisitos, casos de uso, histórias do usuário ... dependendo da metodologia usada). MoSCoW é frequentemente usado com timeboxing, onde um prazo é fixado de modo que o foco deve estar nos requisitos mais importantes. O termo MoSCoW em si é um acrônimo derivado da primeira letra de cada uma das quatro categorias de priorização (deve ter, deve ter, pode ter e não terá):

  • Deve ter : Crítico para o timebox de entrega atual para que seja um sucesso. É tipicamente parte do MVP (Minimum Viable Product).
  • Deveria ter : Importante, mas não necessário, para entrega na timebox de entrega atual.
  • Poderia ter : Desejável mas não necessário, uma melhoria.
  • Não terá : itens menos críticos e de menor retorno, ou não são apropriados no momento.

Ao priorizar desta forma, uma definição comum do projeto pode ser alcançada e as expectativas das partes interessadas definidas de acordo. Note que MoSCoW é um pouco negligente sobre como distinguir a categoria de um item e quando algo será feito, se não neste timebox.

Mais Informações:

Wikipedia