MundoJava 38 - Boas Práticas Java EE - Acerte na sua escolha!

Guerr@:

Auditoria Avançada de Persistência com Hibernate, JPA e Envers
Aprenda como implementar um robusto e completo sistema de auditoria de persistência com o Hibernate em conjunto com o Envers
Autores: José Yoshiriro Ajisaka Ramos e Márcia Amaral

Automatização de testes de persistência com FIT, DBUnit e HSQLDB
Obtenha o máximo de qualidade, eficiência e clareza escrevendo testes de integração automatizados com FIT, DbUnit e HSQLDB.
Autores: Alexandre Gazola

Provocação Digital: Existem métricas eficientes para estimar desenvolvimento OO?
Uma discussão sobre algumas metodologias disponíveis para estimativa do tempo de desenvolvimento
Autor: Glauco dos Santos Reis

Aguardando anciosamente a minha chegar!

É isso aí pessoal, aguardamos o feedback de vocês!

abraços

Eu ja li alguma coisa (compro minha revista na banca).

Eu gostei da materia “interativa”, o formato eh bacana (eu lia revistas e pequenos livros com historias assim a muitos anos atras, bateu um saudosismo). Soh acho que essa coisa de “se vc fizer isso, vai acontecer aquilo” funciona na ficcao, no mundo real eh meio furado. Mas o conteudo esta interessante.

A coluna do Taurion sempre esta legal, eh sempre a primeira que leio. E sobre as “metricas eficientes”, achei soh razoavel, nao trouxe nada muito diferente e nao respondeu direito a pergunta do titulo.

Dei soh uma folheada no resto, a materia sobre os maus habitos de JSF parece estar legal tbem.

Abraco

Este artigo é muito interessante. Ele deixa vc decidir e ver onde isso lhe leva.
Dada a recente discussão sobre patterns este artigo mostra porque patterns são importantes e saber escolhê-los é mais importante ainda.

Mais exercícios deste tipo seriam interessantes até mesmo para uso em escolas e cursos, porque infelizmente a nova onda é achar que patterns é inútil e quadrado.

Para compensar, este artigo é totalmente o inverso. Tudo bem que é uma provocação, mas a que propósito em pleno seculo XXI já quase na segunda decada do seculo ainda estamos falando de pontos de função ? nostalgia ?

O artigo explica rápidamente pontos de funçao e pontos de caso de uso , e o que todo o mundo está cansado de saber : não funciona. Depois pois scrum no barulho. O autor diz que scrum não tem mecanismos para estimar o desenvolvimento.
Isto é tão absurdo em tantos niveis que não sei nem por onde começar. Era essa a provocação ?

Se scrum tem um product backlog, com todas as estorias com seus story points. Como se pode dizer que scrum não tem forma de estimar ? Afinal o que seria planning poker senão uma forma de estimar ? Esta noção de que scrum não permite estimar é incompreensivel para mim e sinceramente me enoja.

Claro, o artigo foca em estimar custo e prazo numa velada tentativa comum de violar o triangulo de projeto e fala que embora o scrum tenha os story points e tal não é possivel chegar em prazos e custos. Scrum sim permite estimar!.

A provocação funcionou e essa é a minha resposta.

A história interativa foi muito bem bolada. fiquei depois fazendo todos caminhos possiveis, pra ver o que acontecia…hehehe

As outras matérias estão muito boas, exceto a matéria sobre métricas OO. Realmente, acho que não chegou-se a nenhuma conclusão, seria melhor se houvesse um exemplo teórico, um caso de uso simples para ser medico com todas as métricas apresentadas, ai sim daria pra ter uma comparação melhor.

Não sei porquê, mas eu nunca gostei das matérias sobre SOA. Acho que deve ser implicancia minha, quando abri a revista e vi que não tinha nenhuma, fiquei até feliz! kkkkk

abraços!

Eu ja li algumas partes , mto bom o artigo sobre Jsf do rafael ,mas gostei muito , mto msm do artigo
Aprendendo Padrões Java EE com uma História Interativa :Autores: Roberto Perillo e Eduardo Guerra e uma visao bem diferente me diverti mto lendo.

Estou lendo a materia. Nos 10 maus habitos. no habito 8 uso do redirect. achei q a sulução ficou um pouco vaga. Tive problemas com o que ele chamou de double submit. No core JavaServer Faces segunda edição fala do uso da tag e explica justamente q ela pode ser usada e que apaga os dados da requisicao. achei interessante e ia fazer um teste. quando acabei de ler na revista que é uma má pratica.

Nesse caso uma enfase maior nesse problema seria bom. muitas pessoas tem esse problema. como o usuario final do sistema web é acostumado usar os botoes do browser e o recarregar… isso eh um problema comum.

Guerra, vocês já fizeram algum artigo sobre melhora de desempenho e alta performance para aplicações Java em sistemas críticos? Se não, fica a sugestão de pauta.

Fazia tempo que eu não lia a MJ, mas essa está interessantíssima, não vou perder não.

hehe… acho que esse é um dos motivos de eu ter deixado a revista um pouco de lado, os caras estavam realmente obcecados por esse assunto

A Revista aborda sim temas que são importantes mas com repetição sobre tecnologias já observadas em outros artigos, uma forma de fazer novas implementações ou mesmo sobre soluções que envolve sempre os mesmos assuntos.

Gostaria que a Revista fala-se mais sobre Python, a nova linguagem do GOOGLE o GO, SCALA entre outros frameWorks como DJANGO, e até mesmo sobre Visual Tersus um Open Source em Java, poderia questionar outros aspectos do Scrum assim como o Sergio Tarboda observou na estimativa sobre projetos e desenvolvimento, a revista as vezes se volta para assuntos que já é batido e sem muita sujestão.

jcracker:

A Revista aborda sim temas que são importantes mas com repetição sobre tecnologias já observadas em outros artigos, uma forma de fazer novas implementações ou mesmo sobre soluções que envolve sempre os mesmos assuntos.

Gostaria que a Revista fala-se mais sobre Python, a nova linguagem do GOOGLE o GO, SCALA entre outros frameWorks como DJANGO, e até mesmo sobre Visual Tersus um Open Source em Java, poderia questionar outros aspectos do Scrum assim como o Sergio Tarboda observou na estimativa sobre projetos e desenvolvimento, a revista as vezes se volta para assuntos que já é batido e sem muita sujestão.

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.

thimor:

Estou lendo a materia. Nos 10 maus habitos. no habito 8 uso do redirect. achei q a sulução ficou um pouco vaga. Tive problemas com o que ele chamou de double submit. No core JavaServer Faces segunda edição fala do uso da tag e explica justamente q ela pode ser usada e que apaga os dados da requisicao. achei interessante e ia fazer um teste. quando acabei de ler na revista que é uma má pratica.

Nesse caso uma enfase maior nesse problema seria bom. muitas pessoas tem esse problema. como o usuario final do sistema web é acostumado usar os botoes do browser e o recarregar… isso eh um problema comum.

Thimor,

O mau hábito não é o fato de usar o redirect, mas sim utilizá-lo da forma indevida. O exemplo da má prática do artigo foca no uso do redirect para facilitar a vida de filtros de segurança que verificam, através da URL, se o usuário autenticado tem ou não acesso a uma página. Como em JSF a navegação é por forwards (exceto Facelets), alguns desenvolvedores vão pelo caminho mais fácil, que é usar redirect sempre para forçar que a requisição passe pelos seus filtros.

Use o redirect quando ele fizer sentido em um problema, como no caso da prevenção de double submits.

Abraços.

Vai ter “jotassefista” botando meu nome na boca do sapo, mas achei muito estranho os 10 maus hábitos. A impressão que tenho é que os 10 maus hábitos está para o JSF assim como o Core J2EE Patterns está para o EJB: Joga a culpa dum framework problemático nas costas dos desenvolvedores (que, supostamente, não sabe usar os padrões estabelecidos), ao invés de admitir que o problema está no próprio design.

Veja, fui um desenvolvedor JSF por muito tempo, e hoje desenvolvo um site em VRaptor. E não penso nem meia vez ao recomendar este ao invés daquele. E porque? Porque nunca ouvi falar em maus hábitos dos desenvolvedores VRaptor. Porque não há reinvenção da roda. E todos aqueles padrões comumente encontrados no desenvolvimento web são benvindos no VRaptor, não apenas “maus hábitos”.

E não me venha dizer que JSF é melhor para aplicações em workflow ou com estado persistente na página, isso é melhor resolvido com JQuery e afins (aliás, os melhores sites “stateful” são feitos em Javascript, não JSF). “Ah não! Javascript é complicado e não funciona no IE!” Paciência, aprenda!

“Jotassefistas” de carteirinha, agora podem jogar tomates. Não vou treplicar o meu comentário.

Leonardo3001:

Vai ter “jotassefista” botando meu nome na boca do sapo, mas achei muito estranho os 10 maus hábitos. A impressão que tenho é que os 10 maus hábitos está para o JSF assim como o Core J2EE Patterns está para o EJB: Joga a culpa dum framework problemático nas costas dos desenvolvedores (que, supostamente, não sabe usar os padrões estabelecidos), ao invés de admitir que o problema está no próprio design.

Veja, fui um desenvolvedor JSF por muito tempo, e hoje desenvolvo um site em VRaptor. E não penso nem meia vez ao recomendar este ao invés daquele. E porque? Porque nunca ouvi falar em maus hábitos dos desenvolvedores VRaptor. Porque não há reinvenção da roda. E todos aqueles padrões comumente encontrados no desenvolvimento web são benvindos no VRaptor, não apenas “maus hábitos”.

E não me venha dizer que JSF é melhor para aplicações em workflow ou com estado persistente na página, isso é melhor resolvido com JQuery e afins (aliás, os melhores sites “stateful” são feitos em Javascript, não JSF). “Ah não! Javascript é complicado e não funciona no IE!” Paciência, aprenda!

“Jotassefistas” de carteirinha, agora podem jogar tomates. Não vou treplicar o meu comentário.

Entao la vai o primeiro tomate podre!! hehe brincadeiras a parte, não ha o que argumentar, ja é sabida de todos no forum a sua paixao por action based, e a sua birra por component based, entao: Contra gosto não ha argumentos!

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) :?

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) :?

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?”??

Ta certo que algumas coisas enchem, mas as coisas estao ali por algum motivo.

fredferrao:

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?”??

Ta certo que algumas coisas enchem, mas as coisas estao ali por algum motivo.

como falei, não li o artigo sobre métricas, mas agora vou antecipar esta leitura.

Ok. Ainda referente a materia dos 10 maus habitos o mau habito 3 referente ao acesso a metodos expostos. O exemplo utilizado pelo dataTable. Vi que esse mal hábito se enquadrou da forma que utilizo para paginar tabelas. Sempre que pagino uma tabela tenho q acessar o metodo getDadosDaTabela que faz uma consulta ao banco de dados. Nesse caso achei a solução valida. Porem nao achei ela adequada para resolver a paginação de tabelas ou pelo menos não ficou de forma implícita.

Minha opnião.

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.

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.

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.

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) :?

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?”??

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

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. "

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.

ncm:

Segui a historia interativa e me dei mal…

rsrrsrsrs…

Mas aposto que ganhou em aprendizado!!!

Espero que se dê bem nas histórias da vida real!

Guerr@:

ncm:

Segui a historia interativa e me dei mal…

rsrrsrsrs…

Mas aposto que ganhou em aprendizado!!!

Espero que se dê bem nas histórias da vida real!

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

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

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.

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

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.

Outra coisa é sobre previsão. Hora, alguém aqui já fez previsão de demanda?

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.

Só uma pergunta…Com essas mudanças todas…como que é feito o gerenciamento do tempo?? replanejado com o cliente???

Acho que não entendi a pergunta , mas … o gerenciamento do tempo é feito por meio de re-priorização e pela divisão em sprints. O replanejamento com o cliente acontece antes e depois de um sprint. antes para planejar o que será feito, depois para ver como foi.
Isso interfere no planejamento do proximo sprint e assim vai sucessivamente…

Em scrum features ficam prontas no fim do sprint. Ou então não ficam prontas. não ha “80% pronto”. Ha pronto e não pronto.
Se está pronto pode ser usado pelo cliente já, naquele momento. se não está pronto o cliente decide se o proximo sprint vai ser usado para continuar isso ou não. É o cliente ( o PO) que decide tudo isso. E ele faz isso regularmente sprint após sprint. Em scrum isso significa 1 a 2 vezes por mês dependendo do tamanho do sprint.

Em Scrum nunca ha atrazo no sentido classico porque as datas nunca mudam. Se o sprint acaba hoje, acaba hoje. doa a quem doer.
Este é o conceito de time-box que é um dos pilares do scrum. A data sempre é fixa. O que acontece é que a feature pode estar pronta ou não.

Lembrar que “pronto” é um conceito a convencionar. Para algumas equipas isso significa apenas “funciona”, Para outra significa “funciona, foi testado atuomaticamente e continuamente, está documentado , está no manual do usuario e está no SVN”. O “grau” de pronto é diretamente proporcional à qualidade da equipa e ao preço cobrado.

Sinceramente até agora nao responderam a questão do TEMPO!

Vivem repetindo e repetindo, mas o que ja falaram do SCRUM até agora, é que é sempre em runtime, sempre com a coisa andando, acontece que quero saber pra quando e quanto antes do inicio do projeto.

O Guerra usou o exemplo perfeito, uma licitação, o cliente chega e fala, quero o sistema X com Y features, tem que ficar pronto em J dias e vou pagar I valor. Ou ainda pior, na licitação o cliente pode falar, quero X com Y features e pago I, e, em quanto tempo, pode ser considerado como ponto para ganhar ou nao a licitação.

Eae? como é que voce sabe se consegue terminar no tempo pra peitar essa licitação ou ainda meter um tempo pro cliente, tempo esse que vale como desempate na licitação. E ainda se vale apena o preço pago? Sim porque voce teria que saber quanta gente e tempo tu leva e ai entra o ponto de estimar, como fica?

Na primeira que responderam meteram logo um depende no meio, o que nao me convenceu.
Mesmo que depende que quanto quero pagar, mesmo assim eu quero saber logo de cara quanto tempo leva, ou ainda posso falar que quero pra data X, e quero isto senao nao fecho o contrato, entao como tu vai responder pra mim se consegue me entregar naquela data?

E se o cliente diz assim: “legal, nessa proxima Iteracao (ou sprint, ou seja que nome for), a gente precisa disso, daquilo, daquilo outro e mais aquilo outro la, alem do ficou pra tras no sprint anterior”. Sendo a data fixa, nao corre o risco de engordar de tarefas e o sprint ficar parecendo o bonequinho da Michelin?

Eu nao faco a pergunta de sacanagem, a faco pq meu conhecmento de Scrum eh (pouco) teorico, e tambem pq ja vi isso acontecendo com iteracoes de 10 dias (mas nao era Scrum).

Abraco

Na verdade tudo é uma questão de risco. Concordo que no momento zero você sabe onde vai terminar, porém quando você pode negociar escopo e realizar o planejamento constante esse risco é mais gerenciável. Quando uma empresa tem que dar o preço de um software antes de começar a faze-lo o risco é bem maior! Nada contra utilizar o Scrum depois de estar com o contrato fechado e criando o software, porém no momento de estimar o preço inicial ele não ajuda muito…

Acho que esse foi o ponto que foi levantado no artigo. O Scrum é muito útil para o gerenciamento e não para a estimativa de preço e tamanho do software. E isso não é nenhuma vergonha para o Scrum! Ele funciona muito bem dentro dos seus objetivos!

guerr@:

Na verdade tudo é uma questão de risco. Concordo que no momento zero você sabe onde vai terminar, porém quando você pode negociar escopo e realizar o planejamento constante esse risco é mais gerenciável. Quando uma empresa tem que dar o preço de um software antes de começar a faze-lo o risco é bem maior! Nada contra utilizar o Scrum depois de estar com o contrato fechado e criando o software, porém no momento de estimar o preço inicial ele não ajuda muito…

Acho que esse foi o ponto que foi levantado no artigo. O Scrum é muito útil para o gerenciamento e não para a estimativa de preço e tamanho do software. E isso não é nenhuma vergonha para o Scrum! Ele funciona muito bem dentro dos seus objetivos!

Apesar de me incomodar um pouco (fica parecendo que é tudo no chute) eu concordo que de fato é uma questão de risco.

