AgileAndArt

Como muitos de vocês sabem, hoje é o meu último dia de Locaweb. Foram 4 anos, muitos projetos, muitas linhas de código escritas, alguns servidores colocados em produção, alguns legados arrumados, várias tecnologias e técnicas novas aprendidas. Durante esses mais de 4 anos de empresa, aprendi muita coisa com muita gente, das quais me orgulho muito de ter conhecido e trabalhado junto. Vocês me ensinaram muito, me ajudaram muito e gostaria de dizer que sou profundamente agradecido por isso.

Queria ressaltar algumas pessoas que realmente fizeram diferença para mim. Sei que ao citar nomes corro o risco de esquecer alguém, mas decidi correr esse risco. Fiz uma retrospectiva de todo tempo que estive na empresa e me esforcei para tentar lembrar de cada momento, de cada pessoa.

• Todos da minha época de Telecom. Essa eu considero a minha ‘época áurea na Locaweb’ e só foi assim graças a esse pessoal supimpa: Renato Pereira, Dov Bigio, Franklin Alves (Biriri), Gustavo Barrancos, Roberto Klein, Evandro Saroka, Adolfo Sousa, Victor Cazzonato, Fernando Urzedo, Luis Henrique
• Às pessoas de sistemas centrais com as quais eu tive mais contato: Natelson Nascimento, Henrique Macedo, Koiti Takahashi, Mozair Alves, Juliana Barros, Marcelo Kato, Gustavo Santana (Garotinho)
• Ao time de Infra-dev, um time do qual fico muito feliz de ter criado na Locaweb. Foi muito bom trabalhar com vocês: Bruno Diniz, Fabio Yamasaki, Fernando Meyer, Rodrigo Fernandes, Herbert Francarelli, Rachad Ronein, Roberto Klein e Vinicius Caldo
• Aos meus amigos da banda Toxoplasmose, que durou pouco mais foi muito divertida: Fabio Perrela, Vitor Paixão, Heitor Nicoliello, Marcelo Fujiwara, Alexandre Conceição, Paulo Giovani
• Aos Gurus que me ensinaram muito, muito mesmo: Maurício Dediana, Fabio Kung, Rafael Rosa, Antônio Marques, Fabio Akita, Alexandre Freire
• Às pessoas do RH da Locaweb, sempre prontos para me atender, seja como profissional ou como amigo: Celso Paulon, Luiz Silva, Cristiane Barberino
• As pessoas do Marketing, que sempre me apoiaram nas iniciativas com as comunidades: Luis Carlos, Carlos Gonçalves, Katia Barreto
• Sem deixar de mencionar alguns que são pessoas incríveis, tanto como colegas de trabalho quanto fora da Locaweb: Maurício e Fernando de Amorim, Ricardo Lemke, Maurício Aniche, Andre Luis de Oliveira, Fabio Hisamoto, Thiago Scalone, Caio Spadafora, André Muraro, Lucia Romão, Andre Cepukas, Andrew Andrade, Marcia Maia, Andreza Vasconcelos, Fernando Zangrande, Thiago Morelo, Nando Vieira, Carlos Mendonça, Fernanda Machado.
• Aos diretores que me acolheram aqui na empresa, me respeitaram e deram espaço para que eu pudesse trabalhar com liberdade: Gilberto Mautner, Cláudio Gora, Francisco Zapata, Joaquim Torres.

A todos vocês da Locaweb, desejo muito sucesso e o meu MUITO OBRIGADO!

Daniel

Há algum tempo, fizemos uma peça de teatro que ensina os conceitos de Domain Driven Design (DDD). O foco desse teatro é a parte de Projeto Estratégico (Strategic Design) de DDD. Essa peça é baseada no roteiro escrito pelo próprio Eric Evans. Em 2008, na QCON SF, eu participei de um Workshop de DDD com o Raph Johnson. Depois fiz a tradução do roteiro, que pode ser baixado aqui.

Para saber mais sobre DDD, leia esse post no meu blog.

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.

É muito fácil escrever um programa em Ruby para importar todos os seus contatos do Google na sua conta de e-mail Marketing da Locaweb. Com um simples script de 25 linhas isso é possível. Veja:

EMAIL_MKT_CHAVE = "[SUA_CHAVE]"
GOOGLE_EMAIL = "[SEU EMAIL NO GOOGLE]"
GOOGLE_PASSWD = "[SENHA GOOGLE]"
EMAIL_MKT_HOST = "[MAQUINA EMAIL MKT]"
EMAIL_MKT_LISTS = "11115"
EMAIL_MKT_LOGIN = "[LOGIN EMAIL MKT]"
EMAIL_MKT_URL = "http://#{EMAIL_MKT_HOST}.locaweb.com.br/admin/api/#{EMAIL_MKT_LOGIN}/contatos/importacao/?chave=#{EMAIL_MKT_CHAVE}&listas=#{EMAIL_MKT_LISTS}"
 
login = {:accountType => "HOSTED_OR_GOOGLE",
	              :Email => GOOGLE_EMAIL,
	              :Passwd => GOOGLE_PASSWD,
	              :service => "cp",
	              :source => "danicuki-teste-1"
	             }
