terça-feira, setembro 21, 2010

GWT Designer gratuito by Google

Adoro o branquelo, mas isso todos já sabem.


O que muitos não sabem é que a algumas semanas atrás (ou meses, não lembro certo agora), a Instantiations (aquela, que lá nos idos de antigamente foi uma das primeiras a criar um designer gráfico para o Eclipse... ) foi adquirida por ele.


Uma supresa para muitos na época da aquisição foi que os downloads dos produtos foram indisponibilizados, e o pessoal estava inseguro sobre o futuro da transção. Em parte, nada demais, visto que essas operações (participo de uma nessas nesse momento) têm vários pontos estratégicos a serem analisados, contratos, etc. Então, a decisão foi cautelar, certamente.

Mas hoje, recebi um mail avisado da liberação do novo website dos produtos e confirmando que os contratos ativos serão mantidos até encerrarem. Novamente, óbvio. E sadio.

A boa nova é que agora os produtos da Instantiations, que na época giravam em algo em torno de U$ 1.000 a U$ 2.000 agora são gratutitos. Exatamente isso, de grátis.

O afamado GWT Designer é uma ferramenta essencial na caixa do desenvolvedor Web 2.0 e, embora eu não seja um, acabei de instalar no meu masserado Eclipse e rodei o clássico Hello World para ver os resultados.

Não estou aqui para defender ou atacar o produto, nem mesmo fazer uma análise criteriosa, mas a primeira impressão é que ele manteve a mesma "cara" do produto que era desde os "tempos antigos" da Instantiations (eu usei ele lá por 2002/4), e alguns itens me deixam ainda insatisfeitos (instantiations.equals(insatisfeitos)... ahahha, brincadeirinha), como as bordas não muito bem elaboradas do designer (parece aquele editor antigo do VB...), a falta de inteligência no resize do formulário (onde os componentes internos não têm a dinâmica de redimensionamento que existe no Matisse, lá no Netbeans - sei que são coisas distintas, mas eu esperava mais), falta de exatidão entre o modo Design e o modo Preview dos formulários, os tooltips mal posicionados da paleta de controles (que quando posicionada à direita da tela, simplesmente eles ficam "cortados") e, bem, algumas coisinhas a mais.

Mas eu sou chato, então não vou reclamar de algo que antes eu tinha que desembolsar quase R$ 5.000 e agora tenho de graça...

Assim, vou me ambientar na ferramenta mais um tempo, e com o apoio do branquelo, certamente essa plataforma logo estará evoluindo, ainda mais se todos nós ajudarmos.

Parabéns ao branquelo por mais esta iniciativa.

T+

segunda-feira, setembro 13, 2010

Sete criterios da Fundacao Nacional da Qualidade

Este poste eh para controle meu, visto que devo repassar por isso muitas vezes ainda.

(Resumo dos 7 criterios da FNQ - fora Resultados, utilizados na gestao de empresas)


Lideranca – governança corporativa, processos/filosofia: processos gerenciais, missão e valores, regras de conduta, riscos/vulnerabilidades, processo decisório, relação com sociedade, prestação de contas da diretoria... tudo isso visando a excelência, sustentabilidade, transparência e nível de confiança aos interessados.

Estrategias e Planos – concepção de estratégias, metas e acompanhamento disso, macroambiente, mercado e tendências, endoconhecimento, modelo de negocio x estratégias, como se definem os indicadores, como as metas são desdobradas, como os recursos são alocados, comunicação, monitoramento.

Clientes – informações de clientes e mercado, segmentação do mercado, clientes-alvo, nichos de atuação, como são identificadas necessidades, como são identificados níveis de conhecimento do cliente sobre os produtos/marca da empresa, como eh avaliada imagem da empresa, como divulgar informações nos canais, como tratar solicitações/reclamações/etc, acompanhamento de clientes, como são analisadas informações de clientes para intensificar satisfação, identificação de parcerias com clientes/revendas/fornecedores,
Sociedade – respeito com socidade, aços sociais, influencias na sociedade, como identificar e tratar de impactos sócio-ambientais, prevenção de acidentes, comunicação com a sociedade, condizencia com regulamentações/normas ambientais, tratamento de sanções, acessibilidade as instalações e produtos, desenvolvimento sustentável, fortalecimento da sociedade e vizinhos, avaliação do grau de satisfação da sociedade e melhoria, avaliação da imagem

