Preço De Um Projeto De Scrum

Metodologia Scrum, o que são histórias e como elas influenciam o preço do projeto

Como explicado no artigo anterior, Scrum é uma metodologia ágil usualmente utilizada em projetos da área de Tecnologia da Informação, como aplicativos e banco de dados. Mas então, vamos entender melhor o que são essas histórias.

Mas bem, já conhecemos a Metodologia Scrum, agora, para entendê-la melhor, é importante saber o que são Histórias.

As histórias são componentes do Product Backlog que representam parte do sistema a ser criado. As Histórias devem descrever detalhadamente o que será implementado.

Product Backlog – Lista de Histórias, que devem ser implementados para a o desenvolvimento do projeto.

Ficou confuso? Veja bem, Histórias nada mais são do que minuciosas funcionalidades que o sistema ou software terão, e o Product Backlog é o conjunto de todas as Histórias do projeto.

As Histórias possuem um certo padrão de escrita, para que o programador entenda exatamente o que deve ser desenvolvido. Na Fluxo, nós utilizamos o determinado padrão:

Eu, como usuário comum, gostaria de que tal coisa seja feita, para que tal coisa aconteça. ”

Por exemplo, imagina que você deseja uma página de login no seu aplicativo, a história dessa funcionalidade seria mais ou menos assim:

Eu, como usuário não logado, gostaria de visualizar uma tela de login com os campos ‘Usuário’, ‘Senha’ e um botão ‘Entrar’, para que eu possa acessar o aplicativo. ”

Desse modo, o programador sabe que ele precisa criar uma página de login, para o usuário não logado, que contenha campos de usuário e senha, e que após digitar tais informações, o usuário deverá acessar o aplicativo.

Okay! Mas quem define as Histórias? Elas são definidas em uma reunião entre o Scrum Master, que é o gerente do projeto, e o Product Owner (PO), que pode ser o cliente ou pessoa responsável pelo acompanhamento do projeto. Nessa reunião o PO dirá todas as funcionalidades que ele deseja que tenha no software, e o Scrum Master as transformará em Histórias, o Scrum Master também adicionará funcionalidades que achar pertinentes e que o PO não havia pensado. Uma História pode descrever desde a alteração de um label na tela até a criação de uma nova funcionalidade do sistema. O importante é verificar se o que deve ser implementado ao realizar aquela História foi realmente compreendido pela equipe de desenvolvimento.

É possível que em algumas Histórias a equipe observe a necessidade de repartir o trabalho previsto para que se tenha maior controle do que deve ser feito. Não existe problemas nisso, pelo contrário isso deve ser feito para que o projeto seja entregue da melhor forma possível e no prazo, satisfazendo as expectativas do cliente. E isso deverá acontecer durante as reuniões, a equipe pode e precisa sugerir ao PO que determinada História seja dividida em outras ou tenha sua descrição alterada.

A função da equipe não é apenas desenvolver a funcionalidade desejada, mas também encontrar, junto com o PO, a melhor maneira de finalizar as Histórias definidas.

Todas as Histórias levantadas pelo PO compõem o Product Backlog. Nele estão listadas todas as necessidades já identificadas para o projeto, ordenadas por prioridade pelo PO. É importante a ressalva de que o Product Backlog nunca é definitivo, ele deve ser atualizado na medida que o desenvolvimento do projeto vai progredindo e novas necessidades são encontradas ou certas funcionalidades não são mais necessárias. A cada iteração do projeto, é possível que novas Histórias sejam adicionadas ao Product Backlog e novas prioridades sejam estabelecidas, ou velhas funcionalidades deixem de fazer parte do mesmo.

Mas e aí, o que acontece depois que eu priorizei as Histórias?

Como foi dito logo acima, as histórias são ordenadas em nível de prioridade, além disso, a elas também são atribuídos pontos.

Como assim pontos?

Cada história tem pontos atrelados a ela, que é o nível de dificuldade ou complexidade daquela funcionalidade. Por exemplo, uma funcionalidade de fazer pagamento em um aplicativo é bem mais dificílima e demorada de se programar do que uma de fazer login, logo, ela tem uma pontuação maior que a outra.

Como funciona a pontuação?

A pontuação é feita utilizando a sequência de Fibonacci, que diz que o número seguinte da sequência é a soma dos dois anteriores, por exemplo: 1, 2, 3, 5, 8, 13, 21, …

Na Fluxo nós pegamos a história, de menor complexidade e mais fácil de se programar, do Product Backlog, e atribuímos a ela a pontuação 2, e a partir daí nós vamos pontuando as outras sempre fazendo comparação com ela, por exemplo, se uma história tem igual complexidade e tempo de desenvolvimento a sua pontuação também será 2, mas se ela é um pouco mais complexa ou demora mais para ser feita a sua pontuação será 3 ou 5, entretanto, se a história for bem mais complexa, ela terá pontuação 8, 13 ou até 21. Se uma funcionalidade necessitar de uma pontuação maior que 21, ela deve ser reavaliada, pois com certeza ela pode ser dividida em outras histórias menores.

