Scrum e Estratégia
Se Scrum é completamente sobre curto prazo, como os caras da estratégia trabalhariam neste ecossistema?
Rastreando mudança e inovação na comunidade de desenvolvimento de software corporativo.
Postado por Chris Sims , traduzido por Wagner R. Santos em 19 Jan 2009 11:53 AM
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.
Se Scrum é completamente sobre curto prazo, como os caras da estratégia trabalhariam neste ecossistema?
Este artigo explica o porquê a adoção de Agile falha em algumas organizações.
Esse artigo apresenta o seguinte autoquestionamento: Eu seria liderado por mim mesmo? Essa é uma pergunta direta, porém,respondê-la é enormemente complicado.
ORMs estão na moda nos dias de hoje por uma boa razão: eles podem fazer o desenvolvimento de aplicações baseadas em banco de dados rápido e sem dor.
Os novos conhecimentos em neurociência (neurociência social, psicologia positiva e técnicas de imagem) nos dão ferramentas para entender e ampliar a habilidade de homens e mulheres trabalharem juntos.
Esse texto almeja gerar uma reflexão na forma como os times estão tratando os impedimentos que aparecem em seu cotidiano.
Este artigo aborda os desafios para adoção de métodos ágeis dentro da empresa e as estratégias para enfrentá-los.
Gerenciar a produtividade e o cronograma em um projeto é sempre um desafio devido à complexidade na tomada de decisões. Neste artigo, tentamos usar o gráfico burndown para endereçar este problema.
1 comentário
Acompanhar Discussão Responder