Papéis na transição do modelo tradicional para o Scrum

Após acompanhar esta discussão, no grupo scrum-brasil, sobre o papel e as atividades do ScrumMaster (SM), pude perceber algumas opiniões que reforçam o que penso sobre o assunto e tenho visto por aí.

Muitas empresas pecam na transição de modelos tradicionais para metodologias ágeis simplesmente por apenas converter o antigo em novo, sem reservar tempo para estudar e avaliar os conceitos envolvidos e as diferenças nas formas de pensamento. Assim, acabam por evitar mudanças (as vezes propositalmente, visando evitar conflitos) que seriam essenciais para obterem sucesso na reestruturação que desejam.

Leia mais…

Códigos de exemplo e exercícios em Java

14/04/2010 1 comentário

Fala galera!

Atualizei meu repositório no google-code (http://code.google.com/p/exercicios-java-uerj/) com os últimos projetos que trabalhamos em sala (curso de extensão em Java – UERJ/IME). Quem quiser pode fazer o check-out via svn ou download do .rar, na área de específica.

Aos que não fizeram o curso mas acompanham o blog, sintam-se a vontade para baixar, melhorar e opinar…

Grande abraço e, aos que estiveram no curso, parabéns e obrigado pela atenção!

Errando logo no início com as famosas RFP´s

14/02/2010 2 comentários

Enquanto curtia a pequena folga de carnaval (trabalharei segunda e quarta-feira – arghhhh)  parei para conferir os e-mails e li este post:

Primeiro passo para um projeto de software falhar: a RFP

A questão levantada pelo autor é bastante interessante e é uma grande realidade em diversas empresas.

– Vamos desenvolver um projeto? Então, escreveremos uma RFP, a entregaremos a algumas empresas e contrataremos a que melhor nos atender (a partir daí, “a que melhor nos atender” pode significar diversas coisas e até, simplesmente, a mais barata).

O problema é que estão negando um princípio muito importante da construção de softwares: Não sabemos o que queremos no início (vide cone da incerteza). Daí, especificamos, no início, algo que pode não ser o mais interessante no final e exigimos que seja feito exatamente daquele jeito.

Em contrapartida, o fornecedor incluirá cláusulas contratuais que bloqueiem (ou ao menos dificultem) qualquer alteração no escopo do projeto, sob pena de multas contratuais. Assim, fazem com que sejam fixados preço, prazo e escopo (logo, a única coisa que pode e vai variar será a QUALIDADE) e, o pior, geralmente não definimos o que será considerado como software de qualidade, no início.

Por exemplo, no que se refere a mudanças no escopo, imagine o impacto que a seguinte frase pode causar no sucesso de um projeto de software (falando de funcionalidades que atendem de forma eficiente e eficaz as necessidades dos usuários e não simplesmente de entregar dentro do prazo e custo definidos – aliás, entregar com prazo e custo dentro do estimado no início é o mais difícil de acontecer):

“Quaisquer alterações no escopo deverão ser apresentadas com no mínimo 30 dias de antecedência e estarão sujeitas a análise do fornecedor”.

Claro que, geralmente, estas alterações serão aceitas pelo fornecedor, desde que o cliente aceite pagar (bem) mais por isso. Afinal, já existem dezenas de documentos definindo o que será feito e tudo deverá ser alterado…

É incrível como, apesar de tanto movimento a favor de melhores práticas e métodos, ainda encontramos diversas empresas com modelos de contratação que não favorecem o sucesso dos projetos de software.

Logo de início, exige-se zilhões de entregáveis que devem ser entregues antes que qualquer linha de código tenha sido escrita. Daí, o que vemos no final são pilhas de documentos mortos desatualizados (ou raramente/precariamente atualizados) e software que não é compatível com o que foi escrito…

De qualquer maneira, alguns pontos que precisamos levantar são:

Estariam os fornecedores preparados/receptíveis para contratos ágeis?

Estariam os clientes e fornecedores preparados para compartilharem os riscos nos projetos de software ao invés de continuarem no “jogo de empurra” onde um quer deixar a culpa para o outro?

É…, sei não viu…

A[]´s e até mais.

Java EE 6: Comeando com Bean Validation

Exemplos de código e Exercícios em Java

17/12/2009 1 comentário

Como havia prometido ao pessoal do curso de extensão em Java da UERJ/IME, estou preparando alguns códigos de teste e exercícios para auxiliar no aprendizado fora das aulas.

Assim, acabo de fazer o primeiro commit deste material no GoogleCode e podem acessar através do link: http://code.google.com/p/exercicios-java-uerj/.

Os exemplos foram feitos utilizando o Eclipse. Sigam os passos abaixo para baixarem e explorarem os exemplos:

  1. Faça o download do arquivo ExerciciosJavaUerj.rar através do link acima (ou clicando aqui);
  2. Descompacte o arquivo na workspace do Eclipse em utilização;
  3. No Eclipse, acesse File -> Import -> Existing Projects into Workspace e clique em Next;
  4. Clique em “Browse”, selecione o diretório o arquivo foi descompactado e clique em “Finish”;
  5. Pronto! A esta altura o projeto já deve estar aparecendo na lista de projetos do Eclipse.

Uma outra dica de fonte de estudo é o site http://www.java2s.com/. Aqui podem ser encontrados diversos exemplos de código (disponível para download) para as mais variadas coisas. Vale a pena dar uma olhada…

Qualquer dúvida e/ou problemas, me avisem. Boa sorte e bons estudos!

Google SpeedTracer: Identifique problemas de performance em suas aplicações web

O pessoal do Google não pára mesmo… Agora, junto com o lançamento do Google Web Toolkit (GWT) 2.0, no dia 8-12-2009, foi disponibilizada uma nova e interessantíssima ferramenta para análise de desempenho de aplicações web – o SpeedTracer.

O SpeedTracer (que foi desenvolvido utilizando o próprio GWT) é um plugin para Google Chrome que permite realizar o profiling de aplicações web (não só as desenvolvidas com o GWT) de maneira bem fácil e com recursos interessantes,  provendo insights sem precedentes sobre o funcionamento interno de qualquer aplicação web (como dito por eles mesmos no blog da ferramenta, descrito logo abaixo).

Abaixo, seguem alguns links interessantes para saber mais sobre assunto:

No site da ferramenta podem ser vistas informações sobre seu download e instalação, além de exemplos de utilização.

Dica rápida: Após atualizar a versão do Chrome para a Google Chrome Developer Channel e antes de instalar o SpeedTracer, feche as telas do Chrome que estiverem abertas e inicie novamente. Tive alguns probleminhas com isso…

Vale a pena dar uma olhada…

Groovy Power: Flexibilidade, Simplicidade e Código Legível

07/12/2009 1 comentário

Enquanto não consigo tempo para me aventurar fortemente, tenho resolvido alguns problemas específicos e lido algumas coisas sobre o Groovy.

Neste post o autor apresenta as coisas que acho mais interessantes na linguagem. Vale a pena dar uma olhada:

Groovy Power: Flexibilidade, Simplicidade e Código Legível.

Junte isso ao poder do Grails e o resultado é no mínimo instigador!