BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Artesanato de software no InfoQ Brasil

  • Comparando Valor, Velocidade e Velocidade de Valor

    Um pressuposto implícito feito pela maioria das equipes ágeis é que o 'valor' é algo diretamente proporcional à 'velocidade' da equipe. Ainda que isto possa ser verdadeiro em alguns casos, no entanto, na maioria das vezes a velocidade da equipe dá pouca indicação sobre o verdadeiro valor entregue.

  • Lidar com Bugs em um Projeto Ágil/Scrum

    Uma pergunta freqüentemente questionada é como Scrum recomenda que a equipe trate os bugs? Eles devem ser colocados no product backlog? Ou em uma lista de bugs separada? Se eles estão no backlog, o Product Owner deve definir as prioridades ou eles são automaticamente os itens mais importantes? Deve existir um sprint em separado para a correção de bugs?

  • Pra que Serve a Velocidade?

    Uma discussão recente no grupo ScrumDevelopment do Yahoo! debateu sobre os diferentes usos e abusos da velocidade. Velocidade deveria ser utilizada como uma métrica de produtividade? Deve ser usada para planejamento de iteração?

  • Resgatando seu Projeto Ruby on Rails

    Ruby on Rails já está aí há cerca de 5 anos, e durante todos esses anos diversas aplicações foram desenvolvidas. Várias dessas aplicações foram criadas enquanto os desenvolvedores estavam aprendendo Ruby e Ruby on Rails, e por consequência, não utilizaram as melhores práticas de desenvolvimento. Apesar disso, as aplicações continuam online.

  • Código de Qualidade nas Equipes

    Malik Jaibeer postou uma introdução de como endereçar e introduzir código de qualidade dentro de uma equipe. Sua série de posts podem ser úteis pra quem estiver em uma situação na qual se queira aprender mais para si mesmo ou apresentar essas idéias para outros. A série oferece uma visão geral breve do tema e aponta várias direções para se estudar mais.

  • 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.

  • Kent Beck Sugere Pular os Testes em Projetos de Curto Prazo

    Kent Beck, autor de “Extreme Programming Explained” e “Test Driven Development: By Example” sugere que um projeto de software, assim como golf, pode ser um jogo longo ou curto. JUnit é um exemplo de projeto longo, muitos usuários, rentabilidade estável (a $0 é triste para qualquer envolvido), onde o objetivo principal é proporcionar funcionalidades além das necessidades dos usuários.

  • Software Craftsmanship North America

    Software Craftsmanship North America (SCNA) é uma conferência de um dia só com o objetivo de introduzir a comunidade ágil no movimento de Software Craftsmanship. Curiosamente, o SCNA vai se realizar ao mesmo tempo que a conferência Ágil, na mesma cidade e com palestrantes partilhados entre as duas conferências.

  • Parar e Refatorar?

    Quando você deve refatorar? Eu nunca concordei com essa noção, pois penso que há momentos em que você simplesmente precisa pagar parte do débito técnico. Não, você só deve refatorar quando se está trabalhando em uma história com esse propósito. Existe outra estratégia que pode funcionar melhor?

  • Top 10 Motivos para Amar Teste Ágil

    Quais são as dez razões para os testadores amarem testes Ágeis? Kay Johansen recentemente fez esta pergunta e obteve algumas respostas dos principais testadores.

  • 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.

  • Medindo Agilidade, Artesanato de Software e Sucesso

    Enquanto Scott Ambler, Ross Pettit e outros continuam em busca da criação de um modelo de maturidade para desenvolvimento ágil, David Starr investiga como e porquê uma organização pode querer medir coisas como: agilidade, habilidade e sucesso organizacional. Ele considerou o artesanato de software de fácil mensuração, ainda que a agilidade seja algo mais difícil de se medir em termos úteis.

  • Avaliando Scrum em um ambiente CMMi5

    Ainda existe no mercado de software uma grande defasagem de informação acerca de como medir o desempenho dos projetos que utilizam Scrum. O mercado, acostumado a ver os resultados em números, tem custado a entender o benefício da filosofia Lean do “go and see” e tem tido mais dificuldade em desenvolver um modelo de medição e análise que agregue valor à organização sem causar overhead aos times.

  • Testador dedicado em um time ágil

    A necessidade de testadores dedicados em um time ágil é uma questão bastante discutida. Em muitos times ágeis, estes desempenham um papel central enquanto os outros desenvolvedores também fazem testes, mas não de forma dedicada. Uma discussão recente no grupo scrumdevelopment endereça novamente essa questão.

  • O que significa Qualidade?

    O que siginifica Qualidade no Desenvolvimento de Software? Como é usado hoje, Mike Bria observa: ‘Qualidade’ se refere á "ausência de defeitos" ao invés da "presença de valor", de modo que isto representa o que é normalmente utilizado no uso diário.

BT