Image Image Image Image Image
Scroll to Top

Topo

desenvolvimento agil

13

jan
2014

Sem Comentários

Em Blog
Destaques
Vídeos

Por Mike Lopes

SWX Direto da trincheira 01 – Desenvolvimento Ágil, Startup e Elite Áudio Studio

Em 13, jan 2014 | Sem Comentários | Em Blog, Destaques, Vídeos | Por Mike Lopes

Neste SWX direto das trincheiras trazemos as primeiras novidades da SWX em 2014. Se você ainda não viu, clique e confira:

Este artigo discute a importância crescente da metodologia de desenvolvimento ágil frente à computação nas nuvens e ao big data, tornando tal metodologia uma necessidade e não mais um diferencial.

O primeiro podcast da SWX traz um tema que conhecemos muito: Startups. Neste episódio debatemos as características de uma Startup e relacionamos este modelo de negócio com outros e com fatos históricos.

Um dos primeiros clientes do CIO Market que utilizando nossa plataforma de Ecommerce (14Commerce) já está com sua loja no ar.

Tags | , , , , ,

Seja ágil ou seja esmagado!

Em 11, dez 2013 | Sem Comentários | Em Agile, Cloud Computing, Destaques | Por Mike Lopes

agile-cloud

Desenvolvimento Ágil não é mais uma forma alternativa de desenvolver software. Com o ritmo de adoção de tecnologia acelerando em um ritmo frenético, desenvolvimento ágil está se tornando a única forma de desenvolver software. Isto é, se você quiser permanecer no, mercado.

Baixando a expectativa a cada release

Desenvolvimento ágil de software refere-se essencialmente a um processo incremental e iterativo de desenvolvimento de software, em oposição à velha escola do método “cascata”, que dependiam de um planejamento inicial de longa duração. Desenvolvimento Ágil pressupõe que os projetos de TI frequentemente falham, apesar de nossas melhores intenções. Ele é, consequentemente, uma forma de minimizar o custo de falhas fazendo com que o processo de desenvolvimento de software seja altamente sensível a alterações.

E, embora o desenvolvimento ágil possa ter sido exclusividade das empresas de tecnologia com pouca burocracia, notadamente as que desenvolvem de aplicações móveis ou web de ponta, ele tem ido agora para o mainstream. Como analista da Forrester Diego Lo Giudice observa:

Within the modern applications era, regardless of whether new software applications are being developed and delivered for mobile, tablets, or the Web, the truly successful app-dev leaders will be those who focus on delivering constant value and incremental improvement to their business. (Na era aplicações modernas, independentemente se novas aplicações de software estão sendo desenvolvidos e entregues para dispositivos móveis, tablets, ou para a Web, os desenvolvedores verdadeiramente bem sucedidos serão aqueles que se concentrarem em entregar valor constante e melhoria incremental para seus negócios.)

É importante ressaltar que as razões para abraçar o desenvolvimento ágil é tanto em razão do antigo método conservador e tedioso quanto o aumento de velocidade de desenvolvimento, como eu ouvi de um executivo da empresa de um (muito) grande serviços financeiros:

OH: “Product stability comes from releasing code more frequently, not less. You want each release to be a non-event, not a major launch.”

— Matt Asay (@mjasay) October 2, 2013

Os tempos estão mudando

Este tipo de abordagem iterativa para o desenvolvimento de software tem sido sempre uma boa ideia, mas está se tornando crítica com a mudança tecnológica e aumento de adoção, como Harvard Business Review mostra:

Tech Adoption Increasing

Tal aumento da adoção, por sua vez, é, sem dúvida conduzido por uma infraestrutura muito mais flexível, particularmente de software. Software de código aberto oferece um enorme conjunto de softwares de qualidade a partir do qual os desenvolvedores podem projetar os seus, uma vez que o hardware acessível por meio das nuvens (Infrastructure-as-a-Service -IaaS) torna trivial para escalar vertical e horizontalmente.

Com isto em mente, o mais novo de dados do Synergy Research Group sobre a adoção de IaaS é tão interessante tanto não porque demonstra que a Amazon domina completamente o mercado, o que nós sabíamos, mas porque mostra o crescimento em todos os principais provedores de nuvem:

iaas-paas-q313-release

Seja qual for o seu provedor, então, a infraestrutura existe para acelerar o desenvolvimento.

Big Data Exige uma abordagem ágil

