Débito Técnico

Desde algumas polêmicas que ocorreram no Scrum Gathering neste ano, tenho discutido em diversos fóruns de discussões e eventos sobre o que tem ocorrido com a nossa comunidade de desenvolvimento ágil. Eu temo pelo o que pode ocorrer com o Agile aqui no Brasil. O que matou o RUP pode também matar o Agile.

Quando eu estava no começo da minha carreira, no início dos anos 90, por incrível que possa parecer os métodos eram ágeis. O cliente e os reais usuários eram muito próximos e participavam ativamente do projeto. O ciclo, apesar de não ter formalidades iterativas, era focado em entregas frequentes. Apesar das arquiteturas fracas, a qualidade era boa e a satisfação dos usuários era maior. Trabalhei com Clipper, Visual Basic 3-6, Mumps e outras coisas da época - além de administrar redes Novell 3.12 e Lantastic. Os projetos eram divertidos, focados em resultados e na maioria das vezes o financiador ficava no seu pé. Eu me lembro do Tonhão, o gerente financeiro da Rede America Burger & Pasta, meu primeiro (e único) emprego como programador CLT. O Tonhão todas as sextas batia na minha mesa no CPD e perguntava: “-E aí Japa, tá pronto?”. Todas as sextas, religiosamente às 15:00 o Tonhão cobrava sobre aquele sistema de controle de caixa das lojas que acabou com os disquetes e com muita burocracia, pois usava comunicação via modem.

Nos meados de 1996 recebí uma ligação de um amigo meu do colégio técnico dizendo que as consultorias estavam pagando R$ 22,00 a hora para projetos do Bug do Milênio em COBOL. Bem, para a época esse valor era bastante significativo, topei na hora e lá fui eu ter a experiência de uma empresa grande. Se existe uma coisa que você pode responsabilizar sobre a bagunça que existe no mercado de TI hoje essa coisa é O BUG DO MILÊNIO. Eu estranhei muito trabalhar em consultorias nessa época. Os projetos chegavam e nem tinha uma única reunião com o cliente. Na maioria das vezes tinha um gerente-proxy entre a equipe e os clientes. Os projetos Y2K eram ainda mais peculiares. Teve projetos que o trabalho era passar uma ferramenta de detecção de problemas Y2K, ir até o código indicado pela ferramenta e fazer as alterações, mas sem recompilar e sem qualquer teste. Eu me sentia um digitador. Levei até uma bronca de um coordenador por tentar compilar o projeto para ver se nossas alterações ao menos geravam os binários. Meu coordenador gritou que aquilo não era escopo do projeto. Nesse momento eu ví que qualidade não era uma preocupação central das consultorias.

Passada a fase Y2K, começaram os projetos Internet e de sistemas periféricos de grandes implementações ERP. O problema é que o desenvolvimento de software empírico (que eu apliquei nos meus estágios e lá na Rede America) não atendia às necessidades de projetos outsourcing. Gerentes queriam controles, relatórios e Gantt Charts. A preocupação maior era a mesma dos projetos Y2K - O ESCOPO. Se você estivesse numa consultoria no final dos anos 90, você compreenderia perfeitamente o mindset do SEI com o seu CMM. Os gerentes de consultorias buscavam algo que amarrasse a equipe ao contrato com o cliente. Meio por fora de tudo isso comecei a estudar Orientação a Objetos, OMT, Booch, e mais pra frente, a UML e o RUP. Minha primeira experiência prática com o RUP foi num projeto internacional para a Phillips Medical Systems em 1999.

Esse projeto da Phillips era um sistema orçamentário empresarial que integrava vários departamentos, inclusive a matriz em Rotterdam. Foi desenvolvido em Visual Basic, Orientado a Objetos e banco de dados Oracle. Quando olhei o RUP pela primeira vez gostei de Casos de Uso, Iteratividade e o foco Arquitetural. Neste projeto a equipe variou entre 3 a 5 pessoas. No início estabelecemos uma Visão para definir o problema junto aos usuários, o ciclo iterativo era de 30 dias e tinha perto de 15 casos de uso (que escrevemos de maneira correta). Usamos o famigerado Visual SourceSafe (o supra-sumo da época) e somente uns 6 ou 7 diagramas UML foram mantidos como artefatos (além do MER). O foco sempre era entregar o produto e não preencher artefatos. A gente até tinha alguns testes automatizados, mas a maioria dos testes era manual. Entregamos o projeto após 3 ou 4 iterações e foi um sucesso! A satisfação dos usuários foi além das expectativas. A partir desse projeto, o modo que eu instancio o RUP é assim: Iterativo, Orientado ao Usuário (Casos de Uso) e centrado em Arquitetura.

