Hoje foi publicado meu artigo de estréia no InfoQ Brasil. Falei sobre um post do Scott Berkun desta semana, daqueles que te deixam humilhado e com a sensação de que você está no caminho errado!
Confiram e comentem! http://www.infoq.com/br/news/2010/06/programador-artista
Com uma pergunta dessas eu com certeza estou causando confusões nas mentes das pessoas que não entendem exatamente o que estou dizendo. Vou dar alguns exemplos de coisas que tenho visto ultimamente para que as conclusões possam fazer algum sentido…
Primeiro, o contexto: as experiências têm se passado no dia-a-dia do trabalho de imersão Ágil que temos feito na Agence. Segundo, não vou citar nomes de clientes ou coisas do tipo e tentarei ser o mais claro possível sem ofender ninguém. Terceiro, se alguém se ofender, sinta-se à vontade para expressar seus argumentos nos comentários, pessoalmente ou de qualquer outra forma. O que vou colocar aqui é apenas meu ponto de vista atual sobre desenvolvimento (ágil) de software.
Tenho visto uma tendência de empresas que tem mostrado um trabalho legal, de não atenderem grandes corporações multinacionais para dar preferências à startups. Com isso, refleti um pouco sobre como isso acontece no meu dia-a-dia, visto que tenho a oportunidade de atender tanto clientes abrindo um novo pequeno negócio ou dando uma “guinada” no seu pequeno negócio atual, quanto grandes corporações multinacionais ou governo.
Percebi algo interessante. Se falando de desenvolvimento ágil, mais especificamente SCRUM, temos a figura do Product Owner (PO). Esse é um papel bastante difícil de se assumir, visto que este cara visa o ROI como principal fator de sucesso de um projeto de software, pelo menos na cartilha. Fazendo um paralelo para o mundo real, nem com os cliente mais “engajados” que atendemos, tenho nutrido esperanças de ter um legítimo PO.
Vou mostrar o que geralmente acontece em dois cenários distintos: projetos para grandes empresas e para pequenas empresas.
Grandes empresas
Quando temos nosso “gerente de projeto” dentro das grandes empresas, esse cara geralmente tem uma formação em TI e pós-graduação/mestrado/MBA/cursos de extensão na área de Gerenciamento de Projetos. OK, ele entende um pouco de software e também um pouco de PMI. Infelizmente, ele não PAGA pelo projeto, mesmo havendo cobrança de seus clientes internos, o dinheiro não sai do bolso dele. Esse é o que considero nosso pior cenário de trabalho pois, a mentalidade cascata (ou cascateiro) é predominante (com raras exceções). Argumentos por parte do cliente:
Como era de se esperar, não é um espanto haverem divergências de requisitos (e várias reuniões para discutir o assunto) no final do projeto. Mesmo tentando trabalhar de forma iterativa, isto é, apresentando o sistema em partes para esse gerente de projeto, no final, quem de fato vai usar o sistema, acaba por não participar dessas “entregas” parciais e acaba “mudando” de idéia quando vê o projeto terminado, meses depois que ele foi “concebido”. As palavras entre aspas nessa frase tem um significado muito relevante:
Resultado final: na maioria das vezes o projeto sai mais caro e demora mais que o previsto. Lembre-se que o escopo mudou e até hoje não vi nenhum projeto que não tenha mudado. A não ser que seja algo muito pequeno (entenda-se, projetos com menos de 300 horas ou 2 profissionais durante 1 mês).
Pequenas empresas
Pequenas empresas por outro lado não tem árvore de dinheiro e por isso tem que otimizar ao máximo cada centavo “gasto” em software. Por isso, não é nenhuma novidade que consigamos fechar projetos de escopo aberto com duração e custo fixo. Neste caso, conseguimos à cada apresentação para o cliente, ter um feedback exato se estamos mesmo indo no caminho certo. E, acreditem, na maioria das vezes o projeto vai para o ar antes daquele prazo inicial previsto terminar.
Aqui, de fato, conseguimos aplicar a cartilha de desenvolvimento iterativo de forma eficiente. Conseguimos fazer menos software, reduzir o time-to-market, gerar valor para o cliente e cultivar um relacionamento muito bom com os clientes.
–
Para concluir, segue um paralelo sobre custos e prazos (esta informação é empírica e baseada apenas na minha observação dos projetos no último ano):
Perfil dos projetos analisados: o prazo geralmente é de 3 a 4 meses para um volume de cerca de 1.500 horas. Nesses projetos trabalhamos com equipes de 3 a 6 pessoas envolvendo uma pessoa que faz o atendimento ao cliente, dois desenvolvedores plenos, um ou dois desenvolvedores júniors e um designer.
| Grande empresa | Pequena Empresa | |
|---|---|---|
| Tempo para primeira versão ir para o ar | 6 meses | 2 meses |
| Esforço para desenvolvimento da primeira versão | 1500 horas (ou mais) | 800 horas |
| Lucratividade para a consultoria (isto é, nós) | Alto risco, já houveram casos de prejuízos | Baixo risco, vários casos de sucesso |
| Fechamento de um contrato de “manutenção evolutiva” | Nem sempre | Quase sempre |
–
Para finalizar… Nem sempre é fácil usar princípios básicos que norteiam desenvolvimento ágil como neste caso, desenvolver de forma iterativa. Muitas vezes os projetos já começam no modelo cascata e, como somos consultorias que prestam serviço para esses clientes, não temos muito o que fazer para alterar o cenário. Neste caso, posso afirmar que seu cliente não é Ágil!
Obrigado para quem leu até aqui!! Fico à disposição para trocar idéias sobre o assunto. []‘s e boa semana!
Hoje de manhã saiu uma reportagem sobre o título deste post no Bom Dia Brasil da Globo. Após a reportagem o “inteligente” comentário de Mirian Leitão sobre o assunto. Minha mãe me comentou sobre isso na hora do almoço, mas não achei que fosse somente uma chamada e não uma reportagem “completa” como a que foi feita. Um pouco depois, li o artigo do Claudio Br comentando o assunto.
Me achei obrigado a comentar o assunto, então lá vai:
Primeiramente, o volume imenso de vagas abertas pra mim não representa uma realidade. Naturalmente o mercado de TI está bastante aquecido, mas há um exagero em se dizer que temos 100 mil vagas não preenchidas. Talvez o número real seja metade disso… Parece mais paupável.
Segundo, os famosos gerentes de RH e donos de empresa nunca entendem o real motivo de não encontrarem bons profissionais. Acham que balões coloridos, monitores grandes, estações de trabalho de última geração e um salário interessante é mais do que o bastante para “atrair” os melhores. Grande falha…
Os bons profissionais estão em busca de empresas que realmente fazem um bom trabalho. Eu não conheço muitos programadores que sonham trabalhar em uma fábrica de software com CMMi nível 5 e 40 funções (leia-se papéis no processo) diferentes. Os bons profissionais preferem um ambiente Ágil, multifuncional, multidisciplinar, onde uma pequena equipe de 6 pessoas consegue fazer mais e melhor que uma grande equipe de 20 pessoas “lideradas” por um gerente de projetos com um gantt chart em mãos e um cartão de ponto para bater.
E mais, grandes empresas raramente investem na comunidade, não tem um setor de Pesquisa & Desenvolvimento focado em software livre, em tecnologias inovadoras, em novos negócios ou qualquer outra área de realmente interesse bons profissionais. Novamente, não é um Wii, um escritório bonitinho, um computador bacana ou um salário bom que vai atrair os melhores profissionais. Pense que você está lidando com empreendedores, que tem um ideal sobre como fazer um bom trabalho, sobre como se divertir trabalhando, sobre como fazer o que tem que ser feito, independente de horário, local físico, idioma ou linguagem de programação.
Nada melhor que o comentário da Miriam Leitão dizendo que os “donos de empresa” reclamam da falta de concentração dos profissionais. Pra mim isso significa só uma coisa: Eles querem profissionais robóticos e disciplinados, meros fazedores de tarefas de programação da fantástica fábrica de software. E como já presenciei várias vezes, esse cara tem que resolver todos os problemas do mundo, afinal, ele é o técnico.
Já vi em grandes empresas um esquema de trabalho absurdo, onde existem mais gerentes que técnicos. Os gerentes tem a tarefa de justificar o motivo de tantos técnicos não conseguirem concluir suas tarefas. E os técnicos tem que abstrair um mundo maluco criado pelos gerentes com seus documentos de requisitos e cronogramas para comunicação. Nesse embate os projetos levam anos de desenvolvimento e não ficam prontos!! É incrível!!
Me desculpe se o tom foi um pouco pesado neste post. Mas não é possível continuarmos convivendo com essa mentalidade atrasada, que acaba por gerar um enorme descrédito da nossa área. Uma vez escutei uma piada que compara um programador com um marceneiro. A diferença é que o marceneiro há algum tempo tem cumprido seus prazos, agora, o programador…
Boa semana a todos!
Muito se fala sobre trabalho em equipe, equipe unida, uma equipe é melhor que um grupo, e outras buzzwords do tipo. Mas todos sabemos que nada substitui o valor de um time! E todo garoto desde cedo aprende que saber jogar video game é uma obrigação para todo candidato a nerd (no bom sentido da palavra)!
A imagem ao lado mostra claramente a motivação de dois times duelando entre si em um Barcelona Vs Real Madrid com o placar de 1 x 1. Detalhe: são 13:30 da tarde e eles estão em seu ambiente de trabalho.
Eu já havia me esquecido da última vez que algo assim tinha acontecido na empresa. Resgatei alguns arquivos e nos lembramos que isso foi há 2 anos atrás, em uma época que tínhamos uma equipe muito unida e rolava Diablo, Conter Strike ou um joguinho de corrida que era muito divertido, tanto no horário de almoço, quanto algumas vezes depois do expediente!
Todos participavam da jogatina e uma vez por semana (pelo menos) rolava um happy hour no posto ao lado da empresa, geralmente com a presença de quase todos! Nessa época também tínhamos capeonatos de Kart, Boliche, Sinuca e outras atividades para atletas de computadores. Me lembro até hoje da satisfação que tive quando toda a equipe se reuniu em uma sexta-feira para almoçar junto no dia do meu aniversário! Foi demais!
Detalhe importante: Nessa época não tínhamos reclamações da equipe, a rotatividade era baixa e com certeza a produtividade era maior. Com o tempo, algumas pessoas foram saindo, não rolou mais o Kart, Boliche, joguinhos na hora do almoço. E um detalhe importante, a produtividade geral caiu drasticamente e nunca mais tivemos um ambiente bacana como esse.
Aí muitos se perguntam: Qual o segredo do sucesso de uma equipe? Na minha opinião é: A equipe tem sucesso a partir do momento que age como Time! E formar um time não é nada fácil. Primeiramente, um time não é formado de estrelas (leia-se arquitetos de software super poderosos). Não adianta contratar os melhores e mais caros profissionais achando que você terá um time (a seleção brasileira de futebol está aí para provar isso).
Um time só é formado quando as pessoas se gostam, se ajudam, se admiram, se desafiam e principalmente, quando se divertem juntas. Eu ando falando há algum tempo sobre o projeto de Imersão Ágil que estamos implantando na empresa, dos resultados positivos que temos conquistado. O interessante é que o manifesto ágil não “prega” que devemos jogar vídeo game no horário de almoço, fazer happy hour uma vez por semana, promover campeonatos de atividades “esportivas” com frequência, ministrar treinamentos uma vez por semana, estimular as pessoas a se divertirem juntas!
Na minha opinião esse é o fator que gera mais resultado do que qualquer método (ágil ou não) que se possa inventar. O poder da química entre as pessoas não é uma coisa que se aprende. Ela acontece naturalmente, e você gerente/diretor/coaching/consultor/instrutor/professor/CEO pouco pode fazer para que isso aconteça senão fazer parte!
Ultimamente tenho postado algumas experiências com o uso de Cucumber para implementação de testes aqui e aqui. Dando continuidade, recentemente fiz um exemplo usando Cucumber + Webrat para testar uma aplicação web desenvolvida com CakePHP. A seguir vou explicar em linhas gerais como isso foi feito, sinta-se à vontade para deixar comentários sobre dúvidas ou críticas.
Antes de começar é indispensável instalar várias gems no seu ambiente. Para isso, siga este artigo que explica passo a passo tudo que deve ser instalado (e até um pouco mais).
Com o ambiente pronto, podemos começar. Na verdade, não criaremos uma aplicação Rails, mas sim, vamos agregar código Ruby na sua aplicação CakePHP. Após descompactar o esqueleto para aplicação Cake, vamos acrescentar o diretórios features que será usado para escrever as descrições dos testes (arquivos features/*.feature) e dos passos de teste (arquivos features/step_definitions/*.rb). Confira como ficará a estrutura do projeto no github. Me baseei neste artigo para configuração do ambiente, mas acabei retirando algumas coisas desnecessárias para esse exemplo, mas que podem ser úteis em projetos do mundo real.
Nosso caso de teste é um sistema de anúncio de veículos onde o anunciante deve entrar com CPF e senha para acessar a área administrativa e gerenciar seus anúncios. A história que vamos implementar trata-se desta autenticação. Abaixo segue a descrição do arquivo autenticacao.feature com todos os cenários de testes:
Perceba que mesmo um uma situação bastante simples, no nosso caso uma mera autenticação, temos vários cenários que devem ser testados para garantir que sua aplicação cumpra determinados requisitos do cliente. E agora seguindo a lógica do cucumber, temos que definir “step definitions” para as ações que estão sendo implementadas, que são: Dado que estou na página de autenticação, Quando digito “…” no campo “…”, Quando clico no botão “…” e Então vejo o texto “…” na tela. Diferente do outro artigo, desta vez, vamos implementar os step definitions usando webrat no lugar do selenium. O webrat não é executado em um browser, ele simplesmente simula o protocolo HTTP fazendo requisições conforme os parâmetros. Logo, é executado muito mais rápido que o selenium, mas não é eficiente para testar scripts client side. O arquivo webrat_steps.rb foi adaptado somente para usar o cucumber em pt-br:
No arquivo features/support/env.rb temos que fazer a inicialização do framework. Na linha 7, fiz uma adaptação para usar a versão 0.9.0 do mechanize para resolver uma warning explicada melhor aqui.
E por fim, temos o arquivo features/support/paths.rb que faz o mapeamento de algumas palavras usadas no arquivo .feature para URLs e nomes de campos. Repare que no método path_to estou usando o endereço http://cucumber.local, que é o nome do meu virtualhost onde está rodando a aplicação cake.
Não deixe de dar uma olhada na implementação em cake, onde foquei fazer o mínimo possível para os testes passarem mantendo assim o design e implementação simples. Leia também o artigo do Jefferson Girão que fala sobre como usar um MIX de selenium (para testes client-side) e webrat (para server-side) que vejo como uma excelente solução para os testes funcionais.
Espero que este exemplo seja útil pra vocês! Fique à vontade para deixar seus comentários.
Venho estudando um framework para Behavioral Driven Development chamado Cucumber e me impressionado com a facilidade e clareza que a atividade de implementar testes automatizados vem se tornando. Para quem quiser saber mais sobre Cucumber, antes mesmo de continuar essa leitura, recomendo consultar esses links:
O foco deste, é apresentar minha experiência em usar o Cucumber integrado com o Selenium e mostrar um exemplo de como é simples implementar testes funcionais. Para começar, leia essa documentação que explica como configurar seu ambiente. Se você usa MacOS Snow Leopard (10.5) deve passar pelos mesmos problemas que eu tive e que encontrei a solução neste link.
A idéia central é escrever estórias para teste de telas (caixa preta). Disponibilizei no github o código-fonte da aplicação em Rails que está sendo testada e de outra aplicação, somente Ruby, usando Cucumber + Selenium. Para demonstrar o uso do Selenium, escolhi um cenário bastante simples, trata-se de um história de autenticação de usuários:
Perceba que nos preocupamos em escrever a história o mais “User Friendly” possível. Isso facilita bastante o entendimento sobre o que você está de fato testando e o que o seu usuário (ou cliente) acha que você deveria testar. E, como você já deve saber, as palavras-chave “dado”, “quando” e “então” representam ações que são implementadas em Ruby. Para começar, configuramos no arquivo support/env.rb o ambiente da API para Selenium em Ruby criando uma instância da classe Selenium::SeleniumDriver.
No arquivo support/paths.rb configuramos o mapeamento de nome de páginas para URIs e também de label de campos para o nome do campo no formulário HTML. Os métodos path_to, field_for e button_for fazem essas funções.
OK, concordo com vocês que essas funções não fazem lá muita coisa, mas lembre-se que estamos fazendo o nosso primeiro caso de teste, tenha certeza que serão úteis no futuro próximo. Um exemplo que eu já posso citar foram os testes que implementamos para testar uma aplicação, na verdade um portal, desenvolvido em Drupal, onde o “label” dos campos não era nem um pouco parecido com o nome (do componente HTML) do campo. Lembrando que as histórias tem de ficar o mais próximo possível da taxonomia (ou idioma) do seu usuário.
Agora, vamos à parte que interessa, de fato a implementação dos passos descritos nas estórias. Criei o arquivo step_definitions/common_steps.rb contendo os passos mais comuns que você deverá usar na maioria de suas estórias. Para passos específicos de determinada história, recomenda-se criar um outro arquivo no diretório step_definitions com o nome da estória.
O exemplo é bastante simples, e a aplicação Rails do github contém uma implementação bastante simples do que está sendo testado. Para executar, basta usar o comando “cucumber” na raiz do projeto de testes. Lembrando que você deve iniciar o servidor do Selenium usando o comando “selenium” (isso funcionou pra mim após instalar o Selenium RC).
Se você tiver dúvidas ou problemas na execução do exemplo, fique à vontade de postar nos comentários que farei o possível para tentar ajudar. E, por hora ficamos por aqui. Em breve devo postar alguns exemplos de passos mais complexos como uso de tabelas e/ou editores ricos. Estamos trabalhando nisso agora!
Neste final de semana finalmente participei do segundo encontro presencial na UFLA (Universidade Federal de Lavras) para conclusão do curso de Especialização em MPS (Melhoria do Processo de Software) que iniciei em 2006. O encontro foi extremamente produtivo visto que havia poucos alunos e com isso temos a oportunidade única de ter consultorias ao invés de aulas com professores de altíssimo nível. Fora que com pouca gente a interação entre os alunos foi infinitamente maior o que com certeza vai promover amizades produtivas.
No sábado eu tive a oportunidade de apresentar meu Trabalho de Conclusão de Curso que trata-se de um artigo entitulado: Gerenciando Projetos de Escopo Aberto – Uma Visão Ágil. Ainda tenho alguns ajustes para fazer, mas já disponibilizei uma prévia do trabalho em PDF e depois atualizo esse post com a versão final (para fazer o download clique no link do nome do trabalho).
É uma pena esse curso ter acabado. Mas já deixo a recomendação de outro curso, na verdade um MBA, que tem como coordenador um dos professores. Trata-se do MBA Gestão da Qualidade em Software com ênfase em CMMI® e MPS.BR da FIAP, e o coordenador é o sensacional Nilson Salvetti.
Como voltei bastante animado do encontro, em breve devo publicar, em parceria com alguns colegas, artigos que estamos preparando sobre teste de integração e gerenciamento de projeto “agile”. Pode me cobrar se eu não enviar! Estou até animado a embarcar em um mestrado na área de Engenharia de Software, e aceito recomendações!
Planejar e controlar projetos de software são atividades que boa parte das empresas tem conseguido desempenhar em seu processo de desenvolvimento. Porém, medir qual desenvolvedor é mais produtivo, re-alimentar o processo de estimativa e coletar informações para tomada de decisão quando o projeto “sai dos trilhos” é uma tarefa bastante complicada. Neste artigo, vou apresentar a experiência que implantamos na área de Produção de Software da Agence para medição da produtividade. Qualquer planejamento de projeto de software é elaborado com base em uma estimativa, especialmente em “Fábricas de Software” que muitas vezes trabalham com projetos de escopo fechado e orçamento pré-definido. Na Agence, usamos basicamente três métodos para estimar o tamanho de um projeto: Para pequenos projetos, inferiores a 300 horas, usamos uma Planilha de Estimativa onde são estimadas horas de trabalho para cada uma das disciplinas da Engenharia de Software (análise e projeto, requisitos, codificação, testes, implantação, etc.). Este método é bastante simples, mas exige experiência do profissional que faz a estimativa, é bastante suscetível a falhas e é calçado em um histórico de experiências anteriores do mesmo tipo. Para projetos maiores, usamos contagem de Pontos por Função e/ou de Pontos por Caso de Uso. Esses métodos têm o embasamento científico de várias pesquisas com projetos de empresas diferentes e devem ser calibrados pela complexidade e natureza do projeto e também pela qualidade da equipe. Com a estimativa em mãos, é hora de planejar o projeto. Na Agence trabalhamos com o modelo Iterativo e Incremental de ciclo de vida. Logo, a primeira fase do planejamento é definir as iterações do projeto e quais artefatos serão entregues em cada uma. Seguindo o princípio do Unified Process (UP), temos quatro fases no ciclo de vida do projeto: Iniciação, Elaboração, Construção e Transição. A fase de Iniciação na maioria dos casos refere-se à prospecção do projeto junto ao cliente e não possui um planejamento formal. Nesta fase o Consultor de Negócio (figura do Analista de Requisitos) entrevista o cliente, documenta os requisitos e prototipa a solução. Nesta fase o projeto é estimado e uma proposta apresentada ao cliente. Se o cliente aprovar, o projeto continua. Na fase de Elaboração, o planejamento do projeto como um todo é elaborado. Além disso, o Modelo de Casos de Uso é detalhado e a Arquitetura da Solução é desenvolvida. Nesta fase, existe uma maior participação do Gerente de Projeto, Analista de Requisitos e Arquiteto. A partir da fase de Construção que o trabalho pesado começa. Nesta fase, há sempre uma versão utilizável do sistema (ou incremento) produzida por mês, independente do tamanho do projeto ou da equipe. Essa entrega da versão formaliza o término de uma iteração e início de outra. Na fase de Transição, o software é instalado em ambiente de homologação/produção e avaliado pelo cliente e usuários final. Muitas vezes são executados testes de carga e stress, projetos pilotos da operação do sistema e treinamentos. Diariamente, os profissionais fazem seu trabalho e registram as horas gastas em uma ferramenta de controle de projetos. No final de cada iteração o Gerente de Projeto mede os registros de trabalho dos profissionais e compara com os valores inicialmente estimados. Naturalmente, o cliente fará uma avaliação da versão entregue no término da iteração e novas pendências podem aparecer. O tempo para os ajustes geralmente está contabilizado na estimativa para o desenvolvimento da funcionalidade. Mas o ponto é, para medir a produtividade, é necessário dividir a quantidade de horas de trabalho pelo tamanho em pontos (de função ou casos de uso) da funcionalidade. Por exemplo, se o desenvolvedor codificou uma funcionalidade que totaliza 5 pontos de função (PF) em 40 horas (h), sua produtividade é de 40 h / 5 PF = 8 h/PF (lê-se quatro horas por ponto de função). Desta forma é possível obter uma produtividade média da equipe e avaliar os desenvolvedores que têm um desempenho menor ou maior. É importante salientar que quando a estimativa é feita, é normal que se tenha 12 h para cada PF. Esse tempo, porém, é dividido entre todas as atividades do processo de desenvolvimento: codificação, testes, análise e projeto, requisitos, gerenciamento, implantação, etc. Logo, se for considerado apenas o tempo de codificação, consideramos de 40 a 50% do tempo estimado para cada PF. Assim, uma funcionalidade que tenha 2 PF, com a relação de 12 h por PF na estimativa, não pode gastar mais que 12 horas com codificação, incluindo os ajustes solicitados pelo cliente. Logo, um desenvolvedor com a produtividade de 8 h/PF não é uma boa média, que será, no máximo, 6 h/PF. De posse dessas informações, é possível, já inicio do projeto, tomar atitudes para evitar atrasos no cronograma ou prejuízos financeiros. No término no projeto, essas informações servem de base para próximas estimativas, definido um fator de horas por ponto de função ou de caso de uso aplicável para a empresa em determinados tipos de projetos. Em um próximo artigo, vou apresentar uma forma de medir produtividade na prática usando a ferramenta Jira. Para quem não conhece, o Jira é uma ferramenta paga, porém com preço bastante acessível, para controle de pendências e gerenciamento de projetos. Até lá!Primeiro Passo: Estimativa
Segundo Passo: Planejamento
Terceiro passo: Controle
E na prática?
Um cidadão chamado Mateus Velloso resolver falar mal de CMMI. Ele é louco? (Deixo a resposta para vocês…). Leia o artigo na íntegra.
Essa semana trabalhei na integração de um sistema em Delphi com um site em PHP & MySQL e resolvi escrever um artigo relatando os diversos problemas ocorridos e quais soluções optei por utilizar.
O artigo está disponível para download aqui.