Scrum: A eficiência de uma Sprint

AGRADEÇA AO AUTOR COMPARTILHE!

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.

metodologia-scrum-gestao-projetos

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!

Publicado originalmente no blog SubRotina

AGRADEÇA AO AUTOR COMPARTILHE!

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.


17 Comentários

Diogo Leite Mesquita
3

“O coração do Scrum é a Sprint, um time-boxed de um mês ou menos”
“Cada Sprint pode ser considerada um projeto com horizonte não maior que um mês.”
“Sprints são limitadas a um mês corrido.”
fonte: Scrum Guide

André Luis Celestino Autor do Post
4

Olá, Diogo.

Agradeço o seu comentário, mas sou da opinião de que o Scrum é um framework, e não um padrão de gerenciamento imutável. Trabalho em uma empresa que definiu Sprints de 60 dias (2 meses) e os resultados sempre foram satisfatórios. O fato de não termos Sprints de 30 dias não significa que estamos fugindo das diretrizes do Scrum ou falhando em utilizá-la, do mesmo modo que, se o Scrum Guide diz que Daily Scrums devem ser 15 minutos e uma empresa ocupar 20, não significa que as reuniões estão incorretas.

O Scrum Guide é um ótimo guia, mas segui-lo à risca pode não ser adequado para o ambiente de desenvolvimento de uma empresa.

Diogo Leite Mesquita
5

Olá Andre,

Concordo que as empresas dificilmente utilizam o Scrum à risca, no mercado usam o termo “Scrumbut” para se referir a essa não adequação fechada ao guia, se ajustando assim, à realidade de desenvolvimento da empresa. Não tenho grande experiencia prática com Scrum, mas pude me certificar na área(PSM I) recentemente, e a maior referência para a prova é o scrum guide, escrito por Ken Schwaber e Jeff Sutherland (www.scrum.org/Scrum-Guide) fundadores do framework. No documento são categóricos ao dizer: “Papéis, artefatos, eventos e regras do Scrum são imutáveis e embora seja possível implementar somente partes do Scrum, o resultado não é Scrum”. Peço desculpa por ser chato nesse ponto, tendo em vista que você elaborou “um artigo pragmático, dispensando pontos teóricos e focando na praticidade de uma Sprint.” e agradeço pelo enriquecimento de sua experiencia prática, mas para a prova de certificação se a sprint for maior que 30 dias(1 mês), então não é Scrum.

André Luis Celestino Autor do Post
6

Olá, Diogo!
Você não está sendo chato, pelo contrário, eu lhe agradeço por complementar informações ao artigo!
Exatamente, Diogo, o artigo foi elaborado com base na realidade do emprego do Scrum em algumas empresas. Seria ideal se todas as empresas ágeis determinassem um time-box de 30 dias conforme define o Scrum Guide, porém, é comum encontrar casos de equipes que ajustam, ou melhor, “modelam” o framework para se adequar à regra de negócio do cliente, flexibilidade na Sprint Backlog, acordos contratuais ou até mesmo pela disponibilidade do cliente em realizar a homologação.
Concordo em dizer que essa modelagem customizada foge do Scrum literal. Além disso, não conhecia o termo “Scrumbut”. Vou ler a respeito!

Abraço!

Daiane
7

Ótimo artigo. Parabéns! Trabalho com o Scrum há um ano e meio. Gostei tanto da metodologia, que utilizo até para organização de projetos pessoais. Realmente o scrum é uma ótima ferramenta. O que mais aprecio é o contato periódico com o cliente, que nos passa um feedback, e quanto antes melhor. Trabalho no desenvolvimento de um site de notícias, criamos novas funcionalidades a cada sprint.

André Luis Celestino Autor do Post
9

Olá, Daiane!

Legal! Ainda não tinha pensado na possibilidade de empregar o Scrum em projetos pessoais. Me parece ser uma boa ideia!
O feedback realmente é um dos grandes destaques do Desenvolvimento Ágil. Trabalhar com um feedback constante é sinônimo de qualidade!

Rudnei Lucas
10

Olá,

lendo sobre a discussão do Diogo e do André, acho que o posicionamento do André é a mais aceitável no mercado. Quando o Diogo citou: “Papéis, artefatos, eventos e regras do Scrum são imutáveis e embora seja possível implementar somente partes do Scrum, o resultado não é Scrum”, ele está correto, mas a duração de Sprint não implica em quebrar nenhum dos termos. Trabalho em uma equipe onde o Sprint é de 2 semanas, já tentamos várias opções e a que mais se adequou com a velocidade do time vs valor para o cliente foi o de 2 semanas.

Diamar
12

Excelente texto, para o meu caso, estou entrando agora numa empresa de desenvolvimento para dar suporte ao produto e estou louca com tantos artigos técnicos, rs. Melhor explicação, impossível!
Obrigada André.

André Luis Celestino Autor do Post
13

Olá, Diamar!
Agradeço pelo feedback sobre o artigo e desejo boa sorte na sua nova empreitada. Continue acompanhando os artigos aqui do PTI. O conteúdo é bastante útil!
Obrigado!

Adriano Rodrigues
14

´O artigo esta muito bom. É sempre ótimo ver uma explicação pratica depois de ler algo mais técnico.
Eu sou estudante, ainda não trabalho, minha duvida é: Estar trabalhando com a instalação de uma parte todo mês e solicitando um Feedback todo mês para o cliente não pode ser um pouco cansativo? Isso pode aumentar os custos do projeto ou minimizar custos na manutenção?

André Luis Celestino Autor do Post
15

Olá, Adriano, tudo bem?

Pelo contrário! O feedback constante do cliente reduzirá os riscos na implementação das funcionalidades, já que ele estará testando-as de modo incremental. Qualquer erro, inconsistência ou não-conformidade da regra de negócio será imediatamente avaliada e corrigida na próxima Sprint, ao invés de esperar o sistema todo ficar completo, como acontece no Waterfall.
Além disso, este feedback mantém o cliente mais próximo do produto final. Dessa forma, as melhorias e esclarecimentos sobre as funcionalidades do software poderão ser relativamente pontuais, aprimorando a qualidade do produto.

Obrigado pelo comentário! Abraço!

Fernando RegoFernando Rego
16

Muito bom artigo. Há anos conheci Extreme Programming e me apeguei aos conceitos de entrega por etapas. Lembro que, além de gerar valor ao cliente, a entrega por etapas nos retorna um valioso recurso: o teste. O próprio cliente/usuário se torna tester da ferramenta negociada. Qualquer reparo fica mais barato, se verificado no início. Parabéns!

André Luis Celestino Autor do Post
17

Olá, Fernando!

Ótimo comentário! Um dos pilares do eXtreme Programming é o feedback constante do cliente, possibilitando a correção antecipada de erros no software e evitando a “bola de neve”. Além disso, como você mencionou, quanto antes o erro for encontrado, mais rápido será avaliado.
O XP também recomenda o TDD (Test-Driven Development), visando a cobertura de testes unitários no código para garantir a implementação de funcionalidades com um menor índice de erros.

Obrigado, Fernando!

Deixe seu comentário

Seu endereço de e-mail não será publicado. Campos com * são obrigatórios!

Você pode usar estas tags e atributos de HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">