Na minha opinião determinar preço e prazo é uma tarefa complexa que envolve muitas variáveis, e o pior, o fator humano tem grande pêso na questão. O histórico de experiencias anteriores acredito que seja a “ferramenta” mais utilizada por todos para qualquer coisa, só perde para a adivinhação. Mas para funcionar bem o projeto tem que ser similar aos anteriores, a(s) equipe(s) tem que ser a(s) mesma(s) na totalidade. Se for um projeto bem diferente vai requerer um estudo deste projeto para detectar os pontos de complexidade e viabilidade no intuito de determinar os valores, não sei se vocês percebem mas este tipo de coisa leva TEMPO e DINHEIRO, detalhe o cliente ainda não assinou o contrato autorizando o início. Se não estou enganado, existem empresas que negociam esta parte do trabalho, ou seja, pagam para saber se é viavel do ponto de vista tecnológico e financeiro.

O engraçado é que nas empresas que desenvolvem software o que mais tem é gente expondo os problemas de forma ultra superficial e espera a resposta sobre preços e prazos em 10 segundos; não deve ser de todo ruim, tem muitas empresas que vão até que bem assim.

flws

fredferrao:

Sinceramente até agora nao responderam a questão do TEMPO!

Vivem repetindo e repetindo, mas o que ja falaram do SCRUM até agora, é que é sempre em runtime, sempre com a coisa andando, acontece que quero saber pra quando e quanto antes do inicio do projeto.

O Guerra usou o exemplo perfeito, uma licitação, o cliente chega e fala, quero o sistema X com Y features, tem que ficar pronto em J dias e vou pagar I valor.

Se o cara define escopo (as features) o prazo (J) e o preço ele está definindo todos os lados do triangulo de projeto o que significa : vai procurar outro.

Mas se vc for mazoquista vc pode entender que está perante um projeto de custo fixo e estimar se consegue aquelas features naquele prazo por aquele custo. Faz assim:

pega a equipa e poe ela a estimar as features. Se a equipa tem experiencia zero, o erro será absurdo e portanto nem vale a pena entrar na licitação. Se a equipa tem experiencia com esse tipo de sistema, ela avalia em SP as features. Como neste caso o fator risco é importante, é bom que a estimativa use intervalos. (tecnica dos 50%-90%)

Cada features tem então um SP minimo e um máximo.
Some todos os minimos e todos os máximos.
O product backlog será entre esse valores. Digamos que o resultado foi de 1000 a 3000 SP.
Pegue a velocidade da equipa. Calcule quantos sprints são necessãrios. Se a velocidade for 100 temos de 10 a 30 sprints.
Utilize a duração do sprint em dias uteis. digamos 15 dias. temos então : de 150 a 450 dias uteis.
Converta isso para dias corridos. digamos que dá 210 e 630 dias corridos.
compare com a data J.
Se J está acima de 630 dias, não ha risco algum. Se está abaixo de 210 só ha risco. fuga da licitação.
Se está no meio é preciso entender o risco. Isso é algo que não é matemático. Cada caso é um caso.
Por outro lado, calcule o custo da equipa trabalhando 210 dias e 630. Esse é o range de custo do projeto. Veja se é compativel com o valor de I

Faça as mesmas contas de antes. considere um projeto de custo fixo.
Lembre-se que licitação é uma espécie de jogo.Existe um fator de felling/tato que nenhuma metodologia oferece. Sempre ha um fator elevado de risco. Existem várias formas de minimizar esse risco ( equipe coesa e trabalhando junta à muito tempo, velocidade hipersaturada , boa plataforma de aplicação ou bom dominio das tecnologias proposta na licitação, boas ferramentas, boas práticas, etc…) - mas o risco sempre está lá.

Repare que é tudo matemático ninguém executou trabalho nenhum. Não estamos em runtime.

E se o cliente diz assim: “legal, nessa proxima Iteracao (ou sprint, ou seja que nome for), a gente precisa disso, daquilo, daquilo outro e mais aquilo outro la, alem do ficou pra tras no sprint anterior”. Sendo a data fixa, nao corre o risco de engordar de tarefas e o sprint ficar parecendo o bonequinho da Michelin?

A primeira coisa a entender é que o sprint (iteração) tem um tamanho e uma duração.
A duração é fixa. O tamanho depende da alocação dos desenvolvedores. em situação comum, esse tamanho é a velocidade estimada. A equipa estima uma velocidade para o sprint, ou seja, quantos pontos a equipa consegue queimar neste sprint. digamos, 80. O PO - que já priorizou o backlog - escolhe as primeiras N estorias que somem 80. Não necessáriamente seguindas. Ele escolhe um grupo que some 80.

Cliente é uma palavra comum, mas não é muito genérico. As decisões do PO não são afetadas apenas pelo cliente. São afetadas por todos os stakeholders. É por isso que o PO não é o cliente. O PO comunica com o cliente. O PO é o cara que tem a responsabilidade perante o cliente e perante a software house de fazer o software. Portanto, existe um fator a mais aqui que é o valor. às vezes o PO inclui coisa aparentemente menos necessárias porque ele está incluindo valor para agradar ao cliente. ele faz isso porque é uma diretiva da software house (da diretoria) e não do cliente em si.

O ponto é o seguinte: para usar Scrum, todos precisam se compromter com os valores do scrum. Senão não funciona.
Esta é a parte dificil. Se ha compometimento ha respeito e isso significa que o PO pode dizer não ao cliente , aos diretores e à equipa. e estes podem dizer não de volta. A comunicação é vital. è por isto que esta pessoa se chama da Dono do Produto. Pois o produto é a unica que ele protege. O resto é negociável.

Se ha respeito , o PO sabe como funciona o scrum e sabe que não ha proveito em criar sprints michelin. Ele sabe que isso irá estragar o produto. Se ele não sabe isto, ele não é um bom PO.

Inchar o sprint é simplesmente proibido. Não ha desculpa. Não ha exceção. Se isso acontecer o scrum morreu porque o compromisso foi traido. Eu já passei por isso e não é bonito. Vc entende que as pessoas não estão preparadas para usar Scrum.

Scrum é facil tecnicamente, mas exige muito moralmente e profissionalmente e infelizmente a maioria das pessoas não está preparada para isto.

Se alguem incha o sprint ou o backlog fora das regras do scrum, tenha a certeza que não é scrum que está fazendo. ai mais vale voltar aos métodos tradicionais.

Guerr@:

sergiotaborda:

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.

…

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.

Na verdade tudo é uma questão de risco. Concordo que no momento zero você sabe onde vai terminar, porém quando você pode negociar escopo e realizar o planejamento constante esse risco é mais gerenciável. Quando uma empresa tem que dar o preço de um software antes de começar a faze-lo o risco é bem maior! Nada contra utilizar o Scrum depois de estar com o contrato fechado e criando o software, porém no momento de estimar o preço inicial ele não ajuda muito…

Bom, eu discordo vemente dessa afimação. Gostaria de saber porque ele não ajuda sendo que para fazer o backlog, que é um processo que acontece antes do inicio do projeto - vc faz exactamente o mesmo tipo de levantamento e conversa que faria nas metodoloias tradicionais. Sendo que o backlog está pronto dele é possivel estrair qualquer previsão. Então não entendo como isso não ajuda.

sergiotaborda:

…O ponto é o seguinte: para usar Scrum, todos precisam se compromter com os valores do scrum. Senão não funciona (…) Inchar o sprint é simplesmente proibido. Não ha desculpa. Não ha exceção. Se isso acontecer o scrum morreu porque o compromisso foi traido. Eu já passei por isso e não é bonito. Vc entende que as pessoas não estão preparadas para usar Scrum.

Scrum é facil tecnicamente, mas exige muito moralmente e profissionalmente e infelizmente a maioria das pessoas não está preparada para isto…

Pois eh, eu tenho isso claramente comigo, software eh feito por pessoas.

Um processo sozinho nao faz nada, sejam ageis, tradicionais, modernos, antiquados. Nada vai funcionar direito se as pessoas nao estiverem comprometidas E preparadas. O que me deixa mal humorado eh que MUITA gente nao entende isso.

Muito bom. Obrigado!

Eu assisti uma palestra ministrada aqui no ITA pelos professores Marco Vieira e Rogério de Lemos sobre Scrum. No final da palestra foram feitas diversas perguntas do tipo “Mas e se no meu ambiente de desenvolvimento…, como eu faço?” e a resposta para diversas perguntas era: para essa situação o Scrum não é adequado. Minha opinião é que você está defendendo que o Scrum é bom sempre, e isso não é verdade…

Dêem uma olhada neste link: When should you nou use scrum? http://stackoverflow.com/questions/596916/when-should-you-not-scrum

Pegando uma frase desse link: “I would not use Scrum when I have a fixed deadline with a fixed feature set.” - o que é o caso em uma licitação: você possui uma especificação e uma data de entrega fixas, e você precisa dar o seu preço. Como você disse “planejar é tudo”, acontece é neste caso você precisa fazer um plano detalhado logo no início e estimar ele com uma certa precisão - isso não tem cara de Scrum para mim…

Se você quer mesmo me convencer que o Scrum pode ser utilizado para estimativa de preço, me diga se existe algum caso de sucesso. Quantas empresas tem utilizado o Scrum para esse fim?

Eu concordo com o Eduardo. Também, convenhamos, na maioria dos projetos de software não existe essa de “escopo fixo”. Se o escopo for fixo, ou seja, tudo está claramente especificado, detalhado e conhecido, então até waterfall no projeto irá funcionar.

Sendo assim, temos o cenário mais real: o cliente tem apenas uma idéia do que ele quer. Com isso, conseguimos um product backlog bem alto nível, visto que nesse ponto tem-se muita coisa desconhecida. Fazer as estimativas em cima de todo esse backlog preliminar será difícil e, muitas vezes, nem será possível porque muitos itens não são conhecidos no momento. Por isso, torna-se bastante complicado fazer a estimativa de prazo/custo do projeto inteiro, com um bom nível de segurança, usando-se SPs.

fantomas:

Mas para funcionar bem o projeto tem que ser similar aos anteriores, a(s) equipe(s) tem que ser a(s) mesma(s) na totalidade.

Acabei de ver um post do Scott Ambler no Twitter: os projetos de software são como flocos de neve, pois de longe parecem ser todos iguais mas quando chegamos perto nos deparamos com grandes diferenças. Os projetos são únicos do ponto de vista do processo: https://www.ibm.com/developerworks/mydeveloperworks/blogs/ambler/entry/snowflake_analogy?lang=en

Guerr@:

sergiotaborda:

Bom, eu discordo vemente dessa afimação. Gostaria de saber porque ele não ajuda sendo que para fazer o backlog, que é um processo que acontece antes do inicio do projeto - vc faz exactamente o mesmo tipo de levantamento e conversa que faria nas metodoloias tradicionais. Sendo que o backlog está pronto dele é possivel estrair qualquer previsão. Então não entendo como isso não ajuda.

Eu assisti uma palestra ministrada aqui no ITA pelos professores Marco Vieira e Rogério de Lemos sobre Scrum. No final da palestra foram feitas diversas perguntas do tipo “Mas e se no meu ambiente de desenvolvimento…, como eu faço?” e a resposta para diversas perguntas era: para essa situação o Scrum não é adequado. Minha opinião é que você está defendendo que o Scrum é bom sempre, e isso não é verdade…

Não. Não estou defendo que o scrum é bom para tudo. Estou defendendo que o Scrum sim permite fazer previsões ao contrário do que foi dito no artigo. Boas ou más , isso depende. Para as outras metodologias tb ha boas e más estimativas pois estimar é processo que inclui capacidades humanas além de saber fazer contas. O ponto é que Scrum oferece um tipo de ferramental equivalente a PF ou a PCU e fornece logicas para estimar. Já mostrei várias vezes como. É inegável que existe esse mecanismo.
Se a estimativa é util ou válida em certo caso são outros 500. Muita gente defende que PF não é válido em projetos OO. Isso são opiniões , não fatos.

Repare que dizer que scrum não é bom para X ou Y é saida fácil de quem não sabe como usar scrum nessas situações. Isso não significa que seja verdade. Para entender isto vc precisa de 2 coisas : ler o livro so ken schwaber “Agile Project Management with Scrum” e praticar scrum. Vc vai entender que quando vc está compometido vc consegue usar scrum mesmo em situações hostis, é por isso que o ken sempre fala que scrum é a arte do possivel. O exemplo interessante é como mesmo tento que fornecer gráficos de grant do projeto scrum pode ser usado. Aposto que esses senhores da palestra lhe diriam que scrum não pode ser usado nessas circunstancias ou que - pior - agil não usa gráficos de grant.

Eu não tenho culpa das missconception que ha por ai, como aquela que vc está fazendo e - pior - foi publicada. Estou tentando explicar que existe muito mais no scrum que iterações.

O scrum não valer numa licitação é diferente do scrum não ter mecanismo de estimativa.
Ele tem mecanismos de estimativa sim. Se vc não os usa, ou não saber usar, é outro problema.
Eu já expliquei atraz como faria numa situação dessas.

Eu não vejo problema em usar para licitação. Você vê. Questão de opinião. afinal nenhum de nós usou para isso.
Mas eu já usei Scrum em projetos normais e não vejo problema. Aliás foi a falta de previbilidade das metodologias tradicionais que me fez procurar scrum.

Não. Não precisa. Não em Scrum. Esse é ponto.
Em metodologia tradicionais vc precisa estimar as tarefas dos programadores para estimar custo/hora etc…
Em Scrum não.

O backlog já está feito : é a própria especificação. Os releases estão determinados pelas datas de entrega do edital.
Pronto. Agora vc só precisa calcular o custo.

Se vc tem um projeto de prazo fixo, vc faz assim :
Fixa o tamanho do sprint. Vê quantos sprints cabem no prazo. Divide os pontos do backlog pelo numero de sprints.
Isso é a velocidade que a equipa tem que ter. Quantas pessoas, com qual grau, vc precisa ter para ter essa velocidade?
Vc já tem um equipa ? a velocidade dela é compativel ?

É muito simples.
A simplicidade do scrum é assutadora para muitos porque esperam formulas reboscadas e coisas dificieis que exigem uso de planilhas. Mas é simples mesmo.

Esse é o problema. Tudo isso é a sua opinião. mas vc colocou isso na revista como se fosse um facto.
É isso que é revoltante. não houve peer review, não houve procura de outras fontes. não houve tentativa de entender como seria feito em scrum.

Um coisa é achar que não é válido e não funciona, outra coisa é dizer que não existe.
Para PF e PCU foi dito que ñ são válidos, não funcionam. Mas para Scrum foi dito que não existe forma de estimar.
E é isso que é falso. Existe sim. E tem que ser mostrado. Mesmo que no fim vc conclua que é inválido como os outros. não importa.
mas dizer que não existe é um des-serviço a todos os leitores.

Eu não quero convenser vc de nada. Eu quero apenas mostrar a falácia do artigo.
Mesmo que scrum não seja usado por ninguem para estimar coisa nenhuma isso não significa que não pode.
Vcs disseram na revista que Scrum não tem os mecanismos para estimar. Isso é falso.
Vcs não disseram “Scrum tem mecanismos, mas ninguém usa”.

Além disso, não existe um pesquisa confiável sobre quem usa Scrum. Mas se todo o mundo partir das mesmas falácias que a MJ partiu , ai sim que nunca ninguém vai usar.

Alexandre Gazola:

Eu concordo com o Eduardo. Também, convenhamos, na maioria dos projetos de software não existe essa de “escopo fixo”. Se o escopo for fixo, ou seja, tudo está claramente especificado, detalhado e conhecido, então até waterfall no projeto irá funcionar.

Sendo assim, temos o cenário mais real: o cliente tem apenas uma idéia do que ele quer. Com isso, conseguimos um product backlog bem alto nível, visto que nesse ponto tem-se muita coisa desconhecida. Fazer as estimativas em cima de todo esse backlog preliminar será difícil e, muitas vezes, nem será possível porque muitos itens não são conhecidos no momento. Por isso, torna-se bastante complicado fazer a estimativa de prazo/custo do projeto inteiro, com um bom nível de segurança, usando-se SPs.

Por essa lógica toda a software house que assina contratos de desenvolvimento é imbecil, pois se nada pode ser conhecido e nada pode ser base de estimativa, então a sh está entrado numa fria a cada contrato que assina e as coisas só dão certo por magia…

Me desculpem se eu acho isso uma tremenda de uma sem vergonhice.

O Product backlog não é ha mais que a lista de requisitos. ela é tão profunda ou tão superficial como a fizermos.
Se o PO e a equipa de analise têm um minimo de experiencia e profissionalismo ele tem a profundidade necessária.
Colocar nas costa do "projeto de software’ a incompetência dos analistas é demais

