AgileAndArt

Sexta passada estive no evento DevOpsDays, que aconteceu em Santa Clara (Califórnia), no escritório central do LinkedIn. O termo DevOps (criado por Patrick Debois) surgiu no final do ano passado, mais ou menos na época em que Andrew Schafer e Paul Nasrat deram uma palestra na Agile 2009 sobre Infraestrutura Ágil.

Onde Surgiu DevOps?

DevOps tem vários signifcados. O mais óbvio deles, como o próprio termo já diz, significa a união de Desenvolvedores (devs) e Operadores (ops) de Sistemas (também conhecidos como SysAdmins).

Em startups, é muito comum que não exista separação entre Devs e Ops. Nessas empresas, os técnicos sabem tanto escrever o software como dar manutenção e administrar os servidores de produção. Conforme as empresas crescem, começa a surgir a necessidade de especialização nas áreas de desenvolvimento e sysadmins (DBAs, Storages, Rede, Linux, Windows, etc). Problemas começam a surgir quando criam-se silos e a empresa fica dividida entre aqueles que criam o software e aqueles que mantém tudo funcionando em produção. Essa divisão pode ser muito nociva para a empresa, uma vez que os profissionais, ao invés de colaborarem para o sucesso da empresa, ficam num jogo de apontar o dedo um para o outro, na busca de um culpado que, convenhamos, pouco importa para o negócio.

DevOps tem o objetivo de trazer os conceitos e boas práticas aprendidas pelos Engenheiros de Software Ágeis para o mundo dos SysAdmins. Não só isso, DevOps também procura clarear para os desenvolvedores as preocupações (justas) e práticas dos SysAdmins. O principal trabalho do SysAdmin é manter tudo no ar. Qualquer coisa a mais que o desenvolvedor quiser, coloca em risco o trabalho o SysAdmin. O desenvolvedor tem que entender isso e trabalhar como parceiro do SysAdmin. Ele tem que se preocupar para que nada quebre em produção e estar disponível para ajudar o administrador caso algo dê errado. Faz parte do trabalho de devs e ops estarem alinhados e colaborarem um com o outro.
continue reading…

Para quem quiser, seguem os slides da minha palestra no Encontro Ágil 2009:

No último domingo, no Encontro Ágil, fizemos uma sessão de Birds of a Feather e discutimos alternativas para pessoas de TI desenvolverem sua inteligência longe do computador. A discussão foi maravilhosa e gostaria de compartilhar com todos esse momento incrível do Encontro Ágil. O vídeo é longo, mas vale muito a pena parar um tempo para refletir sobre tudo que foi dito nessa conversa de pessoas de várias regiões do Brasil, com históricos completamente diferentes, porém, com algo em comum.

Confira o vídeo:

Sábado eu dei uma palestra de 20 minutos no 4o. Locaweb TechDay. Gostei muito de ter explorado esse tema. Muitas das ideias foram baseadas no livro Pragmatic Thinking And Learning, do Andy Hunt, misturado com minhas experiências pessoais. Confesso que tenho muitas outras coisas a respeito desse mesmo assunto que eu ainda quero falar. Façam seus comentários para me ajudar!

Pensamento e Aprendizado Eficiente – Desvendando o Cérebro Humano from Locaweb on Vimeo.

I’d like to use this post to announce 2 big changes in my life. The first one is that since now I will post here in English instead of Portuguese. With this, I’d like to make my blog more understandable outside Brazil. I’m not sure I’m ready to write everything I think in a foreign language, but the only way to find it out is to begin writing and see what happen. So, here I am. For the practice I will also write some poetry in English, in my poetry blog.

The second change in my life is that I’ve just became a film maker. I’ve done my first short film and I’d like to share it with you.
The film title is “Todo mundo tem o direito a vida – todo mundo tem o direito igual”, which means Everybody has the rights for life – everybody has the same rights”. It’s the story of a foot and a dog. The foot wants to dance as the dog just want to turn around the table in infinite cycles. They both have their rights to do it whenever they want, and I hope they continue doing forever and ever. I’d like to thank Lenine for the soundtrack and if the film goes someday to hollywood I promise pay all the rights…

Thanks you for the audience!