Quando voltei desse projeto para a consultoria um dos meus gerentes queria saber como foi o processo. Eu comecei a falar que o cliente participou bastante e que as entregas a cada 30 dias foram determinantes para diminuir os riscos. E a pergunta que se seguiu traduz bastante o mindset de um gerente (da época ou de hoje): “- Legal, legal, Rodrigo, mas quais eram os documentos que vocês preenchiam?”. Aí eu falei que usamos a Visão, os Casos de Uso, a UML, o MER… logo em seguida veio a pergunta número 2: “- Você poderia me dar um exemplo de cada um para usar no projeto XPTO?”. Hoje eu vejo que ele estava buscando respostas fáceis. Na época eu poderia ter dado minha cópia do livro sobre Unified Process dos Três Amigos, porém, o que eu fiz foi copiar um disquete com os artefatos. Ainda hoje ainda me culpo por ter feito aquilo, mas eu era ainda um profissional inexperiente, com pouco mais de 5 anos de estrada. Colaborei para a ilusão daquele gerente por respostas fáceis. Me desculpe se você era um dos desenvolvedores do projeto XPTO na virada do ano 2000. Me desculpe se um dia, um gerente chegou para você entregando um disquete dizendo: “- Olha, o preenchimento desses artefatos garantirão o sucesso do projeto.”

Na virada do Milênio, eu ví pessoas e empresas buscando processos como o RUP e outros pela motivacão errada. Eles achavam que a maneira “falar com o usuário - implementar - entregar” era pouco controlada. O pensamento era: “Ninguém assina nada?”. Nessa época os gerentes voluntariamente queriam uma burocratização. Era proibido falar as palavras empírico e pragmático nesta época. Não importando o Manifesto Ágil publicado em 2001, aqui no Brasil o que eu ví foi adoção de processos por pura burocratização.

No ano de 2003 eu ví a primeira palestra de um “especialista” falando absurdos sobre o RUP, no melhor estilo Waterfall. Ele disse coisas do tipo “Levantar todos os requisitos na concepção”, “Modelar tudo na fase de elaboração”, e principalmente, o cara pregava descaradamente a errônea sequência Casos de Uso - UML - Codificação - Testes, e uma irracional separação de papéis que está em uso até hoje. Ele teve até tempo de mostrar como preenchia alguns artefatos. Nesse tempo eu não era tão crítico como hoje, e nem mesmo para os meus amigos que assistiram a palestra eu alertei contra as falácias daquele fanfarrão.

A cada dia que se passou desde então, ví mais e mais pessoas falando absurdos do RUP. Quando se diz RUP atualmente no mercado muitos torcem o nariz, associam com cascata, associam com artefatos, associam com ferramentas Rational, e principalmente, associam com esse pensamento burocrático da virada do milênio. Muitos dos que criticam são agilistas famosos, mas que não tem mais de 10 anos de experiência. Eu queria que a maioria desses consultores e especialistas Agile estivessem lá nos anos 90, reclamando da implementação OO nos produtos base da Microsoft, tentando entender Objective-C e vendo uma esperança OO mais simples no Delphi como alternativa. A gente acreditava que a Orientação a Objetos resolveria todos os nossos problemas, mas 15 anos depois ainda temos modelos anêmicos e pessoas sem a mínima noção do que são dependências ou mensagens querendo discutir OO em fóruns colocando sua pilha de certificações na sua assinatura de e-mail.

Em 2003-2004 eu tive o primeiro contato com o Extreme Programming num projeto J2EE para um grande Call Center Vendas, um projeto único no mundo, clusterizado, distribuído, Swing e mensageria. Sobre o XP, quer saber? Não ví quase nada de novo. Agora Casos de Uso são User Stories menores, o ciclo iterativo é mais curto, o desenvolvimento é orientado a testes (isso sim achei uma boa idéia, apesar de não compreender bem nos primeiros projetos) e a programação é em par (isso também geralmente não é uma azeitona fácil de engolir logo de primeira). Eu particularmente tenho dificuldade em parear com algumas pessoas devido ao meu déficit de atenção. Eu olhei para o XP e no primeiro momento ví que muito do que diziam do XP era algo parecido com o que a gente fazia nos anos 90, principalmente a parte do cliente presente. Todos os meus clientes no início dos anos 90 eram presentes. Comparado com a visão do desenvolvimento de software das consultorias o XP era o cúmulo da controvérsia. Já na mentalidade de um desenvolvedor de software dos anos 90, o XP faz todo sentido do mundo. Meu primeiro contato com o Scrum foi em 2005. E mais uma vez tive aquele sentimento: Sim, é bem diferente das práticas erradas do mercado, porém, não é muito diferente do RUP. Ele diz mais sobre ROI e sobre um importante Product Owner, mas também me lembro do Tonhão como um Product Owner nato nos anos 90. Em 2005 o Scrum era o cúmulo do descontrole de custos do projeto, por conta do seu escopo aberto e por conta do mindset PMBOK, mas para um desenvolvedor dos anos 90, simplesmente é o retorno aquilo que a gente já fazia: nos anos 90 não tinha pressão para se entregar tudo, mas havia pressão para resolver os problemas de negócio do cliente. E eu me lembro do Tonhão todas as sextas me cobrando aquilo que estava pronto, doido para colocar a aplicacão no ar só para ter certeza que ninguém na rede estava roubando ele.

