Solucionado (ver solução)
Solucionado
(ver solução)
1
resposta

MoSCoW -> W significa "want" ou "won't have"?

Olá!

Eu estudei engenharia de software há uns anos atrás. Agora surgiu uma demanda no trabalho e resolvi vir dar uma relembrada e ver como a Alura abordava o assunto. Quando a técnica MoSCoW foi discutida, eu achei estranho o W ser mostrado como "want". Já que o Co (could have) já traz essa ideia de uma tarefa que a implementação é desejável, mas não essencial para o momento.

Uma busca rápida na internet, e todas as fontes que eu encontrei tratam o W como "won't have", como um requisito que tem a menor prioridade possível e a equipe só deve se preocupar com ele no futuro. https://en.wikipedia.org/wiki/MoSCoW_method

Claro que esses métodos não são exatos e tudo depende do conjunto de regras pra análise estar clara. Mas só queria entender se em algumas referencias (e em quais) os autores realmente tratam o W como um requisito desejável.

Abraço! Mayk

1 resposta
solução!

A técnica MoSCoW é geralmente explicada da seguinte forma:

  • Must have (Deve ter): Requisitos ou funcionalidades essenciais e críticos para o sucesso do projeto. Esses itens são imprescindíveis e devem ser entregues.
  • Should have (Deveria ter): Requisitos ou funcionalidades importantes, mas não críticos. Eles são considerados fundamentais para o projeto, mas podem ser flexibilizados ou adiados, se necessário.
  • Could have (Poderia ter): Requisitos ou funcionalidades que seriam bons de ter, mas não são considerados essenciais ou críticos. Eles podem ser incluídos se houver tempo e recursos disponíveis.
  • Won't have (Não terá): Requisitos ou funcionalidades que não serão incluídos no escopo do projeto atual. São considerados fora do âmbito do projeto, podendo ser considerados em futuras iterações ou versões.

Neste artigo link de Miranda Dulin a mesma explica que em algum lugar também se deparou com a descrição "Would Like" mas a mesma afirma que independentemente de como você se refere à última categoria, ela incluirá as coisas que decidimos não construir porque não se encaixam em nossa visão do produto e coisas que ainda gostaríamos de ter, mas somente depois de implementarmos os itens de maior prioridade.