Participei hoje do primeiro tutorial na QCON San Francisco 2008. O tutorial foi sobre o assunto que eu venho estudando há algum tempo: Padrões para Introduzir Novas Idéias. Em termos de conteúdo, não vi nada muito novo. Mas o que mais me impressionou foi a presença de espírito da Linda Rising. Foi um enorme prazer estar com ela todo esse dia e ouví-la falar sobre os padrões. A sua fala é tranqüila, clara e perfeita. Nunca tinha vista alguém da área da computação se expressar de forma tão maravilhosa. Me sinto privilegiado de ter participado de um tutorial ao lado de uma das mulheres que seja talvez um dos maiores nomes da computação atual.

Clique no link “YouTube” acima para ver os outros vídeos relacionados

Transforme a resistência à nova idéia em algo a seu favor. Toda inovação, no fundo, rompe com algo. Logo, a resistência é bem vinda. Precisamos da resistência para testar nossas idéias e convicções. Os céticos são um presente. Eles nos dão informações sobre o caminho que estamos seguindo e sobre como podemos adaptar nossa abordagem.

Talvez o ponto mais essencial da mudança é a nossa forma de lidar com o medo. Num processo de mudança existe medo de dois lados: quem está sendo mudado quer evitar a dor de ter que, talvez, perder algo; quem está promovendo a mudança tem medo de que sua idéia esteja errada. Quando esses dois lados entram em choque surge um impasse. A resistência não é a principal razão pela qual uma mudança falha. É a reação à resistência que causa problema.

Dificilmente se obterá 100% de aprovação numa nova idéia. E isso é bem vindo. Toda lei que não deixa em aberto a possibilidade de sua execução, justamente por sua desobediência, é uma arbitrariedade. Segundo o Tratado de Sanhedrin, em caso de julgamento de penas capitais – quando se faziam necessários 23 juízes -, caso houvesse uma unanimidade na condenação do réu, o julgamento era desqualificado e este liberado. O sentido de tal lei é a desconfiança de que um processo possa ser tão bem conduzido que não paire qualquer dúvida quanto a uma leitura diferente da situação. (A Alma Imoral – Nilton Bonder)

É difícil ouvir quando não concordamos com algum ponto de vista. Normalmente ficamos fixados em nosso ponto de vista. Uma outra abordagem seria encorajar a outra pessoa a falar mais sobre o ponto de vista dela. Só de ouvi-la já ajudará vocês a se entenderem.

Peça ajuda aos resistentes. Certifique-se de que eles sabem que você está ouvindo. Ouça de verdade e tente aprender com ele. Tente fazê-los entender que aceitar a nova idéia não significa jogar fora a experiência deles. Não assuma que a posição cética é fixa. Alguém que inicialmente parecia contra pode se virar a seu favor.

Esse padrão permite que você use a resistência a seu favor, ao invés de a usarem contra você. As pessoas que virem você lidar com os céticos de forma respeitosa vão admirá-lo por isso.

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 é resultado de um refinamento, de várias tentativas e variações sobre um tema, na busca do resultado perfeito.

Na Disneylândia, existem centenas de atores cujo único trabalho é fazer com que cada visitante tenha momentos maravilhosos. Os requisitos do que é um “momento maravilhoso” muda de visitante para visitante e o trabalho do ator é descobrir o que o visitante vê como experiência de qualidade e se certificar de que ele tenha essa experiência.

A visão de qualidade de serviço (e hoje software é serviço) leva em conta que cada cliente tem uma idéia diferente do que significa uma experiência de qualidade.

A diferença entre prover um serviço e produzir um produto é que, em serviços, atender a necessidade do cliente requer variações, enquanto que em linhas de produção variações são vistas como inimigas.

Problemas de software possuem várias soluções, em vários níveis, feitas por todos os membros do time. Não só os arquitetos estão envolvidos, mas todos os desenvolvedores. Escrever código envolve um entendimento profundo do problema, reconhecer padrões, experimentar várias abordagens, testar os resultados. Para isso, o melhor processo é aquele que consiste em ciclos curtos de aprendizado.

Fonte: Mary and Tom Poppendieck, Lean Software Development – An Agile Toolkit

Só para sentir o clima do Encontro Ágil promovido pela Agilcoop, que aconteceu ontem no IME-USP, fiz alguns filminhos. Em breve teremos disponíveis os vídeos completos da trilha avançada do evento, com debates calorosos. Divirtam-se!

Encontro Ágil 2008 – Almoço

Encontro Ágil 2008 – Passeio

Encontro Ágil 2008 – Introdução a XP

Encontro Ágil 2008 – Debate Ágil x CMMI