Informacoes e Conhecimento – Organizacao da informação, controle de ativos, informações para operações diárias, definição/desenvolvimento/melhoria dos sistemas de informação, utilização de TI, infraestrutura para informações, satisfação do usuário com as informações, segurança da informação, identifacacao e separacacao de ativos de alto valor, compartilhamento/retenção de conhecimento na organização,

Pessoas – configuração das equipes, desenvolvimento de competências, bem-estar, autonomia, cooperação, comunicação, seleção de pessoas (interna e externa), integração de novos colaboradores, remuneração e reconhecimento, capacitação/programas de, avaliação de eficácia das capacitações, promoção do desenvolvimento, métodos de orientação/aconselhamento, saúde ocupacional, expectativas das pessoas, formação de lideres, manutenção do bom clima organizacional, melhoria da qualidade de vida.

 Processos – projeto de processos de negocio e apoio, determinação de requisitos de produtos, processo de desenvolvimento de produtos, metodologias aplicadas, avaliação de idéias criativas, concordância entre requisitos do processo de negocio/apoio e as implementações, padronização, controle, autogerenciamento, tratamento de não-conformidades, ciclo PDCA dos processos e produtos, controle de qualidade, avaliação dos processos frente concorrência, - para fornecedores: cadeia de suprimentos, agregação de valor aos produtos, seleção/avaliacao de fornecedores e aquisições, avaliação de expectativas de fornecedores, garantia de qualidade por parte dos fornecedores, estimulação para inovação de processos/produtos de fornecedores, relação dos fornecedores nos processos da empresa, - para financeiro: requisitos de desempenho para financeiro, papel dos sócios, indicadores utilizados, recursos financeiros x operações, captação de recursos, fomo eh feito o equilibro do fluxo de caixa, investimentos, monitoramento de riscos financeiros, elaboração/controle orçamentário x alinhamento com estratégias.

sexta-feira, agosto 13, 2010

Earned Value Analysis no 3PUP

Pois é, este é um post simbólico, que marca um início há muito esperado...

Deixo o screenshot para a posteridade, e espero não muito longe, colocar outro screenshot com os resultados...

terça-feira, junho 29, 2010

Usando sua conta de email da empresa no Google Groups

O Google Groups é uma plataforma fantástica, e agora com o Waves e o Buzz, as coisas só tendem a melhorar.

Porém, muita reclama que ele obriga usar contas @gmail para funcionar.

Na verdade, não é bem assim.

O que o branquelo obriga sim é ter uma conta no Google, para podermos usar seu Single Sign On, e tirar todos os benefícios de ter um usuário unificado na web.

Então, se você quer usar sua conta @suaempresa, sem problemas, pois basta criar uma conta no Google vinculando ela ao seu email empresarial ou pessoal.

É exatamente isso que fazemos aqui na 3layer Tecnologia, onde usamos muitos dos serviços Google na empresa.

Abaixo, o passo-a-passo "basicão":

1. Acesse o Google Accounts para criar uma nova conta, no link https://www.google.com/accounts/NewAccount

2. Preencha os dados, informando o email @suaempresa.

3. O branquelo vai enviar um email para você confirmar que a conta é sua.

4. Acesse o Google Groups e logue com a conta criada.

5. Tome uma cerveja e segue a festa.

quarta-feira, abril 21, 2010

O Processo-Macro do 3PUP

No post anterior, falei sobre ciclo de vida das features no Processo 3PUP.

Abaixo, mostro o processo-macro do Processo 3PUP, seus portões de fase e os principais artefatos produzidos em cada uma dessas etapas:



Não vou entrar no mérito do detalhe (ainda) de cada um desses itens, mas eles estão sendo detalhados, e a trilha desse trabalho pode ser acompanhada pela issue TPUP-46 no nosso Jira.

quarta-feira, abril 07, 2010

O Ciclo de Vida das Features no Processo 3PUP

Uma Feature é o denominador de elementos de projeto no Processo 3PUP.

Ela define tanto as funcionalidades do sistema para o usuário final, quanto os elementos gerenciáveis (as tarefas do projeto), quanto a base de desenvolvimento para o time do projeto.

Em palavras mais simples, uma Feature (conceito da FDD) é algo "parecido" como um Caso de Uso (RUP, UP), ou uma User Story (XP), ou um Point (Scrum).

Em palavras claras, uma Feature é... uma Feature! Adoro isso :)

