A questão é que não se trada de 10 maus hábitos e sim de uma deficiência do JSF. É querer colocar uma cereja num bolo queimado, entende?
Quais seriam essas deficiências?
Acho que seria saudável a todos se vc comentasse algumas. Seria bom para o fórum, para os desenvolvedores Web e até para a revista mundo Java, que poderia ter conteúdo para uma futura matéria justamente sobre as deficiência do JSF.
Na minha opinião, o que falta no JSF é flexibilidade. Quando vc não tem o que vc quer nas bibliotecas prontas, é bem custoso implementar.
Pelo que eu vi JSF 2.0 isso melhora um pouco, mas não faz milagres.
[quote=fredferrao]
Só nao podemos esquecer o nome da revista: Mundo JAVA
Uma coisa é falar de linguagens que rodam nao VM como scala, groovy, agora sair totalmente do contexto ja não da.
Nao se chama Mundo TI.[/quote]
Uma coisa é falar sobre Java, outra coisa é transformar uma revista em especificação que cerca a tecnologia, existem outras informações tão úteis no mundo Open Source e simplesmente não são trazidas aqui para uma nova descoberta ou horizonte, java é a herança para todas as novas tendencias desse mundo novo e que se extendeu para a WEB 2.0.
Comprei agora pouco minha revista e achei muito boa.
Primeiro pela aparência, pois o código não pode apenas funcionar, tem que ser bonito. E a revista está muito bonita, bem editada, sem erros de ortografia e muito bem organizada. Parabéns.
O primeiro artigo que lí foi do vraptor3. Parabéns ao Lucas e Adriano, o artigo está excelente. O texto foi na medida certa, e vale a pena a leitura de cada linha, mesmo para os que conhecem o framework, como no meu caso. Temos muitos frameworks e utilitários brasileiros, seria mesmo interessante ter seguidamente alguns artigos sobre algum, mesmo que pequeno. Ajuda não apenas incentivar o uso, mas também para apresentar para quem não conhece.
O Artigo sobre eventos JPA, embora eu lí por cima, está muito bom também. Mesmo trabalhando há muitos anos com JPA agregou muita informação.
Gostei também sobre o AdWords, mesmo que eu não use e nem tenha interesse em usar em minhas apps. Será que rola novos artigos sobre as APIs do Google em próximas edições?
Enfim, a revista desse mês, na minha opinião, foi um bom investimento. Valeu Guerra :thumbup:
Onde encontrar a revista?
No site diz as cidades que tem revista, porem passei em algumas bancas e nao encontrei, teria uma lista de bancas?
Legal dar uma olhada neste livro.
Algumas destas coisas (pontos por função, analistas de sistemas e outros cacarecos) TIVERAM um motivo, outras nem isso.
Legal dar uma olhada neste livro.
Algumas destas coisas (pontos por função, analistas de sistemas e outros cacarecos) TIVERAM um motivo, outras nem isso.[/quote]
Certo e isso nao se encaixa em METRICAS??? Veja bem que nao citei qualquer ferramenta ou metodo especifico em si! E repliquei o faelcavalcanti que disse estar cansado de metricas, AGIL ou nao, ainda são metricas, sao maneiras de medir coisas, neste caso devenvolvimento de software.
a respeito deste artigo, visto que ainda não o li, mas sobre métricas, fico imaginando até quando iremos precisar de tantas especificações funcionais/não-funcionais, casos de usos, diagramas UML, ou seja, até quando precisaremos de analistas ?
acho que se cortarem os analistas e/ou transformarem em desenvolvedores, de forma a ter uma equipe uniforme e que todos tivessem quase o mesmo nível de conhecimento, não nos preocuparíamos tanto assim com métricas, seja no setor público ou privado.
(bem foi um pequeno desabafo) :? [/quote]
Entao, supondo empresa privada, o que vai dizer ao seu cliente quando ele perguntar “em quanto tempo fica pronto?”??? E logo em seguida quando ele tambem perguntar “quanto vai custar? baseado em que?”??
[/quote]
Este é um erro comum. A primeira coisa a fazer quando se é perguntado por “em quanto tempo fica pronto” é :“para quando precisa?” Se o cara dá uma data vc tem um projeto de prazo fixo. Se ele não dá uma data, vc pergunta “Quanto quer gastar ?” e tem um projeto de preço fixo. Veja que preço e custo são coisas diferentes. Se o cara responde que não tem prazo nem orçamento então ele está interessando em ter o máximo de funcionalidades. então ai vc pergunta : “quais funcionalidades têm maior prioridade?”
Repare que as métricas não servem para responder aos clientes e sim para que a “gerencia” e o comercial tenha uma ideia de quanto pedir pelo software quando o cara perguntar :“quanto custa”. Veja que é comum o comercial negociar o preço, mas isso é normalmente feito da forma errada porque o custo é chutado pelas métricas e não avalidado concretamente pelas equipas. O comercial vende o software com base no que o cliente pode/está disposto a pagar e não pelas features. O input dos desenvolvedores não existe, e acaba que o projeto estoura prazos e custos. O triangulo de projeto não mente, mas muitas software houses não cansam de tentar driblá-lo.
Métricas são uma forma pobre e preguiçosa e até timida (porque a empresa tem medo de falar com o cliente) de tentar resolver um problema que é estimar. Agil em geral e Scrum em particular tem outra prespetiva. Tanto o cliente como os desenvolvedores devem ser consultados. Riscos devem ser avaliados. O tempo de alocação deve ser considerado, assim como o prazo esperado pelo cliente.
O ideal é que , quando o cliente não estabelece um prazo ou um custo, o projeto seja dividido em releases. Isto força um prazo e isso ajuda no planejamento e permite ao cliente decidir o rumo do software. Em vez de um prototipo, faz uma versão funcional com o mínimo de features e usa reuniões de fim de sprint para direcionar os requisitos. é muito comum que o cliente tenha a capacidade de abstração de uma ameba e que depois de ver a coisa funcionando na frente dele mude de opinião.
Pontos de função ou pontos de caso de uso são falhos. E a razão é simples : se baseiam numa pseudo teoria que nunca foi confirmada. enquanto que planning poker e outras metodologia ageis se baseiam na opinião real de quem vai fazer a coisa existir, se baseiam em consenso e não em autoridade e por conseguinte isso significa que faz nascer uma responsabilidade dos desenvovedore so que os levará a falar numeros honestos.
Não sei se vocês perceberam mas o nome dessa nova coluna é “Provocação Digital”, ou seja, o objetivo é levantar discussões a respeito de temas gerando uma reflexão a respeito deles por parte do leitor. Pelos posts que foram gerados acho que o objetivo está sendo atingido! 
O objetivo é muito ruim sendo que a revista é one-way-only.
Mas o principal problema é que o artigo é baseado em mentiras. Isso me faz pensar se os PF e os PCU realmente se calculam daquela forma. Ou seja, a credebilidade foi pro saco. Além disso se é provocação, o titulo deve ser uma pergunta e o texto deve ser uma suposta resposta. algo do tipo “Você usaria métricas ?” e depois responder. O texto que explica as métricas poderia ser todo um side-box.
O problema é este. todo o texto é o side-box e o core não está lá.
"2. Estimar é opinar a respeito de algo de que não se tem certeza. Por exemplo, estimar a quantidade de pessoas que há numa fila, estimar o preço de uma roupa, estimar o resultado de uma conta, antes de executá-la. "
“Backlog de produto e backlog de sprint
Um backlog é uma lista de itens priorizados a serem desenvolvidos para um software. O backlog de produto é mantido pelo Proprietário do Produto e é uma lista de requisitos que tipicamente vêm do cliente. O backlog de sprint é uma interpretação do backlog do produto e contém tarefas concretas que serão realizadas durante o próximo sprint para implementar alguns dos itens principais no backlog do produto. O backlog de produto e de sprint são, então, duas coisas totalmente diferentes, o primeiro contendo requisitos de alto-nível e o segundo contendo informações sobre como a equipe irá implementar os requisitos do produto.”
Percebe a diferença na linha de tempo (um já começou e outro ainda não) ?
A linguagem java se profissionalizou e evoluiu mais no momento em que os radicais sairam do cenário e empresas e pessoas mais ponderadas começaram a apresentar visões mais realistas e sem os ranços radicalistas, o que fez com que o negócio gradualmente comprasse a idéia. O negócio não compra idéias de pessoas com bombas amarradas à cintura.
Torço para que as pessoas desta lista, que trabalham com Scrum, não sejam tão radicais a ponto de simplesmente ignorar o passado, sem saber porque (todo mundo sabe que não funciona não é resposta).
Mas como disse o Guerra, fico feliz que as pessoas estejam discutindo o tema, que quase sempre é jogado para debaixo do tapete após o início do projeto.
Sobre minha opinião, acho que não conseguiria deixar mais clara minha opinião de que os mecanismos citados (e que são utilizados ainda hoje) não conseguem gerar números verdadeiros, e apenas servem como números mágicos utilizados na negociação de novos projetos. Apresentar a técnica foi uma forma de mostrar matematicametne o porque do não funcionamento.
Glauco Reis
[quote=glaucoreis]"2. Estimar é opinar a respeito de algo de que não se tem certeza. Por exemplo, estimar a quantidade de pessoas que há numa fila, estimar o preço de uma roupa, estimar o resultado de uma conta, antes de executá-la. "
[/quote]
Esse é o primeiro erro. Estimar não é questão de opinião.
Estimar é oferecer um numero e uma margem tal que o numero real está dentro desse intervalo.
Ou seja, nem todos os números servem, e, tem que haver verificação.
Estimativas são baseadas em historicos. Quer seja em historicos documentados ou na simples memoria dos individuos.
É por isso que PF e PCU falham, eles não são baseados em historicos.
Na ausência de históricos de qualquer tipo qualquer numero é puro achismo pois sua margem de erro é maior que metade da escala.
Ou seja, existe estimar e existe chutar. Não são a mesma coisa.
E dai ? mesmo sem ter começado e sendo o sprint backlog diferente do product backlog isso em nada impede que se façam as contas. Primeiro que as estimativas são todas feitas e cima do product backlog, e da velocidade da equipa os sprints log não são necessários. O historico necessário à estimativa está a velocidade da equipa e no fato da equipa ter estimado o backlog. Sendo a duração dos sprints fixa (como é em Scrum) é trivial fazer as contas.
1200 pontos a 80 pontos por sprint equivalem a 15 sprints.
A 15 dias uteis por sprint 1200 pontos equivalem a 225 dias uteis.
A estimativa está feita. Não ha como se comprometer com um valor menor que 225 dias uteis.
A unica variável aqui é a velocidade. O resto é fixado antes dos calculos. Portanto o erro da estimativa depende apenas da variancia da velocidade. Se a velocidade variou entre , digamos, 50 e 90 pontos, o valor estimado para o projeto está entre 360 e 210 dias uteis.
Mais simples que isto não ha.
O unico problema acontece quando não temos histórico. Ou seja, a velocidade da equipa é desconhecida. ai é impossível estimar. Por isso que é necessário exercitar a equipa ou utilizar uma estimativa baseada em dias ideais.
Veja que esta estimativa serve para a software house se cuidar e não para o preço que oferece ao cliente. A empresa deve contar pelo menos com 225 dias uteis indo para 360. Esta margem é o risco.
Além disso Scrum oferece outra ferramenta para estimar : fixar prazos. Dentro do conceito de time-box são desenhados releases “forçados” para que sempre haja um prazo. Se ha um prazo pre-definido a estimativa é futil. As contas são feitas agora para saber quanta funcionalidade (quantos pontos) cabem até ao prazo. Quantos pontos, não quais historias. Isso é mantido flexivel de propósito já que não afeta o prazo ou o custo.
Vo não mostrou matemáticamente porque não funcionam. aliás vc não demonstrou que não funcionam.
“Números verdadeiros” tem graça. Isso faz-me lembrar a citação que o ken schwaber faz do diretor que diz para o gerente :“como eu posso confiar nas suas estimativas se vc nunca acerta” O objetivo não é acertar. O objetivo é não errar por muito. Que se vai errar é um fato conhecido de toda a estimativa.
Se o seu objetivo era provar que PF , PCU e scrum não funcionam para estimar, vc deveria terminar perguntando qual método seria util ou concluindo que estimar é impossivel. Considerar que estimar é impossivel é absurdo já que é todo objetido de uma metodologia de gerencia, portanto ficou devendo um método que funcione.
Segui a historia interativa e me dei mal…
rsrrsrsrs…
Parabéns pelo artigo “Aprendendo Padrões Java EE com uma História Interativa”. Muito bom.
[quote=ncm]Segui a historia interativa e me dei mal…
rsrrsrsrs…[/quote]
Mas aposto que ganhou em aprendizado!!!
Espero que se dê bem nas histórias da vida real! 
[quote=Guerr@][quote=ncm]Segui a historia interativa e me dei mal…
rsrrsrsrs…[/quote]
Mas aposto que ganhou em aprendizado!!!
Espero que se dê bem nas histórias da vida real! [/quote]
Eduardo,
Baseado nas questões referênte ao artigo, que apontamentos das questões aqui já comentadas você daria melhor referência, como já observaram " PF e PCU falham, eles não são baseados em historicos", ou algo como tecnicamente que seja melhor plausivel de dizer “Espero que se dê bem nas histórias da vida real!” , em melhor observação o Encontro Ágil onde o Tutorial: Planning, Estimating and Correction in an Agile Project (Jutta Eckstein) justifica o artigo das Boas Práticas do JAVA EE, já que você foi um dos palestrantes poderia fazer outras observações, no Tutorial da Jutta Eckstein a mesma aborda esses aspectos ?!
Abraçoss
[quote=jcracker]
Eduardo,
Baseado nas questões referênte ao artigo, que apontamentos das questões aqui já comentadas você daria melhor referência, como já observaram " PF e PCU falham, eles não são baseados em historicos", ou algo como tecnicamente que seja melhor plausivel de dizer “Espero que se dê bem nas histórias da vida real!” , em melhor observação o Encontro Ágil onde o Tutorial: Planning, Estimating and Correction in an Agile Project (Jutta Eckstein) justifica o artigo das Boas Práticas do JAVA EE, já que você foi um dos palestrantes poderia fazer outras observações, no Tutorial da Jutta Eckstein a mesma aborda esses aspectos ?!
Abraçoss[/quote]
Me confundi um pouco em relação a algumas coisas que você falou… Mas vamos lá!
Infelizmente não pude ir no Encontro Ágil no dia das palestras internacionais e perdi o tutorial, que certamente deve ter sido excelente, da Jutta Eckstein.
Em metodologias ágeis, a idéia é que o planejamento seja mais flexível e que você tenha liberdade em negociar o escopo no meio do projeto. Infelizmente esse não é o caso em diversas situações. Imagine, por exemplo, que uma empresa esteja entrando em uma concorrência ou licitação e precise dar um preço baseado em uma especificação fornecida (nem sempre de boa qualidade). Como fazer isso sem algum tipo de estimativa?
As opções existentes não são perfeitas, como já foi falado… Essa é uma questão realmente complicada de ser respondida!!! O quanto vale a pena investir e detalhar em uma tarefa como esta? Sinceramente, eu até entro na discussão, mas não me atrevo a dar uma resposta definitiva…
Saudações!
Existe uma diferença entre planejamento e execução.
Quando vc planeja vc estima. Quando vc executa vc sabe.
Scrum é baseado em planejamento constante, o que significa que a cada momento vc estima onde vai terminar. Logo, tb no momento zero vc estima onde vai terminar. aliás, scrum só funciona por causa disso. Planejar é tudo , o plano é nada.
É uma falácia que as metodologias ageis não permitem estimar escopo e parametros de projeto com antecedencia. Se isso fosse real elas seriam inúteis. As metologias ageis, como quaisquer outras não definem contratos, mas como qq outras dão as ferramentas para levantar dados para os fazer. A diferença entre agil e tradicional é que agil realmente consegue fornecer informações uteis em qualquer momento do tempo. O Projet burdwon chart é exactamente para isso que serve. A linha reta diagonal mostra excatamente o que é previsto.
O triste é querem passar essa ideia que agil é bandalheira que é “tudo solto” e que não permite compromissos. É exactamente o contrário. Especialmente Scrum, que é o citado na revista.
Só vejo um problema na tal metodologia ágil: tempo de término. Ótimo ficar replanejando, ótimo sempre estar interagindo, mas, pra quando? sabemos quando começa, mas não há um prazo definido de término e ai começam os problemas: cliente. Ele pode estar ciente, e muitas vezes está, mas ele não quer saber. Como qualquer produto, as pessoas estão acostumadas a pagar pelo que compraram e não a mudar o valor a cada interação. É evidente que isso é um velho pensamento em uma forma de trabalho totalmente diferente. Desenvolver algo customizado exige-se que o cliente saiba que o escopo muda e que o tempo também. Mas no geral, ele quer tudo, mas com o prazo final determinado.
Como já foi falado, em licitações é pior ainda, eles abrem uma, esperando um começo, meio e fim (mais o fim) e ponto. Não dá pra renegociar nada, porque o preço foi fechado. Creio que o Scrum esbarra na cultura e não que seja ruim, aliás, é ideal, mas a cultura ainda é outra.
Não é só desenvolvimento de software que é assim, qualquer produto personalizado, seja um livro, filme, carro, moto e outros, todos precisariam de um escopo variável, mas sabemos que não é sempre assim. Negociar com o cliente é que é a arte, o resto são apenas métodos aplicados e o que o Scrum faz é criar uma forma de deixar todos cientes dos problemas e seus respectivos meios de contorná-los.
Outra coisa é sobre previsão. Hora, alguém aqui já fez previsão de demanda? Pois é, quem manja disso, sabe que, com menos de 5 anos, é complicado e volátil fazer uma previsão de demanda com precisão. É assim na parte elétrica, no estoque de uma empresa e também no desenvolvimento de software. Se você não tem ao menos 5 anos desenvolvendo aquele tipo de software pedido (o tipo me refiro ao modelo), será complicado você estimar uma previsão.
[quote=javamaniaco]Só vejo um problema na tal metodologia ágil: tempo de término. Ótimo ficar replanejando, ótimo sempre estar interagindo, mas, pra quando? sabemos quando começa, mas não há um prazo definido de término
[/quote]
Ora ai é que está. Existe sim um prazo definido para o término. É isso que estou dizendo.
Se existe é possivel estimá-lo.
É preciso entender a diferença entre tamanho do projeto e escopo do software.
O tamanho é fixo. Sempre é fixo. Se não for a software house morre porque não tem como gerenciar as coisas para alocação em outros projetos. O projeto não dura para sempre e não tem tamanho infinito.
O escopo é aquilo que será entregue. Isto muda.
imagine assim: cada vez que uma feature for incluida no software água será colocada num jarro.
O tamanho do jarro é o tamanho do projeto. quando estiver cheio , acabou.
as features são como copos de diferente tamanho cheios de água. Quando vc completar aquela feature, vc adiciona aquela quantidade de água no jarro.
Em scrum se usa a analogia da vela por causa do burndown chart ( gráfico que queima), mas dá no mesmo.
Em agile todas as features têm um tamanho. Isto é essêncial.
A soma do tamanho dá o tamanho inicial. Do tamanho inicial tiramos o tamanho contratado.
Por exemplo, depois de estimar as features chegamos em 2500 pontos. Contratamos com o cliente 3000 pontos.
Analizando o backlog dividimos em 3 releases : 1500 pontos, 1000 pontos e 500 pontos.
Calculamos as datas de cada uma. Pronto. Isso é o contrato.
O cliente pode e deve mudar as features mas ele não pode mudar o tamanho do projeto. ( a menos que faça outro contrato, claro)
Porque ele não pode mudar o tamanho, prazos e custos são fixos.
Contudo ele pode mudar o quê ele quer fazer com esses 3000 pontos. É ai que está a agilidade. É dessa forma que o escopo muda.
O escopo do software muda. O do projeto não.
Sim.É verdade.
mas existe uma diferença entre ter outra cultura e difamar a cultura dos outros.
Ele faz mais que isso. Scrum é para gerenciamento. Não precisa ser gerenciamento de software. ele pode ser usado em todas essas áreas que falou. Existem relatos de uso em marketing.
[quote]
Outra coisa é sobre previsão. Hora, alguém aqui já fez previsão de demanda? [/quote]
Isso que é o legal de agil. Vc não precisa prever a demanda. O cliente pode demandar o que quiser quando quiser.
A unica restrição é o tamanho fixo do projeto. Ísso obriga o cliente a pensar e a fazer escolhas e trade-off. E é isso que os clientes estão pouco habituados. Eles estão habituados que os gerentes “abram as pernas”. E é essa (in)cultura que destroi os projetos e sacrifica os desenvolvedores.
Com scrum se o cara começou por pedir um ERP e mudou para um Jogo de RPG não tem problema nenhum.