AgileAndArt

No mês passado participamos de uma atividade promovida pela ThoghtWorks Brasil em Porto Alegre e organizada pelo Carlos Villela (CV). Eles aproveitaram a ocasião do FISL12 para organizar esse pequeno evento no confortável escritório que fica dentro do campus da PUC-RS. Foi pequeno em relação ao número de participantes (acho que éramos em uns 30), mas enorme em divertimento e aprendizado.

A brincadeira era uma espécie de Dojo, com regras um pouco exóticas. A ideia original foi do Nat Pryce e do Ivan Moore, e eles chamaram de Scrapheap Challenge, por causa do programa de TV, mas eu resolvi re-batizar para Dojo Ojod (um palíndromo de Dojo ao contrário), pois foi exatamente assim que o CV definiu (e que eu concordo muitíssimo): um Dojo ao contrário.

Vamos lembrar que o objetivo principal do Coding Dojo é aprender, num ambiente amistoso e divertido. Nesse quesito o Dojo Ojod é bem semelhante ao Dojo Randori (a mais tradicional modalidade de Dojo). O que muda é que no Dojo Randori temos que fazer TDD, seguir passos de bebê e escrever o melhor código possível, refatorando, deixando ele elegante. No Dojo Randori não temos o objetivo de resolver o problema proposto. Já no Dojo Ojod o objetivo principal é resolver o problema, só que de uma maneira não convencional. Na verdade, a regra é resolver o problema com o maior número possível de gambiarras e escrevendo o mínimo de linhas de código que pudermos. Vale usar qualquer coisa, desde scripts nojentos até ferramentas prontas na Web, planilha de Excel, tudo que tem de mais abominável em matéria de desenvolvimento de software. O importante é favorecer a reutilização.

Aqui vão as instruções de como organizar um Dojo Ojod você mesmo:

1. Exponha a lista de problemas (veja os exemplos de problemas abaixo). Normalmente é bem ter umas 5 opções.
2. Cada pessoa escolhe que problema quere fazer. Dessa forma todos se dividirão em alguns grupos.
3. O ideal são grupos de 4 a 6 pessoas. Tente fazer com que isso aconteça, re-arranjando as pessoas caso seja necessário.
4. Cada grupo irá trabalhar isoladamente por 2 horas (cada grupo pode se sub-dividir como preferir se achar melhor).
5. Durante o trabalho, lembrem-se de que o objetivo principal é resolver o problema com o maior número possível de gambiarras e escrevendo o mínimo de linhas de código.
6. Passadas 2 horas, cada grupo irá apresentar para os outros a solução encontrada (acreditem, isso será muito engraçado!).

Um dos requisitos mais difíceis para esse tipo de Dojo é justamente criar problemas interessantes de serem resolvidos nesse tempo (2 horas). Vou passar aqui a lista dos problemas que tivemos na ThoughWorks:

O grupo que eu participei resolveu o problema número 3 (a música mais sortuda da cidade). Para quem está curioso, veja a solução no meu github e ouça um trecho dessa música maravilhosa.

Essa dinâmica de Dojo nos faz perceber como existem infinitas maneiras de se resolver um problema e como podemos re-utilizar soluções prontas, agrupando-as da maneira adequada, sem a necessidade de escrevermos muito código.

Organize você um Dojo desses na sua comunidade e deixe o seu comentário aqui de como foi o resultado. Se conseguirem inventar novos problemas, por favor, me conte também

Não deixe de ler uma descrição mais detalhada do Scrapheap Challenge no site do Nat Pryce.

No próximo sábado teremos o primeiro DevOpsDays Brasil. O evento será gratuito e terá a presença de palestrantes importantes na área de Cloud e Infra-estrutura de Internet. Quem fará o Keynote do evento será John Willis – VP de serviços da Opscode, empresa que está por trás do software Chef – um dos mais bem feitos softwares de Configuration Management.

Além do Keynote no evento, John se ofereceu para dar um curso GRATUITO de Chef. Esse curso será na 6a. feira que antecede o evento – dia 3 de dezembro – no auditório fornecido pela Caelum. O curso apresentará os seguintes tópicos:

• Uma visão geral sobre o Chef
• O componente Cookbook do Chef
• Integração de Sistemas com Chef

O curso fornecerá uma visão rápida do Chef e da plataforma Opscode. Para fazer o curso é necessário apenas conhecimentos básicos em administração de sistemas. Conhecimento em Ruby é um plus. Faça já a sua inscrição, pois as vagas são limitadas! Todos os participantes do curso ganharão um voucher de 1 mês grátis no Cloud Server Pro da Locaweb.