Bem, mas como as features são controladas, gerenciadas no projeto? Qual é o ciclo de vida de uma Feature no projeto?

Vide a figura abaixo, extraída a pouco do (delicious) Enterprise Architect do 3PUP:


Este é o workflow de uma feature no 3PUP, desde o seu nascimento até que ela morra, desgraçada! (risos, muitos... sempre quis escrever um post com uma frase dessas, sério!)

Bem (mais risos)...(um momento)...(agora sim), para quem conhece a FDD vai perceber que ele está em sintonia com ela (Build Overall Model, Plan By Feature, Design By Feature, Build By Feature), e também não está distante do Scrum (pipeline do projeto via Product Backlog constantemente refinado e priorizado) e também de acordo com o PMBOK no ciclo PDCA (Plan, Do, Check, Act).

De quebra, para quem usa (adoro - como diz o meu tergal) o Enterprise Architect e (adoro idem) e o Jira integrados via nosso plugin Mizura, vai poder ter todo esse controle de Features automatizado, trabalhando com elas sempre sincronizadas entre o projeto lógico (no EA) e o controle operacional (no Jira).

Não entendeu nada, então talvez a descrição abaixo ajude:

1 - Feature não existe: Nada existe. O Product Owner nao tem nem idéia que precisará essa Feature no projeto.

2 - Definição: O Product Owner identificou que precisa de algo no projeto, mas ainda está incipiente.

O Time e o Product Owner trabalham da definição da feature, buscando saber em que parte do projeto este "algo" se encaixa, ou mesmo se ela vai ser uma Feature mesmo ou então um módulo novo, um Serviço, um Set ou um fragmento de funcionalidade que precisa ser incorporado em uma Feature já existente ou, em outra vertente, se este algo não vai fazer parte do projeto ou mesmo se ele vai ser um projeto em separado!

Para sair desse status, a Feature precisa:
1. Ter um nome (no padrao A.A.R.O.)
2. Ter um local para ser encaixada (Modulo, Servico e Set)
3. Ter uma descricao geral, em um parágrafo.
4. Ter um dono (isso deriva do padrao AARO acima, e indica que ela tem um usuario ou grupo de usuarios que vao utiliza-la no sistema quando o projeto for entregue - ou seja, uma role que identifca quem utliiza a feature)
5. Ter um conjunto de requisitos que a balizam (podem ser textuais, genericos, mesmo sem grande formalismo, mas que norteiem claramente sua complexidade e escopo - lembre-se, quanto mais tempo for dedicado para isso nessa fase, mais subsidios ter-se-ao na etapa seguinte, de planejamento).

3 - Planejamento: A feature esta com escopo definido e entrou para a etapa de planejamento, onde vai ser transformada em um elemento de projeto - uma tarefa de projeto.

Nesse momento o PO, o Time e o ScrumMaster vao definir, e ela somente pode sair desse status se:
1. Tiver um dono no projeto (um Chief Programmer da FDD - geralmente um analista de negocio responsavel ou um projetista responsavel), que vai ser responsavel por ela, respondendo por ela, durante todo o ciclo de vida do projeto
2. Ter um tamanho, mensurado em Feature Points (o que sugere que também é mapeado seu tamanho em horas-homem)
3. Ter uma data de entrega (o que sugere que vai ter um FixVersion de entrega). Nada impede que esse FixVersion seja "Unscheduled", ou seja, nao se sabe quando ela vai ser entregue - mas como se diz no PMBOK - "sabemos que nao sabemos quando ela vai ser entregue".
4. Ter uma prioridade (ou Rank no Scrum) perante as outras features no projeto, ou seja, ela tem um indice de importancia e interesse para o PO.

4 - Projeto: A feature está estimada e é parte da WBS do projeto, e agora vai ser detalhada tecnicamente.

Nesta etapa de projeto, a feature será projetada, arquitetada e esmiuçada nos mínimos detalhes, pois é com base nesse projeto técnio que ela será construída.

Nesse ponto, a feature precisa estar exatamente como o PO a deseja.

O projeto técnico envolve tanto o Time (na figura, geralmente, do analista ou projetista responsável - o Chief Programmer, mas também envolvendo os outros recursos do time, como arquiteto, scrum master, desenvolvedores, e outros), quanto - e principalmente - o PO, e portanto ambos trabalham em sitonia, buscando detalhar cada aspecto relevante para a Feature representar o fidedigno do que o PO deseja.

