T.I.S. So Carlos, v. 3, n. 2, p. 122-130, mai-ago 2014
Tecnologias, Infraestrutura e Software
Aplicando a Metodologia gil Scrum para apoio ao
Gerenciamento de Requisitos Felipe Luiz Carnevali, Daniel Lucrdio Resumo: Este trabalho apresenta um estudo de caso que aplica a metodologia gil Scrum para o gerenciamento de requisitos. So levantados os dados das quais a empresa estudada usa para realizar o seu prprio gerenciamento de requisitos. Baseando nas prticas e regras do Scrum foi proposta uma implementao que se adeque realidade da empresa, alterando a sua forma estrutural nas responsabilidades dos profissionais e tambm modificando o ambiente de trabalho aplicando as tcnicas citadas neste estudo de caso, focando na qualidade, prazos, custo, agilidade e satisfao do cliente.
Applying Scrum agile methodoly to support the requirements Management
Abstract: This paper presents a case study that applies Scrum agile methodology for requirements management. Data used by the studied company to carry out its own management requirements is raised. Based on Scrum practices and rules, an implementation that fits the reality ofthe company was proposed, changing its structural form in the responsibilities ofprofessionals and also changing the working environment by applying the techniques mentioned in this case study, focusing on quality, deadlines, cost, agility and customer satisfaction.
Keywords: Scrum, Agile methodoly, requirements.
I. INTRODUO Porm esse processo costuma ser muito rigoroso e demorado.
Diversos estudos (LEFFINGWELL et al., 2003); H algumas dcadas criaram-se algumas metodologias que (SOMMERVILLE; SAWYER, 1997) levantaram e propem melhorar o andamento dos projetos, as quais so comprovaram que uma grande quantidade de projetos de chamadas de metodologias geis. Entre elas existem vrias software so cancelados ou simplesmente fracassam por no metodologias tais como Extreme Programming (XP), Feature atenderem totalmente s necessidades dos clientes ou Driven Development (FDD), Adaptive Software excederem prazos e oramentos propostos no contrato. Esses Development (ASD), Dynamic Systems Development problemas geralmente acontecem devido constante Method (DSDM), Scrum, Crystal Methods (CM) entre outras. mudana do mercado, o que faz com que os requisitos Abrahamsson et al. (2002) confirma que quanto mais de uma mudem frequentemente. Apesar das mudanas, h grande metodologia gil utilizada ao mesmo tempo, melhora-se o deficincia no levantamento dos requisitos, um dos principais processo de agilidade. Entretanto, de acordo com AGILE contratempos no fracasso dos projetos de software. SURVEY (2012), duas das mais populares metodologias que Com essas anlises alguns estudiosos passaram a so utilizadas no contexto de metodologias geis so Extreme considerar a engenharia de requisitos incluindo todo o Programming (XP) e o Scrum. Por esse motivo, decidiu-se processo de elicitao (coleta de requisitos), especificao, focar o estudo de caso em uma dessas, que a metodologia viabilidade e validao como um fator muito importante gil Scrum. dentro da rea de engenharia de software. Todavia a O Scrum foi criado por Shwaber em 1995, com foco no engenharia de software j vem sendo estudada no mundo processo de gesto de projetos de software complexos. acadmico h mais de 40 anos (ESPINDOLA et al., 2004), e Conforme (SCHWABER; BEEDLE, 2002), sua teoria muitos destes sistemas vem sendo utilizados at hoje. atender as necessidades do negcio baseando-se em sistemas A engenharia de requisitos uma forte candidata para adaptativos. Schwaber e Beedle (2002) afirmam ainda que a ocupar-se de responsabilidades com relao garantia, principal caracterstica do Scrum a comunicao entre as necessidades, qualidade, prazos e oramentos que so equipes que participam direta ou indiretamente e no h estimados aos clientes, bem como lidar com as dificuldades especificaes referentes a prticas de construo, pois o que surgem no dia dia do desenvolvimento de sistemas. mtodo enfatiza que as equipes sejam auto-organizadas e os
Departamento de Computao - Universidade Federal de So Carlos (UFSCar)
Caixa Postal 676 13.565-905 So Carlos SP Brasil Autor para correspondncia: felipe.carnevali@hotmail.com, daniel@dc.ufscar.br Felipe Luiz Carnevali, Daniel Lucrdio processos so orientados a objetivos e resultados. para o preenchimento de certo objetivo. Leite (1994). Este trabalho apresenta uma anlise de como funciona a A engenharia de requisitos foca no processo e se torna engenharia de requisitos, considerando seu processo bsico, e responsvel pelas evidncias que mais podem causar as prticas e regras da metodologia gil Scrum. O objetivo problemas srios, podendo ser destacadas as mudana de desse estudo propor uma melhoria no processo de requisitos e especificaes, requisitos e especificaes engenharia de requisitos no contexto de uma empresa de incompletos e falta de engajamento do usurio software localizada na cidade de Ribeiro Preto (SP), que (LEFFINGWELL et al., 2000). possui um sistema j consolidado no mercado h mais de 20 Os usurios esperam um sistema que atenda as suas anos com uma cartela de clientes em todo o pas. Seus necessidades, tarefas e facilite o seu trabalho dirio. Os processos de organizao de levantamento de requisitos financiadores aguardam um sistema que obtenha um retorno foram estudados e foi proposta uma melhoria com base nas adequado ao investimento fornecido. A equipe de tcnicas, prticas e regras acadmicas citadas neste trabalho. desenvolvimento cria expectativas em desenvolver um A seo II apresenta a composio da engenharia de sistema com qualidade, prazo e custo estipulado atendendo requisitos e na seo III a metodologia gil Scrum. A seo todas as reais necessidades dos usurios (LEFFINGWELL et IV apresenta o estudo de caso utilizado neste trabalho, al., 2000), porm a realidade quase sempre no atende a esses detalhando o contexto da empresa estudada, e a proposta quesitos, devido grande abrangncia em que os softwares realizada para a melhoria de desempenho, utilizando-se dos vm fazendo na sociedade. papis e prticas do Scrum com os resultados preliminares e A engenharia de requisitos uma atividade responsvel por discusses de maior importncia para o resultado esperado. A criar e manter documentos de especificaes de requisitos de seo V apresenta os trabalhos relacionados e as concluses e sistemas chamados DERS segundo (KOTONYA; trabalhos futuros so descritos na seo VI. SOMMERVILLE, 1998). Este processo como um todo composto por quatro grandes processos: o estudo de II. ENGENHARIA DE REQUISITOS viabilidade, em qual aspecto o sistema ser vivel ao negcio Com a grande demanda e crescente complexidade de a ser utilizado, a elicitao de requisitos, com a descoberta e software requerida, ausncia de qualidade comea a ser levantamento dos requisitos, a especificao, onde a percebida, pois os produtos no conseguem prover a organizao dos requisitos apresentada em um padro e a capacidade necessria. Atualmente utilizada a engenharia validao, com a descoberta e validao dos requisitos que de requisitos para sistematizar o processo de definio de foram registrados e definem a necessidade que o usurio software. Essa sistematizao necessria, pois ajuda os deseja para o sistema. engenheiros de requisitos a entenderem melhor o problema. Na figura 1 possvel visualizar o modelo de como Uma boa definio de requisitos dada por como sendo a funciona o processo da engenharia de requisitos: "condio necessria para a obteno de certo objetivo, ou
Figura 1 O processo de Engenharia de Requisitos segundo (KOTONYA; SOMMERVILLE, 1998)
Segundo (KOTONYA; SOMMERVILLE, 1998), este que j foram realizadas como em um espiral. Aps o estudo processo bem flexvel, pois pode voltar s fases anteriores de viabilidade, temos as fases de elicitao, especificao e
T.I.S. 2014; 3 (2): 122-130 123
Aplicando a Metodologia gil Scrum para apoio ao Gerenciamento de Requisitos validao, que podem ser divididas em subfases. competitivo ao cliente. A elicitao a fase que coleta os requisitos, dividida em Entrega de software com maior frequncia, de duas subfases chamadas Elicitao dos Requisitos do preferncia a cada semana ou ms, sempre visando o menor Sistema,que foca no levantamento das funes e restries do tempo possvel. sistema de uma forma mais detalhada, e Elicitao dos Os stakeholders, analista de requisitos e os Requisitos do Usurio, onde realizado o levantamento, em desenvolvedores trabalham juntos diariamente no projeto. linguagem natural ou por diagramas, de quais funes que o Manter uma equipe focada e motivada, aderindo sistema deve fornecer e quais restries se devem operar. confiana e ambiente necessrio para o trabalho. A especificao composta de trs subfases: Especificao A principal comunicao da equipe que participa do dos Requisitos de Sistema e Modelagem, que descreve as projeto baseada em uma conversa face-a-face. caractersticas de um sistema ou produto, Especificao dos A simplicidade essncia do negcio. Requisitos de Usurio, que consiste em descrever as Software funcionando a medida principal do atividades efetuadas pelos usurios na organizao que ir progresso. utilizar o sistema, e Especificao dos Requisitos de A ateno contnua a excelncia tcnica e um bom Negcio, que descreve em termos de negcio o que deve ser foco no projeto mantm a agilidade. entregue ou conseguido para fornecer valor ao sistema. As melhores arquiteturas, requisitos, e projetos A validao dividida em trs subfases: Estudo de emergem de equipes auto-organizadas. Viabilidade, onde se avalia do ponto de vista organizacional e A equipe em intervalos regulares reflete sobre como tecnolgico se o projeto vivel, Prototipao, que uma se tornar mais efetivo, por isso a mesma se ajusta e aperfeioa apresentao visual final do produto que est sendo o seu comportamento de acordo com a necessidade. desenvolvido, e Revises, onde analisam sistematicamente as Promover a evoluo do desenvolvimento especificaes produzidas para garantir que o projeto sustentvel. Todos stakeholders devem ser capazes de manter corresponde ao que foi pretendido. um ritmo constante visando sempre melhoria. Baseando-se nestes princpios do manifesto gil, notrio III. METODOLOGIAS GEIS que alguns valores existentes nos mtodos atuais so e Segundo (ZANATTA, 2004), em 2001, vrios continuam sendo muito importantes, como por exemplo, a pesquisadores denominados de "Aliana gil" (Agile modelagem de dados e a documentao que so discutidas por Alliance), dentre eles vrios conhecidos internacionalmente Fowler (2013). Porm a preocupao o excesso de papis no contexto da engenharia de software tais como Martin que so gerados com documentos que muitas vezes os Fowler, Alistair Cockuburn, Jim Highsmith, Kent Beck, Mike mesmos nunca sero lidos. Outro fator o planejamento, que Beedle entre outros, com grande experincia no mundo do extremamente importante que seja utilizado, mas existe a desenvolvimento de software, foram motivados a iniciar uma consequncia de limitaes em termos de organizaes, discusso de como ter uma forma eficaz e rpida para se obter cultura do ambiente, comunicaes entre pessoas, entre produtos de software com qualidade e que atendesse as outras. necessidades dos clientes de forma simples. Nesta ideia possvel considerar os mtodos geis uma forma eficaz nasceu o chamado Manifesto gil que abrange essas para realizar o gerenciamento de requisitos, na qual caractersticas, com os dizeres (AGILE MANIFESTO, 2013): subdivido em dois aspectos bsicos (ZANATTA, 2004): ser adaptativo ao invs de preditivo e ser orientado a pessoas ao Gostaramos de descobrir como invs dos processos. desenvolver software e ajudar a outros a fazer Existem algumas formas que se destacam nos mtodos software da melhor maneira possvel geis quando se fala em desenvolver um software, conforme seguindo os melhores caminhos; Queremos (BECK et al., 2000): deve ser priorizado a satisfao do valorizar os seres humanos que participam cliente, atravs da entrega rpida e contnua de software com desse processo com ferramentas eficazes; O qualidade, deve-se alterar os requisitos de forma rpida e software deve possuir uma documentao eficaz, deve-se buscar um desenvolvimento sustentvel e clara, compreensiva e simples; Queremos orientar todos que participam do projeto a praticar estar aptos s mudanas contando com a simplicidade. colaborao do cliente e obtendo um feedback atravs de uma ideia especfica. A) Scrum Como qualquer processo, mtodos e prticas no Scrum (SCWABER; BEEDLE, 2002) um processo para desenvolvimento de software, foram criados alguns princpios projetos que realizam desenvolvimento de software que seja para os mtodos geis: focado nas pessoas no qual o ambiente tenha uma mudana A nossa maior prioridade satisfazer o cliente constante nos requisitos. O Scrum pode ser tambm atravs da entrega rpida e contnua de uma verso do considerado uma tcnica utilizada para realizar o software sempre atualizada. gerenciamento de processo para o desenvolvimento de Alteraes sobre os requisitos mesmo sendo tardia, software. sempre sero bem vindas, pois isto pode ser um diferencial Abrahamsson et al. (2002) relatam que a etapa de
124 TI.S. 2014; 3 (2): 122-130
Felipe Luiz Carnevali, Daniel Lucrdio desenvolvimento do Scrum inclui as fases tradicionais que funcionrios administrativos, um gerente e dois diretores. existe no desenvolvimento de software como requisitos de O sistema comercializado pela empresa nico, que usurio e requisitos de sistema; a anlise; projeto e a entrega alugado a clientes e cobrado por manutenes e customizao final do produto, ressaltando que todas essas questes especficas dos clientes, de acordo com as suas necessidades. precisam ser adaptveis durante o seu processo. As solicitaes so implementadas e todos os clientes tm O Scrum foi inicialmente desenvolvido pelas organizaes direito do uso das funcionalidades disponveis independente de software Advanced Development Methods e VMARK se os mesmo foram solicitados por eles. Software,em meados dos anos 90, e os seus criadores foram Nessa estrutura, o processo de gerenciamento de requisitos Ken Schawber e Jeff Sutherland com o intuito de gerenciar realizado conforme descrio a seguir: projetos de software (HIGHSMITH et al., 2002). A empresa possui um sistema pronto que O nome Scrum nasceu por meio de uma jogada de rugby, comercializado. O processo comea com a implantao desse que este nome dado pela disputa da bola, onde todo o time sistema, com as pessoas responsveis por realizar toda a avana, trabalhando em equipe com os seus jogadores como instalao e treinamento do sistema para os novos clientes que se fosse um s, passando sempre a bola pra um e para outro, iro utiliz-lo. Na maioria das vezes so necessrias vrias para que marquem o mximo de pontos possveis. Essa a adaptaes decorrentes da implantao. Essas adaptaes ideia no desenvolvimento de software, justamente definir consistem nos primeiros requisitos a serem levantados. A papis bem especficos para todas as pessoas que esto equipe de implantao tambm responsvel por realizar envolvidas no projeto, com o intuito que a equipe realize o visitas de ps-implantao e peridicas para saber como est mximo de tarefas possveis para ter uma nova interao satisfao do cliente com o software utilizado. Nessas visitas (release) do produto final. tambm ocorrem solicitaes de novos requisitos. Sua caracterstica bsica so equipes pequenas entre 8 a 10 A equipe de atendimento (help desk) realiza o pessoas; os requisitos so desconhecidos ou mesmo instveis suporte, sanando dvidas e realizando configuraes que s e as interaes so em um prazo curto de tempo. O vezes so necessrias para o cliente utilizar o software. Essas desenvolvimento realizado em intervalos de no mximo 30 solicitaes podem tambm incluir novos requisitos, que dias, denominados de Sprints. Os requisitos levantados no precisam ser tratados. Na maioria das vezes em que um novo Product Backlog so selecionados para serem feitos e requisito entra por esta equipe trata-se de correes de quebradas em tarefas para ser realizadas no Sprint, porm problemas ou erros inesperados no sistema. essas tarefas no podem exceder o tempo de execuo de uma A equipe de qualidade tambm responsvel pelo semana. Caso isso ocorra necessrio que haja um novo levantamento de requisitos. Na realizao dos testes de desmembramento naquele item. de extrema importncia validao para a liberao de uma nova verso, muitas vezes ressaltar que durante o Sprint, no h nenhuma mudana nas so encontrados erros pr-existentes ou falhas no processo tarefas que estejam em desenvolvimento. que podem ser relacionados com requisitos para melhoria no Outra caracterstica importante o encontro dirio (Daily sistema. Meeting) que so reunies curtas de quinze minutos Os tipos de requisitos so avaliados de trs maneiras: realizadas diariamente para que a equipe do projeto se Erro: quando o sistema no funciona como esperado, atualize de como est o andamento e que possa expor as potencialmente causando problemas. dvidas encontradas durante a realizaes das tarefas no Customizao: novos requisitos que so solicitados a Sprint. pedido do cliente, geralmente para adaptao. Este mtodo no possui ou impe nenhuma tcnica Melhoria: so novas funcionalidades que agregam especfica para que se realize o desenvolvimento do software, valor ao sistema sem gerar nenhum custo a quem realizou a porm so estabelecidos conjuntos de prticas e regras para solicitao. gerenciar e devem ser adotadas para que obtenha sucesso no Esses requisitos so registrados em uma ferramenta prpria projeto. chamada Dirio. Essa ferramenta permite que as diferentes pessoas envolvidas no processo, tais como atendentes de help IV. APLICAO DA METODOLOGIA GIL S CRUM NA desk, implantadores, programadores, testadores, analista de ENGENHARIA DE REQUISITOS negcios e a gerncia, que participam desde a entrada, O estudo de caso foi realizado em uma empresa situada em manuteno e sada desse requisito, consigam acompanhar Ribeiro Preto (SP) que atua no mercado de desenvolvimento como est o andamento do mesmo. Dessa forma, todos podem de software h mais de 20 anos na qual o seu produto atende ficar cientes de quando sair uma prxima verso para clientes em todo o pas e possui um processo de satisfazer as pendncias que so aguardadas pelos clientes. gerenciamento de requisitos que parte desde a sua entrada, So definidos trs tipo de requisitos, porm os requisitos de manuteno e a sada que o software pronto para o uso erros no precisam passar pelo processo de engenharia de final. Conforme o levantamento, no existe nenhuma requisitos. Esses trs itens so tratados de forma conjunta, metodologia aplicada junto ao processo de gerenciamento de pois os problemas so comuns a todos. Os erros so requisitos, e a empresa criou o seu prprio gerenciamento classificados nesse contexto para chegarem at descrito mais adiante. desenvolvimento, teste e liberao da correo do software. A empresa possui oitenta funcionrios tcnicos, seis Quando um novo requisito solicitado, existem duas
T.I.S. 2014; 3 (2): 122-130 125
Aplicando a Metodologia gil Scrum para apoio ao Gerenciamento de Requisitos pessoas responsveis por avali-lo. Essas pessoas, que so A) Proposta de melhoria utilizando o Scrum analistas de negcio, verificam, por exemplo, se os erros Seguindo as regras e prticas do Scrum, a principal realmente so erros ou se so apenas uma falta de caracterstica a comunicao da equipe. Esta prtica se for entendimento do sistema. Tambm verificam se necessrio aplicada no caso estudado, reduziria drasticamente esta falha. realizar uma customizao solicitada ou se existe outra opo Mas tambm notria a falta de papis dentro da empresa. j disponvel no sistema. E decidem se melhorias solicitadas Tanto a equipe de atendimento como implantadores fazem um realmente iro agregar valor para o sistema. Porm, quando mesmo trabalho de levantamento de requisitos, o que pode os analistas de negcios realizam esse processo so ocasionar problemas de responsabilidade e hierarquia. Assim encontradas algumas falhas. sendo, se forem atribudos os papis descritos no Scrum h Uma das principais falhas a falta de comunicao, que maiores chances de respeito hierarquia e senso de observada atualmente na empresa. A falta de comunicao responsabilidade. Isso pode tambm tornar a comunicao com os clientes um dos principais problemas, podendo mais eficaz. Muitas vezes a prpria gerncia e diretoria tm resultar no levantamento de requisitos desnecessrios, e influncia nesse tipo de problema, querendo passar requisitos muitas vezes causando desconforto no momento da que no foram analisados como prioritrios para adquirir implementao do software. A comunicao interna tambm novos clientes. escassa, pois a equipe de atendimento e implantadores, que so os que tm maior interao com os clientes, no tm a A. 1) Uso de papis Scrum prtica e regra de conversarem com os analistas de negcios ou mesmo programadores. Na metodologia gil Scrum existem papis e Os analistas de negcios conversam entre si, porm nem responsabilidades diferentes na qual o objetivo executar os sempre ambos tm o conhecimento de toda a ferramenta trabalhos durante a utilizao das prticas. Abaixo sero completa devido falta de documentao, que outro descritos esses papis (SCHWABER; BEEDLE, 2002): problema observado. Assim, quando os requisitos so Product Owner - o dono do produto, geralmente um validados por eles, comum serem registrados requisitos de cliente ou especialista do negcio o qual est sendo melhorias, customizaes e, principalmente, correes de desenvolvido. Ele defende os interesses do negcio e tem erros, que no so realmente necessrios para o sistema. Se como objetivo e responsabilidade de priorizar e manter os houver uma melhor interao entre a equipe do itens do Product Backlog. No caso da empresa estudada, o desenvolvimento junto aos analistas de negcio este problema Product Backlog consiste no conjunto de requisitos pode ser resolvido. constantemente levantados para o sistema. Na empresa Alm disso, h o problema de falta de qualificao das analisada, prope-se que esse papel seja desempenhado pelos pessoas que levantam os requisitos. Atendentes de help desk analistas de negcios, pois so eles quem mais sabem sobre os nem sempre so pessoas qualificadas para fazer esse tipo de interesses dos requisitos e se os mesmo iro agregar valor ao trabalho por falta de conhecimento tcnico e de negcio, o sistema. que dificulta um pouco o processo. Na prtica do Scrum, a ideia que o Product Owner seja Cita-se tambm o fato de que os implantadores uma nica pessoa. Porm na empresa estudada existem dificilmente ficam na empresa, pois os mesmo esto claramente dois profissionais com essas atribuies. Portanto constantemente realizando viagens de instalaes e a proposta que o papel seja atribudo a apenas um deles por treinamentos. Eles so os maiores responsveis por trazerem cliente, e o outro atuar em seu auxlio. Essa pessoa requisitos de customizaes, que so normalmente aqueles representar o cliente, sempre realizando os contatos que causam maior impacto. Como resultado, a comunicao peridicos com a maioria deles, pois a empresa possui vrios com esses profissionais tambm dificultada. clientes e nem sempre os mesmos solicitam ou necessitam de Por ltimo, a forma de conduzir os requisitos que esto algo nas mesmas circunstncias. sendo implementados atualmente falha. Muitas vezes, Scrum Master - Este papel responsvel pela aplicao de devido ao tempo escasso e a necessidade de alterar os valores, prticas e pelo objetivo concretizado no final do requisitos que esto sendo implementados, muitas tarefas so Scrum. Ele considerado como um "facilitador" das reunies abortadas e novos requisitos so implementados sem nenhum removendo os obstculos ou qualquer impedimento que planejamento e isso um fator prejudicial em termos da comprometa o projeto. Tambm protege a equipe fazendo com qualidade, pois com isso podem ser gerados repetidos que eles no se comprometam a realizar tarefas que o time no requisitos de erros. pode sanar. Ele a principal chave que une o negcio e as Nota-se, portanto, que h uma srie de problemas no tecnologias e segundo (ZANATTA, 2004) suas principais processo da empresa. Para tentar resolv-los, prope-se aqui a atividades so organizar as Daily Meetings, representar o utilizao da metodologia gil Scrum que, com a sua gerente do projeto e o tcnico, gerenciar todo processo Scrum facilidade de uso pode ser adaptvel a realidade da empresa. dentro da organizao, e remover os impedimentos que A ideia propor solues para se obter um melhor resultado a comprometam o projeto. cada liberao de um incremento (verso release) do software Com o conceito definido deste papel, foi analisado que a proprietrio. melhor pessoa por esse papel seria uma pessoa da gerncia ou diretoria, pois na empresa existem dois scios e o gerente de
126 TI.S. 2014; 3 (2): 122-130
Felipe Luiz Carnevali, Daniel Lucrdio projeto, o qual tambm faz o papel de analista de negcio. Product Backlog na onde se inicia todo o processo do Ambos so divididos na seguinte questo: Um diretor Scrum, sendo considerada a prtica responsvel pela parte da responsvel pela implantao e outro responsvel pelo elicitao da rea de engenharia de requisitos onde os desenvolvimento. O gerente de projetos faz o papel de analistas de requisitos realizam as coletas dos requisitos gerncia e de analista de negcio. (SCHWABER; BEEDLE, 2002). Analisando o papel do Scrum Master o que melhor se Realizando reunies e tcnicas de levantamento de adaptaria seria o gerente de projetos, pois ele o que tem requisitos com todos stakeholders do projeto, so levantados e maior afinidade e contato com os clientes, e tambm por registrados os itens com todas as necessidades dos requisitos possuir um vasto conhecimento no negcio ele tambm de negcios e tcnicos para serem desenvolvidos, padres, capaz de sanar as dvidas tcnicas. Mesmo sabendo que os tecnologia entre outros fatores. Em outras palavras, para a diretores so os que participam mais no gerenciamento de empresa em questo, o Product Backlog a lista de atividades novos clientes, nem sempre ser possvel encontr-lo presente que sero desenvolvidas no projeto. na empresa, assim dificultado o processo do Scrum. Esta prtica pode ser realizada usando a ferramenta Scrum Team - Por meio de encontros com o Scrum Master, proprietria Dirio, pois ela contm todos os requisitos que o Scrum Team representado pela equipe de so necessrios para o desenvolvimento do produto e o seu desenvolvimento. No h necessidade de uma diviso entre trmino seria o software completo conforme solicitado. Um os integrantes desta equipe como, por exemplo, o aspecto interessante dessa ferramenta que possvel saber programador, o analista de banco de dados, o testador, entre quem fez uma solicitao, quem a realizou, e quem a aprovou. outros. O foco principal que todos trabalhem juntos no Apesar de que Scrum o foco o resultado e no a projeto para entregarem o conjunto de trabalho a qual foi rastreabilidade (ZANATTA, 2004), acreditamos que isto pode prometido durante a Sprint. A equipe tpica costuma-se ter contribuir para a melhoria no processo. entre 8 a 10 integrantes, podendo-se variar dependendo do Linda e Norman (2000) explicam que Daily Scrum so as ambiente em que se aplica. Pode existir mais de um Scrum reunies realizadas dentro do Scrum durante o Team dentro de uma organizao, e eles iro trabalhar desenvolvimento do projeto. Na maioria das vezes so feitas separadamente, porm quando se tem grandes equipes e diariamente, com durao de quinze minutos existe a necessidade de criar outras, usado o conceito de aproximadamente, lembrando que esse tempo no pode "Scrum of Scrums" (DESENVOLVIMENTO GIL, 2013). exceder o mximo de trinta minutos. Essa reunio realizada Em cada Scrum Team ser necessrio que um integrante para que a equipe Scrum possa expor suas dificuldades ou freqente o Scrum of Scrums Meeting, para que eles impedimentos que esto tendo durante a implementao do conversem entre si para que as mesmas possam coordenar o projeto. importante ressaltar que essas reunies no so trabalho de mltiplas equipes. utilizadas para a soluo do problema e sim, para expor os Atualmente na empresa a equipe de desenvolvimento problemas. de responsabilidade do Scrum Master encontrar composta por programadores, testadores e analistas de banco uma melhor maneira de solucionar esses problemas. O Scrum de dados, totalizando 21 integrantes. Baseando-se nas Master, durante as reunies, deve levar equipe trs recomendaes do Scrum prope-se criar trs equipes, cada importantes perguntas (ZANATTA, 2004) APUD uma composta por cinco desenvolvedores, um analista de (SCHWABER; BEEDLE, 2002): o que j foi finalizado desde banco de dados e um testador. Essa diviso foi realizada na a nossa ultima reunio, existe alguma dificuldade encontrada tentativa de incluir as trs principais categorias de nos trabalhos que esto sendo realizados, e quais so as profissionais necessrios para realizar implementaes prximas atividades que sero entregues no nosso prximo completas em todos os aspectos do sistema. A diviso encontro. tambm tenta manter em uma mesma equipe profissionais No estudo de caso realizado essas reunies seriam uma especializados nos mesmo mdulos do sistema, mantendo prtica muito eficaz, pois a falta de comunicao interna assim as equipes mais coesas. Por existir mais de uma equipe, evidente e isso contribuiria com o alinhamento de todas as existiu a necessidade de deixar uma responsabilidade maior pessoas que fazem parte do processo. Apesar dessa prtica no para um dos integrantes realizar o Scrum of Scrums Meeting. incidir tanto no processo dos requisitos de customizao, ela Esta questo no foi trivial, pois dentro da empresa j existia pode agregar valor no momento em que o desenvolvimento um conceito de que uma pessoa de cada mdulo fosse lder de encontre falha nos processo de requisitos de melhorias e erros. um determinado mdulo. Esse perfil de um desenvolvedor Com relao a Sprint pode-se dizer que considerada a com maior experincia no mdulo e conseqentemente com principal parte do Scrum, pois nela que so executados os mais tempo de colaborao. itens que foram adicionados no Product Backlog pelos Product Owner e os stakeholders do projeto. Esta etapa no A. 2) Prticas do Scrum pode exceder 30 dias, mas em mdia pode durar de uma a Alm da definio dos papis descrita anteriormente, quatro semanas. No Sprint normalmente adota-se a mesma prope-se a utilizao de algumas prticas para realizar o diviso tradicional no processo do desenvolvimento do gerenciamento com o Scrum tais como o Product Backlog, software: requisitos, anlise, projeto e entrega. Ao trmino de Daily Scrum, Sprint, Sprint Planning Meeting, Sprint Backlog cada Sprint a equipe Scrum cria uma demonstrao simples e Sprint Review Meeting. para ilustrar ao cliente como est o andamento do projeto, e
T.I.S. 2014; 3 (2): 122-130 127
Aplicando a Metodologia gil Scrum para apoio ao Gerenciamento de Requisitos com isso gerada uma sensao que o desenvolvedor existiam ou havia uma outra forma de utilizao no sistema. executou sua tarefa com xito (BEEDLE et al., 1999). O teste Essa proposta tem como objetivo reduzir um fator muito importante a ser realizado dentro desta consideravelmente grande parte de requisitos ambguos e etapa, pois assim possvel garantir a qualidade e validar se desnecessrios. Outro fator a ser considerado a maior os requisitos foram implementados de acordo com o facilidade em se medir os esforos e tempos para a entrega de especificado, significando menos problemas e redues na um requisito durante as reunies. Existem muitos requisitos lista do Product Backlog. Caso seja encontrada alguma falha solicitados com prazos escassos, e promessas feitas ao cliente e a Sprint ainda no tenha terminado, o mesmo deve ser sem a consulta prvia equipe sobre o impacto que o mesmo corrigido, ou gerado um novo item no Product Backlog como poderia causar. A reduo de estresse na equipe de dficit tcnico para ser realizado no prximo Sprint. desenvolvimento e a presso dos clientes sero reduzidas Para alinhamento dessa prtica no presente estudo de caso, notavelmente, pois as negociaes dos requisitos so uma das maiores contribuies seria a organizao nos melhores planejadas. requisitos em andamento, evitando assim o problema de O Sprint Backlog como mencionado acima, uma lista de duplicao de requisitos descrito anteriormente, pois a forma tarefas que gerada a cada Sprint Planning Meeting, a qual a de conduzir os requisitos que esto sendo implementados equipe Scrum se compromete a cumprir durante a Sprint falha. Muitas vezes devido ao tempo escasso e a necessidade corrente. Esses itens so extrados do Product Backlog, os de alterar os requisitos que esto em andamento, muitas quais foram priorizados pelo Product Owner, baseando-se na tarefas so abortadas e novos requisitos so implementados complexidade e tempo que ser necessrio para se realizar sem nenhum planejamento e isso o principal fator que aqueles requisitos. Cabe ao Scrum Team determinar a prejudicial nos termos de qualidade. Essa a principal quantidade de itens que sero implementados do Product questo levantada que fazem gerar erros inesperados. A ideia Backlog, pois o Sprint Backlog j a total responsabilidade da Sprint ter uma durao de no mximo 30 dias atualmente do time com relao a uma Sprint (DESENVOLVIMENTO j suprida, pois nos dados levantados a empresa j trabalha GIL, 2013). O papel do Scrum Master nesta etapa manter com prazos curtos de desenvolvimento. O acompanhamento o Sprint Backlog atualizado, para que toda a equipe e ele de como est implementao dos requisitos tambm j possam refletir sobre quais as tarefas foram completadas e existe de uma forma simples. A nica alterao proposta a qual ser o tempo necessrio para poder terminar as demais implementao de uma taskboard dentro da ferramenta que ainda esto na lista para serem feitas. Na prtica pode Dirio, para que os desenvolvedores e testadores consigam acontecer de alguns dos itens que foram selecionados no alterar o andamento de como est o desenvolvimento de um Sprint Backlog no poderem ser implementados, por isso determinado requisito, o que hoje no possvel. cabe ao integrante do Scrum Team expor isso nas Daily O Sprint Planning Meeting a reunio que realizada na Scrum para que o Scrum Master possa verificar o que pode qual devem estar presentes o Product Owner, o Scrum Master ser feito, como por exemplo, passar a Task para outro e todo a equipe do Scrum (DESENVOLVIMENTO GIL, integrante do time, ou mesmo negociar com Product Owner. 2013). nesta etapa que o Product Owner descreve quais as Realizando a adaptao dessa prtica para a empresa funcionalidades so de maior importncia e que tm maior estudada, a sobrecarga de trabalho no Scrum Team, caso relevncia para serem desenvolvida primeiro. No exista, passar a ficar explcita, pois depois de definidos os necessrio que o Product Owner descreva todas as itens que sero entregues em cima dos prazos prioridades e sim, de preferncia a quais iro participar comprometidos, so evitados os requisitos passados sem daquele Sprint. Nesse momento o Scrum Team ir realizar nenhum planejamento. Tambm fica notrio para os diretores perguntas de modo que seja possvel o refinamento dos e gerente que todos os colaboradores da equipe possuem Backlog Items em Task (tarefas) tcnicas logo aps a tarefas e que ambos esto se empenhando no projeto. reunio. Esses conjuntos de Tasks daro a origem ao Sprint Na finalizao de cada Sprint realizada a Sprint Review Backlog. Aps a criao do Sprint Backlog o Scrum Team e Meeting. Nesta reunio, o Scrum Team mostra o que foi o Product Owner iro definir o objetivo daquele Sprint, que realizado durante a Sprint. Formalmente, isso pode ser ser uma breve descrio do que ir ser entregue e qual ser apresentado em uma demonstrao ou uma prvia descrio o objetivo dos requisitos implementados. Muitas vezes esses das novas funcionalidades. Essa reunio realizada junto requisitos podem ser implementaes implcitas que pode equipe do Scrum, Scrum Master, Product Owner e os demais obter nenhum resultado final palpvel pelo cliente, porm stakeholders que compem o projeto. O Scrum Master junto isso discutido e explicado durante o Sprint Planning ao Product Owner mais os stakeholders iro analisar se o Meeting. Aps toda a definio e o Sprint Backlog aprovado incremento satisfaz o que foi comprometido na Sprint pela equipe Scrum possvel se iniciar a Sprint. Planning Meeting. Mesmo que todos ou alguns itens no Essa prtica, se introduzida na empresa estudada, apesar tenham sido implementados no Sprint Backlog, a ideia de aparentemente ocupar tempo produtivo, faria com que os principal que a equipe atinja o objetivo final daquela Sprint. desenvolvedores e analistas de negcios expusessem mais as Adotando-se esta prtica no estudo de caso, a proposta ideias do que j existe na ferramenta, e o que realmente haver um aumento da satisfao do cliente e existe a necessidade de implementar, pois conforme conseqentemente a satisfao da equipe de levantado muitos requisitos eram solicitados e os mesmo j desenvolvimento, pois nessas reunies, conforme a
128 TI.S. 2014; 3 (2): 122-130
Felipe Luiz Carnevali, Daniel Lucrdio apresentaes das demonstraes os clientes podem ter a foi solicitada. confiana da utilizao da nova funcionalidade produzida em A validao passou a ser mais sucinta, pois com os clientes um pequeno espao de tempo. presentes a cada levantamento e a cada apresentao do incremento, j era realizada a aprovao se o que foi realizado B) Resultados preliminares e discusso abrange a necessidade acordadas no incio de cada Sprint. A proposta de melhoria est em estgio avanado de Realizando a apresentao formal, foi possvel analisar a implementao, tendo j implementado a taskboard e todos satisfao do cliente quanto ao que foi prometido. A satisfao os papis e algumas prticas do Scrum tais como o Product um ponto muito importante no Scrum quando se refere ao Backlog, Daily Scrum, a Sprint, a Sprint Backlog e o Sprint cliente, mas isto foi recproco a equipe tambm, pois ver o Review Meeting. Com os papis bem definidos foi simples resultado positivo do produto fez com que a equipe se organizar algumas prticas dentro da organizao, e com a motivasse mais fazendo com que haja harmonia e um bom implementao da taskboard no aplicativo Dirio a equipe relacionamento entre eles. Este ponto, alis, uma das pode acompanhar como est o andamento dos requisitos. caractersticas que a metodologia gil foca: A valorizao das Uma prtica que ainda falta ser implementada Scrum of pessoas que fazem parte do projeto. Scrums Meetting, pois est sendo necessrio realizar algumas Em resumo, com a realizao das trs principais fases da adaptaes de horrios e pessoas entre as reunies dirias, engenharia de requisitos aplicados junto metodologia gil para que depois implemente as reunies entre as equipe. O Scrum foi possvel obter um documento de todos os itens que Sprint Planning Meeting foi parcialmente implementado pois foram e sero implementados de forma simples, clara e existem trabalhos atrasados e precisam ser realizados devido objetiva sem muita burocracia. Foi tambm adquirida a to aos prazos prometidos anteriormente. importante comunicao que fez acontecer um melhor Analisando os resultados ficou explicita a questo de como planejamento do produto a ser implementado realizando a a metodologia gil melhorou o processo da engenharia de integrao do time como se fosse um s com o principal requisitos. Focando nos pontos principais que so a objetivo de obter o que foi acordado com qualidade, agilidade elicitao, especificao e validao, a utilizao das prticas e a satisfao do cliente. e regras do Scrum, junto com a definio de papis aplicado dentro da empresa, obteve-se um resultado satisfatrio. A V. TRABALHOS RELACIONADOS reduo de requisitos desnecessrios e redundantes foi Na metodologia Scrum a simplicidade e a agilidade so os efetivamente observada, causando grande impacto em termos principais aspectos as quais suas prticas induzem realizar o de agilidade. gerenciamento baseado principalmente nas pessoas e nos Outro ponto positivo que, mesmo que a utilizao de processos. Diferente de outras prticas de gerenciamento de algumas prticas provoque alguma perda de tempo produtivo requisitos que envolvem regras e tcnicas na qual o principal com reunies, este tempo sutilmente pequeno analisando o processo realizar um gerenciamento mais burocrtico perde- tempo que se perdia implementando requisitos sem se a eficincia da praticidade. Para o Scrum esses quesitos so necessidade ou mesmo o tempo que era gasto para se fazer o diferenciais, pois o seu principal objetivo a satisfao do levantamento do mesmo. Observou-se alguma reclamao, cliente, e para se garantir isso necessrio que haja qualidade mas principalmente por parte da gerncia. No geral, a equipe e gerenciamento eficaz. Na literatura, possvel encontrar e os clientes mostraram-se satisfeitos com o resultado. alguns esforos em se aplicar mtodos geis e mtodos de Com as tarefas sendo registradas, e com o explicativo de gerenciamento de requisitos. que aquele requisito faz, foi possvel aumentar a capacidade Zanatta (2004) prope a utilizao da metodologia gil dos envolvidos em saber como est o software atualmente. Scrum para a gerncia de requisitos utilizando as prticas do Com relao ao foco na comunicao, a utilizao de CMMI e fazendo uma adaptao. O resultado foi satisfatrio, papis mais bem definidos levou a elicitao a um nvel mais mas nem todas as prticas abordadas pelo Scrum so produtivo. Foi possvel aproximar no s os clientes e atendidas pelo conceito do CMMI. Segundo o autor, isso se analistas de requisitos, mas todos os integrantes da equipe, deve ao fato de que o CMMI introduz prticas de tais como programadores, testadores e outros, que passaram a gerenciamento burocrticas, e por isso muitos de seus itens ter uma melhor viso do negcio e do produto a ser CMMI no seriam contemplados. implementado. Dar essa importncia a todos da equipe Espindola et al. (2004) realizam uma anlise crtica do mau emotiva e aumenta as ideias para encontrar uma melhor gerenciamento dos requisitos e enfatiza o impacto das soluo para o incremento final do produto. negociaes dos requisitos. Os autores afirmam que a analise A especificao tambm tornou-se mais clara, sendo que o responsvel por identificar requisitos conflitantes, Scrum Team j obteve o conhecimento do contexto e o esquecidos, ambguos ou irreais. Entretanto esta atividade objetivo final do que tem que ser feito, pois as conversas realizada com os interessados do projeto pode ser prejudicada realizadas com o Product Onwer e os stakeholders fizeram devida falta de interao entres os stakeholders e o analista com que eles entendessem melhor o dia a dia e a dificuldade de requisitos. O Scrum prope que a constante interao entre que os usurios tem em manusear o software, assim obtendo os interessados do projeto uma das principais caractersticas uma ideia e planejamento melhor na hora de realizar a para o sucesso do negcio, e um dos princpios baseados na implementao para que satisfaa o cliente da maneira que metodologia.
T.I.S. 2014; 3 (2): 122-130 129
Aplicando a Metodologia gil Scrum para apoio ao Gerenciamento de Requisitos O presente estudo de caso vem corroborar outras 2003, 492p. observaes da literatura, como por exemplo, a praticidade do SOMMERVILLE, I.; SAWYER, P. Requirements Engineering Scrum e a importncia da comunicao. Com isso aumenta-se a good practice guide. New York: John Wiley & Sons a evidncia em favor dessa prtica gil j bastante difundida. Ltd, 1997, 391p. ESPINDOLA, R. S.; MAJDENBAUM, A.; AUDY, J. L. N. VI. CONCLUSES E TRABALHOS FUTUROS Uma Anlise Crtica dos Desafios para Engenharia de Conclumos com este trabalho que importante ressaltar Requisitos em Manuteno de Software. In: VII Workshop que quando os requisitos no so bem definidos, a obteno on Requirements Engineering, 2004, Tandil, Argentina, da qualidade dificultada, assim como cumprimento de 2004. prazos e custo dentro do contexto do desenvolvimento de AGILE SURVEY; 7th Annual Survey: 2012 The State of software. Problemas similares foram relatados com base em Agile Development Conducted: June-July, 2012 - um estudo de caso em uma empresa de software, que vivencia Disponvel em: http://www.versionone.com/ Acessado em: na prtica essa realidade. 10 agosto 2013. Com as melhorias propostas, observou-se que a BEEDLE, M.; DEVOS, M.: SCRUM: A Pattern Language for metodologia gil Scrum pode proporcionar esse fator de Hyperproductive Software Development. In Pattern qualidade, prazo e custo como as demais metodologias Languages of Program Design 4, editado por N. Harrson, convencionais, porm visando a agilidade e a satisfao do B. Foote, e H. Rohnert. Addison-Wesley (1999). cliente, obtendo softwares mais rpidos e pertinentes SCHWABER, K.; BEEDLE M.: Agile Software Development conforme a solicitao do cliente. Com os papis, prticas e with Scrum, Upper Saddle River, NJ, Prentice Hall. regras do Scrum, so explcitas as melhorias que foram (2002). aplicadas na utilizao desta metodologia. ZANATTA L. A. xScrum: uma proposta de extenso de um Como trabalhos futuros, sugere-se a realizar a utilizao de Mtodo gil para Gerncia e Desenvolvimento de mais de uma metodologia gil em conjunto, como por Requisitos visando adequao ao CMMI. Florianpolis, exemplo, o Scrum e o Extreming Programming (XP), pois de 2004. 180 pginas. Dissertao (Mestrado em Cincia da acordo com Abrahamsson et al. (2002) quando mais de uma Computao) - Curso de Ps-Graduao em Cincia da metodologia gil utilizada ao mesmo tempo, melhora-se o Computao, Universidade Federal de Santa Catarina. processo de agilidade. Por exemplo, um ponto forte da FOWLER, M. The New Methodology. Disponvel em: utilizao do XP seria o apoio na melhoria no fator da <http://www.martinfowler.com/articles/newMethodology.h utilizao das prticas da engenharia de software tais como tml>. Acesso em : set 2013. Test Driven Development (TDD), Refactoring, Pair HIGHSMITH, J.; Agile Software Development Ecosystems. Programming entre outras. Como o Scrum no define o uso Addison Wesley, 2002. desse tipo de tcnica, o XP seria um bom complemento ao LINDA R.; NORMAN J.,: The SCRUM Software processo, proporcionando maior agilidade tambm no mbito Development Process for Small Teams, IEEE Software, da programao. July-August 2000. DESENVOLVIMENTO GIL; Disponvel em: < REFERNCIAS http://desenvolvimentoagil.com.br/>. Acesso em 26 set, 2013. LEITE, J.C.S.P. Engenharia de Requisitos- Notas de Aula., GILE MANIFESTO; Disponvel em: 1994. <http://www.agilemanifesto.org/principles.html>. Acesso KOTONYA, G.; SOMMERVILLE, I. Requirements em 23 set, 2013. Engineering: Processes and Techniques., Jonh Wiley & ABRAHAMSSON, P.; SALO, O.; RONKAINEN, J.; Sons Ltd., 1998. WARSTA, J. Agile Software Development Methods: LEFFINGWELL, D.; WIDRIG, D. Managing Software Review and Analysis. Espoo, VTT Electronics, 107 p. Requirements: a unified approach., Addison-Wesley, 2000. Publicao VTT 478. (2002). LEFFINGWELL, D,; WIDRIG, Don. Managing Software BECK, K. Extreme Programming: Embrace Change. Addison Requirements A Use Case Approach. Addison-Wesley. Wesley. 2000.