FATTO Consultoria e Sistemas

Medição, Estimativas e Requisitos de Software

O desempenho do desenvolvimento nos tempos

da transformação digital
Carlos Eduardo Vazquez1

Resumo
Estou colocando esse material como uma balão de ensaio para medir o interesse de minha rede nesse tema e coletar
feedback sobre o mesmo antes de publicar a versão finalizada. Ele é de interesse para gestores no desenvolvimento
de software em uma época de transformação digital e desenvolvimento contı́nuo; para aqueles que se sentem meio
perdidos sobre como medir o desempenho em um nı́vel mais alto e sem onerar o processo.
Keywords
Transformação Digital; Gestão do Desenvolvimento de Software; Function Points; Gestão do Desempenho; Métricas
Funcionais; NoEstimates
1 FATTO Consultoria e Sistemas, carlos.vazquez@fattocs.com

Conteúdo contexto de contratos corporativos públicos e privados. Se

1 O novo contexto
1.1 Guerra e paz . . . . . . . . . . . . . . . . . . . . .
1.2 Ascenção e queda da eficiência operacional
1.3 Em busca da efetividade perdida . . . . . . . .
1.4 Além do bem e do mal . . . . . . . . . . . . . . .
2 Enxuto
2.1 Muito barulho por nada . . . . . . . . . . . . . . . . . . 2
2.2 Quem deveria ver florestas está vendo árvores? . . 2
2.3 o Tao do escopo na gestão do desempenho para
governança . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3 Como medir o dedo para comprar sua aliança
1. O novo contexto
1.1 Guerra e paz
A priorização da busca pela eficiência é uma preocupação
dos tempos de paz. Os efeitos das novas tecnologias na
transformação digital promove comportamentos de vida ou
morte; o seu negócio, como você conhece, pode simples-
mente deixar de existir. Esse tipo de comportamento é tı́pico
de tempo de guerra.
1.2 Ascenção e queda da eficiência operacional
Há uns 30 anos tenho trabalhado com a medição da
produção de software, em especial de unidades de pro-
duto por meio de pontos de função e, mais recentemente
também com o SNAP. Normalmente, fazendo isso com o
propósito de relacionar os resultados dessa medição com o
esforço ou custo. O resultado disso permite planejar, pres-
crever ou avaliar o desempenho na dimensão da eficiência,
mesmo quando ainda não se sabem os detalhes do design
ou implementação do produto.
São aplicações, que vão desde a estruturação de um
portfólio de projetos para perı́odos que vão de um a cinco
anos até a auditoria nas entregas de fábricas de software no
pararmos para pensar, percebemos que todas essas ações
1
estão vinculadas à dimensão da eficiência nos resultados
. . . . 1 em sua essência. Elas estão vinculadas a potencializar o
. . . . 1 menor uso de recursos na produção do máximo de resulta-
. . . . 1 dos; ou melhor, unidades de produto. Faço essa correção,
. . . . 2 porque haver muito software não implica em haver proporci-
onalmente um impacto nos resultados, que é a dimensão
2
da efetividade na gestão do desempenho.
1.3 Em busca da efetividade perdida
O que verificamos ao longo dos últimos 20 anos foi o sa-
crifı́cio da efetividade - a do impacto nos resultados - em
2 função da busca pela eficiência operacional. Um dos moti-
vos para isso é a dificuldade em se medir a contribuição das
partes avaliadas individualmente na dimensão que mede o
impacto nos resultados. Nessa busca pela eficiência ope-
racional - e também pela alienação dos desenvolvedores
de forma que a administração se tornasse deles mais inde-
pendente - processos de fábrica foram introduzidos em uma
produção de software, que compartilha muito mais fatores
com o artesanato do que com a engenharia. O resultado
é a demora de até um ano para modificar o nome de um
rótulo em um botão.
Em tempos de guerra, é possı́vel ter esse tempo de espera?
Quanto vale “desperdiçar” para se obter isso mais rápido?
A minha percepção sobre o estado das coisas hoje em dia é
de que haja um refluxo, se comparado ao fluxo nos últimos
20 anos, da importância de processos, métricas e indicado-
res. As métricas passam a ser empı́ricas e subjetivas de
forma que seja impossı́vel auditar. Como alguém do negócio
audita um story point? O próprio termo história de usuário
varia de canto para canto desde um épico, descrevendo
todo um fluxo operacional, até uma atividade de projeto
tratada, equivocadamente, como um requisito do produto.
E ninguém se preocupa com isso. . . desde que funcione.
Muitas vezes, nem mesmo se esse objetivo “funcione” custe
muito mais, que poderia custar.
 O desempenho do desenvolvimento nos tempos da transformação digital — 2/2