O projeto técnico está completo, e a Feature somente pode sair desse status se:
1. Possuir um Caso de Uso, descrito segundo o padrão OBJETIVO; ATOR PRINCIPAL, ENVOLVIDOS E EXPECTATIVAS; PRE-CONDICOES; EVENTOS DE DISPARO; FLUXO PRINCIPAL, FLUXOS ALTERNATIVOS; POS-CONDICOES; EXCECOES)
2. Possuir uma lista de requisitos associados
3. Possuir um projeto de dominio, que descreve as Classes e Operacoes relacionadas (geralmente, um Diagrama de Classes)
4. Possuir um projeto de interface de usuario (geralmente uma tela, mas nem sempre), que identifique claramente os pontos de interacao e elementos envolvidos e tambem a parte navegacional do sistema (a IU em relacao as outras IU do sistema, menus, telas, validacoes, etc).
5. Possuir um projeto de implantacao e comunicacao, que descreve como a Feature deve ser empacotada e disponitilizada no sistema frente a estrutura e arquitetura da aplicacao.
6. Possuir um projeto de teste associado, incluindo teste unitario (a Feature funcionando), teste integrado (a Feature funcionando em conjunto com outras Features dentro do seu Servico), e funcional (a Feature em uso dentro do sistema final, sendo utlilizada pelo usuario final do sistema)


Observa-se que nesse ponto, o projeto tecnico segue o padrao 4+1 (porem ajustado), ou seja, a parte 1 é o quadrante logico (o Caso de Uso, os Requisitos e os Testes), a parte 2 é o nível de desenvolvimento (o Projeto de IU e o Diagrama de Classes), a parte 3 é o quadrante físico (o Diagrama de Implantacao ou Comunicacao) e a parte 4 é o quadrante de processo (ou de processamento, que envolve os famosos requisitos nao funcionais e a questao arquitetural, onde na verdade, o projeto tecnico da Feature precisa ser encaixado na arquitetura da aplicacao de forma transparente, e por isso esse quadrante pode ser minimizado no projeto tecnico, de forma que ele pode ser interpretado e implementado como uma lista de requisitos diferenciado - esteriotipo "nao funcional" por exemplo - na propria lista de requisitos da Feature.).

Caso o projeto técnico mostre discrepância em relação ao planejado (complexidade, tempo, etc), á Feature precisa retroceder no worfklow para a etapa de planejamento.

Isso pode ocorrer na primeira tentativa de projeto técnico, ou mesmo depois que este já foi finalizado uma vez e a construção tenha sido iniciada ou  mesmo já em validação (etapa de validação).

Logo, fica subentendido que uma Feature nunca vai estar fora de sintonia em relação ao plajemaneto do projeto, seja estimada "para mais" ou estimada "para menos".

É responsabilidade do Chief Programmer "sentir" essa discrepância e reportar ao ScrumMaster e PO essa divergência para que a Feature volte para a etapa de planejamento.

Somente com esse projeto tecnico, esta apta a passagem para a próxima etapa de construção.
5 - Construção: A construcao é a realizacao do projeto tecnico.

Aqui, o Time trabalha continuamente, produzindo a feature, testando-a continuamente e evoluindo sua funcionalidade constantemente.

A presenca do PO aqui também é válida e muito importante, pois ele vai ajustando arestas e complmenetando informações durante a construção da Feature, o que vai minimizar quaisquer problemas na etapa posterior de validação funcional.

O Chief Programmer (ou Projetista ou Analista responsável) é o recurso que constanmente monitora e "puxa" o desenvolviemento da feature junto ao time, reportando o andamento diariamente durante as reuniões Stand Up de avaliação do Scrum.

Durante a construção é plausível que o projeto técnico mostre-se inadequado. Então, nesse caso, descarta-se totalmente o avanço na construção e esta deve retornar para o projeto técnico.

Observa-se assim que a Feature pode retroceder no worfklow. Assim, não deve ser construída uma Feature que esteja fora de conformidade com o seu projeto técnico.

Logo, Features que não podem ser construídas de forma avessa ao seu projeto técnico (seja porque o projeto técnico é inconsistente ou incompleto, seja porque ela está agredindo outra feature, seja porque o PO não está satisfeito com a Feature ou qualquer outro evento).

Em todos esses casos, a Feature retrocede para o projeto técnico.

