AgileAndArt

The Art Improving Agile Software Development

Browsing Posts published in July, 2010

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!

Switch to our mobile site