Como se estima o tamanho de requisitos nas metodologia tradicionais ? Não se estima. Eles sao partidos em tarefas essas tarefas é que são estimadas e tudo sai dai. Mas as tarefas reais que serão efetuadas são totalmente diferentes dessas portanto a estimativa é baseada em algo que irá mudar. é por isso que falha.

Em scrum as estorias são dimencioandas. Todas têm um tamanho. Some. A soma não vai mudar.
É tão dificil de entender este conceito ? Que a soma é fixa , mas os elementos não ?
Vcs nunca jogaram RPG ? O numeros de pontos de stat é fixo, a distribuição deles não é fixa. N combinações são possiveis, cada jogador tem uma que lhe agrada. SP é o mesmo. O bolo é fixo, a distribuição varia. Mas a destribuição não influencia as estimativas, apenas o bolo.

Sérgio,

Você me venceu pelo cansaço… Não quero mais discutir com você sobre o assunto!

Antes de mais nada o artigo que você cita, ao contrário do que você disse, é sim um artigo de opinião. O autor é um profissional com muita experiência de mercado a acredito que a opinião dele é válida mesmo que eu não concorde com ela. O nome da coluna é “Provocação Digital”, ou seja, é uma coluna que irá abordar alguns temas polêmicos e fazer algumas afirmações para “provocarem” o leitor a refletir.

Acho que se pela experiência de mercado e os contatos do autor, se ele não vê que ninguém utilizando isso, ele tem direito de fazer a afirmação que está no artigo. Mesmo que ela não esteja 100% precisa, lembre-se que isso é uma provocação. Que se manifeste alguém que se sentiu provocado e já utilizou o Scrum para estimar o preço de um software!!!

Fecho esse post com um convite, ou melhor, um desafio. Se você acredita que a revista não fez justiça ao Scrum, eu te proponho entrar em contato com a gente ([email removido]) para escrever um artigo mostrando para todos os leitores a sua visão do Scrum e como você pode utiliza-lo para estimar um software. Seria uma espécie de “direito de resposta”. O que acha?

Saudações!!

Vamos comentar sobre os outros artigos agora!!!

Alguém aí conseguiu seguir o caminho “de maior sucesso” da estória interativa na primeira tentativa?

Guerr@:

Vamos comentar sobre os outros artigos agora!!!

Alguém aí conseguiu seguir o caminho “de maior sucesso” da estória interativa na primeira tentativa?

Sim. Eu consegui.

O meu direito de resposta está exercido. Não carece de ser publicado.

“Alguns fazem. Alguns ensinam. O resto lê nos livros.”

De qualquer forma fica o convite!

sergiotaborda:

Guerr@:

Vamos comentar sobre os outros artigos agora!!!

Alguém aí conseguiu seguir o caminho “de maior sucesso” da estória interativa na primeira tentativa?

Sim. Eu consegui.

O meu direito de resposta está exercido. Não carece de ser publicado.

“Alguns fazem. Alguns ensinam. O resto lê nos livros.”

Sergio eu gostaria de ver um artigo seu na Revista Mundo Java, eu gosto do seu blog e frequentemente acompanho suas publicações agora também no JavaBuilder, tenho certeza e concordo com o Eduardo Guerra que vai ser muito bem vindo suas colocações e observações, vejo isso como um excelente oportunidade de networking.

Abraçosss

Guerr@:

Que se manifeste alguém que se sentiu provocado e já utilizou o Scrum para estimar o preço de um software!!!

Scrum sendo usado em licitações : http://etutorials.org/Microsoft+Products/Agile+Project+Management+with+Scrum/Appendix+D+Fixed-Price+Fixed-Date+Contracts/

Escrito pelo Ken Schwaber (um dos inventores do scrum) citando experiências reais.

eu cheguei no melhor caminho, até estranhei, pq eu fiquei em dúvida em alguns pontos sore qual a melhor solução. creio que isso se deve a uma certa falta de experiencia com alguns dos patters propostos, alguns eu só conheço, nunca precisei implemententar nada usando eles.

Enquanto não tiver fontes oficiais e referencias tudo aqui nao passa de falacia, opnioes e pontos de vista e este ultimo o pior, é por causa dele que existem tantas religiões e apenas uma biblia.

Agora vamos a alguns pontos, é possivel estimar com scrum? Bom parece que sim, mas ser possivel é muito diferente de foi criado para ou ainda é uma feature dele. Então me falem, existe um capitulo no guia oficial scrum(se é que existe esse cara) especificamente tratando de tecnicas scrum de fazer estimativas? Se sim, entao parabens, voce esta certo estimar faz parte do escopo do scrum, senão sinto muito, mas os que defendem o contrario estao certos. Ao que me parece a maneira de estimar que voce exemplificou é tipo um framework caseiro que voce ou outra pessoa achou/criou/inventou para se estimar o prazo/preço do produto antes do inicio da criação do mesmo usando os artefados do scrum(Product Backlog??), entao parabens sabemos que voce sabe fazer contas matematicas, mas o scrum nao foi essencialmente criado para tal.

Vamos a uma referencia, Por Ken Schwaber, Maio de 2009:

E olhe que estamos falando aqui de produto final, ao que me pareceu na citação era a versão do sprint.

Ainda no mesmo texto acima:

Baseado na sua técnica de estimar antes de iniciar o runtime, eu teria que ter um backlog do produto completo desde o inicio, o que ja foje tambem do descrito acima que diz que o backlog do produto é dinâmico e se eu nao tenho o detalhamento de cada feature logo de inicio como posso estimar(sua técnica) quantos pontos e sprints vou precisar para terminar o produto final e dar assim um preço/prazo para o cliente?

Em suma, eu com todo meu conhecimento avançado de scrum que aprendi todo neste post e na referencia acima digo: não existe técnica scrum para se estimar o preço e prazo de entrega de um produto, logo de cara antes do inicio de construção do mesmo( o exemplo da licitação), é possivel tentar fazer isto a partir de artefatos scrum(product backlog?) sim, mas não é uma técnica scrum e tambem exigiria que o product backlog estivesse completo desde o inicio e não sofresse alteração, fosse estatico.
LOGO, estou concordando com a MJ, me provem o contrario :?

[edited]
ops demorei tanto pra responder que tiveram varios outros posts, hehe mas nao saiu muito disso, apenas a nova referencia do sergio que vou ler agora.

Scrum sendo usado em licitações : http://etutorials.org/Microsoft+Products/Agile+Project+Management+with+Scrum/Appendix+D+Fixed-Price+Fixed-Date+Contracts/

Escrito pelo Ken Schwaber (um dos inventores do scrum) citando experiências reais.

Errr, ou meu ingles esta muito ruim, ou voce acaba de confirmar tudo que eu disse no post anterior, tem certeza que tu leu o que citou acima??

I had to admit to Tony that I didn?t know how to use Scrum to address his business. Scrum?s principle is ?the art of the possible,? not ?you give me what I paid for, when you said that you?d deliver it.? For several years after my meeting with Tony, this problem rolled around in my head and just wouldn?t go away, until finally I realized that Scrum had no silver bullet?it had to go about addressing fixed-price, fixed-date contracts exactly the way any other process would, including the defined, heavyweight methodologies. There simply was no way around analyzing the customer?s requirements enough to understand the scope of the problem and designing enough to understand the number and complexity of the architecture and design artifacts. What a terrible realization! This meant adding a waterfall phase to the front of the Scrum methodology that would produce documentation. That was terrible, and what possible benefit could Scrum provide after it had been so corrupted?

[edit]
mais um pedaço:

The more I thought about it, the more I realized that?even though Scrum couldn?t be used in its entirety?EngageX or any other organization bidding on fixed-price, fixed-date contracts could use Scrum to gain competitive advantage in bidding on fixed-price, fixed-date requests for proposals (RFPs).

Ele fala como empresas que trabalham com preços e prazos fixos podem usar o scrum para ganhar competitividade, e NÃO como estimar com o scrum nesta empresas.

É acho que a discussão morreu depois desta.

Acho que morreu mesmo!

Antes de mais nada gostaria de agradecer o Sergio por postar essa referência excelente que eu desconhecia e totalmente pertinente ao assunto discutido.

A primeira questão a ser colocada é que o Scrum não ataca diretamente este ponto. Se isso incomodou Ken Schwaber por um bom tempo, como ele afirma, não é tão obvio assim como estava sendo argumentado aqui no forum…

Ele afirma no texto que neste caso a solução é adicionar uma fase tradicional antes do Scrum, mostrando que sozinho ele não resolve este tipo de problema.

Saudações!!!

O que me atraiu e me fez escrever um artigo nesse formato é que ele faz as pessoas refletirem para tomar uma decisão e não simplesmente lerem para absorver a informação, muitas vezes sem raciocinar em cima do que está sendo falado. É neste “ficar na dúvida” que realmente você acabou adquirindo uma visão mais crítica dos padrões.

Uma coisa que vi, não só nesta discussão, mas na visão de muitos que vendem o Scrum por ai é que ele serve pra tudo. Não é bem assim. Ele pode ser parte de um todo, mas não o todo em si.
Parabéns a todos por esta ótima discussão e esclarecimento.

Existe ai uma situação de sobrevivencia nas questões que são de poder de desenvolvimento sobre gestão de projetos, ao colocar SCRUM como fator de estimar a melhor soluções é perfeitamente cabivel pois o que se busca é a inteligencia aplicada e isso requer o melhor time de desenvolvimento. Na ótica das metodologia tradicionais percebe-se uma forma de equacionalizar o problema ao invés de saber tratar de requisito como uma melhor ciência a produzir a melhor solução, concordo com o ponto de Vista do Sergio Taborda, acho que a revista Mundo Java se adiantou e não buscou melhor concepção sobre outros fatores que implicariam em uma avaliação melhor em conceitos sobre gerencia de projetos.

fredferrao:

sergiotaborda:

Guerr@:

Que se manifeste alguém que se sentiu provocado e já utilizou o Scrum para estimar o preço de um software!!!

Scrum sendo usado em licitações : http://etutorials.org/Microsoft+Products/Agile+Project+Management+with+Scrum/Appendix+D+Fixed-Price+Fixed-Date+Contracts/

Escrito pelo Ken Schwaber (um dos inventores do scrum) citando experiências reais.

Errr, ou meu ingles esta muito ruim, ou voce acaba de confirmar tudo que eu disse no post anterior, tem certeza que tu leu o que citou acima??

Sim. Seu inglês deve estar ruim.

O problema é complexo e o Ken demorou para achar como tirar partido do Scrum nessa situação.
Este livro é de 2004 o que significa que depois disso houve tempo para outros desenvolvimentos.
Além disso o Ken sempre fala que Scrum para ele é a arte do possivel. Isto significa que as tecnicas scrum têm que ser dobradas para se encaixarem nos casos e é isso que o livro todo mostra. A citação é de um apendendice. Leia o livro completo para entender que ha um jogo de cintura associado ao scrum, especialmente fora da zona de conforto : ou seja, fora da teoria, que é o dia a dia das pessoas.
Além disso, embora o Ken tenha sido um dos percursores do Scrum , existem muitas outras pessoas trabalhando nele e com ele. Nesse aspeto as referencias que tenho do Ken são meio atrazas. Você não vê ele falar de fator de foco , por exemplo.

Scrum é uma coisa nova, e ainda ha trabalho sendo desenvolvido. Um outro apendice mostra como Scrum foi adaptado para poder ser compativel com CMMI. É por isso que existe a certificação de scrum master e PO.
O que quero mostrar com isto é que vc não vai encontrar um livro explicando a teoria do scrum com um monte de formulas e peseudo suporte intelectual. Scrum é baseado em pragmatismo empirico que é uma forma totalmente diferente de pensar e atuar. O conceito de definir e aceitar valores antes de tudo o resto supracede qualquer matemática e qualquer hierarquia.

Uma tenica não é válida apenas se existe um livro que a descreva. Ela é válida se ela traz resultados. Se muitas pessoas a usam e a estudam ela começa a aparecer nos livros. Se vocês querem esperar por livros falando o mesmo que estou dizendo o atrazo é vosso. Mas se vocês querem ler os livros de agora e entender o caminho das pedras, ha muita coisa para ler. Começando com
Software Estimation: Demystifying the black art que faz uma abordagem clássica e moderna (agil) do problema de estimar, seguido de Agile Estimating and Planning que demonstra como se fazem estimativas ageis. Este livro não é sobre Scrum especificamente,mas sobre agil em geram. Como a mecanica dos SP e sprints é mais ou menos universal em agil muitas coisas podem ser transferidas diretamente.

O que quero que fique claro é que :

1. não fui eu que inventei nada. Está tudo nos livros , na web e nas palestras das pessoas que entendem do assunto e tem experiencia. Eu apenas aglutinei as informações de várias fontes e da minha propria experiencia.
2. É possivel estimar em agil sim. Existem livros e pessoas versadas nesse assunto. É óbvio porquê. Sem estimativas é impossivel fazer negócios. Portanto esse papo de “nunca vi” , “me mostra provas” é comversa de pessoas perguiçosas e desinformadas. Não custa nada usar o google para procurar. Tem até no youtube. E um ida à bibloteca ou uma livraria especializada tb não mata ninguem.
3. Se é possivel estimar em agil, e Scrum é agil, então é possivel estimar em Scrum. Isto tem que ficar muito claro. Mas muito mesmo. Independentemente do que vcs acham que é verdade, a realidade é que a mecanica do Scrum se baseia em estar sempre estimando. Isto é um processo comum a todas as tecnicas de gerenciamento (acontece apenas que os gerentes tradicionais se esquecem disso) e a mecanica de sprints e logs permite que isto seja feito muito facilmente a todo o momento. Se vc já praticou scrum, se vc já viu um burdown chart , de vc já teve que justificar o uso de scrum, vc sabe que é real porque vc já teve que usar. Se vc não usou , se não teve contato com isso, e quer apenas entender as coisas conceptualmente e através dos livros, ok. Mas não me venha dizer que scrum é assim ou é assado se vc nem nunca experimentou. Parece aquelas crianças dizendo que não gostam de comer hortaliça sem nunca terem experimentado. Isso é birra. Não é nem um pouco profissional.
4. A minha intenção não é vos convencer que existem formas de estimar usando agil e scrum. A minha intenção é mostrar que existem formas de estimar sim. Que existe muita gente versada nisso e que existe muita informação para ser estudada sobre isso. Não é material de faculdade, todo resumido e bem delineado, é material real, do mundo real, onde vc tem que ler tudo, tirar conclusões, confrontar com os autores dizem e com a prática. Enfim, é mostrar que o argumento 'Scrum não tem formas de estimar" é falso. E isto é fato. Não é uma questão de opinião. A terra gira em torno do sol, isso é fato, mas isso não impde que muita gente ache o contrário. Vocês são livres de achar o contrário, mas não são livres de dispersar mentiras. E isso que estou tentando evitar. Que mais um mentira seja dispersada.

O mundo de desenvolvimento de software sempre foi orfão de uma teoria administrativa cientifica e concreta que se mostrasse válida e util para gerenciar projetos. Lean e Scrum trouxeram isso adotando uma postura empirica em vez de dedutiva e porque é baseado em ciencia verdadeira é uma postura que funciona. Mas como toda a ciencia , ela tem que vencer dogmas e conceitos que historicamente são usados sem justificação. Junte-se a isso o fato de Agil ser baseado em valores - que são coisas morais e não podem ser ensinados - e vc tem uma mistura explosiva. Ou vc odeia scrum ou vc ama scrum. Se vc já usou, vc concerteza ama ou odeia. E isso é porque ele vai diretamente onde doi. Se vc não for um profissional vc não aguenta. A minha sensação é que o Scrum recebe muito desdem porque as pessoas ou têm medo do que ele representa, ou tem preguiça de usar , ou não têm capacidade de o entender embora tenha boas intenções. O livro citado do ken demonstra isso muito bem. E é isso que vejo aqui tb. O meu alerta é apenas para que procurem se informar melhor e saibam crivar o que leêm.

Esse argumento é fraco. RUP tb não foi criado para serem usados pontos de função ou pontos de caso de uso. E mesmo assim as pessoas usam RUP e Pontos de Função juntos.

