Para complementar nosso portifólio de cases ISV, no mês de maio a Aurum, uma empresa direcionada para soluções no mercado jurídico com o seu produto Themis, nos contactou para trabalharmos juntos na transição Agile.

Além do treinamento para aproximadamente 15 pessoas na Aurum, tivemos excelentes sessões de coaching nos primeiros plannings, reviews e retrospectives. Em todas as nossas propostas incluímos entre 8 a 40 horas de consultoria para auxiliar as empresas nas suas implantações de processos ágeis. Com isso, acompanhamos as equipes nas primeiras Sprints, tirando dúvidas, mostrando técnicas e atuando como agente facilitador. Essa tem sido a nossa estratégia em muitos clientes e vemos que somente treinar pode deixar as equipes com muitas dúvidas que algumas horas de coaching eficiente resolvem facilmente.

No caso da Aurum foi bastante interessante como logo na primeira Sprint do projeto piloto a equipe assumiu um compromisso de melhorar também suas práticas de engenharia com uma arquitetura orientada a objetos em Delphi e testes automatizados. Pelo relato deles, a inspeção e adaptação foram determinantes para a entrega do primeiro release Agile que foi um grande sucesso.

Parabéns a todos da Aurum pela determinação e inovação. Muito sucesso!

Treinamento

Equipe no primeiro Planning do projeto piloto

Review & Retrospective Boards nas primeiras Sprints

Fiquei impressionado com o direcionamento dos produtos da e-Deploy. Realmente eles estão alinhados com as idéias novas da Web e com certeza terão sucesso com práticas ágeis.

(ao pessoal da e-Deploy, temos a pendência daquele pairing em Objective-C)

Atividades em Grupo

Sprint Planning

Como consta no nosso programa, o treinamento Extreme Programming foi reformulado para reforçar mais práticas de TDD. Na LBS Local usamos Java, VRaptor 3, JUnit, Mockito, JPA, JBehave e WebDriver numa arquitetura que está disponível no meu GitHub. Divirtam-se!

Foram dois dias muito produtivos com muita troca de experiências, pairings divertidos e muitas discussões sobre Orientação a Objetos, Agile, Cloud e Arquitetura Web.

A equipe Apontador está agora criando uma API aberta para desenvolvedores que deverá ser liberada em breve. Vem novidade por aí!

Pareando com o pessoal

Toda a turma! Parabéns a todos do Apontador

Com os métodos ágeis tomando o mercado de norte a sul do país, a CVale no desejo de melhorar seus processos adotou práticas do Scrum na sua gestão. Porém, a empresa teve dificuldades com algumas práticas do Scrum, especificamente o Time-boxed Sprint. Como já citei aqui no blog, desde o final de 2008 tenho estudado o paradigma do ciclo contínuo com abordagens Lean e Kanban. Minha linha de estudo está baseada principalmente nos autores Alisson Vale, David J Anderson, Don Reinertsen e Alan Shalloway. No caso da CVale, uma equipe super enxuta de TI atende a diversas unidades de negócio - de uma financeira até uma beneficiadora. E por conta disso, o ritmo das demandas e a dinâmica do negócio não permitem o uso de iterações com escopo fixo, e se as iterações não se cumprem por conta de mudanças constantes usar Time-boxes leva a uma dinimuição da importância dos planejamentos e a uma certa frustração da equipe.

Com isso a Aspercom recomendou um direcionamento da empresa para a filosofia Kanban de fluxo contínuo, limitar Work In Progress e visualização do processo. Logicamente este Kanban está recheado de práticas do Scrum como o uso de um Backlog priorizado pelas áreas usuárias. A equipe também desfruta de uma excelente auto-organização e comunicação intensa.

Estarei escrevendo mais aqui no blog sobre Kanban e abordagens Lean. Sucesso a todos da CVale!

Em Março estive junto ao animado pessoal da BSA ministrando o nosso treinamento Scrum. A BSA é uma consultoria pequena que também está trilhando o caminho ágil para projetos de grandes empresas Telecom.

No treinamento da BSA aplicamos um treinamento/coaching simultâneo, onde usamos um projeto real da empresa como base para as atividades práticas do treinamento, fazendo o release planning, escrevendo stories e planejando a primeira Sprint.

Parabéns a todos da BSA e muito sucesso!

A Aspercom está patrocinando o Agile Brazil. É o primeiro evento grande que patrocinamos e isso abriu uma grande gama de dúvidas em nós, principalmente porque sempre vemos patrocinadores de evento como aqueles caras que entulham as sacolas de panfletos inúteis e colocam meninas bonitinhas para chamar a atenção no stand. Nada contra a estratégia de marketing de ninguém, porém, sempre pensei em fazer algo diferente num evento, principalmente um encontro tão excelente como o Agile Brazil com mais de 800 participantes.

