AgileDay 2013: CbE estava em peso

agileday2013Em dezembro, para fechamento do ano, o CbE participou em peso do AgileDay 2013, que aconteceu dia 11, no UniRitter.

O evento contou com palestras de gaúchos em eventos nacionais, como AgileBrazil e AgileTrends.

Nós participamos com várias palestras, ministradas pelo Guilherme Elias, Daniel Wildt, Rafael Helm, Maurício Andreazza e Guilherme Lacerda.

Além das palestras, promovemos também um fishbowl para discutir qualidade de código, testes, refatoração e tudo mais que é relevante para se entregar software de valor, que possa ser mantido e evoluído de forma mais natural.

BbOgnu_IQAAduI8

4a. do Conhecimento: Palestra na PROCERGS

DivulgaçãoNo dia 27 de novembro, fui convidado pela galera da PROCERGS, para ministrar uma palestra em um evento interno que eles tem, que é muito legal: a 4a do Conhecimento. Detalhe: esta bela iniciativa, que deve ser incentivada em outras empresas, está comemorando 10 anos! Parabéns PROCERGS, pelo exemplo!

Neste dia, escolhi falar um pouco sobre retrospectiva, o que considero e embaso muito o meu trabalho de coaching como uma ferramenta essencial de transformação, de formação de equipes. Este foi o ponto principal do nosso bate-papo, que durou mais de 2 horas! Foi legal, porque a companhia, já há um tempo, está passando por esta transição, formando e preparando times para trabalhar com agilidade.

DSC09010Parabéns a todos pelo excelente trabalho de disseminação de Métodos Ágeis (Suzana, Jamile, Dionatan, Marcelo, Petrillo!, entre outros tantos). Eu sei que não é fácil :)

Agradeço o convite do Dionatan e parabenizo o excelente trabalho do Jaime  e do Cleon Espinoza, sobre Gestão do Conhecimento.

Abaixo, está disponível a apresentação realizada.

Continuous Delivery – Em Busca da Entrega Perfeita!

No dia 2/Out, tivemos o privilégio de estar realizando acima de tudo uma grande troca de experiência com o pessoal da PROCERGS, onde desta vez o Maurício e eu representamos o CbE falando um pouco sobre experiências e boas práticas na entrega de software em produção.

No bate papo que intitulamos de “Continuous Delivery – Em busca da entrega perfeita“, buscamos levar um pouco da experiência adquirida em alguns projetos bem como procuramos levar algumas dicas de ferramentas e boas práticas que de forma direta ou indireta influenciam na entrega de software com alto nível de valor a nossos clientes.

E como de costume, também não faltou descontração, traçando assim alguns paralelos com o nosso dia-a-dia no desenvolvimento de software ;-)

Seguem os slides da apresentação:

Database Refactoring

Contextualização

Refatoração de código (Code Refactoring) é uma disciplina/processo que consiste em melhorar a estrutura interna de um software sem modificar seu comportamento externo, e uma Refatoração de Banco de Dados (Database Refactoring) parte do mesmo princípio, porém além de manter o comportamento externo também deve manter a semântica da informação que ele mantém/armazena, e por esse motivo é considerada mais difícil.

Um outro conceito que posso destacar a respeito de Database Refactoring é:
“Mudança disciplinada na estrutura de uma base de dados que não altera sua semântica, porém melhora seu projeto e minimiza a introdução de dados inconsistentes”
O ponto interessante deste último é o texto “minimiza a introdução de dados inconsistentes“, pois esse é o grande objetivo de realizarmos um refactoring na estrutura de um banco de dados, ou seja, melhorar o desing atual para melhorar a consistência dos dados e também a qualidade dos novos dados que serão adicionados ao seu banco de dados.

E esta tarefa não é das mais simples, pois existe um fator preponderante no que diz respeito a dificuldade de execução deste tipo de refactoring, que é o acoplamento.

Acoplamento

dataRefactoringBestCase

Figura 1. Baixo Acoplamento

É a medida de dependência entre dois elementos. Quanto mais acoplados dois elementos estiverem, maior a chance que a mudança em um implique na mudança em outro.

