Empresa Politec Global IT Services

Oi G@bi,

Eu acho muito importante essa etapa no desenvolvimento…http://www.devmedia.com.br/articles/viewcomp.asp?comp=11806

Boa sorte!

Anime:

Oi G@bi,

Eu acho muito importante essa etapa no desenvolvimento…http://www.devmedia.com.br/articles/viewcomp.asp?comp=11806

Boa sorte!

Oi !
Obrigada pelo artigo, vou ler tudo.
No momento aki na empresa não usamos diagramas e sinceramente não nos tem feito falta. Nem os clientes pedem.
Mas acho q pode ser importante dependendo da cultura da empresa.

Se alguem tiver algo a falar sobre a Politec, principalmente a do Rio, eu fico muuuuito agradecida.

Oi Oi,

Politec eh uma empresa bem grandinha. Principalmente em Brasilia.

O fato de eles usarem diagramas e bla bla bla provavelmente se deve ao fato de eles serem CMMI…

se a grana for boa, recomendo pensar com carinho =o)

Abracos

G@bi:

PARECE que Não usam metodologia ágil e coisas mais novas.
Fico com medo de estar retrocedendo…

Acho que você precisa estudar mais,

Metodologia Agil não tem nada a ver com deixar de Usar Diagramas ou documentação, metodologia agil está diretamente focado no ciclo de vida do desenvolvimento de sofware, posso muito bem utilizar diagramas UML ou outra notação e utilizar metodologia Agil (que aliaz é o mais recomendado).

O que me PARECEé que você está acostumada a trabalhar em local que não tem metodologia nenhuma, e fala que é agil, o que é o mais comum hoje em dia.

O pessoal aqui no Brasil é engraçado, programa-se de qualquer jeito, com equipe pequena e desqualificada e se diz agil, não são todas as empresas mas a grande maioria nem parou para ver o que é metodologia.

Metodologia Ágil é muito bom, já trabalhei com e sempre recomendo. Vc ve o projeto “andar”.

Quanto a Diagramas, não se “avexe”, pois eles não vão passar nada complicado. Diagramas são bons para que vc possa tirar suas dúvidas sem precisar purrinhar alguém toda hora!

