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

Assuntos Gerais Notícias
#101

[quote=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.
[/quote]

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

#102

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.

#103

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.

#104

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

#105

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

#106

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

#107

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 !!!

#108

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

[/quote]

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.

#109

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.

#110

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…

#111

[quote]
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! [/quote]
Isso não é uma justificativa técnica observável.

[quote]
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![][/quote]
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.

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 !!!

#112

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
ericgomes@octavarium.com.br

#113

[quote=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
ericgomes@octavarium.com.br
www.octavarium.com.br[/quote]

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.

#114

[quote=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 !!![/quote]

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

#115

[quote=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.[/quote]

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
ericgomes@octavarium.com.br

#116

[quote=mochuara][quote=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 !!![/quote]

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

  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.

#117

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.

#118

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
ericgomes@octavarium.com.br

#119

[quote=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 !!![/quote]

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!

#120

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.