Maurício Linhares também é professor da IDEZ, o que me deixa particularmente feliz em saber que tem gente capaz dentro da academia que pode fazer diferença. Esse contato entre mercado e academia é importante para todos e creio que os alunos ontem tiveram muito dever de casa para fazer.

Ontem anotei muitas dúvidas discutidas na mesa redonda que fizemos após as palestras e nos próximos dias eu postarei sobre as principais dificuldades em entender o que é agilidade, que TDD não evita equipe de Testes ou QA e nem sequer tem a ver com cobertura de código, que agilidade não é velocidade, inclusive pode ser mais lento em determinados períodos, confusão entre práticas, valores e princípios, entre outras coisas.

Sobre minha palestra eu falei sobre as dificuldades que encontro, como melhorar a adoção dos valores e princípios trabalhando a base. Vocês podem acompanhar nos slides e video abaixo:

Vídeo do Evento

Referências sobre os slides de minha palestra

O que é agilidade?
http://manifestoagil.com.br/
http://www.milfont.org/tech/extreme-programming-books/

Scripts do workflow GIT sobre os slides do “Merge From Hell”
http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html
http://reinh.com/blog/2008/08/27/hack-and-and-ship.html
http://gist.github.com/8511

Trabalho energizado
Pair Programming
http://www.milfont.org/tech/2010/06/17/trabalho-energizado-e-a-teoria-das-2-horas-produtivas/
http://www.milfont.org/tech/2009/02/03/pair-programming-vs-code-review/

Automação Total
http://radar.oreilly.com/2009/03/continuous-deployment-5-eas.html
http://blog.caelum.com.br/2010/03/01/o-processo-de-deploy-continuo/
http://agilenomundoreal.com.br/2010/07/06/deploy-continuo-entrega-continua-de-valor/

http://railscasts.com/episodes/179-seed-data

Testes
http://www.milfont.org/tech/2009/06/01/recomendacao-sobre-tdd/
http://www.milfont.org/tech/2009/06/07/quanto-testar/

Sem tempo suficiente
http://www.milfont.org/tech/2010/06/29/sem-tempo-suficiente/

Dar caos a ordem

Destruir arquiteturas de referências

http://www.milfont.org/tech/2010/01/21/voce-esta-nivelando-por-baixo-eou-nao-conhece-seus-desenvolvedores/

http://www.milfont.org/tech/2008/01/20/frameworkstools-caseiros-ou-fechados/
http://www.milfont.org/tech/2009/06/06/frameworks-caseiros-2-a-missao/
http://www.milfont.org/tech/2008/01/21/nao-use-notacao-estranha/

Separar gerenciamento de projetos do processo de desenvolvimento
Pmbok de Jeans
http://www.milfont.org/tech/2009/03/14/pmbok-de-jeans/

Software Funcionando
http://www.milfont.org/tech/2009/09/17/qualidade-interna-vs-qualidade-externa/

Retrabalho e Prejuízo
http://www.milfont.org/tech/2009/01/08/retrabalho-e-prejuizo/

Workflow ágil e simples
http://www.pivotaltracker.com
http://github.com/tpope/pickler
http://github.com/trydionel/git-pivotal
http://www.pivotaltracker.com/help/api?version=v3#scm_post_commit

Jesus recomendando o trabalho em par
“E depois disto designou o Senhor ainda outros setenta, e mandou-os adiante da sua face, de dois em dois, a todas as cidades e lugares aonde ele havia de ir.”
Lucas 10:1

Eu radicalmente sugeri um grande refactoring para corrigir nossa bateria de testes, uma parada faltando apenas uma semana para entrega, mas só assim voltaríamos a trabalhar na entrega das features.

Nesse momento, o clássico “Não temos tempo para isso” surgiu das profundezas do inferno.

Fiquei sozinho nessa decisão, o time inteiro foi contra. Na defesa da solução apresentada eu falei: “Vocês podem se enganar imaginando que podem entregar essa release em uma semana com a qualidade do código existente que vocês sabem que vai de mal a pior ou podem trabalhar para corrigir esses problemas e entregar o possível, mas funcionando”.