Vc descobre o relacionamento, métodos e outras coisas mais! [=

Se a grana for boa, go go go! [=

Já trabalhei na Politec em Brasilia e foi uma boa experiência.
Trabalhava dentro do Banco do Brasil e seguia a metodologia do cliente, não da Politec.

Oi pessoal !
Obrigado pelos q já responderam

Eu sei q metodologia agil não tem nada haver com diagramas. Eu apenas levantei mais uma coisa q não gostei.
Pq eu trabalho com agil a pouco tempo, mas gosto muito e fico com medo de parar no tempo indo pra projetos assim
Seria um projeto da marinha q usam ejb e struts. Não devem usar spring e vou ter q fazer um curso pra usar a IDE.

A grana é boa sim, mas ainda tenho minhas duvidas se profissionalmente seria bom :oops:

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.
Fico com medo de estar retrocedendo… O salario é bom !

[]s

Luiz Aguiar:

Aqui em SP a Politec sempre foi umas das piores empresas que alguém poderia trabalhar, vou morrer falando mal dessa empresa.
[]s

Eu sou da seguinte opnião…se alguém achou que a empresa é péssima, outras pessoas vão acha-la no mínimo ruim.

Luiz Aguiar:

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.
Fico com medo de estar retrocedendo… O salario é bom !

Aqui em SP a Politec sempre foi umas das piores empresas que alguém poderia trabalhar, vou morrer falando mal dessa empresa.

[]s

rsrsrsrsrs
Mas pq ? Trabalhou lá ? Conte-nos :lol:

Olá Gabi,

Fui funcionário por um tempo (2007~2008) na Politec SP (Leopoldina), não tenho realmente o que reclamar, apenas que trabelhei demais, mas em relação a desenvolvimento de software acho que é realmente organizada. CMMI Nível 5, ISO e muitas outras coisas mais. Vai pra que área? trabalhar em que projeto já sabe?

Até!

Luiz Aguiar,

Porque é ruim a Politec? Em que sentido?

Até!

CMMi e ISO não fazem empresa nenhuma ter qualidade, alias estive lá quando ela estava passando pela prova do nível 3 se não me engano, é uma vergonha, ridículo aquilo, se ater a isso é no mínimo “ser inocente”, pra não falar outros termos mais pesado pois não te conheço.

Pra quem tem um perfil de trabalhar em empresas velhas, atrasadas e com políticas da época do inicio da era industrial, deve ser um local bom mesmo, se vc vem de bancos, governo ou telecoms, vai se sentir em casa.

Basta ver que a Politec perder vários clientes “grandes”, esteve envolvidas em vários rolos e maracutais políticas, sempre mamou e muito nas tetas do governo.

Mas essa é apenas a MINHA opinião, ninguém precisa concordar e muito menos achar que é uma verdade absoluta, quem quiser, faça a experiência e depois volte aqui pra contar.

[]s

Um cara tinha postado um lugar pra colocar opiniões sobre empresas de forma anonima, vou ver se acho pra botar aqui…

Renato_Ceadareanu:

Olá Gabi,

Fui funcionário por um tempo (2007~2008) na Politec SP (Leopoldina), não tenho realmente o que reclamar, apenas que trabelhei demais, mas em relação a desenvolvimento de software acho que é realmente organizada. CMMI Nível 5, ISO e muitas outras coisas mais. Vai pra que área? trabalhar em que projeto já sabe?

Até!

Desenvolvimento, projeto da marinha

Anime:

Oi G@bi,

Eu acho muito importante essa etapa no desenvolvimento…http://www.devmedia.com.br/articles/viewcomp.asp?comp=11806

Boa sorte!

Achei pessimo o artigo. Ou o autor nao se expressou bem ou escreveu um artigo defendendo desenvolvimento em cascata e BDUF e com argumentos fraquissimos pra defender isso.

A resposta que proponho à esta pergunta é simples: É necessário desenhar para mostrar o caminho. Sabe aquele jargão, que soa como uma frase irônica ?entendeu ou quer que eu desenhe??, pois bem, a proposta talvez seja entendida por alguns, como tão irônica quanto a pergunta: Desenhe!! Não porque os desenvolvedores na próxima fase não terão a capacidade de entender o que é para ser feito,…

Um erro na produção do desenho, corrige-se alterando o desenho, mas um erro na busca pela solução ideal para determinado problema na construção de software, pode significar desde prejuízo financeiro até rompimento de contrato e insatisfação do cliente.

As duas primeiras perguntas: TDD.
A ultima: Com essa mentalidade a melhor forma de ajudar os desenvolvedores é pedindo a conta e indo embora.

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.

YvGa:

Anime:

Oi G@bi,

Eu acho muito importante essa etapa no desenvolvimento…http://www.devmedia.com.br/articles/viewcomp.asp?comp=11806

Boa sorte!

Achei pessimo o artigo. Ou o autor nao se expressou bem ou escreveu um artigo defendendo desenvolvimento em cascata e BDUF e com argumentos fraquissimos pra defender isso.

A resposta que proponho à esta pergunta é simples: É necessário desenhar para mostrar o caminho. Sabe aquele jargão, que soa como uma frase irônica ?entendeu ou quer que eu desenhe??, pois bem, a proposta talvez seja entendida por alguns, como tão irônica quanto a pergunta: Desenhe!! Não porque os desenvolvedores na próxima fase não terão a capacidade de entender o que é para ser feito,…

Especificacao para o desenvolvedor? Proxima fase?

Um erro na produção do desenho, corrige-se alterando o desenho, mas um erro na busca pela solução ideal para determinado problema na construção de software, pode significar desde prejuízo financeiro até rompimento de contrato e insatisfação do cliente.

Desde quando um desenho garante qualidade? Qualidade se garante com código bem escrito e testado. Alias é muito mais facil o suprasumo desenhista cometer um erro tecnico no desenho (que nao compila, nao executa e nao mostra os erros) do que um desenvolvedor cercado de testes unitarios.

As duas primeiras perguntas: TDD.
A ultima: Com essa mentalidade a melhor forma de ajudar os desenvolvedores é pedindo a conta e indo embora.

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.

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…

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.

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.

Mais alguem pra falar sobre a Politec ? rsrs
Fiquei sabendo q eles tem convenio com cursos e etc…

mark_domi:

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.

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.

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.

G@bi:

Mais alguem pra falar sobre a Politec ? rsrs
Fiquei sabendo q eles tem convenio com cursos e etc…

YvGa:

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…

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.

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…

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.

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.

Ok…

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.
Fico com medo de estar retrocedendo… O salario é bom !

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