Quem patrocina o projeto quer saber o quanto ele custará e quando será entregue.
Este capítulo ficou para o final da Parte II justamente porque ele é o que trata do tema mais complexo no mundo Scrum: como estimar o tempo, esforço e investimento em uma metodologia que, dentre outras coisas, deve estar aberta às mudanças que ocorrem nos requisitos e no ambiente de desenvolvimento?
Quem contrata um projeto quer ter a certeza do quanto terá de pagar e quando terá o produto entregue. Por outro lado, como já falamos no Capítulo 5, “Construindo o Product Backlog”, ninguém mais aguenta o grande e mentiroso contrato que promete mundos e fundos, apresenta uma estimativa detalhada de investimentos e erra feio em seu cronograma e em suas entregas.
Há, na estimativa de desenvolvimento de qualquer coisa, o paradigma do triângulo de ferro, cujos lados são representados pelo custo, pela qualidade e pelo tempo. Mexer em qualquer lado do triângulo implica mexer nos demais. Quem nunca ouviu algo do tipo “podemos reduzir o investimento necessário para o projeto, mas aí teremos de reduzir o seu escopo”? No Scrum, o que se busca é atingir um desenvolvimento hiperprodutivo em que o triângulo de ferro esteja fora de questão. O paradigma é outro e, por isso, as estimativas não podem ser feitas de maneira clássica.
O mesmo Poker do Planejamento que já usamos, como um exemplo, na priorização de histórias no Product Backlog é usado, agora, para estimar o esforço necessário para o seu desenvolvimento. Todos os membros da equipe, com exceção do Scrummaster e do Product Owner, recebem as cartas do Poker do Planejamento e percorrem cada uma das histórias do Product Backlog representado na Tabela 6.1 e já adequado na Tabela 6.2.
O Scrummaster distribui a todos as cartas do Poker do Planejamento (cada uma com os números 0, ½, 1, 2, 3, 5, 8, 13, 21, 0, e mais os ícones de ?, infinito e cafezinho) e pede que a equipe escolha uma história considerada, em consenso, de dificuldade média. Imagine que a equipe, após ponderar as histórias do Product Backlog, considerou a história identificada pelo número 7 como de dificuldade média. A essa história são atribuídos, então, cinco pontos (Tabela 8.1).
Tabela 8.1 – História média base
| ID | História | Pontos |
| 7 | Como Giftwizz, em intervalos predeterminados, quero perguntar aos usuários qual presente recomendariam, a partir de uma lista, a um de seus amigos nas redes sociais. | 5 |
A partir daí, as demais histórias serão pontuadas tomando essa como base. A imediatamente mais fácil receberá três pontos, a imediatamente mais difícil, oito pontos, e assim por diante. Histórias que receberem o valor infinito devem ser consideradas épicos, e, desta forma, subdivididas em outras histórias. Há de se ter alguns cuidados aqui, no sentido de descobrir onde são colocados os limites de detalhamento de itens dos backlogs, das atividades e tarefas. Não se deve burocratizar demais o processo, mas não se deve também deixar que faltem informações àqueles que desenvolverão o projeto. Métodos ágeis requerem que o cliente esteja sempre disponível e presente e, mais adiante, abordaremos o Product Backlog Refinement (as reuniões de ajustes e refinamentos do Product Backlog, das quais a equipe de desenvolvimento, Product Owner, Scrummaster e, eventualmente, vários outros porcos e galinhas podem fazer parte). Por enquanto, deve ser suficiente assumir que os itens do Product Backlog representam exclusivamente aquilo que tem valor de negócio para os patrocinadores, os clientes e o Product Owner que os representa. Esses itens ganham em detalhamento à medida que se aproximam da entrada no Sprint Backlog e, depois, quando são decompostos em tarefas a serem executadas dentro do Sprint.
Uma vez escolhida a história base, o Product Owner lê cada uma das demais histórias e o Scrummaster dá um minuto para que todos pensem um pouco sobre sua execução e estimem seu esforço com o Poker do Planejamento. As regras do jogo não mudam muito com relação ao que você viu quanto à priorização das histórias. A carta de valor zero deve ser usada para histórias que não requerem esforço algum (nem mesmo para a sua integração com algo que já existe), como um código conhecido, testado e perfeitamente integrável. A carta de valor infinito é para épicos que devem ser decompostos. A que tem a interrogação deve ser usada por aqueles que não se sentem capazes de estimar a história e a do cafezinho é a pausa para pensar mais um pouco. Todos os números no meio são a representação arbitrária do sentimento das pessoas quanto ao esforço necessário para a realização das histórias.
Agora, sim, você entendeu por que este capítulo sobre estimativas ficou para o final da Parte II deste livro. Eu precisava manter o seu entusiasmo até aqui para poder falar de representações arbitrárias de sentimentos na estimativa de esforços para a realização de histórias. Mas pense bem… O quão não arbitrárias são quaisquer outras estimativas?
Você não consegue ter pessoas uniformes, com o mesmo nível de compreensão do que deve ser feito e nem com o mesmo domínio de todas as ferramentas necessárias à execução de qualquer projeto. Antes disso, você já entendeu plenamente que não terá o domínio total dos requisitos até que comece a ver alguma entrega do projeto com a qual você possa começar a experimentar. E, dependendo da duração de seu projeto, uma nova tecnologia pode surgir a ponto de mudar muitos dos conceitos iniciais sobre o que você queria. Ou seja, todas as estimativas são, quando muito, chutes mais ou menos calibrados. Além disso, quando estamos em um ambiente competitivo de prestação de serviços de desenvolvimento de qualquer coisa, a estimativa final sempre será aquela do concorrente que ofereceu o menor preço para a entrega do produto no menor tempo possível, dentro de um contrato de qualidade de serviço tido como aceitável pelo cliente – o que quer dizer que, em várias ocasiões, por mais que você queira fazer uma estimativa séria, para ganhar um trabalho você terá de se adequar a estimativas alheias.
Assim, se você não está plenamente satisfeito em estimar o esforço de um projeto usando a sequência de Fibonacci do Poker do Planejamento, sinta-se à vontade para usar outras formas de estimar a complexidade de uma história, como tamanhos de camiseta (pequena, média, grande, extragrande…), número de biscoitos de chocolate que você conseguiria comer durante a realização da história, tamanho de animais em um zoológico ou até mesmo horas (Argh!!!) – acredite, todos esses métodos são usados em estimativas de projetos ágeis!
A verdade é que humanos são péssimos em estabelecer valores absolutos para as coisas, mas ótimos no estabelecimento de valores relativos. Quando duas pessoas entram em uma sala, os que já estão dentro dela dificilmente serão capazes de adivinhar sua altura e peso, mas facilmente dirão quem pesa mais e quem é mais alto. Por isso, métodos comparativos, empíricos, para estimativas, ao valerem-se de nossa natureza humana, são mais eficazes.
Quanto a horas, considere a não uniformidade das pessoas. Eu trabalho com tecnologia da informação há tempo suficiente para ter presenciado programadores experientes, com um grande repertório de sistemas desenvolvidos, passarem horas no desenvolvimento de uma solução que, afinal, surgiu da “inspiração” momentânea de um novato, ou mesmo de alguém que, sem conhecer nada de programação, saiu-se com um palpite certeiro pelo puro desconhecimento de limites imaginários com os quais os programadores trabalhavam. Aliás, essa é uma das razões pelas quais times heterogêneos são, sempre, muito saudáveis. No final, porém, independentemente de qualquer coisa, o que você terá são pessoas e as horas que elas dedicam ao projeto, mas adianto-me! Siga comigo nesse exercício de estimativa com o Poker do Planejamento.
O Scrummaster pede que todos os participantes mostrem suas cartas um minuto depois que o Product Owner leu a descrição desta história (ID 5):
Como usuário, no momento de meu cadastro no sistema, quero optar por permitir (ou não) o acesso a meus dados em redes sociais (dados pessoais, lista de amigos, likes, posts), para gerar estatísticas que permitam que eu receba boas sugestões de presentes para meus amigos.
Os resultados são os exibidos na Tabela 8.2:
Tabela 8.2 – Cartas do poker escolhidas pela equipe
| Pessoa | Carta do poker |
| Pedro | 8 |
| Maria | infinito |
| Cláudia | 8 |
| João | 13 |
| Paulo | 3 |
São evidentes as jogadas (estimativas) extremas de Maria e Paulo. Assim, o Scrummaster pergunta a eles a razão de suas escolhas.
Maria
Esta história é, para mim, um épico. O cadastro e a autorização para o acesso aos dados do usuário devem ser consideradas histórias distintas. Além disso, não conheço a API da rede social e será necessária uma pesquisa ou capacitação da equipe nessa tecnologia.
Paulo
Pontuei esta história apenas com três pontos, pois já trabalhei com a API da rede social e ela é relativamente simples. Além disso, o ambiente de desenvolvimento que utilizaremos já tem métodos prontos tanto para o login do usuário quanto para solicitar a sua autorização. Já usei essa técnica em outros sistemas que desenvolvi e posso explicar, rapidamente, para a equipe como isso é feito.
Em uma breve discussão, todos concordam em usar o plano de Paulo como base, mas como ele ainda não é de pleno conhecimento de todos, em uma nova rodada, os resultados são os da Tabela 8.3:
Tabela 8.3 – Nova escolha e cartas pela equipe
| Pessoa | Carta do poker |
| Pedro | 8 |
| Maria | 8 |
| Cláudia | 8 |
| João | 5 |
| Paulo | 5 |
Agora, com resultados mais uniformes, você tem algumas opções:
1. Continuar incentivando a discussão até que se chegue a um consenso.
2. Fazer uma média dos valores, já que eles estão próximos uns dos outros.
3. Já que os valores estão suficientemente próximos, assumir o maior (a minha escolha pessoal).
Ou seja, em meu caso, o número de pontos para essa história (Story Points) seria 8.
Esse exercício é repetido para todas as histórias do Product Backlog e validado para as histórias que entram em cada um dos Sprints (e a cada refinamento do Product Backlog, mas não se preocupe com isso agora). Se eu preciso, entretanto, entregar um projeto em três meses, do que adianta ficar contando Story Points se o que eu tenho mesmo, nas mãos, são horas disponíveis de pessoas? Uma das razões para isso é que, com esse exercício, você vai ajustando suas estimativas. Após alguns Sprints, você descobrirá, por exemplo, que em um Sprint de uma semana consegue entregar 20 Story Points com um time de quatro pessoas e que, à medida que a prática com o Scrum aumenta, o número de Story Points por Sprint aumenta até atingir um valor máximo para a sua característica de produtividade. Sua capacidade de estimar melhora (a equipe chega a um consenso mais fácil quanto ao número de Story Points por história), sendo mais certeira e realista.
Você chegará a um ponto em que saberá facilmente quantos Story Points pode assumir por Sprint, descobrindo o número de Sprints necessários à entrega final de um projeto. Você também observará como a velocidade (o número de Story Points por Sprint) aumenta e quais os fatores que contribuem para esse aumento. Por exemplo, ficará muito claro o quanto vale a pena capacitar sua equipe (e todos da empresa) em Scrum, assim como incentivar e patrocinar a participação de todos em bons eventos de tecnologia.
Agora, se estimativas são arbitrárias, o que uma pessoa desenvolve em uma hora é diferente do que outra pessoa desenvolve, e uma faísca de criatividade pode acelerar de maneira imprevista o desenvolvimento de um produto ou projeto, qual é o preço que eu coloco nisso?
Este é aquele ponto, cara leitora ou caro leitor, em que eu poderia dizer que este livro não aborda questões de composição de preço, focando-se apenas na prática do Scrum como processo de desenvolvimento, e recomendar outras fontes sobre o tema. No entanto, como você chegou até aqui e eu quero muito que você me acompanhe até o final do livro, não fugirei desse assunto.
A realidade é que a composição do preço de um projeto é bastante complexa e vale muito mais a pena você estabelecer um nível de produtividade superior a todos os seus concorrentes, de forma a sempre conseguir colocar seu produto na melhor relação custo/benefício para os seus clientes. Quem define o preço é o mercado, e não os seus cálculos individuais de custo. Se você já está trabalhando com algum tipo de desenvolvimento de projetos em clientes e, com isso, está sendo remunerado, o Scrum lhe dará uma produtividade maior que aumentará a sua lucratividade dentro de contratos existentes. Se você está tentando colocar um novo projeto de desenvolvimento em um cliente, você terá de entender a forma pela qual ele contrata projetos, produtos, fábrica de software, etc. Se você está entrando no mercado de trabalho, procure empresas que já tenham uma cultura de agilidade (de verdade, e não um Scrum Bunda) para integrar-se ao projeto, incrementar seu currículo e buscar capacitação e maiores ganhos.
As formas de contratação de projetos de desenvolvimento são muitas e estão em evolução. Porém há uma tendência atual, especialmente em contratações de grandes empresas e compras governamentais, de se usar a análise de pontos de função e, mais recentemente, Unidade de Serviço Técnico (UST)
Pontos de função consideram a funcionalidade de um software (sim, nesse caso, estamos falando apenas de projetos de software) a partir do ponto de vista de seu usuário. Eles independem da tecnologia empregada, incluindo a linguagem de programação e qualquer ambiente de desenvolvimento.
A técnica de análise de pontos de função foi proposta em 1979 por Allan J. Albrecht, da IBM, como uma forma de medir a produtividade no desenvolvimento de software e, a partir daí, começou a ser usada na estimativa de esforço e preço de desenvolvimento e comparações de custo/benefício entre produtos de software já prontos. Em 1986, uma série de organizações que já utilizavam a Análise de Pontos de Função criou o IFPUG (International Function Point Users Groups) e, em 2009, essa técnica de análise tornou-se a norma ISO/IEC 20926:2009.
O IFPUG publica o Counting Practices Manual, que foi traduzido para o português e é disponibilizado pelo Grupo de Usuários Brasileiros de Pontos de Função, mediante inscrição no grupo (http://www.bfpug.com.br/), onde é possível encontrar muito mais informações sobre o assunto.
De acordo com a Wikipedia, a Unidade de Serviço Técnico (UST) é uma unidade de mensuração de esforço para a execução de um serviço que envolva, prioritariamente, esforço humano não mensurável previamente com precisão ou de difícil mensuração por outras técnicas. É uma forma de diferenciar e mapear as horas de esforço técnico utilizadas para o desenvolvimento de atividades, baseando-se na natureza e complexidade da tarefa e na qualidade de cada profissional alocado. Ainda que, a rigor, essa definição aproxime a UST da ideia de Story Points, não é difícil encontrar em solicitações de propostas fórmulas que façam a equivalência da mesma em horas.
Leia no Capítulo 13, “Ferramentas”, uma breve descrição da técnica Ballpark, que pode ser usada no auxílio à orçamentação de projetos.