Não sei onde vc acha que isso contradiz o que eu disse. O backlog sim tem que ser estimado e priorizado. E ha várias tecnicas
para como priorizar o backlog. E sim, essas tecnicas são fora do scrum porque o scrum não vai nesse detalhes ele simplesmente diz: O PO tem que priorizar.
O PO tem que ser virar. O Scrum tb não diz “Equipa estimem usando planning poker” mas é a tecnicas que dá mais certo.
Scrum nunca lhe diz como vc tem que fazer algo, apenas o quê tem que ser feito, quando , porquê e por quem.
É por isso que não fala na metodologia Scrum e sim no processo Scrum

Não. Não teria. Esse é o erro de quem ainda pensa do modo tradicional.

Vc tem que entender que ha duas entidades aqui: O projeto e o software. O projeto e o produto.
VC tem um projeto guiado por uma equipa constituida para realizar um produto. Produto e projeto são coisas separadas.
O product backlog diz respeito ao produto e ele é usado como ferramenta para o projeto. Ele não é o projeto, ele é o produto.

Tome atenção : as estorias do product backlog (PB) dizem respeito ao produto. Todas elas tem tamanhos e por portanto o PB tem um tamanho.
No instante zero o PB tem um tamanho. Uma semana depois tem outro, etc… o tamanho do PB vai mudando no tempo porque :

1. As estorias vão sendo implementadas. Isso diminui o tamanho do PB.
2. AS estorias vão sendo reorganizadas. Divididas ou fundidas: isso alterar o tamanho
3. novas estorias são introduzidas. Isso altera o tamanho.

O tamanho do PB é alterado, mas isso apenas significa que o tamanho do software é alterado. O escopo do software é alterado.
O do projeto não.

Como é isso possivel ? Porque o tamanho do projeto não é o do backlog.
Acho que não prestou atenção no que escrevi no outro post. Vc usa o backlog do software para estimar o tamanho do projeto.
Estimar! Vc joga com um numero base de SP e coloca fatores nele. Os mesmo que vc colocaria numa outra estimativa qq. Riscos, Equipa, Equipamentos, Ambiente, etc…
Uma vez chegado num numero esse numero pertence ao Projeto, não ao software. è por isso que vc pode contratar X SP por Y reais.
Esse X inclui pelo menos um release oficial de X pontos ou menos. ( ou menos, não mais).

Se depois desses X pontos, ainda houver no backlog do software muitas features que valem a pean vc faz outro contrato por mais Z pontos. E assim vai.

Essa coisa que fazer projeto = software é o jeito tradicional e tosco de entender um projeto de software. O projeto de software começa antes do software estar pronto e acaba depois dele estar pronto.
Afinal a distribuição não faz parte da criação, mas faz parte do projeto.

Não ha contradição entre o backlog ser dinamico e o projeto ser constante.

Se o numeto é constante ele pode ser estimado. Tão simples quanto isso. Quer vc acredite ou não.

Tambem estou com o Guerra, cansei…

Só nao venha enganar os outros com falacias de meu ingles é ruim, a discussao aqui é sobre estimar e texto que voce citou nada fala disto, mass por acaso do destino voce mesmo deu um tiro no proprio pé e acabou com a discussão quando postou a referencia, e todos ja viram, não ha mais o que falar.

Mas enfim cansei.

"Errar é humano, persistir no erro é BURRICE!!"
Humildade

Acrescente essas duas na tua vida e sera mais feliz!

Se o que negociamos na primeira reunião (Sergio, na primeira reunião) é o projeto, e o escopo vai sendo amadurecido durante as reuniões de levantamento (o Alexandre e o Guerra destacaram bem), então o cliente está comprando um projeto que poderá variar grandemente no quesito funcionalidades (assumindo como regra que o prazo final não muda).
Pior, porque irá variar em função da expertize da equipe. Times mais experientes conseguem entregar mais “coisas” implementadas em SPRINTs, Ou seja, depois de contratada a empresa que irá fazer o serviço, só deus sabe o que será entregue no prazo. Pode atender plenamente, mas pode se extender por mais tempo, ao longo dos SPRINTs. Se o cliente decidir pagar mais para continuar o projeto, porque percebe a evolução, o projeto continua.

Bem, neste momento, acho que devo destacar que já presenciei muitas negociações iniciais de projetos, para várias empresas de vários segmentos, e ao menos na minha vivência, digo que o comportamento apresentado pelos negociadores do projeto diz que :
"NÂO È ASSIM QUE FUNCIONA!!!"
O Cliente deseja saber antes de começar quanto vai custar (ele nem sabe o que é Sprint), e deseja tudo o que têm em mente.
Em uma licitação a coisa é pior ainda.
As consultorias costumam preparar documentos de pré-projeto ou documentos de Visão, com várias cláusulas que indicam o que “não é escopo do projeto”, de forma a eliminar possíveis problemas futuros.

Com frequência acontecem realocações de pessoas dentro da empresa, e o sponsor do cliente pode mudar. Se não há documentos muito formais que indicam o que foi combinado e como seria implementado, problemas acontecem.São raros os projetos onde um mesmo time de pessoas (cliente e consultoria) trabalham desde o início até o final.

Ainda, todas as fases de maturação que foram propostas pelas metodologias durante vinte anos, e artefatos que representam os vários aspectos do desenvolvimento (análise estática - diagramas de classes, análises dinâmicas - sequências, estados). São doze artefatos definidos pela UML. Isto tudo deve ter sido um grande devaneio destes loucos, entre eles Jacobon, Booch e Rumbaugh, já que tudo foi reduzido a um conjunto de discussões e anotações em um papel de pão. Acho esta visão até um desrespeito ao que foi criado.

Quem já gerenciou equipes sabe que existem profissionais de mais alto nível, que têm a capacidade de desenhar o projeto em um nível mais alto, utilizando UML por exemplo, e programadores muito bons, mas que não conseguem ter uma visão de mais alto nível do projeto. São raros, mas muito raros mesmo, os que conseguem conversar com o usuário, entender a demanda, rabiscar em um papel o desenho de como vai ficar, de uma forma que o usuário entenda, ter força de persuasão, montar mentalmente quais são os patterns que serão utilizados e ainda sentar e codificar. Este processo demanda tempo de maturação, é a forma como o cérebro humano funciona. Aposto que todos nós já tivemos situações onde mais de 80% do código estava pronto, quando dá um estalo no chuveiro pela manhã, com uma idéia que revoluciona o projeto, mas o que foi feito precisa ser reescrito. Como se lida com isto ?

Vou lembrar uma historinha para vocÊs :
Quando o ASP foi criado (verdade que o PHP surgiu primeiro, mas o usado extensamente foi o ASP), as tecnolgias que dominavam eram programáticas. Perl, CGI, todas elas você tinha que codificar o HTML dentro do código. Era muito difícil. Quando o ASP popularizou, gerou um sucesso monumental. Era fácil criar páginas, tinha uma produtividade dezenas de vezes maior do que as tecnologias anteriores. A prototipação era visual. O que aconteceu depois de alguns anos ?
Se verificou que fazia o programador tender a criar vários códigos, dava pouca manutenção e os projetos travavam. Eu mesmo participei de projetos (graças a deus não programei em ASP) onde se chegou em uma situação que não era mais possível evoluir. Somente depois do fracasso se amadureceu para o modelo MVC para WEb, com Servlets e JSPs, dividindo visual e códigos. Até a própria Microsft modificou seu modelo de construção. Isto levou mais de 5 anos para fracassar.

Resumindo, o SCRUM como conhecemos hoje ainda é muito novo, e portanto existe pouca jurisprudência para sabermos se o modelo se sustenta no futuro. Tenho medo de daqui a alguns anos (e agora ninguém ainda pode afirmar nada nem a favor nem contra) as pessoas sentirem saudades daqueles montes de documentação, com milhares de códigos na mão e meia dúzia de papeis de pão. Torço para que isto não aconteça, e é por isto que disse no meu primeiro email : as pessoas estão ignorando completamente o passado e criando novos modelos. Quem das pessoas da velha guarda (que têm experiência) se rendeu a estas novas metodologias ?

[]s
Glauco Reis

[momento-viagem]
Tenho uma teoria viajante - sinceramente acho que o cliente só sabe que ele precisa de um sistema, mas não tem a menor idéia do que automatizar. E nós, bons programadores que somos implementamos o que eles nem sabem direito. Se nós invertessemos o papel, por exemplo - ao invés de querermos o cliente próximo de nós para entendermos o problema dele, que tal enviarmos o especialista em TI para junto deles?

Que tal o seguinte rótulo para a sua consultoria: “Contrate nossa consultoria e colocaremos dois profissionais de TI dentro de sua empresa para fazer um estágio e usar seus fortes conhecimentos em computação para identificar todos os pontos passíveis de automação.”

Hoje mais parece que o cliente é quem tem que entrar no nosso mundo, quando na verdade deveria ser o contrário.[/momento-viagem]

Tambem estou com o Guerra, cansei…

Só nao venha enganar os outros com falacias de meu ingles é ruim, a discussao aqui é sobre estimar e texto que voce citou nada fala disto, mass por acaso do destino voce mesmo deu um tiro no proprio pé e acabou com a discussão quando postou a referencia, e todos ja viram, não ha mais o que falar.

Mas enfim cansei.

"Errar é humano, persistir no erro é BURRICE!!"
Humildade

Acrescente essas duas na tua vida e sera mais feliz!

Vamos ter base para continuar a conversa, ninguém esta aqui pra ficar sustentando suas ideias , fale de um autor, coloque uma referencia seja mais objetivo.

Acho que morreu mesmo!

Acredito que existe um ponto de vista mais particular do que algo que seja melhor experimental ou convincente, estamos diante de um paradigma ou não estamos aceitando outras informações com melhor receptividade.

Tambem estou com o Guerra, cansei…

Só nao venha enganar os outros com falacias de meu ingles é ruim, a discussao aqui é sobre estimar e texto que voce citou nada fala disto, mass por acaso do destino voce mesmo deu um tiro no proprio pé e acabou com a discussão quando postou a referencia, e todos ja viram, não ha mais o que falar.

Mas enfim cansei.

"Errar é humano, persistir no erro é BURRICE!!"
Humildade

Acrescente essas duas na tua vida e sera mais feliz!

Vamos ter base para continuar a conversa, ninguém esta aqui pra ficar sustentando suas ideias , fale de um autor, coloque uma referencia seja mais objetivo.
:shock: :shock: :shock: Duran???
A UNICA referencia postada foi um tiro no pé, de resto só sobram ideias e opniões próprias, por favor volte a pagina 1 e comece a ler novamente.

E não estou continuando nada, ja foi, The End, That’s All folks, finish.

O que me atraiu e me fez escrever um artigo nesse formato é que ele faz as pessoas refletirem para tomar uma decisão e não simplesmente lerem para absorver a informação, muitas vezes sem raciocinar em cima do que está sendo falado. É neste “ficar na dúvida” que realmente você acabou adquirindo uma visão mais crítica dos padrões.

Sim, isto foi muito legal. Tanto que depois sequi os outros caminhos, pra ter certeza do porquê que as outras solução não eram tão boas, quais os problemas delas, e as causas posteriores. Nota 10 o artigo.

Thiago Senna:

[momento-viagem]
Tenho uma teoria viajante - sinceramente acho que o cliente só sabe que ele precisa de um sistema, mas não tem a menor idéia do que automatizar. E nós, bons programadores que somos implementamos o que eles nem sabem direito. Se nós invertessemos o papel, por exemplo - ao invés de querermos o cliente próximo de nós para entendermos o problema dele, que tal enviarmos o especialista em TI para junto deles?

Que tal o seguinte rótulo para a sua consultoria: “Contrate nossa consultoria e colocaremos dois profissionais de TI dentro de sua empresa para fazer um estágio e usar seus fortes conhecimentos em computação para identificar todos os pontos passíveis de automação.”

Hoje mais parece que o cliente é quem tem que entrar no nosso mundo, quando na verdade deveria ser o contrário.[/momento-viagem]

Não que va fazer estagio, mas sempre que fiz meus sisteminhas próprios, eu sempre fui na empresa do cliente, ver como é feito todo o processo manualmente para entender como a coisa funciona, a partir dai faço minhas anotações e a vou pro escritorio, precisando eu volto la no cliente, sempre fiz assim. Acho importante ver o processo sendo feito manualmente.

Vocês querem que Scrum possa estimar projetos tradicionais ? É isso ? Vcs estão loucos ?
Scrum só pode estimar projetos feitos com Scrum!

Vejamos passo a passo as diferenças:

glaucoreis:

Se o que negociamos na primeira reunião (Sergio, na primeira reunião) é o projeto,

Já começa mal.
Em scrum existem várias reuniões - as que forem necessárias - para que se determine o product backlog inicial.
Isto é feito da primeira reunião se o PO é experiente e o representante do cliente sabe do assunto, mas pode ser mais do que uma.
Geralmente é mais do que uma porque o representante não sabe tudo. Esta fase é semelhante à escrita de um documento de visão pois o Product backlog (PB) é exactamente isso, neste momento. Eu disse, neste momento.

O que se negocia na primeira reunião não é o projeto. Na primeira reunião não se negocia nada. É uma conversa para levantar o propósito do software.

Depois que o PO está satisfeito com PB a bola passa para o outro lado…

Sim, reuniões de levantamento. Essas reuniões levam ao Product Backlog. Mas em nenhuma ha negociação de nada. É recolha de informação. (A menos é claro, que a empresa cobre por esse levantamento.)

O cliente está comprando a implementação de um software. ele não está comprando projetos. É a software house (SH) que cria e gerencia o projeto, porque ele é um caminho para a implementação do software. O cliente está pagando pela criação do software, não pela gerencia do projeto. As funcionalidades que o cliente quer podem mudar a cada reunião com o PO, o ponto é que chegado em um ponto o PO vai interromper a visita ao cliente e visitar a equipa para se preparar para responder ao cliente na proxima reunião.

O que o PO pede à equipa é a estimativa das funcionalidades. Isto é equivalente ao gerente pedir que os desenvolvedores estimem o projeto. Apenas a forma como é feito muda. O objetivo é o mesmo : estimar.

A equipa faz um planning poker ou outra tecnica e chega em numeros. E chega tb numa lista de perguntas para o PO e uma lista de riscos.

Esta estimativa é independente do prazo. São as funcionalidades que estão sendo estimadas. Não o projeto.

Isso não é Scrum. Scrum é determinista. A todo o momento é possivel saber o que vai ser entregue e o que não vai. Mais do que isso acontece uma entrega no fim de cada sprint e não apenas uma no final do projeto. O cliente pode começar a mexer com o software no fim do primeiro sprint.

A duração dos sprints e o numero de sprint até à entrega é fixo. Se não é fixo,não é scrum.
portanto ao longo do periodo de desenvolvimento é verdade que mais features entram no PB tudo é reistimado e tudo é re-priorizado, mas isso não muda uma virgula na quantidade e duração dos sprints.

aquilo que a equipa consegue entregar é sim proporcional à sua experiencia e sim cada equipa tem uma velocidade diferente , ou seja, entrega um numero de pontos diferente. Algumas equipas entram em estado de hiper-produtivdade que significa que a velocidade delas é maior do que seria “temporalmente” possivel. Isto é muito obvio se usar dias ideias como medida de SP.

Repare que em scrum a equipa estima e a equipa faz. O que ela estima é baseado nos mesmos espertise que ela usa para fazer.
é bem diferente do tradicional em quem o funcional espirra um numero calculado e os desenvolvedores sofrem para se encaixar nesse numero. A estimativa scrum não é apenas um numero, é um compromisso.

Pois não funciona. Metodos tradiiconais não funcionam. Existem N autores explicando porquê.
Agora, quantas reuniões dessas que vc assistiu eram de projetos Scrum ? quantos desses projetos scrum eram realmente scrum ?
Na minha vivencia vejo muitas empresas acertarem preços na primeiro reunião. Isso é simplesmente idiota. Empresas que sabem fazer direito não fazem isso.

“começar” é relativo. Em scrum o desenvolvimento começa depois que o projeto foi estimado, avaliada e assinado.
Depois que o PO tem o PB estimado pela equipa ele volta ao cliente e discute os prazos e os custos. O PO precisa entender se está perante um projeto de custo fixo ou de prazo fixo. Conforme isso ele negocia. Não ha preço inicial sem saber o que o cliente quer.
Depois que ha essa conversa o PO faz umas contas simples e dá prazos e custos. O conrato é feito baseado no PB neste momento. ele está estimado em SP e está priorizado. O contrato conta com custos e prazos e com clausulas que colocam o cliente consciente de que está inserido num processo Scrum. São dados poderes ( como adicionar featues no backlog) e são retirados poderes (como alterar prazos). ou ele concorda ou não.

