Estimativas Ágeis - Planning Poker

Em projetos de software tradicionais, (leia-se não ágeis), geralmente fazer estimativa é algo muito chato, e que provavelmente será feito por apenas uma pessoa, que na maioria das vezes essa pessoa é o gerente de projeto, ou o líder da equipe, que utiliza métodos tradicionais para medir uma atividade com análise de ponto de função, ou por linhas de código, etc... mas acontece que quase sempre essa pessoa não conhece a fundo o negócio e as dificuldades técnicas de se implementar uma certa funcionalidade.

O que acaba gerando problemas no decorrer do projeto, pelo fato do analista de negócio (quando tem) não ter previsto uma funcionalidade adicional, ou uma regra de negócio imprescindível para o negócio.

Nesta altura de campeonato, quanto este tipo de situação acontece, geralmente o projeto já esta em um estágio avançado no desenvolvimento, e ATRASADO.. o cliente está puto,,, e sempre quem acaba levando a culpa é o incompetente do desenvolvedor.

Se você já se sentiu familiarizado com este triste relato, pois bem, não fique triste, pois isto já aconteceu comigo e acontece com milhares de pessoas nos dias atuais...

Pois bem, existe solução para este problema?

Sim, existe, se olharmos para alguns dos príncipios ágeis, conforme segue:

"Business people and developers must work together daily throughout the project. "

Traduzindo, quer dizer algo como "Analistas de negócio e desenvolvedores devem trabalhar juntos DIARIAMENTE no decorrer do projeto".

"The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. "

Traduzindo este também,

“O método mais eficiente e efetivo de obter informação para o time de desenvolvimento é na conversa cara-a-cara."

"Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. "

E por último..

“Mudanças de requisitos são bem vindas, mesmo em um estágio avançado no desenvolvimento. Processos ágeis alinham as mudanças para vantagem competitiva do cliente."

Uma estimativa bem feita durante a fase inicial do projeto, reduz muito as chances de você ter dores de cabeça no futuro.

Ok, você está se perguntando, "Mas isto não respondeu a pergunta !!!", como eu posso melhorar as estimativas no inicio de um projeto ou de uma nova iteração ???

Existe um método ágil para estimativas, chamada de Planning Poker, esse método foi descrito inicialmente por James Grenning em 2002 e depois popularizado por Mike Cohn no seu livro Agile Estimating and Planning,, essa técnica é muito conhecido em XP.

Para "jogar" o Planning Poker precisamos apenas de uma lista de backlog e um baralho. E o baralho, geralmente composto por cartas que possuem uma seqüência fibonaci ou similar (0, ½, 1, 2, 3, 5, 8, 13, 21, 34, 50, 80 ,100, ?) e uma carta opcional com um sinal de interrogação.

Por que utilizar esta seqüência, e não um conjunto de números naturais (0,1,2,3,4,5,6,7,etc...) ?

Boa pergunta, mas vou responder com outra pergunta, você consegue distinguir o número 13 do número 14? Fica mais fácil você ter uma noção de separação de complexidade, quando você trabalha com números em uma seqüência fibonaci, imagine que para cada tarefa, quando você for dar o seu peso, pense que uma tarefa com peso 2, é 2 vezes mais difícil que uma tarefa com peso 1.

Voltando ao PP, para jogar, cada participante, geralmente os membros da equipe de desenvolvimento (programadores, testers, designers, etc..) devem possuir uma seqüência de cartas, e cada funcionalidade da lista de backlog irá corresponder a uma rodada do jogo entre a equipe. Os membros não podem conhecer as cartas uns dos outros até início da rodada.

Para facilitar o entendimento, vou demonstrar um exemplo real, imagine que temos uma lista de backlog conforme a tabela abaixo, apresentada pelo Product Owner, e o mesmo dá explicações relacionadas a cada um dos itens, onde todos os membros discutem para chegar a um entendimento do problema.
Na nossa ambiente, vamo imaginar que temos 5 membros, 3 desenvolvedores (Carlão, Maria, Zeca), um tester (Júlio) e uma designer (Rita) e o Project Manager / SM (Walter). O Product Owner neste momento, já deu uma visão dos itens de backlog e explicou a necessidade do negócio, tirou algumas dúvidas e foi embora..

É importante frizar que os membros do time devem estimar todo o trabalho relacionado ao item do backlog, e não apenas a sua parte especifica.

Antes de iniciar a primeira rodada, o SM inicia a discussão:

Walter (SM): Pessoal, o que vocês acharam dessa user story (100)?, o usuário quer um repositório para armazenas os documentos operacionais da empresa assim, assim, assado, então, vamos votar:

Então, neste momento cada membro da equipe, pega uma carta que acha que corresponde com os Story points e depois que todos escolheram suas cartas, tem inicio a rodada. No nosso exemplo, o resultado foi esse:

Rodada 1:
Perceba que na primeira rodada, tivemos pessoas que votaram 50 (Maria, Julio), duas que votaram 80 (Zeca, Rita), um 21 (Carlão) e um 34 (Walter), neste momento o mediador (geralmente o Scrum Master) questiona os resultados.

Walter (SM): Peraí gente, vamos discutir, esta tendo muita divergência, Rita e Zeca, porque vocês acham que essa atividade tem um peso 80?

Rita (Designer): É por que, fico imaginando o tamanho dessa aplicação, já é uma bagunça hoje a forma que é organizado os documentos, imagina só o trabalho de reclassificar tudo, montar um repositório, modelagem, etc... e chora.. ..

Walter (SM): Huum entendi, e você Zeca.

Zeca (Dev): Concordo com a Maria, imagina a quantidade de trabalho.. e chora mais.. etc..

Walter (SM): Carlão porque você acha que é 21, é tão fácil assim??

Carlão (Dev): Na verdade, olhando na ótica do Zeca e da Rita, o problema me parece ser mais complexo do que pensei,..

Walter (SM): Então, o que vocês acham da gente pesquisar alguma ferramenta open source que nos ajude neste trabalho, como um ECM ??? Estava pensando em algo neste tipo, senão realmente teremos muito trabalho,,,

Júlio (tester): Ok Walter, ótima idéia, mas acho que vamos ter muita customização, e com a estrutura que temos hoje não será nada fácil.. Imagine a quantidade de testes !!!

Walter (SM): Certo, se todos estão de acordo, vamos implantar um ECM, vamos fazer mais uma rodada então...

Nisso, é feito a segunda rodada (Tabela 1), podemos ver que houve um consenso..

Neste exemplo simples, podemos observar que alguns benefícios ficam bem claros:

• O Product Owner descreve cada história resumidamente, de forma que todos tem uma idéia do que esta rolando.
• A sinergia entre a equipe aumenta, cada for iniciar um Sprint, onde as tarefas estarão bem definidas, os membros do time, terão uma idéia bem definida do que esta sendo feito, do que o seu colega de trabalho esta fazendo.
• O risco de erros da estimativa diminui dramaticamente.
• As diferenças de opiniões ficam transparentes, de modo que todos passam a discutir estas diferenças.
• É possível re-estimar uma user story até que haja um consenso.

Ok, muito legal esta explicação, mas ainda falta algo, qual a relação entre os princípios ágeis citados no início deste artigo com este jogo de cartas?

Bem, respondendo a pergunta, eu diria que tem tudo a ver, quer ver só:

