BT

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

Contribuir

Tópicos

Escolha a região

Início Melhores Práticas no InfoQ Brasil

  • Processos de software destroem a paixão dos desenvolvedores?

    Em um post recente, James Turner, editor da O'Reilly, criou polêmica afirmando que processos de software destroem a paixão dos desenvolvedores. O foco demasiado em processos pela indústria de software, sem a consideração dos seus reais benefícios, estaria gerando perda de motivação nas equipes. Veja aqui os aspectos da polêmica e a repercussão em posts e comentários.

  • Reuniões Ágeis Efetivas

    Reuniões são caras. Um dia inteiro de reuniões dos times pode custar milhares de doláres, se calcularmos o custo de todas as pessoas envolvidas além dos overheads que acontecem. Dado isso, é pragmático se preparar para elas a fim de garantir que suas reuniões Ágeis sejam o mais efetivas possíveis.

  • Qual é a nomenclatura ideal para os nosso métodos?

    Recentemente Anderson Fraga, no fórum Tectura, iniciou uma discussão onde ele faz um questionamento familiar para muitos desenvolvedores, ele comparou a declaração de métodos e classes do projeto Restfulie e viu que no projeto foi usado nomes curtos e expressivos. Mas qual o impacto disso? Qual é a nomenclatura ideal para os nossos métodos?

  • TDD: Por onde começar meus testes?

    TDD é uma técnica bastante utilizada hoje por diversos times. Porém essa forma de iniciar sua funcionalidade pelo teste deve começar por qual parte do nosso projeto? Se estivermos utilizando uma abordagem MVC devemos começar pelos controladores, pela tela ou pelo modelo?

  • Cobertura de Teste e a Falsa Impressão de Segurança

    É muito difícil dizer quanto um software está "bem testado". Como é definido um software bem testado? O que os desenvolvedores constumam utilizar em seus projetos são métricas de cobertura de teste que verificam, de diferentes formas, a porcentagem que o seu código está testando. A questão é, podemos confiar nessa porcentagem? Como fazer com que ela não nos atrapalhe?

  • Cinco regras para obter restrospectivas melhores

    Muito se fala sobre como melhorar as retrospectivas das metodologias ágeis. James Carr publicou recentemente cinco regras de como tornar o processo melhor. As regras são baseadas nas experiências dele em várias retrospectivas, algumas com sucesso, outras não.

  • Motivos de Atrasos em um Projeto Ágil

    Um atraso, em geral, é quando se tem algo pronto depois do planejado, ocasionando um inconveniente desconforto. Em outro ponto de vista, pode-se ver um atraso como apenas um desperdício. Em um projeto ágil, um atraso resulta em descontinuidade, além de ocasionar outros tipos de desperdício como necessidade de reaprendizagem, mudança de contexto de tarefas, etc.

  • 26 Dicas para um Desenvolvimento Ágil Bem Sucedido

    Keith Swenson recentemente compilou a lista 26 dicas para um desenvolvimento ágil bem sucedido. Keith sugeriu que frequentemente coleta porções de sabedoria em vários temas e a lista é um conjunto destilado de sugestões que realmente importam para o desenvolvimento ágil de software.

  • Dicas para Selecionar um Projeto Piloto para Adoção de Práticas Ágeis

    Um dos fatores que influenciam o sucesso da adoção de Agile é o conjunto de aprendizados a partir da aplicação de práticas ágeis em um projeto piloto. Tais aprendizados influenciam a organização a seguir em frente com Agile ou continuar com seus processos corriqueiros. Um piloto ruim pode acabar como um projeto abortado, o que sem dúvida resulta em uma publicidade ruim para o novo processo.

  • Quem Impulsionou nosso Stakeholder de Projeto

    Um stakeholder de projeto para um time ágil é uma pessoa que tem participação valiosa no sucesso do projeto. Ele pode também potencialmente segurar as verbas destinadas ao projeto. Os times ágeis devem se engajar ativamente com os stakeholders, para identificar ideias ou sugestões, discutindo um potencial requisito e, depois, modelando-o e documentando-o.

  • Desacelere para Acelerar Lucros

    Geralmente, sugere-se que, se todos na equipe trabalham no topo da capacidade, então, a equipe seria mais produtiva. Ao contrário disso, Steve Bockman mencionou que esta suposição pode não ser sempre verdadeira. Em alguns casos, pode ser necessário desacelerar e trabalhar menos que a capacidade superior a fim de aumentar a produtividade e a rentabilidade.

  • Gerenciamento de Recursos em Projetos Ágeis

    Projetos ágeis são conhecidos por tratar problemas de mudanças rápidas. Podem ser mudanças por força de mercado, requisitos de sistemas ou implementações tecnológicas. Uma das mudanças que não combinam com projetos Ágeis, são mudanças freqüentes das pessoas que trabalham no projeto.

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

  • Como Superar as Políticas Organizacionais?

    A política é parte integrante das organizações. O processo político faz parte do comportamento humano e organizacional. Geralmente, o pessoal técnico não gosta muito da política porque as questões técnicas são mais precisas e podem ser analisadas "no preto e no branco", enquanto as questões políticas têm vários tons de cinza, que não são tão simples de decifrar.

  • Medir Hiper-Produtividade é Perda de Tempo?

    Numa apresentação sobre Hiper-produtividade e Terapia de Choque, Jeff Sutherland menciona que hiper-produtividade é no mínimo o nível de desempenho da Toyota que é quatro vezes maior do que a média. Em um debate recente no Scrum Development group, membros discutiram se é proveitoso e possível medir de forma precisa produtividade entre sprints.

BT