Sabemos da importância de testes, todas as metodologias os cobra obrigatoriamente, então se você não testa, você está errado em todas as metodologias. O problema sempre é a desculpa da timeline e quanto mais vai se aproximando mais desculpas procuramos encontrar para esconder as deficiências. Como nesse caso não tínhamos Test First, os problemas vão se empilhando no final e se tornam mais difíceis de serem detectados.

Por sorte, minha sugestão acabou sendo acatada, apesar de ser apenas um consultor no projeto, portanto uma galinha e não porco.

De onde nascem essas desculpas?

Coragem é um dos valores do XP, é importante enfrentarmos esse tipo de situação que descrevi, na vida real isso quase nunca é possível porque essas arquiteturas flácidas ou códigos mal cheirosos não nascem do dia para o outro e vão se acumulando.

O projeto que descrevi era um projeto novo, tecnologias fresquinhas e um time modernoso. Imagina agora se você está em uma corporação que usa um processo cascata, todo amarrado, criando documentos UML desnecessários no EA, struts 1 como framework, CVS como controle de versão do código [quando há! Sim, em pleno 2010 ainda há quem não use nenhum], o código de banco de dados cheio de procedures e tantas modernidades da década de 80.

Então, acha que só coragem basta?

Em muitas oportunidades o custo de mudanças ou simplesmente “fazer o que se tem que fazer” não se pagará nem a médio prazo, nessas horas convencer já não basta. É muito difícil você convencer a alta direção que deve jogar fora um determinado projeto e começar do zero, ou modificar toda a infraestrutura existente.

A degradação de um software nasce de pequenos problemas que se acumulam, no final há tanto para se fazer que ninguém mais tem coragem para isso.

Socorro, Milfont!

Recebo constantemente pedido de socorro de pessoas que me conhecem das comunidades que participo como XPCE, GURU-CE, JAVA-CE, entre outras. Geralmente são funcionários que se encontram nessa situação que citei anteriormente, com projetos muito defasados e problemáticos.  O pedido é sempre o mesmo, querem que eu vá lá dizer para a alta direção o que eles [funcionários] já sabem. Só que isso não basta, o movimento tem que começar por lá.

Em reunião com a turma da TriadWorks, temos discutido isso já há muito tempo e acabamos preparando um serviço de resgate aos clientes para contornar esse problema. A proposta é envolver as pessoas desses clientes, dar coragem e ânimo nelas para começarem a resolver o problema.

Resolvemos começar com nossos próprios clientes, sim, dá preferência a quem tem contrato conosco e depois verificar como abrir para a comunidade.

Então, esse envolvimento nós demos o codinome de “AvoidNotEnoughTime” e consiste basicamente em um conjunto de ações/eventos  com os funcionários dessas empresas para dar essa força necessária para anular o NotEnoughTime na base. É um movimento de baixo pra cima, roots, serão desde Coding Dojos, Code Retreat, Code Jam, Hack Days, Lightning Talks, Open Space ou um formato adequado a um determinado problema que identificarmos.

Nós não vamos cobrar a mais dos clientes por isso, aliás, eles nem foram avisados e não terão controle sobre o projeto, nós que decidimos quando, como e com quem faremos justamente para evitar sabotagem ou direcionamento.

Sem planejamento nem nada, resolvemos iniciar mesmo assim, domingo passado [27/06/2010] realizamos um Git Session onde eu [@cmilfont], @triadworks representada por @handersonbf, @rponte e @carlosatilabreu, recebemos funcionários de clientes nossos. @jeffersongirao da TubForm, @rodrigogalba da Casa Magalhães e @rodrigodealer da Fortes Informática.

O que vocês ganham com isso?

