A geração de bom software não é um processo de produção; é um processo de desenvolvimento. Desenvolver é diferente de produzir. Desenvolver é como criar uma receita, enquanto que produzir é seguir os passos de uma receita pronta. São atividades diferentes. Desenvolver uma receita é um processo de aprendizado, de tentativa e erro. Quando um grande chefe cria um prato, ele não o cria de primeira. O prato primordial é Continue reading
Post Category → Programming
RailsSummit – Vídeo do almoço
O evento RailsSummit promovido pela locaweb reuniu os maiores nomes da comunidade Ruby/Rails/Ágil. Óbviamente não podia faltar um delicioso strogonoff na hora do almoço.
Vejam:
Rede Neural de XP
A Mariana Vivian Bravo da Agilcoop criou uma linda imagem, relacionando os valores, os princípios e as práticas de XP. Parabéns, Mari, pelo trabalho
Forum Internacional do Software Livre – FISL 9.0 – vídeo
Estou no maior evento de software livre da América do Sul. Em breve farei um post com os melhores momentos do FISL 9.0. Por hora, fiquem com um vídeo que eu fiz passeando pelo evento.
Práticas que vão bem com o plano de iterações
Joca Torres defendeu nesse post algumas vantagens de usar métodos ágeis, do ponto de vista do gerente de produtos. O design incremental e o uso de iterações permite que o cliente veja mais rapidamente aquilo que já está pronto. A partir do momento que o cliente está usando nosso software, ele começa a PAGAR e a ter benefícios (e nós também!).
Porém, do ponto de vista do time de desenvolvimento, existem alguns cuidados que precisam ser tomados para que o software se torne “modificável” para atender as necessidades do cliente. Para entregar funcionalidade de forma incremental, você precisa ter um ambiente de desenvolvimento e uma base de código que facilite e permita essas entregas iterativas.
As práticas de XP são um guia para isso. O gerente de produtos tem muito contato com as práticas de planejamento (histórias, iterações, velocidade etc) mas em software não basta planejar. Continue reading
Ambiente de Desenvolvimento LocaWeb Telecom
Fiz um resumo do ambiente de desenvolvimento da LocaWeb Telecom e o produto PABX Virtual, contando algumas soluções e técnicas que usamos em nossos testes de aceitação.
Injeção de Dependências e Spring
Essa semana fiz um seminário no IME-USP sobre Spring e Injeção de Dependências, um tópico que vem se tornando cada vez mais presente no dia-a-dia do trabalho. Pretendemos começar a colocar em prática essa tecnologia nos próximos meses. A apresentação pode ser baixada em http://gsd.ime.usp.br/seminars/2007/spring.pdf
Estou a disposição para dúvidas
Tracking Subjetivo
O tracker é conhecido como a consciência do time. É ele quem mostra números, gráficos, tabelas. Os dados que o tracker coleta podem ser objetivos (ex: número total de testes, total de horas estimadas por release, estimativas versus realizações) ou subjetivos (ex: nível de satisfação da equipe, qualidade do código. Coloco aqui algumas fotos de tracking subjetivo, tiradas de cartazes feitos durante o segundo semestre de 2007 no Projeto Borboleta
A primeira delas (clique na imagem para vê-la em tamanho grande) é do “humorômetro” da equipe. Continue reading
A poesia de programar
Em dezembro de 2002, Richard Gabriel, um grande nome da Computação e ex-engenheiro da Sun, falou sobre a semelhança entre programar computadores e escrever poesias. Como é possível que essas duas atividades, aparentemente pertencentes a áreas tão distintas, tenham coisas em comum?
O atividade de escrever software deve ser vista como uma atividade criativa. Afinal, software interessante de se fazer é software que nunca foi feito. Essa atividade não pode ser comparada à de criar pontes, por exemplo. Nós construímos pontes há mais de 2000 anos. O software mais antigo não deve ter mais de 50 anos! Mesmo utilizando boas ferramentas, um programador está quase sempre Continue reading
Tracker no Pabx Virtual
Durante 9 meses de trabalho no projeto do Pabx Virtual da LocaWeb, coletamos informações estatísticas do código do projeto. Baseado nessas informações tirei algumas conclusões.
No gráfico à direita vemos claramente que o projeto tinha inicialmente muito código duplicado. Depois de várias Refatorações, foram removidas duplicações e o código ficou muito mais limpo e fácil de alterar.
No gráfico seguinte Continue reading