É com grande satisfação que anuncio o Bluesoft Podcast, um podcast em português que tem como objetivo difundir as metodologias ágeis e desenvolvimento de software apresentado por mim e Luiz Faias Jr.
O Podcast já está em seu 4º episódio e abordou temas como:
“Cultura de Aprendizagem”
“Batman da Iteração”
“Restrospectiva do Seis Chapéus”
“Programação em Par“.
Além do tema principal, o podcast apresenta as principais novidades da última quinzena das comunidades ágeis nacional e internacional.
Disponível em aúdio e vídeo, possui um feed que pode ser assinado e um canal no iTunes.
Convido todos a ouvir ao podcast. Sugestões e críticas serão sempre muito bem vidas, mande-as para podcast arooba bluesoft ponto com ponto br.
O pessoal da Software Engineering Podcast acabou de publicar a entrevista de Markus Völter com o consagrado Robert C. Martin, também conhecido como Uncle Bob Martin autor diversos livros como Clean Code e evangelista do movimento Software Craftsmanship. Recomendo que todos ouçam ao podcast (em inglês) na integra, mas gostaria de enfatizar alguns pontos importantes.
Segundo Uncle Bob, pensar arquitetura e design vale muito a pena, porém, ele não gosta nada da idéia de se separar a arquitetura da codificação. Os melhores arquitetos são aqueles que codificam e vivem no “mundo que constroem para os outros”, disse. Se um arquiteto não codifica ele fica desconectado das decisões que toma, porque não é afetado por elas, ele ”não tem que dormir na cama que faz”.
O importante é que arquitetos mantenham seus dedos no teclado, a final, você não pode liderar um time a menos que os conheça e entenda. Você tem que experienciar o que o time está fazendo para saber o que ele realmente precisa.
O código é documentação mais imporante. Todos os outros documentos devem refletir o que o código faz. O código digire todos o resto e não é apenas resultado de outros documentos como sugure o waterfall.
O termo foi criado com a publicação do livro de Pete McBreen em 2002. Fala-se sobre aprender com mestres. Aprenda as habilidades e como tomar decisões, mas você deve aprender com outras pessoas ajudando-as a fazerem seu trabalho.
Uncle Bob sugere como práticas TDD, Integração Contínua e Programação em par, e afirma que bons times trabalham em par na maior parte do tempo, no entanto, afirma que não se deve ser religioso quanto a isso, “você não precisa trabalhar em par 100% do tempo”, diz.
Não basta funcionar, o software deve ser bem escrito e fácil de manter. Foque em agregar valor. Deve haver um parceira com os clientes. Você deve realmente envolver-se com as decisões tomadas e garantir que o que cliente pede realmente vai agregar valor para ele. Não faça simplesmente porque é seu trabalho se você já sabe que não vai dar certo. Comprometa-se com o resultado do seu trabalho.
Aprenda os Shortkeys (atalhos de teclado). Tente fazer o máximo que você puder sem usar o mouse. Um desenvolvedor de software deve estar altamente integrado com seu ambiente.
Utilize uma boa ferramenta de SCM (Source Code Control), o CVS é razoável, o SVN é melhorzinho, mas meu favorito é o Git.
Bug Tracking Systems são importantes, mas use com certo cuidado. Devem ser leves e simples de usar.
Use ferramentas para teste como jUnit (xUnit), rSpec, Cucumber, JBehave e Fit.
Linguagens dinamicas são muito produtivas e se você faz TDD o “perigo” vai embora. Você não precisa mais de um compilador para te dar uma falsa segurança.
A coisa mais importante para um desenvolvedor de software é noção de aprendizado contínuo. Você nunca pode parar de aprender. É como um médico.
Você deve aprender o máximo de linguagens que puder, e deve conseguir escrever código em todas essas linguagens ainda que não seja um especialista em todas elas. Não adianta. Aprenda no mínimo uma linguagem estática, uma dinâmica e uma funcional. Robert diz que todos devem aprender LISP.
Uncle Bob Martin na RailsConf 2009 porFabio Akita no Vimeo
Um dos maiores problemas da sociedade moderna é a dificuldade de locomoção diária, a maioria das pessoas passa horas em seus carros, ou em meios de transporte públicos para irem de lugar a outro. Há alguns anos atrás quando morava na zona norte de São Paulo e trabalha na zona sul, essa era minha realidade. Uma vez que naquela época passar por isso era inevitável procurei formas de fazer com esse tempo pudesse de alguma forma torna-se produtivo, foi então que comecei a ouvir à podcasts.
De acordo com a Wikipedia, Podcasting é uma forma de publicação de arquivos de mídia digital (áudio, vídeo, foto, etc.) pela Internet, através de um feed RSS, que permite aos utilizadores acompanhar a sua atualização. Assim, é possível o acompanhamento e/ou download automático do conteúdo de um podcast.
Neste post apresentarei os podcasts aos quais escuto e os episódios principais para que você ouça. Sugiro que você utilize o iTunes para inscrever-se nos podcasts e sincronizar com seu iPod.
por Vinícius Teles
http://improveit.com.br/podcast
Português
Por AgilCoop
http://agilcoop.incubadora.fapesp.br/portal/agilcast
Português
Por André Faria e Luiz Faias Jr.
http://podcast.bluesoft.com.br
Português em Áudio e Vídeo
http://agiletoolkit.libsyn.com
Inglês
Inglês
http://www.agilepodcast.com
http://www.thoughtworks.com/what-we-say/podcasts.html
Inglês
por Leo Laport, Jono Bacon e Randal Schwartz
Inglês
Podcast da Comunidade JBoss
Inglês
http://asylum.libsyn.com
Por Tor Norbye, Carl Quinn, Dick Wall e Joe Nuxoll
Inglês
http://www.javaposse.com
Inglês
http://www.javaworld.com/podcasts/jtech
Por Glen Smith e Sven Haiges
http://grailspodcast.com
Por Jason Seifer e Gregg Pollack
Inglês
http://railsenvy.com
por Geoffrey Grosenbach
Inglês
http://podcast.rubyonrails.com/
Por Mike Moore
Ingles
http://rubiverse.com
Inglês
http://blog.jquery.com/2009/11/13/announcing-the-official-jquery-podcast/
Inglês
http://yayquery.com/
Inglês
http://ajaxian.com/by/category/podcasts
por Cali Lewis
Inglês
http://www.geekbrief.tv
por Pragmatic Bookshelf
Inglês
http://www.pragprog.com/podcasts
por Software Engineering Radio
http://www.se-radio.net
Inglês
por Elegant Code Community
http://elegantcode.com
Inglês
http://code.google.com/p/google-developer-podcast/downloads/list
Inglês
http://herdingcode.com
Inglês
The Dev Show
Inglês
http://5by5.tv/devshow
The Changelog
Inglês
http://thechangelog.com/
http://itc.conversationsnetwork.org
Inglês
por Amber MacArthur e Leo Laport
http://www.twit.tv/natn
por Leo Laporte, Jeff Jarvis, Baratunde Thurston, e John C. Dvorak
http://www.twit.tv/twit
por Leo Laporte, Don McAllister, Paul Kent, and Andy Ihnatko
http://www.twit.tv/mbw
por Leo Laporte, Gina Trapani, Jeff Jarvis e Mary Hodder
http://www.twit.tv/twig
inglês
http://www.sitepoint.com/podcast
por 37 Signals
Inglês
http://37signals.com/podcast
por Max Gehringer
Português
http://cbn.globoradio.globo.com/servicos/podcast/NOME.htm
por Heródoto Barbeiro
Português em Áudio
http://cbn.globoradio.globo.com/servicos/podcast/NOME.htm
http://startuppodcast.wordpress.com
Inglês
por TED Talks
Inglês
http://www.ted.com
Se você quiser incluir algum outro podcast nesta lista, deixe um comentário. Espero que seja Útil!
Restrospectivas ágeis são sem dúvida, uma grande oportunidade para que equipes de desenvolvimento de software parem para pensar no trabalho que vem realizando e questionem o que pode se melhorado. É uma execente ferramenta para que o famoso ciclo PDCA (Plan / Do / Check/ Act) possa ser aplicado. O método ágil Scrum sugere que as reuniões de retrospectiva aconteçam no final da iteração (sprint) e que a equipe se faça duas perguntas básicas:
Alguns preferem perguntar:
No fim das contas o que realmente importa é que a reunião tenha como resultado ações a serem tomadas pela equipe para que a melhoria continua seja aplicada, e que na próxima restrospectiva, a equipe seja melhor do que era na última.
Alguns dias atrás o Vinicius Teles da Improveit twitou o link de uma palestra que foi apresentada no Google por by Esther Derby e Diana Larsen sobre restrospectivas ágeis. As duas são especialistas sobre assunto e já até escreveram um livro que pode ser comprado por $20 em PDF. Vale a pena assitir a palestra:
Creio que uma das coisas mais importantes que as duas destacaram na apresentação é a necessidade de dividir as responsabilidades de tomar as ações entre os membros da equipe para que as mudanças realmente aconteçam. De nada adianta reuniões de retrospectivas que apontam problemas que nunca são resolvidos por ninguém. Para evitar que isso aconteça na Bluesoft, ultimante em toda reunião de restrospectiva nós lemos os itens que identicamos como coisas que poderiam ser melhoradas no sprint anterior e então rapidamente discutimos se realmente já estão resolvidos, e caso não estejam, voltamos a incluir o item e insistímos até que finalmente seja resolvido.
Um outro ponto interessante levantando por meu amigo Ricardo Almeida, é que devemos tomar cuidado para não transoformar a reunião de restrospectiva em uma mera busca de culpados. O foco deve estar sempre na solução.
No inicio desde ano Linda Rising apresentou na QCon Londres 2009 um tutorial sobre retrospectivas, uma de suas dicas, foi que as pessoas anotassem os acontecimentos bons e ruins ao longo do sprint em post-its para que não os esquecessem. Na Bluesoft, reservamos uma área do Kanban para que estes post-its sejam anexados.
Para maiores informações sobre retrospectivas, visite o Agile Restrospective Resource Wiki, um wiki (em inglês) com uma série de dicas, exercícios e ferramentas para realização de retrospectivas. O site cmcrossroads possui uma lista bem completa de sites onde você pode encontrar excelente material sobre o assunto.
Boa Restrospectiva!
Como anunciado anteriormente, neste último final de semana participamos do Porto Alegre Agile Weekend, foi a primeira fez que pisei em solo gaúcho. O evento foi realizado na PUC-RS, a universidade possui, sem dúvida, uma excelente estrutura.