É responsabilidade do Chief Programmer em conjunto com o Time reportar essas divergências de implementação frente ao projeto técnico.

Se o projeto técnico está OK, a feature é dada como construída está apta para evoluir no workflow de validacao se, e se:

1. Todos os testes unitários e integrados estiverem consistentes.
2. O PO deu seu OK na Feature durante o processo de homologação do sistema. 

6 - Validação: Aqui, a Feature já foi construída e está em concordância com o projeto técnico.

Nessa etapa, o PO em conjunto com seus usuários finais realiza os testes de aceitação da Feature, os chamados testes funcionais.

Nesse ponto, é esperado que estes testes sejam balizados pelo Casos de Uso associado à Feature, bem como a lista de requisitos que a norteiam, o projeto de IU associado e os testes funcionais atrelados.

Caso qualquer inconsistência apareça, a Feature precisa retroceder para a etapa de Construção, e, eventualmente, dessa para outras etapas anteriores, conforme descrito nas outras etapas.

É responsabilidade do PO, em cojunto com os usuários finais e o Chief Programmer realizar estes testes.

Qualquer anomalia ou inconsistência de funcionamento no teste funcional deve produzir um item de correrção de Feature, e ser ligado (linkado como derivação da Feature) para entrar no pipeline de correção do projeto.

Uma Feature somente pode sair da etapa de validação com o OK formal do Product Owner sobre ela, o que pode ser feito na ferramente de controle do projeto ou então através de relatórios de entrega, tanto faz, mas é explicitamente necessária essa aprovação formal.

7 - Entregue: A Feature foi construída e entregue, e está funcionando perfeitamente no sistema, conforme o PO desejava desde o início do projeto.

8 - Cancelada: Por qualquer motivo, a feature pode ser cancelada, e a qualquer momento.

Quem decide pelo cancelamento de uma feature é, exclusivamente, o PO.

Embora a equipe pode achar que a feature seja inimaginavelmente complexa ou irreal, isso não importa, pois o PO pode assim mesmo a desejar e disposto a esperar e pagar por isso.

Assim, cabe somente ao PO cancelar uma feature.

O ScrumMaster, o Time e seus Chief Programmers podem, porém, persuadiar o PO para que ele cancele features que não estejam em sintonia com o projeto.

Dito isso, volto para a cozinha e faço um (adoro!) delicious tubão de café, e depois, mais uns commits no Mizura ;)

quarta-feira, março 31, 2010

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.

sábado, fevereiro 20, 2010

Template para Use Cases

Ha muito tempo fui projetista de sistemas. Porem, agora isso nao faco mais.

Hoje, quando olho para o M. sofrendo com codigos-fonte sem Javadoc, sem casos de uso definidos, sem "facades" representando os limites do sistema, com "actions" contendo regras de negocio e com "beans" incluindo validacoes e outras coisas, bem, fico muito P. da vida com a "desvirtuacao" do Scrum nos projetos, ou melhor dizendo COM A FALTA DE PROJETO DE SOFTWARE.

Atualmente, meu unico envolvimento com programacao propriamente dita eh na implementacao do meu "pluginzinho" Mizura, que eh um conector robusto para integrar coisas como o Enterprise Architect e o Atlassia Jira, fazendo com que as usecases dos projetistas sejam refletidas de forma transparente como issues na gerencia de projetos.

Bem, como estou praticamente sozinho (again!) em mais este movimento Open Source, estou usando o "estilo cowboy", progamando e criando a arquitetura e classes do projeto conforme as necessidades vao surgindo.

É o tipico Scrum, onde o Product Backlog aparece a cada novo Sprint :)

Ora, todavia surgem momentos em que as regras de negocio ficam complexas (mesmo) e, por isso, o velho e bom projeto de software volta a tona.

Assim, o Mizura tambem possui um projeto "pseudo detalhado" das coisas; ou, em outras palavras, um projeto de software quando as coisas ficam complicadas mesmo!

Uma das coisas (bem) complicadas no Mizura eh o processo de sincronizacao dos elementos (por exemplo, Usecases e Issues); justamnte o "core" do meu plugin.

Para tando, visto que tenho 17 opcoes de sincronizacao distribuidas em 3 formas de operacao, acredito piamente que preciso projetar bem esse aspecto.

Nesse contexto, alem de tentar usar a APIs como o  Google Collect para simplificar o processo, estou montando os casos de uso desses cenarios.

