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

  • O Manifesto do Pronto

    Alixx Skevington postou um Manifesto do Pronto como o começo de uma discussão, falando sobre os compromissos que os membros do time tem sobre os outros em relação à qualidade do seu trabalho e claramente expressando suas obrigações para entregar valor de negócio através do código.

  • CINTEQ - International Conference on Software Testing and Quality

    Na última semana desse mês vai ocorrer um grande evento na área de qualidade de software em São Paulo, o CINTEQ - International Conference on Software Testing and Quality organizado pelo ISQTB. Saiba as principais palestras e o que você pode esperar desse evento.

  • Comentar ou não comentar?

    A maioria dos desenvolvedores já escreveu pelo menos uma linha de comentário em seu código. Alguns chegam até a escrever várias linhas de comentário com o intuito de tornar o explicar melhor o que tal implementação faz. Esse artigo reúne algumas práticas usadas na hora de escrever comentários, além de opiniões internacionais e nacionais sobre comentar o seu código.

  • Estimando Valor de Negócio

    A abordagem ágil para priorização é que as histórias de usuário de mais alto valor de negócio devem ser implementadas antes daquelas de menor valor de negócio. O conceito é simples, mas sua implementação depende de se ter um mecanismo para avaliar o valor de negócio.

  • User Manifesto - Uma extensão do manifesto ágil

    Em seu site, Alistair Cockburn propôs a criação de uma extensão para o Manifesto Ágil, voltada para o usuário / cliente, a partir de um discussão na cidade de Salt Lake junto com Jeff Patton, que em conjunto com outras pessoas iniciaram este trabalho. O trabalho é ainda preliminar, mas já foram criadas quatro opções, que são basicamente as mesmas, mas dispostas de maneira diferente.

  • Sprints de Estabilização, um Mal Necessário ou um Puro Desperdício?

    Dushy tem ouvido falar sobre Sprints de Estabilização e ficou pensando se elas eram a norma no mundo ágil. Sprints de Estabilização são uma porção de sprints adicionais ao final do ciclo normal de desenvolvimento e antes da entrega do produto. Como o nome sugere, elas costumam ser incluídas como uma última oportunidade de explorar o produto numa última busca por bugs.

  • Recompensas Individuais em um Time Scrum

    Uma recente discussão se iniciou no grupo Agile Alliance do LinkedIn com a questão feita por Reeju Srivastava: "Deveríamos ter um reconhecimento individual em um time Scrum?"

  • Software Katas – Práticas em Público Levam à Perfeição

    Muitos líderes pensadores das comunidades ágeis tem passado a falar mais sobre software katas – uma maneira de pôr em prática exercícios específicos até que sejam memorizados. Ao longo das últimas semanas, têm havido um aumento de publicações em blogs e sites relativas a katas. Robert Martin vai longe ao se referir a katas como a "arte do desempenho".

  • Refatorar ou Reescrever?

    O objetivo de refatorar e reescrever é "limpar" o sistema melhorando a legibilidde, estrutura e a clareza do código. Um código limpo erá mais fácil de manter e melhorar. No entanto, em muitas ocasiões as equipes gastam um certo tempo decidindo entre as duas abordagens.

  • Analisando a Dívida Técnica

    O termo "dívida técnica" foi definido por Ward Cunningham e descreve a dívida que a equipe de desenvolvimento assume quando escolhe um design ou abordagem fácil de implementar no curto prazo mas com grande impacto negativo no longo prazo. Alguns agilistas opinaram sobre o que deve ser considerado dívida técnica e como poderia ser classificada.

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

  • EU Software Liability lawsuit: a metade diz que teste unitário é a resposta

    52% dos desenvolvedorres de .NET, questionados pela Typemock, pensam que teste unitário pode ajudar empresas a evitar processos relacionados à proposta do projeto de lei de responsabilidade do software na EU (União Européia). O que eles dizem?

  • Deficiências de software Crescem em Custos Substantivos

    No recente artigo entitulado "Entrega Continua de Ganhos na Evolução do Sistema", Chris Sterlin discute o conceito de Deficiências de Software – "A deficiência do software se acumula quando o foco permanece na finalização imediata, enquanto flexibilidade de mudanças do sistema é negligenciada no decorrer do tempo".

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

BT