28 de set. de 2009

Produtividade e Métricas de Software – Parte I

Discutir sobre produtividade e métricas pode ser muito divertido caso tenhamos no mesmo grupo representantes dos atuais mundos do desenvolvimento de software: o tradicional e o ágil. No entanto, acredito que o debate se tornará proveitoso caso as discussões evoluam para o comum acordo entre as partes, e não para a briga de egos ou apegos filosóficos! ;-)

É muito comum observarmos que tanto o cálculo da produtividade quanto a utilização de unidades de medida em projetos de software tem gerado polêmica em reuniões, palestras e listas de discussão. O principal motivo é que a medição de determinadas informações pode gerar desperdício no processo caso seu resultado não agregue valor em atividades de planejamento, controle ou melhoria do ambiente de produção.

No dia 4 de agosto de 2009, tive a oportunidade de conduzir um encontro de análise e resolução de problemas num cliente já aderente à cultura ágil, que incorporou com sucesso ações sistemáticas de melhoria contínua nas práticas mensais de sua unidade de desenvolvimento em Porto Alegre (RS). Naquela ocasião, optamos por não utilizar nossa ferramenta padrão de investigação de cenários de melhoria (Café Kaizen), pois o interesse da discussão, proposto pelo Gerente Geral de Desenvolvimento, estava focado na seleção de métricas para a avaliação da produtividade de suas equipes de software.

O assunto foi despertado devido ao interesse crescente da alta gerência em avaliar a capacidade produtiva das equipes de desenvolvimento com a utilização de uma “unidade padrão de medida” que fosse reconhecida pelo mercado internacional de software. A justificativa dos mesmos estava no interesse por uma avaliação de benchmarking que comparasse os custos e a produtividade das equipes localizadas em diferentes regiões do Brasil.

Fiquei surpreso com o fato dos gestores estarem propondo a utilização de Pontos de Função como unidade de medida do cálculo de produtividade (sob a orientação de outros consultores), pois esta decisão entraria em choque com as atuais práticas incorporadas na empresa que já utilizam Story Points como base para a medida de tamanho de produto e produtividade das equipes.

Diante desse cenário, utilizamos a reunião para analisarmos algumas métricas comuns do desenvolvimento de software, bem como suas vantagens e desvantagens na avaliação dos resultados das equipes de desenvolvimento. Este post relata a primeira parte das reflexões que fizemos sobre este tema durante o encontro. Começarei apresentando uma reflexão sobre produtividade baseada no cálculo de linhas de código, dado que este era um tema presente no ambiente de produção do cliente e ainda persiste em muitas empresas de software pelo país.

Investigando a Unidade de Medida "Linhas de Código"

Não vou me deter muito tempo sobre este tema dado que o entendimento do mesmo já deve ter evoluído bastante em nossa comunidade de software nos últimos anos. Pelo menos isso é o que eu espero das pessoas que evoluíram junto com os avanços da nossa querida Engenharia de Software! ;-)

Vou contar duas histórias para tentar transmitir minha opinião sobre produtividade calculada com linhas de código.

Caso #1: Produtividade Negativa de um Desenvolvedor Sênior

“Certo dia, acordei com muita disposição para trabalhar. Cheguei cedo no escritório, li meus e-mails e me dirigi para a reunião diária de atualização de projeto. De volta para a minha mesa, e de posse dos requisitos funcionais que eu desenvolveria naquele dia, preparei minha IDE para começar uma jornada de trabalho que seria a mais produtiva de minha vida! Fiz o update de meu projeto para ter a certeza de que eu teria todas as alterações de código realizadas por colegas de equipe desde o último commit no repositório. Analisei as demandas e identifiquei os componentes que seriam alterados e criados no sistema. Infelizmente, meu antigo colega havia feito um “espaguetão” quando desenvolveu os componentes que eu deveria atualizar naquele dia, demonstrando total desconhecimento de nossa arquitetura e conceitos básicos de programação orientada a objetos. Fui obrigado a realizar um belo refactoring em todas aquelas classes e desenvolver novos componentes que receberiam elogios dos maiores gurus da engenharia de software. Eliminei centenas de linhas reutilizando componentes e explorando design patterns, escrevi poucos métodos e linhas de código, mantive o código padronizado e intuitivo para os próximos colegas que utilizariam o mesmo, garantindo 100% de cobertura em testes de unidade para cada componente. Passei todo o dia refatorando os componentes existentes e criando novos elementos altamente enxutos. Sabe qual foi o resultado? Entreguei três novas funcionalidades num único dia e reduzi em mais de 1.000 linhas nosso código fonte, tendo passado em todos os testes de integração! Sinto-me realizado!”.

