Tenho ouvido ultimamente muitos amigos da área comentando sobre pressão por aumento de produtividade baseada em pontos de complexidade. Isso me deixa bastante preocupado. Embora seja nobre o desejo de aumentar as entregas da área de desenvolvimento, quantificar isso usando os pontos de complexidade das histórias não quer dizer muita coisa.
Contudo antes de simplesmente reclamar contra a pressão, é preciso analisar as possiveis causas de produtividade baixa que possam estimular esse tipo de pressão. Pensando bastante cheguei a três possibilidades, e com elas, possiveis soluções, que seriam mais eficazes do que estimular aumento desse tipo de numero.
1- Não há confiança de que o time esteja trabalhando em seu máximo. Ou seja, o agente gerador de pressão acredita que os integrantes estão fazendo corpo mole ou gastando o dia com amenidades ao invés de se focar na entrega do projeto. A pressão por aumento de pontos de complexidade pode até resolver esse problema temporariamente, mas também pode ser mascarado por integrantes do time que se sentem coagidos a fazer horas extras para cobrir as entregas esperadas. Ou seja, o problema só se resolve mesmo com conversas francas e com uma presença mais ativa do interessado.
2- O time percebendo folga na iteração aproveita para melhorar a qualidade da entrega ainda mais. Esse tipo de preciosismo costuma acontecer com bastante frequência. Muitas vezes o desenvolvedor por ter mais tempo para pensar aproveita para implementar testes e fluxos mais rebuscados evitando bugs que no futuro tomariam o triplo do tempo, e o designer aproveita para criar e rebuscar as interfaces e assim encantar ainda mais o cliente. Neste caso a pressão pelo aumento de entrega de pontos de complexidade apenas estimula a diminuição da qualidade. Ou seja, embora haja um aumento imediato na velocidade, em pouco tempo ela cairá por causa das correções de bugs e dos ajustes visuais.
3- O time é inexperiente ou não conhece a tecnologia adotada. Neste caso pressionar pelo aumento de entrega de pontos de complexidade de nada adianta. De certa forma, com o tempo, naturalmente as entregas serão maiores, ou em muitos casos menores pois o time começará a estimar com menos pontos, demonstrando assim a ineficácia desse numeros para medir produtividade. Para resolver este problema existem diversas opções como, organizar dojos, estimular programação em par, indicar livros e treinamentos, estimular a experimentação com tempo para projetos pessoais.
Todas três possibilidades acima eu vi acontecer de perto nos times em que trabalhei. E quase sempre o problema foi resolvido sem utilizar os pontos de complexidade como parâmetro de medição. E vocês lembram de alguma outra causa de produtividade baixa? Tem idéia de como solucionar? Qual sua opinião sobre o assunto?
Dê uma lida em http://www.poppendieck.com/pdfs/Software%20Development%20Productivity.pdf, você vai ver que sim, existe como medir prodtividade, mas nunca atrelando o resultado a uma medida controlada por quem é medido.
ResponderExcluirLogo no começo do texto tem uma lista de como aumentar a produtividade:
- Reduzir custos, eliminando investimentos em features que não agregam valor ao produto
- Reduzir custos indiretos tornando os processos menos complicados e eliminando o desperdício no desenvolvimento, entrega e suporte
- Aumentar a receita, adicionando mais valor aos produtos, de forma que se pague mais por isso.
Pode não ser produtividade baixa, mas pouco valor entregue. O que você prefere, entregar menos pontos e mais valor, ou entregar mais pontos e menos valor (o que no final das contas é apenas gasto)? Claro, a melhor alternativa seria entregar muito valor com muita produtividade.
ResponderExcluirMas o que eu realmente gostaria de ver os "agentes geradores de pressão" fazerem é, ao invés de apenas cobrarem mais produtividade, perguntarem "como eu posso te ajudar a ser mais produtivo?".
Simplesmente sensacional, meu caro. Curti ver esta análise de três padrões e concordo com todos eles.
ResponderExcluirEu continuo sendo do partido que pontos de complexidade são uma medida interna do time, pra que este não se comprometa demais em um sprint.
É apenas um velocímetro, nada mais.
Tentar medir a capacidade ou a produtividade de um time com base na complexidade é tão insensato quanto usar critérios como quantidade de linhas de código escritas ou horas trabalhadas. É orientar-se em direção à mediocridade e ao trabalho imbecilizado.
O que interessa é o valor que está sendo entregue.
Dado um backlog onde o product owner consegue estabelecer de maneira correta o valor de negócio de cada estória, este pode até usar de pontos de complexidade para fazer seu plano de releases e assim ter alguma *noção* de quando as coisas acontecem (noção != prazo). Ainda assim, release plan que nao considerar uma constante de pontos de valor de negócio sendo entregues com constância tende a fazer o cliente bocejar logo ali na frente… e com isto perder o seu usuário/cliente pra outro produto ou rival.
E assim como o manter de um ciclo de releases sempre recheados de valor constante faz com que o cliente/usuário estejam sempre felizes, a mesma relação baseada em constante entrega de valor de negócio a cada sprint manterá time e sponsors felizes.
É impressionante como a proposição de medir a capacidade de produzir de um time pelo valor entregue ainda soa absurda pra algumas pessoas ditas de produto.
Fossem ainda críticas dizendo "é muito difícil calcular valor de negócio", eu até poderia aceitar -- se bem que, numa boa, é muito mais fácil calcular valor de negocio do que chutar complexidade, mas beleza. Discordar? Sei não…
E aí que vem o ponto mais legal: pra fazer isso você precisa de um bom Product Owner, com PO de verdade, que saque de produto e seja realmente dono do que está sendo feito e possa trabalhar com accountability (mal pelo ingles, nao tem palavra melhor) e definir o valor de cada estória.
Sem isso? Hmmmm… deixa pra lá, vamos contar horás, digo, pontos…
[]s!
ISSO de produtividade sempre me lembra ISSO:
ResponderExcluirhttp://www.wetherobots.com/2008/07/07/typing/
E no final, estes números, estatisticas, são iguais a biquinis: mostram tudo, menos o essencial.