"O método mais eficiente e efetivo de obter informação para o time de desenvolvimento é na conversa cara-a-cara."

Em planning poker todos estão conversando, (quase sempre olho no olho), o que dá transparência ao negócio.

"Analistas de negócio e desenvolvedores devem trabalhar juntos DIARIAMENTE no decorrer do projeto".

Ao fazer o planning poker, estamos discutindo requisitos funcionais e não funcionais, que visam a realização de um desejo do cliente, e geralmente, durate o planning poker está o Product Owner, para tirar todas as dúvidas em relação ao negócio e verificar se está sendo feito o que foi acordado.

E por último..

"Mudanças de requisitos são bem vindas, mesmo em um estágio avançado no desenvolvimento. Processos ágeis alinha as mudanças para vantagem competitiva do cliente."

Isso irá sempre acontecer, sempre haverá novas features/sistemas a serem desenvolvidos, e durante a estimativa podemos discutir de maneira mais técnica, até modelos de arquitetura, pois querendo ou não, a arquitetura/modelo que será desenvolvido o produto tem um forte peso nas user stories. Portanto, a qualidade do código e do modelo é essencial para que as mudanças de requisitos sejam menos "traumáticas".

Estive no Sun Tech Days, e uma palestra que achei interessante foi a "Usando computação social para melhorar a produtividade no seu projeto" da "Java Champion" Fabiane Nardon, onde ela apresentou várias ferramentas para computação social, e uma das ferramentas citadas foi o site "http://www.planningpoker.com/", um site idealizado por Mike Cohn, e propõe uma ferramenta para que time distribuídos façam a estimativa em conjunto, tem algumas coisas a melhorar, mas a idéia é bem bacana..

OBS> Nas fotos acima, a 1º é uma sessão de planning poker no meu ambiente de trabalho, e na segunda foto o PO priorizando e discutindo os itens de Backlog.

Planning poker com certeza é uma ótima prática, e é também uma boa maneira de iniciar no mundo ágil..

Diversão garantida !!!

[JavaEE 6] EJB 3.1 no GlassFish V3 e NetBeans

Esta semana saiu nas bancas a edição 31 da revista Mundo Java com o título "Futuro do Java Corporativo", com um artigo meu sobre o mesmo tema.
Para quem quer saber o que vai rolar na próxima especificação do Java EE 6, está edição está um prato cheio, portanto compre uma edição e aproveite...
Não vou entrar em muitos detalhes da matéria, mas vou descrever aqui melhor a demo que está na revista, onde apresento uma aplicação utilizando Session Bean da especificação de EJB 3.1 no GlassFish V3.

Instalando o GlassFish V3 e o conteiner EJB

No site do GlassFish baixe o arquivo zip e descompacte em um diretório da sua escolha, a partir deste momento vamos chamar apenas de GLASSFISH_HOME\bin e execute o updatetool (Figura 1).
Na opção available addons, selecione glassfishv3-ejb e clique em Install, esta ação irá instalar o container EJB no Glassfish.

Instalando o plugin GlassFish V3 no NetBeans

Agora inicie o NetBeans (de preferência a versão 6.1 ou 6.5) e instale o plugin do GlassFish V3 para o NetBeans em Ferramentas | Plugins, selecione em plugins disponíveis "Glassfish JavaEE Integration" e clique em instalar.
Após instaldo o plugin, na aba Serviços, adicione um novo servidor, selecione a opção GlassFish V3 e siga os passos apontando o diretório GLASSFISH_HOME de instalação e finalizar.



Vamos explorar agora uma funcionalidade no NetBeans para a criação de CRUD, crie uma nova Aplicação Web na categoria Web e clique em Próximo.
Neste passo digite "DEMO_EJB31" e clique em Próximo, na opção servidores selecione o servidor GlassFish V3 T2 recém instalado e clique em Próximo. No último passo selecione o framework JavaServer Faces e clique em Finalizar.

Agora vamos criar uma aplicação CRUD completa baseada em uma entidade de banco de dados, para isso clique em Arquivo | Novo Arquivo, na categoria Persistence selecione a opção "Classes de entidade do banco de dados" e clique em Próximo.
OBS: Antes de fazer o passo abaixo, inicie o banco de dados Derby na guia Serviços do NetBeans, clique com o botão direito do mouse em Java DB e clique em "Iniciar Servidor".

Neste segundo passo, na lista Fonte de Dados selecione a opção "Nova Fonte de Dados", no campo "Nome JNDI" digite jndi/TesteEJB e na lista "Conexão de banco de dados" selecione o banco "jdbc:derby://localhost:1527/vir" já existente e clique em OK.

Se tudo ocorreu de maneira correta será apresentada uma lista de tabelas disponíveis. Selecione a tabela Employee, clique em Adicionar e em seguida clique em Próximo.

No campo nome do pacote digite br.com.netfeijao.entities e por fim clique no botão "Criar unidade de persistência". Mantenha os valores default clique em Criar e depois clique em Finalizar. Esta ação irá criar a classe persistente Employee no pacote informado.

Agora vamos utilizar um recurso no NetBeans para a criação de um CRUD com páginas JSF baseado em entidades JPA, no caso a classe Employee que acabamos de criar. Acesse o menu Arquivo | Novo Arquivo, na pasta categoria Persistence selecione "Páginas JSF de classes de entidade" e clique em próximo. Adicione a única classe persistente (Employee) existente (ver figura 1), clique em Próximo e a seguir clique em Finalizar.
Execute a aplicação pressionando o botão F6 e faça testes, perceba que o NetBeans criou uma aplicação completa "a lá Ruby on Rails" com apenas alguns cliques.

public class EmployeeController {
private Employee employee = null;
private List employees = null;
@Resource
private UserTransaction utx = null;
@PersistenceUnit(unitName = "DEMO_EJB31PU")
private EntityManagerFactory emf = null;

public EntityManager getEntityManager() {
return emf.createEntityManager();
}
public int batchSize = 5;
private int firstItem = 0;
private int itemCount = -1;

public SelectItem[] getEmployeesAvailableSelectMany() {
return getEmployeesAvailable(false);
}

public SelectItem[] getEmployeesAvailableSelectOne() {
return getEmployeesAvailable(true);
}

private SelectItem[] getEmployeesAvailable(boolean one) {
List allEmployees = getEmployees(true);
int size = one ? allEmployees.size() + 1 : allEmployees.size();
SelectItem[] items = new SelectItem[size];
int i = 0;
if (one) {
items[0] = new SelectItem("", "---");
i++;
}
for (Employee x : allEmployees) {
items[i++] = new SelectItem(x, x.toString());
}
return items;
}

public Employee getEmployee() {
if (employee == null) {
employee = getEmployeeFromRequest();
}
if (employee == null) {
employee = new Employee();
}
return employee;
}

public String listSetup() {
reset(true);
return "employee_list";
}

public String createSetup() {
reset(false);
employee = new Employee();
return "employee_create";
}

public String create() {
EntityManager em = getEntityManager();
try {
utx.begin();
em.persist(employee);
utx.commit();
addSuccessMessage("Employee was successfully created.");
} catch (Exception ex) {
try {
if (findEmployee(employee.getId()) != null) {
addErrorMessage("Employee " + employee + " already exists.");
} else {
ensureAddErrorMessage(ex, "A persistence error occurred.");
}
utx.rollback();
} catch (Exception e) {
ensureAddErrorMessage(e, "An error occurred attempting to roll back the transaction.");
}
return null;
} finally {
em.close();
}
return listSetup();
}

public String detailSetup() {
return scalarSetup("employee_detail");
}

public String editSetup() {
return scalarSetup("employee_edit");
}
..
}

