Rodrigo Allemand

Uma das grandes barreiras para a adoção de uma metodologia ágil de uma equipe pode ser aquela antiga mania de isolar o cliente das adoções tomadas no decorrer do desenvolvimento. Não adianta! Sem o cliente por perto, não temos metodologia ágil que funcione simplesmente porque sem o cliente por perto, a chance de errarmos aumenta demais! Isso normalmente acontece quando temos aquele otimo tecnico que virou gestor e parou no tempo onde existia as fases de um produto, e não um produto em fases!

Muitas vezes, por mais que um ‘analista’ entenda 100% do que o cliente solicitou, ele não sabe o que o software tem que fazer quando for dado por completo. Nem o cliente saberá isso em um Brainstorm, ainda mais se vc colocar aquela bendita fase de levantamento no seu cornograma cronograma.

Dividir o produto em UserStories é dar certeza ao cliente e ao desenvolvedor que, apenas aquele pequeno escopo está sendo desenvolvido neste momento (iteração). Ele não precisa se preocupar no momento que lá na frente o produto tem que se comunicar com 50 pontos diferentes. Isso não está no mini-escopo da UserStory a qual o desenvolvedor está focado!

User stories also drive the creation of the acceptance tests. One or more automated acceptance tests must be created to verify the user story has been correctly implemented.

Para quem não sabe, eu trabalho no Instituto Nacional do Cancer, com uma equipe de 12 pessoas que desenvolve Java (Web e Mobile) para alguns clientes/institutos satélites do governo. Porem, quando eu cheguei aqui, minha tarefa era “organizar a casa para que os sistemas que estavam em fase final de levantamento tivessem uma melhor performance de entrega”.

Pois bem, fiz a minha parte! Os softwares estão sendo entregues quase como eles descreveram, mesmo com todos os problemas encontrados no meio do caminho! Digo isso porque não sei se enquanto eu escrevi esse post, as novas funcionalidades foram aceitas. Mas ainda me sinto muito insatisfeito com o meu próprio serviço, conforme enumero abaixo:

1. Não há testes por parte da equipe, nem falo de unitários ou integrados. Não há teste automatizado de maneira alguma!;
2. Não há a presença do cliente. Estamos desenvolvendo no escuro, levando em consideração o que o gerente do projeto acha, o que não será (quse com certeza) o que o cliente final deseja;
3. Não há uma definição fechada do que fazer e como fazer. Até mesmo coisas básicas como layout são alterados dias antes da entrega final de um módulo, mesmo sem o concentimento do cliente;
4. Não há gerencia de configuração alguma. Os ambientes de desenvolvimento, homologação e produção são diferentes a ponto de serem utilizadas versões de softwares e bibliotecas comuns diferentes entre esses ambientes;
5. Há sempre o “faz como esse aqui”. Sistemas arcaicos com soluções precárias como exemplo… nesse eu nem preciso me aprofundar muito!
6. Minha-Própria-Metodologia-Ágil não funciona se todos não tiverem completa noção de como funciona. Para qualquer metodologia funcionar, tudo deve estar entendido e todos devem estar de acordo.

Para se ter noção melhor sobre o que eu passo, na proxima terça feira (03/03/2009) deveriamos fazer um deploy contendo 80% do projeto para o cliente. Mas quem vai testar é o gerente do projeto, já que o cliente só vai ver quando o produto estiver 100% pronto. Mas amanhã teremos uma reunião para definir um escopo de versionamento de informações, que é vital para um processo de certificação (escopo do sistema). MAs calmae, amanhã para entregar numa terça?! Sugeri então envolver o cliente, mesmo que por audio conferência, para ter uma solução aprovada por ele, porque a alteração iria ser muito grande. Resposta: Vamos definir entre nós, o cliente será avisado sobre a nossa decisão!!

Um outro exemplo aqui tambem: o sistema ainda não tem usuário final e está em fase de homologação?!? Como assim?!? Quem definiu isso?!?

Enfim, estou muito insatisfeito e tenho plena noção de que não conseguirei alterar isso a curto prazo, ou seja, até a entrega desses produtos aos seus clientes com a etiqueta “SURPRESA!” Gosto muito do local, da empresa, da causa (principalmente) e das pessoas. Mas as metodologias e os modelos estão me esgotando!

Mas a minha saga em busca do projeto-agil-piloto-que-transformará-toda-a-empresa continua!

“Não é o mais forte que sobrevive, nem o mais inteligente, mas o que melhor se adapta às mudanças” – Charles Darwin

Até!

Camadas

DDD – Domain Driven Design – depende que vc desenvolva em camadas, isso é fato. A maioria das aplicações utilizam 4 camadas, conforme a figura abaixo:

1. Camada de Interface com o Usuário (User Interface)
2. Cama de Aplicação (Application Layer)
3. Domínio (Domain Model)
4. Camada de Infra-estrutura

Camadas básicas de uma aplicação DDD