a = RestClient.post("https://www.google.com/accounts/ClientLogin", login)
auth = {"Authorization" => "GoogleLogin auth=#{a.split.last.split("=")[1]}"}
c = RestClient.get("https://www.google.com/m8/feeds/contacts/default/full?max-results=2000", auth)
contacts = Hash.from_xml(c)["feed"]["entry"]
emails = contacts.select {|c| !c["title"].blank?}.select {|c| !c["email"].blank?}
email_mkt_hash = emails.map do |c|
	{:nome => c["title"].split[0].camelize, :email => (c["email"][0] ? c["email"][0]["address"] : c["email"]["address"])}
end
RestClient.post(EMAIL_MKT_URL, email_mkt_hash.to_json)

Agora a descrição dos passos do código:

1. Primeiro você define todos os parâmetros para a sua busca. Os dados sobre a sua conta de e-mail Marketing podem ser obtidos na documentação da API da Locaweb.
2. Depois faz um post para obter a credencial do google, que será usada logo mais para buscar os contatos. A credencial é retornada em formato texto, uma string bem feiona tipo essa: SID=DQAAAJcAAAAGD-h4PWkAfqRPrDJcIVmiPg1qq1pDPCbY-1DykHzaSmxrpIqIYjUNdqYUjDgLJRmKZstgafFhHa0CIajl-SIlAKPLr2Ll-wuQhC5z-DFQ66mybDfiPlig5osdQ-Uf6JlFdfHGnKiQk4xfqHvg3xm0SFqwg2SQDIBXI-iidkkIjnS7F4Z8FYVP_bGj_26JYr7S6FTA3jNxiUS7QewUsk7d
   LSID=DQAAAJkAAAAPZxYEjHLtrIT6pO-E7hVvM_1khNV7FWfdsr1BMjqwHmfuuabdMSPwv9gHBvd8eHiO8lrMv2ugwGFB7eKxe5WiNQ_uBy3u9aOy8jrqCT_Gx_LRSEE2gyvX8aiGtdpLCiGxTjhCRz5S-wz2g4Qo6uwt-Rdh3xgocPEvSQeiF1Eqr5N5c8_eN0Kn-Gr6WBIsFm6mlyZqUKLSuROK1rL7WpMu
   Auth=DQAAAJkAAAAPZxYEjHLtrIT6pO-E7hVvM_1khNV7FWfdsr1BMjqwHmfuuabdMSPwv9gHBvd8eHh4LIFHdmGkr75M6OHTAjZf3T4n2Q8GwqyAu5G73NA9dnkDbC3q-AsdnZOV7eP6uSF_jhvZYrGmOzAARthZ9BCcmaz2y2eWCUdYzUE0vdNDgYlhAh2ybT21M4KHXFP5T6JfXN8wZVrVEiWhcaqP2MfI

   Para a chamada a API, a única coisa que interessa nessa string é o valor de Auth, que extraímos com o código

   a.split.last.split("=")[1]

3. A API do Google Contacts é bem simples, porém o XML que ela retorna é um trambolho. Nesse momento estamos interessados em apenas montar um hash com o primeiro nome da pessoa e o e-mail. Fazemos isso nessas linhas:

   #contacts conterá um array de contatos
   contacts = Hash.from_xml(c)["feed"]["entry"]
   #filtra apenas contatos que tenha nome e email definidos
   emails = contacts.select {|c| !c["title"].blank?}.select {|c| !c["email"].blank?}
   #monta o hash - o nome é apenas a primeira parte do titulo 'camelized'
   # o email tenta o campo 0, se tiver coloca, senão é o próprio address (chatices...)
   email_mkt_hash = emails.map do |c|
   	{:nome => c["title"].split[0].camelize, :email => (c["email"][0] ? c["email"][0]["address"] : c["email"]["address"])}
   end

4. Por último transformamos o hash em JSON e enviamos para o Web Service do Email Marketing.

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.

Fiz um resumo do ambiente de desenvolvimento da LocaWeb Telecom e o produto PABX Virtual, contando algumas soluções e técnicas que usamos em nossos testes de aceitação.

Durante 9 meses de trabalho no projeto do Pabx Virtual da LocaWeb, coletamos informações estatísticas do código do projeto. Baseado nessas informações tirei algumas conclusões.
No gráfico à direita vemos claramente que o projeto tinha inicialmente muito código duplicado. Depois de várias Refatorações, foram removidas duplicações e o código ficou muito mais limpo e fácil de alterar.

No gráfico seguinte vemos que, enquanto o número de linhas de código diminuiu
drasticamente, o número de linhas de código de
teste aumentou, o que significa que além de desenvolver novas funcionalidades, melhorar a qualidade do código do produto, ainda criamos uma série de testes automatizados que ajudam a garantir a qualidade do sistemas nas próximas versões.

No próximo gráfico vemos que o número de classes do sistema aumentou bastante, indicando que houve um aumento na modularização e reutilização do código. Mais classes com menos código significa maior especialização das classes, métodos menores e também maior testabilidade.

Todos estes números nos ajudam a ver que a metodologia adotada foi eficaz para melhorar e manter o projeto. Algumas práticas de XP adotadas pela equipe foram: programação pareada, releases curtos, jogo do planejamento, refatoração, design simples, cliente sempre presente, padronização de código.