Inicialmente, ao invés de um panfleto comercial, fizemos um adesivo simples sem muita invasão publicitária que o participante pudesse colar no notebook e assim expressar seus sentimentos na empresa que trabalha. Postei o modelo do adesivo no meu Twitter. Mas o motivo deste post não é o adesivo, e sim o projeto que quero propor para ser desenvolvido durante o Agile Brazil.

Na semana passada tive a idéia de fazer algo diferente no evento. Pensei que seria legal fazer um projeto ágil, e assim, mostrar a força da comunidade brasileira desenvolvendo um produto simples mas útil durante o Agile Brazil com o trabalho dos participantes do evento. Eu realmente acho que podemos chamar a atenção do mundo com esse projeto.

No vôo para Porto Alegre bolei um sisteminha que cabe como uma luva para esse propósito. Modelei algumas coisas rapidamente e já tenho uma visão no Github.

http://github.com/rodrigoy/kanban_sketch

Mesmo o projeto sendo simples vamos precisar de pessoas com muita criatividade e conhecimento em Rails, DSL, Http, Webdesign, deployment e etc.. O nosso QG será o stand da Aspercom no evento onde teremos um kanban para organizar as tarefas. Pretendo atuar mais como Product Owner, pareando com o pessoal quando necessário.

A parte que cabe a Aspercom é a premiação. Além de dar os créditos na página do produto na web, nós vamos sortear entre os participantes do projeto um vale compra da Amazon no valor de US$ 150. Qualquer pessoa que colaborar com código, design, testes, arquitetura ou simples boas sugestões farão parte do sorteio.

Tendo dúvidas ou comentários podem postar aqui ou usem a hashtag #ProjetoAgileBrazil no Twitter.

Nesta edição, meu artigo entitulado “Patterns no Desenvolvimento de Software Moderno” é um apanhado de conceitos sobre alguns patterns revisitados, esquecidos e novos na nossa caixa de ferramentas. Quem viu algumas palestras minhas em 2009 sabe do que estou falando: equipes ágeis estão pecando em algumas práticas OO, mesmo usando bons testes automatizados. Tem muita equipe gerando monstros monolíticos orientados a testes. Como é costume aqui no Débito Técnico, segue o chorinho do artigo:

O Design Moderno visa a Testabilidade

A maior diferença que destacamos sobre a orientação a objetos comparada com o paradigma procedural é o encapsulamento. Ao contrário do que tínhamos no modelo procedural, um design orientado a objetos não é um conjunto de algoritmos encadeados no estilo “entrada-processamento-saída”. Objetos possuem estado e trocam estímulos através de mensagens. As mensagens que o objeto responde fazem parte da sua interface pública. Como disse, uma mensagem pode ser uma simples chamada de método, assim como um estímulo remoto, assíncrono que veio de uma fila que você nem sabe qual é. Objetos possuem encapsulamento forte, e os objetivos do sistema são cumpridos com a colaboração entre eles através da troca de mensagens.

Dado esta característica dos objetos, podemos facilmente testar sua implementação através de testes de unidade. Eu me lembro muito bem quando meu professor de lógica de programação falou que um compilador só consegue detectar erros de sintaxe do meu programa, mas não erros de lógica. “A sintaxe pode ser checada pelo computador, mas não a lógica”, dizia ele. Eu creio que atualmente nós podemos desafiar esse conceito usando testes automatizados e práticas de desenvolvimento orientado a testes (TDD). É possível sim validarmos a lógica de um programa assim como o compilador (ou interpretador) faz com a sintaxe.
É uma premissa fundamental que os objetos tenham somente uma responsabilidade, assim como é importante que eles tenham um encapsulamento que proteja seu estado. Se um objeto tem uma interface pública e esta pode ser utilizada por qualquer outro componente, temos todo ferramental para concentrar testes nessa interface, e assim, conseguimos validar deterministicamente se a lógica do componente funciona.

Além disso, se escrevermos os testes antes da implementação teremos uma descrição muito clara da interface necessária. Nosso componente será simples, pois atenderá somente aquilo que nosso teste exige. Desenvolver a aplicação orientada a teste (TDD) é uma das melhores ferramentas para ter um bom design, além de nos dar segurança para evoluirmos o design refatorando sempre que necessário. Ter bons testes tira o nosso medo em mexer naquelas partes obscuras do código. Refatoração só existe de forma segura com testes.

Muitos desenvolvedores questionam como testes podem melhorar o design. Ora, a resposta é bem simples, e está relacionada com os conceitos defendidos neste artigo como coesão, acoplamento e dependências: se um design a priori é difícil de testar isoladamente (com testes unitários) consequentemente é um design acoplado e difícil de manter. A facilidade de testar os componentes é proporcional à qualidade do seu design.