DevOpsDays

Algumas palestras que já estão confirmadas para o evento:

John Willis: Keynote: The Agile Enterprise, Devops and Clouds

No começo, TI era limitada pelo tempo que levava para provisionar e colocar no ar uma nova infra-estrutura. Porém, com o surgimento do Cloud, podemos montar – e desmontar – um datacenter vitual inteiro instantaneamente. Isso acelera o ciclo de tempo de TI. Isso é análogo a dois outros grandes passos tecnológicos: métodos ágeis de desenvolvimento de software e o movimento “devops” de arquiteturas auto-escaláveis e auto-configuráveis. Vamos ver como o destino da nuvem, código ágil e devops estão entrelaçados, e o que isso significa para os profissionais de TI.

Nessa sessão, John Willis (o co-apresentador dos famosos podcasts Devops Café e IT Management & Cloud) nos fará entender o que é Devops e como ele pode ajudar (ou atrapalhar!) você. Essa sessão dará uma visão pragmática sobre devops, esclarecendo como Devops se aplica para você e sua empresa.

Carla Souza: Automagicaly manage your configuration

Puppet é um software open source poderoso, flexível e extensível que consiste numa linguagem declarativa para expressão configurações de sistemas, além de um cliente e um servidor para distribui-la e uma biblioteca para perceber a configuração desejada. Nessa sessão, Carla Souza mostrará as funcionalidades do Puppet, os requisitos, como funciona e porque um sysadmin irá ama-lo.

Fabio Kung: Cloud e automação: tome o controle da sua infraestrutura!

Um dos principais conceitos trazidos pelo movimento DevOps é a automação de tudo que for possível na infraestrutura. Durante esse tempo em que venho desenvolvendo produtos de Cloud, juntei algumas ideias e possibilidades que gostaria de compartilhar.

Como algumas das principais ideias e serviços do que chamamos de “Cloud” podem ajudar? Como automatizar a infraestrutura? Como isso beneficia os meus sistemas? Como isso acelera a entrega de novas funcionalidades? E a escalabilidade? Performance? Confiabilidade?

Guilherme Silveira: Deploy contínuo: pois integração contínua não basta

Integrar continuamente é uma das primeiras práticas de engenharia de software defendidas por nós agilistas. Mas ser ágil é poder se adaptar rapidamente, requer feedback rápido, inclusive do cliente. Como colocar logo em produção? Em homologação? Depois de ganhar experiência, passamos ao próximo passo natural: automatizar os processos de deploy para homologação e produção, mas passamos por questões desde dificuldades com a infraestrutura até problemas de segurança de dados. Passando por aplicações pequenas, desktop, médias, web e grandes, veremos qual a importância de efetuar deploy sempre.

Outras atrações

Além dessas palestras, o DevOpsDays terá palestras relâmpago, OpenSpaces e painéis de discussão sobre o mundo devops.

Última receita

E para animar a semana, fiquem com o vídeo do Chef Diego Cukier – meu irmão – preparando incríveis pratos no restaurante Brooklin.

É com muito orgulho que anunciamos o primeiro DevOpsDays Brasil, que será realizado no dia 4 de dezembro de 2010. O evento acontecerá num único dia – uma trilha organizada sobre uma série de painéis/apresentações onde encorajamos fortemente a discussão aberta entre os participantes.

Devopsdays é um evento aberto para discutir todos tópicos sobre como melhorar a interação entre o que é tradicionalmente considerado atividade de desenvolvimento e o que é tradicionalmente considerado atividade de operações.

Como nós montamos juntos uma agenda, estamos esperando que *VOCÊ* nos ajude a moldar o evento. A melhor maneira de garantir que você tire o máximo proveito do evento é fazer uma proposta ou sugestão sobre algum tópico que lhe interessa.

O formato será parecido com o Devopsdays US que aconteceu no início desse ano.

Os seguintes tópicos são *exemplos* de possíveis assuntos. Se você tiver outras ideias, conte-nos por favor!

