Fim do Waterfall = Fim do Analista?

A morte lenta da função de analista pode estar relacionada à morte lenta do waterfall?

Sem contar a perda de informação com o caminho feito pelos requisitos até chegar ao desenvolvedor (existe até uma tirinha sobre isso - a montagem de um balanço na árvore -, mas não encontrei).

É claro que esta metodologia ainda não morreu, mas creio que tenha ficado claro a sua ineficiência.

Me parece que o Desenvolvimento iterativo e incremental tem papel importante na eliminação da função do analista. Posso estar enganado, mas me parece muito lógico.

Abraços

Para falar a verdade o papel no Analista está morrendo com o fim de arquiteturas complicadas e abstrações pobres. Não tem qualquer relação com o "fim do waterfall", aliás, quem disse que o Waterfall está acabando?

rodrigoy wrote:Para falar a verdade o papel no Analista está morrendo com o fim de arquiteturas complicadas e abstrações pobres. Não tem qualquer relação com o "fim do waterfall", aliás, quem disse que o Waterfall está acabando?

Cara, acredito que seja uma tendência. Acho que o modelo é rígido demais e, como li em algum lugar por aí, hoje em dia devemos planejar para o presente e codificar para o futuro.

Aqui no trabalho, como metodologia principal (recomendado para todo o projeto), ainda é o waterfall. Mas já existe um consenso entre nós que o modelo não é eficiente. Assim, no desenvolvimento de ferramentas internas, nas equipes, estamos tentando o desenvolvimento iterativo e incremental.

GUJ Master Membro desde: 23/01/2008 11:14:35 Mensagens: 1905 Offline

rodrigoy wrote:Para falar a verdade o papel no Analista está morrendo com o fim de arquiteturas complicadas e abstrações pobres. Não tem qualquer relação com o "fim do waterfall", aliás, quem disse que o Waterfall está acabando?

- Mas se esta morrendo o papel do Analista, que profissional esta emergindo ? , quanto ao fim das arquiteturas complicadas, é o fim para o seu legado ? , não posso pensar que aquele analista iria ficar para essa migração a renovar as novas abstrações e conceitos.

Marcio Duran wrote:
- Mas se esta morrendo o papel do Analista, que profissional esta emergindo ? , quanto ao fim das arquiteturas complicadas e fim para o seu legado ? , não posso pensar que aquele analista iria ficar para essa migração a renovar as novas abstrações e conceitos.

Creio que o desenvolvedor esteja absorvendo este papel.

GUJ Expert Membro desde: 18/02/2008 16:17:53 Mensagens: 3002 Offline

Marcio Duran wrote:

rodrigoy wrote:Para falar a verdade o papel no Analista está morrendo com o fim de arquiteturas complicadas e abstrações pobres. Não tem qualquer relação com o "fim do waterfall", aliás, quem disse que o Waterfall está acabando?

- Mas se esta morrendo o papel do Analista, que profissional esta emergindo ? , quanto ao fim das arquiteturas complicadas, é o fim para o seu legado ? , não posso pensar que aquele analista iria ficar para essa migração a renovar as novas abstrações e conceitos.

Não tem nenhum professional emergindo, entre Requisitos, Analista e Desenvolvedor, só fica Requisitos e Desenvolvedor. É um fortalecimento tanto dos papéis de quem tem a informação quanto de quem irá fazer o sistema para lidar com ela.

GUJ Master Membro desde: 23/01/2008 11:14:35 Mensagens: 1905 Offline

Bruno Laturner wrote:

Marcio Duran wrote:

rodrigoy wrote:Para falar a verdade o papel no Analista está morrendo com o fim de arquiteturas complicadas e abstrações pobres. Não tem qualquer relação com o "fim do waterfall", aliás, quem disse que o Waterfall está acabando?

- Mas se esta morrendo o papel do Analista, que profissional esta emergindo ? , quanto ao fim das arquiteturas complicadas, é o fim para o seu legado ? , não posso pensar que aquele analista iria ficar para essa migração a renovar as novas abstrações e conceitos.

Não tem nenhum professional emergindo, entre Requisitos, Analista e Desenvolvedor, só fica Requisitos e Desenvolvedor. É um fortalecimento tanto dos papéis de quem tem a informação quanto de quem irá fazer o sistema para lidar com ela.

Acredito nisso também !!!! ; )

celso.martins wrote:A morte lenta da função de analista pode estar relacionada à morte lenta do waterfall?

Sem contar a perda de informação com o caminho feito pelos requisitos até chegar ao desenvolvedor (existe até uma tirinha sobre isso - a montagem de um balanço na árvore -, mas não encontrei).

É claro que esta metodologia ainda não morreu, mas creio que tenha ficado claro a sua ineficiência.

Me parece que o Desenvolvimento iterativo e incremental tem papel importante na eliminação da função do analista. Posso estar enganado, mas me parece muito lógico.