Resolvemos fazer um Git Hack Session devido alguns de nossos clientes usarem CVS e SVN. O tempo perdido resolvendo problemas de repositório como merges e bobagens simples causam um prejuízo enorme, as desculpas para mudarem cai sempre no “não temos suficiente” ou “depois fazemos quando terminar esse projeto”.

Então cada ponto de dificuldade que um time enfrenta e observarmos que se repete nos demais clientes, vamos organizar ações para envolver essa turma afim de anular essas desculpas. Treinar multiplicadores em todos os princípios.

No caso do Jefferson Girão, que trabalha também para a Hoodiny, veio mais para nos auxiliar, já que está mestre no uso do git no meu cliente Tubform [uma das maiores indústrias do Nordeste].

Dessa forma nosso trabalho de consultoria será facilitado e no mínimo já faríamos esses eventos internamente, então unimos o útil ao agradável.

Se você gostaria de participar de algum desses eventos mesmo não sendo funcionário de cliente nosso, mande um email para mim [cmilfont@gmail.com] e tentaremos incluir sempre quando puder. Domingo agora surgiu um desfalque, até twittei convocando alguém que estivesse disponível, mas foi em cima da hora.

Creio que todo mundo já conheça a função noConflict do JQuery para evitar conflitos com outros frameworks que utilizam a variável dóllar ($). JQuery é sem dúvidas o melhor framework javascript para manipulação DOM e não há motivos e nem desculpas para não o usar, principalmente com essa resolução de conflitos.

Tenho refatorado alguns códigos javascript e o pessoal tem resolvido o conflito de forma confusa e misturando código de dois framework, inclusive código DOM nativo. A documentação recomenda, como uma opção, atribuir o resultado da função noConflict a uma variável e ela será o seu objeto JQuery.

Imagina que você tem Prototype e Jquery na mesma aplicação como no codigo abaixo:

A legibilidade vai ser horrível para manutenção desse código porque você vai ficar com códigos misturados com sintaxes e estilos diferentes, a medida que isso vai crescendo a manutenção vai ficando impossível.

Minha sugestão é utilizarem Closure e Currying para resolver o conflito, isolar o código e deixar bem mais claro. Se ler a documentação lá do noConflict tem exemplo como o código abaixo.

Se você preferir deixar claro a diferença entre os frameworks pode continuar a usar outra variável no lugar do $, mas a idéia é isolar o código de cada framework.

Duas horas produtivas para mim é uma licença poética para “códigos testáveis de forma automatizada, bem escritos, entregues por dia independente de tempo e que não trarão retrabalho”. Um par evita muito retrabalho, lembrando que retrabalho não é refactoring, é prejuízo.

Claro que não há método científico algum, apenas inferência por observação simples. Dia desses um funcionário de um cliente me disse:

“- Milfont, essa sua teoria é mais um dos seus exageros”.  Respondi:

“- Olha do lado, observe o que todos estão fazendo”.

Para espanto desse funcionário, ao olhar para o time mais caxias da empresa, aquele time considerado certinho, que ninguém conversa com ninguém, ele tomou um susto e detectou que todos, eu disse T-O-D-O-S, estavam com o cliente de email aberto. Ninguem estava com sua IDE em primeiro plano.

Coincidência?

Trabalho Energizado

Como consultor eu enfrento problemas de coaching e mentoring [adoro buzzwords] em relação a dificuldade da alta gestão não compreender os benefícios de programação em par para o trabalho energizado. Não que programação em par seja o único responsável por um trabalho focado, mas sem essa prática não dá nem para começar a mudar o cenário.

Todos meus clientes dizem em uníssono: “Até entendo que programação em par é importante, mas não o tempo todo e não para aqueles trabalhos simples”. Investigaremos essa frase ao final.

Meu trabalho como consultor é transformar galinhas mortas em galos de briga, então não tenho pretensões nem esperança que em um mês meus clientes terão integração contínua, todos seguirão Test First como prática e serão felizes para sempre, no mundo real a coisa é só um pouquinho mais complicada. Enfrento muitos clientes saindo da década de 80 direto para o novo milenio, é uma leva de CVS, Delphi, até clipper, além de vícios provocados por essas plataformas/arquiteturas/whatever.

