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, unidade de tempo que permite a entrega contínua de valor para o cliente. Por esse motivo, decidi elaborar um artigo pragmático, dispensando pontos teóricos e focando na praticidade de uma Sprint.
Quando utilizamos a frase “entrega contínua de valor para o cliente”, nos referimos à entrega de 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. 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, significa 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.
PARA FACILITAR, VOU APRESENTAR 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. Após 2 anos, conforme negociado, o software finalmente é desenvolvido e entregue ao restaurante. Eis que, ao começar a utilizar o software, o cliente entra em contato e reporta as seguintes reclamações:
“Há funcionalidades demais no software. Não pedi nada disso!”
“Onde estão as telas e relatórios que solicitei no dia da negociação?”
“A interface gráfica é muito complicada. Ninguém está conseguindo se adaptar!”
A empresa, então, provavelmente irá alocar a equipe de desenvolvimento para ajustar as correções no software. Mas, 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 que, mesmo após as correções, o software de fato ficará perfeitamente da forma como o cliente solicitou?
Não seria melhor se o cliente acompanhasse a evolução do software, provendo feedbacks para a equipe?
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. 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 sucessivamente. Ao final de 10 Sprints, teremos o software completamente desenvolvido.
CERTO, MAS QUAL É O BENEFÍCIO EM FAZER ENTREGAS CONTÍNUAS?
Pois bem, considerando o mesmo exemplo do restaurante, no final de cada mês o cliente terá uma pequena versão do software que já poderá ser utilizada, trazendo algumas vantagens no processo de desenvolvimento.
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 entregue ao 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, defeitos e inconformidades. Isso evita que uma falha de especificação seja identificada pelo cliente somente após 2 anos.
Em terceiro lugar, a manutenção do software. Através do feedback, é possível corrigir os bugs imediatamente na próxima Sprint, de modo 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 pronto, incorrendo em uma manutenção muito mais complexa.
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, me desculpo pelo artigo ter ficado tão extenso.
Obrigado pela atenção!
ANDRÉ LUIS CELESTINO
Mais artigos deste autor »
Desenvolvedor de software há 7 anos e autor do blog AndreCelestino.com. Graduado em Sistemas de Informação e pós-graduado em Engenharia e Arquitetura de Software com ênfase em Desenvolvimento Ágil. Atualmente trabalha como Analista Implementador Delphi em Florianópolis.
Nenhum comentário:
Postar um comentário