Abraços

encontrei essa, mas eu ja tinha visto uma diferente:

celso.martins wrote:Creio que o desenvolvedor esteja absorvendo este papel.

Todo desenvolvedor tem que ser também um analista, onde já se viu programar sem pensar no que está fazendo?

Nem estagiário deveria fazer isso.

This message was edited 1 time. Last update was at 25/03/2009 18:04:32

fredferrao wrote:.....

Era essa mesmo... não conheço outra... sensacional essa tira. =)

Mauricio Linhares wrote:Todo desenvolvedor tem que ser também um analista, onde já se viu programar sem pensar no que está fazendo?
Nem estagiário deveria fazer isso.

Pois é... nunca achei muito lógico esses papéis distintos. Levando só para o lado da UML, o analista modelaria a solução, mas o programador deveria conhecer a UML para entender o modelo do Analista. Isso subjulgava o programador, dizendo, creio eu, que ele não era capaz de compreender um problema e modelar a solução.

EDIT:

Bruno Laturner wrote:
Não tem nenhum professional emergindo, entre Requisitos, Analista e Desenvolvedor, só fica Requisitos e Desenvolvedor. É um fortalecimento tanto dos papéis de quem tem a informação quanto de quem irá fazer o sistema para lidar com ela.

É exatamente esse o meu ponto de vista também.

GUJ Master Membro desde: 23/01/2008 11:14:35 Mensagens: 1905 Offline

Mauricio Linhares wrote:

celso.martins wrote:Creio que o desenvolvedor esteja absorvendo este papel.

Todo desenvolvedor tem que ser também um analista, onde já se viu programar sem pensar no que está fazendo?

Nem estagiário deveria fazer isso.

Nossa até quem fim eu concordo com você ....

This message was edited 3 times. Last update was at 25/03/2009 18:21:44

Dentro do modelo Iterativo, tenha a UML:

* Como rascunho.
* Como planta de software.
* Como linguagem de programação (determina uma especificação executavel, ainda em desenvolvimento)..
* Como documentação.

Visual é a palavra chave aqui.

Não vejo como isso possa subjulgar o desenvolvedor. Pelo contrário, é um meio comum para garantir a comunicação (entendimento), e explorar possiblidades em um projeto.

Esses são alguns pontos fortes, no modelo Iterativo.

No projeto Iterativo, o cliente está envolvido nas reuniões, visto como responsável pelo projeto também, e os programadores participam e não recebem recados dos analistas. Muitas perspectivas, definem um Projeto Unificado.

O Projeto em Cascata ainda é muito utilizado, pois requer uma mudança em um nível mais alto: financeiro.

IMHO

F?io Henrique wrote:
Não vejo como isso possa subjulgar o desenvolvedor. Pelo contrário, é um meio comum para garantir a comunicação (entendimento), e explorar possiblidades em um projeto.

Quando eu disse subjulgar o desenvolvedor, foi no sentido de que o desenvolvedor não seria capaz, teoricamente, de entender um problema e modelar a solução. O que acho um absurdo.

celso.martins wrote:Pois é... nunca achei muito lógico esses papéis distintos. Levando só para o lado da UML, o analista modelaria a solução, mas o programador deveria conhecer a UML para entender o modelo do Analista. Isso subjulgava o programador, dizendo, creio eu, que ele não era capaz de compreender um problema e modelar a solução.

Mas aí é que está o problema. A maior parte dos softwares não pode ser modelada em UML, porque ela é restrita demais em termos de "programação", o máximo que acontece é o analista chegar com um rascunho do que ele imagina, rascunho esse que seria muito bem mais aproveitável se feito pela equipe de desenvolvedores em vez de sair direto de um único "analista". Se fosse possível programar a maior parte dos sistemas só com UML, o Maker já teria tomado o emprego de todo mundo aqui.

Assim, eu nunca trabalhei numa consultoria de code monkeys, então nunca passei por uma situação de ser tradutor de diagramas UML, mas eu realmente custo a acretidar que existam lugares onde os programadores simplesmente "traduzam" os diagramas que um analista fez. E se isso existe, quem faz o trabalho com certeza não deve ser lá muito bom do ofício não viu, porque não tem condições de uma pessoa se passar a um absurdo desses e não odiar o que faz todos os dias.

This message was edited 1 time. Last update was at 26/03/2009 10:26:57

F?io Henrique wrote:Não vejo como isso possa subjulgar o desenvolvedor. Pelo contrário, é um meio comum para garantir a comunicação (entendimento), e explorar possiblidades em um projeto.

A maneira mais eficiente de se "explorar" coisas em um sistema é com testes e refactorings, porque eles vão lhe mostrar os resultados ali, na hora, UML é só imagem. Como já dizia aquela propaganda da Sprite, "imagem não é nada, sede é tudo"

Notícias, artigos e o maior fórum brasileiro sobre Java