Análise comparativa entre a engenharia de requisitos e o
método de desenvolvimento ágil: Scrum
Patrícia Bastos Girardi, Sulimar Prado, Andreia Sampaio
Resumo
Este trabalho tem como objetivo prover uma visão geral de como técnicas da
Engenharia de Requisitos podem ser aplicadas aos métodos de desenvolvimento
ágeis a fim de garantir a qualidade do produto final, bem como, entender como e
porque a Engenharia de Requisitos ágil difere da Engenharia de Requisitos
tradicional. Analisando as vantagens e desvantagens de cada técnica e método,
dentro da realidade do mercado de desenvolvimento de software, propondo ao final,
a junção das vantagens em uma abordagem mista.
Palavras-chave: Engenharia de Requisitos, Métodos Ágeis, Processos Ágeis.
Abstract
This work aims to provide an overview of how the requirements engineering
techniques can be applied to agile development methods to ensure the quality of the
final product, as well as to understand how and why agile requirements engineering
differs from the Engineering traditional requirements. Analyzing the advantages and
disadvantages of each technique and method, within the reality of software
development market, offering the end, the junction of the advantages of a mixed
technique.
1. INTRODUÇÃO
O artigo visa oferecer uma analise de como a utilização de métodos ágeis na
construção de produtos de software, podem desonerar o processo de levantamento,
analise e construção de um sistema. O objetivo principal dessa pesquisa é expor
quais técnicas e abordagens da Engenharia de Requisitos poderão ser utilizadas
dentro do contexto ágil, bem como, entender como e porque a Engenharia de
Requisitos ágil difere da Engenharia de Requisitos tradicional. Para realização desse
estudo foram utilizadas referências bibliográficas de diversos autores.
Atualmente as empresas de desenvolvimento de software têm sentido a
necessidade, baseado em experiências insatisfatórias, de dar maior atenção aos
requisitos, identificando-os de forma mais consistente e eficiente. Os requisitos
tendem a evoluir rapidamente e se tornarem obsoletos mesmo antes dos projetos
serem finalizados. Isso se deve a mudanças cada vez mais rápidas no ambiente de
negócio, no qual a maioria das organizações operam, dessa forma o mercado de
desenvolvimento de software vem sendo desafiado em seus métodos, conceitos e
ferramentas de Engenharia de Requisitos tradicional.
Diante dessa realidade, surge a utilização dos Métodos Ágeis (MAs), que
procura atacar os desafios emergentes destes contextos dinâmicos, têm ganho
bastante interesse de pesquisadores e engenheiros de softwares. Esses métodos,
constituem uma família de processos de desenvolvimento de software que se tornou
popular durante os últimos anos. O objetivo principal desta abordagem é garantir a
entrega de produtos em um menor prazo, com maior qualidade e satisfazendo às
necessidades dos clientes. Dentre as ferramentas disponíveis no mercado a mais
utilizada, e a que será alvo dessa pesquisa, é o framework Scrum que consiste em
um conjunto formado por Times Scrum e seus papéis associados, Eventos com
Duração Fixa (Time-Boxes), Artefatos e Regras. Os Times Scrum são projetados
para otimizar flexibilidade e produtividade. Para esse fim, eles são auto organizáveis,
interdisciplinares e trabalham em iterações com o propósito de produzir um software
dividido em vários pedaços, que são planejados para serem entregues ao final de
cada Sprint. Priorizando o compromisso de prazo firmado como o cliente, em
detrimento, muitas vezes, da qualidade do produto.
Por outro lado a Engenharia de Requisitos é um processo tradicional da
engenharia de software, que requer um tempo maior para identificar, analisar,
documentar e validar requisitos para o sistema que será desenvolvido. Seus
métodos e conceitos não acompanham a velocidade que o mercado impõe, e por
esse fator são na prática pouco utilizados, pois exigem muito tempo na confecção
dos seus artefatos fazendo com que as empresas não consigam seguir sua
metodologia plenamente, pois oneram o tempo de todos envolvidos e o custo de
produção do projeto. Dessa forma, a utilização parcial ou não aplicação da
Engenharia de Requisitos compromete a qualidade e a confiabilidade do produto
final, gerando um retrabalho para implementação de melhorias e ajustes não
planejados no processo inicial de elaboração do projeto.
2. Desenvolvimento do estudo
a. Engenharia de requisitos
A engenharia de requisitos é um processo que envolve todas as atividades exigidas
para criar e manter o documento de requisitos de sistema. Existem quatro atividades
genéricas de processo de engenharia de software que são de alto nível, ou seja, o
estudo da viabilidade do sistema, a obtenção e a análise de requisitos, a especificação
de requisitos e sua documentação e, finalmente, a validação desses requisitos.
(SOMMERVILLE, 2005, p.103).
A engenharia de requisitos, tem por objetivo sistematizar o processo do
desenvolvimento de software através da utilização de técnicas e ferramentas que
são utilizados desde a fase de elicitação, levantamento e analise dos requisitos
funcionais e não funcionais de um sistema de software.
As atividades do processo são:
Compreensão do processo – Os analistas devem desenvolver sua compreensão
do processo de negocio que se deseja automatizar.
Coleta de requisitos – Processo de interagir com os stakeholders do sistema para
descobrir suas necessidades. Esse processo é chamado de Elicitação de requisitos
ou Levantamento de requisitos.
Classificação – Essa atividade considera o conjunto não estruturado dos requisitos
e os organiza em grupos coerentes. Nessa etapa do processo as necessidades
levantadas na fase de elicitação são classificadas e podem dar origem aos requisitos
funcionais e não funcionais do sistema.
Resolução de conflitos – Quando múltiplos stakeholders estão envolvidos, os
requisitos apresentação conflitos. Essa atividade se ocupa em encontrar e
solucionar esses conflitos.
Definição das prioridades – Em qualquer conjunto de requisitos, alguns serão mais
importantes do que outros. Esse estágio envolve a interação com os stakeholders,
para descobrir os requisitos mais importantes e classifica-los como maior e menor
prioridade. Após essa atividade, o analista irá iniciar a especificação da
documentação priorizando os requisitos mais importantes no processo de
desenvolvimento do sistema.
Verificação de requisitos – Os requisitos são verificados e validados, a fim de se
descobrir se eles são completos e consistentes e se estão em concordância com o
que os stakeholders realmente desejam do sistema.
b. Métodos Ágeis - Scrum
O Scrum vem sendo utilizado para o desenvolvimento de produtos complexos
desde o início dos anos 90. O Scrum não é um processo ou uma técnica para o
desenvolvimento de produtos, trata-se de um framework dentro do qual se emprega
diversos processos e técnicas.
O papel do Scrum é fazer transparecer a eficácia relativa as práticas de
desenvolvimento, para que se possa continuamente melhorá-las, enquanto se provê
um framework dentro do qual produtos complexos podem ser desenvolvidos.
Scrum é fundamentado na teoria de controle de processos empíricos que
emprega uma abordagem iterativa e incremental para otimizar a previsibilidade e
controlar riscos.
Três pilares o sustentam:
Transparência que garante os aspectos do processo que afetam o resultado, deve
ser visível para aqueles que gerenciam os resultados;
Inspeção que define que os diversos aspectos do processo devem ser
inspecionados com uma frequência suficiente para que variações inaceitáveis no
processo possam ser detectadas;
Adaptação se o inspetor determinar, a partir da inspeção, que um ou mais aspectos
do processo estão fora dos limites aceitáveis e que o produto resultante será
inaceitável, ele deverá ajustar o processo ou o material sendo processado.
Existem três pontos para inspeção e adaptação em Scrum.
A Reunião Diária é utilizada para inspecionar o progresso em direção à Meta da
Sprint e para realizar adaptações que otimizem o valor do próximo dia de trabalho.
As Reuniões de Revisão da Sprint e de Planejamento da Sprint são utilizadas para
inspecionar o progresso em direção à Meta da Release e para fazer as adaptações
que otimizem o valor da próxima Sprint.
A Retrospectiva da Sprint é utilizada para revisar a Sprint passada e definir que
adaptações tornarão a próxima Sprint mais produtiva, recompensadora e
gratificante.
O coração do Scrum é a Sprint, que é uma iteração de um mês ou menos, de
duração consistente com o esforço de desenvolvimento. Todas as Sprints utilizam o
mesmo modelo de Scrum e todas as Sprints têm como resultado um incremento do
produto final que é potencialmente entregável. Cada Sprint começa imediatamente
após a anterior.
i. Como funciona
No Scrum o projeto será dividido em ciclos periódicos chamados Sprints.
Cada Sprint, geralmente variando entre uma semana e um mês, representa um
volume de esforço pré-definido dentro do qual um grupo de atividades deverá ser
executado e seu produto final será um software funcional. O processo é iterativo e
incremental.
As funcionalidades que o Cliente deseja implementar em um software são
registradas em um Product Backlog, definido antes do início do projeto através de
técnicas especiais de levantamento e registro de requisitos. Cada funcionalidade é
estimada (esforço e prazo) e, em função da quantidade de profissionais envolvidos
no projeto, este é dividido em Sprints.
No começo de cada Sprint é realizado um Sprint Planning Meeting, uma
reunião de planejamento no qual o Product Owner define prioridades dentro do
Product Backlog e a equipe seleciona as atividades que ela será capaz de
implementar durante o Sprint sendo iniciado. As tarefas definidas para cada Sprint
são realocadas do Product Backlog para um Sprint Backlog.
Diariamente é realizada pela equipe uma breve reunião (Daily Scrum),
geralmente pela manhã, cujo objetivo é disseminar conhecimento sobre as
atividades realizadas no dia anterior, identificar riscos e problemas, e priorizar as
tarefas no dia corrente.
A cada término de
Sprint a equipe apresenta as funcionalidades
implementadas na Sprint Review Meeting, quando é realizada uma Sprint
Retrospective e os membros do time planejam o próximo Sprint, reiniciando o ciclo.
ii. Como documentar
Scrum utiliza quatro artefatos principais:
O Backlog do Produto é uma lista priorizada de tudo que pode ser necessário no
produto.
O Backlog da Sprint é uma lista de tarefas para transformar o Backlog do Produto,
por uma Sprint, em um incremento do produto potencialmente entregável.
Um Burndown de Release mede o Backlog do Produto restante ao longo do tempo
de um plano de release.
Um Burndown de Sprint mede os itens do Backlog da Sprint restantes ao longo do
tempo de uma Sprint. As Regras fazem o elo entre os eventos com duração fixa
(timeboxes), os papéis e os artefatos do Scrum.
O Backlog do Produto representa tudo que é necessário para desenvolver e
lançar um produto de sucesso. É uma lista de todas as características, funções,
tecnologias, melhorias e correções de defeitos que constituem as mudanças que
serão efetuadas no produto para releases futuras. Os itens do Backlog do Produto
possuem os atributos de descrição, prioridade e estimativa. A prioridade é
determinada por risco, valor e necessidade. Há diversas técnicas para dar valor a
esses atributos. O Backlog do Produto é ordenado por prioridade. O Backlog do
Produto de mais alta prioridade leva a atividades de desenvolvimento imediatas.
Quanto mais alta sua prioridade, mais urgente ele é, mais se pensou sobre ele e há
mais consenso no que diz respeito ao seu valor. O Backlog de mais alta prioridade é
mais claro e possui mais informações detalhadas do que o Backlog de prioridade
mais baixa. Fazem-se melhores estimativas quando baseadas em uma maior
clareza e em mais detalhes. Quanto mais baixa a prioridade, menor é o nível de
detalhe, até que mal se consiga entender o item. À medida que um produto é
utilizado, que seu valor aumenta e que o cliente fornece feedback, o Backlog do
Produto torna-se uma lista maior e mais aprofundada. Os requisitos nunca param de
mudar. O Backlog do Produto é um documento vivo. Mudanças nos requisitos de
negócios, condições do mercado, tecnologia e equipe causam mudanças no Backlog
do Produto. Para minimizar o retrabalho, apenas os itens de maior prioridade
precisam ser mais detalhados.
Frequentemente, múltiplas equipes de Scrum trabalham juntos no mesmo
produto. Um único Backlog do Produto é usado para descrever o trabalho a ser
realizado no produto. Então, um atributo que agrupe os itens é aplicado no Backlog
do Produto. O agrupamento pode ocorrer por conjuntos de características, por
tecnologia ou por arquitetura, e ele é frequentemente utilizado como uma forma de
se organizar o trabalho por equipe de Scrum.
Uma das regras do Scrum está ligada ao objetivo de cada Sprint, que é ter
como resultado incrementos de funcionalidade potencialmente entregáveis que
estejam de acordo com uma definição de “pronto” operacional. Scrum exige que as
equipes desenvolvam um incremento de funcionalidade do produto a cada Sprint.
Esse incremento deve ser potencialmente entregável, pois o Product Owner pode
optar por implantar a funcionalidade imediatamente. Para isso ser possível, o
incremento deve ser um pedaço completo do produto. Ele deve estar “pronto”. Cada
incremento deve ser adicionado a todos os incrementos anteriores e exaustivamente
testado, garantindo que todos os incrementos funcionem juntos.
No desenvolvimento de produtos, afirmar que a funcionalidade está pronta
pode se levar a presumir que ela está pelo menos bem codificada, que tenha
passado por testes unitários, que tenha sido feito o build e que tenha passado por
testes de aceitação. Outros podem presumir que apenas o código tenha sido
desenvolvido. A definição de pronto deve estar bem clara para toda a equipe para
que os outros dois pilares do controle de processos empíricos possam funcionar.
Quando se descreve algo como “pronto”, todos os envolvidos devem entender o que
“pronto” significa. Um incremento completamente “pronto” inclui toda a análise,
projeto, programação, documentação e testes para o incremento e todos os itens do
Backlog do Produto no incremento.
Os testes incluem testes de unidade, de sistema, de usuário e de regressão,
bem como testes não-funcionais como de performance, de estabilidade, de
segurança e de integração. “Pronto” inclui também qualquer internacionalização
necessária. Algumas equipes ainda não são capazes de incluir em sua definição de
“pronto” tudo o que é necessário para a implantação. Isto deve estar claro para o
Product Owner. Esse trabalho restante deverá ser feito antes que o produto possa
ser implantado e utilizado. Algumas organizações são incapazes de desenvolver um
incremento completo dentro de uma Sprint. Elas podem ainda não ter infraestrutura
automatizada de testes para completar todos os testes. Nesse caso, duas categorias
são criadas para cada incremento: o trabalho “pronto” e o trabalho “não pronto”. O
trabalho “não pronto” é a porção de cada incremento que terá que ser completada
mais tarde. O Product Owner sabe exatamente o que ele está inspecionando ao final
da Sprint, porque o incremento atende à definição de “pronto” e o Product Owner
entende essa definição. O trabalho “não pronto” é adicionado a um item do Backlog
do Produto chamado “trabalho não pronto”, de forma que ele se acumula. Essa
técnica cria transparência no progresso em direção à entrega. A inspeção e a
adaptação na Revisão da Sprint serão tão precisas quanto essa transparência for. O
trabalho “não pronto” de cada incremento vai se acumulando e deve ser tratado
antes da entrega do produto. Esse trabalho é acumulado linearmente, embora haja
algum tipo de acúmulo exponencial que é dependente das características de cada
organização. Sprints de Release são adicionados ao final de cada release para
completar o trabalho “não pronto”. O número de Sprints é imprevisível, visto que o
acúmulo de trabalho “não pronto” não é linear.
c. Processos da engenharia de requisitos e o seu Impacto
em Métodos Ágeis
A importância de se definir padrões reside no fato de se ter um conjunto de
diretrizes previamente definidas por onde toda a equipe de desenvolvimento será
guiada.
Métodos ágeis não se baseiam nestes padrões para elicitação e
gerenciamento de requisitos, porém, eles têm adaptado muitas das ideias básicas
da engenharia de requisitos ao seu ambiente. Por exemplo, em métodos ágeis toda
a equipe de desenvolvimento está envolvida na atividade de elicitação e
gerenciamento de requisitos enquanto em que abordagens tradicionais somente um
subconjunto da equipe de desenvolvimento será envolvida.
Métodos ágeis entendem que variabilidade de requisitos é um problema
constante em praticamente todos os projetos de software, portanto, o suporte a
essas mudanças está incluso em seu processo como um ponto forte. Além do mais,
métodos ágeis não tentam prever mudanças ou necessidades futuras, eles só focam
nas “entregas” pela quais o cliente está pagando. Esta abordagem evita o
desenvolvimento de uma arquitetura que requer esforço extra. O entendimento de
variabilidade de requisitos tem um forte impacto na habilidade de métodos ágeis
serem “enxutos”. Em geral, uma arquitetura genérica e mais abrangente é esperada
para suportar a variabilidade nos requisitos que podem ser previstas com
antecedência. Contudo, uma arquitetura mais complexa custa mais, não só para a
equipe de desenvolvimento, mas também para a equipe de manutenção e correção
de erros.
3. Conclusão
Após análise das duas realidades, a escassez de tempo e a qualidade na entrega do
produto, conclui-se que para desenvolver um software em pouco tempo e de forma
confiável e eficiente, é necessário que a utilização da Engenharia de Requisitos
Tradicional não seja banida ou substituída, e sim, que seja adaptada e customizada
para que todo documento que não comprove significância seja retirado do projeto e
os demais sejam adequadas no sentido de corrigir o exagero na produção de
documentos que não serão lidos e dessa forma reduzir o alto custo que produzi-los
requer, devido o grande investimento de tempo. Utilizando as vantagens da
metodologia ágil, fazendo com que toda a equipe de desenvolvedores participe do
levantamento de requisitos, participando da fase inicial do projeto para aumentar a
visão dos desenvolvedores sobre projeto como um todo. E tendo a compreensão
bem clara do que seja realmente um produto no estado pronto para ser entregue,
dando mais atenção a testes automatizados na fase final do software, evitando os
riscos de que o produto acabe sendo testado pelo cliente. A utilização de métodos
ágeis como o Scrum, juntamente com as práticas de engenharia de requisitos
tradicional, pode reduzir o custo do processo e o tempo de desenvolvimento, sem
reduzir a qualidade do produto final.
Referências
FUSCO, Camila. Scrum, A Nova Gestão de Projetos, mar,2008. Disponível em:
http://governanca.wordpress.com/Scrum-a-nova-gestao-deprojetos. Acesso em 21/06/2012.
GOMES,
Handerson.
Porque
usar
Scrum,
Nov,
2008.
Disponível
em:
http://webinsider.uol.com.br/index.php/porque-usar-Scrum/. Acesso em 21/06/2012.
SOMMERVILLE, Ian. Engenharia de Software, São Paulo: Ed. Pearson, 2007.
TELES, Vinícius Manhães. Extreme Programming: Aprenda como encantar seus usuários
desenvolvendo software com agilidade e alta qualidade. São Paulo: Novatec, 2008.