Agile Bibas

Hoje é muito comum meus clientes pedirem planilhas e técnicas para medir velocidade e desempenho de seus “recursos” porque leram sobre isso nas revistas da moda. Isso é perda de tempo, vou cair no clichê mas não posso deixar de falar, enquanto voce não tratar seu time como pessoas e que elas não são máquinas controladas, não espere retorno deles.

Leonardo Eloy cunhou o termo #Agilebibas para representar todos os defensores do PMBoK de Jeans que irão vender métricas e dirão que o time não produz conforme o esperado porque não se comprometem com as planilhas. Apenas comando-controle disfarçado de ágil.

Esqueça métrica de time, concentre-se na métrica do software. Não importa se o membro do time está nu, pulando corda, de cabeça para baixo, lendo emails ou enchendo a cara numa terça de manhã. O que importa é se as features foram entregues e com qualidade.

Parece simples mas não é, a soma “8 + 8 = 16″ é difícil de ser anulada [imaginar que 8 horas de dois funcionários representam 16 horas de trabalho produzido com qualidade]. Medir tempo por funcionário é um dos maiores erros para tentar aumentar a produtividade do time.

Vou dizer mais uma vez: “Não meça pessoas, meça e entregue software”. Então não importa se seu funcionário não trabalha as 6 ou 8 horas que você espera que ele trabalhe, o que importa é se as duas features planejadas para hoje foram entregues com a qualidade esperada.

Evitar o trabalho chato

Algumas empresas ainda sonham com a esperança que basta impedir o acesso a redes sociais ou serviços na web, então o funcionário vai parar o “Goofing Off“. Existem inúmeros motivos para uma pessoa não estar energizada em seu trabalho, considero o principal como sendo “fazer trabalho chato”.

Vamos agora analisar aquela frase do início:

“Até entendo que programação em par é importante, mas não o tempo todo e não para aqueles trabalhos simples”

Observe que essa frase revela duas nuances onde o cliente acredita que trabalho em par não é importante, uma consequência da outra. Trabalho simples que provoca a necessidade de não trabalhar em par o tempo todo.

A primeira coisa como consultor quando sou contratado para mudar a cultura do time é tentar incluir programação em par como algo natural e prática necessária, para tanto preciso anular esse trabalho chato que considero ser basicamente trabalho repetitivo. Observe na frase anterior que meus clientes chamam esse trabalho de “simples”.

Não é simples, é chato.

Exemplo que me veio a cabeça agora mesmo, todos os cliente que não tem Test First como prática, então ficam testanto as coisas durante o desenvolvimento na mão, para tanto precisam gerar dados.  Para um desenvolvedor é frustrante ficar fazendo dump e passando para seus colegas de trabalho, porque não automatizar isso?

Todos meus clientes que não fazem Test First passam por isso. Ora, se mesmo os que tem essa prática nós enfrentamos desafios de um bom Setup para garantir a independência no INVEST, imagina os que não fazem.

Outro erro comum é achar que número de commits é sinal de proficiência ou estar trabalhando mais, em regra, para mim é sinal de muito trabalho repetitivo.

Não vou me prolongar, quero só concluir que evitar trabalho chato ajuda a demonstrar que Pair Programming é sim necessário o tempo todo e que se isso for alcançado a “morcegação” tende a diminuir e o reflexo na entrega de funcionalidades se torna positivo. Junte a isso o foco no software ao invés de medir pessoas e esqueça as toneladas de planilhas, na maioria das vezes nem um Burndown seja necessário, apenas trabalho energizado.

O objetivo dessa palestra foi desmistificar um pouco o entendimento sobre Domain Driven Design. O foco foi demonstrar que essa abordagem não é sobre padrões, como bem me aconselhou o Rodrigo Yoshima. Enfatizei a comunicação como fator importante e comparei arquiteturas existentes por má compreensão não só da “Orientação a Objetos”, mas por dogmatismo e ignorância.