Isto é particularmente importante em novas áreas de exploração, como Big Data. Como mostra a pesquisa da Gartner, as empresas estão obcecadas em começar com Big Data, mas muitas vezes não têm mais que de uma pista sobre como lidar com esses projetos.

Big Data é novo, e vamos enfrentá-lo: a maioria das empresas provavelmente irá falhar quando começarem seus projetos. Afinal, é quase garantido que as empresas não sabem quais dados capturar, ou a forma de aproveitá-lo, sem tentativa e erro. O desenvolvimento ágil, consequentemente, torna-se crítico para um projeto que venha a falhar, uma vez que tal abordagem reduz o custo de falhas, tanto em termos de tempo e dinheiro.

Isto poderia ser feito em uma abordagem em cascata tradicional? Claro. E muitas empresas quase certamente irão abordar o Big Data e outros projetos dessa maneira, porque eles simplesmente não conhecem nada melhor. Mas não seja essa empresa, ou esse desenvolvedor. O desenvolvimento ágil não é um Santo Graal que vai resolver todos os problemas de um desenvolvedor, mas é uma forma astuta de acompanhar a inovação tecnológica (como o Big Data) e para resolver projetos de desenvolvimento em larga escala.

Fonte: ReadWrite

Tags | , ,

10

abr
2012

Sem Comentários

Em Agile
Blog

Por Allison

Precisamos de uma metodologia mais ágil

Em 10, abr 2012 | Sem Comentários | Em Agile, Blog | Por Allison

Fonte: Fabio Camera/IMasters


Desde o princípio, em qualquer relação humana, o indivíduo organizado serve de exemplo, estimula e ensina ao indivíduo menos organizado. É assim com as crianças em relação aos adultos. É assim nas corporações quando inicia um novo funcionário inexperiente. Quem está aberto para crescer sempre busca aprender um método mais eficiente com alguém qualificado.

Dessa afirmação já se justifica a utilidade funcional de uma metodologia. De forma simplista, podemos traduzir metodologia como uma proposta particular de organização de métodos úteis e funcionais a mais de um indivíduo para uma determinada situação.

Nesse contexto, qualquer metodologia é perfeita. Se já funcionou para uma situação específica, depois foi documentada e agora pode ser utilizada por mais pessoas – é uma metodologia perfeita. É uma experiência similar ao princípio do método científico em sua finalidade.

Porém, muitas corporações, muitas equipes falham em atingir resultados satisfatórios com a utilização de uma metodologia. Onde está o problema? Nas pessoas? Na corporação? Na cultura? Muitas iniciativas frustradas têm uma explicação muito simples para o insucesso: quando não se tem a menor ideia daquilo que se está procurando, fica difícil encontrar.

Por que precisamos de um método ágil?

Recentemente, abordei esse assunto com um competente gestor de projetos que veio trabalhar em nossa empresa. Eu sabia que ele havia implantado na empresa anterior e eu precisava descobrir a motivação e os problemas para os quais ele buscava soluções.

Ele citou que o maior problema é que todos faziam a mesma coisa todos os dias, e o problema se tornava maior, ao invés de diminuir. Imagine uma rotina diária: cansativa – aquela ferramenta, aquela linguagem para o mesmo sistema, quase sempre entediante, certamente monótona pela ausência de oportunidades. O mesmo trabalho, as mesmas pessoas, e o que era antes uma vocação tornou-se somente um trabalho como outro qualquer.

Antes de tentar um método ágil, esse gestor acreditava que o problema estava no controle – ou melhor – na falta de controle. Com isso, aumentava a “pressão” por resultados no time, de vez em quando aumentava o time, frequentemente aumentava a quantidade de horas de trabalho diária, entretanto os resultados não se mostravam muito diferentes do que já eram.

Eu o questionei a respeito desta compreensão: se ele entendia que precisava fazer algo diferente, se esperava por resultados diferentes, por que havia resistência à proposta da metodologia ágil?

Resposta do gestor:

Nas iniciativas de implantação de Agile que presenciei ou das quais participei, a maior resistência era o medo de “perder o controle” sobre a qualidade do resultado do projeto. De alguma forma, alguns envolvidos acreditavam que o uso de metodologias ágeis resulta em um produto de baixa qualidade ou que não atende às expectativas.

Por fim, essa falsa crença foi justamente um dos motivadores para encarar o desafio na empresa que implantei. Ter a oportunidade de mostrar que o resultado seria justamente o oposto fazia o esforço mais compensador.

