Encaixando Processo 3PUP na Java EE

Há mais de 2 anos trabalho - quando tiro tempo de outras coisas - no Processo 3PUP, que é uma iniciativa (quase pessoal) para padronizar algo que me permita trabalhar com as melhores práticas da DDD, UP, FDD, XP, Scrum, RUP, 4+1 e XProcess, além de um punhado de algumas outras coisinhas ;)

Um dos dramas maiores era sempre a pergunta: Como organizar as coisas dentro do processo?

Processos e frameworks como o UP, Scrum, XP e 4+1 não são nada claros nesse sentido, e nos deixam perdidos entre uma série de diagramas complicados e disconexos, ou um simples (e nada fácil de estimar e vender dentro de uma tríplice restrição do PMBOK3) Product Backlog, ou pior, com um saco de User Stories misturadas.

Partindo da FDD (que particularmente eu adoro), a coisa começa ter um Norte para trabalharmos, pois dividimos o sistema em 4 níveis (que são - além do próprio Sistema - Área, FeatureSet e Feature).

Entretanto, por mais que eu tentasse aplicar essa sequência, eu nunca conseguia ser tão simplista.

Assim, (in)felizmente, adicionei um 5o nível na estrutura, e a coisa ficou como a figura abaixo:

É claro (hic, eu acho) observar nessa figura uma relação 1-para-1 entre os elementos do Processo 3PUP e a estrutura de uma aplicação Java EE clássica.

Os elementos

No 3PUP, dividimos o sistema em 5 níveis, que são:

Nível 1. O sistema: É o primeiro nível. Grosso modo, ele "é" o nosso sistema, aquele que vai ser implantado no cliente. Aqui, ele é o nodo principal, e dentro dele todos os outros elementos estão contidos. Pensando em Java EE, seria o nosso arquivo .EAR deployado no servidor de aplicação. Pensando em nível de negócio, seria o nosso domínio da aplicação. E, pensando em nível de gerenciamento, seria o nosso projeto.

Nível 2. Os módulos. São o segundo nível. Cada módulo é, em princípio, uma parte independente e autocontida do sistema. Pensando em Java EE, seria um típico arquivo .JAR ou .WAR, e dentro deles estariam encapsulados uma parte do sistema. Isso, além de organizar a vida, permite fazermos deployments parcias de cada nova parte do sistema sem afetar o restante das estruturas. Pensando em nível de negócio seria uma área do domínio da aplicação. E, pensando em nível de gerenciamento, seria uma parte da WBS no PMBOK, ou então um componente (component/s) para quem usa o ótimo Atlassian Jira ;)

Nível 3. Os serviços. São o terceiro nível. Cada serviço representa um agrupamento lógico de processos de negócio. Pensando em Java EE e Patterns, isso seria representado por EJBs de Fachada, que também poderiam ser expostos via Webservices ou REST. Os serviços aumentam a coesão e diminuem o acoplamento dentro do módulo, permitindo que cada uma de suas partes internas (os grupos de processo) evoluam sem grandes impactos em relação às outras (os outros grupos de processo dentro do módulo). Pensando em negócio, poderíamos dizer que os serviços são os conjuntos de funcionalidades expostas pelos módulos. Pensando em nível de gerenciamento e projeto, os serviços são pontos perfeitos para elegermos os "Chief Programmers" (que a FDD defende), onde cada serviço é destiando à uma equipe de projeto e liderado por um Analista ou Projetista, o qual pode evoluir e desenvolver seus grupos de processos relacionados sem impactuar no restante dos times de trabalho, que trabalham em outros grupos de processos, dentro ou fora do seu módulo.

Nível 4. As funcionalidades. São o quarto nível. Cada funcionalidade é um processo de negócio, contendo seu próprio ciclo de vida e regras. Pensando em Java EE, cada funcionalidade (ou processo de negócio) pode ser implementado por um EJB de negócio. E, se estendermos essa definição, vamos ver que está em concordância com a JSR 299, ou seja, os WebBeans (sendo que cada Bean no container Java EE pode ter seu próprio ciclo de vida, ou seja, é o mesmo ciclo de vida do processo de negócio!). Pensando em nível de negócio, as funcionalidades estão em concordância com o Scrum (são os Itens do Product Backlog), com a FDD (são os FeatureSets) ou com o XP (os Themes, que agrupam as User Stories). Em nível de projeto e gerenciamento, as funcionalidades são pontos perfeitos para trabalharmos a questão do Earned Value do PMBOK, e fazer a gestão de custos e andamento de cronograma do projeto: pense bem, de que adianta eu entregar ao cliente meio processo de negócio, ou seja, meia funcionalidade? Assim, se formos pensar em gerenciamento de andamento do projeto e valor agregado, as funcionalidades são o denominador comum e lógico para o gerenciamento de alto nível do projeto.

Nível 5. As funções. São o quinto, último e mais detalhado nível da estrutura. Cada função (ou Feature no FDD, ou User Story no XP, ou Task no Scrum) é mapeada para uma atividade dentro de um processo de negócio, que pode ou não ser automatizada no nosso projeto. Grosso modo, podemos mapear cada função (ou atividade) para uma Usecase (o que eu gosto) e sobre ela centralizar todas as nossas estimativas de tamanho do projeto e custos em baixo nível, seja via Use Case Points (UCP) ou então, conforme entidades mais pragmáticas preferem (Governo, USA, etc.), os Pontos de Função. No caso do 3PUP, usamos os Feature Points (devo falar em outro post, mas é parecido - mas só parecido - com a UCP). Pensando em Java EE, as funções (ou casos de uso) nada mais são do que os métodos públicos de um EJB de negócio. Pensando em nível de negócio, elas são as operações (ações) que o sistema vai oferecer ao usuário, e representam o menor pedaço funcional do nosso sistema. Idealmente, em nível de projeto e gerenciamento, para sabermos o "tamanho" do nosso projeto, precisaríamos elencar todas as suas funções (casos de uso) e estimar, e de baixo para cima montar a WBS do projeto para, então, termos seu custo final. Obviamente, cada modelo de negócio (contrato com o cliente) vai determinar se isso é possível, viável ou interessante. No 3PUP, deixamos essa opção na mão do cliente, e escolhemos se fazemos tudo isso de antemão, ou (seguindo a FDD + Scrum), a cada passo do projeto (Portão de Fase e Ciclo), detalhando um próximo módulo, serviço, ou funcionalidade no nosso pipeline (Product Backlog). De forma geral, e antecipando um futuro post (espero que breve), no 3PUP, seguimos uma regrinha para escrever os nomes nossas "features", no formato AA[R]O, ou seja, Ator Ação Resultado Objeto. Perceba na figura, o caso de uso  "Tecnico (o Ator) iniciar (a Ação) atendimento (o Resultado) do chamado (o Objeto)". Essa estrutura é uma extensão (da novamente bela) FDD, e, não pasmem, é mapeada diretamente para o método de negócio (a Ação) do EJB (o Objeto) e é invocada por um perfil (o Ator) e tem como retorno uma saída (o Resultado).

Termino esse longo post com três pensamentos:

Primeiro, que preciso escrever um paper com isso num texto mais organizado e de fácil entendimento.

Segundo, que preciso configurar o nosso (sempre maravilhoso) Enterprise Architect para ter um profile customizado para o 3PUP, de forma a aplicarmos isso com poucos cliques de mouse.

E, terceiro, que preciso finalizar logo o meu plugin Mizura, para ter tudo isso integrado entre o Excel, Enterprise Architect e Jira.

Bye.