Scrum-Half: Uma Ferramenta Web de Apoio ao Scrum Diego R. Marins 1,2, José A. Rodrigues Nt. 1, Geraldo B. Xexéo 2, Jano M. de Sousa 1 1 Programa de Engenharia de Sistemas e Computação - COPPE/UFRJ 2 Departamento de Ciência da Computação - IM/UFRJ {diegomarins,rneto,xexeo,jano}@cos.ufrj.br Abstract. This paper presents the Scrum-Half, which was developed with the purpose of supporting the use of Scrum in project management. The motivation is to facilitate the organization and coordination of a software development team and assist them in making decisions, so that the use of Scrum becomes more efficient. The Scrum-Half allows the user to track the Scrum flow, since the preparation and maintenance of the Product Backlog to the planning, development and end of each Sprint. 1. Introdução Com o objetivo de apoiar o Scrum (Schwaber 2004), foi desenvolvida uma ferramenta web, o Scrum-Half, cujo nome teve origem em uma das posições de jogo do Rugby. A motivação para esse trabalho foi facilitar a organização de uma equipe de desenvolvimento de software e auxiliá-la nas tomadas de decisão, de modo que o uso do Scrum se torne ainda mais eficiente. A ferramenta armazena informações sobre as Sprints, registrando a velocidade da equipe e estatísticas sobre a quantidade de tarefas concluídas em cada iteração e quais tarefas ficaram pendentes. Isso permite uma visão rápida sobre o desempenho da equipe, auxiliando sua evolução. Além disso, na construção da ferramenta, houve a preocupação em se fazer um estudo detalhado sobre o Scrum, de modo que ela fosse desenvolvida com a maior proximidade possível aos conceitos da metodologia. Com isso, espera-se que a ferramenta auxilie as equipes que adotaram o modelo ágil a obter sucesso com o uso do Scrum nos projetos de desenvolvimento de software. 2. Breve Introdução ao Scrum O Scrum é uma metodologia de desenvolvimento ágil que possui características importantes como os períodos curtos de trabalho onde são desenvolvidos alguns itens de uma lista priorizada pelo cliente. Cada período é chamado de Sprint e quando sua duração chega ao final, uma nova funcionalidade é apresentada. Durante toda a Sprint a equipe se reúne diariamente para discutir o que foi feito, os obstáculos encontrados e o que será feito até a próxima reunião (Pressman 2006). As Sprints ocorrem uma após a outra e consistem no Planejamento de Sprint, no trabalho de desenvolvimento, na Revisão da Sprint e na Retrospectiva da Sprint (Schwaber & Sutherland 2008). A lista de itens possui os requisitos do produto em desenvolvimento e é chamada de Product Backlog. Ela é criada no início do projeto e é modificada constantemente para identificar o que o produto necessita para ser apropriado, competitivo e útil (Schwaber 2004). Outro artefato importante do Scrum é o Sprint Backlog, construído na reunião de planejamento da Sprint. O Sprint Backlog define as tarefas que a equipe terá
que desenvolver para transformar os itens do Product Backlog selecionados para a Sprint em um incremento de funcionalidade ao término dela (Schwaber 2004). No Scrum, a responsabilidade de avaliar e aceitar o produto construído pela equipe cabe ao Product Owner. Ele também é o responsável por definir as características do produto e gerenciar o Product Backlog, priorizando seus itens de acordo com o valor de negócio (Srinivasan & Lundqvist 2009). Outro papel, o Scrum Master, tem a função de facilitar o desenvolvimento de software, removendo obstáculos e acompanhando o progresso da equipe Scrum. Uma equipe Scrum pode ser constituída de desenvolvedores, analistas de banco de dados, administradores de sistema, entre outros, dependendo do trabalho que será feito no projeto (Cohn et al. 2009). 3. Ferramentas Relacionadas Outras ferramentas já foram desenvolvidas com o mesmo objetivo, como o ScrumNinja (Carvalho & Lowenfels 2009), o imeta Agility (imeta 2009), o Scrum`d (Atlantic Dominion Solutions 2010) e o SkinnyBoard (Fluid Media Inc 2009). Essas quatro ferramentas oferecem um serviço web pago mensalmente, com preço calculado de acordo com o plano escolhido, na maioria dos casos levando em consideração o número de usuários que usará o serviço. Elas diferem principalmente na forma de organizar o Product Backlog e o Sprint Backlog. Exceto o Scrum`d, as ferramentas citadas oferecem o quadro de tarefas para definir o estado da tarefa na Sprint em andamento. O Scrum-Half também oferece um quadro de tarefas para ser usado durante a Sprint e permite a organização do Product Backlog e do Sprint Backlog. Além disso, o Scrum-Half possui o diferencial de acompanhar o fluxo Scrum, seguindo as etapas necessárias para o desenvolvimento de um projeto de software, auxiliando as reuniões para elaboração e encerramento da Sprint e também no dia a dia do trabalho de desenvolvimento. Atualmente, é possível utilizar o sistema gratuitamente em http://carambola.cos.ufrj.br/scrum-half. 4. Arquitetura O Scrum-Half utiliza uma arquitetura web. A ferramenta foi implementada em Java utilizando o banco de dados MySql (Oracle Corporation 2010b) e o servidor de aplicação JBoss (Red Hat 2010). O lado servidor foi desenvolvido com uma arquitetura com as seguintes camadas: apresentação, controle, serviços, domínio de negócio e persistência. A camada de apresentação, responsável pela comunicação com o cliente, foi feita utilizando o framework JavaServer Faces (JSF) (Oracle Corporation 2010a). Além disso, foram utilizados componentes Enterprise JavaBeans (EJB) e a Java Persistence API (JPA) (Oracle Corporation 2010a), utilizada na camada de persistência. As classes de domínio de negócio foram modeladas com base nos conceitos do Scrum, seus artefatos e as relações entre eles. 5. Descrição da Ferramenta 5.1. Características Gerais O Scrum-Half permite que um usuário participe de mais de um projeto, possuindo papel diferente em cada um deles. É possível atribuir um ou mais papéis do Scrum a um
membro do projeto. Essa escolha implica em privilégios no sistema, de acordo com as características de cada papel. Além disso, o sistema permite a atribuição do papel Gerente, caso necessário, para um membro da equipe que estiver utilizando o sistema. 5.2. O Product Backlog do Scrum-Half Ao acessar o Product Backlog o usuário visualiza a lista de requisitos do projeto, chamados de itens de Backlog. Além dele, o usuário também pode visualizar a lista de itens de Backlog pendentes, que é formada pelos itens de Backlog criados, mas ainda não aprovados pelo Product Owner. De acordo com o Guia do Scrum (Schwaber & Sutherland 2008), os itens do Product Backlog possuem os atributos de descrição, prioridade e estimativa. A prioridade é determinada por risco, valor e necessidade e é o atributo responsável pela ordenação dos itens. Os itens do Product Backlog podem ser atualizados a qualquer momento. Enquanto o Product Owner é o responsável pela prioridade dos itens, a equipe fica responsável por todas as estimativas. Os itens de Backlog do Scrum-Half possuem esses três atributos. No momento da criação de um item, qualquer usuário, independente do papel que exerce na equipe, pode informar os dados, a prioridade e a estimativa. Porém, um item criado precisa ser aceito pelo Product Owner para poder fazer parte do Product Backlog. Na atualização dos itens pertencentes ao Product Backlog, o Product Owner pode alterar os dados e a prioridade de um item, enquanto o Scrum Master, a Equipe Scrum e o Gerente podem alterar a estimativa. Os atributos de prioridade e de estimativa possuem valor numérico. No caso da prioridade, quanto maior o valor de um item, mais importante para o cliente ele é. Já para o caso da estimativa, um valor maior corresponde a um item mais difícil de ser desenvolvido. Figura 1. Criação de Item de Backlog
Figura 2. Product Backlog 5.3. Planejamento, Andamento e Encerramento da Sprint no Scrum-Half Uma Sprint é uma iteração de duração fixa. Sua data final não muda mesmo que a equipe precise reduzir a funcionalidade entregue para poder concluir na data especificada (Rising & Janoff 2000). A reunião de planejamento da Sprint é o momento no qual a iteração é planejada. Nela são decididos os itens do Product Backlog que serão desenvolvidos na próxima Sprint. A equipe define como transformará os itens selecionados em um incremento pronto. O trabalho necessário para isso é definido numa lista de tarefas chamada de Sprint Backlog (Schwaber & Sutherland 2008). O Scrum-Half possui uma funcionalidade para o planejamento da Sprint. Nela o usuário primeiramente define o nome, o objetivo, a data de início e a data de término. Concluída essa etapa o sistema apresenta o Product Backlog para seleção dos itens que farão parte da iteração. Para auxiliar na escolha dos itens, o sistema informa a velocidade mínima, média e máxima da equipe, que correspondem respectivamente à quantidade mínima, média e máxima de pontos de estimativa que a equipe concluiu nas Sprints anteriores. Um diferencial do Scrum-Half no planejamento da Sprint é a recomendação de um conjunto de itens de Backlog que podem ser desenvolvidos na próxima iteração, de acordo com a velocidade da equipe. A criação de tarefas do Sprint Backlog é feita no quadro de tarefas. O quadro apresenta todas as tarefas criadas para a Sprint correspondente e o estado em que cada uma se encontra. Além disso, permite a atualização do Sprint Backlog a qualquer momento, acrescentando tarefas novas, atualizando dados ou removendo as que foram mal planejadas. O quadro possui três colunas, na seguinte ordem: TAREFAS PENDENTES, TAREFAS EM ANDAMENTO e TAREFAS CONCLUÍDAS. As tarefas são criadas na primeira coluna e são movidas por drag and drop para as outras colunas no decorrer da Sprint. Em todas as colunas as tarefas são ordenadas de acordo com a
prioridade do item de Backlog correspondente. Com o quadro de tarefas é possível ter uma visão rápida do número de tarefas concluídas e de quantas ainda estão por fazer. Figura 3. Quadro de Tarefas Outro artefato que permite acompanhar o progresso da Sprint, também presente no Scrum-Half, é o gráfico de Burndown. Ele mostra o trabalho restante ao longo do tempo e o progresso da equipe na redução desse trabalho. O trabalho restante é monitorado no eixo vertical e os períodos de tempo da Sprint são monitorados no eixo horizontal (Schwaber 2004). A quantidade de trabalho restante para a Sprint é determinada pela soma das estimativas dos itens de Backlog restantes (Schwaber & Sutherland 2008). A funcionalidade desenvolvida na Sprint é apresentada ao Product Owner durante a Reunião de Revisão da Sprint (Schwaber 2004). Na Reunião de Retrospectiva da Sprint, por sua vez é feita a revisão do processo de desenvolvimento, de forma a torná-lo mais eficaz e gratificante para a próxima iteração. (Schwaber & Sutherland 2008). O Scrum-Half oferece apoio às duas reuniões na funcionalidade de encerramento da Sprint, permitindo que o Scrum Master ou o Gerente informe os itens de Backlog que foram aceitos pelo Product Owner e também registre os pontos positivos e negativos da Sprint, para que possam ser avaliados a qualquer momento, visando auxiliar a evolução da equipe. 6. Conclusão Esse artigo apresentou o Scrum-Half, uma ferramenta que possui as funcionalidades básicas para o uso do Scrum, tais como o registro do Product Backlog e a manipulação do quadro de tarefas durante a Sprint. Além disso, o Scrum-Half possui também o diferencial de auxiliar nas reuniões de Scrum, fornecendo informações úteis para o planejamento da Sprint e permitindo o registro do que é aprendido nas reuniões de revisão e retrospectiva. Armazenar o que ocorre na construção de um software é importante para a equipe evoluir com a própria experiência. O registro do que foi desenvolvido em cada
Sprint auxilia o planejamento das Sprints futuras, obtendo uma estimativa para término do projeto mais próxima da realidade. O Scrum-Half tem como objetivo apoiar o uso do Scrum, mas não propõe substituir as reuniões do Scrum ou qualquer forma de integração da equipe, pois o contato pessoal é muito importante para o sucesso de um projeto. No entanto, em projetos que possuem equipes distribuídas, o Scrum-Half auxilia a unir a equipe e manter a sincronia dos dados do projeto, como os itens de Backlog e as tarefas em andamento na Sprint. 7. Referências Atlantic Dominion Solutions, 2010. Scrum`d. Scrum`d. Disponível em: http://www.scrumd.com/ [Acessado Maio 23, 2010]. Carvalho, R. & Lowenfels, D., 2009. ScrumNinja. ScrumNinja. Disponível em: http://scrumninja.com [Acessado Outubro 12, 2009]. Cohn, M.L., Sim, S.E. & Lee, C.P., 2009. What counts as software process? Negotiating the boundary of software work through artifacts and conversation. Computer Supported Cooperative Work, 401-443. Fluid Media Inc, 2009. SkinnyBoard. Disponível em: http://www.skinnyboard.com [Acessado Outubro 12, 2009]. imeta, 2009. imeta Agility. imeta Agility Scrum Software Management Software. Disponível em: http://agility.imeta.co.uk/ [Acessado Outubro 12, 2009]. Oracle Corporation, 2010a. Java.sun.com. Disponível em: http://java.sun.com/ [Acessado Junho 20, 2010]. Oracle Corporation, 2010b. MySQL. Disponível em: http://www.mysql.com [Acessado Junho 20, 2010]. Pressman, R.S., 2006. Engenharia de Software 6 ed., McGraw-Hill. Red Hat, 2010. JBoss Community. Available at: 20/06/2010. Rising, L. & Janoff, N.S., 2000. The Scrum Software Development Process for Small Teams. IEEE Software, 26-32. Schwaber, K., 2004. Agile Project Management With Scrum 1º ed., Microsoft Press. Schwaber, K. & Sutherland, J., 2008. Scrum Guide, Srinivasan, J. & Lundqvist, K., 2009. Using agile methods in software product development: A case study. 6th International Conference on Information Technology: New Generations, 1415-1420.