Ao analisar um ambiente que adotou uma metodologia ágil, após longos períodos de utilização de uma metodologia convencional, é possível observar diversos ganhos, dentre os quais destaco:

  • Maior produtividade: Entregar mais em menos tempo. Evitar desperdiçar o tempo com o que não é importante. Em ambientes mais engessados, perdemos muito tempo com um processo burocrático e por vezes ineficiente;
  • Entregas constantes: Proporcionar feedback de todos, dos clientes, dos usuários, dos contratantes e etc., com frequência;
  • Mais qualidade: Menor número de retrabalho e defeitos. Código com melhor “manutenibilidade” e escalabilidade;
  • Maior envolvimento do time: As reuniões diárias e as outras interações sugeridas pela metodologia ágil fizeram o time funcionar como time. Todos se conheciam, sabiam aonde podiam chegar.

Fazendo o mesmo comparativo com um ambiente que antes não seguia metodologia alguma, os ganhos também são expressivos: maior visibilidade, melhor comunicação e enorme incremento de qualidade.

Dessa forma, encontrei a resposta para a minha intenção com esse gestor. Com essas informações, concluí que sem novidade de meios (ferramenta ou linguagem), somente ordenando de uma forma diferente o “como” você faz diariamente, somente utilizando uma técnica diversa ao seu cotidiano, possivelmente podemos alcançar um fim novo.

O hábito que o sujeito carrega dentro de si para o trabalho, com o tempo, torna-se o seu maior algoz, o seu maior limitante. Impede-o de verificar novas opções, alternativas diversas. Implantar mais controle para mudar os resultados é automatizar um ser humano. É como se transformássemos um desenvolvedor em um robô. E como se medíssemos um programador como um atleta, buscando fazer cada vez mais rápido a mesma coisa.

A proposta de uma metodologia deve melhorar a comunicação, a interação entre os partícipes, a sinergia entre expectativas e os resultados. Afinal, processos fabris no universo da informática não deveriam ser “uma linha de montagem” em que pessoas ficam isoladas em suas mesas e computadores conectadas à internet, e ao mesmo tempo desconectadas com o projeto.

Infelizmente, nossos desenvolvedores são formados à margem dessa proposta de comunicação e interação. Um desenvolvedor nunca é estimulado a ser comunicativo ou a trabalhar em equipe de verdade. Na escola superior de ciência da computação, recebe uma educação matemática robótica que o estimula a se tornar um introspectivo cientista lógico.

O que esperar de uma metodologia ágil?

Um critério, válido, que podemos utilizar para definir se uma metodologia nos ajuda ou nos atrapalha em nosso dia-a-dia é a visibilidade que os problemas alcançam. Se somente o time do trabalho sabe/soube dos problemas e para os clientes ficou imperceptível, certamente a metodologia usada está sendo funcional.

Outro critério é a versatilidade das técnicas. Se há baixa aderência com a cultura existente e não há espaço para adaptações, a imposição da disciplina rígida nos proporcionará resultados comportamentais indesejados, como a resistência a mudanças pelas pessoas. O segredo nesse ponto é nunca perder de vista a razão de ser do trabalho, da empresa e de sua cultura. A metodologia deve propor técnicas para incrementar isso, não trazer razões contrárias. Numa metodologia inflexível, com restrições em excesso, você para de pensar no que pode fazer para se preocupar com o que não pode fazer. Se há uma imposição de seguir tudo o que está em manuais para o seu projeto, muita coisa escapará do que está escrito e ninguém saberá o que fazer.

Mais um critério que considero muito válido é o da análise do resultado. Os métodos sugeridos pela proposta metodológica devem trazer uma compreensão real sobre a capacidade de realizar e a capacidade de coordenar um grupo a um único escopo. É conduzir um projeto através de técnicas que não permitam dúvidas sobre o valor, o mérito e a expectativa de sucesso. No fim, sucesso é uma convenção social do grupo que definiu o escopo. O que é inicialmente pensado como sucesso para o time pode não ser sucesso para os contratantes ou para os clientes. A metodologia ágil ensina técnicas para se obter o critério de sucesso de um projeto.

Para não alongar demais com sugestões de critérios, concluindo de forma mais generalista, entretanto muito completa, podemos nos utilizar dos valores do Manifesto Ágil. Ele foi escrito por Kent Beck, James Grenning, Robert C. Martin, Mike Beedle, Jim Highsmith, Steve Mellor, Arie Van Bennekun, Andrew Hunt, Ken Schwaber, Alistair Cockburn, Ron Jeffries, Jeff Sutherland, Ward Cunninghan, John Kern, Dave Thomas, Martin Fowler e Brian Marick

