Quando o Scrum surgiu no cenário de desenvolvimento de software, seus conceitos, papéis e artefatos se tornaram importantes para os profissionais ágeis. Logo, o Desenvolvimento Ágil ganhou uma aceitação notável e passou a ser amplamente utilizada na gestão das empresas.
Um dos fatores que levam as empresas a implantar o Scrum é o conceito de Sprints, artefato que permite a entrega contínua de valor para o cliente. Durante o ano, participei de algumas discussões que questionavam a importância e a aplicabilidade das Sprints em um projeto. Por esse motivo, decidi elaborar um artigo pragmático, dispensando pontos teóricos e focando na praticidade de uma Sprint. Confira!
Introdução
Quando utilizamos a frase “entrega contínua de valor para o cliente”, nos referimos à entrega do produto de software, ou seja, um sistema de informação que servirá como apoio para que o cliente possa aprimorar os seus negócios, visando uma maior lucratividade. Pensando dessa forma, podemos afirmar que o software está diretamente ligado aos objetivos de negócio do cliente e na forma como a empresa conduz suas atividades. Sendo assim, se o software é tão importante para a continuidade do negócio, é imprescindível que ele esteja sempre disponível e atualizado.
No mundo ágil, uma Sprint responde exatamente ao cenário acima. Em poucas palavras, uma Sprint é uma unidade temporal (também chamada de ciclo de desenvolvimento ou Time Box) que permite a implementação de um conjunto parcial de funcionalidades definido pelo próprio cliente. Por ser parcial, observe que não é um software completamente pronto, mas uma parte funcional dele. As Sprints possibilitam que a equipe trabalhe dentro de um prazo fixo para a implementação de um número definido de funcionalidades que, por sua vez, podem ser classificadas por prioridade.
Um breve exemplo
Suponha que uma empresa de software utilize o Desenvolvimento em Cascata (Waterfall) e esteja desenvolvendo um software para um restaurante. Durante a negociação, a empresa estipula um prazo de 2 anos para que o software fique completamente pronto e funcional. No dia seguinte, os desenvolvedores já começam a trabalhar na solução e, após 2 anos, o software finalmente é desenvolvido e entregue ao dono do restaurante. Eis que, ao começar a utilizar o software, o cliente liga pra empresa e reporta as seguintes reclamações:
“Há funcionalidades demais no software. Não pedi tudo isso!”
“Onde estão as funcionalidades que solicitei no dia da negociação?”
“A interface gráfica é muito complicada. Ninguém está conseguindo se adaptar!”
E então, vai refazer todo o software?
Claro que não. Vou pedir para a equipe de desenvolvimento ajustar as correções no software!
Opa, prevejo problemas aí! O software mal começou a ser utilizado e já vai passar por uma fase de manutenção? Além disso, significa que o prazo de 2 anos será quebrado, já que a equipe vai levar mais alguns meses para fazer as correções. E mais, quem garante, mesmo após as correções, o software de fato ficará perfeitamente da forma como o cliente solicitou?
Meu amigo, não seria melhor se o cliente acompanhasse a evolução do software, provendo feedbacks para a equipe?
Agora sim podemos colocar a Sprint na história.
Sprint em ação
Agora, vamos supor que a empresa de software esteja utilizando o Scrum. Na fase de negociação e levantamento de requisitos surge uma lista chamada Product Backlog, que representa todas as funcionalidades que deverão ser implementadas no software, do começo ao fim. Porém, como se trata de tudo que o software deverá fazer, é uma lista de implementações bastante extensa e provavelmente levará meses ou anos para conclusão. Neste caso, seria viável dividir essas implementações em prazos menores, selecionando um conjunto parcial das funcionalidades do Product Backlog.
Esse prazo menor é o que chamamos de Sprint e esse conjunto parcial é definido como Sprint Backlog.
Na prática, se um Product Backlog contém 100 funcionalidades para serem desenvolvidas, podemos selecionar 10 delas para a nossa Sprint Backlog, de modo que sejam implementadas nos primeiros 30 dias. As próximas 10 funcionalidades seriam implementadas na 2ª Sprint e assim por diante. Ao final de 10 Sprints, teremos o software completamente desenvolvido.
Quem seleciona essas funcionalidades? Os desenvolvedores?
Não. O cliente! Essas funcionalidades geralmente são organizadas por prioridade ou de acordo com uma sequência de desenvolvimento definida na negociação. Para discutir o esforço, restrições e recursos da lista de funcionalidades em uma Sprint, a equipe participa de uma reunião conhecida como Sprint Planning, que consiste no planejamento dos próximos itens a serem implementados.
Algumas vezes, o acesso ao cliente é crítico (normalmente por causa da distância ou indisponibilidade), impossibilitando o contato constante com a equipe. Neste caso, as decisões passam a ser tomadas pelo Product Owner, papel no Scrum que representa o cliente dentro da empresa.
Benefício de entregas contínuas
Pois bem, continuando, considere que a empresa negociou um prazo de 30 dias para cada entrega do software do restaurante. No final de cada mês, o cliente terá uma pequena versão do software que já poderá ser testada e utilizada. Bom, acredito que neste ponto do artigo já podemos destacar uma série de vantagens, não é?
Em primeiro lugar, ao invés de esperar 2 anos pelo produto pronto, o cliente poderá utilizá-lo a cada mês, mesmo que não esteja totalmente desenvolvido. Por exemplo, no final do 1º mês teríamos o cadastro de clientes desenvolvido e pronto para ser utilizado pelo usuário. Embora o módulo de pedidos, financeiro, caixa e estoque não estejam prontos, os clientes já poderão ser cadastrados no banco de dados.
Em segundo lugar, o feedback. Já que o produto é entregue de forma contínua, o cliente acompanha o desenvolvimento, sugerindo melhorias e reportando erros, falhas e defeitos. É um sistema de feedback eficiente. Isso evita que uma falha de especificação seja identificada pelo cliente somente após 2 anos. Os valores de colaboração e comunicação do Desenvolvimento Ágil respondem exatamente à essa vantagem.
Em terceiro lugar, a manutenção do software. Através do feedback, é possível corrigir os bugs imediatamente na próxima Sprint, de forma que elas possam ser testadas novamente no próximo incremento. Ao realizar manutenções constantes, a equipe evita o risco de refazer uma funcionalidade que influencia todo o software após um prazo extenso, incorrendo em uma manutenção muito mais demorada.
Em muitas literaturas sobre Scrum, geralmente os autores dizem que o produto de software gerado no fim de uma Sprint é considerado “potencialmente utilizável”. Esse adjetivo é empregado para definir que o software entregue ao cliente em cada ciclo de desenvolvimento (Sprint) já pode ser utilizado em produção, ou seja, não é uma versão apenas para testes.
Qual é o melhor ciclo de entrega?
Uma Sprint normalmente tem um prazo fixo de entrega que pode variar entre 2 a 6 semanas, porém, a delimitação deste tempo é muito relativa. A empresa deve considerar a quantidade de recursos no desenvolvimento, as tecnologias e a regra de negócio, bem como a própria negociação com o cliente. Já presenciei casos de Sprints com 60 e 75 dias que, apesar de bastante longa, era o ideal para o desenvolvimento do projeto em questão.
Leitores, o artigo ficou um pouco extenso, mas ainda não falei tudo o que queria sobre Sprints.
Assim que possível, pretendo publicar mais um artigo sobre este assunto.
Obrigado pela visita! Abraço!