Auditório Principal
Ao chegar, pegamos o final da palestra “Anti-Práticas Ágeis” do Peleteiro da Globo.com. Peleteiro ressaltou a importância da prática e da vivência das metodologias ágeis, e alertou sobre a cilada de pensar que “Agile By the Book” funciona, mencionou a consagrada estória do taxista que foi publicada há algum tempo atrás no blog do Alexandre Magno para ilustrar a importância de se ter o cliente presente, e respondeu a diversas perguntas sobre Scrum na Globo.com.
Depois do delicioso coffe break voltei ao auditório e assisti a palestra do Bruno Lichot: “Como o Scrum mudou a forma da Borland de Entregar Software“. Lichot apresentou um pouco da história dos métodos ágeis na Borland e falou sobre sua conversão pessoal aos métodos ágeis. “Scrum fez a ponte entre o gerenciamento e a execução“, disse, e completou “Mantemos o foco em agregar valor a empresa com projetos mais curtos e um relacionamento mais estreito com o cliente“.
A Borland foi eleita pela a Scrum Allience um dos maiores casos de sucesso de Scrum. Lichot apresentou um pouco do perfil das equipes da Borland: 70% dos projetos da empresa utilizam métodos ágeis, o tamanho dos sprints varia de acordo com o perfil de cada equipe e as necessidades de cada projeto, o perfil de cada profissional é respeitado, o plano de testes é gerado no levantamento de requisitos, procura-se remover obstáculos ao invés de encontrar culpados, utiliza-se kanban digital para equipes distribuídas.
Lichot deixou ainda algumas dicas: “Mudança sempre gera conflito“, afirmou, e ao alertar sobre os céticos, aqueles que apresentaram resistência as mudanças, Lichot aconselhou: “ganhe dos céticos, apresente resultados, afinal contra fatos não há argumentos, mostre software pronto e que funciona.”
Alguns dos benefícios alcançados pela Borland com a adoção de Scrum:

P-47 Thunderbolt, Força Aérea Brasileira / Brazilian Air Force por Luigi Brasile
O segundo dia foi aberto com chave de ouro pelo famoso trio da Sea Tecnologia (Alexandre Gomes, Bruno Pedroso e Renato Willi), eles apresentaram o case do projeto ágil que desenvolveram na Força Aérea Brasileira. Esse, sem dúvida, é um dos cases mais interessantes que já conheci, principalmente por causas dos desafios culturais que precisaram ser enfrentados por ambas as partes: cliente e equipe de desenvolvimento.
O pessoal da Sea também apresentou algumas lições aprendidas: quebrar tarefas complexas em tarefas menores e mais simples faz com o que o projeto evolua mais rápido e com que todos acompanhem a evolução com maior transparência; retirar baias, ou qualquer barreira física melhora a comunicação entre a equipe; o tempo proporciona mais segurança para estimar e dá a equipe maior capacidade de analisar impactos; a cultura do cliente, seus valores e princípios devem ser respeitados.
Um diferencial muito interessante que nos foi apresentado, foram os mantras utilizados pela equipe da Sea, esses mantras são afirmações ou frases que representam ações que devem ser tomadas para que algo seja melhorado no processo. Os mantras podem ficar escritos em algum local que seja de fácil visão para os membros da equipe, para que assim todos possam lembrar da ação que deve ser tomada. Alguns exemplos de mantras seriam: “Eu vou escrever testes unitários”, “Eu vou rodar os testes ander de dar commit”, etc..
Confira os slides da apresentação no SlideShare.

