Empresa Politec Global IT Services

[quote=mark_domi][quote=YvGa]

Péssimo artigo.

P.S. Desculpe desviar o assunto do topico, mas é ruim deixar algumas coisas passarem em branco para nao confundir quem esta estudando e passando por aqui.[/quote]

Concordo que este artigo não é dos melhores.

mas concordo também com a Anime.

Metodologias ágeis não propoem a extinção da documentação, mas também não propoem a documentação completa do sistema como no caso do RUP que não é agil nem cascata como propos nosso amigo YvGA.

a Proposta da maioria das metodolias ágeis é você documentar o que realmente é necessário, para isso vc precisa conhcer o projeto como um todo e conhecer a notação que eu acho que foi o real objetivo do artigo, mostrar a notação e não a metodologia (Metodologia = Notação + Processo).

Porem, conhecendo um pouco melhor o Processo Unificado ou suas extenções como o RUP, você vai perceber que a proposta de colaboração continua com o usuário e Processo de responder a mudanças, que são dois dos quatro itens do manifesto agil, estão presentes no Processo Unificado (e no RUP).

O Processo Unificado defende a Documentação abrangente (contrario ao manifesto agil), porem ele é feito para projetos de Grandes proporções com mais de 50 Desenvolvedores, e NÃO É cascata.

Espero ter esclarecido algumas duvidas, e deixando o fanatismo de lado.

[/quote]

Veja como o artigo fala em fases, em “passar para o desenvolvedor”, sugerindo nitidamente um processo tipo linha de produção. Isso pra quem ja tem alguma vivencia em desenvolvimento de software sabe perfeitamente que nao funciona, que trava o processo, que torna qualquer alteração de requisito num tormento.

Eu não defendo o fim da documentação, eu defendo o fim da documentação como propõe o artigo, cheio de desenhos que vão para o fundo da gaveta ja no começo do projeto, desenhos que no primeiro release já estarão completamente ultrapassados em relação ao que foi implementado.

Não há documentação melhor para um sistema do que um TestSuit bem feito.

UML é ótimo para comunicação, falar sobre algo complexo fazendo alguns desenhos para se certificar que todos entenderam, até guardar esses desenhos se for o caso.

Agora se é para ficar no fundo do armário criando pó, ou pior, alguem ter que manter só pelo simples prazer de manter, eu sou absolutamente contra.

E nao, o artigo nao se propoe apenas a mostrar a formas de notação, ele discorre longamente sobre como a documentação e o Big Design Up Front são importante para os desenvolvedores conseguirem entender o que é pra ser feito.

Nao duvido nem um pouco da sua boa intenção em colocar o link do artigo, mas eu discordo dele.

Discordo tambem quando fala em etapas, porque me passa a impressao de voce estar falando em etapas bem definidas, como levantamento de requisitos, analise, design, modelagem, implementação e testes. Essa é uma fórmula que não funciona sem uma enorme dor de cabeça e estouro invariavel de prazos.

Voce não tem como prever o que será alterado nos requisitos até o fim do projeto, não tem como saber o que vai entrar, o que vai sair, que ideia mirabolante o usuário vai ter. Porque ELE mesmo normalmente ainda nao sabe o que quer direito. Entao quando voce tenta definir muita coisa ja numa primeira etapa, voce está assumindo um monte de coisas que provavelmente vao se mostrar inuteis ou irreais no decorrer do projeto. E tudo isso foi tempo e dinheiro jogado fora.

Outra coisa, não se pode confundir ser contra documentação e contra detalhamento nas fases iniciais com se contra a analise. Eu acho que ninguem no mundo é contra a analise, o problema é a forma como a analise é feita.

Voce tem nas mãos a melhor ferramenta para analise e modelagem de software que ja existiu, com ela voce pode criar, apagar, contornar, arrumar e fazer o que quiser com seu modelo. Com a vantagem que a ferramenta te dá de que quando voce terminar teu modelo é real, nao imaginário. Essa ferramenta é linguagem de programação.

Mas não se pode, nem de longe, confundir metodologias ageis, desenvolvimento dirigido por testes, com baderna, com fazer a primeira coisa que der na cabeça pra ver o que acontece. É muito diferente disso.

[quote=G@bi]Mais alguem pra falar sobre a Politec ? rsrs
Fiquei sabendo q eles tem convenio com cursos e etc…
[/quote]
:oops: :roll: :oops: :roll:

[quote=YvGa][quote=Anime]
Olá YvGa,