A grande questão sobre o Agile Movement é sua mudança cultural. Infelizmente são poucas as pessoas que se divertiram fazendo software nos anos 90 - se você costuma tratar os desenvolvedores como crianças, lentamente eles se convencem que são crianças. O manifesto é um grito contra as coisas erradas do mercado. É uma emancipação dos desenvolvedores que não querem ser crianças. É uma injeção pragmática contra o pensamento pseudo-tradicionalista, controlador e traumatizado que existe hoje no mundo empresarial, especialmente na indústria do desenvolvimento de software.

O que vocês devem estar se perguntando é: O que matou o RUP e pode matar o Agile? Como eu falei, eu temo pelo movimento Agile. Assim como foi em 2003, em 2009 eu ví o primeiro pseudo-especialista Agile falando absurdos - violando valores. A partir do momento que eu vejo a comunidade Agile discutindo e dando importância demais a post-its, quadro de tarefas e cartinhas de planning poker, eu temo pelo movimento Agile. Quando eu vejo a comunidade Agile buscando certificações, preocupados em como casar Agile com CMMI ou como adaptar Agile à contratos de escopo fechado, eu temo pelo movimento Agile. Sempre que eu vejo isso no mundo Agile, me transporto a 10 anos atrás e me lembro das discussões sobre templates de casos de uso, definições de padrões de modelagem UML, pensamento linear, check-lists de artefatos, uso incorreto de ferramentas, falta de compreensão sobre fases e o pior de todos: o departamento que cuida dos processos de desenvolvimento. Resumindo, quando vejo esse mindset de besteirols e libertinagens Agile, eu me lembro do mindset burro e burocrático que contaminou o RUP.

O que matou o RUP foi a falta de entendimento, e isso é o que vai matar o Agile. Lean é o próximo da fila. Escreva aí: em 5 anos, dependendo dos ventos da economia e do clima empresarial, muitos vão estar criticando Agile do mesmo modo que hoje criticam o RUP, sem autoridade de causa. Tudo vai depender do mindset vigente no momento. Tudo depende do mindset: se você der o Scrum e XP para um “tradicionalista” ele não vai mudar seu mindset, mas sim adaptar o Scrum e o XP às suas “crenças”. Se você der o RUP para um pragmático, ele também não muda o seu mindset, mas sim, adapta o RUP à sua realidade. Você pode decidir o seu mindset: ou você realmente acredita nos 4 valores e 12 princípios ágeis e adota este estilo, ou você se enche de penduricalhos ágeis só para ficar na modinha.

Mais sobre o assunto “queda do Agile”:

Agile está morto! D-us salve o Agile! - José Papo
The Decline and Fall of Agile - James Shore
Por que dizemos não à certificação de Scrum Master - Vinicius Teles
A Completa Irrelevância do Certified Scrum Master - Philip Calçado
Flaccid Scrum - Martin Fowler

Esse artigo e a palestra que ministro com mesmo título é inspirado em “What Killed Smalltalk Could Kill Ruby, Too”, Keynote do Robert Martin (ou Uncle Bob) na RailsConf ‘09. Uma das melhores palestras que já ví. Veja abaixo:

Como havia anunciado aqui no Débito Técnico, tivemos a primeira turma aberta do Workshop Extreme Programming em São Paulo, com a participação de 5 equipes, usando as mais diversas tecnologias. O motivo da Aspercom aplicar turmas Beta de seus treinamentos é para verificar a aceitação do público geral e também para verificarmos a dinâmica do programa dentro do horário e as atividades práticas. No caso do Workshop XP, muitas dúvidas tivemos com relação à aplicabilidade do treinamento às diversas tecnologias, porém, tiramos esta preocupação com esta turma. Tudo correu muito bem e o treinamento foi um sucesso!

Iteração Inicial: Ainda muita pendência arquitetural para acertar…

4 pessoas, 2 notebooks = Pair Programming Obrigatório (e apesar do preconceito, no fim todo mundo gosta)

Paulo Calligaris, Marcelo Chisté, Willian W. Leite e Luis Cesar Teodoro: pessoal da BRQ em .NET

Leandro Faria, Carlos Lisandro, Hugo Sacramento, Elton Moura e Marcelo Costa: pessoal da UpLexis em PHP

Luiz Ricardo Batista, Alan Vidotti, Pedro Matheus, Daniel Takabayashi: pessoal da BRQ em Java

Mauricio Aniche, Paulo Henrique Martins, Willy Nakata, Murilo Cezar de Oliveira: equipe WOOF! em Java

Ricardo Almeida, Rafael Rosa, José Guilherme Ribeiro, Rodolfo Liviero da Silva e Anderson Carubelli: equipe da Gonow em Rails

Antes de mais nada, queria agradecer muito a turma pela excelente avaliação (principalmente pelos twitts) e também parabenizar a todos pelas aplicações que foram geradas. Elas me forneceram um ótimo feedback para melhorar o curso e alterar algumas coisas no sistema exemplo.

Próximas turmas…