Comentário: Nosso amigo fez tudo isso e acabou tendo uma produtividade negativa calculada em linhas de código!

Caso #2: Produtividade do Fornecedor Mal Intencionado

"Pessoal, não se esqueçam de utilizar aquele sistema gerador de código que baixamos da Internet. Ele caiu como uma luva em nosso projeto, pois aumentou consideravelmente nossa produtividade! Para atender todas as necessidades de diferentes equipes de desenvolvimento, ele insere tudo que você pode imaginar no código fonte, gerando um monte de linhas inúteis e deixando o mesmo difícil de ser analisado. Como nossa equipe é remunerada por linhas de código, ele é perfeito! A propósito, não percam tempo estudando a API do sistema. Refaçam tudo o que for necessário! Não economizem na velha técnica de 'copiar e colar'! Afinal de contas, nosso cliente está pagando pela quantidade de linhas de código que entregamos semanalmente em seu repositório de aplicações. Até na correção de bugs nós ganhamos pela manutenção das linhas que não passam nos testes de aceitação. Ainda bem que eles não sabem realizar inspeção de código, automação de testes e integração contínua!”

Comentário: A quantidade de linhas de código pode ser uma excelente medida de desempenho para quem não é produtivo ou não dá valor ao dinheiro dos outros!

Observações:

Saber o tamanho de um produto de software em função de suas linhas de código pode ser útil para o entendimento do crescimento de um repositório de controle de versões ou identificação da complexidade de um sistema legado que entrará em manutenção de melhoria ou migração de plataforma tecnológica. Não podemos negar que os riscos associados a manutenção de um sistema de 1 milhão de linhas de código é muito maior que os riscos associados a um sistema com 100.000 linhas de código. Se você estiver utilizando um bom sistema de controle de versões, essa informação pode ser facilmente obtida de seu repositório de programas.

Por outro lado, calcular a produtividade da equipe ou remunerar profissionais pelo total de linhas de código produzidas por unidade de tempo (como foi feito na grande maioria dos projetos do “bug do milênio”) é completamente insano nos dias de hoje!

Talvez você diga que pode ser uma informação útil para definir a escolha de uma linguagem de programação ou plataforma tecnológica (com qual linguagem eu desenvolvo o mesmo número de funcionalidades com menos linhas de código). No entanto, gerar poucas linhas e não ser capaz de garantir a qualidade do que foi gerado por inspeção automática de código ou integração contínua com testes automatizados pode impactar diretamente nos ganhos de produção a médio prazo.

No próximo post, medidas de tempo e pontos de função ...

8 de set. de 2009

Percepções do Agile 2009 (Chicago, USA)

