Estudo sobre Desenvolvimento de Software Utilizando o Framework Ágil Scrum

Transcrição

1 Estudo sobre Desenvolvimento de Software Utilizando o Framework Ágil Scrum Andre Scarmagnani 1, Fabricio C. Mota 1, Isaac da Silva 1, Matheus de C. Madalozzo 1, Regis S. Onishi 1, Luciano S. Cardoso 1 1 UDC ANGLO Faculdade Anglo Americano (FAA) Av. Paraná, 5661, CEP: Foz do Iguaçu PR Brasil {andre-scar, caceres.mota, shindionishi}@hotmail.com, isaac.s@outlook.com, matheus.madalozzo@gmail.com, lucianoscardoso@gmail.com Abstract. Agile development methodologies has been outstanding every day, but these are still not widespread in academia. The purpose of this article, as well as disseminating this issue and provide support for future research is to demonstrate a simple and objective way, operation, features, vocabulary and application of the scrum framework in a work environment. Resumo. As metodologias de desenvolvimento ágil vem se destacando a cada dia, porém essas ainda são pouco difundidas no meio acadêmico. O objetivo deste artigo, além de difundir esse assunto e servir de apoio para futuras pesquisas, é demonstrar de maneira simples e objetiva, o funcionamento, as características, o vocabulário e a aplicação do framework scrum em um ambiente de trabalho. 1. Introdução Atualmente, os negócios atuam em um ambiente sujeito a mudanças constantes, como novas oportunidades de mercados, diferentes condições econômicas e o surgimento de produtos e serviços concorrentes. Para quase todas as operações de negócios é essencial que um novo software seja desenvolvido e, para maior competitividade, deve ser em curto prazo. O desenvolvimento ágil muitas vezes é requisito fundamental para a criação de softwares a fim de que consigam atender mais prontamente as demandas do cliente. Segundo [Sommerville 2006], os processos de desenvolvimento ágil de software são projetados para criar softwares úteis rapidamente. Geralmente, são processos iterativos nos quais a especificação, o projeto, o desenvolvimento e o teste são intercalados. O software não é desenvolvido e disponibilizado integralmente, mas em uma série de incrementos, onde cada incremento inclui uma nova funcionalidade do sistema. Na engenharia de software existem modelos que trabalham de forma ágil nos processos, com semelhanças entre as abordagens filosóficas e práticas. Dentro dessa abordagem surgiu o manifesto para o desenvolvimento ágil de software, cujo o objetivo era descobrir melhores maneiras de desenvolver software [Beck et al. 2001]. Uma das maneiras encontradas foi a utilização do framework Scrum que foi desenvolvido por Jeff Sutherland na década de 90.

2 2. Conceitos de Scrum O framework Scrum utilizado para gestão de desenvolvimento de software complexos. Essa ferramenta não é um processo para construir produto, mas sim um framework no qual pode ser empregado vários processos ou técnicas, tendo uma eficácia relativa das práticas de gerenciamento e desenvolvimento de softwares. O Scrum é formado pelos times do Scrum, associados a papeis, eventos, artefatos e regras. Cada uma dessas associações dentro do framework servem a um proposito e é importante para o sucesso do Scrum. O framework tem sua fundamentação nas boas práticas que foram adquiridas através da realização de vários projetos e que tiveram seus processos de maior sucesso documentados, empregando uma abordagem iterativa e incremental para aperfeiçoar a previsão e o controle de riscos. Três pilares apoiam a implementação de controle de processo empírico: Transparência Aspectos significativos do processo devem estar visíveis aos responsáveis pelos resultados. Inspeção Os usuários Scrum devem, frequentemente, inspecionar os artefatos Scrum e o progresso em direção a detectar variações. Adaptação Se um inspetor identifica que um processo se desviou para fora dos limites aceitáveis, e que o produto resultado será inaceitável, o processo ou o material sendo produzido deve ser ajustado o mais breve possível. O Scrum possui quatro eventos formais, contidos dentro dos limites da Sprint 1, para inspeção e adaptação, conforme mostra na figura 1 [Sutherland and Schwaber 2011] Figura 1. Ciclo da sprint. (Fonte: Adaptada de [Schwaber and Beedle 2002]). 3. O Time O time Scrum é composto pelo product owner, o time de desenvolvimento e o scrum master, os integrantes do time Scrum são auto-organizáveis, ou seja, escolhem qual a melhor forma para completarem seu trabalho, em vez de serem dirigidos por outros de fora do time. São multifuncionais pois possuem todas as competências necessárias para completar o trabalho sem depender de outros de fora da equipe. O modelo de time no Scrum é projetado para aperfeiçoar a flexibilidade, criatividade e produtividade. A Entrega dos produtos é feita de forma iterativa e incremental, o que resulta em mais oportunidades de realimentação 1 Abordado na seção 5.1

