Archive for the ‘Metodologias’ Category
Se tem algo que realmente vale a pena assistir são entrevistas. Não importa a área do entrevistado, você sempre aprende alguma coisa. Uma entrevista que acho muito relevante para qualquer profissional da nossa área é a entrevista do Alex Atala ao Roda Viva. Alex Atala é chef de cozinha e proprietário do D.O.M Restaurante. Na entrevista, ele mostrou que a nossa área tem algumas coisas em comum com a gastronomia. Fiz alguns comentários sobre os pontos que julguei mais relevantes, mas recomendo fortemente que você leitor, assista a entrevista e reflita sobre essas semelhanças:
Aconteceu nesse último final de semana um dos eventos mais importantes do ano, o DNAD 2011. Esse evento conseguiu reunir no centro de São Paulo, participantes do Grupo .Net Architects de vários estados, possibilitando troca de conhecimento e muito networking dessa galera que só se conhecia por e-mail ou pelo Twitter. Primeiramente, gostaria de agradecer todos os feedbacks positivos com relação ao conteúdo que tenho publicado nesse blog. Saber que o que disponibilizo aqui ajuda tanta gente é uma ótima motivação para continuar o trabalho. Também fiquei muito feliz pela receptividade da minha Lightning Talk sobre Scrum e das discussões no Open Space.
Depois dos feedbacks positivos com relação ao HeroCast, decidi experimentar um outro formato de publicação onde, através da Twitcam, busco falar sobre assuntos relacionados à área de desenvolvimento usando como referência alguns posts.
Séries como Friends, Two And A Half Men e The Big Bang Theory são alguns Sitcoms de sucesso que, ao analisarmos seus processos de produção, percebemos que vários aspectos desse tipo de projeto são comuns à projetos de software. Essa comparação pode parecer estranha de início, mas além das semelhanças, devemos avaliar também quais práticas do Show Business deveriam ser aplicadas na nossa área a fim de melhorá-la.
Só o código importa. Essa frase nem sempre me disse tanto quanto diz hoje em dia. Sua simplicidade desafia a compreensão de um profissional que vivenciou e ainda vivencia projetos de software nos quais o código é apenas mais uma das coisas que podem dar errado. Em um contexto no qual passamos boa parte da graduação aprendendo a montar diagramas e no mercado em que os profissionais passam o dia montando documentos, essa frase realmente não pode fazer sentido. Desde 2009 atuo em um contexto diferente da maioria do mercado: O contexto de entregas rápidas e funcionais de software. Nele o tempo é um recurso que precisa ser muito bem aplicado e tudo o que for desnecessário ou demorado deve ser simplificado ou simplesmente removido do processo, buscando a entrega. Nesse contexto, onde o que importa é software funcionando, feedbacks rápidos e projetos adaptáveis à mudança de requisitos e tecnologias, o código ganha muito mais relevância do que tem nas fábricas e torna-se a base para obtenção de bons resultados. Trabalhar nesse contexto me trouxe algumas percepções que gostaria de compartilhar. Não são verdades absolutas é claro, mas fazem muito sentido para mim:
No último sábado, dia 30/04, aconteceu em Cachoeiro-ES o DevInCachu, um dos melhores eventos que já tive oportunidade de participar e palestrar. O evento aconteceu na faculdade São Camilo e foi organizado pelo pessoal do grupo Nerds, uma galera que não só mandou bem pela iniciativa de trazer esse tipo de evento para região, mas também pela qualidade em que o evento teve em todos os aspectos. O evento iniciou com a galera da Giran contando sobre os 2 anos da empresa utilizando métodos ágeis. O Jeveaux e o Hackin colocaram o nível do evento lá no alto falando de forma descontraída sobre suas percepções das práticas ágeis e os desafios de ser uma startup. Fui o segundo palestrante do dia. Apresentei o tema “Como errar em desenvolvimento de software”. Essa palestra é uma compilação das minhas experiências com projetos de software desde que iniciei na área. Procurei apresentar através das situações que passei o por que, na minha visão, as práticas ágeis fazem mais sentido atualmente. Abordei temas como Previsibilidade, Scrum, Ténicas de engenharia, TDD e outras práticas que tenho utilizado. Recebi bons feedbacks da galera.
01 de setembro de 2010, por Denis Ferrari em Metodologias
Olá Pessoal! Não escondo que sou “meio” viciado em quadrinhos, games, filmes, etc. Pois bem, depois de algum tempo parado decidi voltar a jogar um dos games mais viciantes da minha adolescência: O Counter-Strike. Voltei a jogar somente para dar uma surra no pessoal do escritório (@hrosko e @andrepiresmct), mas acabei deixando-o instalado e jogando eventualmente. Apensar das coisas não terem muito a ver uma com a outra, comecei a traçar uma linha entre Counter-Strike e Desenvolvimento de Software, uma espécie de “boas práticas” comuns para ambos. Pensei muito antes de escrever esse post, depois desencanei e vi que o máximo que pode acontecer é que essas dicas ajudem vocês a desenvolver melhor ou a jogar melhor, então vamos lá:
Nessa semana realizamos o II Fórum para Gerentes de Sistemas na Mindworks em Vitória-ES. Realizamos a primeira versão do evento no mês passado a pedido da própria Microsoft, e depois de uma série de pedidos para realização de uma segunda versão, decidimos organizar um evento semelhante, porém, voltado para a comunidade local. Acredito que a segunda versão do evento ficou ainda melhor que a primeira. Mudamos algumas abordagens, inserimos alguns assuntos importantes e procuramos trabalhar de uma forma dinâmica e interativa com os participantes. Vou relatar agora um pouco do que aconteceu no evento:
05 de fevereiro de 2010, por Denis Ferrari em Metodologias
Nossa área de desenvolvimento de software é muito nova, e como consequência disso, ainda estamos aprendendo quais são as técnicas que funcionam e quais só atrapalham o dia-a-dia dos nossos projetos. É dever de todo profissional da área buscar meios para melhorar o nosso objetivo principal: Construir softwares que atendam aos clientes, aos usuários e às equipes de desenvolvimento. Práticas ágeis são um meio e não um fim, não deve-se utilizar as técnias se não é evidente quais problemas elas tentam resolver, usar por usar não melhora em nada o resultado final do seu projeto. Você só deve usar essas práticas se realmente entender porquê elas são necessárias, e não porquê estão na moda. |
|
||||||