Na prática , uma empresa usando Scrum tem que evangelizar muito como parte do proceso. Mas é algo que se paga a longo prazo.
Na prática tb, a empresa tem que se proteger do cliente porque ele tende a querer paraticar acções tradicionais que vão contra o scrum. O SM e PO tem esta responsabilidade de educar o cliente e proteger a empresa. às vezes eles tb têm que educar a empresa e ai fica complicado. Complicado, não impossivel. Scrum é muito usado in house porque neste cenário não ha clientes na historia, mas sempre existem stakeholders , sejam clientes ou não, e a responsabilidade do PO perante eles é sempre a mesma.

Nada impede isso em scrum. Nada impede que vc coloque o PB num excel e anexo num documento do contrato.

Isso não é scrum. o PO não pode mudar. O SM sim. A equipe sim.
Aliás existem tecnicas para isso.

Contratos são sobre compromissos entre empresas, não entre pessoas.
Contrato é sempre formal. É idiota pensar em fazer software on demand sem contrato.
O ponto é que o contrato não tem que ser assinado no primeiro dia, nem precisa ser um monte de conversa fiada.
Ele pode ser um instrumento de educação e de proteção do scrum.

No fim o cliente só pensa uma coisa : entra dinheiro, sai software. Isto o scrum faz direito. Com sprints de um mês a cada pagamento da parcela do cliente sai uma versão do software. isto os clientes adoram porque eles veêm o dinheiro ser convertido em “coisa”. E mais, eles adoram poder mudar de ideias. Com scrum eles podem. em contratos normais não.

Se vc usa 12 artefactos UML para cada classe, andar, nodo e decisão do projeto a escolha é sua.
Em Scrum vc pode fazer a mesma coisa. Só que esses documentos vão estar prontos no fim.
Em scrum a definição de “pronto” é aberta. Se a sua definição inclui 12 artefactos UML, que seja. So que isso vai
1: aumentar o numero de SP por estoria - a menos que a equipa aumente, o que é ruim
2: vai entregar menos funcionalidades por spritn - o que é ruim, porque alarga o projeto.

Em scrum ninguem proibe vc de usar uml e escrever documentos no word ou no excell. o que scrum proibe é que isso não seja contabilizado. Tem que ser contabilizado. A resposta a “Qual o tamanho em SP de um webservice de login?” depende do conceito de pronto. Se o conceito é : implementado, testado e documentado no manual do usuário, vc tem X pontos. Se é: 12 artefactos de uml, implementado, testado e manual do usuario é Y. Claro que Y > X para uma mesma equipa.

Dizer que scrum é um decrespeito ao pessoal da UML é simplesmente um falso argumento. Primeiro que UML não é documentação, nem é implementação. Segundo que usar scrum não impede usar UML.

Vc está confundindo as coisas. Mostrando que realmente não sabe o que é Scrum. Em scrum os desenvolvedores não falam com o cliente. quem faz isso é o PO e o SM. A equipa é auto-gerenciável com impedimentos sendo removidos pelo SM. Pessoas com formas diferentes de pensar podem trabalhar juntas se lhes for dado o poder de se auto-organizarem. O problema só nasce quando um gerente quer se meter no meio. PO não têm que entender de sistemas nem desenvolvedores de negocio. é para isso que serve o SM,para fazer a ponte. O que tem que acontecer é que o PO confia nos desenvolvedores e vice-versa. Se os desenvolvedores dizem não, é não. Se eles dizem 10 é 10. Comprometimento é o valor mais alto no scrum e ele que mata todos esses problemas que falou.

Isso é mencionado na reunião de daily scrum nessa mesma manhã. se os outros membros da equipa concordarem que realmente vale a pena, o problema é levado pelo SM para o backlog. A equipa estima essa alteração. Na proxima reunião de sprint o PO prioriza essa estoria tecnica. Muito provavelmente ele não vai priorizá-la muito alto. Aqui tudo depende do problema.Se for um problema visivel para o PO que afeta o software ele vai priorizar alto. se for alguma mania do desenvolvedor ele prioriza baixo.
mas pode acontecer que a ideia que o cara teve é relevante apenas em relação a como as coisas estão sendo feitas no codigo. usar um factory em vez de um singleton, usar jms em vez de webservices… algo assim muito particular da implementação morre na daily scrum. É um ajsute de rota da propria equipa de desenvolvimento e não do software como um todo. O SM é essencial para arbitrar a diferença entre uma situação e outra.

Não é culpa do scrum ser bom e as pessas serem atrazados mentais.
Scrum e agil em geral oferece solução para todos os problemas que mencionou. Quem sabe dos problemas e entende agil sabe mudar. Quem não quer ou não sabe fica nessa ilusão que scrum é mais uma coisa do monte.

O ponto é muito simples : ou vc conduz um projeto em scrum ou vc não conduz em scrum. Não ha meio termo.
Se vc conduz vc onsegue estimar. Consegue mais do que isso. Consegue o comprometimento da equipa e do cliente para com o software. E é isso que realmente importa e é isso que realmente está faltando.

Clientes querem software e pagam por software. Software Houses querem projetos e cobram por projetos.
Confundir software e projeto é o erro da metodologias tradicionais. qualquer pessoa com mais de 5 anos no mercado sabe que as metodologias tradicionais não funcionam, são stressantes e fazem as SH perder dinheiro. E sabem tb que as empresas não veêm isso.

Vocês que acham que scrum não permite estimativas ainda estão pensando tradicionalmente, ou seja, o que vc querem dizer é que :“Scrum não oferece as estimativas que estou acustomado a ver”. Pois não. Mas isso não significa que ele não ofereça.

Não se pode esperar que um processo agil funcione da mesma forma que um tradicional. Isso é absurdo. Se fosse assim não seria ágil. Fica patente nos vosso discursos que vcs não sabem relamente o que significa Scrum ou agil. Confundem agil com um monte de interações.

Agil é mais determinista do que vcs acham. Leiam o Agile Estimation and Planing se não entendem porquê.

Ha uma analogia que eu gosto muito mas a maioria não vai entender ,mas aqui fica:
metodos tradiconais são como a fisica classica. Chega-se numa conclusão conhecendo todos os passos do processo. Os resultados são bons mas limitados e não explicam certos fenómenos. metodos ageis são como a fisica quantica. Chega-se numa conclusão sem saber todos os passos. Os resultados são melhores e todos os fenomenos são explicados. Agilidade sobre do mesmo problema que a fisica quantica no inicio do seculo passado. Muitas pessoas não entendem porque não conseguem pensar de forma abstrata sem conhecer todos os passos. Mas isso é limitação das pessoas, não das ideias e conceitos da teoria.

E você tem tido sucesso implementando assim? Pq eu aposto pelo menos nessa idéia!

Veja, sistemas corporativos são sistemas mais complexos que “sisteminhas” e os profissionais de TI se contentam com User Stories e Casos de Uso sem ir colocar a mão na massa pessoalmente. UML, User Stories, Casos de Uso entre outros, na prática, não passam de ferramentas de adivinhação.

E você tem tido sucesso implementando assim? Pq eu aposto pelo menos nessa idéia!

Veja, sistemas corporativos são sistemas mais complexos que “sisteminhas” e os profissionais de TI se contentam com User Stories e Casos de Uso sem ir colocar a mão na massa pessoalmente. UML, User Stories, Casos de Uso entre outros, na prática, não passam de ferramentas de adivinhação.

Sim, no meu caso sempre foi bom. Não posso dizer nada sobre os corporativos, mas eu tambem acredito que ficaria muito mais claro o que o cliente realmente precisa, porque todos sabemos que o cliente só sabe que quer alguma coisa, ficar tentando ouvir da boca dele o que realmente quer é complicado, é muito mais produtivo voce ir la pessoalmente e ver de fato o funcionamento da coisa.

Hoje na empresa que trabalho uma das coisas que faço é dar suporte remoto para nossos usuarios, quando o usuario me liga e começa a falar o que ta errado ou o que quer, eu ja corto logo a conversa e peço logo o IP da maquina dele para eu ver pessoalmente qual o problema, acredite, tu nao sabe o tempo que ganho fazendo isto, o usuario nao sabe se expressar, é muito melhor eu ir ver do que que fica tentando advinhar, acho que o mesmo seria valido para desenvolvimento de software.

fredferrao:

Hoje na empresa que trabalho uma das coisas que faço é dar suporte remoto para nossos usuarios, quando o usuario me liga e começa a falar o que ta errado ou o que quer, eu ja corto logo a conversa e peço logo o IP da maquina dele para eu ver pessoalmente qual o problema, acredite, tu nao sabe o tempo que ganho fazendo isto, o usuario nao sabe se expressar, é muito melhor eu ir ver do que que fica tentando advinhar, acho que o mesmo seria valido para desenvolvimento de software.

Exatamente por isso os processos modernos , como scrum, incluem demonstrações ao cliente. Isto ajuda a que ele veja com os olhos da cara o software funcionando e que haja discussão com base em algo concreto. Além disso isto serve de treinamento para quando o cliente virar usuário. É sem duvida util ter poucos intermediários e é por isso que em Scrum se fala em Porcos e Galinhas.

sergiotaborda:

fredferrao:

Hoje na empresa que trabalho uma das coisas que faço é dar suporte remoto para nossos usuarios, quando o usuario me liga e começa a falar o que ta errado ou o que quer, eu ja corto logo a conversa e peço logo o IP da maquina dele para eu ver pessoalmente qual o problema, acredite, tu nao sabe o tempo que ganho fazendo isto, o usuario nao sabe se expressar, é muito melhor eu ir ver do que que fica tentando advinhar, acho que o mesmo seria valido para desenvolvimento de software.

Exatamente por isso os processos modernos , como scrum, incluem demonstrações ao cliente. Isto ajuda a que ele veja com os olhos da cara o software funcionando e que haja discussão com base em algo concreto. Além disso isto serve de treinamento para quando o cliente virar usuário. É sem duvida util ter poucos intermediários e é por isso que em Scrum se fala em Porcos e Galinhas.

Sim eu entendeo seu ponto, mas veja que continuam sendo historias contadas por alguem para alguem e sabemos que o entendimento é sempre complicado, voce citou o scrum, ótimo sempre ha as reuniões, e o cara vai la ver as releases, mas e o tempo que ja se gastou no sprint e no fim o cliente fala que nao era aquilo? Mas eu entendi, no scrum o produto vai se adaptando dinamicamente/iterativamente, mas concorca que houve perda de tempo e dinheiro que eu poderia ter impedido se tivesse algo mais concreto na mão?

Eu vejo os seguintes pontos:

1 - O cliente não sabe falar direito o que quer, nao sabe se expressar;

2 - Alem do cliente não se expressar direito, o analista entende ainda de outra forma;

Bom só aqui ja temos A, B e C, sendo o que o cliente queria, o que ele explicou e o que o analista entendeu.

Então como seria simples se fossem cliente e analista la olhar o processo como ele realmente é.

Uma imagem diz tudo:

Ai que esta a diferença. em agil não apenas um conto. è um compromisso. Portanto todo o mundo tem que estar consciente e concorda com o é para fazer. Se o PO ( não o cliente) diz faz X e depois de arrepende o problema é dele. Ele que gastou Y SP para uma coisa errada. Se vc usa scrum direito e o PO faz isto muitas vezes o SM vai apertá-lo. Ele passa a ser um impedimento ao projeto e o SM tem poder de pedir a demissão do PO se ele não se indireitar. Entenda que o PO controla o software, o SM controla o processo. Se alguem impede o processo essa pessoa é avisada, é treinada, se mesmo assim não der, é removida. Simples assim.

O problema atualmente é que ninguem tem poder de remover o gerente excepto os diretores. Mas como é uma hirarquia não ha ninguem que audite o gerente e reporte ao diretor. O desenvolvedor não pode chamar a atenção do diretor para a incompetencia do gerente. Em scrum não só ele pode chamar a atenção do SM, como o SM pode chamar a atenção dos diretores.

As reuniões servem o proposito exacto das pessoas se entenderem. Não ha margem para falhas desse tipo. Algum detalhe pode não ficar bom, mas a funcionalidade é aquela, porque foi discutida entre todos. Em Scrum não ha ordens, ha necessidade e consenso de como resolver.

Não. Não concordo. É impossivel vc ter um processo que impede erros. O que pode ter é contigência de minimizar os problemas criados por esses erros. O PO pode errar. Ele só não pode errar sempre. Ele é um profissional. Espera-se que aprenda com erros ou é demitido. O dinheiro jogado fora é sim um problema e por isso o PO é despedido se isso for muito problemático.
É essa a diferença para o gerente tradicional que erra constantemente mas nada lhe acontece, o que permite que continue errando.

Sim, as pessoas não se sabem expressar direito. Vemos isso todos os dias aqui no guj, mas isso não impede que se façam bons software. Existem boas práticas tb para levantar requisitos. Por exemplo , desconfie sempre que o cliente usar as palavras “sempre” e “nunca”. E existem Padrões de Requisito que permitem que quando o cliente pede uma coisa, vc desconfie que ele está pedindo mais um conjunto de N coisas.Se vc só coloca o que ele pediu vc vai se ferrar, mas se vc sabe das N coisas vc repassa uma a uma.
As que ele quiser, coloque. Por exemplo : “o sistema tem que ter login” -> “a senha tem que ser encriptada ?” ,“como muda a senha?” , “como faz se esquecer a senha?” De 1 estoria vc adiciona 4 no backlog.

Analisando a figurinha que o FredFerrao postou, talvez, o último quadro foi tão bem colocado que o texto foi “o que o cliente realmente precisava” e não “o que o cliente queria”. O que o cliente precisa não é exatamente o que ele quer. Uma vez que você apenas confia nas reuniões e relato de cliente você só tenta adivinhar o que ele quer.

Eu não vejo outra forma de você saber o que ele realmente precisa se você não for o próprio usuário com bons conhecimentos em “como automatizar” o trabalho.

olhando a sinopse parece que esta edição ta meio fraquinha…

Thiago Senna:

Eu não vejo outra forma de você saber o que ele realmente precisa se você não for o próprio usuário com bons conhecimentos em “como automatizar” o trabalho.

Um levantamento correto de requisitos é feito junto aos stakeholders. Quem são estes ?
São todos aqueles cujas opiniões podem mudar o rumo do projeto e/ou afetar a aceitação do software.

Sempre é aconcelhando vc ouvir o usuário. Porque muitas vezes (aka sempre) o cliente acha que os usuários precisam de tal coisa,mas os usuários odeiam essa coisa. Pesquisa de mercado é exatamente isto. È por isso que o Google a Microsoft e outros incluem nos seus software mecanismo de estatistica de uso. Isto indica o que pegou e o que não pegou.

O cliente nunca sabe o que quer e nunca tem razão.

Olá Luis!

Que tipo de coisas você gostaria de ver na revista? Diga o que não gostou na edição! Por que assuntos você se interessaria?

Este tipo de feedback é importante para estarmos fazendo uma revista cada vez melhor!

Saudações!

sergiotaborda:

Um levantamento correto de requisitos é feito junto aos stakeholders. Quem são estes ?
São todos aqueles cujas opiniões podem mudar o rumo do projeto e/ou afetar a aceitação do software.

Hmm. “Leventamento correto de requisitos” chega a doer no meu ouvido. Requisitos ou vc sabe quais são ou então levanta pra ir embora pra casa porque um projeto que tem como fase “levantar requisitos” não vai a lugar nenhum.

Não existe levantamento de requisitos em projetos de software, é apenas uma aberração inventada na época dos analistas de sistema, antes da existencia de domain experts (ainda existem lugares onde se usa o papel de analista de sistema, nesses lugares defasados talvez levantamento de requisitos ainda seja utilizado).

Olá Luis!

Que tipo de coisas você gostaria de ver na revista? Diga o que não gostou na edição! Por que assuntos você se interessaria?

Este tipo de feedback é importante para estarmos fazendo uma revista cada vez melhor!

Saudações!
Uma coisa que acho que poderia ser valida é ensinar o consultor java a saber pesquisar assuntos e como decidi-los a estudar, fica muito complexo pegar a revista e ver soluções sem ao menos a pessoa saber porque deve-se usar isso ou aquilo, a revista esta indo no caminho para esse entendimento quando colocou no"Artigo 38 -Boas Práticas Java EE", ao Tema Acerte na sua escolha, mas ainda percebo que falta melhor direcionar os assuntos sobre obras e escritores, claro que isso é um grande desafio, mas acredito que possa mesmo a ter uma real colaboração sobre esse ponto de vista, por onde se deve mapear resultados sobre desenvolvimento e implementações com soluções em tecnologias, levar ao leitor a auto critica e elevar seu grau intelectual de conhecimento.

