M√©tricas, Indicadores e Scrum 

Oct/12
17

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.

Comente

Enquete

Sobre quais assuntos gosta de ler neste blog ?

View Results

Loading ... Loading ...

Artigos