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!
[quote=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! [/quote]
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
[quote=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.
[/quote]
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?
[/quote]
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.
[quote=Guerr@][quote=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.
[/quote]
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…
[/quote]
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.
[quote=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… [/quote]
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.
[quote=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.
[/quote]
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
[quote=Guerr@][quote=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.
[/quote]
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…
[/quote]
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.
[quote=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.
[/quote]
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 (artigos@mundojava.com.br) 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?
[quote=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?[/quote]
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!
[quote=sergiotaborda][quote=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?[/quote]
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.” [/quote]
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