Luiz Faias Jr.
Esse foi o tema da palestra do meu amigo e colega de trabalho Luiz Faias Junior. Nesta primeira participação da Bluesoft em um evento de métodos ágeis, Faias apresentou o processo da Bluesoft e diversas dicas para a construção de uma equipe e de um ambiente ágil: comentou sobre a criação do quadro magnético de scrum; testes unitários para propiciar a equipe de desenvolvimento mais segurança para realizar alterações no software e agregar qualidade ao produto; integração contínua para que seja tomada alguma providência rápida se um teste for quebrado.

CML - Caipira Modeling Language
A audiência pareceu ter gostado bastante da “Caipira Modeling Language“, uma mistura de UML, Desenhos de Telas, Fluxogramas, e tudo o que você puder imaginar que faça sentido em um desenho de modelagem.
Um outro tópico interessante foram as Technical Sessions ou Reuniões Técnicas. São reuniões de 1 hora que acontecem todas as quartas-ferias na Bluesoft durante o horário de trabalho. Nessas reuniões qualquer membro da equipe pode escolher um determinado tema que tenha relação com alguma tecnologia utilizada no projeto ou alguma tecnologia que possa melhorar a dia-a-dia da equipe. Faias, citou o exemplo do JQuery, um framework JavaScript que começou a ser utilizado depois de apresentado em uma technical session e trouxe muita produtividade ao trabalho da equipe. O mesmo aconteceu com Git e com o Spring Framework. As technical sessions oferecem a todos a oportunidade de ensinar e aprender.
Fique ligado, em breve mais detalhes sobre a apresentação serão publicados no blog da Bluesoft.
Sem sombra de dúvidas o evento foi um verdadeiro sucesso! As palestras foram excelentes e as dicussões muito enriquecedoras, gostaria de parabenizar a toda a equipe do Porto Alegre Agile Weekend pelo ótimo trabalho realizado, e de forma especial agradeço também ao Daniel Wildt por nos ter convidado a participar do evento.
Confira também as impressões de Maurício Aniche e Victor Hugo Germano.