A próxima turma aberta já está agendada para o dia 24 de outubro, sábado e com preço promocional, lembrando que você deve formar uma equipe de 4 ou 5 pessoas e escolher uma arquitetura para cumprir uma atividade prática antes do curso começar. Maiores informações:

http://www.aspercom.com.br/ead/calendar/view.php?view=day&cal_d=24&cal_m=10&cal_y=2009

No mês de agosto estive na WebGoal ministrando o nosso curso Extreme Programming. A WebGoal é uma empresa de desenvolvimento de projetos e de produtos próprios; fiquei bastante impressionado em como a empresa é dinâmica e possui uma filosofia empolgante. Eles são uma consultoria pequena focada em práticas ágeis e com muito potencial de crescimento. A primeira vez que os visitei era o dia de entrega da Sprint e lá eles comemoram com um churrasco na própria empresa. De fato é um ambiente muito legal, que me fez lembrar o Domenico DeMasi dizendo como o estilo e ambiente dos escritórios atuais influenciam na produtividade das equipes.

A WebGoal é um caso típico de uma empresa esperta que após alguns Sprints com o Scrum rapidamente notou as pernas que faltavam para um desenvolvimento ágil de verdade. Eles notaram que precisavam das práticas de engenharia do XP, destacando Testes Automatizados e Integração Contínua. É aí que nosso treinamento entrou. O Scrum e XP é a dupla que torna equipes verdadeiramente ágeis (fujam do Scrum flácido). O pessoal da WebGoal já usava muito Pair Programming, o que é muito bom, então, nas atividades práticas, os pares tiraram tudo de letra. Foi um dia muito enriquecedor, parabéns a todos da WebGoal!

Todo pessoal pareando.

Equipe 1

Equipe 2 e o Kanban

Um desenho vale por 3 palavras

Neste ano de 2009 teremos muitos eventos interessantes e muita gente boa presente nas palestras e bate papos. Estarei palestrando em quase todos eles (o ruim disso é que vou gastar muito tempo fazendo apresentações e pouco código).

JustJava 2009

Na semana que vem rola o JustJava 2009. Um dos eventos mais tradicionais da comunidade Java. Neste ano estarei levando a palestra “Requisitos Executáveis com FIT”, marcada para o dia 15/09, terça-feira às 17:30.

Evento de Aniversário do CEJUG em Fortaleza. Já faz um tempo que tenho contato com o pessoal de Fortaleza através da Fortes Treinamentos, nossa parceira no Ceará. Dessa vez o pessoal do CEJUG me fez um convite muito especial para palestrar no seu evento de aniversário que vai rolar no dia 19/09. Estarei presente com a apresentação: “O que matou o RUP pode também matar o Agile”. Se você é da região não pode perder.

Nessa minha ida a Fortaleza também estarei levando o Workshop Domain-Driven Design em Java que será no dia 18/09 com desconto para os associados do CEJUG.

Na sua segunda edição, as Jornadas Latino-Americanas sobre Metodologias Ágeis vem com força total e com presença garantida de muitas pessoas importantes da nossa comunidade Agile. Neste evento em Florianópolis estarei fazendo aquilo que faço sempre: ENSINAR. Minha apresentação na verdade será um mini-workshop sobre User Stories que vai rolar no dia 08/10.

O Encontro Ágil em São Paulo tem muitas novidades neste ano. A principal delas é a presença de Alistair Cockburn, um dos autores do Manifesto Ágil. De fato, uma oportunidade única. Estarei palestrando novamente com o José Paulo Papo sobre Auto-organização e Gestão por Metas Flexíveis.

Muitos outros eventos legais serão realizados. Entre eles eu sugiro o Dev In Rio e o Rails Summit. Infelizmente, por conta de problemas de agenda, não poderei participar do Dev In Rio, mas no Rails Summit estarei presente!

Desculpem o atraso! Mas só neste feriadão de 7 de setembro estou tendo tempo de escrever sobre a experiência do Rails Rumble, e com uma vista espetacular da Mata Atlantica, na praia da Barra do Sahy em São Sebastião.

Bem, como tinha falado no post anterior, a nossa aplicação para o Rumble não era algo para se fazer em 48 horas. Era um desafio e tanto, mais ainda para uma equipe que nunca havia trabalhado junto antes. Eram 23 user stories. Todas as outras equipes falaram que era grande demais! Porém, eu acreditava que seria possível, pois dessas 23 stories havia gordura para queimar (stories que poderiam ser cortadas sem prejuízo para o valor da aplicação).

A equipe brazilian-dojo (conte as latas de RedBull)

Logo no inicio do Rumble, para variar um pouco, tivemos alguns problemas de infra. Contas de GitHub que não entravam e Linodes com alguns problemas. Graças a Deus nossa equipe tinha o Cauê Guerra, que demonstrou muita habilidade para lidar com hospedagens Linux para Rails. Passado esse primeiro momento o Cauê falou a palavra mágica: “Vamos parear”.