mochuara:

sergiotaborda:

Um levantamento correto de requisitos é feito junto aos stakeholders. Quem são estes ?
São todos aqueles cujas opiniões podem mudar o rumo do projeto e/ou afetar a aceitação do software.

Hmm. “Leventamento correto de requisitos” chega a doer no meu ouvido. Requisitos ou vc sabe quais são ou então levanta pra ir embora pra casa porque um projeto que tem como fase “levantar requisitos” não vai a lugar nenhum.

Não existe levantamento de requisitos em projetos de software, é apenas uma aberração inventada na época dos analistas de sistema, antes da existencia de domain experts (ainda existem lugares onde se usa o papel de analista de sistema, nesses lugares defasados talvez levantamento de requisitos ainda seja utilizado).

:shock: As coisas que temos que ler por aqui …

Ok. vc não levanta requistos nenhuns. como vc sabe o que cliente quer ?
Vc é daqueles que ouve “faz um sistema financeiro” e sai fazendo coisas da sua cabeça ?

Estou muito curioso como vc faz sistema sem levantar requisito algum.

Se vc tivesse dito “Os projetos não precisam de uma fase de levantamento de requisitos” ainda vai que não vai, mas “Não existe levantamento de requisitos em projetos de software” é demais. Até em agil vc precisa levantar estorias…
Vc quer ter um output sem ter um input. Isso só é possivel se o output é aleatorio. O seu negocio é fazer sistemas geradores de numeros aleatorios ? Se sim até entendo o seu ponto. Mas se não , responda como faz um sistema sem nunca levantar um unico requisito.

sergiotaborda:

mochuara:

sergiotaborda:

Um levantamento correto de requisitos é feito junto aos stakeholders. Quem são estes ?
São todos aqueles cujas opiniões podem mudar o rumo do projeto e/ou afetar a aceitação do software.

Hmm. “Leventamento correto de requisitos” chega a doer no meu ouvido. Requisitos ou vc sabe quais são ou então levanta pra ir embora pra casa porque um projeto que tem como fase “levantar requisitos” não vai a lugar nenhum.

Não existe levantamento de requisitos em projetos de software, é apenas uma aberração inventada na época dos analistas de sistema, antes da existencia de domain experts (ainda existem lugares onde se usa o papel de analista de sistema, nesses lugares defasados talvez levantamento de requisitos ainda seja utilizado).

:shock: As coisas que temos que ler por aqui …

Ok. vc não levanta requistos nenhuns. como vc sabe o que cliente quer ?
Vc é daqueles que ouve “faz um sistema financeiro” e sai fazendo coisas da sua cabeça ?

Estou muito curioso como vc faz sistema sem levantar requisito algum.

Se vc tivesse dito “Os projetos não precisam de uma fase de levantamento de requisitos” ainda vai que não vai, mas “Não existe levantamento de requisitos em projetos de software” é demais. Até em agil vc precisa levantar estorias…
Vc quer ter um output sem ter um input. Isso só é possivel se o output é aleatorio. O seu negocio é fazer sistemas geradores de numeros aleatorios ? Se sim até entendo o seu ponto. Mas se não , responda como faz um sistema sem nunca levantar um unico requisito.

Como falei, vc pode desistir do cliente e ir desenvolver frameworks, bugtrackers e outras ferramentas para programadores ou então exigir do cliente um domain expert. Mas o projeto só começa depois que os requisitos forem conhecidos. E no caso de clientes corporativos tais requisitos não é competência da área técnica.

Volto a repetir, em um modelo de tempo fechado para entrega, o Scrum não é totalmente eficaz se o cliente e a empresa que for desenvolver não conhecer o negócio bem. Só é eficaz se o prazo for estabelecido e a empresa já tiver uma experiência no assunto (não no desenvolvimento, mas no que será desenvolvido), pois sem isso, não adianta cada um ir aprendendo o que o cliente quer em cada interação que tanto um, como o outro, vai descobrir que o buraco é mais embaixo e o prazo expira.
Você mesmo Sergio, tá falando que faz iterações que às vezes aumenta a estória, às vezes as funde e às vezes descarta. De um jeito ou de outro, isso é uma descoberta do que vai ser feito, tanto do cliente como da empresa que vai desenvolver. Se for assim, a desenvolvedora vai descobrir lá no sprint sei lá do que, que o tempo pré-estabelecido é impróprio. E o cliente vai aumentar o tamanho do software além do imaginado. Tá, pode ser que isso seja barrado com cláusulas contratuais, mas a satisfação do cliente vai pro ralo e, talvez, no meio da descoberta, o cliente estime que sem aquela funcionalidade XYZ que vai detonar no software, não poderá ser implementada por ter um tempo curto.
Claro que isso tudo muda se for um modelo de sistema que a empresa de software está acostumada a fazer. É possível estimar neste caso.
Por isso penso que, isso só rola com um contrato flexível. Preço e prazo fixo, não vai rolar totalmente.

PS: O povo tá falando de métodos administrativos, mas já vou mandar a bola: o Scrum não mostra eficazmente uma previsão de demanda como na administração. Gente, não caiam nessa de que Scrum é um faz tudo, porque previsões são fórmulas matemáticas aplicadas com uma precisão real. O Scrum é um pressuposto que vai interagindo sem matemática e métrica real de tempo previsto inicialmente. E pelo que estou vendo, ele só tem uma noção métrica de quanto tempo vai durar algo quando passar da metade do trabalho feito ou quando ele tiver forma o suficiente para que tanto o cliente como os desenvolvedores saibam que corpo vai ter aquele aplicativo.

mochuara:

sergiotaborda:

mochuara:

sergiotaborda:

Um levantamento correto de requisitos é feito junto aos stakeholders. Quem são estes ?
São todos aqueles cujas opiniões podem mudar o rumo do projeto e/ou afetar a aceitação do software.

Hmm. “Leventamento correto de requisitos” chega a doer no meu ouvido. Requisitos ou vc sabe quais são ou então levanta pra ir embora pra casa porque um projeto que tem como fase “levantar requisitos” não vai a lugar nenhum.

Não existe levantamento de requisitos em projetos de software, é apenas uma aberração inventada na época dos analistas de sistema, antes da existencia de domain experts (ainda existem lugares onde se usa o papel de analista de sistema, nesses lugares defasados talvez levantamento de requisitos ainda seja utilizado).

:shock: As coisas que temos que ler por aqui …

Ok. vc não levanta requistos nenhuns. como vc sabe o que cliente quer ?
Vc é daqueles que ouve “faz um sistema financeiro” e sai fazendo coisas da sua cabeça ?

Estou muito curioso como vc faz sistema sem levantar requisito algum.

Se vc tivesse dito “Os projetos não precisam de uma fase de levantamento de requisitos” ainda vai que não vai, mas “Não existe levantamento de requisitos em projetos de software” é demais. Até em agil vc precisa levantar estorias…
Vc quer ter um output sem ter um input. Isso só é possivel se o output é aleatorio. O seu negocio é fazer sistemas geradores de numeros aleatorios ? Se sim até entendo o seu ponto. Mas se não , responda como faz um sistema sem nunca levantar um unico requisito.

Como falei, vc pode desistir do cliente e ir desenvolver frameworks, bugtrackers e outras ferramentas para programadores ou então exigir do cliente um domain expert. Mas o projeto só começa depois que os requisitos forem conhecidos. E no caso de clientes corporativos tais requisitos não é competência da área técnica.

Piorou. O projeto só começa depois que os requisitos são conhecidos, mas não ha levantamento de requisitos. então como ele são conhecido ? Telepatia ?

Thiago Senna:

[momento-viagem]
Tenho uma teoria viajante - sinceramente acho que o cliente só sabe que ele precisa de um sistema, mas não tem a menor idéia do que automatizar. E nós, bons programadores que somos implementamos o que eles nem sabem direito. Se nós invertessemos o papel, por exemplo - ao invés de querermos o cliente próximo de nós para entendermos o problema dele, que tal enviarmos o especialista em TI para junto deles?

Que tal o seguinte rótulo para a sua consultoria: “Contrate nossa consultoria e colocaremos dois profissionais de TI dentro de sua empresa para fazer um estágio e usar seus fortes conhecimentos em computação para identificar todos os pontos passíveis de automação.”

Hoje mais parece que o cliente é quem tem que entrar no nosso mundo, quando na verdade deveria ser o contrário.[/momento-viagem]

Se o cliente não sabe o que precisa não é por falta de programadores ou analistas que se formaram em curso de computação, eles precisam de um domain expert.

Das dua,três: ou vcs não sabem o que é scrum e ficam dando pitaco sobre o que vcs acham que scrum é, ou vcs estão com a consciencia alterada por algum produto quimico ou vcs estão de sacanagem comigo.

Até aqui perfeito.

Isto nunca vai acontecer porque o tempo nunca é estabelecido. Vc não estima em tempo. Estima tamanho.
O máximo que vai acontecer é sua estimativa estar errada e em vez de fazer em um sprint vc faz em dois.
Isso é aceite e esperado em scrum. Não muda nada no planejamento do projeto.

Vc contratou 3000 pontos. uma features que vc cotou como 8 pontos foi na realidade 21 pontos. Isso significa que vc perdeu 13 pontos. Isso significa que features equivalentes a 13 pontos não serão incluidas neste release. Se o projeto só tem um release (o que é estupido,mas é possivel) isso significa que vão existir features que somam 13 pontos que não serão incluidas.

Veja bem, o cliente não está pagando para incluir todas as features. ele está pagando para ter um software utilizável numa certa data. Esta é uma grande diferença do metodo tradicional. No método tradicional software utilizável, escopo, tempo e custo é tudo a mesma coisa. Em agil não é.

Tlv seja isto que vcs não estão entendendo. Em scrum o foco é ter software entregável. A cada sprint o software é integravel. O PO pode chegar no fim de uma reunião de fim de sprint e dizer :“tá blz. empacota assim” ( nice, ship that). Isso significa que o release foi antecipado e o cliente tem o sistema antes do prazo. Antes do prazo.Onde vc vê isso no método tradicional? nunca. é sempre depois do prazo.

Do software, não do projeto. São coisas diferentes em Scrum. Tem que entender este conceito , porque senão vai ficar chovendo no molhado.

Não. Isso nunca vai acontecer. Porque ele priorizou. Se ele chega nessa conclusão a culpa é dele. Portanto não tem como ficar insatisfeito com a equipa. mas a satisfação nunca vai para o ralo porque todos os meses ele tem um software novo. Acho que é isso que vc não enxergam. Todos os fins de sprint ele tem um brinquedo novo para mexer. Isso é satisfatório.

O Scrum é um pressuposto que vai interagindo sem matemática e métrica real de tempo previsto inicialmente. E pelo que estou vendo, ele só tem uma noção métrica de quanto tempo vai durar algo quando passar da metade do trabalho feito ou quando ele tiver forma o suficiente para que tanto o cliente como os desenvolvedores saibam que corpo vai ter aquele aplicativo.

Isto é totalmente equivocado. Um burdown chat tem muita matemática e permite fazer muitos ajustes e estimativas. Vc tem que entender um burdown chat antes de dizer que o scrum não tem matemática.

Vocês vão ficar nesse loop infinito pra sempre desse jeito.

Ágil é uma via de mão dupla: não é só a software house, mas o cliente também tem que adotar. Não adianta ter uma equipe ágil e o cliente ser tradicionalista, e essa é a situação que todos querem que o Scrum resolva, sendo o maior exemplo a questão das licitações, muitas vezes exigindo, mesmo que não de forma escrita, um processo tradicional.

Se você quer adotar ágil, você vai precisar convencer seus clientes de que isso vale a pena antes. Não adianta você querer artefatos tradicionais usando uma metodologia ágil, ponto final.

E podemos voltar a discutir a revista?
Aliás, ainda não pude ler, pois não achei em nenhuma banca aqui em Recife.

100% Apoiado!!!

jcracker:

Uma coisa que acho que poderia ser valida é ensinar o consultor java a saber pesquisar assuntos e como decidi-los a estudar, fica muito complexo pegar a revista e ver soluções sem ao menos a pessoa saber por deve-se usar isso ou aquilo, a revista esta indo no caminho para esse entendimento quando colocou no"Artigo 38 -Boas Práticas Java EE", ao Tema Acerte na sua escolha, mas ainda percebo que falta melhor direcionar os assuntos sobre obras e escritores, claro que isso é um grande desafio, mas acredito que possa mesmo a ter uma real colaboração sobre esse ponto de vista, por onde se deve mapear resultados sobre desenvolvimento e implementações com soluções em tecnologias, levar ao leitor a auto critica e elevar seu grau intelectual de conhecimento.

Tenha certeza que isso realmente é um desafio! Tentamos a cada edição trazer um conteúdo relevante para os nossos leitores. Como já disse outras vezes aqui no fórum, o nosso maior concorrente são os artigos da Internet, que são numerosos e abrangem muitos assuntos! Estar trazendo sempre algo novo, como esse formato de artigo com a estória interativa e a entrevista exclusiva com Alex Buckley na edição anterior, é algo que temos sempre perseguido!

Para a próxima edição aguardem uma nova surpresa e a volta do Rodrigo Yoshima que estava meio sumido da revista!!!

sergiotaborda:

Isto é totalmente equivocado. Um burdown chat tem muita matemática e permite fazer muitos ajustes e estimativas. Vc tem que entender um burdown chat antes de dizer que o scrum não tem matemática.

Guerr@:

juliofsn:

E podemos voltar a discutir a revista?

100% Apoiado!!!

Uma coisa que eu acho muito importante, e que não me lembro se todos os artigos tem, são referências. no artigo do Gazola, por exemplo, tinham ótimas refêrencias, e eu fui atras pra le-las (ta certo isso que eu escrevi? :? ). Isso é como a bibliografia de trabalhos cientificos, se vc gostou do assunto, va ler as referências, e as referências das referências e assim por diante. Isso já é um começo para a proposta do jcracker de ensinar o cara a estudar.

javamaniaco:

Se o tempo estimado para desenvolver o projeto já foi lançado como fixo, temos um problema grande: faz o que o cliente vai olhando como prioritário e deixa as loucuras de lado pra dar tempo ou…, simplesmente implementa e cobra mais do cara, porque o tempo estoura.

O vosso problema não é com métricas ou com scrum. O vosso problema é entender gerenciamento de projetos.
Qualquer tipo de projeto de qualquer área obedece certas regras. Se vc tentar violar essas regras dá merda.
Em desenvolvimento de software tradicional essas regras sçao violadas diáriamente e é por isso que os clientes ficam insatisfeitos.

Primeiro erro :o cliente tem sempre razão.

O cliente não tem sempre razão. Ele tem razão se pede coisas no ambito do contrato. Se está fora do contrato, está fora.

Quais são as três variáveis que o cliente mexe : prazo, preço e requisitos.

Projetos tradicionais partem do principio que tem preço, prazo e requisitos fixos. Mas não é verdade. todos sabem que os requisitos não são fixos.

O triangulo de projeto relaciona 3 coisas : Preço, Tempo e Qualidade. Só dois podem ser otimizados e isso leva à desotimização do outro. Bom e Rápido é Caro. Barato e Rápido tem pouca qualidade.

Em projetos de software sérios a qualidade é otimizada. Portanto só existem dois tipos de projetos de software : Bons, Caros e Rápidos e Bons, Baratos e Lentos. Qualquer outra combinação leva a qualidade fraca.

Na prática as empresas usam : Rápido , Barato e com pouca qualidade. mas eu não posso defender isso.

Para projetos de prazo fixo , vc tem duas constantes : qualidade e tempo. Portando a variável é preço. O cliente não pode pagar o preço que exigimos ? problema nosso. Reveja os centros de custo. Diminua o custo e fará melhor preço.

Para projetos de preço fixo , vc tem constantes qualidade e preço. Portanto a variável é tempo. O cliente não pode pedir as três coisas ao mesmo tempo. quer dizer, pode pedir, mas vc não pode prometer. A razão é simples : é impossivel.

Contratos tradicionais fixam os três e isso é que leva a toda a merda dos projetos tradicionais. É isso que leva a horas extras e outras aberrações …