Listagem 1 - Parte da Classe EmployeeController gerado pelo NetBeans

Perceba que o NetBeans gerou o código de persistencia em uma classe controller, vamos melhorar um pouco isto, tirando o código de acesso aos dados e isolando isto em uma classe DAO, depois vamos transformar esta classe em um EJB sem interface,

OBS> Cuidado, o uso de um EJB DAO deve ser restrito, pois dependendo do seu uso, isso pode ser um Anti-Pattern

Vamos criar uma nova classe Java acessando o menu Arquivo | Novo Arquivo. Nomeie a classe como EmployeeDAO no pacote br.com.mundojava.dao. Nesta classe vamos colocar todos os métodos de acesso ao banco utilizados na classe EmployeeController e inclui-los na classe recém criada. Veja parte do código na Listagem 18.

Vamos criar uma nova classe Java acessando o menu Arquivo | Novo Arquivo. Nomeie a classe como EmployeeDAO no pacote br.com.mundojava.dao.
Adicionalmente vamos criar uma classe para tratamento de Exceptions, crie uma classe e nomeie de DatabaseException, na classe DAO vamos encapsular os erros de acesso a banco nesta classe.

Criada a classe DAO, vamos colocar todos os métodos de acesso ao banco utilizados na classe EmployeeController. Feito isto, transforme esta classe EmployeeDAO em um EJB colocando a anotação Stateless em cima da declaração da classe. Veja parte da classe criada na Listagem 2.

@Stateless
public class EmployeeDAO {

public static final int PROCESSADO = 1;
public static final int JA_EXISTE = 2;
public static final int ERRO = 3;

@PersistenceUnit(unitName = "DEMO_EJB31PU")
private EntityManagerFactory emf;

private EntityManager getEntityManager() {
  return emf.createEntityManager();
}

  public Employee getEmployeeFromRequestParam(Object employee) {
    EntityManager em = getEntityManager();
     try{
       Employee o = em.merge((Employee) employee);
       return o;
     } finally {
       em.close();
     }
  } 

  public int create(Employee employee) throws DatabaseException{
    EntityManager em = getEntityManager();
    try {
      em.getTransaction().begin();
      em.persist(employee);
      em.getTransaction().commit();
      return EmployeeDAO.PROCESSADO;
    } catch (Exception ex) {
      try{
       int opt = 0;
       if (getEmployee(employee.getId()) != null) {
         opt = EmployeeDAO.JA_EXISTE;
       } else {
         opt = EmployeeDAO.ERRO;
         throw new DatabaseException("A persistence error occurred.");
       }
       em.getTransaction().rollback();
       return opt;
      }catch(Exception sup){
        throw new DatabaseException("An error occurred attempting to roll back the transaction.");
      } finally {
        em.close();
      }
    }
  }

public void edit(Employee employee) throws DatabaseException {
EntityManager em = getEntityManager();
try {
em.getTransaction().begin();
em.merge(employee);
em.getTransaction().commit();
} catch (Exception ex) {
try {
em.getTransaction().rollback();
throw new DatabaseException(ex.getLocalizedMessage());
} catch (Exception e) {
throw new DatabaseException("An error occurred attempting to roll back the transaction.");
}
} finally {
em.close();
}
}
...
}

Listagem 2 - Parte da classe EmployeeDAO recém criada.

Fica um desafio para o leitor do blog, criar os métodos

public void destroy(Employee employee);
public List getEmployees(boolean all, 
                         int batchSize, 
                         int firstItem); 
public List getEmployees(boolean all,  
                         int batchSize,  
                         int firstItem); 
public Employee getEmployee(Integer id); 
public int getItemCount();

Por fim, na classe EmployeeController vamos fazer algumas alterações para consumir o EJB sem interface. Primeiro declare uma variável do tipo EmployeeDAO, e vamos injetar com a referência do EJB, e troque todas as referências ao código de acesso ao banco para apontar para o nosso EJB DAO, veja como ficou na classe EmployeeController na Listagem 3.

public class EmployeeController {
private Employee employee = null;
private List employees = null;
public int batchSize = 5;
private int firstItem = 0;
private int itemCount = -1;
@EJB
EmployeeDAO dao;

public SelectItem[] getEmployeesAvailableSelectMany() {
return getEmployeesAvailable(false);
}

public SelectItem[] getEmployeesAvailableSelectOne() {
return getEmployeesAvailable(true);
}

private SelectItem[] getEmployeesAvailable(boolean one) {
List allEmployees = getEmployees(true);
int size = one ? allEmployees.size() + 1 : allEmployees.size();
SelectItem[] items = new SelectItem[size];
int i = 0;
if (one) {
items[0] = new SelectItem("", "---");
i++;
}
for (Employee x : allEmployees) {
items[i++] = new SelectItem(x, x.toString());
}
return items;
}

public Employee getEmployee() {
if (employee == null) {
employee = getEmployeeFromRequest();
}
if (employee == null) {
employee = new Employee();
}
return employee;
}

public String listSetup() {
reset(true);
return "employee_list";
}

public String createSetup() {
reset(false);
employee = new Employee();
return "employee_create";
}

public String create() {
int resultado = dao.PROCESSADO;
try {
resultado = dao.create(employee);
if (resultado == dao.PROCESSADO) {
addSuccessMessage("Employee was successfully created.");
} else if (resultado == dao.JA_EXISTE) {
addErrorMessage("Employee " + employee + " already exists.");
}
} catch (Exception ex) {
ensureAddErrorMessage(ex, ex.getLocalizedMessage());
}
return listSetup();
}

public String detailSetup() {
return scalarSetup("employee_detail");
}

public String editSetup() {
return scalarSetup("employee_edit");
}

private String scalarSetup(String destination) {
reset(false);
employee = getEmployeeFromRequest();
if (employee == null) {
String requestEmployeeString = getRequestParameter("jsfcrud.currentEmployee");
addErrorMessage("The employee with id " + requestEmployeeString + " no longer exists.");
String relatedControllerOutcome = relatedControllerOutcome();
if (relatedControllerOutcome != null) {
return relatedControllerOutcome;
}
return listSetup();
}
return destination;
}

public String edit() {
EmployeeConverter converter = new EmployeeConverter();
String employeeString = converter.getAsString(FacesContext.getCurrentInstance(), null, employee);
String currentEmployeeString = getRequestParameter("jsfcrud.currentEmployee");
if (employeeString == null || employeeString.length() == 0 || !employeeString.equals(currentEmployeeString)) {
String outcome = editSetup();
if ("employee_edit".equals(outcome)) {
addErrorMessage("Could not edit employee. Try again.");
}
return outcome;
}
try {
dao.edit(employee);
addSuccessMessage("Employee was successfully updated.");
} catch (DatabaseException ex) {
String msg = ex.getLocalizedMessage();
if (msg != null && msg.length() > 0) {
addErrorMessage(msg);
}else if (getEmployeeFromRequest() == null) {
addErrorMessage("The employee with id " + currentEmployeeString + " no longer exists.");
return listSetup();
} else {
addErrorMessage("A persistence error occurred.");
}
return null;
}
return detailSetup();
}

public String destroy() {
employee = getEmployeeFromRequest();
if (employee == null) {
String currentEmployeeString = getRequestParameter("jsfcrud.currentEmployee");
addErrorMessage("The employee with id " + currentEmployeeString + " no longer exists.");
String relatedControllerOutcome = relatedControllerOutcome();
if (relatedControllerOutcome != null) {
return relatedControllerOutcome;
}
return listSetup();
}
try {
dao.destroy(employee);
addSuccessMessage("Employee was successfully deleted.");
} catch (DatabaseException ex) {
ensureAddErrorMessage(ex, ex.getLocalizedMessage());
return null;
}

String relatedControllerOutcome = relatedControllerOutcome();
if (relatedControllerOutcome != null) {
return relatedControllerOutcome;
}
return listSetup();
}
...
}