Caros amigos, retornei do Agile 2009 (Chicago) com algumas considerações sobre o que está acontecendo no mercado internacional de desenvolvimento de software. Dentre elas, gostaria de relatar nove que me deixaram mais frustrado do que empolgado quando comparo os fatos identificados e a situação brasileira do mercado de métodos ágeis ... Confira!
  1. No exterior, "métodos ágeis é coisa para gente experiente"! Enquanto por aqui falam que isso é coisa de "gurizada", por lá muitos dos palestrantes tinham cabelo branco ... sem contar que a maioria foi ou é líder de grandes empresas. Tive o prazer de conhecer pessoalmente um dos ex-engenheiros de software do projeto Apolo (NASA, anos 60), Mr. Jim Highsmith (atual diretor do Cutter Consortium). Sem contar com os demais gurus que lá estavam presentes ...
  2. Enquanto no Brasil quem vai nesses eventos são alunos e pessoas sem muito poder de decisão, por lá tivemos a oportunidade de sentar à mesa com gerentes e diretores da Microsoft, HP, Motorola, American Airlines, Disney, Amazon.com, ThoughtWorks, governo americano e muitas outras grandes empresas ...
  3. Enquanto no Brasil a grande maioria ainda está pensando se as metodologias ágeis realmente funcionam, por lá o que mais ouvimos foram relatos de projetos com equipes distribuídas em diversos continentes, todos com milhares de profissionais alocados nas mais diferentes partes e culturas do planeta. Ouvimos relatos de um projeto de "agilização" de uma empresa asiática com aproximadamente 40.000 profissionais ... não conheço empresa brasileira que tenha tudo isso!
  4. O modelo de gestão da Toyota (Lean) é a tendência para a grande maioria das organizações que adotam agile. Scrum e XP continuam em alta, mas é muito mais fácil adotar as práticas de gestão de times do Scrum num primeiro momento do que toda a disciplina de engenharia de software demandada pela XP. O que tem que ficar claro é que as práticas da XP acabam se tornando um caminho natural quando um time Scrum atinge seu máximo de desempenho e Lean tem que estar no sangue dos gestores e cultura da empresa ...
  5. Grandes empresas de fornecimento de serviços de software, totalmente baseadas nos princípios e práticas ágeis, já estão recusando projetos de milhões de dólares quando os mesmos estão sendo demandados com a utilização de metodologias tradicionais. O sucesso do projeto e a satisfação de todos os seus integrantes é mais importante do que a receita obtida associado ao risco do fracasso, pois o desenvolvimento ágil está mostrando maior lucratividade e fidelidade do cliente.
  6. "Coaching" é assunto sério! Assim como não é comum vermos atletas profissionais de elite treinando sem a supervisão de um excelente técnico (somente amadores treinam sem supervisão técnica), empresas de alto desempenho fazem uso indiscriminado de profissionais experientes estimulando o aprimoramento técnico de novas equipes.
  7. Não conseguimos falar de planejamento desacoplado da análise de requisitos. Além disso, como o foco das metodologias ágeis sempre foi a agregação de valor ao negócio do cliente, cada vez mais é demandada uma competência em análise de negócios para todos os integrantes da equipe de desenvolvimento envolvidos no desenvolvimento de requisitos.
  8. Representantes do PMI internacional estavam em peso no congresso, uma vez que a estratégia internacional é orientar os PMPs a aderirem a práticas que realmente funcionam em projetos de software: processo criativo e desenvolvimento orientado a auto-gestão da equipe de desenvolvimento (comunicação e liderança). Nossos PMPs terão que "se puxar" para encarar essa ...
  9. Agile 2009 (Chicago): US$ 1.800,00 de inscrição, recursos da ordem dos US$ 1,5 milhões, 1.500 participantes ... Agiles 2009 (Florianópolis): muitos dos palestrantes nacionais e internacionais do Agile Chicago, R$ 100,00 de inscrição, recursos da ordem dos R$ 100K, e se der 400 participantes é muito! Realmente, a nossa realidade é outra ... ;-(
  10. Quanto aos brasileiros falando em Chicago? Nos saimos muito bem (eu, Rafael, Alexandre, Danilo e Francisco) com nossas palestras e workshops! Ficou claro que estamos fazendo muito bem nosso dever de casa (como consultores e instrutores) e estamos cada vez mais sendo respeitados pela comunidade internacional ... só falta nosso mercado nacional perceber que "santos de casa podem fazer milagres" ... ;-)

Para mim, as metodologias ágeis serão disseminadas em nosso país quando ensinarmos nossos clientes (compradores de projetos de software), a questionarem os desperdícios existentes nos processos de seus fornecedores e avaliarem de forma objetiva a qualidade dos produtos a eles fornecidos.

Para quem não pode comparecer, confira uma matéria bem legal em vídeo feita pelo pessoal da Agile Journal.