Você está na página 1de 4

Nome: Nathan Silveira Schneider Commented [NS1]: Depois, elaborem em grupo um

resumo, apresentando num texto contínuo seu


entendimento sobre os seguintes aspectos, no mínimo:
- Engenharia de requisitos para métodos ágeis
Requisitos em Metodologias Ágeis - O que são requisitos ágeis?
- Análise de requisitos ágeis
- Gestão de mudanças de requisitos ágeis
O que são Requisitos Ágeis? - Como especificar requisitos em métodos ágeis?
- User Stories
Requisitos Ágeis são uma nomenclatura utilizada para se referir às formas com
as quais os requisitos se manifestam em Metodologias Ágeis, como Scrum ou
Extreme Programming (XP). Abrahamsson cita em seu artigo "Agile software
development methods: Review and analysis" que metodologias tradicionais de
desenvolvimento de sistemas de informação são "tratadas como uma ficção
necessária para apresentar uma imagem de controle ou para prover um estado
simbólico" e que "são ideais inatingíveis e espantalhos que proporcionam um
referencial para situações utópicas de desenvolvimento". Neste contexto, as
Metodologias Ágeis surgem para tentar remediar muitas das desvantagens inerentes
às metodologias tradicionais.
O termo "Ágil" vem do "Agile Manifesto", um manifesto escrito e assinado de
forma simbólica por uma série de profissionais importantes da área de
desenvolvimento de software em 2001. O manifesto diz:

Estamos descobrindo maneiras melhores de desenvolver


software, fazendo-o nós mesmos e ajudando outros a
fazerem o mesmo. Através deste trabalho, passamos a valorizar:

Indivíduos e interações mais que processos e ferramentas


Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano

Ou seja, mesmo havendo valor nos itens à direita,


valorizamos mais os itens à esquerda.

Abrahamsson também cita quatro pilares de características importantes para


o desenvolvimento ágil:
• Incremental
• Cooperativo
• Direto
• Adaptativo

Desenvolvimento Iterativo e Incremental

Apesar do desenvolvimento iterativo e incremental, comumente visto nas


metodologias ágeis, ser visto como algo recente e moderno, existem evidências de
projetos feitos de forma mais "ágil" desde 1960. Um desses exemplos é um projeto
feito pela IBM em 1972 para controle e comando de submarinos norte-americanos. O
projeto teve a duração de dois anos, e foi quebrado em quatro partes, como forma de
mitigar riscos e receber feedback mais cedo.
No artigo de Winston Royce, do qual a metodologia Waterfall foi derivada
erroneamente, são descritos os riscos inerentes à metodologia waterfall "pura",
quando empregada para o desenvolvimento de softwares de grande porte.
Desta forma, o Desenvolvimento Iterativo e Incremental visa constantemente
refinar requisitos através da aprendizagem e da mudança ocorrida ao longo da
duração do projeto, com o desenvolvimento de cada funcionalidade, em oposição a
uma especificação detalhada a priori do início do desenvolvimento do sistema. Desta
forma, o cliente aceita dividir seu sistema em "subsistemas", ou funcionalidades, para
recebê-lo antes e com atualizações mais frequentes, ainda que ele não possua todas
as funcionalidades já visionadas.

Requisitos em Scrum

Requisitos em Scrum existem no chamado "backlog". O backlog pode ser