Simples assim, quanto mais o seu banco de dados estiver acoplado, ou seja, dependente de diversas aplicações externas, mais difícil será a aplicação de um refactoring.

dataRefactoringWorstCase

Figura 2. Alto Acoplamento

A figura 1 demonstra um cenário “Single-Database Application” que é bem simplificado, onde a aplicação de um refactoring será mais tranquilo. 

Com certeza o cenário da Figura 2, o “Multi-Database Application” é o pior caso, pois exige muito cuidado e planejamento para execução do refactoring, então veremos a seguir uma sugestão de processo para execução.

Processo de refatoração

databaseRefactoringProcess

Figura 3. Processo de Database Refactoring

Um processo é um conjunto organizado de atividades com um objetivo em comum. Executar um database refactoring em um cenário “Single-Database Application” ou “Multi-Application Database” requer um processo, por mais simples que seja. A grande diferença na execução em ambos cenários é que no caso do “Multi-Application Database” o período de transição (mais abaixo falaremos) geralmente será mais longo.

É bom sempre ter em mente que um database refactoring, como já vimos, não é uma atividade simples então caso seja identificada a real necessidade de refatorar um banco de dados então podemos usar o seguinte roteiro (processo) para se guiar:

  • Escolher o refactoring mais apropriado;
  • Depreciar o esquema original;
  • Testar antes, durante e após;
  • Modificar esquema;
  • Migrar os dados;
  • Modificar código externo;
  • Executar testes de regressão;
  • Versionar seu trabalho;
  • Anunciar o refactoring.

Na Figura 4 é demonstrado um pequeno processo descrevendo um fluxo básico para aplicação de um refactoring.

process-refactoring-regra-geral

Figura 4. Regra Geral Processo Refatoração

Atente bem para o “Período de Transição”, que é a fase mais importante, principalmente para cenários “Multi-Database Application” (Figura 2), onde você precisa ter em mente que não conseguirá realizar o refactoring e fazer o deploy em produção de todas as aplicações ao mesmo tempo. A grande verdade é que muito provavelmente você nem consiga alterar todas as aplicações ao mesmo tempo, principalmente se você tiver dependência de terceiros, então você precisará suportar o esquema original e o esquema resultante ao mesmo tempo, para somente quando todas aplicações estiverem suportando apenas o esquema resultante, ou novo esquema, você poderá aposentar de vez o antigo esquema e assim finalizar este período.

Estratégias de Database Refactorings

Existem alguns pontos a considerar com estratégias para adoção de um database refactoring:

  • Pequenas mudanças são mais fáceis de aplicar;
  • Identifique unicamente cada refactoring;
  • Implemente uma grande mudança realizando várias pequenas mudanças;
  • Tenha uma tabela de configuração/versionamento do seu banco de dados;
  • Priorize triggers ao invés de views ou sincronizações em lote;
  • Escolha um período de transição suficiente para realizar as mudanças;
  • Simplifique sua estratégia de controle de versão de banco de dados;
  • Simplifique negociações com outros times;
  • Encapsule acesso ao banco de dados;
  • Habilite-se a montar facilmente um ambiente de banco de dados;
  • Não duplique SQL;
  • Coloque os ativos de banco de dados sobre controle de mudanças;
  • Seja cuidadoso com políticas.

Os items acima mostram apenas algumas sugestões, em forma de “lições aprendidas”, de algumas estratégias que você pode considerar quando tiver a necessidade de realizar um refactoring.

Para apoiar essas estratégias existe um catálogo que descrevem diversos tipos de refactorings em bancos de dados e exemplos de uso, que veremos a seguir.

Catálogo de Database Refactorings

Este catálogo é dividido em algumas categorias:

  • Structural: são mudanças na estrutura do banco de dados (tabelas, colunas, visões, etc).
  • Data Quality: são mudanças que melhoram a qualidade das informações contidas em um banco de dados.
  • Referential Integrity: são mudanças que asseguram que uma linha referenciada exista em outra relação e/ou assegura que uma linha que não é mais necessária seja removida apropriadamente.
  • Architectural: são mudanças que melhoram a maneira que programas externos interagem com a base de dados.
  • Method: são mudanças que melhoram a qualidade de uma Procedure um Função.
  • Transformations: mudanças que alteram a semântica do esquema do banco pela adição de novas funcionalidades.