O Manifesto Agil contém quatro valores fundamentais:

  • Os indivíduos e as suas interações acima de procedimentos e ferramentas;
  • O funcionamento do software acima de documentação abrangente;
  • A colaboração dos clientes acima da negociação de contratos;
  • A capacidade de resposta a mudanças acima de um plano pré-estabelecido.

Referência Bibliográfica:

  • MENEGHETTI, A. A Psicologia do Líder. 4ª. Edição. Recanto Maestro, RS: Ontopsicologica Editrice, 2008.
  • MENEGHETTI, A. Sistema e Personalidade. 3ª. Edição. Recanto Maestro, RS: Ontopsicologica Editrice, 2004
  • HEWARD, L. Cirque Du Soleil – A Reinvenção do Espetáculo. 8ª. Edição. São Paulo, SP: Elsevier Editora, 2006
  • ANDERSON, D. Agile Management for Software Engineering. 2ª. Edição. New York, NY: Prentice Hall Editora, 2004

Tags | , , ,

20

dez
2011

Sem Comentários

Em Agile
Blog

Por Allison

Scrum o que realmente é

Em 20, dez 2011 | Sem Comentários | Em Agile, Blog | Por Allison

O Scrum é um processo de gestão e desenvolvimento ágil que se desenvolveu como uma abordagem iterativa e incremental para otimizar a previsibilidade e controle de riscos, fortemente sustentado por três pilares:

  • Transparência: garante que aspectos do processo que afetam o resultado devem ser visíveis para aqueles que gerenciam os resultados;
  • Inspeção: diversos aspectos do processo devem ser inspecionados com uma frequência suficiente para que variações inaceitáveis no processo possam ser detectadas;
  • Adaptação: se um ou mais aspectos do processo estão fora dos limites aceitáveis e que o produto resultante será inaceitável, o inspetor deverá ajustar o mais rápido possível o processo ou o material sendo processado.

A metodologia Scrum consiste em um conjunto formado por Times e seus papéis, Time-Boxes, Artefatos e Regras. Os Times de Scrum são projetados para otimizar flexibilidade e produtividade, são auto-organizáveis, multidisciplinares e trabalham com iterações. Um Time de Scrum conta com três papéis definidos:

  • o ScrumMaster: responsável por garantir que o processo seja seguido e compreendido por todos, trabalhando na remoção de impedimentos, incentivando e levando a equipe a ser mais produtiva e garantindo a qualidade do código gerado;
  • o Product Owner: é a única pessoa responsável pelo gerenciamento do Product Backlog e por garantir o valor do trabalho realizado pelo Time. Deve manter a lista de prioridades sempre atualizada com as tarefas de maior valor de negócio.
  • o Time: são os desenvolvedores que transformam o Product Backlog em incrementos de funcionalidades potencialmente entregáveis em cada Sprint. Frequentemente possuem conhecimentos especializados, como programação, controle de qualidade, análise de negócios, arquitetura, etc. Cada membro do time aplica sua especialidade a todos os problemas. A sinergia que resulta disso melhora a eficiência e eficácia do time como um todo.