É muito interessante que o Erich Gama na entrevista desta edição mencionou que a Injeção de Dependências (DI) seria um padrão digno de entrar na obra do GOF. As soluções atuais de DI garantem uma melhor testabilidade, pois todas as ligações são feitas externamente à inteligência do próprio componente, permitindo o uso de Mocks e Stubs para simular o comportamento dessas dependências durante um teste de unidade.

Tenho discutido muito sobre design de software com várias pessoas e vejo que a falta de testes é uma das piores faltas em design. É melhor ter um design ruim com testes do que ter um design bom sem testes. O design ruim com testes você pode com segurança refatorar para que ele se torne um bom design. Com um design bom sem testes você não tem nada! Concluindo, um bom design inclui testes.

No ano de 2009 eu tirei “férias” da MundoJava. Minha coluna MundoOO precisava de novas idéias e eu mesmo já estava com assuntos esgotados. Para o ano de 2010 estarei escrevendo uma outra coluna chamada MundoAgile, onde vou compartilhar sobre meu dia-a-dia como Agile Coach, e as dificuldades que tenho nas minhas implantações Scrum e XP. Espero que gostem!

BOM DESIGN É INOVADOR
BOM DESIGN TORNA O PRODUTO ÚTIL
BOM DESIGN É ESTÉTICO
BOM DESIGN TORNA O PRODUTO COMPREENSÍVEL
BOM DESIGN É DISCRETO
BOM DESIGN É HONESTO
BOM DESIGN É DURADOURO
BOM DESIGN É MINUCIOSO, ATÉ O ÚLTIMO DETALHE
BOM DESIGN É AMIGO DO MEIO AMBIENTE
BOM DESIGN É O MÍNIMO DESIGN POSSÍVEL

Esses são os 10 princípios de um bom design de Dieter Rams, um designer industrial alemão.

Perguntas:
Isso é aplicável a design de software?
Isso é aplicável a design de websites/UX?
Seus designs seguem esses princípios?

Meus exemplos de bom design: Apple, Porsche, Rails e o corpo da mulher.
Meus exemplos de mau design: Land Rover, JSF e o site da IBM.

A Imagem é uma empresa especializada em software de informações geográficas. Sim, assim como a Scheffer, é mais uma empresa que foge totalmente de “sisteminhas web”. Sem querer ser perjorativo: software não se limita a Websites. Os clientes da Aspercom têm me mostrado ultimamente que desenvolvimento de software é algo muito vasto. É um assunto abrangente demais. Como exemplo, apesar de gostar muito do Scrum, nos últimos 8 meses tive contato com ao menos 5 empresas onde o Scrum não rola. Isso é assunto para outro post!

Sistemas de informação geográfica (GIS) auxiliam empresas em diversos aspectos. Geralmente são empresas gigantes. Esses sistemas podem auxiliar a manutenção de linhas de transmissão de energia, o projeto de um oleoduto, a construção de uma nova fábrica, logística em lugares remotos, compreender o impacto de fenômenos naturais e muito mais. Isso envolve imagens de satélite, informações geológicas e meteorológicas e muitos cálculos complexos.

O treinamento XP e TDD na Imagem foi muito divertido. Nosso treinamento tem muitas dinâmicas, muitos pairings e a colaboração exigida nas equipes para cumprir o sistema exemplo é empolgante.

Parabéns a todos da Imagem. Muito sucesso nos importantes projetos e clientes que vocês têm atuado.

Eu realmente creio que modelar e implementar um domínio desses seria a tafera mais divertida do mundo. Projetos de automação como esses são desafiadores, e se você é um aficionado em orientação a objetos deve ter sentido uma vontade irresistível de modelar algumas entidades vendo este vídeo.

O treinamento da Scheffer começou normalmente, mas terminou com uma sessão de modelagem ágil, Domain-Driven Design e práticas de BDD e Design Incremental usando Fitnesse. É bastante comum um treinamento corporativo iniciar como um curso e terminar com pairings e consultoria.

A Scheffer é uma empresa nacional pioneira na tecnologia de transelevadores em armazens automatizados, um setor em franco crescimento. Foi muito interessante conversar com pessoas que trabalham com TI num domínio tão diferente. Um aspecto bastante interessante é que apesar dos métodos ágeis dizerem tanto para “abraçarmos as mudanças”, digo para vocês que existem sim projetos com escopo fixo, aonde o Scrum perde muito do seu brilho, pois usamos iterações exatamente para ter feedback e com isso, mudanças. Um projeto de automação geralmente é direcionado pelo maquinário utilizado, as restrições do escopo da automação e etc… Um cliente que tem um armazém de 20.000 metros quadrados não terá mudanças na sua forma de automação. Geralmente o projeto físico inicial (feito por engenheiros especializados) não muda, e com isso a solução do software também tende a não ter alterações vindas do negócio. Logicamente a Scheffer se beneficiará de iterações, design incremental e outras técnicas aprendidas para limitar seu próprio risco do projeto.

Parabéns a todos da Scheffer!