3 3.1. Product Owner O Product Owner (PO), ou dono do produto é o responsável por maximizar o valor do produto e do trabalho da equipe de Desenvolvimento e é a única pessoa responsável por gerenciar o Product Backlog O PO está ligado à visão de negócio do projeto, ele representa o interesse das pessoas que investem no desenvolvimento do produto[neto 2012]. Sua maior responsabilidade é gerenciar o Product Backlog que inclui: Ordenar os itens do Product Backlog de acordo com a visão de prioridade do cliente; Garantir a transparência do Product Backlog; Aceitar ou rejeitar os resultados dos trabalhos; Decidir o momento de liberação do produto ou de suas versões funcionais para o cliente Time de Desenvolvimento O time de desenvolvimento consiste de profissionais que transformam o Product Backlog em um produto funcional. É esse time que desenvolve as versões incrementais do produto pronto que são entregues ao final de cada Sprint. O tamanho ideal do time é pequeno o suficiente para se manter ágil e grande o suficiente para ser capaz de completar uma parcela significativa do trabalho Também espera-se que time possua um caráter auto-gerenciável, com o comprometimento e uma postura multifuncional dos membros representando um fator crucial para o sucesso do projeto Scrum Master O scrum master é o gerente do projeto, o responsavel por garantir que a equipe siga de maneira adequada as práticas da scrum e também responsável por eliminar os obstáculos que impedem o bom funcionamento do Scrum. 4. Eventos Scrum O Scrum utiliza os eventos prescritos parar criar uma rotina e minimizar a necessidade de reuniões não definidas no Scrum. Os eventos podem terminar quando o propósito for alcançado, ou seja, disponibiliza o tempo adequado aos processos e evita possíveis perdas 4.1. Sprint A parte fundamental do Scrum é a Sprint, no qual uma versão incremental potencialmente utilizável do produto é criada. Suas durações são coerentes em todo o esforço de desenvolvimento e iniciam uma após a outra, com intervalos não maiores que um mês. Durante a Sprint não são feitas mudanças que possam colocar em perigo o objetivo da Sprint. As metas de qualidade não diminuem e o escopo pode ser renegociado entre o Product Owner e o Time de Desenvolvimento de acordo com o que foi aprendido.