Mas pasmem, percebi que, embora eu tenha mais de 12 anos de experiencia nisso, e o 3PUP esteja em construcao, nao padronizei meus casos de uso ainda.

Seguindo as premissas do Alistair Cockburn e adequando as coisas para o ambiente tupiniquim de desenvolvimento, estou adotando o seguinte padrao de casos de uso:

Template para caso de uso

Objetivo:
Frase curta, resumindo a meta/o porque desse caso de uso existir

Ator principal, envolvidos e expectativas:
Lista numerada, que identifica o ator principal, seguido do seu objetivo com este caso de uso.

Pre-condicoes:
Lista numerada, que identifica todas as pre-condicoes necessarias para que este caso de uso possa ser realizado.

Eventos de disparo:
Lista numerada, que identifica todos os eventos que podem iniciar este caso de uso.

Fluxo principal:
Lista numerada, no formato ATOR ACAO OBJETO , mostrando a acao realizada no desenvolvimento do caso de uso.

Fluxos alternativos:
Lista numerada, a partir do ponto do fluxo principal, no formato ATOR ACAO OBJETO, mostrando a acao alternativa realizada no desenvolvimento do caso de uso. Caso nao existam, use o termo "1. Nada consta."

Pos-Condicoes:
Lista numerada, mostrando as condicoes esperadas do caso de uso. Sempre deve existir pelo menos uma pos-condicao, que é justamente o resultado principal (o objetivo) do caso de uso.

Em caso de excecoes:
Lista numerada, no formato , mostrando o que o ator envolvido deve fazer no cenario onde o caso de uso nao pode ser realizado (por exemplo, se o software der problemas, ocorrer falta de luz, queda de rede, etc.).Caso nao seja planejado, use o termo "1. Nada consta."

Exemplo de caso de uso

Como exemplo, mostro este do Mizura:

Caso de uso:
UC0019 - Usuario sincronizar elementos da origem para o destino

Objetivo:
Elementos do repositorio no lado direito (destino) serem sincronizados com informacoes contidas no repositorio do lado esquerdo (origem)

Ator principal, envolvidos e expectativas:
1. Usuario, ter as informacoes sincronizadas da origem para o destino.

Pre-condicoes:
1. Repositorios estarem disponiveis

Eventos de disparo:
1. Usuario solicitar sincronizacao dos elementos UML com issues

Fluxo principal:
1. O usuario indica o repositorio de origem a ser sincronizado
2. O usuario indica o repositorio de destino a ser sincronizado
3. O usuario invoca a sincronizacao "origem para destino" (left_to_right)
3. INCLUDE Usecase UC0020
4. Fim
Fluxo alternativo:
1. Nada consta

Pos-Condicoes:
1. Nada consta

Obviamente, cada caso é um caso (de uso, hehehe) e assim, meu template pode nao ser adequado para todas as situacoes.

Entretanto, este formato esta de acordo com o 3PUP e tambem segue as premissas da FDD, e vai permitir que eu possa estimar isso as "famosas" Feature Points (ou FEP), - semelhantes as Use Case Points (UUCP) -  que podem ser traduzidas em horas-homem e, finalmente, em R$.

Abraço a todos e mais um Redlabel (o quinto) nesta sexta feira a noite.

sexta-feira, janeiro 08, 2010

Moving towards the integration between Jira and Enterprise Architect

Dando seguimento ao post inicial sobre integração entre o Jira e o Enterprise Architect (EA), nesta semana que passou, acredito que dei dois passos importantes até agora.

Primeiro, consegui no commit número #93 deixar a parte 1 de 3 do referido plugin (vou descrever a arquitetura dele em outro post) funcionando.

Em outras palavras, já tenho um servico EJB Stateful que provê acesso a múltiplos clientes e invocações repetidas ao repositório do EA. Também, usando o padrão Factory com um cache de mapas, consigo manipular múltiplos repositórios do EA de forma transparente; e com o uso da anotação @PreDestroy, garanto que não ocorra vazamento de recursos em caso de queda de sessões de clientes. De quebra, usando o padrão Delegate entre a camada EJB e a classe Wrapper, consigo usar o Wrapper para manipular o repositório do EA localmente (ex. sem uso de container JavaEE), se for o caso.

Segundo, e isso levou esta noite toda, consegui seguir o passo-a-passo do pessoal da Atlassian para montar um ambiente de desenvolvimento com o Atlassian SDK para o meu Eclipse.