1. Sua kilometragem pode variar: Experiências e lições aprendidas ao enfrentar problemas de DevOps nas trincheiras de TI (mesmo que não tenha siado chamado de DevOps!). O bom, o ruim, as surpresas e ideias para o futuro.
2. Infraestrutura como código: automatização é essencial para DevOps. O conceito de infraestrutura como código orienta hoje boa parte das técnicas de automação de ponta. O que significa tudo isso? Quais são as limitações?
3. Mudanças culturais para permitir DevOps: Mudar as ferramentas é fácil se comparado a mudanças em processos e pessoas. Como podemos cultivar a cultura de uma organização para identificar e resolver problemas de DevOps?
4. O Cloud precisa de DevOps? DevOps precisa do Cloud?: Examinando o papel que as tecnologias de Cloud podem ter para resolver problemas de DevOps e o papel que soluções DevOps podem ter para extrairmos o máximo das tecnologias de Cloud.
5. DevOps exige visibilidade: monitoração, testes e performance: Examinando o papel das técnicas de monitoração e testes em resolver problemas de DevOps
6. DevOps fora do mundo de Operações Web: Muito da discussão sobre DevOps tem foco em Operações Web. Esse painel é sobre levar as lições de DevOps para outras áreas de TI.
7. Casos de negócio: Nós sabemos que resolver problemas de DevOps melhora as operações do seu negócio, mas como explicar isso ao seu CEO ou CFO? Como fazer com que os executivos comprem as ideias e invistam em soluções de DevOps?

Adicionalmente aos painéis, haverão lightning talks (palestras relâmpago) sobre vários temas. As palestras relâmpago usarão o formato “ignite” (a única regra é que são 5 minutos de apresentação usando 20 slides que passam automaticamente a cada 15 segundos). Os horários de lightning talks estão sendo preenchidos rapidamente, então se você gostaria de participar, mande sua proposta por email para proposals-brazil-2010@devopsdays.org

Para se inscrever no evento e obter mais detalhes, entre no site do devopsdays. Nos vemos lá!

Test Driven Development (TDD) is a common practice for software development, in which you write your tests before writing your code. Then you run the tests and they will fail. Then you implement the feature and the test passes. Then you write another test. Then run and fail. Then implement the feature. Then tests passes again. You repeat this process many times. Good developers are already familiar with TDD and do it on their daily-work. But what about sysadmins? How do they test their work? Is it possible for a sysadmin do TDD?

Here’s a small tip of how a sysop could get real benefits doing TDC (Test Driven Changes) to their environments. Matthias Marschall described how to do TDD in Ops world in 3 simple steps:

1. In your monitoring system (Nagios, Zabbix, etc), write a service that monitors the problem you are trying to solve, and make sure the service shows red on your dashboard.
2. Implement the configuration change, and have the your CM – Configuration Manager (Puppet, Chef, CfEngine, etc) roll it out to your test system.
3. Once the service shows green on your dashboard, have your CM roll out the change to production.

So, in infrastructure world, your Test Suite is all the rules you setup in your monitoring tool. Once all your tests are green, you can “refactor” your system. If you break something, some of your tests should fail so you will know what should be fixed.

Ontem, durante o I CBSoft (Congresso Brasileiro de Software), Rafael Prikladnicki e eu (representando a Locaweb e a Agilcoop) demos um mini-curso de Introdução a Métodos Ágeis. Ficamos muito felizes em saber que foi um dos cursos mais procurados do evento. No início do curso, fizemos uma dinâmica com os participantes para que escrevessem em post-its suas experiências. Eles teriam que nos dizer sua opinião sobre por que um projeto de software fracassa ou por que um projeto de software tem sucesso. Baseado nessas respostas, fomos moldando o curso, tentando responder o que Métodos Ágeis ajuda a resolver e o que não.

Uma das coisas mais interessantes foi o fato de que eu não conhecia o Rafael antes. Nós organizamos o esqueleto do curso por e-mail, nos encontramos um dia antes para acertarmos os últimos detalhes e improvisamos muito durante a apresentação. Assumimos a filosofia ágil e íamos apresentando os assuntos que mais interessavam ao cliente (no caso o nosso público). Foi uma experiência divertida.

Para quem quiser ver um pouco do conteúdo do mini-curso, aqui vão os slides.

1 – Quando e como surgiu a idéia de implantar a XP como método de desenvolvimento?