4 Cada Sprint tem a definição do que é para ser construído, um plano projetado e flexível que irá guiar a construção, o trabalho e o resultado do produto. O intervalo entre uma Sprint e outra for muito longo, aumentam os riscos de erros e prejuízos. Sprints rápidas permitem uma previsão que garante a correção e adaptação do progresso em direção ao objetivo, pelo menos a cada mês. O objetivo da Sprint é satisfeito através da implementação do Backlog do produto, que por sua vez, fornece ao time de desenvolvimento o porquê de estar construindo o incremento, criado durante a reunião de planejamento da Sprint. O time de desenvolvimento implementa a funcionalidade e tecnologia no intuito de satisfazer o objetivo da Sprint, se o trabalho for finalizado por ser diferente do esperado pelo time de desenvolvimento, então eles contam com o Product Owner para negociar o escopo do backlog 4.2. Reunião de Planejamento da Sprint Em [Schwaber and Beedle 2002], o trabalho a ser realizado na Sprint é planejado na reunião de planejamento. Este plano é criado com o trabalho colaborativo de todo o time Scrum. O Scrum Master garante que o evento ocorra e que os participantes entendam seu propósito, ensinando o time Scrum a manter-se dentro dos limites do time-box. A reunião de planejamento da Sprint responde as seguintes questões: O que pode ser entregue como resultado do incremento da próxima Sprint? Como o trabalho necessário para entregar o incremento será realizado? 4.3. Reunião Diária As reuniões diárias do scrum são realizadas para que o time de desenvolvimento, possa inspecionar o trabalho das reuniões posteriores, e prever o próximo trabalho que deverá ser feito. De acordo com [Sutherland and Schwaber 2011], durante a reunião os desenvolvedores esclarecem: O que eu fiz ontem que ajudou o time de desenvolvimento a atender a meta da Sprint? O que eu farei hoje para ajudar o time de desenvolvimento atender a meta da Sprint? Eu vejo algum obstáculo que impeça a mim ou o time de desenvolvimento no atendimento da meta da Sprint? O time de desenvolvimento utiliza as reuniões para inspecionar o processo em direção ao objetivo. O Scrum Master assegura que a equipe de desenvolvimento tenha a reunião, porém a equipe é responsável por conduzi-la. As reuniões diárias melhoram as comunicações, eliminam outras reuniões, identificam e removem impedimentos para o desenvolvimento, destacam e promovem rápidas tomadas de decisão, e melhoram o nível de conhecimento do time de desenvolvimento Revisão da Sprint A revisão é executada no final, para inspecionar o incremento e adaptar o Backlog do produto se necessário. Qualquer mudança no Backlog do produto durante a Sprint, os

5 participantes colaboram nas próximas coisas que podem ser feitas para otimizar. Esta é uma reunião informal, não uma reunião de status, e a apresentação do incremento destinase a motivar e obter comentários e promover a colaboração. O resultado da reunião de revisão da Sprint é um Backlog do produto revisado, que define o provável Backlog do produto para a próxima Sprint. O Backlog do produto pode também ser ajustado completamente para atender novas oportunidades 4.5. Retrospectiva da Sprint Segundo [Sutherland and Schwaber 2011], a retrospectiva da Sprint serve para que o time Scrum inspecione a si próprio e crie formas de melhorias que são aplicadas na próxima Sprint. Esta retrospectiva ocorre antes da reunião de planejamento e depois da revisão da Sprint. A Retrospectiva da Sprint consiste em inspecionar como a última Sprint foi, identificar suas melhorias e melhorar no modo que o Time Scrum faz seu trabalho. 5. Artefatos do Scrum Os artefatos do Scrum representam o trabalho ou o valor para o fornecimento de transparência e oportunidades para inspeção e adaptação. São especificamente projetados para maximizar a transparência das informações chave de modo que todos tenham o mesmo entendimento dos artefatos 5.1. Backlog do Produto O Backlog do Produto é uma lista ordenada por prioridade de tudo que deve ser necessário no produto, e é uma origem única dos requisitos para qualquer mudança a ser feita no produto, sendo de responsabilidade do Product Owner. O Product Owner deve influenciar o time, ajudando no entendimento e nas decisões, porém o time de Desenvolvimento é responsável por todas as estimativas, assim as pessoas que irão realizar o trabalho fazem a estimativa final. O Product Owner acompanha o trabalho restante pelo menos a cada reunião de revisão da Sprint, para isso, compara com trabalho que restava quando ocorreu a reunião de revisão anterior, para avaliar o progresso do trabalho previsto e finalizar no prazo previsto. Esta informação deve ser transparente para todas as partes interessadas 5.2. Backlog da Sprint O Backlog da Sprint é um conjunto de itens da Backlog do Produto selecionados para a Sprint, juntamente com o plano de entrega do incremento do produto. Ele torna mais visível o trabalho que o time de Desenvolvimento identifica como necessário para atingir o objetivo da Sprint. O Backlog da Sprint serve como um plano que contém detalhes suficientes para que as mudanças no progresso sejam entendidas durante a Reunião Diária. O time de desenvolvimento modifica o Backlog ao longo de toda a Sprint, e o Backlog vai surgindo durante a Sprint. Este surgimento ocorre quando o time de desenvolvimento trabalha segundo o plano e aprende mais sobre o trabalho necessário para alcançar o objetivo da Sprint