Acho que o Rumble foi uma das minhas melhores experiências com Pair Programming. Isso porque esse foi o meu primeiro projeto Rails com uma equipe de programadores (meus projetos Rails anteriores foram solo). Eu aprendi muito. Parear com o Cauê foi muito legal, pois ele ensinou vários truques e também ví muitos vícios ruins eu fazia. Na nossa primeira sessão pareamos por pouco mais de 4 horas. Depois tivemos algumas outras sessões curtas, mas no sábado, teve um momento que adiantamos MUITO o projeto numa sessão em par de 10 horas. Não há dúvidas que programar em par é mais produtivo. O gargalo da programação não está na digitação. Quem diz o contrário ou nunca programou na vida ou não sabe trabalhar em equipe. Num projeto como este, cheios de integrações e incertezas, ví que os momentos que a gente não pareava era muito improdutivo. Talvez isso que vou falar aqui agora é a coisa mais nerd deste blog: no Rumble, eu e o Cauê passamos as primeiras 30 horas programando sem parar, movidos a Red Bull. O Alexandre, nosso web designer também nos acompanhou por parte do trajeto.

Um monitor adicional ajuda muito no Pairing.

Nós não terminamos a aplicação completa. Nós tivemos muitos problemas na reta final, principalmente com a integração com o GoogleMaps (a batalha do Felipe e do Cauê). Mas nem por isso tivemos um sentimento de derrota. Foi muito divertido e foi uma inter-fertilização tremenda. Das 23 stories nós entregamos 15, dropamos umas 5 e deixamos de entregar 3. Essas 3 histórias simples que deixamos para final eram as histórias que não tinham integração com nada, mas que davam todo o sentido para o site (a busca e a parte de colaboração). Mais 4-5 horas nós conseguiríamos entregar tudo, mas o Rumble é implacável com relação ao prazo. Ao final do tempo tudo é bloqueado.

Discussões de Design no amanhecer

Pessoal das outras equipes e amigos da Gonow.

Quero agradecer muito o Cauê, o Felipe e o Alexandre pela excelente experiência, onde pudemos compartilhar muito da nossa arte de desenvolver software. Quero também parabenizar a Gonow pelo patrocínio das equipes brasileiras e por ter fornecido absolutamente tudo para nós, desde as refeições até o hotel, que era a nossa “descompressão”. Tudo foi muito bem organizado.

E que venha o Rumble 2010!!!!!

No próximo final de semana, mais especificamente das 21:00hs da sexta-feira às 21:00hs do domingo, estarei participando do Rails Rumble. Para quem não conhece, o Rails Rumble é muito simples: É uma competição onde você e mais 3 amigos devem fazer uma aplicação, um website ou produto usando Rails em 48 horas. A melhor aplicação vence! Simples né?

A equipe conta com Felipe Oliveira Kenobi (nosso sensei SOA), Cauê Guerra (nosso Jedi Rails) e Alexandre Theodoro (nosso expert em Web Design). O projeto é um site para os eventos do tipo Flash Mob estendido ao conceito de redes sociais, onde um usuário poderá criar eventos, notificar seus amigos sobre o mesmo, compartilhar as experiências agregando opiniões de diversos partipantes, registrar seus momentos em diferentes mídias e torná-las acessíveis à partir de um único ponto.

Olhando pela visão tecnológica, o projeto não pretende reiventar a roda. Serão integradas plataformas pré-existentes divididas em: Conteúdo (Digg.com), Mídia (Flickr e Youtube), Calendário (sistemas como Google Calendar e Yahoo UpComing), oAuth para registro do usuário, OpenSocial Platform (Google), Maps e sistemas de microblog (Twitter). Resumindo, muitos mashups em cima de um modelo baseado em WOA.

Link para o projeto: http://r09.railsrumble.com/teams/brazilian-dojo

A participação das equipes brasileiras no Rails Rumble é um patrocínio muito legal da Gonow. Durante o evento, a Gonow estará cedendo o seu espaço e infra-estrutura para as 3 equipes participantes. Além disso, estará também fornecendo hospedagem e alimentação durante o evento. Não só isso, a Gonow também estará filmando tudo (um Big Brother Developer Brasil).

Fazer uma aplicação completa num curto espaço de tempo é um desafio técnico e também para a gestão do “projeto”. Como havia relatado aqui anteriormente, no projeto da DDWorks, tínhamos o desafio de entregar um e-commerce em 40 horas (uma semana). Trabalhamos com iterações diárias. Minha experiência nesse tipo de projeto poderá ajudar no Rumble. Basicamente, o que aprendi foi: baby steps são amigos, use histórias bem pequenas, integração contínua insana, coloque os incrementos no ar o mais rápido possível e veja bem o quanto você investe em testes. Espero que isso também ajude as outras equipes!

Neste projeto do Rumble será uma experiencia diferente. A equipe trabalhará tanto no Tech como no Business e vejo que a junção dos skills está favorecendo muito o projeto. Nós decidimos fazer iterações de 3 horas, com 30 minutos de retrospective e planning. Vamos trabalhar em pares, integrando em não mais que 30 minutos. Estamos também separando alguns momentos para descanso dos participantes. Esperamos estar vivos para comemorar no domingo com todo mundo.