Listagem 3 - Classe EmployeeController refatorada para utilizar o EJB DAO sem interface

Perceba que na expressão "@EJB EmployeeDAO dao" estamos referenciando ao EJB, sem interface para atrapalhar, claro que não é possível criar uma instância utilizando a palavra reservada new ainda, na verdade estamos trabalhando com um proxy, mas se quisermos podemos fazer um lookup utilizando JNDI também.
Vou deixar o restante dos métodos para o leitor resolver, é apenas trocar a referencia pela classe dao conforme os métodos acima.


Compile e faça o deploy, rode a aplicação, se tudo deu certo você irá ver a sua aplicação rodando (ver figura 2) com um EJB sem interface, e o melhor, o EJB está dentro de um arquivo .war, já estamos implementando o empacotamento simplificado.






Veja como ficou o empacotamento do nosso projeto na Figura 3.



Para maiores informações sobre o futuro do Java Corporativo, leia a edição 31 da Mundo Java, que ainda traz ótimos artigos como:

• EJB 3.1:Conheça as Novidades do Futuro do Java Corporativo.
• Autor:Wagner Roberto dos Santos
  
• Grizzly e Comet - Ajax Reverso com Escalabilidade.
• Autor: Pedro Cavalero
• Usando o Mavem para melhorar a Qualidade dos seus Projetos.
• Autor:Márcio Varchavsky
• Criando Software mais próximo do Cliente com Domain-Drivgen Design.
• Autor:Sérgio Lopes
• Setembro: Mês de Java.
• Autor:Mauricio Leal
• Testes de unidades Avançadas com JMock 2
• Autor:Eduardo Guerra
• Gerenciamento de Conteúdo Web com OpemCMS -Customização de Sites.
• Autor:Rodrigo Cunha de Paiva
• Tirando o Máximo dos Interceptors no Struts2.
• Autor: José Yoshiriro Ajisaka Ramos
• Tendências em Foco:Ganhando com Open Source
• Autor:Cezar Taurion
• Jogo Rápido
• Autor:Charbel Symanski e Rodrigo Barbosa Cesar
• Mundo OO: Requisitos Executáveis com FIT
• Autor:Rodrigo Yoshima
• SOA na Pratica:Iniciando Projetos SOA.
• Autor:Ricardo Ferreira

Diversão Garantida !!!

[Just Java 2008] - Considerações

.
O Just Java, o maior evento independente da comunidade Java no Brasil, rolou nos dias 10, 11 e 12 de Setembro, e mais uma vez tivemos ótimas palestras, eu particularmente participei apenas nos dias 10 e 11, que foram os dias que tive as minhas palestras.

No dia 10 apresentei junto com meu grande amigo e professor Renato Bellia a palestra "Java EE 6/ EJB 3.1 e o Futuro do Java Corporativo", confesso que fiquei bem nervoso durante a apresentação por conta do grande número de pessoas presentes, o auditório estava extremamente lotado, com pessoas de pé e sentadas no chão..

No dia 11 foi dia de apresentar o framework Diamond Powder - Produtividade Open Source para Java ME , desenvolvido pelo Bellia, minha parte na apresentação foi mostrar o plugin que desenvolvi para o NetBeans, onde auxilia a criação do Schema, nesta apresentação fiquei muito mais tranquilo, o público era bem menor (ver foto),, mas o que me deixou muito mais calmo foi o fato de estar atrás de um teclado, mostrando código, as funcionalidades ali, na hora =) ,,,





No mais, foi muito bom conhecer caras como Kohsuke Kawaguchi e Roger Brinkley da Sun, e conheci pessoalmente o Eduardo Guerra da Mundo Java, inclusive tivemos uma ótima conversa com o Kawaguchi sobre o metadados, GlassFish V3, OSGi, entre outras coisas.

E claro, foi ótimo rever os amigos, Mauricio Leal, Bruno Souza, Michel Graciano, Alessandro Lazarotti, Cristian Sanchez, Jefferson Prestes, Carlos Fernando Gonçalves e toda a galera da Globalcode.


O evento como um todo foi muito bom, e mostra a força que tem, parabéns para o Mauricio Leal e o SOUJava que trabalharam muito para trazer a todos um evento com ótimas palestras e uma organização impecável... só mais um comentário, é impressionante ver como a galera ama Java =) heheh,, o evento começou as nove horas da manhã e acabava apenas as oito da noite, só que depois deste horário ainda tinham as muvucas, que acabavam em torno das 21:00 - 21:30, o engraçado foi ver que tinha pessoas tristes por ter acabado a muvuca 21:30, incluvise tem quem sugerisse um happy hour após as muvucas para continuar as discussões.. =) ,,


Brincadeiras a parte, parabéns a todos que fizeram o evento a acontecer, é por essas e outras que a linguagem é a mais utilizada no mundo..

Diversão garantida !!!!

Just Java 2008

Esta chegando o Just Java 2008, em Setembro no mês do Java a festa do Just Java será em São Paulo nos dias 10, 11 e 12 de Setembro. Será a 7a edição do principal evento da Comunidade Java Brasileira.
Serão 3 dias com várias palestras relacionadas a Java e agora com alguns temas sobre Agile, hora de aprender um pouco mais, rever os amigos e reforçar o Networking.

Eu vou representar no Just Java com duas palestras junto com meu grande amigo Renato Bellia, no dia 10 ás 15:00 hs com a palestra Java EE 6 / EJB 3.1 e o Futuro do Java Corporativo no auditório superior 2, e no dia 11 de Setembro será a vez de falar do framework Diamond Powder - Produtividade OpenSource para JavaME, que é um projeto criado pelo Bellia.

Neste projeto do Diamond Powder, tive a felicidade de participar com o desenvolvimento de um plugin para o NetBeans para facilitar a criação do Schema, que é um Hashtable que descreve o os campos do coletor, as páginas, fluxo de navegação com opção de persistência.
Você que desenvolve aplicativos embarcados vale a pena conhecer este framework!!

Site do Evento: http://www.sucesusp.org.br/justjava2008/
Grade de Palestras: http://soujava.org.br/display/v/Grade+de+Palestras
Diamond Powder no java.net: https://diamond-powder.dev.java.net/
Blog do Diamond Powder: https://diamond-powder.dev.java.net/

Participe, é diversão garantida !

Entendendo REST (REpresentational State Transfer)

