Eu gosto bastante do modelo de 6 dimensões ( características, restrições) de projeto usado no PRINCE2. É uma evolução em relação ao triangulo de ouro, e dá para utilizar com ágil também. As 6 dimensões são : Escopo, Prazo, Custo, Beneficio, Risco e Qualidade. A ideia é medir variações em cada uma delas e de posse dessas variações avaliar a saúde do projeto. Nos mecanismos tradicionais apenas o custo e o prazo são avaliados e a qualidade é subentendida.
Para medir precisamos de uma unidade e de uma escala. Para o Prazo e o Custo é simples de escolher a unidade. Dias para o Prazo e Dinheiro (na moeda corrente) para o Custo. Isto é simples, mas esconde algumas particularidades não triviais. Por exemplo, o prazo é em dias uteis ou dias corridos ? Faz todas as diferença. O prazo e o custo têm uma relação. Mais dias trabalhando significa mais energia consumida , mais salários etc. Manter o mesmo prazo também tem um preço (mais horas extra, mais esforço, menos qualidade). Mas o custo não advém apenas do esforço feito pelas equipes. Ele advém principalmente do esforço não feito. Se não foi investido um tempo criando uma infraestrutura para o projeto é muito provável que todos os programadores estejam violando alguma regra em algum lugar que não apenas irá afetar a qualidade, mas irá gerar custo de correções.
A Qualidade é uma dimensão mais dificil de medir. Normalmente contam-se os bugs, mas isto é muito limitado. Seria necessário classificar o tamanho do bug. Um bug que implica em mudar uma virgula é diferente do bug que implica mudar uma camada. Por outro lado, também estão incluídos na dimensão de Qualidade conceitos relacionados a calculos que o sistema faça e a especificações sobre desvios aceitáveis, ou seja, a confiabilidade e a exatidão. A Qualidade está relacionada ao conceito de Defeito que é mais lato que o conceito de bug. Defeitos podem acontecer em todas as partes do software, inclusive nas conceptuais como nos requisitos. E é sabido que um Defeito no Requisito gera um muito maior custo para ser resolvido que um defeito no código.
O Escopo é uma outra dimensão difícil de medir. O escopo é especificado em requisitos (que podem estar sob várias formas como estorias ou casos de uso, mas no final são requisitos) e esse escopo tem um tamanho. Estamos interessados em medir o tamanho do escopo. Quando falamos de projetos de escopo fixo as pessoas normalmente entendem que a lita de requisitos não muda. Isto é simplesmente impossível, e todos sabemos que a lista de requisitos sim irá mudar. Então a opção é considerar que os requisitos podem mudar, desde que o tamanho não mude, pois é o tamanho que está relacionado ao prazo e ao custo e não o requisito em si. Contudo, a especificação em si mesma está relacionada ao risco e ao beneficio. Fazer do jeito A ou B podem até ter o mesmo tamanho e portanto devem demorar o mesmo tempo e ter o mesmo custo para implementar, mas podem não ter o mesmo risco e/ou beneficio. Por exemplo, encriptar a password do usuário no banco de dados ou não, dá o mesmo trabalho ( a diferença não é significativa, mas se quiser tome o exemplo com dois algoritmos de encriptação diferentes), mas não tem o mesmo risco. A password aberta permite hacking mais simples e rápido. Para o escopo temos os tradicionais pontos de função , ou os pontos de estoria.
O Risco é medido em duas partes. Ele é medido pela probabilidade de um certo problema acontecer e o impacto se acontecer. Por exemplo, qual é a probabilidade de sermos hackeados e se formos, quanto vamos perder. Este arcabouço serve para medir tanto os riscos do sistema quanto os do projeto. Por exemplo, o risco de ter que refazer todas as telas se o requisito A for modificado. Qual é a probabilidade de ser modificado ? (não é zero) O quanto teremos que pagar para mudar as telas ? Riscos relacionados a mudanças no código podem ser mitigados com uma melhor design e uma melhor estruturação do projeto em termos de abstrações, tentando deixar o código o mais flexível possível adiando decisões o mais possível.
Finalmente o Beneficio. Medir o beneficio é o mais difícil. Como se quantifica o valor ? Podemos priorizar as estorias e os requisitos. Se começarmos pelo mais prioritário e seguirmos a ordem sem pular, estaremos colocando o máximo valor. Mas e se pularmos um item ? Quanto ficou de valor ? O Beneficio quase nunca é absoluto a menos que esteja relacionado a um prêmio em dinheiro ou a um tempo, quase sempre é relativo e depende das opções que são possíveis.
Dado isto, a minha proposta é olhar estas dimensões do ponto de vista do scrum/ágil.
O conceito básico é que em scrum tudo são historias e todas as historias têm tamanho e valor. O tamanho é relacionado ao tempo pela velocidade e duração do sprint. O custo é relacionado ao tempo da forma comum usada em projetos tradicionais. O tamanho é medido em Pontos de Estória. O valor é diretamente relacionado ao beneficio. O risco é relacionado às historias bloqueadas, ao backlog de impedimentos e a um possível valor de risco que é atribuído a cada historia durante o planning poker.
O tamanho do Escopo é a soma dos tamanhos das historias no product backlog e no defact backlog. Desvios neste tamanho têm que ver com a adição/remoção de historias e operações de divisão das historias em outras historias ou fusão de historias em menos historias. A qualidade pode seria medida pela soma dos tamanhos dos Defeitos (que são historias) e não por meros bugs. Os bugs são mortos dentro do sprint , então eles nunca são visualizados. O que escapa e é observado depois gera Defeitos. Quando maior é o defeito , pior, pois irá ocupar um espaço no sprint log que poderia ser ocupado por uma estoria. Isto vai afetar o tamanho do escopo pois novas historias estão surgindo “do nada”. A estoria também tem um valor, e em Scrum o valor é um numero diferente da prioridade. Então embora estejamos sempre seguindo a prioridade ao executar as estorias isso não significa que o valor está aumentando da mesma forma. Porque os defeitos não têm valor colocar mais defeitos no sprint significa aportar menos valor, mas um defeito tem prioridade máxima o que causa um paradoxo que tem que ser resolvido caso a caso. Será que aquele Defeito é realmente tão nefasto assim ? E se comparados com os outros ? Podemos sobreviver com ele ? Isto é consistente com o que seria de esperar pois correção de defeito não “faz andar” o projeto, contudo, porque tem um tamanho, o defeito irá consumir espaço no sprint e portanto no prazo e no custo. Ou seja, quanto mais a equipe scrum (PO incluído se enganar, mais Defeitos existirão, menor será a Qualidade e maior será o Custo e o Prazo. Isto é o que seria de esperar no modelo tradicional. A diferença é que “mais Defeitos” no modelo tradicional simplesmente significa uma quantidade maior de defeitos, em scrum, significa não apenas uma quantidade mais um tamanho. Um só defeito pode arrastar o projeto por longos períodos porque ele é grande. Este tipo de conceito e conta não pode ser feito no modelo tradicional onde não existe o conceito de tamanho.
O Prazo é o numero de Sprints ainda faltando para o final multiplicado pelo tempo de um sprint adicionando tempo entres sprints, dias não uteis, etc… Conforme o escopo aumenta porque as estorias são mudadas ou os defeitos são encontrados o numero de sprints necessário para o final aumenta. Isto também significa que dado o escopo inicial e considerando uma velocidade média qualquer, sempre o numero de sprints encontrado desta forma será menor que o numero de sprints real. Primeiro porque esta velocidade média é uma estimativa e segundo porque se está despesando a carga de defeitos. Na prática existem sprints onde o objetivo é eliminar defeitos ao invés de incluir novas historias.
Sabido o prazo, o custo pode ser calculado com base nele juntando algum tipo de multa ou custo de oportunidade perdido. Aqui teríamos que diferenciar custo de despesa e de investimento. Normalmente as pessoas pensam custo= despesa , mas tem mais profundidade nessa dimensão. Num modelo simples o custo é diretamente proporcional ao prazo, mas não necessariamente. considerando que custo = despeza + investimento é possível que um maior custo produza um menor prazo, porque houve investimento. O contrário também é possível, investir um certo tempo criando uma estrutura ou clarificando um requisito pode diminuir o custo porque diminui a despreza. A relação entre prazo e custo não é tão direta como parece.
O beneficio é avaliado pela quantidade de valor que está sendo adicionada a cada sprint – considerando a prioridade dada pelo PO, face ao valor que deveria estar sendo adicionado considerando apenas as estórias ordenadas pelo seu valor ( não pela sua prioridade). Isto significa que se não pularmos nenhuma estória ou fizermos nenhuma priorização “ad doc” , o valor deve sempre aumentar a cada sprint com variação nula em relação ao esperado. Quanto mais priorizações, mais defeitos ou pulos, menos valor será adicionado o que significa que estamos gastando sem ter o retorno devido. Isto dá uma nova imagem ao PO de como controlar o ROI. Basta maximizar o valor por Sprint. Na prática quase sempre é necessário pular um pouco no backlog atraz de uma historia mais pequena que tem menos valor mas que cabe no sprint. Afinal o PO quer maximizar os pontos por sprint mantendo o fator de foco ( o numero de pontos feitos sobre o numero de pontos orçados pela equipe)
O risco é mais complexo, porque ele tem duas dimensões (a probabilidade e o impacto). A lista de risco pode advir do backlog de bloqueios levantado pelo scrum master, pode advir de simples conclusões que os membros da equipe retiram das especificação ou do andamento dos trabalhos. O impacto pode ser mensurado em “estórias de mitigação” no sentido de que se o risco realmente acontecer, uma estória ( ou um tema) terá que ser criado para resolver. Estimar isso em tamanho e adicionar ao escopo indica o tamanho do risco ( o impacto) a prioridade dessas historias de mitigação no backlog aponta a probabilidade. Quanto mais para cima, mais provável.
Isto nos dá uma ideia de como as dimensões poderiam ser avaliadas dentro de framework scrum. Dito de outra forma, o scrum embute em si mesmo mecanismos e mensuráveis que fundamentam e realizam as 6 dimensões de qualquer projeto. Isto significa que ao executar o processo scrum estamos implicitamente fazendo medidas e tomando decisões sobre os desvios dessas medidas sem sequer nos apercebermos. Controlar todos estes fatores iria requere uma super equação e muito trabalho para pensar sobre o que está além do limite e que medidas tomar. O scrum permite tomar decisões sem ter que pensar num super modelo complexo de várias variáveis que conspiram para o sucesso ou insucesso do projeto. Ainda mais o scrum oferece uma linguagem simples para o cliente entenda o estado do projeto sem ter que entender um super complexo modelo de variáveis mas possa participar das decisões de forma simples e fundamentada em dados reais.
Vimos que tudo se resume a criar historias – que nada mais são que itens de uma lista – e atribuir-lhes um Tamanho, um Valor e uma Prioridade. Mas também vimos que as escalas destes valores não são imparciais. Por este motivo é muito perigoso usar quaisquer destes valores em contratos. Primeiro porque são subjetivos e em segundo porque a Lei de Goodhart os irá corromper fazendo com que deixem de ser valores medidos, para serem valores cozinhados. O texto do Allan Kelly explica bem por quê.
Em suma métricas e indicadores devem ser usados pelo projeto e para o projeto, não pelo processo do departamento comercial, financeiro ou pela contabilidade. A conversa com o cliente deve ser aberta no sentido de que ele conhece os conceitos, os respeita e sabe entender os números e como eles demonstram onde estão os problemas. As métricas e os indicadores devem fazer parte da linguagem entre a empresa e os clientes , entre o cliente e o PO e entre o PO e a equipe, mas não devem servir para mapear o sucesso ou insucesso do projeto.