Se o cliente fixou um prazo isso não significa que vamos entregar todo o software possivel e imaginável até lá. Quer dizer que vamos entregar o software contratados. Classicamente isso significa :" todos os requisitos" , modernamente signfica :“tudo o que couber em X pontos”. Repare que classicamente não é necessário priorizar, porque afinal tudo será incluido. Isso leva a muitos desastres, como deixar o core dos sistema para o fim depois de ter feito todos os cadastros. Em agil é necessário priorizar porque as features que realmente importam são incluidas primeiro. Ou seja, vc começa pelo core e vai adicionando coisas.

São abordagens diferentes. E é preciso entender as diferenças. é preciso entender que o cliente não tem sempre razão, que existem limites ao que se pode prometer e que sim, o cliente tem que fazer trade-offs. Não sabe ? aprende. Não quer aprender ? paga mais caro pelos seus erros.

Se vc tem um ambiente estável, que é balizado por regras, vc consegue estimar facilmente.
Se vc tem um ambiente onde tudo é variável, não é possivel estimar. é por isso que os projetos tradicionais falham feio.

P.S.
Antes que venham com a mesma conversa esfarrapada que não coloco referencias aqui fica uma sobre o que estou falando. The Enterprise and Scrum , tb do Ken Schawber mas de 2007.
Capitulo 4 é muito interessante , não tem diretamente com scrum, mas comas idiosincrazia das empresas. uma resenha pode ser vista aqui

Deixa eu fazer uma critica construtiva ao pessoal que fez o artigo de JSF. Gente, não é mau hábito algumas coisas, como o caso do login com PhaseListener. Se eu não quero me atrelar ao JSF, pq devo me atrelar ao Spring ou outro? Afinal, se estou implementando algo em JSF, posso sim usar PhaseListener e nem é um mau hábito. Acho que mau hábito é usar o JSF, rs.
Agora, falando sério, tem alguns pontos que discordo, além desse.
O “mau hábito 2”, por exemplo, posso fazer diretamente tb. Sinceramente, isso não muda muito o desempenho e nem come memória. Vai usar algo mais pesado como Seam, que falam tanto e vocês vão ver o que é pesado. Aliás, achei bem verboso a forma que apresentou, além de mostrar uma anotação que desconheço do JSF.
Espero que nem todo leitor leve em consideração, pois isso pra mim não teve muito valor.
O mau hábito do JSTL então, nem se fala. Cara, me diz uma coisa, toda vez que tiver de fazer uma condicional que com JSTL seria simples vou ter que verificar com componentes. Afe, acharam um pelo em ovo. Desculpa, mas ficou pobre o exemplo. Não vou colocar e repito, algo mais verboso usando rendered e código no bean para ter visível ou não, um conjunto de componentes. Besteira. Ai vocês dizem: blz, coloque um panel ou similar. Mas e se eu não quiser usar aquela coisa tosca, o que faço? choro e coloco rendered em cada componente? Outra coisa, pra quem alguém usaria foreach? Desconheço. Se for usar Facelets, se for essa a desculpa, tem o componente repeat pra isso. Mas o if colega, tira o cavalinho da chuva tá. Usar JSF com Facelets e IF do JSTL é um excelente hábito para não ter código a mais.
Outro detalhe, o 6º hábito ficou confuso. O título não condiz com a situação. Passar parâmetros em HTTP é a maior deficiencia do JSF e é algo Web 2.0. Só que o título induz que usar isso é ruim, sendo que o conteúdo diz que em certos componentes. Então, mude o título que ficou pessimamente explicado.

Sérgio, volto a dizer, você quer mudar algo pré-estabelecido. Não é que não entendo gerenciamento, o que me parece é que vc que não entende. Se vc deu um prazo fixo, morreu ali, não tem como ir implementando toda a loucura do cliente, pq ele vai querer, e não vai dar tempo. Esquece o Scrum, não funciona.
Ótimo fazer mais sprints, mas legal também é que, se não meter mais gente, vou ficar mais horas trabalhando. Meter mais gente de outro projeto já indica mau cheiro. Enfim, cocei a orelha esquerda com a mão direita como no método tradicional.
E sim, clientes sempre tem razão, ou você quer ir a falência? Pra mim, sinceramente, você está defendendo assim porque, se gerencia projetos, o que duvido, não lida com clientes. Logo, desconheço gerencia de projetos sem lidar com clientes, já que fica meio que um telefone sem fio. Porque eu lido com clientes e não dá pra ficar dizendo NÃO. E nem vamos ver se dá pra colocar. Ou coloca, ou não coloca. Mas se não colocar, o cliente vai reclamar e ficar insatisfeito e pronto.
Então, volto a repetir, em um ambiente onde o contrato é fixo, não dá pra implantar o Scrum na sua totalidade porque não dá pra prever todas as variáveis e principalmente, as adições feitas pelos clientes.
Novamente, me repito: Se o cliente e nem a empresa possui experiência no que vai ser desenvolvido, esqueça um contrato fixo com Scrum. É dar um tiro no pé. É como aquela frase: “Na prática, a teoria é outra”. E Scrum, não tem matemática pra prever as imprevisibilidades humanas porque não existe métricas pra isso.

??? Se eu quero mudar a forma embecil de se fazer projeto de software do modo tradiconal para Scrum ? claro que quero.
Se estou inventando o scrum agora, claro que não.

uhé, isso foi exactamente o que eu disse. Se o praxo é fixo, não se vai implementar toda a loucura do cliente. aliás , mesmo que nem seja fixo,em scrum, isso não vai acontecer nunca.

Isso vc fala porque conhece muitos exemplos de empresas usando scrum e falhando.
Mas dessas empresas quantas realmente usam scrum de verdade ? Esse é que é o ponto. Scrum de verdade funcionas sim.

Então você é como todos os gerentes tradicionais : você esconde a realidade,mente e tem medo.

“The soon-to-be Scrum users don’t think that transparency, or truth, is acceptable where they work. They tell me
that they will be fired if they tell the truth. Truth isn’t what their customers want to hear. They tell me their customers will find someone else who will lie to them if they don’t. I have seen this in class after class for five years. People in product development think that their customers want to hear news only if it is good news and would rather hear a lie than the truth. “Lying” is a harsh word. But what else do you call saying that something is true when you know it not to be true? What else do you call misleading someone with information or holding back information that would have led them to better decisions? The Product Owners want to believe in magic, and the developers support the belief by lying. “Can you do this project by this date?” “Sure, no problem.””

• Ken Schwaber : The Enterprise and Scrum

Eu já lidei com clientes e já fui coordenador de equipe e me recuso a mentir. Os gerentes e diretores não gostam, mas o problema é deles.

Vc ainda não entendeu. Em scrum , em agil em geral, você SEMPRE ACEITA ALTERAÇÔES ! Sempre!
não ha discussão de aceita ou não. vc sempre aceita.
A estoria vai para o backlog, é estimada pela equipe no fim do sprint e depois é priorizada pelo cliente em realação às outras estorias já no backlog. Não ha problema nenhum com isto. NENHUM!

Scrum aceita exactamente o que vc está descrevendo. ele não luta nem resiste à alteração. Esse não é o jeito scrum de pensar.
Como vc SEMPRE coloca a featue o cliente NUNCA fica instatisfeito.

Vc não precisa prever, esse é o poder do scrum e do agil em geral.

Mas Scrum não precisa dessa matemática porque ele não precisa prever as imprevisibilidades.
Scrum só precisa prever o que é previsivel. O que é previsivel é : quantos releases vamos fazer . Quais as suas datas. Quanta funcionalidade - “quanta” não “qual” - vamos entregar em cada um. NUNCA se define qual a funcionalidade. É para isso que existe o backlog. Apenas quando formos fazer o sprint é que se escolhe qual funcionalidade vamos fazer.

Vc está se queixando de problemas que existem em projetos tradicionais. Eles não existem em scrum! E não existem porque Scrum é desenhado exactamente para que eles não existam! Vc acham que tem esses problemas nas sua empresa ? Quer resolvê-los ? use Scrum. Mas use de verdade e não um receita caseira.

Bom, não desejo aqui fazer o papel de psicólogo, ou no caso psiquiatra, mas façamos um histórico das respostas :

“Século XXI falando sobre pontos de função.Todo mundo tá cansado de saber, não funciona”

Entretanto, logo depois (terceira resposta) comentou que têm dúvidas de como se calcula e também afirmou que eu não sei calcular, que todo o artigo é baseado em mentiras

"Se vc usa 12 artefactos UML para cada classe, andar, nodo e decisão do projeto a escolha é sua."
Bom, aparentemente desconhece e despreza a UML também

“Não é culpa do scrum ser bom e as pessas serem atrazados mentais.”

“Confundir software e projeto é o erro da metodologias tradicionais. qualquer pessoa com mais de 5 anos no mercado sabe que as metodologias tradicionais não funcionam, são stressantes e fazem as SH perder dinheiro.”

“O problema atualmente é que ninguem tem poder de remover o gerente excepto os diretores. Mas como é uma hirarquia não ha ninguem que audite o gerente e reporte ao diretor. O desenvolvedor não pode chamar a atenção do diretor para a incompetencia do gerente. Em scrum não só ele pode chamar a atenção do SM, como o SM pode chamar a atenção dos diretores.”

“O cliente nunca sabe o que quer e nunca tem razão.”

“Primeiro erro :o cliente tem sempre razão.
O cliente não tem sempre razão. Ele tem razão se pede coisas no ambito do contrato. Se está fora do contrato, está fora.”

“??? Se eu quero mudar a forma embecil de se fazer projeto de software do modo tradiconal para Scrum ? claro que quero.
Se estou inventando o scrum agora, claro que não.
Então você é como todos os gerentes tradicionais : você esconde a realidade,mente e tem medo.”

Bom, acho que o resumo de toda a discussão é que qualquer pessoa que sequer tenha dúvidas sobre SCRUM é um imbecil e atrasado. Tudo o que foi feito até hoje em termos de engenharia de software foi uma grande babaquice, as metodologias anteriores nunca fizeram nada de bom para o mundo, e SCRUM é a única coisa verdadeira. Todos os gerentes e diretores são estúpidos, e o cliente não sabe nada nem o que quer, e deve aceitar tudo o que Ken Schwaber (do qual foram apresentadas absolutamente todas as referências) ou seus representantes legais disserem que é verdade.
Bem, esquecí algo, antes de ir para um canto chorar o final de semana todo ?
PS : Continuo mesmo torcendo para que as pessoas que trabalham com SCRUM não tenham este grau de “radicalidade”, caso contrário não tenho dúvidas sobre o fracasso da tecnologia.

[]s
Glauco Reis

É quase isso. Tudo o que foi feito até hoje em engenharia de software foi sim uma babaquice. Prove o contrário se for capaz :foi vc mesmo que , no artigo, diz que pontos de função e pontos de caso de uso não funcionam. E isso foi inventado pela engenharia de software.
Empresas exploradoras de pessoas com formação superior como se fossem peões sim é ultrajante, covarde e uma vergonha. Ser conivente com este modelo de negocio sim é atrazado. Nisso vc acertou em cheio.

Você está defendendo o jeito atual de fazer as coisas ? Que seja. Mas não venha com essas que temos que respeitar os antepassados porque desenvolvimento de software não é uma monarquia e nem uma religião. O que temos que respeitar são as pessoas. As ideias foram feitas para serem trocadas.

Eu respeito imenso o pessoal que inventou o UML porque eu uso todos os dias. Mas não uso como documentação. Mesmo que vc encontre uma referencia dos autores dizendo que UML serve para fazer documentação - o que duvido - eu lhe cito alguem que já escreveu/ ainda escreve na MJ : http://blog.aspercom.com.br/2008/06/06/uml-nao-eh-documentacao/

Quanto a que scrum ( não se escreve SCRUM porque não é nenhum acronimo) é a única coisa verdadeira o meu ponto é : foram ditas coisas sobre scrum que não são verdade. Eu apenas tento explicar porque não são verdade. Quem sabe , como eu, que não são verdade não é problema. Quem pensa como vc , o Guerra e outros, tb não é problema. O problema são todos aqueles que estão tentando aprender e procuram fontes fidedignas. Só não quero que pessoas que ainda estão aprendendo a formar uma ideia do assunto tenham informações distorcidas.

Não todos. A grande maioria. Tenho fé que ha por ai algum director e gerente que não é estupido e algum cliente que sabe o que quer.
Aliás, meu objetivo é trabalhar com eles.

Bom, pelo menos eu apresentei alguma referencia do que estou defendendo. Ninguem que defende o modo tradicional apresentou referencia alguma. Apenas opiniões.
Mas cadê as referencias que suportam a sua opinião ?

Bom, para suportar a sua opinião no artigo vc usou as seguintes referencias:

http://struts.apache.org/1.x/userGuide/introduction.html - hummm… muito a propósito sem duvida. Se eu referir o manual do Spring ou do Hiberante ficamos quites nessa.
http://en.wikipedia.org/wiki/Graig_McClanahan - uma referencia ao autor do struts. Se eu referir o Rod Jonhson tb estamos quites.
http://www.softwaremetrics.com/Articles/using.html - como usar pontos de função. A citação a Agile Estimation and Planing cobre isto.
Applying Use Cases - A pratical Guide , Writing Effective Use Cases - Alistair Cockburn , Function Point Analysis - a citação aos livros do ken Schwaber cobre o mesmo escopo para como aplicar scrum.

Cadê a sua referencia a algo de Scrum para poder dizer que

De onde vc tirou isto ? Você até escreveu scrum errado! Concerteza não é uma citação nem uma paráfrase.

Se vc tivesse procurado vc teria encontrado isto :“We then estimate and prioritize it compared to all other work in the
enterprise’s Product Backlog. For Scrum estimation techniques, see Mike Cohn’s recent book, Agile Estimating and Planning (Prentice Hall, 2004).” - The Enterprise and Scrum (2007).

Como que o inventor do Scrum pode estar referindo um livro inteiro de tecnicas de estimativa Scrum se em Scrum não existem tecnicas para estimar ?
É só nisto que quero que as pessoas pensem.

E Glauco, aprenda a escrever scrum!

Scrum sim é imutável:

“At this point in the adoption cycle, many people in your enterprise are probably advising you to change Scrum because it needs some tweaking to be compatible with your enterprise. My advice is this: Don’t Do It. The rules, roles, and time-boxes of Scrum are few and simple. The practices and structure of Scrum uncover problems that are sometimes ugly and difficult to solve. The normal tendency is to change the aspect of Scrum that made the problems visible. Everyone will then feel better and can proceed with their work just as they always have. Unfortunately, if you change Scrum, the very reason why their work is less productive than it could be will again be obscured. Whenever I visit an enterprise that is adopting Scrum, I look for these deviations from standard Scrum practices. In every instance, I have found an enterprise problem that everyone wanted to continue to ignore.” - The Enterprise and Scrum

Eu não tenho culpa que vc e o pessoal da MJ não saibam o que é scrum. Não tenho culpa que não pesquisaram direito.
A minha unica culpa seria deixar passar impune esse erro. Fiz minha parte.
Está aqui, preto no branco por A mais B porquê estou dizendo o que digo.

A grande ironia é que sou eu que tenho que me explicar e não você ou a MundoJava. Afinal foram vocês que erraram. E erraram feio.

Sergio ,

Quero dizer que são de grande valia sua contribuição e esclarecimento, fico certo que todos vão acatar melhor o entendimento sobre o assunto que aqui fora publicado pela MJ e debatido, sabemos o quanto experiencias e literatura são necessárias para se atingir um nivel profissional e não são todos que tem a mesma oportunidades, porque uns são academicos de mais, outros só dão treinamento e poucos são os consultores com um senso de literatura e critica, espero que a Revista Mundo Java repense ao tema das questões publicadas.

Abraçoss !!!

glaucoreis:

Bom, não desejo aqui fazer o papel de psicólogo, ou no caso psiquiatra, mas façamos um histórico das respostas :
…
…

Bom, a melhor resposta do tópico até aqui!
Eu sinceramente estava pensando em algo to tipo, mas como ja disse la atraz cansei, e vi que de nada adiantaria, é perda de tempo, não importa o que tu diga, não importa os teus argumentos, não importada nada, só importa a palavra de “Deus” o soberano, e seu livro perfeito, o Scr… ops a Biblia.

Se liberte desse topico como eu fiz, e seja feliz.

Infelizmente o Glauco Reis tá longe de entender ou querer defender seus argumentos, e agora pior ainda você querer se manifestar em busca de divindade porque não exerce de razão pra querer entrar em um assunto de natureza tecnica e cientifica, eu só lamento o descaso que poucos aqui possam evoluir de conhecimento e liberdade de expressão.

