Avaliando Scrum em um ambiente CMMi5

Postado por Daniel Magalhães em 26 Mai 2009

Seções

Processos e Práticas,

Arquitetura e Design

Tópicos

Scrum Gathering ,

Metodologias ,

Eventos ,

Agile

Tags

Scrum ,

Product Owner ,

Qualidade

Ainda existe no mercado de software uma grande defasagem de informação acerca de como medir o desempenho dos projetos que utilizam Scrum. O mercado, acostumado a ver os resultados em números, tem custado a entender o beneficio da filosofia Lean do “go and see”, e tem tido mais dificuldade ainda em desenvolver um modelo de medição e análise que agregue valor à organização sem causar overhead aos times.

A ideia de nossa apresentação no Scrum Gathering Brasil 2009 foi mostrar o trabalho que tem sido realizado na Ci&T, um ambiente de Outsourcing e com uma forte cultura CMMi, em relação a gerência quantitativa e estatística dos projetos Scrum. Projetos que já fazem parte da carteira da empresa há 2 anos. Apresentamos o trabalho que tem sido realizado para construir um conjunto confiável de métricas que evidenciem o desempenho destes projetos, de forma clara e precisa; métricas que corroborem o sentimento de que estes projetos apresentam resultados muito melhores do que aqueles que utilizam metodologia Waterfall.

Discutimos quais métricas perdem o sentido para estes projetos, tais como Taxa de Defeito por KLOC ou por Ponto de Função (PF), Produtividade (h/PF ou LOC/h) e Custo por PF. Mostramos exemplos de métricas cujo acompanhamento passa a ter um novo sentido, tais como:

• Desvio (%)
O desvio é calculado da mesma forma que era para os projetos Não Scrum. O que muda é o sentido que ele passa a ter. Estamos olhando para este desvio como um indicador de que o time não está sabendo negociar adequadamente com o Product Owner (PO) os itens de backlog do Sprint, ou também como um indicador de que o PO não entendeu corretamente ainda como Scrum funciona e qual o papel dele nesta governança de escopo. Identificando uma destas duas causas ou outras ainda, atacamos o problema com a melhor abordagem necessária.


• Percentual de Conclusão (%) (PC)
Cada membro do time ao executar uma atividade informa a porcentagem de conclusão do seu trabalho, baseado nas horas que gastou. Também é calculado da mesma maneira que anteriormente, só que nos projetos Scrum ele não tem o mesmo poder de informação que tem a curva de burndown, que nos mostra dia a dia quais tarefas do backlog estão sendo concluídas. O PC leva em consideração também as horas gastas com outras atividades, que não somente as horas utilizadas para “queimar” o Backlog, por isso, deve ser analisado diferentemente. Funciona mais como um auxiliar aos indicadores financeiros, mostrando quanto deveríamos receber até dado momento.

Discutimos também, métricas adotadas para medirmos os projetos Scrum, tais como:

• Tamanho do Backlog Futuro (FTE)
É a quantidade de FTEs que estão planejados para a conclusão do projeto. De posse dela e da capacidade produtiva alocada para um Sprint extraimos oTamanho do Backlog Futuro em Sprints, o que nos dará uma visão em Sprints do quanto falta para concluir o projeto.


• Business Value
Está métrica depende da maturidade do cliente em quantificar o valor de negócio do projeto e dos itens de backlog. Alguns possuem uma maneira muito particular de calcular este Bussines Value, baseada em alguns critérios muito bem estabelecidos. Outros, contudo, ainda não possuem esta maturidade e precisamos discutir com eles alguma forma de quantificar este valor, mostrando a importância que esta métrica possui para a correta percepção dos resultados do projeto. Para nós não importa muito a maneira como o cliente chega neste valor, o mais importante é que ele consiga quantificá-lo e nos diga a cada Sprint o quanto deste valor estamos entregando. Para efeito da métrica nos interessa a porcentagem. 

Além deste conjunto de métricas, apresentamos também os resultados obtidos com a aplicação do "Nokia Test" e a importância desta avaliação na inspeção e adaptação dos times.

Apresentamos ainda os excelentes resultados que temos obtido nos projetos Scrum:

• Ótimo Retorno Financeiro
• Satisfação do Cliente fora da curva
• Melhoria no clima interno de trabalho
• Motivação do time acima da média
• Ótima qualidade do produto

Por fim, discutimos quais tem sido os desafios enfrentados desde o começo da implantação de Scrum na empresa. Para citar alguns:

• Mudança de Mindset – dificuldade de alguns em enxergar o grande valor do novo paradigma de fixar as variáveis tempo, custo e qualidade do triângulo de ferro e deixar o escopo como a variável negociável.
• Questão cultural externa – resistência por parte dos clientes dentre outros fatores em aceitar a responsabilidade pela governança de escopo.
• Questão cultural interna – resistência a mudanças, receio em deixar a zona de conforto.

Ainda existem perguntas em aberto e muito trabalho a ser feito para manter o nível de excelência e maturidade conquistadas ao longo do tempo na busca da melhoria contínua, mas acreditamos estar no caminho correto.

• Mais antigos >