Você já precisou explicitamente utilizar algum método (PUT, DELETE, POST, GET) do protocolo HTTP, muito dificil, geralmente quando o fazemos, nós fazemos isto ao desenvolver uma aplicação web para especificar o tipo de submit, enfim, agora encontraram uma solução muito útil para utilizar os tais métodos, que é através de REST (REpresentational State Transfer), que é o nome dado por Roy Fielding em sua tese de doutorado, muita gente confunde REST com Web Services SOAP, mas ambos são totalmente diferentes.

REST são serviços stateless e arquiteturas baseadas nela são construídas a partir de "pedaços de informação" únicas identificadas por URIs. Em sistemas REST, os recursos são manipulados através da troca de representações do recurso.

Ex.:
http://netfeijao.blogspot.com/colecao/marvel/spiderman/3

Neste exemplo, atráves desta URI estamos definindo como a URI mapeia nossos recursos, no exemplo fica muito fácil entender como funciona, identificamos nossa chave primária (3) no último elemento, e o nome da coleção (spiderman), podemos ainda definir um serviço que me retorne uma coleção de objetos do spiderman caso seja omitido a chave primária,

Por as URIs serem únicas ganhamos uma busca otimizada e posso ter multiplas representações oferecendo esta informação em vários tipos de formatos como XML, JSON e XHTML.

Temos um DE-PARA dos métodos HTTP com as funções CRUD que queremos desempenhar em um sistema baseado em REST, conforme tabela abaixo:

Características dos métodos HTTP em REST

Método GET.

Utilizado para retornar informação de acordo com a URI informada.
Não deve uma mudança de estado
Fica no cache.

Método POST

Utilizado para adicionar uma nova inforamação

Métodp PUT
• Utilize PUT para alterar uma informação
• Controle total na entidade utilizada quando o ID ou chave primária é conhecido

Ex.: PUT /colecao/marvel/spiderman/3-456789012


Método DELETE
Remove (logicamente) uma entidade
Ex.: DELETE /colecao/marvel/spiderman/3 (Exclui Spiderman nº 3)


Benefícios do REST.

Serviços baseados em REST são muito fáceis de entender e de se trabalhar, pois o cliente que vai utilizar o serviço REST não precisa utilizar nenhuma API especializada, ele utiliza apenas HTTP padrão =), podemos usar nosso browser para testes e experimentos.
URI é uma maneira uniforme de identificar recursos e o HTTP é o meio utilizado para manipular estes recursos.
Fácil consumir e desenvolver com linguagens de scripting..


Web Services SOAP vs Serviços REST

SOAP WS.

• Poucas URIs, muitos métodos customizados
• comicsPort.getComics("spiderman")
• Utiliza HTTP para trafegar mensagens SOAP.
• Muitos padrões (WS-*)
• Deve seguir um contrato WSDL.

Web Services baseados em SOAP diz respeito a SOA.

ex: Serviço de venda de quadrinhos
comicService.vender("spiderman", 3, 250);

RESTful WS.

• Muitos recursos (URIs), poucos métodos fixos.
• HTTP é o protocolo de transporte.

Web Services baseados em REST diz respeito a um novo conceito chamado de ROA
(Resource-Oriented Architecture)

ex: Recurso de venda de quadrinhos

POST /colecao/marvel/spiderman/3-250

Para a construção de serviços baseados em REST em Java, foi disponibilizada o JAX-RS, que é uma API para Web Services RESTful, em breve vou blogar com exemplos no GlassFish

[Getting Real] Caindo na Real no Desenvolvimento de Software

Este ultimo mês, finalmente li o livro da 37signals.com, chamado Getting Real, dos mesmos criadores do framework Ruby on Rails, onde eles criticam de maneira agressiva o desenvolvimento de software tradicional, e expõe os seus pontos de vista, e não dão a mínima importância de ir contra a maioria dos conceitos que aplicamos diariamente em nossos projetos.

É uma leitura no mínimo interessante, e com certeza recomendada, tem vários conceitos que ficam inviáveis de se aplicar na maioria das empresas, mas com certeza ajuda a abrir os olhos para muitas coisas, se você não quiser ler o livro, recomendo pelo menos a leitura do resumo que fiz abaixo, boa leitura !!!!

******************************************************

Caindo na Real.

Quer construir uma aplicação web de sucesso? Então é hora de Cair na Real. Caindo na Real é o menor, mais rápido e melhor caminho para construir software. Veja como:

Construir menos

Desenvolver apenas o arroz com feijão.

• Menos funcionalidades
• Menos opções/preferências
• Menos pessoas e estrutura empresarial
• Menos reuniões e abstrações

Construir software para você mesmo.

Com paixão, realmente goste do que faz, acredite no seu software, seguindo a filosofia da comunidade open source.

Viva o software que você produz, fale dele, realmente se importe com isso.

Financie você mesmo

Não conte com o dinheiro de fora. Isso pode trazer dor de cabeça, pois um projeto financiado traz consigo prazos, cobranças, expectativa, metas, inchação de saco, e por fim acaba sendo produzido um produto medíocre.

Em projeto sem dinheiro de fora você tem tempo para desenvolver e com isso mais qualidade,

O que você pode fazer em 3 meses ao invés de 6 ?

Prazo fixo, orçamento, flexibilidade no escopo.

Faça o arroz e o feijão, aquilo que será o core do sistema, o que puder ser feito dentro do prazo e do orçamento, ótimo, fora disso a qualidade do produto irá sofrer, sempre diminua o escopo, sempre haverá novas features para serem incluídas no futuro.

Tenha um inimigo

Arrume um inimigo, veja um produto no mercado que seja um concorrente e faça algo inovador no seu produto, sem querer imitir, tome um caminho oposto, e faça uma proposta diferente para abordar o seu produto.

Tendo em mente o seguinte pensamento “Não siga o líder”, conte uma história diferente para os seus clientes. Não tente convencer o seu cliente de que ele fez uma escolha errada, ao invés disso mostre as qualidades do seu software.

Menos massa

Quanto mais robusto você for, mais fácil será se adaptar as mudanças.

Menos massa diminuir o custo de mudança.

Mais massa é:

Contratos de longos termos, excesso de burocracia, decisões permanentes, reuniões sobre outras reuniões, processo moroso, inventário (físico e mental), ficar preso a fornecedores, formatos de dados proprietários, o passado mandando no futuro, roadmaps, políticas de escritórios.

Menos massa é:

Pensamento just-in-time, time com membros multi-tarefa, abraçar as regras ao invés de tentar burlá-las, menos software, menos código, times pequenos, simplicidade, formatos de dados abertos, produtos open source, uma cultura aberta que é fácil de admitir erros.

Abrace as Regras

Permita que as restrições guiem você para soluções criativas. Não reclame sobre a falta de recursos (tempo/dinheiro/equipe). Trabalhe com o que tem e veja o lado bom disto. Em um bom time, limitação traz boas idéias (inovação) e força o foco.

Tenha times pequenos

Times pequenos melhoram o entendimento do grupo, potencializa o fluxo de informação e evita guerra de egos. O ideal em um projeto é ter times de até 3 pessoas.

Seja você mesmo e sinta a dor

Seja diferente dos grandes players, trabalhando o lado pessoal sendo amigável com os clientes, dê um atendimento pessoal sempre que possível, atenda seu cliente, conheça seu cliente, por default, empresas pequenas são mais próximas do cliente, utilize isto como uma vantagem, e conheça seu cliente, que desta maneira você irá ver seu produto por um outro foco.