Começamos a fazer XP em 2006, no time que desenvolvia o PABX Virtual (antiga Locaweb Telecom). Quem trouxe a ideia de XP foi Daniel Cukier, um dos desenvolvedores do time na época. Ele tinha cursado em seu mestrado (IME-USP) duas disciplinas sobre Métodos Ágeis e já era membro da Agilcoop. Ja tinha adquirido certa experiência para tentar aplicar o aprendizado num projeto de verdade. O time era pequeno na época (4 desenvolvedores) e o gerente gostou bastante das ideias propostas no XP que lhes foram apresentadas. O time de Telecom era relativamente isolado dos outros times de desenvolvimento e isso facilitou as coisas. Era possível adotar a metodologia como um projeto piloto, sem afetar outras áreas ou produtos. Durante 8 meses, de outubro de 2006 até junho de 2007 o time se estabeleceu na metodologia. O produto PABX Virtual foi lançado e sua evolução em termos de funcionalidades era rápida e eficiente, com poucos bugs. A cada duas semanas, o time de Telecom lançava novidades no produto.Em paralelo a isso, Daniel Cukier e Maurício De Diana criaram um grupo de estudos de tecnologia, onde um dos assuntos estudados foi Métodos Ágeis. O grupo de estudos serviu para que as pessoas pudessem conhecer mais os detalhes não só de XP, mas também de outras metodologias como Scrum e Lean. As reuniões do grupo tinham entre 10 e 20 pessoas. Esse grupo de estudos tentou iniciar um projeto multi-equipes usando XP, mas devido às várias atribulações do dia-a-dia dos membros do grupo, o projeto não deu certo.Em meados de junho/julho de 2007 foram feitas algumas apresentações para a diretoria da empresa, com o objetivo de estimular a adoção de Métodos Ágeis em todos os times de desenvolvimento da empresa. Para convencer os diretores, foram mostrados números que demonstravam a qualidade do produto PABX, tanto em relação ao código quanto à velocidade de criação de novas funcionalidades. Na mesma época, um consultor internacional veio à empresa dar um curso para o time de produtos. Esse consultor comentou que gostava de Métodos Ágeis para desenvolver software. Isso foi a gota d’água que faltava.