Como eu conheço bem o mercado local, enfatizei algumas más práticas que considero o empecilho aos projetos, principalmente as “arquiteturas de referências” que se proliferam aqui e impactam na modelagem.

Fizemos um “Hands On” rapidinho e não tem como não falar sobre TDD, afinal, modelagem ágil passa invariavelmente pelo Test First. “Fizemos”, porque tive a ajuda do @rponte.

Descobri só ontem que existe tradução do livro Domain Driven Design do Eric Evans, eu recomendo comprarem o original na Amazon, mas se forem comprar em português que seja pelo meu link.

A InfoQ publicou um minibook sobre o tema.

Vou subir a aplicação que codificamos ontem para o github e atualizo essa página quando estiver disponível. Algumas fotos que foram tirados voces conferem aqui.

Algumas referências importantes sobre o que falei ontem:

http://blog.aspercom.com.br/2009/08/11/repositorios-ddd/

http://fragmental.tw/2010/02/24/everyday-tales-anatomy-of-a-refactoring/

http://fragmental.tw/2010/03/10/everyday-tales-anatomy-of-a-refactoring-%E2%80%93-part-2/

http://fragmental.tw/2010/03/10/everyday-tales-anatomy-of-a-refactoring-%e2%80%93-part-3/

http://fragmental.tw/2010/03/22/nevermind-domain-driven-design/

O governo do estado inaugurou essa semana “A Conta do Paciente“, um projeto inédito no Brasil que vai informar ao paciente quanto foi sua despesa desde a entrada no hospital até sua alta. Esse tipo de atuação aproxima o governo da agilidade que a sociedade cobra em relação à transparência nas contas públicas, antes era quase impossível saber o custo real por paciente. Fora que a secretaria vai saber precisamente e em tempo real os custos por unidade, além de facilitar a tomada de decisões que podem salvar vidas.

Esse formulário detalhado com a conta do paciente é possível graças ao ERP especialista em gestão hospitalar pública da empresa Insystem, nosso cliente e parceiro. A Insytem acreditou em nosso trabalho e é um dos maiores Cases, senão o melhor.

O ERP foi construído 100% com base em TDD em Java usando DWR, Hibernate e  Spring basicamente. Alguns requisitos necessários de usabilidade utilizam Reverse Ajax com DWR. O sistema é totalmente ajax e utiliza o Extjs seguindo a filosofia model 3. Fizemos algumas customizações no Extjs para se integrar ao DWR de forma transparente.

Fomos ágeis desde o primeiro momento, mas nunca nos preocupamos em implantação de processo, metodologia ou qualquer coisa que o foco não fosse software saudável. XP foi algo natural, valores e princípios foram assimilados desde o primeiro dia, mas foi e é o software funcionando e livre de erros [o mais livre possível] que nos moveu.

Destaque para o Felipe Andrade, funcionário da Insystem que se tornou especialista em Extjs com DWR e hoje domina e é talvez o maior conhecedor da união desses Frameworks no estado.

Agradecimentos especiais aos diretores Evando Chaves e Marcelo Meirelles que investiram nessa solução e tiveram a sagacidade de sair na frente da concorrência entendendo que software funcionando é mais importante do que processos bonitos e pomposos, afinal o barco não chega na frente por causa do tambor e sim dos remadores. A Insystem está de parabéns por ter enfrentado todas as correntes contrárias e ter chegado a essa vitória investindo e apostando no fator humano como responsável para a vitória.

Esse é um Case que entrou para a história, estamos procurando outra solução semelhante na saúde pública do Brasil e até agora não encontramos nada.

Orgulhoso por participar dessa conquista.

Palestra: BDD prático com Cucumber, Selenium e RSpec

Resumo: Palestra na forma de “hands on” com a construção de uma aplicação utilizando conceitos de BDD. Outside in development visto na prática através da construção e automação de user stories com Cucumber + Selenium e descrição de comportamento com RSpec e Remarkable