Sinta a dor que o seu cliente passa, quando ele reclama de alguma coisa, NÃO FAÇA OUTSOURCING DO SAC PARA UM CALL CENTER OU UM OUTRO TERCEIRO, FAÇA ISTO VOCÊ MESMO.

Passe confiança para o cliente, a nível de passar o seu número celular se possível, traga o cliente para perto de você, pois isto inspira confiança.

Mantenha o Foco.

O seu aplicativo deve ter uma identidade, um objetivo, e nunca deve perder o seu propósito, tenha sempre em mente o que ele deve fazer e nunca fuja do foco.

Eleja o cliente/mercado correto e foque somente neste nicho, se você tentar agradar a todos, nunca irá dar certo.

Ignore os detalhes no primeiro momento

Faça o seu produto o mais simples possível, pense no “floreamento” em um segundo momento, ou até mesmo deixe para lá, deixe que o usuário trabalhe como o que tem.

É um problema somente quando é um problema

Não perca seu tempo tentando arrumar bugs que não existem, não faça algo pensando em resolver um problema que não existem.

Por exemplo, porque montar uma aplicação altamente escalável em um primeiro momento, se você não sabe ainda se vai precisar, ou não sabe a quantidade de acessos sua aplicação irá ter... crie sua aplicação e depois se preocupe para resolver isto, quando sua aplicação for um sucesso. Pois se formos pensar, sempre teremos que rever a nossa aplicação, em termos de tunning, dimensionamento, etc...

Meio Produto, não Meia Boca.

Atenha-se ao que é verdadeiramente essencial. Boas idéias podem ser tiradas da gaveta. Pegue tudo que você acha que seu produto deve ser e corte pela metade. Remova funcionalidades até que você obtenha apenas o essencial. E então, repita o processo.

FAÇA ALGO QUE VOCÊ POSSA GERENCIAR.

FAÇA UM SOFTWARE PARA UM PÚBLICO GERAL E FAÇA COM QUE O USUÁRIO ACHE SUAS PRÓPRIAS SOLUÇÕES.

O Não é a resposta,

Uma vez com o produto lançado, prepare-se para uma enxurrada de requisições de usuários, do tipo, porque não colocar isso? Porque não coloca aquilo? etc...

A primeira resposta é sempre NÃO. Nós não precisamos de um milhão de funcionalidades, eu mesmo não utilizo metade das funcionalidades do NetBeans, só altere seu produto, quando começar a pipocar várias vezes a mesma requisição.

Outra coisa, você não precisa de uma lista de backlog, o fórum /lista de discussão é o melhor local, pois aquilo que realmente precisa ser feito, irá sempre aparecer.

O que você não quer?

Busque feedback dos usuários, e pergunte por funcionalidades que eles não utilizam ou coisas que eles não querem, então, tire do seu software, mantenha seu software o mais simples possível.

Coloque seu código para rodar,

Não espere muito tempo para colocar seu software no ar, coloque no ar, e vá incluindo novas funcionalidades aos poucos.

Celebre as pequenas vitórias, uma coisa importante é a motivação, diminua suas iterações, no meio de uma semana atribulada busque algo que foi feito durante a semana, uma funcionalidade, uma melhoria, retirar uma funcionalidade não utilizada e comemore... pois isto irá trazer desejo de mais pequenas vitórias.

ABOMINE REUNIÕES.

Você já parou para pensar, em quanto tempo você já perdeu da sua vida em reuniões inúteis ? Muitas né .. pois é, eu também :(,, no livro o cara detona as reuniões. Nunca faça reuniões, somente em último caso, se não tiver como evitar, faça uma reunião de no máximo 30 minutos, convide o menor número de pessoas possíveis, e procure não perder o foco. Sempre tem aquele que acaba desvirtuando para um assunto totalmente fora do foco.

Não contrate,

Mantenha um número pequeno de pessoas, somente contrate em último caso, se sair alguém, espere por um tempo, e veja se aquela pessoa esta fazendo falta, se estiver fazendo muita falta, contrate, senão, não.

Ações, Não Palavras.

Se for contratar, procure caras que fazem open-source, pois de quebra, você pode analisar a qualidade do código, cultura, nível de paixão, se a pessoa é social. Open source rules !!! Contrate caras que sabem escrever bem, tenham boa comunicação, e que sejam entusiasmadas.

Primeiro a interface,

Faça primeiro a interface, depois codifique, fica muito mais fácil quando você vê o produto.

Depois de iniciar o desenvolvimento, desenvolva de dentro para fora, começando pelo núcleo do seu código.

Trabalhe pensando nos 3 estados, no estado regular, que é quando o usuário vê a tela funcionando normalmente, estado da tela em branco, quando o usuário vê a tela ao utilizar a tela primeira vez, este estado é importante pois marca a primeira impressão. E o estado de erro, que é quando acontece algo de errado na aplicação.

Felicidade Otimizada

Utilize ferramentas que deixe seu time feliz e excitado, pois um desenvolvedor feliz é um desenvolvedor produtivo.

Se desenvolvedores fossem pagos para remover código de seus programas,.

Ao invés de escrever novo código, seu software seria muito melhor, pense nisso.

Abra as portas

Disponibilize para o mundo seu software através de RSS, APIs, Widgets etc..

Isso faz toda a diferença, se possível torne seu software extensível.

Amostra Grátis

Quando lançar seu produto, disponibilizar amostras grátis, deixe o seu cliente em potencial testar seu produto, mas deixe sempre funcionalidades na manga para o produto licenciado, deixe a funcionalidade a mostra, quando o usuário clicar na opções, avise-o esta funcionalidade é para clientes que tem uma assinatura, bla bla bla..

Não tem nada de funcional e uma especificação funcional,

Não escreva especificações funcionais, pois elas não refletem a realidade, isso é feito para fazer as pessoas felizes, ela leva para acordo ilusório, pois cada um pode interpretar de uma maneira um texto.

Especificações funcionais levam você a tomar decisões importantes quando você tem menos informação. Essas especificações não fazem você evoluir, mudar, ou revisar pois você fica preso naquele escopo.

E bata de frente com os bloqueadores, pois vai aparecer várias pessoas querendo todo tipo de documentação, o que com certeza vai atrasar todo o processo. O melhor a fazer é ter os conceitos bem formados na cabeça, iniciar um protótipo estático, isto dará uma idéia muito madura do que deve ser feito.

Mais uma vez, NÃO FAÇA DOCUMENTAÇÃO QUE NINGUÉM IRÁ LER.

Escreva estórias, não detalhes.

Lembra do user stories, então, é isso aí.

Fácil para entrar, fácil para sair,

No site, torne fácil o processo de adesão do produto e o de cancelamento, pois é mais difícil um cliente que não teve problemas ao cancelar a assinatura de voltar a assinar do que o cliente que ficou nervoso ao tentar cancelar e não conseguiu.

Evite contratos de longo termo, taxas de assinatura, etc... não tente enganar seu cliente para ganhar mais dinheiro, seja HONESTO sempre.

Luva de Pelica

Precisa dar uma má notícia como aumento de preço, faça de uma maneira que não vá agredir, ou seja, vá avisando aos poucos, enviando emails comentando de melhorias, de novas aquisições (de hardware), etc... e por isso nós próximos meses teremos um pequeno reajuste, bla bla bla.. isso dói muito menos, do que chegar na hora H e pegar o cliente desavisado, é pedir para apanhar.

Lançamento estilo Hollywood

Vá do teaser para o trailer para o lançamento.

O esquema é marketing, para o seu produto faça um lançamento no estilo Hollywood.

Teaser

Alguns meses antes, já inicie o projeto, divulgando o produto em sites relacionados, crie um logo, crie um site promocional, com algumas novidades semana a semana, para ir alimentando a curiosidade de seus futuros clientes. Crie uma lista para as pessoas receberem avisos do que está rolando, novidades.

Trailer

Nesta fase, lance um produto beta com preview de algumas funcionalidades, deixe um grupo de pessoas testarem, e colha opiniões, bugs, etc...

Lançamento

Divulgue, faça com que todos voltem a atenção para o seu software, reformule o hot site, coloque blog, tour, um overview, relate cases, Valores, formulários para inscrição, testemunhos,

Blog é o melhor marketing que existe, você não gasta nada (apenas tempo) e as vezes o efeito é melhor do que uma propaganda na mídia.

Promova seu software através da educação, ensine as pessoas a utilizarem seu software, com tutoriais, vídeo aulas, seminários, etc..

E deixe o software o mais fácil possível, utilize FAQs, e help na aplicação, tente deixar um nível próximo de zero a necessidade de um treinamento.

De um nome

Dê um nome fácil das pessoas guardarem, não precisar ser nada muito óbvio com que a sua aplicação faz.

Resposta Rápida

Responda o mais rápido possível ás dúvidas do seu cliente, o suporte rápido e eficiente deve ser a prioridade no seu negócio, e seja sempre sincero, quando acontecer algum muito errado, por exemplo, deu crash no servidor, seja sincero, e explique o que aconteceu, com certeza ele irá entender.

Mantenha o seu blog atualizado

Um blog parado, passa a impressão que o produto está descontinuado, tirando assim a confiabilidade, atualize sempre, dê uma dica, ensine uma feature, mas mantenha seu blog sempre atualizado

Saiba o que os seus concorrentes estão fazendo.

Se inscreva nos feeds dos seus concorrentes, mas não se aprofunde demais, para o seu produto não perder a personalidade

Siga a maré

Seja sempre aberto para novas possibilidades, e mudanças de direção. Seja um surfista, e não o oceano, tente adivinhar aonde a maré rebenta e se ajuste de acordo ;-).