Eu não vi nada de dramatico no artigo,alias só passei o link,como demostração da importancia de cada etapa em um desenvolvimento…Muitos são contrarios a análise, por exemplo.(Eu,acho que a análise,diagramas faz parte de um bom desenvolvimento,aprendi isso e concordo plenamente).
Muitas vezes um programador,sem uma análise bem feita tem que refazer o código várias vezes sim.Isso é fato,não tem o que discutir.

Desculpe mas acho que seu comentário foi infeliz…É uma opinião pessoal (minha)…Claro que pode descordar…Fique à vontade… :wink:
[/quote]

Nao duvido nem um pouco da sua boa intenção em colocar o link do artigo, mas eu discordo dele.

Discordo tambem quando fala em etapas, porque me passa a impressao de voce estar falando em etapas bem definidas, como levantamento de requisitos, analise, design, modelagem, implementação e testes. Essa é uma fórmula que não funciona sem uma enorme dor de cabeça e estouro invariavel de prazos.

Voce não tem como prever o que será alterado nos requisitos até o fim do projeto, não tem como saber o que vai entrar, o que vai sair, que ideia mirabolante o usuário vai ter. Porque ELE mesmo normalmente ainda nao sabe o que quer direito. Entao quando voce tenta definir muita coisa ja numa primeira etapa, voce está assumindo um monte de coisas que provavelmente vao se mostrar inuteis ou irreais no decorrer do projeto. E tudo isso foi tempo e dinheiro jogado fora.

Outra coisa, não se pode confundir ser contra documentação e contra detalhamento nas fases iniciais com se contra a analise. Eu acho que ninguem no mundo é contra a analise, o problema é a forma como a analise é feita.

Voce tem nas mãos a melhor ferramenta para analise e modelagem de software que ja existiu, com ela voce pode criar, apagar, contornar, arrumar e fazer o que quiser com seu modelo. Com a vantagem que a ferramenta te dá de que quando voce terminar teu modelo é real, nao imaginário. Essa ferramenta é linguagem de programação.

Mas não se pode, nem de longe, confundir metodologias ageis, desenvolvimento dirigido por testes, com baderna, com fazer a primeira coisa que der na cabeça pra ver o que acontece. É muito diferente disso.[/quote]

Quanto ao artigo,tenho que concordar que não é dos melhores… :oops:
Peço desculpas,por “dizer” que seu comentário foi infeliz,infeliz fui eu com esse comentário… :oops:
E como eu disse,é uma opinião pessoal,qualquer pessoa pode discordar… :stuck_out_tongue:

Voce nao tem do que se desculpar, nem tampouco voce me ofendeu de alguma forma. Esse é um espaço justamente pra isso mesmo, para discordamos e discutirmos.

[quote=YvGa]

Voce nao tem do que se desculpar, nem tampouco voce me ofendeu de alguma forma. Esse é um espaço justamente pra isso mesmo, para discordamos e discutirmos.[/quote]

Ok… :wink:

[quote=G@bi]Olá !
Fui convidada pra trabalhar na Politec. Alguém poderia me dar informações sobre esta empresa ?
Percebi que eles usam muito diagramas de classes e sequencia (posso estar enganada) isso me deixa com uma puga atras da orelha pq acho isso meio coisa do passado rsrsrsrs
Alguém poderia me informar como é trabalhar lá ? Eles usam EJB. Parece, repito, PARECE que Não usam metodologia ágil e coisas mais novas. :frowning:
Fico com medo de estar retrocedendo… O salario é bom ![/quote]
Nem todas as empresas grandes adotam metodologia ágil. Muitas vezes, algumas equipes assumem essa postura mas não chega a ser regra.
A Politec trabalha com clientes grandes e alguns deles certamente ditam a metodologia e tecnologia a ser seguida engessando os processos.

De qualquer forma, as metodologias ágeis não impedem/proibem o uso de documentos (como diagramas). As vezes eles tornam-se apenas mais simples de serem utilizados.

Bom, sobre essa emrpesa aí, não vou falar nada pois nunca trabalhei nela, no entanto sugiro a leitura (mta repetitiva neste forum) mas que sempre vale apena pra quem não leu.

Empresas 3 Letrinhas

Ja estou no mercado a algum tempo, ja trabalhei nessas empresas 3 letrinhas, e digo… é assim mesmo… como no post. Não se iluda com selinhos, também vale para esses de melhor empresa para se trabalhar (empresa boa deixa os funcionários satisfeitos e ponto, não precisa de selinho). Isso é tudo isca pra pegar trouxa. (sic)

Outra forma é, ao entrar na empresa, manter as expectativas baixas (sic)…

[]'s