É bem provável que estaremos postando muita coisa no Twitter neste fim de semana. Siga: @scaphe, @caueguerra e @rodrigoy.

Domain-Driven Desing não é sobre padrões - isso gera muita discussão. Domain-Driven Design (ou simplesmente DDD) é sobre fazer software de maneira mais simples - e sei que muitos não vão concordar com isso, pois “parece” que é mais fácil e muitos se sentem muitos produtivos ligando Table Modules diretamente às telas e abusando de Transaction Scripts.

O objetivo deste artigo não é falar sobre o que a literatura diz sobre repositórios e nem tenho a pretensão de escrever o “post definitivo sobre Repositórios”. O objetivo aqui é demonstrar como tenho aplicado Repositórios nesses 3 anos de experiência em aplicação e ensino de DDD.

O que são Repositórios afinal?

Antes de mais nada, orientamos a aplicação ao domínio. O exemplo que vou montar aqui não é real, mas é bem próximo daquilo que apliquei em alguns projetos. Orientar a aplicação ao domínio significa que seu código será limpo e principalmente sua camada de negócios demonstrará o NEGÓCIO, suas regras, seu estado e suas associações. Se sua aplicação é de vendas, é esperado que o vocabulário do domínio “vendas” seja encontrado nas suas classes. As classes do domínio também não devem ser poluídas com o domínio técnico: o domínio “vendas” não sabe o que são tabelas, filas, sistema de arquivos e nem SMTP. O domínio técnico e do domínio do negócio tentam ao máximo não se misturar numa aplicação Domain-Driven.

Se minhas classes de negócio traduzem a linguagem de vendas, quero que você tente pensar num modelo que resolva os seguintes requisitos:

1. Um pedido de vendas possui cliente e itens
2. O valor total do pedido é a soma do valor dos itens
3. Somente produtos disponíveis podem ser vendidos

Imagine agora, como um ator Vendedor utilizaria o sistema. Ele criaria um pedido, colocaria alguns itens com produtos disponíveis e finalizaria este caso de uso. Quero que você pense bastante em como você resolveria o requisito número 3. No meu código, surgiria algo deste tipo:

A primeira pergunta natural é: Por que o repositório está como uma interface? Muitas vezes o Repositório simplesmente é uma abstração do domínio cuja responsabilidade é representar coleções de entidades, porém, ele ainda é um elemento do domínio. Muitas vezes nós temos um elemento que realiza esta interface para fornecer implementação para essas buscas.

Usar repositórios como interfaces é bom para a saúde da testabilidade da sua aplicação e ainda posso me beneficiar de injeção de dependência. Isso facilita o uso de Mocks e Stubs para testes unitários ou de integração, além de deixar seus objetos desacoplados.

Teve algumas situações peculiares onde a interface TodosProdutos era um elemento do domínio e a implementação TodosProdutosImpl era puramente infra-estrutura. Neste caso, TodosProdutos (a interface) estava empacotada no domínio (geralmente uso o nome domain) e a TodosProdutosImpl estava empacotado como infra-estrutura.

De qualquer forma, para a discussão aqui, simplesmente destaco que o repositório TodosProdutos é algo puramente do vocabulário de negócios. “Todos os Produtos” é algo que o meu usuário sabe o que significa. E TodosProdutos.getDisponiveis - a minha operação - faz mais sentido ainda para os usuários, pois eles também sabem o que são produtos disponíveis para venda (se isso para eles é uma interface ou uma classe isso é completamente irrelevante).

Repositórios como Coleções Parciais

Teve uma certa aplicação que desenvolvi que nas conversas com os especialistas de negócio um determinado termo era muito recorrente. Eles se referiam a um determinado conjunto de entidades com um nome especial: pedidos faturados. E nesse sistema, os “pedidos faturados” tinham uma força tão grande na Ubiquitous Language da DDD que passou a ser um contexto separado.

Várias vezes mostrei esse diagrama a arquitetos e programadores e muitos não entenderam isso facilmente. É bastante comum as pessoas associarem um repositório por entidade, enxergando-os como 1 para 1 com DAOs. Muitos desses programadores que não entendem DDD questionaram: - Por que separar isso? Minha resposta: - Não fui eu que separei isto… no domínio do negócio isso é separado. Não é uma opção arquitetural, somente estou transparecendo o domínio.

A maioria das respostas sobre a camada de negócios numa aplicação Domain-Driven é dada pelos usuários e especialistas do domínio e não pelos arquitetos e programadores.

O nome não deve ser XptoRepository?

Durante algum tempo, seguindo a linha do Hibernate, minhas classes de busca eram [NomeDaEntidade]DAO. Depois de um tempo meus DAOs eram repositórios, mas continuava chamando-os de DAOs, pois odeio o nome Repository dentro do meu código. Acho pior ainda o nome “Repositório” - que é uma tradução livre corrente. O nome Repositório é bem pouco expressivo em português (que raios é repositório?) - o termo em inglês é mais claro.