Aplicando Caindo na Real

Execução.

Todo mundo pode ler um livro, criar um blog, ter uma idéia, todo mundo tem um primo que é web designer.

A diferença entre você e o resto é de como isso será executado. Sucesso se resume a uma grande execução.

Pessoas

Não adianta você aplicar estes conceitos, se você não tem um bom time, com pessoas que realmente gostam do que faz, que se importam com a qualidade do software, pessoas que não guardam informação. Tenha o time certo! Procure os apaixonados.

Engenharia de Software: 40 Anos de sofrimento e aprendizado

Um pouco de história:
Modelo Cascata ou Waterfall:
Nas empresas que passei, pelo menos a maioria, posso dizer que trabalharam (ou trabalham) com o método cascata para o desenvolvimento de software, que tem seus prós e contras, o problema é que este modelo foi concebido nos anos 70 por W. W. Royce, e consiste na evolução de cada fase do projeto de forma sequencial (Figura 1), vemos na imagem que o primeiro quadrado inicia-se pelo "Requerimento", ou seja, é aquela fase do projeto que demora até meses para ser feita, onde o analista tem que coletar todas as informações pertinentes do projeto e definir os seus requisitos.

Pois bem, uma vez definido os requisitos e fechado o contrato ou a SLA, é montado o cronograma e iniciando a segunda fase deste modelo, a fase do "Projeto", e aí é que geralmente os problemas começam, pois muitas vezes, o cliente ao especificar um projeto não tem nem certeza do que quer, apenas uma idéia, ficando para o analista decifrar tudo o que cliente quer, e quando os requisitos chegam para os desenvolvedores, muitas vezes estes não tem nem contato com o usuário, e tem que se virar com o entendimento baseado nos documentos de especificação, o máximo é uma conversa rápida com o analista, e quando possível.
Outro problema é que estes projetos, são estimados em torno de 3 - 6 meses, e conforme o tempo vai passando, acontece coisas com o cliente e ele começa a esquecer o que foi acordado, sobrando para o pobre desenvolvedor que acaba tendo que refatorar o código para atender a necessidade do usuário, e no modelo cascata não podemos voltar uma fase, conclusão, projetos mal sucedidos, ou atrasados, ou o produto acaba não atendendo o cliente.

Modelo Espiral:

Para tentar acabar com estes problemas conhecidos do Modelo Cascata, em 1988 Barry Boehm escreveu um artigo “A Spiral Model of Software Develpement and Enhancement” , que propõe um desenvolvimento iterativo e incremental que podem chegar de 6 meses a 2 anos,


Vantagens deste modelo:
• O Modelo em espiral permite que ao longo de cada iteração se obtenham versões do sistema cada vez mais completas, recorrendo à prototipagem para reduzir os riscos.
• Este tipo de modelo permite a abordagem do refinamento seguido pelo modelo em cascata, mas que incorpora um enquadramento iterativo que reflete, de uma forma bastante realística, o processo de desenvolvimento.


Desvantagens:
• Pode ser difícil convencer grandes clientes (particularmente em situações de contrato) de que a abordagem evolutiva é controlável.
• A abordagem deste tipo de modelo exige considerável experiência na avaliação dos riscos e baseia-se nessa experiência para o sucesso. Se um grande risco não for descoberto, poderão ocorrer problemas.
• Este tipo de modelo é relativamente novo e não tem sido amplamente usado.
• É importante ter em conta que podem existir diferenças entre o protótipo e o sistema final. O protótipo pode não cumprir os requisitos de desempenho, pode ser incompleto, e pode refletir somente alguns aspectos do sistema a ser desenvolvido.
• O modelo em espiral pode levar ao desenvolvimento em paralelo de múltiplas partes do projeto, cada uma sendo abordada de modo diferenciado, por isso é necessário o uso de técnicas específicas para estimar e sincronizar cronogramas, bem como para determinar os indicadores de custo e progresso mais adequados.

RUP:

Nestes 3 últimos anos especificamente, tenho trabalhado com um híbrido de RUP, e nas minhas experiências não tenho tido o sucesso desejado, vendo a causa pude chegar a conclusão que para uma metodologia desta dar certo não dependendo só dos templates do método e das fases estabelecidas mas da cultura da empresa e das pessoas envolvidas, pelo menos nos locais onde trabalhei com esta metodologia as pessoas trabalham com RUP em uma forma cascata, e RUP pode será ágil, que é o que mostra o artigo RUP Ágil de José Papo em seu blog. Mas mesmo assim, as pessoas tendem a trabalhar com um RUP mais “pesado”, com um excesso de documentação a ser preenchida, onde para cada passo que é dado, é preciso de assinaturas dos envolvidos.
Ou seja, essa situação faz com que as pessoas envolvidas no processo (leia-se cliente, fornecedor, terceiro) acabam entrando em conflito, pois imagine a seguinte situação, eu tenho um determinado cliente que pede uma determinada funcionalidade no sistema DELE, após eu(analista) colher o requisito, eu tenho o trabalho de documentar isso em um documento definindo as fronteiras do sistema, identificando principais envolvidos/interessados e priorizando suas necessidades, e os requisitos funcionais e não funcionais, pois bem, depois de todo este trabalho, antes de fazer qualquer coisa eu tenho que pegar um documento assinado ou email, provando que foi uma solicitação real e será implementada de acordo com a especificação.
É normal que o cliente terá receio de assinar qualquer documento, pois na cabeça dele, ele pensa que se acontecer alguma coisa errada no processo, a culpa irá recair sobre ele por causa deste documento assinado. Isso vai gerando um desconforto muito grande entre os envolvidos, e o atraso é evidente pois para cada passo é preciso da aprovação do cliente, cada fase do projeto é auditada. Então me diga, Cadê a agilidade?
Lembro que estas foram as minhas experiências com RUP.
Será que não tem algo errado nisto ? Por quê muitas empresas utilizam processos de desenvolvimento de 40 anos atrás, sendo que todo ano é publicado o relatório do Caos pela Standish Group International, onde até o ano passado, 1 entre 3 projetos estouram o orçamento,