6 5.3. Incremento O incremento é a soma de todos os itens do Backlog do produto completados durante a Sprint e o valor dos incrementos de todas as Sprints anteriores. Ao final da Sprint um novo incremento deve estar Pronto, o que significa que deve estar na condição utilizável e atender a definição de Pronto do time Scrum, independente do Product Owner decidir por liberá-lo realmente ou não [Schwaber and Beedle 2002]. 6. Transparência do Artefato Decisões para otimizar o valor e controlar os riscos são feitos com base no estado dos artefatos. Na medida em que a transparência é plena, estas decisões tem uma base sólida. Na medida em que os artefatos não são completamente transparentes, estas decisões podem conter falhas, valores podem diminuir e riscos podem aumentar. O trabalho do Scrum Master é trabalhar com o time Scrum para aumentar a transparência dos artefatos. Este trabalho geralmente envolve aprendizagem, convencimento e mudança. Transparência não ocorre de um dia para o outro, mas é um caminho 6.1. Definição de Pronto Quando o item do Backlog do Produto ou um incremento é descrito como Pronto, todos devem entender o que o Pronto significa. Embora, isso varie significativamente para cada time Scrum, os integrantes devem ter um entendimento compartilhado do que significa o trabalho estar completo, assegurando a transparência. Esta é a Definição de Pronto para o time Scrum e é usado para assegurar quando o trabalho de incremento do produto está completo. A mesma definição orienta o time de desenvolvimento no conhecimento de quantos itens do Backlog do produto podem ser selecionados durante a reunião de planejamento da Sprint. O propósito de cada Sprint é entregar incrementos de funcionalidades potencialmente utilizáveis que aderem à definição atual de Pronto do time Scrum. O time de desenvolvimento entrega um incremento de funcionalidade do produto a cada Sprint. Este incremento é utilizável, assim o Product Owner pode escolher liberá-lo imediatamente. Se a definição de Pronto para um incremento é parte das convenções, padrões ou diretrizes de desenvolvimento da organização, todos os times Scrum devem segui-la. Se Pronto para um incremento não é uma convenção de desenvolvimento da organização, o time de desenvolvimento do time Scrum deve criar uma definição de Pronto apropriada para o produto. Se há múltiplos times Scrum trabalhando no lançamento do sistema ou produto, os times de desenvolvimento de todos os times Scrum devem mutuamente acordar uma definição de Pronto. Cada incremento é adicionado a todos os incrementos anteriores e completamente testado, garantindo que todos os incrementos funcionem juntos. Com um time Scrum maduro, é esperado que a sua definição de Pronto seja expandida para incluir critérios mais rigorosos de alta qualidade

7 7. Conclusão O Scrum é geralmente voltado ao desenvolvimento de software mas pode ser aplicado em qualquer área. É um framework simples, criado para tornar ágil a realização de projetos complexos, tal como os que necessitam de mudanças rápidas durante o desenvolvimento, e mesmo assim, proporcionando a entrega de resultados de alta qualidade. Sendo assim, dentro do gerenciamento ágil de projetos, o Scrum é um dos que mais se destaca. Existem alguns benefícios obtidos com o uso do framework scrum, tais como: Diminuição dos riscos, maior integração entre os membros das equipe, rápida solução de problemas, progresso medido continuamente, os clientes se tornam parte da equipe de desenvolvimento, entregas frequentes de funcionalidades funcionando, discussões diárias de status com a equipe, os profissionais de negócios e tecnologias trabalham juntos. Com todo esse entrosamento entre a equipe de desenvolvimento e com a participação ativa dos clientes o rendimento do projeto aumenta e os requisitos e solicitação de alteração passa a ser entendido mais rapidamente, devido ao explícito entrosamento de todos os participantes do desenvolvimento. Referências Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R. C., Mellor, S., Schwaber, K., Sutherland, J., and Thomas, D. (2001). Manifesto for agile software development. Acessado em: 22 maio de Neto, C. (2012). Conhecendo o scrum. Acessado em: 26 maio de Schwaber, K. and Beedle, M. (2002). Agile software development with scrum. Prentice Hall, 1th edition. Sommerville, I. (2006). Engenharia de Software. Pearson, 8th edition. Sutherland, J. and Schwaber, K. (2011). The scrum guide. Retrieved from