Reuniões de Planejamento da Release, a Sprint, Reuniões de Planejamento da Sprint, a Revisão da Sprint, a Retrospectiva da Sprint e a Daily Scrum estão incluídos nos Time-Boxes da Scrum.

  • Reunião de Planejamento da Release: estabelece a meta da release, estimativas e as maiores prioridades do Product Backlog, os principais riscos e as características gerais e funcionalidades que estarão contidas na release. Estabelece também uma data de entrega e os custos prováveis se nada mudar. A organização pode inspecionar o progresso e fazer mudanças nesse plano a cada Sprint. Esse planejamento é inteiramente opcional, onde iniciando os trabalhos sem essa reunião, a ausência de seus artefatos aparecerá como um impedimento que deverá ser resolvido. Na maior parte dos caso o processo de planejamento é feito no início do trabalho da release e não é modificado com o passar do tempo. São definidos uma meta geral e resultados prováveis.
  • Sprint: é uma iteração de duração fixa. Durante um Sprint, o ScrumMaster garente que não será feita nenhuma alteração de escopo que possa afetar a Meta da Sprint. Uma Sprint consiste do Planejamento da Sprint, o trabalho de desenvolvimento, a Revisão da Sprint e a Retrospectiva da Sprint. As Sprints ocorrem uma após a outra, sem intervalos entre elas. Uma Sprint pode ser cancelada antes do prazo fixo, mas somente o Product Owner tem autoridade para isto. Uma Sprint pode ser cancelada se a Meta da Sprint se tornar oblsoleta, pela empresa mudar de direção ou se as condições do mercado ou tecnologia mudarem.
  • Reunião de Planejamento da Sprint: é o momento no qual a iteração é planejada. É fixada oito horas de duração para uma Sprint de um mês. Para Sprints mais curtas, deve-se alocar proporcionalmente ao tamanho total da Sprint para essa reunião. Ela consiste em duas partes, a primeira parte – o quê? – é o momento no qual é decidido o que será feito na Sprint e a segunda parte – como? – é o momento no qual o Time entende como desenvolverá as funcionalidades em um incremento do produto. Para a primeira parte o Product Owner apresenta ao Time o que é mais prioritário no Product Backlog. Cabe ao Time a decisão de avaliar quanto do Backlog deverá ser selecionado para a Sprint. Uma vez selecionada as atividades do Backlog, a Meta da Sprint é delineada, sendo ela o objetivo que será atingido no Sprint. Na segunda parte da reunião o Time geralmente começa projetando o trabalho, identificando tarefas. As tarefas devem ser decompostas para que possam ser feitas em menos de um dia. Essa lista de tarefas é chamada de Sprint Backlog. O Product Owner estará presente nesta segunda parte da reunião para esclarecer e ajudar a efetuar trocas de tarefas caso as estimativas excedam ao tempo da Sprint ou o haja algum impedimento ainda não resolvido para a execução daquela tarefa. Caso o Time finalize a Sprint antes do prazo, será negociado com o Product Owner uma nova tarefa que será adicionada ao atual Sprint Backlog.
  • Revisão da Sprint: ao final da Sprint, é feita uma reunião de Revisão, com duração proporcional à duração da Sprint – quatro horas para Sprints de um mês. Nesta reunião o time colabora sobre o que acabou de ser feito e baseado nisso eles colaboram sobre quais são as próximas tarefas que podem ser feitas. Trata-se de uma reunião informal, com a apresentação das funcionalidades. O Product Owner identifica o que foi feito e o que não foi feito. O Time discute sobre o que ocorreu bem e quais foram os problemas enfrentados, além de como esses problemas foram resolvidos. O Time demonstra o trabalho que está pronto e responde a questionamentos. O Product Owner faz projeções de datas prováveis a partir de várias hipóteses de velocidade. A Revisão de Sprint fornece entradas valiosas para as reuniões de Planejamento de Sprints seguintes.
  • Retrospectiva da Sprint: logo após a revisão da Sprint e antes da próxima reunião de Planejamento da Sprint o ScrumMaster encoraja o Time a revisar seu processo de desenvolvimento, de forma a torná-lo mais eficaz e gratificante para a próxima Sprint. A finalidade é inspecionar como ocorreu a última Sprint em se tratando de pessoas, das relações entre elas, dos processos e ferramentas. Deve identificar e priorizar os principais itens que ocorreram bem e aqueles que, feitos de modo diferente, poderiam ter deixado as coisas ainda melhores. No final desta reunião o time deve ter identificado medidas de factíveis melhoria que implementarão na próxima Sprint.
  • Daily Scrum: o Time se encontra diariamente para uma reunião de no máximo 15 minutos, sempre no mesmo horário e no mesmo local durante as Sprints. Durante a reunião cada membro explica:
    • O que ele realizou desde a última reunião;
    • O que ele vai fazer antes da próxima reunião;
    • Quais obstáculos estão em seu caminho.