Com isso, posso fazer a parte 2 de 3 do plugin, que visa a conexão dos elementos do EA via protocolo SOAP (é um protocolo mesmo?) com as issues no Jira.

Depois de muito sofrer com o Maven (detesto ele!), tendo que baixar os Jars da JTA e JNDI por fora, e transformar o projeto em um projeto Eclipse (isso foi fácil, com mvn eclipse:eclipse; mas demorou 27 minutos!), montei o projeto e rodei os demos. Bingo!

Minha primeira issue Jira via SOAP

Com os demos rodando, criei uma classe tosca, e alterei a URL do Jira demo para apontar para o nosso Jira. Depois, regerei as classses Java via o WSDL e, voilá.

Abaixo, o screenshot da issue JB-552, criada em nosso ambiente, e logo após a classe de teste:







/**
 *  Copyright 2010 3L TECNOLOGIA
 * 
 *  Licensed to the Apache Software Foundation (ASF) under one or more
 *  contributor license agreements.  See the NOTICE file distributed with
 *  this work for additional information regarding copyright ownership.
 *  The ASF licenses this file to You under the Apache License, Version 2.0
 *  (the "License"); you may not use this file except in compliance with
 *  the License.  You may obtain a copy of the License at
 *
 *      http://www.apache.org/licenses/LICENSE-2.0
 *
 *  Unless required by applicable law or agreed to in writing, software
 *  distributed under the License is distributed on an "AS IS" BASIS,
 *  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 *  See the License for the specific language governing permissions and
 *  limitations under the License.
 *
 */
package com.atlassian.jira_soapclient;

import java.net.MalformedURLException;
import java.net.URL;

import com.atlassian.jira.rpc.soap.client.JiraSoapService;
import com.atlassian.jira.rpc.soap.client.RemoteAuthenticationException;
import com.atlassian.jira.rpc.soap.client.RemoteException;
import com.atlassian.jira.rpc.soap.client.RemoteIssue;
import com.atlassian.jira.rpc.soap.client.RemotePermissionException;
import com.atlassian.jira.rpc.soap.client.RemoteValidationException;

/**
 * @author mmrack
 * @since 08/01/2010 01:09:47
 *
 */
public class LM2JiraSOAPClient {

    private JiraSoapService jiraSoapService;

    private String authToken;

    public LM2JiraSOAPClient(String user, String password) throws Exception {
        authToken = connectTo(
                "http://jboss.lm2.com.br/jira/rpc/soap/jirasoapservice-v2", user,
                password);
    }

    /**
     * @param args
     * @throws Exception
     */
    public static void main(String[] args) throws Exception {
        LM2JiraSOAPClient jiraClient = new LM2JiraSOAPClient("mmrack",
                "mypassword");
        String iKey = jiraClient.createIssue("JB", "1", "LM2JiraSOAPClient Issue",
                ":)");
        System.out.println(iKey);
    }

    private String createIssue(String pkey, String type, String summary,
            String description) throws Exception {
        String iKey;

        RemoteIssue issue = new RemoteIssue();
        issue.setProject(pkey);
        issue.setType(type);
        issue.setSummary(summary);
        issue.setDescription(description);

        RemoteIssue returnedIssue = jiraSoapService.createIssue(authToken, issue);
        return returnedIssue.getKey();
    }

    private String connectTo(String url, String user, String password)
            throws Exception {
        SOAPSession soapSession = new SOAPSession(new URL(url));
        soapSession.connect(user, password);
        this.jiraSoapService = soapSession.getJiraSoapService();
        return soapSession.getAuthenticationToken();
    }

}

Próximos passos

Estou trabalhando com o P. nesse projeto fora de horário, e ele deve dar ênfase na parte da interface do usuário, que espero fazer em Grails.

Quanto à parte 3 de 3 do plugin, esta envolve Model Driven Architecture (MDA) e, por isso, devo iniciar um projeto logo (já faz mais de ano que digo isso!) com o F., lá na PUCRS.

Enquanto as partes 1 e 2 do plugin visam ser totalmente Open Source, essa parte 3 visa dar um retorno financeiro para nós e, assim, o objetivo é fazer algo bem estruturado, que possa operar de forma fragmentada ou integrada, visando tando desenvolvedores standalone, quando softwarehouses de porte, onde projetos grandes carecem de sincronia de informações.

Bye.