dividido em várias pilhas. Uma delas é a do produto, onde existem todos os requisitos
já identificados em ordem de prioridade, onde idealmente os requisitos que estão
próximos do topo possuem mais detalhe. Outra é a do Sprint de desenvolvimento,
que é o conjunto de requisitos em que o time de desenvolvimento se compromete a
entregar durante o período definido do Sprint, que pode variar entre uma semana a
um mês. Os requisitos que entram para desenvolvimento são retirados do topo da
pilha do backlog do produto. O time de desenvolvimento pode optar por dividir um
requisito em diversas tarefas, para atribuir cada uma a um membro do time.
Os responsáveis pelo levantamento de requisitos do produto também devem
ter sua pilha em um Sprint. Nesta pilha devem entrar requisitos que não estão
completamente refinados (prontos para serem desenvolvidos de acordo com a
definição de pronto). O fruto dos gerentes de produto devem ser requisitos refinados
e prontos para entrar para o desenvolvimento. Desta forma, a equipe de gerentes de
produto deve estar no mínimo a um Sprint "à frente" da equipe de desenvolvimento.
Vlaanderen, Kevin, et al. descreve em seu artigo "The agile requirements
refinery: Applying SCRUM principles to software product management" diversos
estágios pelos quais um requisito pode transitar, do menos detalhado ao mais
detalhado, respectivamente:
o Visão
o É o primeiro estágio de um novo requisito, podendo surgir de uma ideia
do cliente, da diretoria da empresa, ou algum stakeholder do projeto.
Um exemplo de visão pode ser o desejo de atingir empresas de
pequeno porte através de um ERP versão "light".
o Tema
o O tema é a elaboração formal de uma Visão elaborado por um
responsável pelo levantamento de requisitos. O Tema deve descrever
o problema de negócio e o que seria necessário para solucioná-lo.
Dependendo da complexidade da Visão, ela pode dar origem a múltiplos
Temas.
o Conceito
o Cada tema pode dar origem a múltiplos conceitos. Nesta altura, já se
fala em um software conceitual, descrevendo em alto nível os requisitos
que ele haveria de ter para cubrir as necessidades de pequenas
empresas.
o Definição de requisito
o Os conceitos são traduzidos em uma série de definições de requisitos
de alto nível pela equipe do produto, para serem posteriormente
detalhados pela equipe de desenvolvimento.

Nem todos os requisitos precisam passar por todas as fases, mas apenas os maiores.
Requisitos novos que surgirem podem se encaixar diretamente em alguma subcategoria.

User Stories

Requisitos em metodologias ágeis são comumente escritos como User


Stories. Estes artefatos são escritos da perspectiva do usuário do sistema ou da
pessoa interessada na funcionalidade específica. As user stories possuem diversas
partes, como o título e o critério de aceite. Existe mais de um padrão para a escrita
de títulos, mas uma das formas pode ser a seguinte:

Eu, enquanto <QUEM> quero <O QUÊ> para <POR QUÊ>

Nota-se que é necessário especificar do ponto de vista de qual "job description"


a história está sendo escrita, a funcionalidade desejada em si, e também a justificativa
do porquê esta funcionalidade é necessária.
Complementando o título da história, também é escrito o critério de aceite,
onde deve ser especificado em mais detalhe os critérios pelas quais a história será
avaliada e validada. O critério de aceite é uma parte crucial e importante para a
história, pois será usada como base para o desenvolvimento, provendo para o
desenvolvedor uma visão do que precisa necessariamente existir, e o que está
"aberto para discussão".
Uma história precisa ser refinada pelo time de desenvolvimento e também pelo
time de negócios para ser considerada pronta para ser desenvolvida, de acordo com
a "definition of ready", ou "definição de pronta". As histórias devem ser delimitadas
em um certo nível de escopo e nível de detalhe. O nível não pode ser muito alto, pois
ela deve ser entregável em um Sprint (que dura no máximo um mês), e não pode ser
muito baixo, pois cada história deve entregar valor para o usuário final e para não
gerar um overhead muito grande no rastreamento e na apresentação.
Referências:

Abrahamsson, Pekka, et al. "Agile software development methods: Review and


analysis." arXiv preprint arXiv:1709.08439 (2017).
Larman, Craig, and Victor R. Basili. "Iterative and incremental developments. a brief
history." Computer 36.6 (2003): 47-56.
Royce, Winston W. "Managing the development of large software systems: concepts
and techniques." Proceedings of the 9th international conference on Software
Engineering. IEEE Computer Society Press, 1987.
Schwaber, Ken. "Scrum development process." Business object design and
implementation. Springer London, 1997. 117-134.
Vlaanderen, Kevin, et al. "The agile requirements refinery: Applying SCRUM
principles to software product management." Information and software technology
53.1 (2011): 58-70.