Ao fim de tudo isso, vejo que é bem pouco proveitoso chamar uma classe de domínio de PedidoRepository ou PedidoRepositorio. Teve uma aplicação que chamei meus repositorio de “Pedidos”, mas últimamente tenho usado mesmo “TodosPedidos”, “TodosClientes”, “PedidosFaturados”, “ClientesInadimplentes” e etc… Uso esses termos pois são mais próximos do domínio e não vejo a mínima razão para ter o nome do padrão no nome ou empacotamento das classes.

Pedido é uma entidade, nem por isso o chamamos de PedidoEntity, o mesmo vale para Value Objects, Services e Repositórios. O BufferedInputStream do Java é um Decorator, nem por isso chamamos ele de BufferedInpuStreamDecorator.

Repositórios mais Complexos

Associar repositórios com buscas nem sempre é verdadeiro. Repositórios respondem por conjuntos de entidades, não importando a dificuldade de se obter esse conjunto. Há repositórios que podem ter código de negócio complexo em sua execução onde determinadas operações podem à primeira vista aparentar simplesmente uma busca. Você deve levar em consideração se há inteligência de domínio envolvida, caso afirmativo seu repositório deverá ter essa inteligência embutida. Vamos colocar mais requisitos:

4. Se o pedido é para entrega imediata, os produtos disponíveis são aqueles que eu tenho em estoque no momento da venda
5. Se o pedido é para entrega futura, os produtos disponíveis são aqueles que estarão em estoque na data de entrega

Neste “TodosProdutos” refatorado, para obter os produtos disponíveis na data da entrega é necessário pegar o saldo atual do estoque, subtrair os pedidos de venda já comprometidos (saídas) e somar os pedidos de compra (entradas) até a data desejada. Tudo isso é inteligência de domínio que não deve ser delegado para o banco de dados. É um repositório que tem regras e pode até orquestrar junto a outros repositórios e services para cumprir o seu propósito.

Um ponto importante a destacar é que muitas outras variações de implementações de repositórios existem. O objetivo do artigo é somente destacar algumas implementações interessantes que implementei em alguns projetos.

É lícito acessar o EntityManager diretamente?

Discussões sobre Domain-Driven e implementações de respositórios são muito recorrentes em listas de discussões, principalmente no GUJ e na DotNetArchitects (sou novo nessa lista).

Uma das perguntas comuns é: “É licito eu acessar diretamente o EntityManager ou Sessão do Hibernate?”. Particularmente eu sou da opinião que se você está fazendo buscas que não são importantes para o negócio não há problemas acessar diretamente seu framework de persistência. Logicamente que isso não deve ser levado a ferro e a fogo, testabilidade e complexidade são pontos a considerar.

Um exemplo seria: imagine que para emitir o pedido eu tenha que preencher um combo com o tipo de venda (um dado simplesmente informativo). Se é uma busca de uma entidade fraca, que significa muito pouco para o domínio, para reduzir a complexidade, o repositório pode ser descartado sem muito prejuízo para a testabilidade.

Em Novembro de 2007 estive em Porto Velho ministrando sobre arquitetura e orientação a objetos para o pessoal do Tribunal de Justiça de Rondônia (TJRO).

Agora em julho, estive mais uma vez com nossos animados amigos do tribunal dessa vez para ministrar sobre práticas ágeis de gerenciamento e engenharia. O TJRO foi uma das primeiras organizações a comprar um pacote Agile completo (Scrum+XP).

O nosso novo curso Extreme Programming vem para completar o nosso renomado curso Scrum com práticas de engenharia do dia-a-dia de uma equipe ágil. Vamos as fotos das equipes…

Durante a iteração: “pares promíscuos”, muita conversa e concentração.

Ambiente informativo semi-digital do treinamento

Equipe que entregou mais histórias

A equipe que mais divergiu nos pairings

A equipe que mais discutiu

A equipe que mostrou maior comunicação/colaboração (infelizmente morreram na praia!)

Gostaria agradecer a todos do TJRO pelo excelente empenho e participação dos treinamentos como um todo. Ao fim todos gostaram das práticas mais polêmicas do Extreme Programming, como a programação em pares. É bastante comum as pessoas questionarem sobre Pair Programming, porém, quando você tem a experiência real, a sua opinião realmente muda!

Neste mês de Julho estive na empresa MicroPower ministrando nosso curso UML e também o curso de Scrum.

A MicroPower é uma empresa especializada em soluções focadas em gestão do ensino/aprendizado de empresas, tendo produtos próprios para Gestão de Treinamentos e também serviços sob medida como a criação de conteúdo para treinamentos à distância.

Gostaria de parabenizar a todos da MicroPower pelo excelente nível da turma e desejar muito sucesso, principalmente na adoção das práticas ágeis/iterativas de desenvolvimento.

Turma concentrada!!!

Antes de mais nada, deixa eu explicar: a Aspercom foi a primeira empresa a possuir o próprio curso Scrum aqui no Brasil, já treinamos mais de 100 equipes e temos experiência com consultoria e coaching em implementações Agile.