As Daily Scrums melhoram a comunicação, eliminam outras reuniões, identificam e removem impedimentos para o desenvolvimento, ressaltam e promovem a tomada rápida de decisões e melhoram o nível de conhecimento de todos acerca do projeto. É uma inspeção e adaptação do progresso na direção da Meta da Sprint. Os Artefatos do Scrum incluem o Product BackLog, o Burndown da Release, o Sprint Backlog e o Burndown da Sprint.

  • Product Backlog e Burndown da Release: os requisitos para o produto estão listados no Product Backlog, por seu conteúdo, por sua disponibilidade e por sua priorização. O Product Backlog evolui à medida que o produto e o ambiente em que ele será usa evoluem, ele é dinâmico, no sentido de que ele está constantemente mudando para identificar o que o produto necessita para ser apropriado, competitivo e útil. O gráfico de Burndown da Release registra a soma das estimativas dos esforços restantes do Product Backlog ao longo do tempo. O Product Owner mantém o Product Backlog e o Burndown do Backlog da Release atualizados e publicados todo o tempo.
  • Sprint Backlog e Burndown da Sprint: o Sprint Backlog consite nas tarefas que o time executa para transformar itens do Product Backlog em incremento pronto. É todo trabalho que o Time identifica como necessário para alcançar a Meta da Sprint. Os itens do Sprint Backlog devem ser decompostos suficientemente para que mudanças no progresso possam ser entendidas na Daily Scrum. Um dia ou menos é um tamanho comum para um item do Sprint Backlog. O Sprint Backlog é um retrato em tempo real altamente visível do trabalho que o Time planeja efetuar durante a Sprint. O Burndown do Sprint Backlog é um gráfico da quantidade restante de trabalho do Sprint Backlog em uma determinada Sprint ao longo do tempo da Sprint.

O Scrum exige que os Times desenvolvam um incremento de funcionalidade do produto a cada Sprint. Esse incremento deve ser potencialmente integrável, pois o Product Owner pode optar por implantar a funcionalidade imediatamente. Para isso ser possível, o incremento deve ser um pedaço completo do produto. Ele deve estar “pronto”. Cada incremento deve ser adicionado a todos os incrementos anteriores e exaustivamente testado, garantindo que todos os incrementos funcionem juntos.

Fonte: Elton Kuzniewski

Tags | , ,

12

dez
2011

Sem Comentários

Em Agile
Blog

Por Allison

Programação em Pares: Lado a lado ou frente a frente?

Em 12, dez 2011 | Sem Comentários | Em Agile, Blog | Por Allison

A programação em pares é uma técnica de desenvolvimento ágil em que dois programadores trabalham juntos em apenas uma estação de trabalho. Seus benefícios são bem conhecidos e a técnica é amplamente praticada. Entretanto, qual é o melhor posicionamento das pessoas quando se trabalha em pares?

Uma maneira comum é sentar-se lado a lado, mas este modelo traz alguns inconvenientes, como sugere Josh Susser:

Embora sentar-se lado a lado seja um bom modelo em vários aspectos, o mesmo se mostra pouco ergonômico. Primeiro, os programadores acabam ficando de lado para o monitor, o que requer inclinação e torção para se sentarem em uma posição em que ambos possam tanto ver quanto digitar. Também é difícil olhar para o parceiro sem contorcer o pescoço.

Uma maneira alternativa de se programar em pares é sentar-se frente a frente. A organização alternativa se parece com o desenho abaixo, onde as áreas destacadas representam os pares.

Diz Susser sobre esse layout:

É muito mais confortável, pois ambos temos uma visão melhor da tela e se pode ver um ao outro com facilidade. Ficamos sentados próximos o suficiente para que seja possível se comunicar, sem que seja necessário levantar a voz. Facilitou muito nossa interação.

Brian e Corey experimentaram este modelo e o acharam bastante efetivo. De acordo com Brian, ele acabou preferindo esta forma de parear ao modelo convencional:

Acabei preferindo este estilo ao pareamento lado a lado, de frente a uma única tela. E ainda prefiro este modelo, no lugar de sentar-se em frente a dois monitores com dois teclados. O trabalho tem um fluxo mais livre e é mais fácil perceber a linguagem corporal da outra pessoa. Também fica mais natural parar de codificar, levantar a cabeça e conversar. A troca entre os pares também melhorou; houve poucas situações em que se tentou mexer no cursor ao mesmo tempo.

Tim Ottinger tentou este arranjo mas não ficou tão impressionado. De acordo com Tim,

Não foi tão ruim assim, mas nos sentimos menos conectados um ao outro neste modelo e era necessário apontar com o mouse ao invés das mãos. Funciona, mas parece mais com a experiência de se programar em pares remotamente.

Será que este arranjo tem desvantagens?

Josh Susser diz que é um pouco difícil perceber sinais sutis, como quando a outra pessoa está pronta para assumir o controle do teclado ou pequenos movimentos das mãos, que são mais visíveis quando se está sentado lado a lado. O layout também aumenta o custo, pois requer mais equipamentos e espaço físico.

Postado por Vikas Hazrati, traduzido por Rafael Buzon

Fonte: InfoQ

Tags | , , ,