A camada de interface com o usuário, como o próprio nome diz (dããããã!) é a camada que… hum…. er… cria uma interface com o usuário… rs. Deixando a brincadeira de lado, a definição desta camada é tão simples quanto o próprio nome. Ela é responavel por ter uma interface amigavel com o cliente, tanto de entrada quando te saída (leia amigavel como algo que o cliente consiga ler e excrever). Se a sua aplicação for Web, essa camada seria os seus JSPs e todos aqueles outros arquivos que te auxiliam na comunicação com o usuário (imagens, scripts, etc). Se vc tem um WebService, pode ser a linguagem de máquina que vc está usando (SOA, JMS, etc). Se for uma aplicação Client-Server, por exemplo, baseada em Java, são os seus componentes de GUI, como SWT, AWT, Swing, etc.

A camada de aplicação é a camada responsavel por tratar trabalhar os objetos da camada de domínio. Nela estão raros e possiveis trabalhos sobre informações da camada de aplicação sem que se execute qualquer tipo de regra de negócio, por mais simples que isso seja. Utilizando exemplos de aplicações Web, estes seriam os seus Servlets ou Commands ou Actions (no caso do Struts, por exemplo).

A camada de domínio é o coração do sistema. Nela estão todas as regras de negócio, ou melhor, ela é responsavel por abstrair o negócio. No decorrer dos posts, vc entenderá melhor o que será esta abstração.

A camada de infra-estrutura é toda a parte que liga a lógica ao físico, como banco de dados, emails, arquivos e coisas do tipo. Uma duvida que muitos tem é que a camada de dominio NÃO é responsavel por gravar/buscar nada em lugar algum, seja isso banco de dados ou um arquivo. Isso é tarefa da camada de infra estrutura. Você verá como o domínio solicita essa iteração com as mídias quando chegarmos em Repositorios.

Dependências e comunicação

Repare bem como ficam as dependências entre as camadas na figura acima. As dependencias são sempre na descendente vertical. A camada de interface depende da camada de aplicação que depende do domínio que depende da infra-estrutura. Eventualmente vc pode ter a camada de interface depender da camada de infra, mas nunca o contrário. As camadas sempre dependerão da mais inferior, e nunca da superior. O dominio NUNCA pode depender da camada de interface ou da camada de aplicação. Nunca passe um objeto da camada de aplicação para a camada de dominio!! As setas da figura podem lhe ajudar a entender a dependência.

Como você já sabe pode imaginar, dentro do dominio existem podem existir outras camadas. Alguns autores conseguem tipar os domínios, como vc pode ver no livro Pojos em Ação, onde o autor coloca tipos de domínios (Exposto e Aberto são os unicos que me vem a cabeça no momento).

Não vou me arriscar a falar de tipos de domínio por ser um assunto que eu não concordo. Vamos usar sempre a nossa camada de domínio bem fechada e definida.

Até a proxima!

Comente e Recomende!

Continuando a série, chegou a hora do arquiteto passar para um modelo um pouco mais técnico aquilo que definiu junto com o Domain Expert.

Após a definição inicial do modelo, cabe ao arquiteto passar isso para um diagrama mais técnico (neste caso, um diagrama de classe) e começar a estressar o modelo para saber se tudo que o cliente precisa pode ser resolvido naquele modelo. Caso ele encontre algum ponto que precisa ser mudado ou não está completamente definido ou entendido, ele deve voltar com o Domain Expert e discutir novamente, não só para fazer o Domain Expert entender o que ele pensou, mas tambem saber se o modelo que ele está propondo é realmente o que a empresa espera como produto final.

O arquiteto, por mais que saiba de uma tecnologia ou domine o DDD, nunca estará 100% ciente do processo da empresa que receberá o sistema. Por isso, esses feedbacks devem ser muito bem utilizados sempre que possível.

No exemplo citado anteriormente, após analisar o modelo o arquiteto esbarrou em algumas duvidas:

• O endereço do cliente é unico ou ele pode faturar em um endereço e entregar em outro. O Domain Expert disse que isso é o mais comum, quando um cliente tem um escritório administrativo e manda entregar num armazem logistico, por exemplo.
• Os contatos o arquiteto colocou como variados. O Domain Expert aprovou a alteração
• O arquiteto percebeu que o workflow deveria ser parametrizavel, onde de acordo com um status, o pedido poderia ir para outros possíveis de acordo com uma regra. O Domain Expert acordou que isso não acontece. O processo está desenhado e não vai mudar, pelo menos ele não enchergava tal mudança mesmo num longo período por causa da estrutura e dos processos já criados na empresa.

Então vamos ao diagrama.

Diagrama de Classe extraido do Modelo

Vemos claramente que do modelo acima, podemos extrair um modelo de dados inicial para o projeto. Definimos o modelo de dados como a imagem abaixo.

Modelo de dados extraido do Diagrama de Classes

Podemos claramente classificar o Diagrama de Classes citado acima com um Diagrama de entidades. Entidades são os principais objetos em um modelo de domínio.

Com um simples diagrama conseguimos fazer o cliente (neste caso, a empresa) e a equipe falar a mesma língua, os mesmo termos e, mais uma vez, colocamos a Ubiquitous Language pra funcionar no meio do time de projeto.

Mas vamos parar por aqui hoje. Chegamos a um entendimento bom sobre o que o Domain Expert quer e o com desenvolver o problema da empresa.

A partir de agora, iremos colocar a mão na massa!

Até!

Comente e Recomende!