Formando equipes de alto desempenho, parte 1: Início e fases de evolução
Nesta primeira parte de uma série sobre equipes de alto desempenho e gerenciamento Agile, veja uma introdução geral e uma apresentação dos estágios de formação das equipes.
Disseminando conhecimento e inovação em desenvolvimento de software corporativo
O conteúdo foi adicionado aos favoritos!
Houve um erro ao adicionar aos favoritos! Por favor, tente novamente.
Postado por Chris Sims , traduzido por Wagner R. Santos em 19 Jan 2009
Programação em Par e Revisão de Código são práticas que aumentam a qualidade do software, assim como promovem a disseminação do conhecimento. Enquanto os debates Agile vs Lean, XP vs Scrum e vi vs Emacs andam em marcha lenta, desenvolvedores são conhecidos por debater os méritos da programação em par vs revisão de código. Theodore Nguyen-Cao descreveu revisores de código como galinhas, e programadores em par como porcos.
A história da galinha e do porco é geralmente discutida no circulo dos agilistas. Quando é para fazer um café da manhã com bacon e ovos, a galinha é envolvida mas o porco é comprometido.
Desta maneira, o termo ‘porco’ tem sido utilizado para descrever aqueles que são totalmente comprometidos para um dado empreendimento. O termo ‘galinha’ é utilizado para descrever aqueles que são envolvidos, mas cuja responsabilidade é menor.
Em revisões de código, as pessoas sentam para revisar o código de outra pessoa. Todo mundo possui uma opinião mas nem todos irão trabalhar com o código em uma base diária. Em dado momento, todos parecem estar envolvidos no processo, mas não há um interesse real. Eles estão apenas olhando para um monte de código e perguntando a si mesmos “será que este código está bom e correto?” É uma visão muito passiva. Por outro lado, programadores em par estão completamente interados (comprometidos?) na tarefa da vez. Eles imediatamente estão utilizando o código que eles estão escrevendo em conjunto e compartilham suas idéias em relação ao design, layout do código, etc. Ambos programadores estão tomando um papel ativo e estão emocionalmente envolvidos na tarefa da vez pois estão atacando o mesmo problema juntos.
Theodore também apontou que o ciclo de feedback é muito melhor durante a programação em par do que durante a revisão de código. Durante a programação em par, os desenvolvedores escrevem, inspecionam, e alteram o código continuamente. Em uma revisão de código, em contraste, envolve inspecionar o código posteriormente, geralmente quando o autor pensa que ele esta pronto para deployment.
É geralmente aceitável que o custo de um bug de software suba drasticamente, talvez exponencialmente, conforme o tempo entre a introdução e a correção suba. Por esta métrica, bugs pegos durante uma sessão de programação em par custa muito menos do que aquelas pegas durante uma revisão de código. É claro, que para qualquer um dos dois o custo é muito menor que permitir que o bug seja liberado antes que seja pego. Talvez isto pague fazer os dois.
Você prefere programação em par, revisão de código, ambos, ou nenhum? Deixe um comentário e compartilhe suas idéias.
Nesta primeira parte de uma série sobre equipes de alto desempenho e gerenciamento Agile, veja uma introdução geral e uma apresentação dos estágios de formação das equipes.
O Business Model Canvas é uma ferramenta estratégica para a construção visual de novos produtos ou serviços. Conheça cada um dos seus elementos e como preencher o Canvas, passo a passo.
Nessa segunda e última parte de uma série sobre o Google Apps Script, conheça como funciona o envio de emails, a conversão de documentos e como criar menus e triggers.
Este artigo avalia seis dos mais importantes fornecedores de serviços de cloud computing PaaS para desenvolvedores Java, analisando critérios como desempenho, escalabilidade e tecnologias suportadas.
O Canvas de Modelo de Negócios é um novo modo de comunicar e suportar a validação iterativa, incremental e empírica de modelos de negócio de startups e novos produtos substituindo o plano de negócios.
Nesta segunda e última parte de uma entrevista exclusiva para InfoQ Brasil, Rebecca Parsons, CTO da ThoughtWorks, fala sobre o Agile Distribuído e técnicas para definição de arquiteturas.
Nessa primeira parte de uma entrevista com a CTO da ThoughtWorks, veja recomendações sobre formas de construir e arquitetar sistemas para obter o máximo de flexibilidade e responsividade a mudanças.
Os gerentes de projetos podem assumir o papel crítico de liderar a introdução do Agile. Vejas conceitos, dicas e técnicas para apoiar esse processo de mudanças.
1 comentário
Acompanhar Discussão Responder