No mês de agosto, a diretoria patrocinou um treinamento em Métodos Ágeis para desenvolvedores, gerentes e clientes internos de diversas áreas da empresa (até o presidente participou. A partir daí iniciou-se um processo longo e trabalhoso de adoção das práticas Ágeis dentro da empresa.

2 – Após o planejamento, quanto tempo se gastou para o método ser implantado? Seria possível nos informar o custo médio que a implantação desse método teve? Todos os objetivos da Locaweb foram alcançados?

Foram quase 2 anos de evolução das práticas ágeis dentro da empresa, até o ponto em que podemos afirmar que a Locaweb se tornou de fato uma empresa de Desenvolvimento Ágil. Durante esses anos, muitas coisas mudaram. Várias pessoas saíram da empresa e muitas outras foram contratadas. O perfil dos profissionais mudou drasticamente. No primeiro ano, as práticas de Scrum foram as mais facilmente adotadas (práticas como planejamento, estimativas, ciclos de desenvolvimento, etc.) – as práticas de engenharia e design, como testes, refatoração, integração contínua, só começaram a se estabelecer a partir do 2o. ano. A programação em pares foi uma prática que teve adoção em quase todos os times, mas também demorou 2 anos até que fosse algo arraigado na cultura da empresa. Uma vez que a Locaweb se tornou Ágil nos times de programação, essa mudança começou a impactar outras áreas da empresa: áreas como infra-estrutura, times de sysadmins, e até marketing, vendas e recursos humanos. O objetivo de estruturar a área de desenvolvimento, de forma que a empresa como um todo (diretoria, cobrança, marketing, financeiro) pudesse ter visibilidade sobre os projetos em andamento, foi atingido. Porém, a empresa continua mudando sempre, visando a melhoria contínua dos seus produtos e processos internos. A excelência em Métodos Ágeis na área de tecnologia não significou que todos os problemas fossem resolvidos, pois a empresa é grande e complexa. Mas foi um primeiro passo foi dado e novos aprendizados e ações surgiram desse passo. Então, podemos dizer que a Locaweb é uma empresa muito melhor do que era antes dos Métodos Ágeis.

3 – Houve um aumento de produtividade após a implantação de XP? Ouve uma redução do custo de produção?

continue reading…

O Lego Lean Game é um jogo idealizado pelo Danilo Sato e Francisco Trindade da ThoughtWorks, com o objetivo de ensinar os conceitos básicos da metodologia Lean para desenvolvimento de software de uma forma lúdica e divertida. Para quem não conhece Lean, sugiro ler o livro da Mary e do Tom Poppendieck ou visitar o site dos autores, que contém várias referências sobre o assunto.

Antes de continuar a leitura desse artigo, assista o vídeo:

Existem várias formas de se aprender algo: você pode ler um livro sobre o assunto, ouvir um podcast, ler artigos em revistas ou posts em blogs, assistir um filme. Todas as formas de aprendizado que eu citei são formas de aprendizado por análise. No aprendizado por análise usamos preferencialmente o lado esquerdo do cérebro, o lado lógico, digital, exato, verbal. Nesse tipo de aprendizado, nós olhamos para um problema e tentamos desmembra-lo as partes, tentando entender, com o pensamento, cada uma dessas partes que compõe o todo. Existe uma outra forma de aprender as coisas, o aprendizado por síntese. Nesse tipo de abordagem, nós usamos a prática, a experiência, a vivência, a execução de uma tarefa como ferramenta de aprendizado. O jogo Lego Lean Game é um ótimo exemplo de aprendizado por experiência.

Não adianta muito você ler todos os livros de Lean (ou qualquer outra metodologia) se você não praticou, não experimentou na vida real os conceitos do livro. No jogo de Lego, ficam muito claros os princípios da metodologia:

• Eliminar desperdício – sub ou sobre-produção, espera, trabalho extra, transporte desnecessário, estoque, deslocamento, defeitos
• Modelos Push e Pull
• Fluxo
• Células de Trabalho
• Melhoria Contínua
• Respeito ao trabalho do indivíduo

Todos esses conceitos são apenas palavras jogadas para quem ainda não entende a metodologia. Mas depois de participar dessa dinâmica, essas palavras tomam forte significado e dão abertura para insights e mudanças de comportamento.

O objetivo do Lego Lean Game é construir casas de Lego. Inicialmente monta-se uma linha de produção tradicional para a produção das casas. Depois da primeira rodada de “fabricação”, fazemos uma análise da produtividade. Depois começa-se a alterar o processo, inserindo as práticas Lean. Após cada rodada, refletimos sobre as mudanças e entendemos porque elas funcionam ou não. O mais interessante é pensar, no final, como esses princípios podem ser implementados no dia-a-dia da empresa, com o objetivo de ser mais produtivo, atendendo a demanda do mercado, com profissionais criativos e 100% aproveitados.

A Agilbits foi a consultoria que trouxe essa experiência de Lean para a Locaweb. Quem quiser saber mais sobre o jogo, ou quiser aplica-lo na sua empresa, deixe um comentário que eu encaminho para eles.

Maiores informações sobre o jogo de Lego Lean podem ser encontradas no site do Danilo Sato.

Domain Driven Design significa Projeto Orientado a Domínio. Ele veio do título do livro escrito por Eric Evans, dono da DomainLanguage,  uma empresa especializada em treinamento e consultoria para desenvolvimento de software. O livro de Evans é um grande catálogo de Padrões, baseados em experiências do autor ao longo de mais de 20 anos desenvolvendo software utilizando técnicas de Orientação a Objetos. O que seria um Padrão?

Um padrão é uma regra de três partes que expressa a relação entre um contexto (1), um problema (2) e uma solução (3).

DDD pode ser visto por alguns como a volta da orientação a objetos. É verdade que o livro é um chamado às boas práticas de programação que já existem desde a época remota do SmallTalk. Quando se fala em Orientação a Objetos pensa-se logo em classes, heranças, polimorfismo, encapsulamento. Mas a essência da Orientação a Objetos também tem coisas como:

• Alinhamento do código com o negócio: o contato dos desenvolvedores com os especialistas do domínio é algo essencial quando se faz DDD (o pessoal de métodos ágeis já sabe disso faz tempo);
• Favorecer reutilização: os blocos de construção, que veremos adiante, facilitam aproveitar um mesmo conceito de domínio ou um mesmo código em vários lugares;
• Mínimo de acoplamento: Com um modelo bem feito, organizado, as várias partes de um sistema interagem sem que haja muita dependência entre módulos ou classes de objetos de conceitos distintos;
• Independência da Tecnologia: DDD não foca em tecnologia, mas sim em entender as regras de negócio e como elas devem estar refletidas no código e no modelo de domínio. Não que a tecnologia usada não seja importante, mas essa não é uma preocupação de DDD.

Todas essas coisas são bem exemplificadas e mostradas na forma de vários padrões em DDD. Mas o livro também mostra muitos padrões que não dizem respeito a código ou modelagem. Aparecem coisas que estão mais ligadas a processos (como Integração Contínua) ou a formas de relacionamento entre times que fazem parte do desenvolvimento de um sistema complexo. Eric Evans dividiu o livro em quatro partes, que apresentaremos a seguir.

continue reading…

In this interview, Patrick gives us a quick start guide to the concept of DevOps. I hope you enjoy it!

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…