AgileAndArt

O modelo de Dojo que estamos acostumados é o Dojo Randori, aquele em que temos uma dupla programando (o piloto e o co-piloto) e um telão para mostrar para o resto da plateia o código que está sendo feito. A cada 5 ou 7 minutos o co-piloto ocupa o lugar do piloto e alguém da plateia ocupa o lugar do co-piloto. No Randori, todo desenvolvimento é sempre feito usando TDD.

O Dojo Kake é uma modalidade diferente de Coding Dojo. No Kake, nós temos sempre duas ou mais duplas trabalhando simultaneamente. As duplas podem resolver o mesmo problema em linguagens diferentes ou problemas diferentes. Os turnos continuam sendo de 7 minutos, porém a plateia NÃO PODE ficar olhando a dupla programar. A ideia é sentar para programar sem ter a menor noção do que estava acontecendo antes. É uma simulação da vida real: você chega para trabalhar num projeto que já começou, tem código legado. O seu par deve conseguir te explicar o que foi feito até então e vocês precisam avançar com o código. Depois de 7 minutos, o seu par sai e agora fica com você a responsabilidade de explicar para o próximo o que foi feito e continuar resolvendo o problema. Algumas regras do Kake Dojo:

• Dois ou mais computadores, dependendo da quantidade de participantes
• Turnos de 7 minutos
• TDD, baby steps, refatorações continuam sendo obrigatórios
• Divertir-se é obrigação: bater papo, contar piadas, cantar uma música, jogar video game, vale TUDO, menos olhar os outros programando
• Comida durante toda a sessão (pizza, sanduíche de metro ou jantar gourmet)
• No final fazemos uma retrospectiva usando a técnica dos 6 chapéus

Algumas cenas do último Dojo Kake que realizamos em 2009 podem ser vistas no vídeo:

Vamos fazer um Dojo Kake na próxima 3a. feira, dia 17 de agosto as 20h. Quem estiver interessado em participar, mande um e-mail para mim: danicuki arroba gmail ponto com.

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…

Sexta-feira dessa semana acontecerá o Oxente Rails, o maior evento de Rails do Nordeste do Brasil. O evento será em Natal e terá a presença de pessoas importantíssimas da comunidade Rails, não só do Brasil, mas do mundo todo. Veja a lista de palestrantes. Alguns deles são: David Hanson (criador do Rails), Fábio Akita (evangelista de Rails no Brasil), Vinicius Teles da ImproveIT, Fabio Kung. A abertura do evento será feita pelo Aldinho (irmão de Elomar). Com certeza esse será um dos grandes eventos do ano.

Eu vou para o Oxente Rails, onde apresentarei a palestra Pensamento e Aprendizado Ágil. Também estarei lá para bater papo com todo mundo, falar de Rails, Ruby, Agilidade e outras coisas nerds. E conforme prometido no vídeo abaixo, cantarei AO VIVO o forró do Elomar! Não perrrrrrrrrcam. A gente se vê lá, bixim danado, cabra da péxti!

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.

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…

Here are the slides of a talk I gave to young people, from  14 to 16 years, about how is the life of a Computer Scientist. Some time ago, I’ve made a blog post with 15 question and answers about Computer Science. I hope this presentation and the blog post can be useful to teenagers. I know choosing the course which will be your life for the next 4 or 5 years is not an easy task, so, the more information available the better. And don’t forget: every time is time to change and make other choices.

This weekend I was working at the first Random Hack of Kindess mundial edition. There were 4 people in our team and we worked on a project called Urban Fact (Fato Urbano in Portuguese). The main idea of this project is to emphasize GOOD orBAD facts in your city. If you see someone throwing the garbage over the streets, just take a picture and post it on twitter using #urbanfact hashtag (or #fatourbano). This picture automatically  goes to the project website, where people can vote, comment and share with friends.

For the solution, we used Rails for the web interface, MySql as database and Python for the backend twitter collector. We also used Google Maps API to automatically generate the map with all entries. All code is available at my github account. We hosted the website in a Locaweb Cloud Server.

Our project earned the 2nd best project prize!

Visit my flickr account to see the pictures of this event.

It took a long time, but I finally migrated my old blogspot blog to Wordpress. Please, give me your feedback about the new blog’s layout. I hope I can create much more content for you, with this incredible tool.