No meu github é possível encontrar exemplos práticos de aplicação passo-a-passo de um refactoring em um modelo inicial, passando por um período de transição e chegando ao modelo final.

Considerações Finais

Devemos levar em consideração que apesar destas técnicas serem direcionadas para refatoração, ou seja, mudar estrutura sem mudar sua semântica, as mesmas podem e devem ser utilizadas para evolução da sua aplicação, ou seja, se você precisa construir uma nova feature em sua aplicação que está em produção, você poderá recorrer das práticas aqui apresentadas para evoluir seu esquema de forma mais consistente e segura.

Baseado no exposto podemos facilmente responder a pergunta “Por quê Refatorar?”:

  • aceitar mudança de escopo;
  • fornecer feedback rápido;
  • melhoria contínua;
  • aumentar simplicidade para facilitar entendimento;
  • tornar os modelos mais próximos do mundo real;
  • termos modelos simples para facilitar:
    • manutenção e
    • evolução da aplicação

E para refatorarmos precisamos ter conhecimento, disciplina, simplicidade, bom senso e persistência, sem contar no ponto fundamental que é organização.

Referências

FISL 14

fisl14O CbE estará presente no FISL 14 – Fórum Internacional de Software Livre, com duas palestras. Abaixo, segue o resumo delas:

  • Troca de figurinhas – Como criar um ambiente de aprendizagem em sua equipe? Sabemos que desenvolver software requer conhecimento, seja este oriundo da leitura de livros e salas de aula, e/ou obtido através de experiências em projetos anteriores. Mas como você repassa conhecimento para outras pessoas? Talvez você nunca tenha pensado nisto, ou até já pensou mas não soube como fazer. Se este for o seu caso venha conhecer o que algumas empresas tem feito para distribuir conhecimento entre seus funcionários. Acredite, isto pode fazer a diferença e manter sua equipe motivada. Esta palestra será realizada por Rafael Helm e Guilherme Elias.
  • Integração e entrega contínua de produtos? Que venha o eXtreme Programming! Sabemos que desenvolver software requer conhecimento, seja este oriundo da leitura de livros e salas de aula, e/ou obtido através de experiências em projetos anteriores. Mas como você repassa conhecimento para outras pessoas? Talvez você nunca tenha pensado nisto, ou até já pensou mas não soube como fazer. Se este for o seu caso venha conhecer o que algumas empresas tem feito para distribuir conhecimento entre seus funcionários. Acredite, isto pode fazer a diferença e manter sua equipe motivada. Palestra ministrada por Guilherme Lacerda e Daniel Wildt.

Com 14 anos de história, o Fórum Internacional Software Livre já se consolidou como o mais significativo encontro de comunidades de Software – e cultura! – Livre na América Latina, com cerca de 5 mil participantes. Este é o resultado do trabalho, da colaboração e do envolvimento de milhares de pessoas que acreditam nas soluções tecnológicas e educacionais livres e na força de uma comunidade atuante em todo o mundo.

O FISL 14 acontece de 3 a 6 de julho de 2013, em Porto Alegre.

CbE no Agile Brazil 2013

agilebrazil2013

