quinta-feira, julho 07, 2011

Novo visual para Google Calendar

 É isso aí, o o branquelo não pára.

Há algum tempinho o Google já vem atualizando suas aplicações para a nova arquitetura GWT, com uma interface e e apelo visual atualizado.

Começou pelo Orkut, passou por aplicações como Blogspot, pela própria interface do Search, pelo GDocs e também para quem usa o GApps, quase toda a suíte de aplicativos corporativos.

Como mes passado veio o lançe da integração das contas (Single Sign On) de usuário (@gmail) comum e corporativo (@suaempresa), fazia um tempinho já que eu não abria o Google Calendar pela minha conta @gmail.

Hoje abri. E olha a surpresa:



O que temos aí?

Ainda não sei, mas vou começar a comparar as diferenças e aguardar isso "virar" também para minha conta corporativa, abaixo:

Quer saber mais? Então acesse a FAQ do Google.

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 ;)