Ainda explicando, nosso curso Scrum é focado em pilares importantes da Agilidade que vemos o mercado tendo muita dificuldade em aplicar: auto-organização, uma voz forte do cliente e planejamento progressivo. Porém, para ter planejamento progressivo e direcionado a resultados (ROI) é lógico que você precisa de boas práticas de engenharia. Um fato: no nosso treinamento Scrum, sempre que falamos sobre um Backlog orientado a ROI, automaticamente vemos uma grande - e bem grande - interrogação arquitetural na cara dos nossos alunos e isso também acontece no curso UML e OOAD.

Nós explicamos sobre design incremental em ambos os treinamentos e os alunos até compreendem, mas nós não estamos satisfeitos, pois não é suficientemente prático da maneira que nós gostamos. Para realmente conhecer sobre design incremental, você precisa FAZER design incremental, EM CÓDIGO. A gestão covarde é um anti-pattern constante nas minhas andanças pelas empresas do Brasil, e me retratando aqui, não só os gerentes são covardes. As equipes desenvolvem paradigmas próprios pela simples falta de conhecimento ou exposição exagerada ao desenvolvimento em cascata.

Uma das maiores críticas ao Scrum é a falta das práticas de engenharia. OK, isso não é escopo do Scrum, mas é esperado que nas suas retrospectivas você busque melhores arquiteturas, melhores designs, melhores práticas de teste e etc… A melhoria contínua do processo é a chave do Scrum, e se você está usando Scrum de verdade, você deve se aproximar das boas práticas de engenharia do Extreme Programming.

Para acelerar esse objetivo natural nas equipes, a Aspercom está lançando um treinamento focado nas práticas de engenharia do Extreme Programming. Esse curso Extreme Programming é fruto da nossa observação em diversas empresas e mostra na prática como é o dia-a-dia de uma equipe ágil (seriam aquelas 7:45hs do dia do Scrum, onde vocês não estão fazendo a reunião diária).

Os desafios de fazer um Curso Extreme Programming

Fazer um treinamento prático de XP para o público aberto é um desafio! Isso porque num treinamento XP precisa ter programação. Desenvolvimento de software é programação e não só planejamento. É lógico que no treinamento da Aspercom vocês vão PROGRAMAR, assim, o público alvo do curso são programadores (nós não vamos ensinar você a construir algorítmos nesse curso). O desafio é que nós temos muitas arquiteturas, plataformas e linguagens diferentes, e fica difícil juntar interessados de uma forma que seja possível haver programação dada a diversidade dos ambientes (se você tiver um phpista, um javeiro, um dotNeteiro e um Railer numa equipe não há programação, mas sim uma disputa entre eles sobre qual é o melhor…)

Nós resolvemos essa questão fazendo a inscrição do curso por equipe de 4 membros. Você vai se inscrever junto com mais 3 pessoas para formar uma equipe. Assim como o Workshop Scrum, o treinamento toma um dia inteiro. Além disso, no curso Extreme Programming sua equipe DEVE cumprir uma atividade prática antes do dia do treinamento. Essa atividade basicamente é eleger uma arquitetura WEB e implementar duas histórias. Essa preparação de ambiente antes do treinamento é importante para que o dia do Workshop seja mais produtivo. Um ponto importante é que a própria equipe deve trazer seus dois notebooks (e somente dois!) para o dia do Workshop já com este ambiente preparado.

O dia do Workshop é um hand-on prático como o treinamento Scrum. Serão cinco a seis iterações de uma hora recheadas de pairing e programação. A cada iteração o instrutor (eu) apresentará alguns conceitos teóricos do XP e após isso temos a iteração de 1 hora para implementar histórias num projeto real e didático. Uma experiência real com o XP. A programação toda será em par, onde o aluno aprenderá de maneira muito prática o design incremental e o desenvolvimento orientado a testes (as histórias são liberadas gradativamente e não todas de uma vez, isso força o design incremental e refatorações).

Este curso é altamente recomendado para pessoas que já conhecem XP, que já leram os livros, mas nunca tiveram uma experiência prática real num projeto. Posso afirmar com absoluta certeza que com a prática você terá uma visão muito enriquecedora sobre a teoria.

Como anunciei no meu Twitter, teremos uma turma BETA deste treinamento no dia 29 de agosto, sábado, em São Paulo (Av. Paulista, 807). SOMENTE para essa turma BETA o preço será R$ 85,00 por pessoa (R$ 340 por equipe). Para se inscrever você precisa juntar a sua equipe com 4 membros e 2 notebooks, ter uma arquitetura (Java, .NET, PHP, Rails ou outra) e implementar a atividade inicial já citada. Turmas limitadas a 5 equipes.

Inscrições/Informações: contato@aspercom.com.br.

Uma informação importante é que este treinamento já foi ministrado em empresas (como o TJRO, já postado aqui no Débito Técnico). Chamamos essa primeira turma de BETA, pois é a primeira vez que estamos tentando fazer isso em turmas abertas ao público.

Mais novidades sobre este treinamento em breve aqui no Débito Técnico. Se você tiver mais dúvidas poste aqui como comentário que nós podemos te ajudar e até melhorar nosso produto.