Palestrante: Jefferson Jean Martins Girão
Desenvolvedor no Grupo Tubform (http://www.grupotubform.com.br) atualmente trabalhando na migração de um ERP industrial de MS FoxPro para Ruby on Rails e Javascript com EXTjs. Tem 4 anos de experiência em desenvolvimento de software já tendo passado por áreas como automação comercial, terceiro setor e gestão pública municipal.

Informações sobre o evento:

Título: 3º Encontro XPCE – Comunidade eXtreme Programming do Ceará

Local: Faculdade FA7

Data: 24 de Outubro

Agenda

1. 08:30 as 09:30 – BDD prático com Cucumber, Selenium e RSpec – Jefferson Girão
2. 09:30 as 10:00 – Intervalo
3. 10:00 as 11:00 – Automação de Testes Funcionais de Software com Selenium – Fabrício Lemos

O que diferencia esses processos não são as práticas, são os valores. O problema é que entender, compreender e adotar valores é algo subjetivo que varia de pessoa para pessoa por mais que se tenha princípios bem definidos que conectem as práticas a esses valores.

Diante disso, nenhum processo garante que seu projeto será um sucesso por estar o seguindo, mesmo que seja “By The Book”.

Há uma preocupação com o chamado Scrumbut, mas eu já vejo e vi projetos Scrum que não são Scrumbut e mesmo assim o software produzido, por mais ágil que seja, não tem qualidade e no primeiro refactoring você já entra no prejuízo similar a um software desenvolvido em Cascata.

Fato é que esses valores e princípios não garantem software com código coeso, desacoplado, limpo, claro e facilmente lido, ou seja, com qualidade interna.

Hoje minha preocupação em todos os projetos é a qualidade interna do software, não importa que metodologia seja adotada. Qualidade interna garante que o software tem boa saúde e é fácil de ser medida.

Saúde do software é o quão rápido e efetivo ele se recupera de mudanças e o quão limpo ele está de defeitos. Para se recuperar de mudanças o software precisa ser limpo e claro, ser facilmente entendível e lido.

Livre de defeitos é ter uma cobertura de testes que explorem e machuquem o código até descobrir falhas que passam despercebidas.

A grande maioria dos processos se preocupa mais com a qualidade externa do que a interna. Não importa se você faz reuniões em pé, tenha o cliente presente ou faça Scrumban ou até mesmo que você esteja entregando software rápido, nada disso vai garantir qualidade e que não vá ter prejuízo no futuro.

Vender qualidade externa tem um apelo comercial fácil porque você não precisa comprovar a qualidade do software e sim do processo, o discurso é sempre mais elegante do que falar em código, principalmente para alta gerência e burocratas, tanto é que todos os modelos de qualidade reconhecidos avaliam o processo e não o produto.

CMMi, ISO ou seja lá que for, não garantem que o produto será de qualidade e sim que o processo seja e se pararmos para pensar um momento, o processo realmente é de qualidade, temos um conjunto de métodos eficazes para produzir… processo e não produto.

Um exemplo de qualidade interna de um software são os testes automáticos em suas diversas nuances como unitários, aceitação, integração e funcional, mas não apenas isso, métricas de coesão, cobertura, LOC, complexidade e tantas outras.

No Maré de Agilidade eu fiz questão de enfatizar:

“Não importa que processo você siga, se é ágil ou não, se você não faz testes de Software vocês está errado em todos.”

Não existe um software sem bateria de testes automáticos com qualidade, isso é lenda. Em mais de 10 anos de profissão o que tenho notado é que a grande maioria, senão todos, são fortemente acoplados e de baixa coesão como consequência da falta de testes. Aplicar testes nesses softwares é uma tarefa quase impossível e proibitiva em relação a custos, sai mais barato fazer um software novo.

Outra coisa que falei no Maré de Agilidade foi:

“Não seja ágil, seja o melhor possível, porque ao procurar ser o melhor você invariavelmente vai se deparar com práticas que o tornam melhor e aí você se tornará ágil”.

Assim como o lema da Rossi: “Armas não matam pessoas, pessoas matam pessoas” podemos induzir que: Processos não desenvolvem software, pessoas desenvolvem software!

Ao trabalhar com pessoas, precisamos entender que modelos de negócios como software são de terceira onda [Alvin Toffler aqui] e não da segunda onda [industrialismo]. Qualquer analogia com modelos de segunda onda provocará insuficiência no trabalho dessas pessoas [por isso Lean faz tanto sucesso hoje] e elas precisam estarem motivadas para produzir qualidade interna, coisa que o trabalho sobre qualidade externa não produz.

Esse tema sobre pessoas e processos [como homem/hora] será escrito em outro artigo.

Resumo desse artigo é: Pessoas são responsáveis por produzirem qualidade interna ao produto e não processo, invista nelas.

Fotos

http://picasaweb.google.com.br/lucianobeserra/CursoCaelum
http://picasaweb.google.com.br/cmilfont/CursoCaelumRR11
http://picasaweb.google.com.br/handersonbf/MareDeAgilidade
http://picasaweb.google.com/maredeagilidade/SwellFortalezaMinicursos
http://picasaweb.google.com/maredeagilidade/SwellFortalezaPalestras
http://picasaweb.google.com/maredeagilidade/SwellFortalezaConfraternizacoes
http://www.manoelpimentel.com/fotos_eventos/72157622015680086/1

Twitter

http://twitter.com/#search?q=maredeagilidade

Posts

http://agiletips.blogspot.com/2009/09/big-agile-wave-in-brazil.html
http://pauloigor.blogspot.com/2009/08/mare-de-agilidade-em-fortaleza.html
http://www.natanaelpantoja.com/tech/?p=299
http://felipebviana.wordpress.com/2009/08/10/mare-de-agilidade-fortaleza/
http://ialis.wordpress.com/2009/08/09/mais-agilidade-por-aqui/
http://www.handersonfrota.com.br/triadworks-no-mare-de-agilidade/
http://www.milfont.org/tech/2009/08/05/mare-de-agilidade/
http://henriquegogo.wordpress.com/2009/08/04/mare-de-agilidade-em-fortaleza/
http://www.cearaonrails.org/2009/07/29/esta-querendo-ir-ao-mare-de-agilidade-que-tal-concorrer-a-algumas-cortesias/
http://blog.seatecnologia.com.br/2009/07/20/mare-de-agilidade-e-oxente-rails
http://iviablog.blogspot.com/2009/07/fortaleza-e-palco-para-o-evento-mare-de.html
http://www.igocoelho.com.br/2009/07/14/promocao-para-o-mare-de-agilidade/
http://www.fa7.edu.br/ypiranga/noticia/noticia.php?id=848
http://www.fernandoquadro.com.br/html/2009/07/13/evento-mare-de-agilidade-2009/
http://www.eventosdeti.com.br/2009/07/mare-de-agilidade-fortaleza/
http://www.cejug.org/pages/viewpage.action?pageId=40632324
http://leonardoeloy.com/2009/05/13/mare-de-agilidade-fortaleza/

Slides

http://www.slideshare.net/seatecnologia/manifesto-20
http://www.slideshare.net/seatecnologia/minicurso-ruby-e-rails
http://www.slideshare.net/seatecnologia/minicurso-de-testesonrails
http://www.slideshare.net/fabiokung/onde-mora-a-produtividade-do-ruby-on-rails
http://www.slideshare.net/manoelp/gesto-lean-para-o-desenvolvimento-de-softwaremanoel-pimentel-verso-30
http://www.slideshare.net/cmilfont/mare-de-agilidade-bdd-e-tdd
http://www.slideshare.net/brunopedroso/curso-xp

Videos

http://www.youtube.com/watch?v=IG7QzUjl5TM