E por que dividir uma história grande em outras menores?

Porque o objetivo do Scrum é entregar de maneira mais rápida algo minimamente funcional para o cliente, se uma História for muito grande, o cliente terá que esperar muito para receber uma única funcionalidade. Uma das melhores coisas de utilizarmos o Scrum para desenvolvermos, é que temos sempre entregas parciais, na qual o cliente pode testar e mudar o produto, seja ele um Sistema Web ou aplicativo, mesmo antes de ter tudo integrado, dessa forma podemos encontrar erros em pequenas partes, que poderiam passar despercebidos se houvesse somente uma entrega final com tudo pronto.

Me dê um exemplo de Histórias de pontuação alta que são complexas.

Imagina que você quer saber a localização do usuário do seu aplicativo, isso é relativamente fácil, basta pegar os dados do GPS, mas agora imagina que além de saber a localização você quer projetá-la em um mapa e calcular o tempo estimado que o usuário irá demorar para chegar em um determinado local, levando em consideração o trânsito real da cidade, ou até mesmo calcular a melhor rota (Waze, Google Maps), isso seria bem mais complicado e demorado de se fazer, mesmo que a história em geral seja sobre GPS e medir a distância. Viu só, a primeira funcionalidade é muito simples, mas a segunda terá que ser destrinchada em várias outras, uma para a localização, outra para o tempo estimado, outra para o trânsito, outra para o tempo estimado e mais uma para a dizer qual a melhor rota.

Beleza! Agora já sabemos o que são as Histórias na metodologia Scrum e que elas são priorizadas e pontuadas, mas como isso influencia no preço e prazo do meu projeto?

Bem, quando já temos o Product Backlog definido, nós fazemos a reunião de Sprint Planning, que é feita com o Scrum Master, Product Owner e a equipe de desenvolvimento. Nessa reunião será definida a Sprint Backlog, que são todas as Histórias que serão desenvolvidas na Sprint.

Espera aí, você não sabe o que é Sprint?

Se você não leu o nosso artigo que explica tudo sobre o Scrum, aqui vai uma colinha:

Sprint – É um período de tempo de desenvolvimento, no qual o programador irá realizar as histórias escolhidas pelo Product Owner.

Ainda está complicado? Pensa assim, imagina a tarefa de aprender a fazer um bolo, na primeira Sprint você faz um cupcake, que é simples, mas aí você vê que não era isso que queria, então você o melhora e transforma em um bolo comum, entretanto você ainda não está satisfeito e na última Sprint você decide transformá-lo em um bolo de casamento.

sacrum-cake

O projeto todo é dividido em Sprints. Na Fluxo, uma Sprint tem duração de duas semanas, 10 dias úteis, mas isso pode variar de um projeto para outro

E como é definido as histórias que serão desenvolvidas na Sprint?

Então, em geral são escolhidas as histórias mais prioritárias, que sigam uma linearidade, e que geralmente a soma dos pontos de cada uma dê algo por volta de 21 pontos.

Em suma, a quantidade da soma dos pontos de todas as Histórias do Product Backlog, dividido por 21 vai dar a quantidade aproximada de Sprints necessárias para o desenvolvimento do projeto, com isso podemos estimar o Prazo e Preço do projeto.

Recapitulando

Para a realização de um projeto em Scrum seguimos tais passos:

  1. Definimos todas as funcionalidades do produto;
  2. Transformamos as funcionalidades em Histórias;
  • Priorizamos e pontuamos as Histórias, considerando importância e complexidade;
  1. Definimos quais Histórias serão feitas em cada Sprint;
  2. Reavaliamos, adicionamos e retiramos Histórias do Product Backlog;
  3. Entregamos o que foi desenvolvido em cada Sprint para o cliente testar;
  • Corrigimos os erros e revalidamos;
  • Entregamos o projeto de acordo com as expectativas do cliente, ou até mesmo as superando.

Foi um prazer trabalhar com você!

Algumas observações:

O cliente contrata a Fluxo por tempo de desenvolvimento, logo, se ele quiser adicionar mais funcionalidade ao projeto ele pode, porém isso acarretará a adição de mais Sprints e consequentemente um aumento no preço do projeto.

O cliente paga a Fluxo por Sprint, entretanto Sprints de itens diferentes podem ter preços variados. Por exemplo, uma Sprint de um aplicativo Android tem um valor distinto da de um Sistema Web, Banco de dados, ou até mesmo da de um aplicativo iOS.

Para mais informações, leia os artigos do nosso blog. Gostou do texto? Deixe a sua mensagem nos comentários e continue nos acompanhando, pois sempre temos novas postagens sobre diversos assuntos.

Carlos Serra Menezes

Graduando em Engenharia Elétrica na Universidade Federal do Rio de Janeiro, Gerente de Projetos e Assessor de Marketing na Fluxo Consultoria. Já gerenciou projetos Banco de Dados, Sistema Web e Aplicativos, na metodologia SCRUM. Responsável pelo Site da Fluxo Consultoria, Marketing Digital e a área de Divulgação da Empresa.

This Post Has 2 Comments

Deixe uma resposta

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