Foram por causa dessas perguntas que comecei a me interessar por meios alternativos de gerenciamento de projeto, foi quando conheci as metodologias ágeis. E descobri algo que o que realmente faltava nestes processos / modelos / metodologias, e é algo que é o ponto chave em metodologias como SCRUM, é que esta metodologia é centrada em PESSOAS, GENTE, SER HUMANO, agora que as outras não priorizam. Desenvolvimento LEAN. Veja alguns dos principios:

“Indivíduos e interações são mais importantes que processos e ferramentas.”

“Software funcional é mais importantes que excesso de documentação.”

Para uma idéia melhor sobre o que que é manifesto ágil, veja meu outro post Agile Manifesto – Metodologias Ágeis.

E essa descoberta mudou radicalmente o meu processo de pensar, é a solução para todos o problemas? NÃO.

Mas com certeza é um passo muito importante para quebrar o paradigma de desenvolvimento de software tradicional.

Aos poucos vou falar sobre estes processos ágeis, recomendo que você leia as seguintes matéria.


Blog:

Agile Manifesto – Metodologias Ágeis
TDD – Test Driven Development
SCRUM – Uma abordagem prática

Livros:
Agile Software Development with SCRUM
Extreme-Programming-Explained
User Stories Applied
Lean-Software-Development

The Developers Conference 2008

Nos dias 26 e 27 de Julho foi realizado o The Developers Conference 2008, um evento organizado pela Globalcode, com patrocinio da JBoss, UOL e a Locaweb. E posso dizer com certeza que este foi o melhor evento de Java no ano até o momento aqui no Brasil.

Tivemos uma série de palestras altamente técnicas distribuídas em 2 tracks, uma para Java e outra voltada mais para metologias ágeis.

Caption: Sr. Rubens, Renato Bellia, Melissa e Wagner

O evento agradou ambos os mundos tanto os amantes de metologias ágeis, quanto os amantes do Java,



Pude conferir as seguintes palestras:
Dia 25/07

• KeyNote com Burr Suttler sobre a plataforma SOA da JBoss, passando um ótimo overview com algumas dicas práticas utilizando jBPM, Seam e Drools.
• Arquiteturas SOA com ferramentas Open-Source com Edgar Silva, também outra ótima palestra com direito a uma demo com Rest / jBPM e Seam.
• Depois fui ver a palestra do meu "guru" e amigo Renato Bellia, criador do framework Diamond Powder sobre arquiteturas de Persistência.
• Uma introdução a Restful WebServices com uma interessante palestra com Rafael Nunes.
• JSF 2.0 - Com o "pai da criança" Ed Burns, dando uma visão geral do que vem por aí..
• Java Module System e OSGi em uma palestra com Vinicius Senger, que roubou a cena apresentado OSGi com uma animação usando Sketch up da Google.
• Java EE 6: A Community Update com Reza Rahman, membro do expert group da JSR que define o EJB 3.1, dando uma geral nas novidades da plataforma Java EE 6.

Dia 26/07 Esse dia para mim foi muito produtivo também pude aproveitar muito bem as palestras, acompanhei o Key Note do Ed Burns, sobre o seu recente livro Secrets of the Rock Star Programmers nesta palestra Ed mostrou várias entrevistas com programadores famosos, um momento bem descontraído.
Depois assisti uma palestra muito boa do Manuel Pimentel sobre Modelagem Ágil, dando um overview sobre as metodologias ágeis. A seguir, acompanhei a palestra de Paulo Viragine da JBoss sobre o framework Seam, sem dúvida muito bem "mandada", dando várias dicas de produtividade com o JBoss Developer Studio.
Após a palestra sobre o JBoss Seam, assisti a palestra de Andre Piza da UOL, sobre SCRUM e o case de como eles trabalham e implementaram na UOL, para mim foi muito interessante também, pois pude ver de perto o que o pessoal esta fazendo e o que está dando certo na UOL, recentemente tirei a certificação de Scrum Master e estou tendo a oportunidade de aplicar esta metodologia na empresa que estou prestando serviços atualmente.
Depois acompanhei a palestra Dr. Spock e do Ricardo Jun sobre o leque de opções do Spring, para mim foi interessante, pois para ser sincero não tive a oportunidade de desenvolver com esta tecnologia ainda.


E por fim, acompanhei o que para mim foi um dos momentos mais interessantes do evento, que foi o Painel Gestão, metodologias e processos de software mediado muito bem pelo Jorge Diz da Globalcode, com a presença de vários caras feras no desenvolvimento ágil como Vinicius Teles da ImproveIT, Manoel Pimentel (Visão Agil), André Piza (UOL), Juan Bernabó (TeamWare), Enio Stein (Paggo), José Papo (BRQ) e o pobre Marcos Dorça da Borland levantando a bandeira do CMMI, tive o privilégio de ser o primeiro a fazer uma pergunta (que ficou sem resposta) ao grupo quando foi aberto para o público, e perguntei para o Marcos Dorça como o cara faz para aplicar um modelo de maturidade baseado em CMMI utilizando uma metodologia ágil como SCRUM sem ferir os princípios de agile (entendeu porque ficou sem resposta :D). O que acabou levantando uma polêmica e o pobre rapaz acabou sendo sufocado pelos colegas... mas falando sério, foi um painel muito legal onde todos interagiram e puderam dar os seus pontos de vista !



No geral o evento foi muito bom por outros fatores, pude encontrar amigos como Renato Bellia, Mauricio Leal, Leandro Vil, Vinicius e Yara Senger, Kleber, Melissa, Waldir, Ana, Luca, Edgar Silva, Ed Burns, Jorge Diz, Juan Bernabó, Alessandro Lazarotti, Jefferson Prestes, Fabiano Silva entre outros e também pude conhecer caras incríveis como Reza Rahman, Bruno Ghisi e o Ricardo do GUJSC, Manuel Pimentel e Felipe Rodrigues, este último acabei tendo um contato maior agora com a InfoQ Brasil por intermédio do Manuel Pimentel, ou seja, o evento foi um ótimo local para fazer um network, muito importante na nossa área.



















Só achei uma pena uma coisa, pois não pude assistir as outras palestras, como a do Mister M sobre Java SE 7, o comparativo de frameworks, extreme programming e muitas outras.

No mais, parabéns para a Globalcode, e um parabéns especial para o Leandro Vil e para a Yara Senger que organizaram o evento na "unha", espero participar mais vezes desta festa !!!

Sucesso !!!

Fotos do evento