Um texto interessante escrito pelo Rodrigo Yoshima que talvez interesse quem se interessou pela discussão:

O que matou o RUP pode matar o Agile: http://blog.aspercom.com.br/2009/09/29/o-que-matou-o-rup-pode-matar-o-agile/

Pessoal,

Acho que essa discussão não está levando mais a lugar nenhum. Foi colocado em um post anterior um link que no meu ponto vista deixava claro que contratos de escopo fechado não eram o escopo do Scrum e mostrava uma forma de combina-lo com outras técnicas para isso. Li várias vezes o texto e realmente entendi isso. Outras pessoas entenderam o oposto!

Acho que essa questão é polêmica e pelo visto depende muito da visão e opinião de cada um. Acho que todos já leram os pontos de vista expressados, alguns concordam com o que foi publicado na revista e outros com a posição do Sergio. Sem problemas! O mundo como um todo é assim mesmo! As pessoas podem discordar e não ficar se degladiando!

Acho que deveríamos encerrar a discussão por aqui, pois não está tomando um rumo muito “saudável”. O Sergio exerceu o seu “direito de resposta” e quem ler os posts e decidir concordar com ele está no seu direito. Porém, quem achar que o que foi escrito na revista está correto, também está no seu direito.

Caso queiram continuar a discussão (que não tem mais nada a ver com a revista) sugiro criar um novo tópico e talvez outras pessoas interessadas em Scrum (atraídas pelo nome do tópico) também participem.

Sem mais…

Pessoal,

Acho que essa discussão não está levando mais a lugar nenhum. Foi colocado em um post anterior um link que no meu ponto vista deixava claro que contratos de escopo fechado não eram o escopo do Scrum e mostrava uma forma de combina-lo com outras técnicas para isso. Li várias vezes o texto e realmente entendi isso. Outras pessoas entenderam o oposto!

Acho que essa questão é polêmica e pelo visto depende muito da visão e opinião de cada um. Acho que todos já leram os pontos de vista expressados, alguns concordam com o que foi publicado na revista e outros com a posição do Sergio. Sem problemas! O mundo como um todo é assim mesmo! As pessoas podem discordar e não ficar se degladiando![]

Bom não vamos encerra assunto à sentenciar questões sobre ao que leigos querem concordar, vamos lapidar esse diamente que esta muito bruto para vender idéias, aqui não estamos fazendo leis, vamos continuar no esclarecimento e a correção de um assunto que todos podem se instruir melhor.

Eduardo ,
Você não pode se sentir atingido, não estamos colocando pontos de vista tão somente ou então vamos deixar que profissionais coloquem suas experiencia e questão sobre aquilo que ainda não entenderam ou não experimentaram não sabem e não dominam plenamento o assunto.Em relação a dizer Caso queiram continuar a discussão (que não tem mais nada a ver com a revista), lamento em dizer isso é demagogia da sua parte.

Melhores considerações ,

Forte abraço !!!

Olá, pessoal.

Eu gostaria de ver alguns comentários, sugestões e críticas sobre o artigo que eu escrevi utilizando a API do Google AdWords nesta edição 38 da revista Mundo Java.

Existe uma carência considerável nesta área nas agências de martketing digital brasileiras.
Tem mais gente por aqui trabalhando com sistemas integrados ao AdWords?

Abraço!
Eric M Gomes
[email removido]

ericgomes:

Olá, pessoal.

Eu gostaria de ver alguns comentários, sugestões e críticas sobre o artigo que eu escrevi utilizando a API do Google AdWords nesta edição (número 38) da revista Mundo Java.

Existe uma carência considerável nesta área nas agências de martketing digital brasileiras.
Tem mais gente por aqui trabalhando com sistemas integrados ao AdWords?

Abraço!
Eric M Gomes
[email removido]
www.octavarium.com.br

Agências de marketing digital brasileiras seria a filial do google no brasil?

Que eu saiba o google e uma meia duzia de gato pingado que realmente ganham dinheiro com publicidade na web. Talvez marketing digital abranhja outras midias, estou falando da web.

jcracker:

Pessoal,

Estamos exercendo o direito a melhor informação e nisso colocando referências, assim como fez o Sergio quando postou obervações do autor ken Schwaber e você desconhecia determinada informação ao lado de estimativa pelo SCRUM, não é o degladiamento é evoluir um assunto para seu melhor esclarecimento.

Forte abraço !!!

Sim, no link o proprio inventor do scrum reconheceu que Scrum falha nessa área.

mochuara:

Agências de marketing digital brasileiras seria a filial do google no brasil?

Que eu saiba o google e uma meia duzia de gato pingado que realmente ganham dinheiro com publicidade na web. Talvez marketing digital abranhja outras midias, estou falando da web.

Estou falando sobre web sim e mais especificamente sobre os anúncios de links patrocinados do Google.

Além do próprio Google, que fatura alto com a ferramenta de publicidade online que disponibiliza, existem agências de marketing digital especializadas em gerenciar profissionalmente as campanhas online de links patrocinados para seus clientes.

Dependendo do tamanho da verba de publicidade destas empresas, o investimento no Google AdWords também é alto, com isso algumas agências também faturam bem.
Consequentemente as 4 pontas saem satisfeitas: o Google, as agências, o cliente final e o internauta que encontra publicidade relevante.

O artigo mostra um exemplo de como integrar por exemplo o estoque de uma loja virtual com a campanha online no AdWords.

Abraço,
Eric M Gomes
[email removido]

mochuara:

jcracker:

Pessoal,

Estamos exercendo o direito a melhor informação e nisso colocando referências, assim como fez o Sergio quando postou obervações do autor ken Schwaber e você desconhecia determinada informação ao lado de estimativa pelo SCRUM, não é o degladiamento é evoluir um assunto para seu melhor esclarecimento.

Forte abraço !!!

Sim, no link o proprio inventor do scrum reconheceu que Scrum falha nessa área.

1. Ele não reconhece que falha.
2. Scrum sim funciona em projetos de preco e prazo fixo

“The value-added product would be specified, and a fixed-price, fixed-date contract would be signed between your company and Contoso. The project to develop it would typically last four or so months. Contoso’s business model is to at least break even on these projects. (…)
One customer had a fixed-price, fixed-date contract that called for delivery within six months. When Contoso delivered in six months, the customer wasn’t ready for the product. The customer had hedged its bets, assuming that Contoso would probably be late.” - The Entreprise and Scrum , do mesmo autor 3 anos depois de Agile Manegemanet with Scrum

Usar apenas uma referencia para descer o martelo da decisão é sinal de imaturidade argumentativa ou má vontade , ou pior, má fé.
Vc pode dizer o que quiser do Schwaber. Que ele mudou de ideia, que ele não sabia o que era scrum, que ele foi inventando durante os anos ( afinal é por isso que ele é um dos inventores) , etc…
O ponto é que sim funciona. E esse exemplo que ele dá no livro é a prova. Não está convencido que o Scrum é bom, é melhor ? tudo bem. Esse não é o objetivo. Mas ainda não está convencido que scrum sim funciona em projetos de preço e prazo fixo ? Bom, isso acho que já é má vontade.

Veja bem, se ele funciona em projetos de preço não fixo e prazo não fixo seria de esperar que funcionaria melhor se essas coisas forem fixas. Certo ? Afinal fixando essas coisas á menos variáveis. Ora, pois é isso mesmo que acontece. Sabendo isso, Scrum sempre funciona com datas fixas mesmo quando elas são fixadas artificialmente. Contudo na vida real é muito dificil que aconteça o prazo não ser fixo e ter que o fixar artificialmente - mas é sempre uma ferramenta disponivel. As pessoas utilizam o software para realizar coisas e comprometem-se com terceiros com base na prespetiva de ter o software pronto em certa data. Afinal os negócios são baseados em compromissos. E é isso que o Scrum faz acima de tudo :estabelece compromissos entre pessoas.

Publicidade na web é pessimo para a usabilidade do site e experiencia do usuário, não sei daonde vc tirou que usuário quer ver publicidade desse tipo, grande parte dos usuários inclusive ja ignora a parte do site onde fica os anuncios, o que exige comportamentos cada vez mais incisivos por parte dos anunciantes e consequentemente uma degradação ainda maior da experiencia desse mesmo usuario. Como pode ver isso gera uma espiral negativa que não ajuda em nada a trazer os milhoes de pageviews que vc precisa pra gerar alguma receita significante. Marketing de forma geral não acho que seja algo inerentemente ruim, mas o atual modelo de publicidade na web dominado pelo google é um cancer.

Mochuara, eu particularmente clico em links patrocinados. Tenho relatórios de campanhas que acompanho mostrando que muitos internautas clicam porque se interessam.

O pay per click com anúncios relevantes ao internauta, por estarem relacionados ao contexto, é o modelo vigente hoje e traz melhorias em relação ao modelo de display branding online tradicional.
O Google tenta evitar ao máximo anúncios incisivos justamente por que isso afasta a experiência do internauta. Os anúncios de texto têm CTR (taxa de cliques) muito superior aos banners tradicionais. Quanto menor a taxa de cliques nestes anúncios, mais difícil é para se manterem, devivo ao índice de Qualidade que o Google aplica, objetivando aumentar sempre a relevância para o internauta.

De alguma forma a conta tem que fechar e a publicidade não vai morrer, assim como acontece nas outras mídias. O AdWords hoje sustenta o Google e na minha opinião vamos ver cada vez mais publicidade nos produtos ‘by Google’. A dupla concorrente também corre atrás com o Search Marketing e o adCenter, do Yahoo e Microsoft respectivamente.

Abraço,
Eric M Gomes
[email removido]

jcracker:

Eduardo ,
Você não pode se sentir atingido, não estamos colocando pontos de vista tão somente ou então vamos deixar que profissionais coloquem suas experiencia e questão sobre aquilo que ainda não entenderam ou não experimentaram não sabem e não dominam plenamento o assunto.Em relação a dizer Caso queiram continuar a discussão (que não tem mais nada a ver com a revista), lamento em dizer isso é demagogia da sua parte.

Melhores considerações ,

Forte abraço !!!

Na verdade não me senti atingido. A questão é a discussão entrou em loop e alguns termos ofensivos que não são “justificativas técnicas observáveis” estão sendo utilizados em alguns posts. Algumas declarações estão saindo da esfera técnica para a esfera pessoal.

É em relação a isso que estava falando e não em relação a mérito técnico do tema, que inclusive reconheço sugerindo a criação de um novo tópico.

Um forte abraço para você também!

Quanto mais leio isso daqui, mais percebo que os que defendem Scrum em tudo, não lidam com clientes diretamente e não costumam trabalhar com uma demanda de softwares especificamente não comerciais (softwares de cruds e reports).
Sérgio e o outro ai que parece um papagaio do Sergio, lamento mas passando suas referências não indicam nada. Vai explicar pro cliente porque aquela feature que ele quer, devido as interações, ele não pode ter porque não vai dar tempo de tudo.
E por favor, parem de dizer que Scrum lida bem com tempos fixos. Pois não dá pra ter isso com precisão antecipada já que ele não possui métrica matemática aplicada em demanda.
Quanto mais vejo vocês discutirem, mais percebo que lidam com coisas menos complexas e seus conhecimentos matemáticos na parte administrativa, significativamente importantes para prever realmente como as coisas andarão nos próximos meses, são deixadas de lado.

PS: Scrum é simples demais de entender. Também é fácil perceber que ele falha em certas coisas. Nada é perfeito.

Guerr@:

Na verdade não me senti atingido. A questão é a discussão entrou em loop e alguns termos ofensivos que não são “justificativas técnicas observáveis” estão sendo utilizados em alguns posts. Algumas declarações estão saindo da esfera técnica para a esfera pessoal.

O Tema aqui debatido fora exposto do artigo “Mundo Java 38” em especifico derivado sobre metodologias disponíveis para estimativa do tempo de desenvolvimento, Autor: Glauco dos Santos Reis.Sugerir um novo tópico é algo que entendo como sendo defensivo ao interesse da Revista Mundo Java, mas eu não ligo, todavia me preocupa a condução queremos abrir uma discurssão a favorecer merito técnico que tenha melhor cabimento e assim à evitar futuros contrasenso para novos artigos, fica aqui minha observação final que se abra um novo tópico sobre o assunto SCRUM.

Por fim quero dizer acredito na sua responsabilidade.

Um Grande Abraço !!!

Eu só acho que não devemos tomar como exemplo a nossa experiencia na web, que é completamente diferente da de um usuario tipico msn/orkut, este clica em qualquer coisa que brilhe muito, acredite eu tenho mulher e cunhadas aqui pra comprovar.

Cliente não tem cultura ou qualquer maturidade ao lidar com SCRUM , é necessário você faze-lo compreender em forma didatica o assunto e a produção desses resultados.

Sérgio e o outro ai que parece um papagaio do Sergio, lamento mas passando suas referências não indicam nada. Vai explicar pro cliente porque aquela feature que ele quer, devido as interações, ele não pode ter porque não vai dar tempo de tudo.

E por favor, parem de dizer que Scrum lida bem com tempos fixos. Pois não dá pra ter isso com precisão antecipada já que ele não possui métrica matemática aplicada em demanda.

Quanto mais vejo vocês discutirem, mais percebo que lidam com coisas menos complexas e seus conhecimentos matemáticos na parte administrativa, significativamente importantes para prever realmente como as coisas andarão nos próximos meses, são deixadas de lado.
PS: Scrum é simples demais de entender. Também é fácil perceber que ele falha em certas coisas. Nada é perfeito.

javamaniaco:

Quanto mais leio isso daqui, mais percebo que os que defendem Scrum em tudo, não lidam com clientes diretamente e não costumam trabalhar com uma demanda de softwares especificamente não comerciais (softwares de cruds e reports).
Sérgio e o outro ai que parece um papagaio do Sergio, lamento mas passando suas referências não indicam nada. Vai explicar pro cliente porque aquela feature que ele quer, devido as interações, ele não pode ter porque não vai dar tempo de tudo.

Vc só sabe dizer isso. Eu acho que vc tentou usar um scrum meia boca um dia e tentou levar a serio e confrontar o cliente e levou a maior bronca da sua vida por isso e ai vc culpa o scrum por isso e tem mágoa do scrum.
E ai vc desconta em mim e no scrum a sua incapcidade de se impor aos clientes. Parece até que você era gerente e agora é apenas um programadorzinho que ningeum houve.
Espero que seja isso, porque se vc nunca usou scrum e nunca confrontou o cliente dessa maneira não seria ético afirmar que não é possivel negar coisas ao cliente e que scrum não funciona.
conte-nos a sua experiencia com scrum para não cairmos nos mesmos erros.

Você vai nos mostrar uma referencia suportanto essa afirmação. Não vai ? Esperamos por ela então. Porque sem isso, isso não passa de conversa fiada.

Só gostaria de saber qual métrica/equação matemática aplicada em demanda pode nos trazer uma PRECISÃO ANTECIPADA de prazos quando se trata de desenvolvimento de software, descartando assim o que conhecemos hoje como meras estimatívas.

Se isso existir, eu desconheço.

(Prentice Hall) - Agile Estimating and Planning (2005) , estou lendo esse obra e estou achando bem interessante.

“Planning is everything. Plans are nothing.”
“Field Marshal Helmuth Graf von Moltke”

Só gostaria de saber qual métrica/equação matemática aplicada em demanda pode nos trazer uma PRECISÃO ANTECIPADA de prazos quando se trata de desenvolvimento de software, descartando assim o que conhecemos hoje como meras estimatívas.

Se isso existir, eu desconheço.
Mas é isso que to tentando falar pro Sergio, não existe. Uma precisão de demanda como existe em outras áreas não são aplicáveis ao software, logo, um prazo fixo sem capacidade de previsão certa do tempo que vai transcorrer o projeto, não dá pra sair adotando Scrum como metodologia única e esperar que o prazo finde certinho, como se nenhum imprevisto ocorresse e pior, em todos os casos ocorrem, mas as margens de erro sem uma lógica de demanda mais precisa causam catástrofes. É simplesmente estimar pela experiência, mais nada.

Cara, achei um lugar no Youtube muito apropriado chamado NoiseCall!
Olha que iniciativa legal para quem gosta de Produzir, Tocar ou Escutar novos sons:
http://www.youtube.com/watch?v=QFEcG2tQx7M
Acho que vale a pena a gente repassar ideias assim que rolam na net.
FALOW!!!