É 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!
É com grande satisfação que anuncio a publicação do artigo “Desenvolvendo com Agilidade” na revista Java Magazine Edição 68. Esta foi a primeira vez que escrevi um artigo para ser publicado em uma revista, e sem dúvida foi uma grande oportunidade que me trouxe excelentes experiências e maturidade. No artigo, procurei apresentar uma visão geral sobre o desenvolvimento ágil de software, sua origem, principais metodologias e práticas.
Espero que através de artigo mais pessoas entrem em contato com o desenvolvimento ágil e que tenham assim uma melhor experiência profissional. Escrevi sobre esse tema porque realmente acredito nele, e sei que pode trazer grandes benefícios ao dia-a-dia de muitas pessoas.
Críticas, sugestões e feedback serão sempre bem vindos.
Já nas bancas!