O CbE estará presente no Agile Brazil 2013, que acontece em Brasília, de 26 a 28/06. Os temas apresentados serão:

  • “Baby Steps Game” - Tutorial que ministrarei com o Émerson Hernandez (ThoughtWorks), que substituirá o Carlos Lopes. Resumo:“’Baby steps’ é um mantra ágil, indicado tanto para práticas de gestão quanto do ponto de vista técnico.
    Mas como exercitamos esta prática? Como podemos exercitar práticas como design simples, move people around, programação em pares, TDD e refatoração, entendendo a essência deste mantra? Em especial, como podemos integrar código várias vezes por dia, de forma segura e consciente? Venha participar desta divertida dinâmica de programação e entender o real benefício e poder dos baby steps.”
  • “No movimento da Agilidade – o time de desenvolvimento deve virar o time de marketing!”  - Palestra que será ministrada pelo Daniel Wildt e pelo Rafael Helm. Resumo: “Quando um time inicia o trabalho com métodos ágeis, inicia a busca por uma cultura de prevenção e aprendizado. Por um processo de entrega de valor de forma constante aos clientes. Aprende que não é suficiente ter um ritmo para entrega de software. Deve ser entregue software de valor, que traga algum tipo de retorno para o cliente. E quanto mais um time avança no trabalho com produtos, começa a se preocupar com questões como aquisição de novos clientes, conversão, retenção, a busca por fazer estes clientes se tornarem seguidores e pessoas que possuem grande empatia pela marca ou produto em questão. E tudo isto faz o trabalho de um desenvolvedor evoluir, para trabalhar outros skills que passam a ser esperados em um desenvolvedor.”

Em breve disponibilizaremos o material da palestra e tutorial. Aguardem!

Pratique para sempre

Originally posted on Pingos de Agilidade:

karate-kidPraticar para evoluir é algo necessário na vida de qualquer pessoa. Desde criança, usamos a prática como forma de aprendizado e evolução, basta você puxar da memória para lembrar como foi necessário praticar até conseguir amarrar os cadarços de um calçado sozinho, sem precisar da ajuda dos pais.

Atletas chamam está prática de “treino”. Atletas treinam quase que diariamente, muitas vezes de forma exaustiva e repetitiva. Se você acha que o jamaicano Usain Bolt (recordista mundial e bi-campeão olímpico nos 100 e 200 metros), atingiu o alto nível através de talento e boa genética (sorte), então de uma olhada neste vídeo e veja como ele treina.

É bem provável que ainda hoje você vai precisar executar alguma tarefa que não se sente confortável, que ainda não praticou o suficiente. Alguém pode te ensinar algo, te dar uma introdução ou até uma explicação bem detalhada; você pode ler livros e fazer treinamentos, mas muitas vezes…

View original 374 more words

Novas seções no blog

Olá,

Estamos atualizando novamente o blog. Em breve, teremos o acréscimo de duas novas seções, descritas brevemente a seguir:

  • Book List: Indicaremos uma lista de livros técnicos e não técnicos, com comentários, revisões e dicas de leitura, voltados a profissionais de desenvolvimento de software. Temos certeza que esta lista deve fazer parte de sua leitura e que ajudará muito na sua prática profissional.
  • Tutoriais: Estamos montando vários tutoriais voltados a ferramentas e técnicas de  apoio que podem ser usadas no dia-a-dia do profissional de software.

Não deixe de acompanhar!

Agile Day Porto Alegre 2012 – Terceira Edição

Ocorreu hoje na Faculdade UniRitter, campus Porto Alegre, prédio D a terceira edição do Agile Day 2012 (#agileday). O evento contou com a presença de mais de 100 inscritos, com palestras que abordaram temas desde a engenharia de software, empreendendorismo, startup dojos, dinâmicas e entre outros. A programação completa pode ser acessada aqui.

Como não podia ser diferente,  o pessoal do CbE esteve presente em peso :-)

Às 10h30min o @guilhermeslac apresentou um resumo da palestra apresentada no Agiles este ano, onde o nome nada mais nada menos foi “Coding by Example” :-)

No mesmo horário, @dwildt também falou sobre “MVP! Criando a 1ª versão do produto” onde rolou um startup dojo com a galera presente. Na parte da tarde @dwildt também falou em uma lightning talk sobre “Sustenable pace”. Os slides estão destas apresentações estão disponíveis aqui.

Também ocorreu, após a palestra do @guilhermeslac, @guilhermelias (eu :)) bati um papo literalmente com a galera sobre “Continuous Practices – Hábitos que vieram para ficar”, onde foram discutidos principais problemas e dificuldades enfrentadas no dia-a-dia das equipes de desenvolvimento, apresentando deste forma boas práticas e algumas ferramentas como solução a problemas conhecidos ou então para medir qualidade de código.