1.4 Além do bem e do mal Se você tem problemas com a gestão do desempenho no
Meu propósito não é discutir méritos ou deméritos nessa cenário que descrevemos, a FATTO tem soluções criativas
minha percepção de como as organizações têm se com- para ajudá-lo a definir a solução e operar as atividades
portado diante da transformação digital. O meu propósito necessárias para que a mesma seja implementada.
é definir um contexto para compartilhar a visão de como a
medição padrão ISO, como as métricas do IFPUG ou do
COSMIC, podem contribuir.

2. Enxuto
Em uma ótica lean, tudo o que não estiver agregando valor
ao produto ou serviço deve ser retirado do processo. Fa-
zendo para alguns executivos a pergunta sobre onde eles
estariam dispostos a pagar até 1

2.1 Muito barulho por nada

Nessa mesma linha de minimizar e, idealmente, eliminar
o que não agrega valor ao produto ou serviço, percebo o
desperdı́cio de muito tempo na resolução de divergências
de medição em minúcias. Se passarmos a considerar o
processo elementar como unidade; diminui-se o custo de
medição em menos da metade e os resultados são - ainda
assim - muito melhores e comparáveis do que outras uni-
dades como quantidade de histórias de usuário ou story
points.

2.2 Quem deveria ver florestas está vendo árvores?

Por fim, o uso das métricas funcionais não deveriam ser
usados na granularidade de um sprint ; usando a terminolo-
gia do SCRUM para um ciclo curto de desenvolvimento de
entre duas e quatro semanas. Confesso, que nesse nı́vel
de granularidade, não vejo a menor necessidade de uma
unidade de produto, seja ela qual for. Se o desenvolvedor
não consegue estimar de maneira direta um trabalho pon-
tual de até uma semana, então há um problema de gestão,
cuja solução não são as métricas de software.

2.3 o Tao do escopo na gestão do desempenho para

governança
A minha recomendação é que a medição de unidades de
produto seja no nı́vel de uma nova release do produto. Anti-
gamente, eu também citava a granularidade do projeto; mas
vejo hoje, que no contexto descrito, o paradigma do projeto
deveria ser abandonado e, em seu lugar, adotada a lógica
de um produto vivo, que evolui contı́nua e organicamente
ao longo do tempo e conforme há ciclos de experimentação,
feedback e aprendizado pela comunidade usuária.

3. Como medir o dedo para comprar

sua aliança
Voltando a questão do valor; o que se mede, se promove.
Considerando, que o prazo seja a dimensão de maior valor,
nada melhor que relacionar a quantidade de processos
elementares com o prazo da release. A quantidade de
processos elementares pode ser usada diretamente, ou
utilizar um fator de comparação com pontos de função para
fins de alavancar a comparabilidade dos resultados, por
exemplo, cada 01 processo elementar equivale em média
a 06 PF. O prazo da release pode ser expresso em dias
corridos, porque é mais fácil de obter. A métrica resultante
cumpre o papel de um cycle time no nı́vel de uma release,
passı́vel de planejamento e monitoramento por elementos
externos do time de desenvolvimento.

c FATTO Consultoria e Sistemas - www.fattocs.com
Proibida a reprodução total ou parcial sem a permissão dos autores por escrito.