Será que ser radical hoje em software é considerado crítica ou elogio? :lol:
Mas falando sério, pra mim radical é quem fala que agile não é 100% eficiente e tem seu pontos fracos (e pior, não sabe apontar qual, demonstrando ainda que é ignorante).
Qual é, entusiasmo é bem vindo em todas metodologias. Só que em processos arcaicos como RUP o mais divertido acaba sendo as reuniões onde os gerentes tentam te fazer acreditar que o produto é um sucesso mesmo ele não tendo sido lançado ainda! Alias, gerentes são entusiastas em querer adquirir cada vez mais entusiastas para sua mais nova grande idéia que ira continuar entusiasmando o mundo. Mas eu desconfiaria de processos que tem reuniões como único motivador de equipes.
Mas para o estado do agile eu penso que é bom esse tido de gente pois ela costuma ser mais vocal. A verdade é que a grande maioria de nós que produz software e portanto se beneficia de agile de verdade não esta preocupado com o que seria uma imagem do agile (!) para o resto do mundo.
[quote=sergiotaborda][quote=André Fonseca]
se as empresas perdem dinheiro e continuam fazendo isso a muito tempo então tem duas alternativas, ou não aprenderam até hoje ou então alguém está ganhando dinheiro - consultorias, novos projetos, manutenções, etc, etc[/quote]
Repare, temos as empresas produtoras. Estas não estão perdendo dinheiro já que estão chupando ele das empresas “clientes”.
São as empresas clientes que têm que acordar e ver que estão levando um boa noite cinderela desde do principio do anos 90.[/quote]
[quote=sergiotaborda][quote=André Fonseca]
se as empresas perdem dinheiro e continuam fazendo isso a muito tempo então tem duas alternativas, ou não aprenderam até hoje ou então alguém está ganhando dinheiro - consultorias, novos projetos, manutenções, etc, etc[/quote]
Repare, temos as empresas produtoras. Estas não estão perdendo dinheiro já que estão chupando ele das empresas “clientes”.
São as empresas clientes que têm que acordar e ver que estão levando um boa noite cinderela desde do principio do anos 90.[/quote]
Acho que é mais um longo casamento de interesses onde um provavelmente estaria pior sem o outro.
Alexandre Magno b[/b] - [color=red]O palestrante teve problemas pessoais e infelizmente não poderá comparecer. Lamentamos o inconveniente.[/color]
A morte do Scrum começa a ser anunciada pela comunidade. Não são poucos os artigos e posts que falam que Scrum não o tornará ágil, e pior, que o Scrum o fará achar ser ágil sem o ser de fato. Mas afinal, se ao usar Extreme Programming eu já uso Scrum, por que Scrum existe? E ao usar Scrum + XP, serei ágil de fato? Nesta apresentação o palestrante questionará o papel que Scrum tem exercido dentro do mundo ágil e avaliará o lado positivo e negativo dos fatos.
Vejam as coisas mudam e mudam muito rápido mesmo, é o que só vem a afirmar “Ágil é uma maneira de Pensar”
Scrum é voltado para gerenciamento e funciona mesmo fora do mundo de software (basta referir que foi inventado na industria automovel). XP é voltado para desenvolvimento.
Sendo que as duas são ageis as duas aplicam a permissa : a unica coisa que temos a certeza é que software evolui e o respeito a valores. Valores são quase os mesmos, mas os de XP são voltados para o desenvolvimento. Por exemplo, a partilha de codigo.
O codigo é de todos, não apenas de um. todos têm direito a mudar qualquer código a qualquer momento. São valores que só fazem sentido em desenvolvimento.
Como ja foi dito as bases das práticas agil vêm de antes. Por isso tanto xp como scrum beberam das mesmas fontes.
Só que scrum foca em gerenciar o projeto, não o codigo. Ele tenta estimar tamanho, custo,prazo, etc… tudo de forma agil.
XP apenas foca em executar o projeto. Os dois casam bem porque partem da mesma base.
XP se sobrepoe um pouco a scrum porque tenta colmatar os problemas gerencias das metodologias gerenciais tradicionais que não são compativeis com XP.
Na prática se vc usar os dois , cada um na sua área, não tem espaço para falha.
O legal do scrum é que pode ser usado em qq nivel da empresa,em qq tipo de time (marketing, vendas, sei lá…) e por isso se fala do scrum of scrums que seria a resposta agil a quem quer “hierarquia”
[quote=mochuara]
Mas para o estado do agile eu penso que é bom esse tido de gente pois ela costuma ser mais vocal. A verdade é que a grande maioria de nós que produz software e portanto se beneficia de agile de verdade não esta preocupado com o que seria uma imagem do agile (!) para o resto do mundo.[/quote]
Eu tbm pensava assim quando trabalhava com agile. Mudei para uma empresa que dizia ser agil, vi que nao era e pensei que podia ajuda-la a se tornar. Triste engano.
Mas nós temos a mania de atirar pedras nos gerentes e diretores, culpando-os por nao quererem agilidade e ficarem amarrados em processos atrasados que nao levam a lugar nenhum. Mas a grande culpa da metodologia ainda nao ter engrenado é dos desenvolvedores mesmo.
Um exemplo simples, que provavelmente ocorre na maioria das empresas de desenvolvimento, grande, medias ou pequenas: aqui onde trabalho, a primeira vez que a maioria dos programadores ouviu falar em TDD foi da minha boca, ha no maximo seis meses atras, e mesmo assim ainda nao consegui introduzir o conceito como regra para o desenvolvimento. E dizem que usam Scrum.
Ora, aí se perguntam por que uns dizem que Scrum tem que morrer.
Tenho acompanhado o tópico, mas não entendi esse seu ultimo comentário marcos.
O que vc quer dizer? que os desenvolvedores não devem procurar melhores ambientes de trabalho, já que é sempre a mesma música que toca, independente do lugar ou que vc não acredita que ambientes ágeis são melhores para se trabalhar?
O problema de RUP, CMMI, PUK, PMBOX, é que elas são muito lentas para responder ao mercado competitivo de TI. As grandes empresas sem duvida podem se beneficiar de praticas ageis no seu processo mas dificilmente o fazem por que vai contra todo o status quo já estabelecido que é de parar pra estabelecer objetivos, discutir taticas para cumprir esses objetivos, o problema disso é que geralmente são estimativas construidas sobre base tão sólida como gelatina. No final, havendo caixa, é mais facil comprar o concorrente, uma startup que usa metodologias ageis.
[quote=marcosalex][quote=sergiotaborda]
A questão é que ninguém segue!
Como disse, agilidade é uma forma de pensar. Se vc pensa agil vc pode ser agil até com RUP.
[/quote]
Se ninguém segue, nem agile resolve. :lol: :lol:
[/quote]
Ai é que está. Se vc é agil, vc segue, e ai resolve. Agil é seguir valores. Que é exactamente o que falta
no desenvolvimento de software.
Ora exactamente porque elas usam é que são chamadas assim. Essa sua frase é um tautologia.
Só dá para entender agil vs tradicional se falarmos do tradicional. Chama-se argumentação por contra-posição.
Não, escolhi certo. Exactamente porque a MS tem problemas que ela vale menos. Eu disse “vale” e não “lucra”. Quem quer comprar a microsoft ? e quem quer comprar o google ?
Primeiro o chrome é feito com TDD ?
Segundo o chrome é um beta , ou seja, oficialmente ainda não está pronto. Esse é exactamente o conceito. Ele só está pronto e oficialmente entregue quando tiver zero bugs.
Não é a palavra. É o que ela representa. Não são todos os problemas do mundo. São todos os problemas do mundo do desenvolvimento de software.
As suas frases são tautologias. É claro que é obvio e que scrum , xp e lean (que são tudo metodologias ageis) se baseiam nisso.
Quem não se baseia nisso são as metodologias burucráticas que se usam na prática nestes 50 anos.
Se nestes 50 anos em que é obvio que se deve ser agil não se usou isso, nem se tirou partido disso, e pelo contrário se instituicionalizou um mecanismo burucrático que nada tem a ver com nada e que só enche o saco dos desenvolvedores e dos clientes algo está muito errado. O que está muito errado é clientes e desenvolvedores deixarem isso ser assim. Existe uma razão porque a palavra manifesto é usada em “manifesto agil”. Não é apenas uma afirmação , é um pedido de mudança.
Complementando a resposta do Marcos, aqui foi muito comparado o modelo ágil ao cascata. Entretanto, existem diversos modelos de desenvolvimento, entre eles:
Voce pode por um resumo pra gente de como voces trabalham ai na sua empresa, Marcos, como funciona o processo desde a coleta dos requisitos ate o ultimo release? Como voce divide as tarefas? como integra o processo? Como faz a integracao do trabalho dos desenvolvedores? de que forma os testes unitarios sao realizados, com quais frameworks? Qual o tipo de documentacao que gera? Como reage as alteracoes de ultima hora do cliente? Como define as prioridades do projeto, do que vai ser entregue?
Essa conversa de “Nao, nao somos waterfall, somos ‘quase’ Scrum, eu escuto sempre” e embora ninguem aceite esse termo, é o que se ve na maioria do casos, por mais que os gerentes tentem negar. Sempre a mesma historia e quando vao argumentar é sempre com os mesmos velhos argumentos.
[quote=marcosalex][quote=sergiotaborda]
Ai é que está. Se vc é agil, vc segue, e ai resolve.
[/quote]
Ué, toda metologia é assim.
[/quote]
Não. Primeiro que Agil não é uma metodologia, e segundo que nenhuma metodologia tem como pilar fundamental valores.
Por outro lado, se por alguma razão obscura vc acha que as metodologias tradicionais são baseadas em valores como Abertura, Comprometimento, Foco e principalmente Respeito e Coragem então elas falharam redondamente porque na prática ninguem pratica esses valores. Se chamadas fábricas de software, em que o software é tratado como imutável e que pode ser planejado até o ultimo detalhes em UML antes de um desenvolvedor sequer ser consultado, são o resultado dessas metodologias pré-agil que defendiam esses valores então ou essas metodologias são um lixo, ou a sua implementação é um lixo, ou ambos.
O ponto da conversa é o que o ágil traz a mais. O que traz a mais é o seguimento de valores que não são seguido no dia a dia da maioria das produtoras de software internas e externas. E isto, pasme-se,é um fenomeno mundial. Não é só no Brasil que se está fazendo software de forma ruim, é em todo o lugar.
Vc insiste em mostrar números. Valor não é numérico.
Saber a diferença é fundamental. Porque quando se fala em agregar valor, não se está falando em aumentar o preço.
O Google tem mais valor porque é um player que dá cartas. Ele não fica simplesmente assistindo e copiando como a MS.
O Google mandou o mobile para a estratosfera com o android , disponibilizou mapas para o mundo inteiro , do mundo inteiro e até da lua. Quer digitalizar todos os livros do planeta e até se meteu a construir carros ecologicamente corretos. Além das ferramentas , API e serviços que todos conhecem… e a MS ? Corre atraz do prejuizo do windows vista , da rede .NET (não o framework), lançou um tal de blink e vai lançar um tal de windows 7. O zune é uma copia ruim do ipod que não deu certo. Resumindo, a MS pode faturar mais (pq cobra mais caro!!), mas ela parou no tempo. A visibilidade é menor. Ninguem mais tem medo ou respeito pela MS como antes e tem até gente falando que ela será comprada.
Se o que vc diz é verdade, então temos que concluir que a Google é uma empresa meia-boca. O que é verdade de qualquer jeito e mesmo se o chrome não tivesse bugs. O ponto não são os bugs do chorme. O ponto é entregar sistemas com bugs conhecidos.
quanto dos bugs do chrome eram conhecidos e não resolvidos na entrega da versão 1?
Quando vc entrega um software vc o testou ? Testou mesmo ? para valer ? até o osso ? Se sim, vc resolveu todos os bugs ? então vc está de consciencia tranquila. quem faz o que pode, a mais não é obrigado.
Se um bug acontece depois (alguns acontecem por diferenças do ecosistema onde o sistema é instalado ) é uma falha honesta. Vc fez tudo ao seu alcance para detectar o bug, mas não pegou esse… et lasse.
Agora a outra situação é vc ter descoberto o bug e não o resolver antes da entrega. É isso que não é honesto.
Encontre o bug como quiser, TDD ou sem TDD , mas encontre.
Depois de encontrado, resolva-o. Resolver é tão importante como encontrar.
Se o seu sistema tem 1000 bugs, 3000 bugs , 10000 bugs na lista, abertos, num dado momento, algo está errado na sua equipa de desenvolvimento ou na sua metodologia, ou ambos. Se vc tem 30000 bugs na lista, mas todos estão fechados, vc está funcionado perfeitamente.
Isso não faz nenhum sentido. como é que o passado pode usar o futuro ?
Se vc está falando de ferramentas como planning poker ou kanban, ok, isso é usado em várias metodologias ageis ou não.
Agora , dizer que a metodologia em si é usada antes não faz sentido. Mas sinta-se livre de dar exemplos.
Por exemplo, que metodologia usava Scrum ? Qual usava XP ?
Se até a IBM mudou o seu RUP para o OpenUP porque quer ser agil , não faz muito sentido dizer que RUP é ágil. (embora como eu já disse agil não seja uma metodologia em si)
O que lhe posso dizer é que se alguem já trabalhou assim , e não trabalha mais, então essa forma de trabalhar não era agil. Pela simples razão que se fosse, as pessoas teriam coragem para não deixar mudar as coisas.
O gerente burrocratas que tomaram conta das 'fábricas de software" só pegaram esse lugar porque alguem deixou.Se deixou é pq não tinha coragem para enfrentar essa burrocracia. E se não tinha coragem, se isso não era valorizado, se a pessoa não podia se expressar livremente e colocar em causa essas más práticas, então não existia agil para começo de conversa. Onde existe agil, ha coragem e abertura para mandar esses burrocratas catarem coquinho…
Se os desenvolvedores do seculo passado - a velha guarda - se deixou enganar shame on them. Mas quem desenvolve agora tem que aguentar um sistema que esses desenvolvedores ajudaram a construir. Foram coniventes com a burrocracia e o foram por falta de coragem e repeito para com a profissão e os outros profissionais e até para com os clientes. Quer que eu acredite que existia um paraiso antigamente ? então alguem tem que ser culpado por ele não existir mais ! e quem vão ser esses culpados a não ser quem desenvolvia nessa epoca e deixou as coisas chegararem no nivel que estão hoje ?
Vc quer passar a ideia de que agil não é novidade e que não é bala de prata. Tlv para um culpado pelo sistema atual isso seja a forma de amenizar o problema,porque ele sabe que a bala é para ele. A bala sim é para ele. Todos aqueles que ainda desenvolvem no métodos burrocráticos e imbecis que totalmente violam o profissionalismo e assediam as pessoas moralmente diáriamente sim têm que ser eliminados.
Se agil não é essa bala de prata que matará estes monstruoso sugadores de recursos algo melhor virá. Mas virá. E virá rapidamente porque os desenvolvedores deste século já perceberam que estão sendo enganados.
Quem aqui conhece um gerente que foi despedido porque o projeto atrazou ? E quem aqui conhece projetos que não atrazaram ?
ah!, detalhe, o projeto atrazou assim que alguem sugerir que se façam horas extra.
Vai-nos fazer acreditar que tudo está bem no mundo do desenvolvimento de software ? Ora! ninguem aqui acredita nisso.
Isso é simplesmente mentira. Ninguem que eu conheça trabalha com essa hipotese, muito menos sempre. Logo, nem todo o mundo trabalha com ela sempre.
E muitas outras pessoas que eu conheço tb não conhecem ninguem. Aliás , alguem conhece alguém que sempre trabalha com essa hipotese?
Mesmo que alguns trabalham assim, esses alguns não são a maioria e não têm representatividade para podermos dizer que essa é a norma em desenvolvimento de software. A norma é o gerente não planejar, prometer o que o cliente perguntou e esfolar os desenvolvedores. Vai dizer que é mentira ? Vai dizer que agil não é diferente disso ? Que tautologia vc vai inventar agora para dizer que não devemos seguir agil ?
Nao, nao entendi. Leia o texto do Rodrigo Yoshima, para o qual eu pus o link no meu ultimo post e voce vai entender porque eu nao entendi.
Nao conheco uma empresa que utilize, de fato, qualquer metodologia agil e se denomine fabrica de software. Algumas gostam do termo e o anunciam em algum lugar, mas nem sabem o que significa. É assim em absolutamente TODAS as que conheci, por mim mesmo ou por descricao de amigos. O termo fabrica de software nos remete, e é o que essas empresas pregam, a linhas de montagem de software, ou seja, é furada.
Isso é absurdo. As empresas vem ha anos tentando lutar contra a mudanca, buscando formas de neutralizar essas mudancas, tentando pregar que o problema esta na coleta dos requisitos, que os “analistas” precisam saber “tirar” do cliente a informacao precisa. Pregando que os cliente sao responsaveis por um requisito mal formulado, fazendo-os inclusive assinar, registrar, lavrar em cartorio, um termo dizendo, olha esse é o requisito, se precisar mudar a culpa é minha.
E voce vem me dizer que todo mundo sempre trabalhou com essa hipotese? Se isso fosse verdade provavelmente nao estariamos discutindo aqui.
Não, já disse nos outros posts que não estou defendendo as metodologias tradicionais. Vide respostas anteriores que você deve ter pulado.
E “ninguém pratica” da mesma forma que “todo mundo faz” são termos vazios. Quem generaliza é porque falta argumentos. Será seu caso?
[/quote]
[/quote]
Não. o meu caso é falta de paciência mesmo… vc não entendeu , ou finge que não entendeu, distorce o que eu disse, responde a algo que eu não perguntei e fica nesse ciclo idiota.
Mostre-me os numeros.
O que acontece é que muitas dizem usar e publicitam que usam, mas na realidade é só uma mascara para a mesma burrocracia de sempre. Como não ha nenhuma entidade que certifique que é verdade cada um pode dizer o que quiser…
Concordo que ha muitos que dizem ser e usar, mas o problema é que é mentira que sejam e usem.
Fábrica de software não é toda a empresa que produz software. É um termo prejorativo mesmo. O termo normal é Software House que pode traduzir para Produtora de Software ou Casa de Software. Fábrica de Software designa um tipo especifico de processo de criação de software e não se restringe a empresas que produzem ondemand. Empresas que produzem software internamente tb têm fábricas de software ( aliás quanto mais CLT mais fábrica é).
Diga-me o nome de uma ou duas empresas nacionais que produzem software on demand (para clientes) usando Scrum. E me mostre o depoimento de pessoas que trabalham lá e atestam que é verdade. Curiosidade…
O ponto não é , mais uma vez para ver se vc entende - se existe ou não existe, se já era usado ou não era usado.
O ponto é que enquanto existirem empresas que seguem politicas abjetas, imorais e não profissionais para a criação de software, temos um problema grave. Enquanto existirem empresas que xulam os seus desenvolvedores, teremos problemas. Enquanto a qualidade for negociável, teremos problema. enquanto os desenvolvedores forem tratados como peoes teremos problema.
Existem muitos problemas no desenvolvimento de software que eu e muitos vivemos no dia a dia. Isso é a realidade. sim existem gerentes malvados. E se vc nunca encontrou um, sorte sua. Não é mito. É real. Existe imbecis mentecaptos interferindo com a profissão e a vida de desenvolvedore pelo mundo inteiro pela simples razão que eles nunca são responsabilizados por coisa alguma.
É impossivel usar agil e não ser responsabilizado. É por isso que agil é a esperança para acabar com essa raça de fraudadores.
Quando um cara se passa por médico é preso por falsidade ideologia. Mas quando se passa por gerente de projeto de software nunca lhe acontece nada. É isto que tem que mudar. E agil é uma a solução. É a que temos agora.
Se o seu ponto não é contra agil , nem a favor das metologias tradicionais, afinal o que vc está defendendo ?
Que agil já existe ha 50 anos ? Essa tem até graça pelo anacronismo. Mas sinta-se à vontade de mostrar como agil existe e é prática comum em todas as produtoras de software ha 50 anos.
[quote=marcosalex]
Eu disse que não devemos seguir agil? Só disse que ele não é novidade. Se você está mudando o que eu disse, acho que o problema não está comigo, ou está?
E essa sua “norma do gerente de software” é que está 50 anos defasada. Se existe algum que faz assim, é minoria faz anos. Fala a verdade, seja sincero: você sabe disso mas não quer dar o braço a torcer.[/quote]
Discordo. Fabrica de software continua sendo uma aberração bastante comum. Pra piorar agile ta na moda e ganha cada vez mais novos especialistas dizendo que agile tb tem analista, que é tudo a mesma coisa, etc. Acho que não é questão de dar o braço a torcer, até porque sem números pra basear sua afirmação que enterprise software no brasil é agil só pode ser piada.