Início Programação em Par no InfoQ Brasil
Notícias
Feed RSS-
Como programação pareada funciona
Stuart Wray escreveu um artigo analisando como a programação pareada realmente funciona em ambientes de desenvolvimento e identificou quatro mecanismos que podem ser aplicados para melhorar a eficácia da programação pareada, e porque ela resulta em produtos com mais qualidade.
-
PairWithUs: Vídeos de Exemplos de Desenvolvimento Ágil de Software Por Demanda
Uma coisa muito conhecida pela maioria dos programadores é que o melhor (único?) caminho para aprender uma técnica de programação é pelo exemplo; especificamente, vendo alguém fazer algo. Antony Marcano & Andy Palmer, em seu site PairWithUs dão boas razões às pessoas para fazerem isso.
-
Precisamos ser mais Psicólogos que Engenheiros para ter Sucesso com Engenharia de Software
Einstein certa vez afirmou que se ele tivesse uma hora para salvar o mundo, gastaria 55 minutos definindo o problema e apenas cinco minutos buscando a solução. Exceto pela proporção do tempo dedicado ao problema e à solução, concordo inteiramente com a importância que Einstein dava ao entendimento do problema antes de partir para a resolução do mesmo.
-
Economizando com Programação em Par
Porque alguém utilizaria duas pessoas para fazer o trabalho de uma? Esta é uma reação comum quando as pessoas são apresentadas a ideia da programação em par. Eles concluem programação em par como duplicar o custo de escrever um segmento de código. Dave Nicollete demonstra algumas ideias quantitativas para ajudar a mostrar como a programação em par pode salvar dinheiro, ao invés de desperdiça-lo.
-
Como TDD e Pareamento Aumentam a Produtividade
"Desenvolvimento orientado a testes" (TDD) e "Pareamento" são duas das práticas ágeis mais conhecidas, e mesmo assim não são postas em prática por muitas equipes ágeis. Com frequência, as pessoas afirmam estar "muito ocupadas" para praticarem TDD e pareamento; em essência, deixando a entender que esforçar-se para produzir um código de alta qualidade reduz a produtividade.
-
Uma Velocidade Boa
Há pouco tempo, Buddha Buck perguntou na lista de Extreme Programming se existe uma média de velocidade que poderia ser considerada boa para uma equipe de sete pessoas que realiza iterações de duas semanas. Ele sentiu que uma velocidade de oito pra baixo indicaria que as estórias estariam muito grandes. A discussão em torno do tema conseguiu responder a essa e a outras questões decorrentes também.
-
Uma Abordagem Ágil para Reutilização de Código
Uma discussão recente na lista de Extreme Programming do Yahoo Groups explorou o conflito aparente entre desenvolver software reutilizável e a prática do XP de não escrever o código até que ele seja necessário. Ron Jeffries e outras pessoas compartilharam suas idéias sobre os custos e benefícios da reutilizacão de código, além de como e quando colocá-la em prática em um ambiente Ágil.
-
Modelos de aprendizado
De acordo com o Cambridge Dictionary um aprendiz é "alguém que trabalha para um expert com a finalidade de aprender um trabalho ou habilidade específica". O Merriam Webster diz: "alguém que está aprendendo através de experiência prática sob o comando de trabalhadores habilidosos, um negócio, arte ou chamado".
-
Adotando o "Bolo" Inteiro
Recentemente a InfoQ informou sobre o popular artigo do Jim Shore O Declínio e a Queda do Agile, que destacou a tendência das organizações adotarem "Agile" (no nome) mas falharem ao adotar Agile (na prática).Os líderes da comunidade como Martin Fowler, Joshua Kerievsky, Ron Jeffries, levaram a declaração inicial de Shore a alguns passos além, postando seus pensamentos sobre o que está acontecendo.
-
A viagem de um homem numa Jornada com Pair Programming
Corey Haines recentemente embarcou em "uma excursão de Pair Programming" de uma única pessoa na região central dos EUA. Agora, Haines postou um vídeo de entrevistas revelando muitos dos insights que conseguiu sobre pares, testes automatizados e a evolução do conceito de “artesão de software” enquanto compartilha o teclado nas casas de Dave Chelimsky, Brian Marick, Uncle Bob Martin entre outros.
-
Queime as estórias não as tarefas
Desenvolvedores geralmente quebram a estória do usuário em tarefas para facilitar o trabalho de distribuição e implementação em torno da equipe e permitir um acompanhamento dos processos em um nível fino de granularidade. Infelizmente, a estória pode explodir em uma lista de tarefas não triviais tão grandes que a estória não é entregue no fim da iteração.
-
Programação em Par vs Revisão de Código
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.
-
Lidando com os “Rotten Apple” da sua equipe
Recentemente em um debate no Grupo Scrum Development do Yahoo Grupos sobre o que fazer quando uma pessoa da sua equipe está tendo "baixo desempenho". Na thread de mais de 130 respostas, "Rotten apple in Scrum team", a discussão variou de conselhos até a questão principal, até o debate clássico da medição de indivíduos, para distinguir se uma equipe é realmente uma "equipe", e mais.