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!
Publicado originalmente no blog SubRotina
17 Comentários
Olá André, parabéns pelo artigo. A analogia do waterfall versus scrum foi ótima.
Olá, Aloisio! Muito obrigado pelo feedback! Grande abraço!
“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
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.
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.
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!
Ó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.
Complementando a discussão o sprint na empresa que eu trabalho dura 15 a 13 dias.
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!
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.
Muito bom!!!!
Parabéns.
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é.
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!
´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?
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!
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!
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!