Concordo que a dificuldade em se utilizar scrum e metodologias está na capacidade dos desenvolvedores, ou melhor, na falta de vontade dos desenvolvedores de melhorar. Scrum, ou qualquer metodologia agil nao resolve problema algum se nao tiver como base codigo bem feito, baseado nos principio basicos OO. E dificilmente um desenvolvedor consegue este conhecimento só “trabalhando”, sem dedicar um bom tempo de estudo ao assunto.
Mas falta de desenvolvedor nao deve ser desculpa para código ruim mesmo assim.
Este é o problema, o entendimento do que se quer dizer quando se diz, fim da profissao de analista. Na verdade quer dizer fim do programador digitador e fim do analista que programa no word. Ao contrario do que voce diz, eu acho um absurdo pagar duas pessoas para fazerem o que uma pode fazer.
Se o desenvolvedor não pode atender o cliente porque está trabalhando em outro projeto é um sinal obvio de que precisa de outro(s) desenvolvedor, não que precisa de uma analista e um desenvolvedor. Até porque dificilmente este analista vai passar todos os dias o dia todo em reuniao, atendendo o cliente. Ele vai e depois vem “modelar” o sistema, ou seja, fazer o que o programador deveria estar fazendo.
Sim, esta realidade que voce citou existe, mas só nas empresas que nao tem competencia pra trabalhar com outro modelo.
O mercado vai acabar se adaptando as coisas que funcionam cedo ou tarde, quem ve essas coisas antes leva vantagem.
E sobre o modelo de fabrica de software é algo impossivel de funcionar porque despreza uma constante em desenvolvimento de software: mudanca de requisitos.
Na minha opinião um dos maiores erros dos agilistas é justamente tentar prever o futuro como se ele fosse certo quanto um calculod e matemática. Não é.
Dizer que o futuro é X ou Y é pura ilusão. Ninguém sabe ao certo como as coisas vao desenrolar devido a quantidade de variaveis envolvidas.
É muito bonito na teoria falar sobre desenvolvedores capacitados, código bem feito, facilidade de manutenção, integração entre a equipe, clientes aliados e etc.
Na pratica isso não é comum. Na pratica temos uma grande quantidade de desenvolvedores fraquissimos que não possuem a qualificação necessária para entrar em um time scrum que dê certo.
A falta de desenvolvedor não deve ser desculpa para um código ruim, por isso mesmo algumas empresas tentam contornar esse problema melhorando seus processos. Novamente, se isso é a solução, se é por aí que as empresas devem seguir, esse é outro ponto. Estou falando do que ocorre na prática. Por isso algumas empresas viram, de certa forma, na espefcialização das atividades e o foco no processo como a solução para a falta de profissional capacitado. Daí vem a idéia das fabricas, que estão diretamente relacionadas à necessidade de se ter uma pessoa adotando um ou poucos papeis especializados. Para uma empresa que tem o processo como foco, não intersesa se tu é um desenvovledor que sabe fazer analise e etc. O que interessa é que tu faça teu papel bem feito e isso é o suficiente.
O modelo de fabrica inevitavelmente coloca algumas barreiras para as mudanças nos requisitos, porém tentam contornar isso também na organização de seus processos. A ideia é que aperfeiçoando os processos, mais eficiente será o tratamento dos requisitos.
Deixo claro que eu mesmo não compartilho da idéia de que este deveria ser o caminho que as empresas deveriam seguir, mas dizer que o futuro é o scrum é pra mim tão fora da realidade quanto acreditar que só pq algo é bom irá prevalecer.
[quote=ViniGodoy]Por essa filosofia, immortalsoul, teremos também:
Analistas mal qualificados;
Projetistas mal qualificados;
Programadores mal qualificados;
Isso com baixo feedback, gera um projeto que não tem absolutamente nada a ver com o que foi pedido.
Mesmo no caso de má qualificação, um ciclo mais iterativo ainda permite que o cliente puxe o projeto de volta aos eixos.[/quote]
Concordo em partes contigo,
porém é preciso admitir que treinar uma pessoa para fazer somente o trabalho de análise ou somente o trabalho de projeto ou de códificação é muito mais fácil e barato do que treinar um desenvolvedor completo (coisa que provavelmente levará anos). Essa é alguma das grandes vantagens (na visão de alguns gestores) da adoção das fabricas.
Veja que eu disse que o treinamento é mais fácil e mais barato, mas não que trará mais beneficios ou com maior qualidade( seja a curto ou longo prazo). Na verdade esses gestores tentam fazer um equilibrio desta qualidade com o custo e o tempo, o que de certo modo faz sentido.
A função varia de empresa para empresa, mas geralmente um Analista De Sistemas não fica codificando sistema não, para isto criou o papel de Analista de Desenvolvimento que seria um programador de nível superior, a bagunça e grande como eu disse vai de empresa para empresa, de estrutura para estrutura, mas de forma geral o Analista trabalha com Requisitos é Diagramas, fluxograma e um termo antigo que foi substituído…
Já o Gerente de Projetos cuida mais da parte de Métricas, Medições, Cronogramas, como o nome fala e a parte mais gerencial, os gerentes de projetos que eu conheço sabem programar, mas não o fazem no seu dia a dia.
quer ser analista mas não sabe o que um analista faz???
po, não leva a mal não mais… até lembrei do tiririca agora…
quanto a o que um analista faz, isso varia muuuito de empresa para empresa, de um modo geral é ele quem faz aquela analise de requisitos, conversa com o cliente para identificar o que entra no sistema e o que não… sendo assim ele tende também a fazer fluxogramas em muitas empresas, outras não, apresentações, é ele quem costuma criar as documentações de software… por ai vai…
[quote=immortalSoul]
Veja que eu disse que o treinamento é mais fácil e mais barato, mas não que trará mais beneficios ou com maior qualidade( seja a curto ou longo prazo). Na verdade esses gestores tentam fazer um equilibrio desta qualidade com o custo e o tempo, o que de certo modo faz sentido.[/quote]
Nao faz o menor sentido porque o custo e o tempo de um projeto agil com uma equipe boa é invariavelmente menor do que qualquer processo burocratico, com hierarquia rigida como as que voce esta usando como exemplo.
Na verdade é que esses gestores nao conhecem outra forma de trabalhar que nao a deles, na maioria. Mas eles vao gostar de qualquer coisa que de a eles menor tempo de desenvolvimento e menor custo do produto.
Nao adotar metodologias ageis em uma empresa não é culpa dos diretores, é culpa dos desenvolvedores que, ou nao tem experiencia suficiente para conduzir um projeto agil, ou não tem iniciativa pra isso. As empresas que tem desenvolvedores com experiencia e iniciativa estao se tornando ageis.
[quote=YvGa][quote=immortalSoul]
Veja que eu disse que o treinamento é mais fácil e mais barato, mas não que trará mais beneficios ou com maior qualidade( seja a curto ou longo prazo). Na verdade esses gestores tentam fazer um equilibrio desta qualidade com o custo e o tempo, o que de certo modo faz sentido.[/quote]
Nao faz o menor sentido porque o custo e o tempo de um projeto agil com uma equipe boa é invariavelmente menor do que qualquer processo burocratico, com hierarquia rigida como as que voce esta usando como exemplo.
Na verdade é que esses gestores nao conhecem outra forma de trabalhar que nao a deles, na maioria. Mas eles vao gostar de qualquer coisa que de a eles menor tempo de desenvolvimento e menor custo do produto.
Nao adotar metodologias ageis em uma empresa não é culpa dos diretores, é culpa dos desenvolvedores que, ou nao tem experiencia suficiente para conduzir um projeto agil, ou não tem iniciativa pra isso. As empresas que tem desenvolvedores com experiencia e iniciativa estao se tornando ageis.[/quote]
Como eu disse, tudo muito bonito na teoria.
Agora imagina um mero desenvolvedor chegar em um diretor de uma grande empresa afirmando que conhece uma forma mais eficiente do que os processos que a empresa adota ( ou começou a adotar).Em outras palavras tu estaria dizendo: Joga fora esses processos que vc investiu milhoes para colocar em pratica e que levou alguns anos e começa a utilizar esse processo aqui que é bem mais interessante. Mesmo que tu tenha razão, é inevitavel que exista uma certa ( certa nao, grande mesmo) resistencia por parte deste diretor.
Tu pode ser o cara mais certo do mundo, mas se põe no lugar dele. Não estou dizendo que é impossível, mas só o fato de tu conseguir falar com um diretor de uma grande empresa já pode ser considerado um feito. Conseguir convencer de que tu ta certo e de que todo o resto da empresa está errada… Como eu disse, não é impossível, mas é algo bastante incomum.
Sem falar que qualquer mudança simples em empresas deste tipo é algo monstruoso. Quase inacreditavel. Agora multiplica essa dificuldade por 100 pois aqui a necessidade é de se alterar a cultura da empresa. Não gosto de parecer pessimista, mas essa é a realidade.
ok, isso é só um ponto.
O outro ponto é que um processo burocratico ( lembrando não devemos ver burocracia como algo necessariamente ruim) traz uma certa segurança para os gestores. Ok. Pode dizer que essa segurança é ilusória, mas aqui estamos em mundo real onde a ilusão também tem sua importancia, principalmente quando estamos tentando perceber o futuro.
A questao do futuro destes processos não é exato como uma conta matematica. Anunciar a morte do analista hoje em dia é totalmente precipitado. O tal do “rejeito a realidade e substituo pela minha” não ajuda em muita coisa também.
Mais uma coisa relacionado ao assunto incial do tópico.
Quem acha que ser analista é uma especie de evolução do programador, está completamente enganado. Tanto quanto quem acha o contrário.
É incrível como programador/desenvolvedor frequentemente tem uma visão elevada de sua função e de seu conhecimento. Grande parte é tão estrela que até esquece que tem que andar com os pés no chão. Valorizam demais o conhecimento técnico, ao ponto de limitar sua mente a achar que é só isso que importa. Já vi muita gente aqui criticando o analista por não saber programar. Ainda não perceberam que esse conhecimento técnico é uma necessidade muito especifica da situação. Hoje saber configurar o spring, hibernates e todas essas tecnologias que em teoria surgem para facilitar ( mas em java eu acho que acontece o contrário ) a vida do programador só servirá por um tempo e para determinada situações.
Nem tudo na área de informatica gira em torno de porogramação. Um bom analista não precisa saber programar, assim como um bom programador não precisa saber de redes. Claro que não estou falando de um conhecimento superficial de TI, pois esse todos devem ter, independente mesmo se for da área de TI ou não. Veja as provas de concursos públicos para entender do que estou falando.
Volto a dizer que isso não tem nenhuma relação com o processo de desenvolvimento adotado, seja fabrica ou seja agil.
As pessoas tendem a confundir e acham que por estar em uma equipe ágil ela necessáriamente deve saber de tudo. Não concordo com essa visão. Nada impede eu compor minha equipe com um analista que não sabe programar, principalmente se eu sentir uma certa deficiencia do resto da equipe nesta parte. O mesmo serve para outros papeis como do DBA e etc… tudo depende do projeto e cada caso é um caso.
Uma coisa é fato. A informatização só é realmente efetiva se a empresa em questão estiver disposta a rever seus processos.
Caso contrário, só automatizamos a burocracia. E isso não deixa com que a informática penetre com todo potencial na empresa.
Computadores existem também para simplificar o processo, não só para automatizá-lo.
[quote=immortalSoul]
Como eu disse, tudo muito bonito na teoria.
Agora imagina um mero desenvolvedor chegar em um diretor de uma grande empresa afirmando que conhece uma forma mais eficiente do que os processos que a empresa adota ( ou começou a adotar).Em outras palavras tu estaria dizendo: Joga fora esses processos que vc investiu milhoes para colocar em pratica e que levou alguns anos e começa a utilizar esse processo aqui que é bem mais interessante. Mesmo que tu tenha razão, é inevitavel que exista uma certa ( certa nao, grande mesmo) resistencia por parte deste diretor.
Tu pode ser o cara mais certo do mundo, mas se põe no lugar dele. Não estou dizendo que é impossível, mas só o fato de tu conseguir falar com um diretor de uma grande empresa já pode ser considerado um feito. Conseguir convencer de que tu ta certo e de que todo o resto da empresa está errada… Como eu disse, não é impossível, mas é algo bastante incomum.
Sem falar que qualquer mudança simples em empresas deste tipo é algo monstruoso. Quase inacreditavel. Agora multiplica essa dificuldade por 100 pois aqui a necessidade é de se alterar a cultura da empresa. Não gosto de parecer pessimista, mas essa é a realidade.
ok, isso é só um ponto.
O outro ponto é que um processo burocratico ( lembrando não devemos ver burocracia como algo necessariamente ruim) traz uma certa segurança para os gestores. Ok. Pode dizer que essa segurança é ilusória, mas aqui estamos em mundo real onde a ilusão também tem sua importancia, principalmente quando estamos tentando perceber o futuro.
A questao do futuro destes processos não é exato como uma conta matematica. Anunciar a morte do analista hoje em dia é totalmente precipitado. O tal do “rejeito a realidade e substituo pela minha” não ajuda em muita coisa também.[/quote]
Se todos pensassem assim estariamos nas cavernas ainda. Essa ideia do “Ah, isso nao vai dar certo” é uma coisa que os diretores normalmente nao tem. Embora muitos erroneamente acham que tem. Em media, os diretores de empresas de TI (nao estou falando de gerentes de projeto) são mais competentes em suas profissões do que os desenvolvedores e analistas juntos.
O caso não é voce chegar com blablabla para eles supondo um mundo imaginario, voce tem que MOSTRAR COMO e porque funciona, só na teoria voce nao vai conseguir convencer ninguem. E é nesse MOSTRAR que mora o problema. Quem sabe fazer isso?
[quote=immortalSoul]Mais uma coisa relacionado ao assunto incial do tópico.
Quem acha que ser analista é uma especie de evolução do programador, está completamente enganado. Tanto quanto quem acha o contrário.
É incrível como programador/desenvolvedor frequentemente tem uma visão elevada de sua função e de seu conhecimento. Grande parte é tão estrela que até esquece que tem que andar com os pés no chão. Valorizam demais o conhecimento técnico, ao ponto de limitar sua mente a achar que é só isso que importa. Já vi muita gente aqui criticando o analista por não saber programar. Ainda não perceberam que esse conhecimento técnico é uma necessidade muito especifica da situação. Hoje saber configurar o spring, hibernates e todas essas tecnologias que em teoria surgem para facilitar ( mas em java eu acho que acontece o contrário ) a vida do programador só servirá por um tempo e para determinada situações.
[/quote]
Por ferramentas pra funcionar sem saber pra que não é sinonimo de conhecimento técnico, muito pelo contrário. Spring e hibernate facilitam muito a vida do programador. Se não facilitar é porque voce nao precisa delas. E sinceramente, hoje em dia, dizer que trabalha com java e nao precisa delas já é algo que me faz torcer o nariz. O código ao qual voce se refere deve ser extremamente procedural, com muita duplicacao de código, muitos módulo extremamente acoplados entre si e etc… Sinal evidente de programadores medianos e analistas medianos. Pois não há possibilidade do Hibernate (ou algum de seus concorrentes) complicar um bom modelo orientado a objetos criado pelo grande analista. Provavelmente a coisa ja vem torta de la. E tambem nao há como o Spring complicar alguma coisa se ele foi feito pra integrar partes distintas, deixando o código mais limpo e facilitando os testes. Se ele complica é sinal evidente de programador meia-boca.
Se voce tem uma deficiencia de sua equipe na parte de analise voce vai por alguem que nao tem a menor nocao de programacao pra salvar isso?
Melhorar a sua equipe nem pensar né?
Como? voce vai me perguntar.
Esse é o problema, as empresas não conseguem avaliar candidatos, simplesmente não conseguem.
Veja bem, não estou dizendo que a pessoa deve se acomodar. Muito pelo contrário.
Estou falando exclusivamente sobre a posição do analista não programador ( ou mesmo do gerente de projeto ) hoje e no futuro. Estou também rebatendo o que foi exposto no blog, pelo menos na parte que não concordo.
aproveitando, se todos pensassem assim seria pessimo. Na verdade, se todos pensassem da mesma forma seria pessimo, independente se fosse defendendo um lado ou outro.
outro ponto, a questão da competente do diretor de TI não tem relação direta com a posição que ele adote na questão. Nem a competencia do programador, do GP, desenvolvedor ou quem quer que seja estaria diretamente relacionado com a posição que adota.
Um outro ponto improtante que deve ser considerado é que quando falamos em scrum estamos falando em mudança de cultura. A menos que tu descubra um meio de manipular a mente das pessoas, tu vai encontrar dificuldade independente do teu conhecimento ou boa vontade. As pessoas no geral parecem não se importar muito com a lei da causa-efeito, ou pelo menos não de modo previsivel.
Exemplo classico ( e adatpado): Se voce aumenta o salário por quantidade de mato cortado era de se esperar que as pessoas buscassem cortar mais mato para ganhar mais. Será? Dependendo da sociedade, da cultura e até da religião os efeitos obtidos podem ser o contrário do desejado. A solução racional no caso seria diminuir o salario destes trabalhadores. Mas mesmo isso seria impossível generalizar.
Apesar disso tem várias equipes adotando scrum e mostrando um bom resultado inicial e isso é animador. Mas é preciso não cometer o erro de generalizar esse sucesso. O scrum é possível de ser aplicado, mas para determinados ambientes, para determinadas condições e etc. Tentar generalizar e dizer que o scrum serve para qualquer situação e ambiente é ignorar completamente a realidade de alguns ambientes. Se um gestor ou diretor fizer uma escolha dessas sem fazer esse tipo de analise vai se arrepender e ainda vai sair falando que o scrum não presta. Tanto ele como todos os envolvidos no projeto.
No scrum o mais importante é a cultura que será moldada entre os integrantes da equipe e entre todos os envolvidos no projeto. Sem essa mudança cultural o scrum não vai ter resultado nenhum, ou talvez até pior do que conseguiriamos de outro modo. Com isso não estou falando de desistencia e nem que o scrum não é bom ou que é impossível de se adotar. Mas considerando todos estes aspectos é bem razoavel supor que o modelo de fabrica não vai morrer tão cedo ( e isso se morrer).
Uma coisa é falar da dificuldade de por uma metodologia agil pra funcionar, outra coisa é defender a cultura atual de grande parte das empresas.
Que não é fácil mudar a cultura eu sei, mas tem que ser mudada.
E essa historia de que “aqui isso não funciona” eu ja ouvi bastante. Se fosse de alguem que trabalha de uma forma eficiente, que entrega os projetos no prazo, e de quem o cliente está satisfeito, eu nao diria nada. Mas não era o caso de TODOS aqueles de quem ouvi o tradicional “aqui isso não funciona”. Ali nada funciona.
Se voce perguntar para um diretor de uma dessas empresas, um que não seja técnico, se ele está satisfeito com a área de desenvolvimento, eu nao tenho duvidas de que, com rarissimas exceções, eles vao dizer que não. Mas as pessoas não acreditam em metodologias porque estão fartas de ouvir que soluções mágicas vão revolucionar a área de desenvolvimento da empresa e que agora vai se tudo lindo e maravilhoso e no final das contas nada muda, só aumentam os gastos.
E por que? Resposta simples, falta de capacidade daqueles que se propoe a mudar. E nisso o Scrum não é diferente, o cara lê num blog nao sei onde que o Scrum é maravilhoso, le um artigo numa revista que fala sobre as fase do Scrum e voilá, está lá ele propondo Scrum ao seu gerente.
Mas na hora H ele nao consegue por em pratica porque ele nao tem o minimo embasamento pra isso, e o projeto volta a ser um waterfall, com um ou outro ingrediente de Scrum. Ao que se concluirá que Scrum é uma porcaria.
Se voce quer mudar, nao chegue com conversa mole. Se prepare, estude, reuna uma pequena equipe interessada para um pequeno projeto, com ou sem o aval dos superiores e mostre o resultado. O RESULTADO, não a teoria.
[quote=YvGa][quote=immortalSoul]Mais uma coisa relacionado ao assunto incial do tópico.
Quem acha que ser analista é uma especie de evolução do programador, está completamente enganado. Tanto quanto quem acha o contrário.
É incrível como programador/desenvolvedor frequentemente tem uma visão elevada de sua função e de seu conhecimento. Grande parte é tão estrela que até esquece que tem que andar com os pés no chão. Valorizam demais o conhecimento técnico, ao ponto de limitar sua mente a achar que é só isso que importa. Já vi muita gente aqui criticando o analista por não saber programar. Ainda não perceberam que esse conhecimento técnico é uma necessidade muito especifica da situação. Hoje saber configurar o spring, hibernates e todas essas tecnologias que em teoria surgem para facilitar ( mas em java eu acho que acontece o contrário ) a vida do programador só servirá por um tempo e para determinada situações.
[/quote]
Por ferramentas pra funcionar sem saber pra que não é sinonimo de conhecimento técnico, muito pelo contrário. Spring e hibernate facilitam muito a vida do programador. Se não facilitar é porque voce nao precisa delas. E sinceramente, hoje em dia, dizer que trabalha com java e nao precisa delas já é algo que me faz torcer o nariz. O código ao qual voce se refere deve ser extremamente procedural, com muita duplicacao de código, muitos módulo extremamente acoplados entre si e etc… Sinal evidente de programadores medianos e analistas medianos. Pois não há possibilidade do Hibernate (ou algum de seus concorrentes) complicar um bom modelo orientado a objetos criado pelo grande analista. Provavelmente a coisa ja vem torta de la. E tambem nao há como o Spring complicar alguma coisa se ele foi feito pra integrar partes distintas, deixando o código mais limpo e facilitando os testes. Se ele complica é sinal evidente de programador meia-boca.
Se voce tem uma deficiencia de sua equipe na parte de analise voce vai por alguem que nao tem a menor nocao de programacao pra salvar isso?
Melhorar a sua equipe nem pensar né?
Como? voce vai me perguntar.
Esse é o problema, as empresas não conseguem avaliar candidatos, simplesmente não conseguem.[/quote]
indo por partes, novamente ( e tentarei fazer minha ultima postagem aqui).
Primeiro: Hibernates. Quem acha que hibernates é uma ferramenta moderna é pq nunca ouviu falar no SQL Alchemy. Ok, sql alchemy é um ORM de outra linguagem que não tem nada a ver com JAVA, mas e daí? Conheço um cara que sabe muito de SQL alchemy, ótimo programador, mas nunca configurou um XML ( eca ) pro Hibernates ( não precisa dizer que se quiser não precisa usar XML, estou sendo sarcástico) e mal sabe dar um print ( ou melhor system.out.println ) no JAVA . Sabe o que quero dizer com isso? Que saber uma ou outra não indica o quanto o cara é capacitado como programador e muito menos como analista.
Segundo: Como eu disse, é preciso ter os pés no chão. Frequentemente programador não é o tanto quanto imagina ser. Se estou com problema em meu carro vou em um mecanico, não em um programador. Se a equipe precisa alguém para fazer o levantamento de requisitos eu devo ir atrás de um bom analista ( veja bem, a necessidade especifica desse caso teorico é a de alguem para fazer o papel do analista. Não tem pq eu ir atrás de um programador).
O problema é que a gente acaba achando que sabe fazer tudo, até contratação corretamente ( que é função RH em grande parte das empreas). O mais ironico de tudo isso é que frequentemente a área de TI é a mais mal vista de todas nas empresas. Acho que deviamos tirar uma lição disso, tentar cair um pouco na real e ver que não somos tudo isso que achamos.
Concordo plenamente que a área de TI é a mais mal vista de todas nas empresas, mas não se esqueça de que o modelo padrão que a area de TI usa atualmente para ser a mais mal vista dentro de uma empresa é justamente aquele que você esta defendendo.
E RH para contratar corretamente para um cargo técnico contribui bastante para a area de TI das empresas ser mal vista. Já participei de entrevistas em que ao final o entrevistador tinha exata noção do meu conhecimento técnico em cada um dos itens que eu apontava em meu curriculo. Alguem do RH jamais conseguiria isso.
[quote=YvGa][quote=immortalSoul]
O problema é que a gente acaba achando que sabe fazer tudo, até contratação corretamente ( que é função RH em grande parte das empreas). O mais ironico de tudo isso é que frequentemente a área de TI é a mais mal vista de todas nas empresas. Acho que deviamos tirar uma lição disso, tentar cair um pouco na real e ver que não somos tudo isso que achamos.
[/quote]
Concordo plenamente que a área de TI é a mais mal vista de todas nas empresas, mas não se esqueça de que o modelo padrão que a area de TI usa atualmente para ser a mais mal vista dentro de uma empresa é justamente aquele que você esta defendendo.
E RH para contratar corretamente para um cargo técnico contribui bastante para a area de TI das empresas ser mal vista. Já participei de entrevistas em que ao final o entrevistador tinha exata noção do meu conhecimento técnico em cada um dos itens que eu apontava em meu curriculo. Alguem do RH jamais conseguiria isso.
[/quote]
O modelo padrão é não adotar modelo algum. O modelo padrão é uma especie de anarquismo.
Mesmo o RUP que ainda é visto por muitos ( de forma incorreta ) como um modelo fracassado deu certo em algumas empresas que conseguiram levar a coisa da forma que deveria ser feito.Não tive vivencia com o RUP então só me limito a dizer o que li sobre o assunto.
Mas posso dizer que processos bem definidos não é sinonimo de waterfall. Burocracia não é algo necessariamente ruim. RUP não era waterfall. Foco no melhoramento do processo não é necessariamente ruim. As vezes dá até um nó na cabeça ao ter que entender isso. São muitas variaveis, muita coisa pra dar errado e culpar somente o metodo pelo fracasso é ignorar completamente as outras váriaveis. É preciso fazer uma sintese pra não corrermos o risco de cair nos mesmo erros. O modelo waterfall não é defendido por ninguém, porém algumas empresas tema necessidade de adaptar seus processos para facilitar a alteração dos requisitos enquanto outras podem se dar ao luxo passar completamente por cima dos processos. A estratégia empresarial também esta relacionada com o assunto. A estratégia também esta relacionada ao mercado e com outros pontos e cada ponto impacta no outro de forma que é quase impossível entender exatamente o que acontece. Mesmo a forma de contratação utilizada pela empresa está relacionada à sua estratégia, seu negocio, sua estrutura e etc. Nem todas as empresas possuem estrutura projetizadas e nem deveria mesmo, pois cada empresa atua em um mercado, cada uma com uma estrategia, cada uma com sua cultura. Temos somente nosso limitado ponto de vista da TI sobre como as coisas acontecem, por isso para nós é fácil criticar, pois não temos a noção real das coisas.
[quote=immortalSoul]Mais uma coisa relacionado ao assunto incial do tópico.
Quem acha que ser analista é uma especie de evolução do programador, está completamente enganado. Tanto quanto quem acha o contrário.
[/quote]
As pessoas tem essa concepção porque analistas são profissionais de venda e por isso podem ser recompensados de acordo com seu desempenho. O papel do analista é fazer o corpo-a-corpo com os clientes. O bom programador por outro lado tem seu desempenho geralmente rebaixado ao nivel do pior programador existente na equipe. Mas nas empresas, tanto analistas quanto programadores estedem da classe Recurso.
Uma equipe agil deve saber tudo porque ela reune todas as disciplinas necessarias para executar o projeto, não quer dizer que cada pessoa sabe tudo, mas que a equipe é multidisciplinar e portanto analista de negócios, programadores, designers, DBAs, e todo aquele que puder contribuir para executar o projeto esta presente.
Um analista de sistema não é necessário porque neste momento o foco é executar e não vender.
ps: Já é a segunda vez que vc demonstra seu desconhecimento sobre metodos ageis nesta thread. Primeiro vc acusou agilistas de serem rigidos e inflexiveis, de acreditarem que nada vai mudar, quando são eles que pregam manter o escopo aberto enquanto é prática de todo analista de sistemas congelar a especificação do sistema em requisitos pra só então o projeto começar.
[quote=mochuara][quote=immortalSoul]Mais uma coisa relacionado ao assunto incial do tópico.
Quem acha que ser analista é uma especie de evolução do programador, está completamente enganado. Tanto quanto quem acha o contrário.
[/quote]
As pessoas tem essa concepção porque analistas são profissionais de venda e por isso podem ser recompensados de acordo com seu desempenho. O papel do analista é fazer o corpo-a-corpo com os clientes. O bom programador por outro lado tem seu desempenho geralmente rebaixado ao nivel do pior programador existente na equipe. Mas nas empresas, tanto analistas quanto programadores estedem da classe Recurso.
Uma equipe agil deve saber tudo porque ela reune todas as disciplinas necessarias para executar o projeto, não quer dizer que cada pessoa sabe tudo, mas que a equipe é multidisciplinar e portanto analista de negócios, programadores, designers, DBAs, e todo aquele que puder contribuir para executar o projeto esta presente.
Um analista de sistema não é necessário porque neste momento o foco é executar e não vender.
ps: Já é a segunda vez que vc demonstra seu desconhecimento sobre metodos ageis nesta thread. Primeiro vc acusou agilistas de serem rigidos e inflexiveis, de acreditarem que nada vai mudar, quando são eles que pregam manter o escopo aberto enquanto é prática de todo analista de sistemas congelar a especificação do sistema em requisitos pra só então o projeto começar.
[/quote]
Hã???
Do que vc está falando?
Eu disse exatamente o que voce disse quanto à equipe ser multidisciplinar, não a pessoa ( Na verdade foi justamente este o enfoque que dei o dizer que a pessoa em uma equipe não precisa saber tudo).
Segundo o analista é um vendedor? Ta de brincadeira, não é?
Terceiro. ONDE EU DISSE QUE AGILISTA É RIGIDO E INFLEXIVEL COM RELAÇÃO AO ESCOPO DO PROJETO???
sério, esse comentário foi muito estranho. Eu não sei se vc existe em uma realidade paralela ou sei lá. Só não faço a minima ideia do que vc está falando.
Vender para clientes corporativos não é brincadeira. Talvez por isso vc não tenha sido evoluido até esse ponto ainda. Clientes corporativos tem processos bastante custosos e demorados devido a toda burocracia imposta pela propria empresa ara se proteger de fornecedores que prometem mas não cumprem. O analista é um recurso utilizado para empresas de software B2B para fazer o corpo-a-corpo com esse cliente corporativo, não só durante a venda, mas depois durante o projeto. Não tenha duvida que vc esta confuso sobre analista de sistemas e analistas de negócio. Este último, como havia falado, são uma coisa completamente diferente.
[quote]Terceiro. ONDE EU DISSE QUE AGILISTA É RIGIDO E INFLEXIVEL COM RELAÇÃO AO ESCOPO DO PROJETO???
[/quote]
[quote]Na minha opinião um dos maiores erros dos agilistas é justamente tentar prever o futuro como se ele fosse certo quanto um calculod e matemática. Não é.
Dizer que o futuro é X ou Y é pura ilusão. Ninguém sabe ao certo como as coisas vao desenrolar devido a quantidade de variaveis envolvidas.
