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.