Disseminando conhecimento e inovação em desenvolvimento de software corporativo
Integração Contínua não se resume a disponibilizar um servidor que continuamente obtenha e compile uma cópia do projeto. Ela é uma virtude a ser cultivada pelos desenvolvedores, independente de um servidor e, para tanto, é preciso seguir uma série de práticas que tornam possível integrar o trabalho dos diversos membros do projeto, mantendo sua integridade e realizando o menor esforço possível.
Em seu recente livro, Padrões de Adoção de Métodos Ágeis: um roteiro para o Sucesso Organizacional, Amr Elssamadisy fornece um framework para a criação de uma estratégia para adoção de métodos ágeis em um contexto específico.
Para desenvolvedores e líderes familiarizados somente com Scrum e XP, Lean pode ser um mistério. Aqui está uma introdução ao Pensamento Lean e como isso contribui para o desenvolvimento de software. Ning Lu da ThoughtWorks China identificou o maior obstáculo para Lean ou Agile como sendo o pensamento desenvolvido durante o período de manufatura em larga escala.
Steve Denning aponta, em artigo recente, pontos fracos do Agile que precisam ser revistos para responder a mudanças ocorridas nos últimos dez anos após publicação do Manifesto Ágil. Apenas gerar software em funcionamento deixou de ser suficiente: o foco deve ser no encantamento dos clientes. Denning oferece recomendações de mudanças na filosofia Agile para adequação à nova realidade.
O Scrum se torna mais eficiente quando você prioriza o seu backlog. A priorização do backlog é parte do trabalho do product owner, mas o que podemos fazer quando o product owner não prioriza o backlog por conta que ele ou ela não vê valor na priorização?
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.
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.
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.
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.
